A.X-K2-DSpark: โมเดลร่าง Speculative-Decoding ของ SK Telecom เปิดตัวโดยไม่มีการประกาศล่วงหน้า

A.X-K2-DSpark คือโมเดลที่คุณอาจไม่เคยเรียกใช้โดยตรง — และนั่นคือเหตุผลที่มันน่าอ่าน SK Telecom โพสต์มันบน Hugging Face อย่างเงียบๆ โดยไม่มีโพสต์เปิดตัวหรือข่าวประชาสัมพันธ์ใดๆ; การ์ดโมเดลเพียงแค่ระบุตอนต้นว่า checkpoint นี้ "อยู่ในระหว่างการตรวจสอบขั้นสุดท้าย และมีแผนจะเผยแพร่สู่สาธารณะภายในไม่กี่วันข้างหน้า" มันคือ checkpoint ที่ใช้เป็นตัวร่าง (drafter) สำหรับ speculative decoding โดยสร้างมาเพื่อภารกิจเดียว: ทำให้เรือธง A.X K2 ขนาด 688B พารามิเตอร์ของ SK Telecom ให้บริการได้เร็วขึ้นและถูกลง ด้วยการเสนอ tokens ที่ A.X K2 จะนำไปตรวจสอบต่อ นี่คือสิ่งที่ repository บอกเราจริงๆ สิ่งที่ยังไม่ได้รับการยืนยัน และเหตุผลว่าโมเดลตัวช่วยเล็กๆ แบบนี้คือที่ซ่อนของรอบถัดไปของการลดต้นทุนการให้บริการ LLM

A.X-K2-DSpark แท้จริงคืออะไร

A.X-K2-DSpark ไม่ใช่โมเดลแบบสแตนด์อโลนในความหมายที่มีนัยสำคัญใดๆ การ์ดโมเดลระบุไว้ในหมายเหตุการใช้งานตามวัตถุประสงค์ว่า มันเป็น "เช็คพอยต์สำหรับการร่างเท่านั้น" ที่ "ไม่มีการใช้งานแบบสแตนด์อโลน" โดยถูกโหลดด้วย vLLM ควบคู่ไปกับโมเดลเป้าหมาย A.X K2 ภายในลูป speculative-decoding มันคือขั้นตอนการร่างของเจเนอเรเตอร์แบบสองขั้นตอน — โมเดลขนาดเล็กจะเสนอโทเคนตัวเลือกอย่างรวดเร็ว จากนั้นโมเดลเป้าหมายจะตรวจสอบโทเคนเหล่านั้นก่อนที่จะยอมรับโทเคนใดๆ สู่เอาต์พุต

เป้าหมาย ในเชิงบริบท คือหนึ่งในโมเดล open-weight ที่ใหญ่ที่สุดเท่าที่มีอยู่ A.X K2 คือโมเดล Mixture-of-Experts ของ SK Telecom ที่มีพารามิเตอร์รวม 688B และใช้งานจริง 33B เผยแพร่บน Hugging Face ในช่วงปลายเดือนกรกฎาคม 2026 ภายใต้สัญญาอนุญาต Apache 2.0 สร้างบนสถาปัตยกรรมพื้นฐานที่จับคู่ระหว่าง Multi-head Latent Attention และ DeepSeek Sparse Attention และเพิ่มการปรับแต่ง Sparse Gate Attention สำหรับบริบทยาว (long-context) ของ SK Telecom เอง A.X-K2-DSpark ใช้ hidden states ของ A.X K2 เป็นเงื่อนไข และเพิ่มการสร้างแบบจำลองการพึ่งพาระยะใกล้แบบเบา ๆ ระหว่างตำแหน่งตัวเลือก จึงสามารถเสนอหลายโทเคนพร้อมกันแทนที่จะร่างแบบ autoregressive ตามลำดับอย่างเคร่งครัด จากนั้นทุกตัวเลือกจะถูกตรวจสอบโดย A.X K2 ก่อนที่จะถูกนำไปใช้ — ซึ่งเป็นเหตุผลที่การ์ดเรียกผลลัพธ์ว่า "lossless by construction" (ไม่สูญเสียโดยการออกแบบ): การกระจายของเอาต์พุตไม่เปลี่ยนแปลงจากตัวร่าง มีเพียงความเร็วในการให้บริการเท่านั้นที่เปลี่ยนไป

