Guides & Insights

A.X K2 DSpark เทียบกับ A.X K2: สิ่งที่โมเดลแบบ Drafter-Only มอบให้คุณจริงๆ

ผู้เขียน

Rowan Sterling

วันที่เผยแพร่

Aug 7, 2026

โมเดลล่าสุด · 20ดูโมเดลทั้งหมด →

เบนช์มาร์ก: Artificial Analysis · อัปเดตทุกวัน

กลับไปยังโพสต์ทั้งหมด

สิ่งที่แปลกที่สุดเกี่ยวกับการเปรียบเทียบ A.X K2 DSpark กับ A.X K2 ก็คือมันไม่ใช่การเปรียบเทียบจริงๆ เลย A.X K2 DSpark ไม่สามารถใช้แทน A.X K2 ได้ — มันไม่สามารถใช้ได้ด้วยตัวเองเลยด้วยซ้ำ มันคือ "drafter-only checkpoint" ที่ SK Telecom วางไว้บน Hugging Face อย่างเงียบๆ ในช่วงต้นเดือนสิงหาคมโดยไม่มีการประกาศใดๆ: เป็นโมเดล draft สำหรับ speculative decoding ซึ่งหน้าที่ทั้งหมดของมันคือทำให้ A.X K2 ซึ่งเป็นโมเดลเรือธงแบบ Mixture-of-Experts ขนาด 688 พันล้านพารามิเตอร์แบบโอเพนเวตของบริษัท สร้างโทเคนได้เร็วขึ้นในขณะที่ปล่อยให้คำตอบของมันไม่เปลี่ยนแปลง ดังนั้นคำถามจริงที่การแข่งขันนี้ชี้ขาดจึงไม่ใช่ "อันไหนดีกว่า" แต่เป็น "คุณควรเรียกใช้ A.X K2 กับ DSpark หรือไม่ใช้ดี?" ทุกอย่างในบทความนี้ระบุแหล่งที่มา เนื่องจากช่องว่างระหว่างสิ่งที่ repo บอกเรากับสิ่งที่วัดได้จริงคือเรื่องราวทั้งหมด

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

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

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

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

ทำไมคำว่า "versus" นี้จริงๆ แล้วคือ "with versus without"

เนื่องจาก A.X K2 DSpark ไม่มีการใช้งานแบบ standalone จึงไม่มีสถานการณ์ใดที่คุณจะเลือกใช้มันแทน A.X K2 ทางเลือกคือระหว่าง A.X K2 เพียงอย่างเดียว กับ A.X K2 ที่มี draft model แนบอยู่ ในด้านคุณภาพของเอาต์พุต การกำหนดค่าทั้งสองแบบเหมือนกันโดยโครงสร้าง แกนเดียวที่ขยับได้คือความเร็วในการ decode

เพื่อเป็นข้อมูล นี่คือสิ่งที่ A.X K2 เป็น: ตัวถอดรหัสแบบ Mixture-of-Experts ที่มีพารามิเตอร์รวม 688 พันล้าน และใช้งานจริง 33 พันล้าน มีผู้เชี่ยวชาญ 256 ตัว บวกกับผู้เชี่ยวชาญร่วมอีก 1 ตัว (ใช้งานพร้อมกัน 8 ตัวต่อรอบการคำนวณ) 61 ชั้น 64 หัวแอตเทนชัน และคำศัพท์ 163,840 โทเคน เผยแพร่ด้วยน้ำหนักแบบเปิดภายใต้สัญญาอนุญาต Apache 2.0 เมื่อวันที่ 29 กรกฎาคม ผ่านการฝึกก่อนบนโทเคนประมาณ 8.2 ล้านล้านโทเคนในรูปแบบ MXFP8 ดั้งเดิม ใช้ Sparse Gated Attention ของ SK Telecom เพื่อประสิทธิภาพกับบริบทขนาดยาว และรองรับบริบท 262,144 โทเคน (จาก 128K ดั้งเดิมขยายเป็น 256K ผ่าน YaRN) SK Telecom รายงานว่าโดยเฉลี่ยสูงกว่า A.X K1 อยู่ 32.2 จุดเปอร์เซ็นต์จากเกณฑ์ประเมิน 14 รายการ โดยการประเมินด้านบริบทระยะยาวและเอเจนต์เพิ่มขึ้นประมาณ 83.9 จุด — ทั้งหมดเป็นข้อมูลที่ผู้พัฒนารายงานเอง ยังไม่มีคะแนนรวมจากการประเมินอิสระเผยแพร่

