เมื่อรันโมเดลภาษาในเครื่อง เวลาที่ผู้ใช้รอไม่ได้ขึ้นอยู่กับความเก่งของโมเดลเท่านั้น แต่ยังขึ้นกับความเร็วในการสร้าง token ทีละคำ Liquid AI เปิดตัว checkpoint ชุด LFM2.5-DSpark เพื่อเพิ่มเส้นทาง speculative decoding ให้โมเดล LFM2.5 สามรุ่น โดยรายงานความเร็วสูงสุด 3.18 เท่า บน NVIDIA H100 and 2.87 เท่า บน MacBook Pro ชิป M4 Max จุดสำคัญคือในโหมด greedy decoding ลำดับคำตอบที่ปล่อยออกมายังคงเหมือนการรันโมเดลหลักเพียงตัวเดียว
โมเดลที่รองรับประกอบด้วย LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B ไฟล์มีทั้ง Safetensors and GGUF พร้อมการรองรับตั้งแต่วันแรกใน SGLang and llama.cpp แต่ต้องนำไปรันเอง เพราะในเวลาที่รายงานยังไม่มีผู้ให้บริการ inference บน Hugging Face เปิด checkpoint กลุ่มนี้เป็นบริการสำเร็จรูป
ให้โมเดลเล็กเดาก่อน แล้วให้โมเดลหลักตรวจทีเดียว
speculative decoding เปลี่ยนลำดับงานจากการให้โมเดลหลักสร้าง token ทีละตัว เป็นการใช้ draft model ขนาดเล็กเสนอคำหลายตัวล่วงหน้า จากนั้นโมเดลหลักตรวจทั้งชุดในการ forward pass ครั้งเดียว หากคำที่เสนอผ่านการตรวจ ระบบก็รับไปใช้ ทำให้ลดจำนวนรอบที่ต้องเรียกโมเดลใหญ่โดยไม่เปลี่ยนเกณฑ์ตัดสินคำตอบสุดท้าย
draft model ของ DSpark มีพารามิเตอร์ราว 300 ล้านตัว รุ่นที่จับคู่กับเป้าหมาย 1.2B Has 295.7M parameters ส่วนรุ่นสำหรับเป้าหมาย 2.6B and 8B-A1B Has 327.7M parameters โครงสร้างใช้ full-attention 5 ชั้น และเสนอ token เป็นบล็อกขนาด 9 น้ำหนัก embedding กับ LM head ไม่ได้บรรจุซ้ำ แต่ดึงจากโมเดลเป้าหมายตอนโหลด ส่วน repository ของ drafter รุ่น 2.6B มีขนาด 655 MB ใน BF16 ซึ่งเป็นต้นทุนหน่วยความจำที่ต้องเพิ่ม
ภายในประกอบด้วยสามส่วน backbone แบบขนานเสนอ hidden state ของคำร่างทั้งหมดในรอบเดียว sequential head ขนาดเบาที่เชื่อมความสัมพันธ์ของ token ข้างเคียง และ verifier ที่ประเมินความมั่นใจ หากส่วนท้ายมีโอกาสไม่ผ่านและการตรวจจะเสียมากกว่าได้ ระบบก็ตัดส่วนนั้นออกก่อน แนวทางนี้พยายามรักษาสมดุลระหว่างการเดาล่วงหน้าเยอะกับภาระที่ต้องย้อนกลับเมื่อเดาผิด
ความเร็วขึ้นกับว่างานนั้นเดาง่ายเพียงใด
Liquid AI ทดสอบด้วย H100 หนึ่งตัว ใน BF16 ผ่าน SGLang และบน M4 Max MacBook Pro ผ่าน llama.cpp, Metal และน้ำหนัก GGUF แบบ FP16 ทั้งสองชุดใช้ block size 9, batch size 1, temperature 0 With MATH500, HumanEval, MBPP, GSM8K และ MT-Bench
ผลของ LFM2.5-8B-A1B แสดงความผันผวนชัดเจน บน MATH500 ระบบรับคำร่างเฉลี่ย 8.27 จาก 10 tokens และเร็วขึ้น 3.18 เท่า แต่บน GSM8K รับเพียง 4.02 tokens ความเร็วเพิ่มเหลือ 1.29 เท่า ส่วนโมเดล 1.2B บน MT-Bench รับเฉลี่ย 3.90 tokens และเพิ่มความเร็วบน H100 1.66 เท่า จึงไม่ควรนำตัวเลขสูงสุดไปคาดกับทุก prompt
กรณีที่เหมาะคือ agent ที่ต้องคิด เรียกเครื่องมือ แล้วกลับมาคิดต่อหลายรอบ เพราะต้นทุน decode เกิดซ้ำในคำขอเดียว Liquid AI รายงานว่าในสถานการณ์ function calling หลายเครื่องมือ DSpark ลด latency เฉลี่ย 57% For LFM2.5-2.6B แต่ประโยชน์จริงยังขึ้นกับรูปแบบข้อความและอัตราที่คำร่างได้รับการยอมรับ
เร็วขึ้นโดยแลกกับหน่วยความจำและความซับซ้อน
ข้อควรระวัง: คำว่าเร็วขึ้นสูงสุด 3.18 เท่า เป็นผลในบางโมเดลและบางชุดทดสอบ ไม่ใช่ค่าเฉลี่ยทุกงาน บน M4 Max โมเดล MoE รุ่น LFM2.5-8B-A1B เร็วขึ้นเฉลี่ยเพียง 1.18 เท่า เพราะข้อจำกัดของการทำ MoE ใน Metal backend ของ llama.cpp และการตรวจหลาย token ทำให้เปิดใช้ expert และเคลื่อนย้ายน้ำหนักมากขึ้น
การเพิ่ม drafter ยังใช้หน่วยความจำมากขึ้น ต้องเลือก build ของ SGLang หรือ llama.cpp ที่รองรับ และเพิ่มชิ้นส่วนในการดูแลระบบ แม้ output แบบ greedy จะเหมือนเดิม แต่ผู้ใช้งานที่ใช้ sampling หรือการตั้งค่าอื่นไม่ควรเหมารวมผลดังกล่าว ควรเทียบกับ baseline ที่ใช้รุ่น runtime และพารามิเตอร์เดียวกันก่อนนำไป production
ความหมายต่อผู้ประกอบการ/ผู้ใช้งานไทย
ส่วนนี้เป็นความเห็นของสมาคมโดรนไทย: DSpark ชี้ว่าการทำ AI server ให้ตอบเร็วขึ้นไม่จำเป็นต้องเริ่มจากซื้อ GPU รุ่นใหญ่กว่าเสมอไป ซอฟต์แวร์ decode ที่เหมาะกับโมเดลและงานอาจเพิ่ม throughput จากฮาร์ดแวร์เดิมได้ ผู้ให้บริการแชตบอตหรือ agent ภาษาไทยควรเก็บ trace ของงานจริง แล้ววัด acceptance rate, latency และ RAM/VRAM ที่เพิ่มขึ้นก่อนเทียบราคาอัปเกรดเครื่อง
สำหรับผู้ที่ต้องการรันโมเดลในเครื่องส่วนตัวแทนคลาวด์ต่างประเทศ Mac ที่มี unified memory เพียงพอหรือเครื่อง NVIDIA อาจใช้แนวทางนี้ได้ แต่ตัวเลข M4 Max แสดงแล้วว่าผลไม่ได้ดีเท่ากันทุกสถาปัตยกรรม การซื้อ eGPU หรือการ์ดจอเพิ่มจึงควรตรวจว่า runtime และโมเดลเป้าหมายรองรับ speculative decoding จริง ไม่เช่นนั้นฮาร์ดแวร์ที่นำเข้าเพิ่มอาจไม่ได้ลดเวลารออย่างที่คาด
ในทางต้นทุน องค์กรควรคำนวณค่าใช้จ่ายต่อ token หรือจำนวนคำขอพร้อมกัน แทนการดู benchmark สูงสุดเพียงค่าเดียว หาก drafter เพิ่มหน่วยความจำจนต้องขยับไป GPU รุ่นแพงกว่า ประโยชน์ด้านความเร็วอาจไม่คุ้ม แต่ถ้าภาระงาน agent มีรูปแบบซ้ำและยอมรับคำร่างได้สูง การลงทุนปรับ runtime อาจเลื่อนการซื้อเซิร์ฟเวอร์ล็อตใหม่ออกไปได้