speculative decoding ทำงานอย่างไร และเหตุใด MoE ขนาด 688B ถึงจำเป็นต้องใช้มัน

การถอดรหัสแบบคาดเดา (speculative decoding) เกิดขึ้นเพราะการสร้างแบบออโตรีเกรสซีฟ (autoregressive generation) เป็นกระบวนการที่ทำงานเป็นอนุกรมและมีหน่วยความจำเป็นคอขวด การสร้างโทเคนแต่ละตัวหมายถึงการอ่านน้ำหนักของโมเดลจากหน่วยความจำ และสำหรับโมเดลขนาด 688B แล้ว ต้องย้ายข้อมูลจำนวนมหาศาลในทุก ๆ โทเคน — ถึงแม้จะมีพารามิเตอร์เพียง 33B ที่ทำงานอยู่ในการส่งผ่านไปข้างหน้าแต่ละครั้งก็ตาม เคล็ดลับคือการใช้ทรัพยากรการคำนวณเพิ่มอีกเล็กน้อยกับดราฟเตอร์ขนาดเล็กที่คาดเดาโทเคนถัดไปหลายตัวในคราวเดียว จากนั้นให้โมเดลใหญ่ตรวจสอบการคาดเดาทั้งหมดในการส่งผ่านไปข้างหน้าครั้งเดียว และเก็บคำนำหน้าที่ยาวที่สุดที่ตรงกับการแจกแจงของตัวมันเอง เมื่อดราฟเตอร์ดี คุณจะได้โทเคนสองหรือสามตัวต่อการส่งผ่านของโมเดลใหญ่หนึ่งครั้งแทนที่จะได้เพียงหนึ่งตัว โดยผลลัพธ์สุดท้ายไม่เปลี่ยนแปลง

ทั้งเกมอยู่ที่อัตราการยอมรับ ดราฟเตอร์ที่คาดเดาได้ไม่ดีจะทำให้ข้อเสนอถูกปฏิเสธ และรอบการตรวจสอบยังคงใช้แบนด์วิดท์หน่วยความจำเท่าเดิม ดังนั้นการเร่งความเร็วจึงหายไป นั่นคือเหตุผลที่ดราฟเตอร์กลายเป็นหัวข้อวิจัยที่จริงจังในตัวเอง: สำหรับโมเดลขนาด A.X K2 ความแตกต่างระหว่างการเร่งความเร็ว 1.5 เท่าและ 3 เท่า คือความแตกต่างระหว่างคลัสเตอร์ให้บริการที่มี GPU สิบตัวกับห้าตัว เลเยอร์ประสิทธิภาพแบบนี้คือแหล่งที่มาของการลดราคารอบหน้าใน LLM API ที่ให้บริการแบบโฮสต์ — ไม่ได้มาจากตัวเลขคุณภาพของโมเดลพื้นฐาน แต่มาจากสแตกการให้บริการที่ครอบอยู่รอบ ๆ

DSpark คือวิธีการ — และมันมาจากทีม DeepSeek

ชื่อรุ่น "DSpark" เป็นเทคนิคเฉพาะ และไม่ใช่สิ่งประดิษฐ์ของ SK Telecom เอกสารโมเดลอ้างอิงบทความ "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv 2607.05147) ซึ่งเป็น preprint วันที่ 6 กรกฎาคม 2026 จากทีมผู้เขียน 33 คนที่ DeepSeek ซึ่งนำเทคนิคนี้ไปใช้งานในระบบ serving ยุค V4 ของผู้เขียนเองภายใต้การจราจรจริง SK Telecom ได้ปรับเทคนิคเดียวกันนี้ให้เข้ากับโมเดลเป้าหมายของตน