DSpark ถูกออกแบบมาโดยเฉพาะสำหรับสถาปัตยกรรมนั้น การ์ดระบุว่ามันเข้ากันได้กับโครงสร้าง MoE ของ A.X K2, เค้าโครง attention และการกำหนดค่า 256K ดั้งเดิม และไม่มีการตรวจสอบความถูกต้องกับเป้าหมายอื่นใด มันสืบทอดบริบท 262,144 โทเค็นเดียวกัน ดังนั้นการรันมันจึงไม่มีค่าใช้จ่ายเพิ่มเติมในเรื่องขนาดหน้าต่าง

A comparison scoreboard for A.X K2 DSpark and A.X K2: drafter-only checkpoint vs 688B / 33B-active MoE target; identical output by construction; shared 262,144-token context and Apache 2.0 license; DSpark's 60-85% faster decode labeled as a paper claim not yet measured on A.X K2; A.X K2 live open weights since 7-29.

การอ่าน model card: รู้ได้ แต่ยังไม่ยืนยัน

repo นี้ให้ภาพที่ชัดเจนว่าโมเดลคืออะไร และมีรายการสั้นๆ ของสิ่งที่มันไม่ได้บอกคุณ

สิ่งที่รู้ได้ในวันนี้:

• เป็น checkpoint สำหรับ drafter เท่านั้น ไม่สามารถใช้งานแบบเดี่ยวได้ โดยโหลดด้วย vLLM ควบคู่กับ A.X K2 ผ่าน speculative decoding

ใบอนุญาตคือ Apache 2.0; ค่าน้ำหนักสามารถดาวน์โหลดและใช้งานได้ฟรี

ความยาวบริบทตรงกับ A.X K2 ที่ 262,144 โทเคน

• มันทำงานผ่าน vLLM fork ของ SK Telecom (repo SKT-AI/vllm, branch axk2-v0.23.0) โดยใช้แฟล็ก --speculative-config

• วิธีการนี้ได้อธิบายไว้ในบทความ "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv:2607.05147, ส่งเมื่อวันที่ 6 กรกฎาคม 2026) — บทความดังกล่าวยังเป็นที่มาของตัวเลขการเพิ่มความเร็วที่คุณจะเห็นกล่าวถึง

• ไม่มีผู้ให้บริการ inference ใดที่ปรับใช้ในปัจจุบัน ดังนั้นจึงไม่มี hosted API ให้เรียกใช้

ยังไม่ได้รับการยืนยัน:

ประกาศอย่างเป็นทางการ — การ์ดให้สัญญาว่าจะเผยแพร่สู่สาธารณะ "ภายในไม่กี่วันข้างหน้า"

• ตัวเลขความเร็วที่เพิ่มขึ้นเฉพาะ A.X K2 ใดๆ กำลังอยู่ระหว่างการประเมิน และทุกตัวชี้วัดประสิทธิภาพยังไม่ได้รับการกำหนด (TBD)

• จริงๆ แล้วมันช่วยได้มากแค่ไหนภายใต้โหลด ซึ่งการ์ดระบุว่า "ขึ้นอยู่กับปริมาณงาน"

• การวัดผลใด ๆ ของแบบจำลองร่างโดยบุคคลที่สามอย่างเป็นอิสระ

The Hugging Face model card for skt/A.X-K2-DSpark, showing it is a DSpark speculative-decoding draft model and a drafter-only checkpoint for A.X K2 with no standalone use, Apache 2.0 license, a 262,144-token context, release status 'planned for public release within the next few days,' and the note that no inference provider deploys it.

DSpark แตกต่างจาก speculative decoding ทั่วไปอย่างไร

การถอดรหัสแบบคาดการณ์ (speculative decoding) เป็นกลเม็ดที่ใช้กันจนชินตา: โมเดลร่างขนาดเล็กและเร็วจะเขียนการคาดเดาสำหรับโทเค็นหลายตัวถัดไป จากนั้นโมเดลใหญ่จะตรวจสอบการคาดเดาทั้งหมดในฟอร์เวิร์ดพาสเดียว โดยยอมรับส่วนนำที่ผ่านการตรวจสอบก่อนจะดำเนินการแก้ไขหนึ่งขั้น หากทำได้ดี จะลดความหน่วงได้อย่างมากโดยไม่ทำให้คุณภาพลดลง

