LFM2.5-DSpark: โมเดล draft ขนาด 300M ที่ทำให้ LFM2.5 เร็วขึ้น 2.7 เท่าโดยข้อความที่ได้ "เหมือนเดิมทุกตัวอักษร" — และลด latency การเรียกทูลลง 57%

20 สิงหาคม 2026 Liquid AI ปล่อย LFM2.5-DSpark — ชุดโมเดล draft สำหรับทำ speculative decoding ให้ตระกูล LFM2.5 และนี่คือของประเภทที่คนรันโมเดลบนเครื่องตัวเองควรสนใจเป็นพิเศษ เพราะมันเพิ่มความเร็วโดย ไม่แลกกับคุณภาพเลยแม้แต่นิดเดียว — ไม่ใช่ “แทบไม่ต่าง” แต่คือเหมือนกันตามนิยาม

(นี่คนละเรื่องกับ QAD Q4_0 GGUF ที่ Liquid AI ปล่อยเมื่อ 19 ส.ค. และเราเขียนถึงไปแล้ว — อันนั้นคือวิธีบีบโมเดลลง 4-bit อันนี้คือวิธีทำให้โมเดลที่มีอยู่ decode เร็วขึ้น ใช้ร่วมกันได้)

speculative decoding คืออะไร และทำไมมันถึงไม่ทำให้คำตอบเพี้ยน

ตอน generate ข้อความ คอขวดไม่ใช่การคำนวณ แต่คือ แบนด์วิดท์หน่วยความจำ — ทุกครั้งที่จะได้โทเคนหนึ่งตัว GPU ต้องอ่านน้ำหนักโมเดลทั้งก้อนจาก VRAM เข้ามาหนึ่งรอบ ได้โทเคนกลับมาหนึ่งตัว นี่คือเหตุผลที่โมเดล 8B ช้ากว่าโมเดล 1B แบบเป็นสัดส่วนตรง ๆ ทั้งที่การ์ดยังว่างอยู่มาก

speculative decoding แก้ด้วยการให้โมเดลเล็ก (draft) เดาโทเคนล่วงหน้าไว้หลายตัว แล้วให้โมเดลจริง (target) ตรวจทั้งชุดในการอ่านน้ำหนักรอบเดียว ต้นทุนการโหลดน้ำหนักหนึ่งรอบจึงถูกเฉลี่ยไปกับโทเคนหลายตัว

จุดที่คนมักเข้าใจผิดคือคิดว่ามันคือการ “ยอมใช้คำตอบของโมเดลเล็ก” — ไม่ใช่ โมเดลใหญ่ตรวจทุกโทเคนที่ถูกเสนอ ตัวไหนไม่ตรงกับที่ตัวเองจะเลือกก็ทิ้งแล้วเริ่มใหม่จากจุดนั้น อย่างที่การ์ดโมเดลเขียนไว้ตรง ๆ ว่า “the target verifies every proposed token, so the generated text is what the target would have produced on its own” — ข้อความที่ได้คือข้อความเดียวกับที่โมเดลใหญ่จะเขียนเองอยู่แล้ว

ตัวเลขจริง

Liquid AI ปล่อย draft สามตัว คู่กับ target สามขนาด แต่ละ draft มีขนาดราว 300M พารามิเตอร์ สถาปัตยกรรมเรียบง่ายมาก — attention ล้วน 5 เลเยอร์ (ตัวสำหรับ LFM2.5-2.6B ระบุ 327.7M พารามิเตอร์ hidden size 2048)

บน H100:

โมเดล	เดิม	มี DSpark	เร็วขึ้น
LFM2.5-1.2B-Instruct	656 tok/s	1,384 tok/s	2.10×
LFM2.5-2.6B	323 tok/s	864 tok/s	2.67×
LFM2.5-8B-A1B	418 tok/s	1,074 tok/s	2.54×

บน MacBook M4 Max:

โมเดล	เดิม	มี DSpark	เร็วขึ้น
LFM2.5-1.2B-Instruct	138 tok/s	350 tok/s	2.54×
LFM2.5-2.6B	61 tok/s	139 tok/s	2.27×
LFM2.5-8B-A1B	90 tok/s	106 tok/s	1.18×

ตัวเลขที่บอกความจริงที่สุดคือ acceptance rate ของ LFM2.5-2.6B อยู่ที่ 4.81 จาก 10 — คือเดา 10 ตัว ผ่านเฉลี่ย 4.81 ตัว นี่คือที่มาของ 2.67× และเป็นตัวเลขที่ควรจำไว้เวลาไปลองกับโมเดลอื่น เพราะ acceptance rate คือทุกอย่างของเทคนิคนี้

สังเกตว่า 8B-A1B บน MacBook ได้แค่ 1.18× ต่างจากบน H100 ที่ได้ 2.54× อย่างชัดเจน เหตุผลคือ A1B เป็น MoE ที่ activate พารามิเตอร์แค่ราว 1B ต่อโทเคนอยู่แล้ว ต้นทุนต่อโทเคนจึงต่ำตั้งแต่แรก และบนเครื่องที่แบนด์วิดท์จำกัด draft ขนาด 300M ก็กินสัดส่วนของงบไปมากพอจะกลืนกำไรไปเกือบหมด — บทเรียนคือ speculative decoding คุ้มที่สุดกับโมเดล dense ที่หนัก ไม่ใช่ MoE ที่เบาอยู่แล้ว