ผลงานหลักสองประการของบทความนี้สอดคล้องโดยตรงกับสิ่งที่การ์ด A.X-K2-DSpark อธิบายไว้ ประการแรก การร่างแบบกึ่งออโตรีเกรสซีฟ (semi-autoregressive drafting): โครงข่ายหลักแบบขนานเสนอโทเค็นทั่วทั้งหน้าต่าง ขณะที่โมดูลแบบลำดับน้ำหนักเบาทำหน้าที่จำลองความสัมพันธ์ระหว่างตำแหน่งตัวเลือก ซึ่งแก้ปัญหาคลาสสิกที่อัตราการยอมรับของตัวร่างแบบขนานลดลงอย่างรวดเร็วตามลำดับที่เสนอ ประการที่สอง การตรวจสอบตามกำหนดความเชื่อมั่น (confidence-scheduled verification): แทนที่จะตรวจสอบโทเค็นร่างจำนวนคงที่ทุกครั้ง ระบบจะประมาณความน่าจะเป็นที่แต่ละคำนำหน้าจะอยู่รอด และกำหนดความยาวในการตรวจสอบต่อคำขอ โดยปรับให้เข้ากับโปรไฟล์ปริมาณงานของเอนจิน — ดังนั้นความพยายามในการตรวจสอบจึงคำนึงถึงโหลดแทนที่จะเป็นแบบสม่ำเสมอ

ตามตัวเลขของรายงานเอง ซึ่งเป็นการวัดโดยผู้เขียน ยังไม่ได้รับการตรวจสอบอย่างอิสระ DSpark ให้การสร้างผลลัพธ์ต่อผู้ใช้ที่เร็วกว่าเกณฑ์พื้นฐาน MTP-1 ที่ใช้งานจริง 60–85% ที่ปริมาณงานที่เท่ากัน และป้องกันการลดลงของปริมาณงานอย่างรุนแรงภายใต้ข้อจำกัดด้านการโต้ตอบที่เข้มงวด ข้อควรระวังสองประการที่สำคัญสำหรับการอ่านการประกาศนี้ ผลลัพธ์เหล่านั้นวัดบนสแตกและเป้าหมายของผู้เขียนเอง ไม่ใช่บน A.X K2 และการ์ดโมเดล A.X-K2-DSpark ระบุอย่างชัดเจนว่าการประเมินของมันเองยังอยู่ในระหว่างดำเนินการ รายงานฉบับนี้พิสูจน์ว่าวิธีการทำงานได้จริงในการผลิต แต่ไม่ได้พิสูจน์ว่า checkpoint ของ SK Telecom ให้ผลลัพธ์เช่นเดียวกันนั้นได้ — นั่นคือส่วนที่ยังไม่ได้รับการยืนยัน

สิ่งที่ repo บอก — และสิ่งที่มันไม่ได้บอก

นี่คือสิ่งที่ทราบได้จาก repository ในตอนนี้ ทั้งหมดมาจาก model card:

• บทบาท — checkpoint สำหรับ A.X K2 ที่ใช้กับ drafter เท่านั้น; ไม่สามารถใช้งานแบบ standalone ได้; ไม่ได้รับการตรวจสอบกับ target อื่นใด และ "เข้ากันไม่ได้กับโมเดลที่ไม่เกี่ยวข้อง."

• เป้าหมาย — A.X K2, 688B รวม / 33B แอคทีฟ Mixture-of-Experts.

• ความยาวบริบท — 262,144 โทเคน (256K) ซึ่งตรงกับการกำหนดค่าดั้งเดิมของ A.X K2.

• สัญญาอนุญาต — Apache 2.0.

• กลไก — การร่างแบบกึ่งออโตรีเกรสซีฟของ DSpark; ทุกตัวเลือกได้รับการตรวจสอบโดย A.X K2 ก่อนนำไปใช้ (แบบไม่สูญเสียข้อมูล).

• สถานะ — "อยู่ระหว่างการตรวจสอบขั้นสุดท้าย"; มีแผนจะเผยแพร่ "ภายในอีกไม่กี่วัน"

และนี่คือสิ่งที่ยังไม่ได้รับการยืนยันอย่างชัดเจน:

• ความแม่นยำและขนาดของเช็คพอยต์ — ทั้งสองถูกระบุเป็น TBD บนโมเดลการ์ด

• Throughput, TPOT และความยาวเฉลี่ยที่ยอมรับ — ตัวเลขสามตัวที่จะบอกว่าผู้ร่างทำงานจริงหรือไม่ ทั้งหมดเป็น TBD โดยระบุว่า "การประเมินอยู่ระหว่างดำเนินการ"

• ผลลัพธ์รายโดเมน — การ์ดสัญญาว่าจะมีการแจกแจงสำหรับภาษาเกาหลี คณิตศาสตร์ วิทยาศาสตร์ และโค้ด "ในภายหลัง" โดยไม่ระบุวันที่

• ประกาศอย่างเป็นทางการSK Telecom ยังไม่ได้ประกาศ A.X-K2-DSpark ในที่ใดที่เราหาได้; ที่เก็บคือการประกาศ

• คะแนนอิสระ — ไม่มีอยู่จริง ทุกอย่างบนการ์ดเป็นคำกล่าวอ้างของ SK Telecom เอง และส่วนใหญ่ยังเป็นเพียงคำสัญญา

ตัวเลขที่ยังไม่ได้รับการยืนยันที่สำคัญที่สุดคือค่าเฉลี่ยความยาวที่ยอมรับ — จำนวนเฉลี่ยของ draft tokens ที่ A.X K2 ยอมรับต่อรอบการตรวจสอบ (verification pass) ตัวเลขเพียงตัวเดียวนี้เป็นตัวตัดสินว่า drafter นี้เป็นสิ่งที่ดีขึ้นเล็กน้อย 1.2 เท่า หรือเป็นการอัปเกรดการให้บริการ 2.5 เท่า และมันยังเป็นตัวเลขที่มีแนวโน้มมากที่สุดที่จะถูกเผยแพร่โดยไม่มีที่มาที่ไปเมื่อเปิดตัวจริง จงมองด้วยความกังขาเมื่อมันปรากฏขึ้น: ตัวเลข 60–85% จากเอกสารของ DSpark ถูกวัดบน serving stack ของโมเดลอื่น และ A.X K2 ก็มีคุณลักษณะการยอมรับ draft เฉพาะของตัวเอง

วิธีที่คุณจะรันมันจริงๆ

การรัน drafter หมายถึงการให้บริการ A.X K2 จาก vLLM fork ของ SK Telecom ตัวอย่างของการ์ดโมเดลที่ตัดทอนเล็กน้อยคือ:

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

โดยติดตั้ง fork จาก repository ของ SKT-AI vLLM บน branch axk2-v0.23.0 ข้อควรระวังสองสามข้อที่การ์ดระบุไว้อย่างตรงไปตรงมา: การตั้งค่านี้มุ่งเป้าไปที่การกำหนดค่า context 256K ดั้งเดิมของ A.X K2 และความเร็วที่เพิ่มขึ้นขึ้นอยู่กับลักษณะงาน — concurrency, ความยาวของ output, อัตราการยอมรับ และต้นทุนสัมพัทธ์ของการร่างเทียบกับการตรวจสอบ ล้วนมีผลต่อผลลัพธ์ กล่าวอีกนัยหนึ่ง นี่คือโครงสร้างพื้นฐานสำหรับการให้บริการ ไม่ใช่สคริปต์ที่ดาวน์โหลดแล้วรันได้เลย คุณต้องมี weights ของ A.X K2, คลัสเตอร์ที่ใหญ่พอสำหรับ tensor-parallel 8 และความอดทนในการปรับ num_speculative_tokensให้เข้ากับ traffic ของคุณเอง นั่นคือโปรเจกต์ที่มีความหมายสำหรับทีมที่ให้บริการ A.X K2 อยู่แล้ว ไม่ใช่เหตุผลที่จะเริ่มตั้งระบบใหม่ขึ้นมา

เศรษฐศาสตร์: ชั้นประสิทธิภาพเอาชนะการกล่าวอ้างคุณภาพ