ประเด็นสำคัญ ตามที่งานวิจัย DSpark กล่าวไว้ คือ ผู้ร่างแบบขนานในยุคใหม่ที่เสนอลำดับยาวๆ ในรอบเดียวนั้น ประสบปัญหา "การยอมรับลดลงอย่างรวดเร็ว" เพราะโทเค็นท้ายๆ ในร่างไม่มีความสัมพันธ์กับโทเค็นก่อนหน้า ทำให้ถูกปฏิเสธบ่อยกว่ามาก และการตรวจสอบบล็อกยาวๆ โดยไม่ไตร่ตรองก็ทำให้ความจุของแบตช์ต้องสูญเปล่าไปกับโทเค็นที่อาจถูกปฏิเสธ ซึ่งลดปริมาณงานลงอย่างมาก โดยเฉพาะในระบบให้บริการที่รองรับการทำงานพร้อมกันสูง

DSpark จัดการกับปัญหาทั้งสอง:

• การร่างแบบกึ่งออโตรีเกรสซีฟ โดยจับคู่แบ็คโบนแบบขนานกับโมดูลเชิงลำดับน้ำหนักเบา เพิ่มการจำลองการพึ่งพากันภายในบล็อก เพื่อให้โทเคนที่ร่างในภายหลังขึ้นอยู่กับโทเคนก่อนหน้า ซึ่งเป็นสิ่งที่ช่วยบรรเทาการเสื่อมของส่วนต่อท้าย

• การตรวจสอบแบบกำหนดเวลาตามความเชื่อมั่น แทนที่จะตรวจสอบความยาวบล็อกที่คงที่ มันจะปรับความยาวการตรวจสอบตามคำขอแต่ละรายการ โดยอิงจากค่าประมาณความน่าจะเป็นที่คำนำหน้าจะอยู่รอด และโปรไฟล์ปริมาณงานของเอนจิน การตรวจสอบจึงปรับตามโหลด

ตัวเลขในรายงาน — และสิ่งที่มันไม่ได้บอกคุณ

นี่คือตัวเลขที่คุณจะเห็นถูกอ้างถึง: DSpark "เร่งความเร็วการสร้างต่อผู้ใช้ขึ้น 60 ถึง 85 เปอร์เซ็นต์" ที่ระดับทรูพุตที่เท่ากัน เมื่อเทียบกับเส้นฐานการผลิต MTP-1 รายงานยังระบุถึงความยาวที่ยอมรับได้ (accepted length) ที่ดีขึ้นอย่างมีนัยสำคัญ เมื่อเทียบกับตัวร่างแบบ autoregressive และแบบขนานที่ทันสมัย บนเกณฑ์มาตรฐานแบบออฟไลน์ และกล่าวว่าป้องกันการลดลงของทรูพุตอย่างรุนแรงภายใต้ข้อจำกัดด้านการโต้ตอบที่เข้มงวด

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

The arXiv abstract page for the DSpark paper (arXiv 2607.05147), stating that DSpark accelerates per-user generation speeds by 60 to 85 percent at matched throughput against the MTP-1 production baseline, deployed in the DeepSeek-V4 serving system.

สิ่งที่ต้องใช้จริงๆ ในการรันมัน

ข้อกำหนดเบื้องต้นคือส่วนที่คนส่วนใหญ่จะถอดใจ: คุณต้องโฮสต์ A.X K2 ด้วยตัวเอง ไม่มี API แบบโฮสต์สำหรับโมเดลเป้าหมาย — มันเป็น open-weight และการเสิร์ฟ MoE แบบ 688B/33B-active ถือเป็นความมุ่งมั่นด้านโครงสร้างพื้นฐานที่จริงจัง DSpark มีความสำคัญเฉพาะกับทีมที่ได้ทำความมุ่งมั่นนั้นแล้วเท่านั้น

หากคุณมี ต้นทุนส่วนเพิ่มของการเพิ่มโมเดลร่างมีน้อย:

• ดาวน์โหลด draft checkpoint ภายใต้สัญญาอนุญาต Apache 2.0 และรัน vLLM fork ของ SK Telecom (branch axk2-v0.23.0)

เปิดใช้งาน speculative decoding ผ่านแฟล็ก {{1}}--speculative-config{{/1}} โดยชี้ไปที่ {{2}}DSpark checkpoint{{/2}}