ของที่ใช้ได้จริงวันนี้

ตัว DSpark เองรวมสามส่วน: backbone แบบขนานที่ได้แรงบันดาลใจจาก DFlash, หัว Markov chain แบบลำดับสำหรับจับความสัมพันธ์ระหว่างโทเคน และ verifier ที่มี confidence schedule คอยตัดการเดาที่มั่นใจต่ำทิ้ง

ที่สำคัญกว่าสำหรับคนใช้งานคือ Liquid AI เขียนโค้ดฝั่ง llama.cpp และ SGLang ให้ตั้งแต่วันแรก และ upstream ขึ้นต้นทางแล้ว น้ำหนักมีทั้ง Safetensors และ GGUF บน Hugging Face รันด้วยคำสั่งเดียว:

llama-server -m LFM2.5-2.6B-F16.gguf \
  -md LFM2.5-2.6B-DSpark-F16.gguf \
  --spec-type draft-dspark --spec-draft-n-max 10

ข้อควรรู้เรื่องสัญญาอนุญาต: การ์ดโมเดลของ LFM2.5-2.6B-DSpark ระบุไลเซนส์เป็น lfm1.0 ซึ่งเป็นไลเซนส์ของ Liquid AI เอง ไม่ใช่ Apache-2.0 — ถ้าจะเอาไปใช้เชิงพาณิชย์ควรอ่านเงื่อนไขก่อน

ตัวเลขสุดท้ายที่ผมว่าเป็นพระเอกจริง ๆ คือ latency การเรียกฟังก์ชันลดลงเฉลี่ย 57% สำหรับ LFM2.5-2.6B ในสถานการณ์เรียกหลายทูลบนอุปกรณ์

มุมมอง AI Curator

ตัวเลข 57% นั้นสำคัญกว่า 2.67× และผมคิดว่าหลายคนจะอ่านข้ามไป

เหตุผลคือ output ของการเรียกทูลเป็นสิ่งที่ เดาง่ายผิดปกติ — มันคือ JSON ที่มีโครงสร้างตายตัว ชื่อฟิลด์ซ้ำเดิมทุกครั้ง เครื่องหมายวงเล็บและ comma อยู่ตำแหน่งที่คาดเดาได้ โมเดล draft 300M ที่เดาข้อความทั่วไปถูกไม่ถึงครึ่ง จะเดา {"name": "get_weather", "arguments": {" ถูกเกือบทั้งท่อน นี่คือกรณีที่ speculative decoding เจิดจ้าที่สุด

และมันบังเอิญตรงกับสิ่งที่ทุกคนกำลังสร้างพอดี — เอเจนต์บนอุปกรณ์ที่วนเรียกทูลสิบยี่สิบรอบกว่าจะจบงาน ในลูปแบบนั้น latency ต่อรอบไม่ได้บวกกันเฉย ๆ แต่มันคือความต่างระหว่าง “ผู้ใช้รอได้” กับ “ผู้ใช้ปิดแอป” การหั่นทิ้งครึ่งหนึ่งจึงเปลี่ยนว่าฟีเจอร์ไหน ship ได้บ้าง ไม่ใช่แค่ตัวเลขในเบนช์มาร์ก

สิ่งที่อยากให้สังเกตในเชิงกลยุทธ์: Liquid AI ปล่อยของสองวันติด (QAD 19 ส.ค., DSpark 20 ส.ค.) และทั้งสองอันไม่ใช่ “โมเดลใหม่เก่งขึ้น” แต่เป็น วิธีทำให้โมเดลเดิมรันได้จริงบนเครื่องจริง — อันหนึ่งลดขนาด อันหนึ่งลดเวลา นี่คือการเลือกสนามรบที่ต่างจากทุกคน ในขณะที่ทั้งอุตสาหกรรมแข่งกันดันเพดานความสามารถ Liquid ไปแข่งเรื่องการส่งของถึงมือผู้ใช้บนฮาร์ดแวร์ที่มีอยู่แล้ว

สำหรับนักพัฒนาไทย ข้อดีของ speculative decoding ที่ผมคิดว่าถูกมองข้ามคือมัน ไม่ต้องเปลี่ยนอะไรในโค้ดของคุณเลย ไม่ต้อง fine-tune ใหม่ ไม่ต้องประเมินคุณภาพใหม่ ไม่ต้องกลัวว่าคำตอบภาษาไทยจะเพี้ยนขึ้นเพราะโดน quantize — เพราะเอาต์พุตพิสูจน์ได้ว่าเหมือนเดิม เพิ่มไฟล์ draft หนึ่งไฟล์กับแฟล็กสองตัวใน llama.cpp เท่านั้น ทีมที่รันโมเดลบนเซิร์ฟเวอร์ตัวเองอยู่แล้วควรลองภายในสัปดาห์นี้ ต้นทุนการลองแทบเป็นศูนย์ และถ้า acceptance rate บนงานของคุณออกมาดี ก็เท่ากับได้ GPU เพิ่มมาฟรี ๆ หนึ่งเท่าตัว

แหล่งข่าว

• Up to 3.2x Faster Inference with LFM2.5-DSpark — Liquid AI (Hugging Face Blog)
• LiquidAI/LFM2.5-2.6B-DSpark — Hugging Face
• Liquid AI Releases LFM2.5-DSpark Draft Models — MarkTechPost