สาเหตุที่โมเดลดราฟต์สำหรับโมเดล 688B น่าจับตามองก็คือ การแข่งขันด้านเบนช์มาร์กของโมเดลฐานส่วนใหญ่ถึงจุดอิ่มตัวแล้ว แต่การแข่งขันด้านต้นทุนการให้บริการยังไม่ถึงจุดนั้น SK Telecom เปิดตัวผลิตภัณฑ์ของตัวเองโดยเน้นประสิทธิภาพอยู่แล้ว — การเปลี่ยนแปลง Sparse Gate Attention อ้างว่าช่วยเพิ่มปริมาณโทเค็นรวมขึ้น 67.7% เมื่อเทียบกับเจนเนอเรชันก่อนหน้าที่อินพุต 120K โทเค็น — และดราฟเตอร์ก็คือแนวคิดเดียวกันที่นำมาประยุกต์ใช้กับการดีโค้ด ทุกโทเค็นดราฟต์ที่ถูกยอมรับคือการฟอร์เวิร์ดพาสของโมเดลใหญ่ที่คุณไม่ต้องจ่ายเงิน

สำหรับใครก็ตามที่ใช้งานโมเดลเหล่านี้ผ่าน API แทนที่จะโฮสต์เอง ตัวดราฟเตอร์จะมองไม่เห็น — และนั่นคือประเด็น เมื่อผู้ให้บริการเพิ่ม speculative decoding เข้าไปในเซิร์ฟวิ่งสแตกของพวกเขา คุณจะไม่เห็นโมเดลใหม่ คุณจะเห็นโมเดลเดิมเร็วขึ้นและถูกลงต่อโทเค็น ชั้นราคามีความสำคัญด้วยเหตุผลเดียวกัน: ที่ OrcaRouter เราส่งต่อราคาที่ผู้ให้บริการตั้งไว้ตรงๆ โดยไม่มีมาร์กอัป 0% ดังนั้นเมื่องานด้านประสิทธิภาพการให้บริการของเวนเดอร์แสดงผลเป็นการลดราคา มันจะใช้งานจริงบนฝั่งเราในวันเดียวกัน — ไม่ต้องเจรจาใหม่ ไม่ต้องแก้ไขสัญญา และสำหรับโมเดลที่ยังไม่ผ่านการพิสูจน์ที่อาจจะสำเร็จหรือไม่ก็ตาม การใช้รูทติ้งพร้อมระบบ failover อัตโนมัติเป็นวิธีลองใช้โดยไม่ต้องวางเดิมพันกับเส้นทางการผลิต: คีย์ API เดียว และคำขอจะเปลี่ยนไปยังผู้ให้บริการรายอื่นถ้ารายแรกเสื่อมประสิทธิภาพ

หมายเหตุความตรงไปตรงมาอย่างหนึ่งสำหรับรุ่นนี้: A.X-K2-DSpark เป็นเช็คพอยต์สำหรับ drafter เท่านั้น ดังนั้นจึงไม่ใช่สิ่งที่ API โมเดลที่โฮสต์ใด ๆ จะสามารถ route ได้ — รวมถึงของเราด้วย Drafter เป็นส่วนประกอบฝั่ง serving ไม่ใช่ผลิตภัณฑ์ที่เรียกใช้งานได้ เมื่อ drafter ถูกปล่อยออกมาและตัวเลข eval มาถึง สิ่งที่จะปรากฏในรายการราคาคือ A.X K2 ที่เร็วกว่าและถูกกว่า — ไม่ใช่เอนด์พอยต์ใหม่ที่ชื่อว่า "DSpark"

คำถามสองสามข้อที่ควรค่าแก่การตอบ

ฉันใช้ A.X-K2-DSpark ด้วยตัวเองได้ไหมไม่ — นั่นคือข้อเท็จจริงชี้ขาดของการเปิดตัวครั้งนี้ มันคือ checkpoint ที่ใช้เป็น drafter เท่านั้น ไม่มีการใช้งานแบบ standalone และไม่มี public API; มันมีอยู่เพียงในฐานะตัวช่วยภายใน speculative-decoding loop ของ vLLM ที่ให้บริการ A.X K2 และการ์ดระบุว่ายังไม่ได้รับการตรวจสอบกับ target อื่นใด