จัดสรรหน่วยความจำเพิ่มเติมสำหรับน้ำหนักแบบร่าง และยอมรับว่าตอนนี้คุณกำลังใช้งาน vLLM fork จากผู้จำหน่ายแทนเวอร์ชันมาตรฐาน — ซึ่งเป็นข้อพิจารณาด้านการบำรุงรักษา

• อย่าลืมข้อควรระวังของบทความเองที่ว่า การตรวจสอบไม่ได้ฟรี: ภายใต้การทำงานพร้อมกันสูง การตรวจสอบอย่างไม่ระมัดระวังจะกินความจุของแบตช์ ซึ่งเป็นโหมดความล้มเหลวที่การตรวจสอบแบบกำหนดตารางตามระดับความเชื่อมั่นถูกออกแบบมาเพื่อจัดการ

อีกสิ่งหนึ่งที่ควรรู้: Hugging Face รายงานว่าการดาวน์โหลด 'ไม่ถูกติดตามสำหรับโมเดลนี้' ดังนั้นจึงไม่มีสัญญาณสาธารณะว่ามีกี่ทีมที่ลองใช้งานจริง

ใครควรเลือกอันไหน

รัน A.X K2 แบบธรรมดา หากคุณตรงกับข้อใดข้อหนึ่งต่อไปนี้

• คุณรัน vLLM มาตรฐานและไม่ต้องการเช็คพอยต์ที่สองหรือ vendor fork ในเส้นทาง

เวิร์กโหลดของคุณถูกจำกัดด้วยปริมาณงานประมวลผล (throughput) ไม่ใช่ความหน่วง (latency) และผู้ใช้ยอมรับการรอคอยการสร้างผลลัพธ์ที่ยาวนาน

• คุณอยากจะรอการเปิดตัวอย่างเป็นทางการและการวัดผลอิสระครั้งแรกมากกว่า

รัน A.X K2 และ DSpark หากนี่คือคุณ:

• คุณโฮสต์ A.X K2 ด้วยตัวเอง และความหน่วงในการสร้างหรือปริมาณงานโทเค็นคือสิ่งที่ทำให้เกิดปัญหา

• เวิร์กโหลดแบบบริบทยาวและแบบเอเจนต์ทำให้ผู้ใช้ต้องรอผลลัพธ์ที่ยาวนาน — ซึ่งเป็นสภาวะที่ speculative decoding ถูกออกแบบมาเพื่อรองรับ

• คุณรู้สึกสบายใจที่จะใช้งานคอมโพเนนต์ที่ประกาศล่วงหน้า ซึ่งข้อเสียมีขอบเขตจำกัด: ในกรณีเลวร้ายที่สุดมันก็แค่ไม่ช่วย และมันไม่สามารถเปลี่ยนคุณภาพผลลัพธ์ได้

หากคุณไม่ได้โฮสต์ 688B MoE ด้วยตัวเองเลย ก็ไม่ควรเลือกทั้งสองตัวเลือก จุดแข็งด้านอธิปไตยและภาษาเกาหลีของ A.X K2 จะเข้าถึงคุณได้ก็ต่อเมื่อคุณรันมัน และหลายทีมจะเข้าถึงโมเดลโอเพนระดับแนวหน้าผ่านแคตตาล็อกแบบโฮสต์แทน จุดนี้เองที่การรักษาการผสานรวมของคุณให้ไม่ยึดติดกับโมเดลใดโมเดลหนึ่ง (model-agnostic) ให้ผลตอบแทน: เอนด์พอยต์เดียวที่ใช้ร่วมกับ OpenAI ได้ของ OrcaRouter ครอบคลุมโมเดลมากกว่า 200 รายการในราคาตามรายการของผู้ให้บริการ ด้วยมาร์กอัป 0% พร้อม failover อัตโนมัติ และ routing DSL สำหรับประกอบหลายโมเดลให้เป็นการเรียกเดียว (ทั้ง A.X K2 และ A.X K2 DSpark ยังไม่ได้ถูกโฮสต์ที่ใดในปัจจุบัน — รวมถึงบน OrcaRouter ด้วย — ดังนั้นเรื่องนี้จึงเกี่ยวกับสแตกที่เหลือของคุณ ไม่ใช่การกำหนดเส้นทางสำหรับคู่นี้) แนวทางนี้ยังคงนำมาใช้ได้: ทดลองโมเดลที่ยังไม่ผ่านการพิสูจน์กับทราฟฟิกส่วนหนึ่งแล้ว fail over โดยอัตโนมัติ แทนที่จะเดิมพันเส้นทางโปรดักชันกับมัน