A.X-K2-DSpark เป็นคู่แข่งของ A.X K2 หรือไม่ ตรงกันข้าม มันเป็นตัวเร่งความเร็วสำหรับ A.X K2 — โมเดลเดียวกันจะทำงานเร็วขึ้น โดยที่การกระจายเอาต์พุตไม่เปลี่ยนแปลง คิดว่ามันเป็นชิ้นส่วนเพิ่มประสิทธิภาพแบบติดตั้งเพิ่ม ไม่ใช่รุ่นใหม่ในกลุ่มผลิตภัณฑ์

มันจะปล่อยจริง ๆ เมื่อไหร่ การ์ดโมเดลระบุว่าอยู่ระหว่างการตรวจสอบขั้นสุดท้าย และมีแผนเผยแพร่สู่สาธารณะ "ภายในไม่กี่วันข้างหน้า" นั่นคือทั้งหมดที่ยืนยันได้ วันที่ควรจับตาคือวันที่ตัวเลข TBD — throughput, TPOT และ mean accepted length — ถูกกรอกครบ เพราะนั่นคือตอนที่การปล่อยจะไม่ใช่แค่คำสัญญา แต่กลายเป็นสิ่งที่คุณประเมินได้

หากฉันใช้ A.X K2 ผ่าน API ฉันจำเป็นต้องคิดเกี่ยวกับเรื่องนี้หรือไม่?อาจจะไม่โดยตรง สแตกการให้บริการที่อยู่เบื้องหลัง API เป็นตัวตัดสินว่ามีดราฟเตอร์อยู่ในวงจรหรือไม่ คุณเห็นผลลัพธ์เป็นราคาและความหน่วง ไม่ใช่แฟล็ก มันสำคัญที่สุดสำหรับทีมที่โฮสต์ A.X K2 ด้วยตนเอง ซึ่งการเลือกใช้คือการเปลี่ยนแปลงการกำหนดค่า vLLM ที่พวกเขาควบคุม

ประเด็นที่นี่ไม่ใช่{{1}}ตัว drafter เอง{{/1}} — แต่เป็น{{2}}สิ่งที่ drafter ส่งสัญญาณออกมา{{/2}} {{3}}งานด้านประสิทธิภาพกำลังค่อยๆ กลายเป็นหมวดหมู่การเปิดตัวของตัวเอง{{/3}} และ{{4}}โมเดลใหม่ที่น่าสนใจที่สุดในปีนี้คือตัวช่วยที่ทำให้โมเดลใหญ่มีต้นทุนถูกลงมากขึ้นเรื่อยๆ ไม่ใช่โมเดลที่ใหญ่ขึ้น{{/4}} {{5}}A.X-K2-DSpark{{/5}} คือ{{6}}ตัวอย่างที่ชัดเจนที่สุดในตอนนี้{{/6}}: {{7}}เช็คพอยต์ที่ไม่มีการใช้งานแบบเดี่ยว{{/7}} {{8}}โพสต์ก่อนการประกาศ{{/8}} {{9}}โดยมีหลักฐานส่วนใหญ่ของตัวเองยังเป็น TBD{{/9}} จับตาดู{{10}}ตัวเลข accepted-length{{/10}} เมื่อมันออกมา ถือว่า{{11}}ผลลัพธ์จากบทความของ DSpark{{/11}} เป็น{{12}}ที่มาของวิธีการ{{/12}} มากกว่าจะเป็น{{13}}คำสัญญาสำหรับเช็คพอยต์นี้{{/13}} และถ้า{{14}}คุณให้บริการ A.X K2 ด้วยตัวเอง{{/14}} {{15}}จัดสรรงบประมาณสำหรับ benchmark{{/15}} — นั่นคือ{{16}}วิธีเดียวที่จะรู้{{/16}}ว่า{{17}}drafter ที่ถูกโพสต์อย่างเงียบๆ{{/17}} เป็นแค่{{18}}ของเสริมเล็กน้อยแบบ 1.2x{{/18}} หรือ{{19}}ของจริง{{/19}}.