สิ่งที่ควรดูต่อไป

สถานการณ์ปัจจุบันนั้นเรียบง่าย: repo มีอยู่จริง มีการบันทึกวิธีการไว้แล้ว แต่ยังไม่มีการวัดผล สามสิ่งที่ต้องจับตามองคือ การเปิดตัวสู่สาธารณะตามที่สัญญาไว้ (การ์ดระบุว่า "ภายในไม่กี่วันข้างหน้า") ตัวเลข throughput หรือ latency เฉพาะ K2 รุ่น A.X ครั้งแรกเมื่อการประเมินของ SK Telecom เสร็จสิ้น และว่าผู้ให้บริการอินเฟอเรนซ์รายใดจะรับคู่นี้ไปใช้ — ซึ่งนั่นคือสิ่งที่ทำให้ DSpark มีความเกี่ยวข้องกับทีมที่ไม่ได้โฮสต์ระบบด้วยตนเอง

คำถามที่พบบ่อย

A.X K2 DSpark สามารถแทนที่ A.X K2 ได้หรือไม่?

ไม่ใช่ มันเป็น checkpoint สำหรับ drafter เท่านั้น ไม่มีการใช้งานแบบ standalone — มันมีไว้เพื่อทำให้ A.X K2 ถอดรหัสได้เร็วขึ้น ไม่ใช่เพื่อเป็นทางเลือกแทนมัน คุณไม่สามารถรัน A.X K2 DSpark ได้หากไม่มี A.X K2

DSpark เปลี่ยนคุณภาพเอาต์พุตของ A.X K2 หรือไม่

ไม่ใช่ โดยโครงสร้างแล้ว โทเคนตัวเลือกทุกตัวจะถูกตรวจสอบโดย A.X K2 ก่อนที่จะถูกคอมมิต ดังนั้นการกระจายของเอาต์พุตจึงไม่เปลี่ยนแปลง — การ์ดระบุว่าแนวทางนี้เป็นการไม่สูญเสียข้อมูล

ฉันจำเป็นต้องโฮสต์ A.X K2 ด้วยตัวเองเพื่อใช้ DSpark หรือไม่?

ใช่ DSpark ถูกโหลดโดย vLLM พร้อมกับ A.X K2 ดังนั้นจึงไม่มีอะไรให้มันร่าง (draft) เว้นแต่คุณจะรันโมเดลเป้าหมาย 688B ขณะนี้ไม่มี hosted API สำหรับทั้งสองโมเดล

DSpark ทำงานกับโมเดลอื่น ๆ ได้หรือไม่?

SK Telecom ออกแบบมันสำหรับสถาปัตยกรรม MoE โครงสร้าง attention และบริบท 256K ของ A.X K2 และยังไม่ได้ตรวจสอบกับเป้าหมายอื่นใด

คำตัดสิน

A.X K2 DSpark เทียบกับ A.X K2 เป็น "versus" ที่คำตอบที่ตรงไปตรงมาคือ "ทั้งคู่" ถ้าคุณรัน A.X K2 อยู่แล้วและผู้ใช้ต้องรอการสร้างเอาต์พุตที่ยาวนาน โมเดลร่างคือการทดลองที่ฟรีและมีความเสี่ยงต่ำ: น้ำหนักโมเดล Apache 2.0, กรณีแย่ที่สุดคือไม่มีความเร็วเพิ่มขึ้น และโดยโครงสร้างแล้วไม่มีการถดถอยของคุณภาพเกิดขึ้นได้ ถ้าคุณไม่ได้ถูกจำกัดด้วยเวลาแฝง — หรือไม่ได้โฮสต์โมเดล MoE ขนาด 688B ด้วยตัวเองเลย — คุณสามารถเพิกเฉยได้อย่างปลอดภัยจนกว่าตัวเลขการประเมินของ SK Telecom จะเผยแพร่ และการเปิดตัวต่อสาธารณะตามที่สัญญาไว้จะทำให้โมเดลนี้เป็นทางการ สิ่งที่คุณไม่ควรทำคือการเข้าใจผิดว่าตัวเลข 60–85% ในรายงานคือการวัดผลของโมเดลนี้: ในตอนนี้ ทุกอย่างที่เกี่ยวกับ DSpark โดยเฉพาะใน A.X K2 ยังคงเป็น TBD