LFM2.5-2.6B-DSpark: ตัวร่างขนาด 328M ที่ทำให้เอเจนต์บนอุปกรณ์ของ Liquid ทำงานเร็วขึ้น 2.3 เท่า

ไม่มีใครนอก Liquid AI ที่รัน LFM2.5-2.6B-DSpark บนฮาร์ดแวร์ของตัวเองและเผยแพร่ตัวเลขออกมาแล้ว นั่นคือจุดเริ่มต้นที่ซื่อสัตย์สำหรับโมเดลนี้ เพราะทั้งหมดคือการอ้างสิทธิ์ด้านประสิทธิภาพ: มันไม่ใช่ 2.6B ที่ดีกว่า แต่เป็นโมเดลร่างที่มีพารามิเตอร์ 328M ที่อยู่ข้างหน้าโมเดลตัวแทน 2.6B อย่าง LFM2.5-2.6B และเสนอโทเคนให้มันตรวจสอบ ดังนั้นตัวแทนจึงทำงานเร็วขึ้นประมาณสองเท่าโดยไม่เปลี่ยนเอาต์พุต

เผยแพร่เมื่อวันที่ 20 สิงหาคม 2026 พร้อมบทความทางเทคนิคบน Hugging Face และโพสต์ประกอบบนบล็อกของ Liquid เอง LFM2.5-2.6B-DSpark เป็นเรือธงของตระกูลเล็ก ๆ ของเช็คพอยต์ตัวร่างสำหรับการถอดรหัสแบบคาดการณ์ที่ Liquid เผยแพร่ในวันนั้น ทุกอย่างในคอลัมน์ความเร็วด้านล่างนี้วัดโดยผู้จำหน่ายและยังไม่ได้รับการยืนยันโดยอิสระ ส่วนทุกอย่างในที่เก็บโค้ด รูปแบบ และการรองรับเฟรมเวิร์กนั้นมีไว้ให้ตรวจสอบได้

DSpark คืออะไร ในหนึ่งลมหายใจ

การถอดรหัสแบบคาดเดา (speculative decoding) คือเทคนิคการรันโมเดลร่างราคาถูกล่วงหน้าเหนือโมเดลจริง: ตัวร่างจะเดาโทเคนถัดไปจำนวนหนึ่ง โมเดลเป้าหมายจะตรวจสอบทั้งชุดในรอบการส่งผ่านไปข้างหน้าครั้งเดียว และเก็บโทเคนที่ตรงกันไว้ เมื่อเดาถูก คุณจะได้โทเคนหลายตัวในราคาของหนึ่งตัว ทำให้ปริมาณงานสูงขึ้นโดยไม่ต้องแตะต้องค่าน้ำหนักของโมเดลเป้าหมาย DSpark — เทคนิคที่นักวิจัยของ DeepSeek เสนอครั้งแรกในเดือนกรกฎาคม 2026 และนำไปใช้แล้วใน DeepSeek-V4 — คือเวอร์ชันของเทคนิคดังกล่าวที่ปรับแต่งสำหรับโมเดลขนาดเล็กที่รันบนอุปกรณ์ Liquid เรียกมันว่าการถอดรหัสแบบคาดเดาที่กำหนดเวลาด้วยความเชื่อมั่น (confidence-scheduled speculative decoding) และมีองค์ประกอบที่ทำงานร่วมกันสามส่วน: กระดูกสันหลังแบบขนานที่สร้าง hidden states สำหรับโทเคนร่างทั้งหมดในรอบเดียว หัวแบบลำดับน้ำหนักเบาที่จำลองการพึ่งพากันระหว่างโทเคนข้างเคียงเพื่อให้อัตราการยอมรับไม่ทรุดตัวช่วงท้ายของบล็อก และตัวตรวจสอบที่ตัดส่วนต่อท้ายที่มีความเชื่อมั่นต่ำทิ้งเมื่อการตรวจสอบมีต้นทุนมากกว่าที่จะประหยัดได้

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

ผู้ร่างตามตัวเลข

จุดตรวจสอบ LFM2.5-2.6B-DSpark เป็นโมเดลร่าง (draft model) แบบเน้น attention เท่านั้นที่มีพารามิเตอร์ 0.3B ประกอบด้วยเลเยอร์ attention เต็มรูปแบบ 5 เลเยอร์ (ขนาด hidden 2,048, grouped-query attention ที่มี 32 heads และ 8 key-value heads) คำศัพท์ 128K token, Markov head ที่มี rank 256 และ confidence head Liquid ฝึกมันเป็นเวลา 15 epochs บนข้อมูลที่ผสมระหว่างคำสั่ง การสนทนา โค้ด และข้อมูลการเรียกใช้ฟังก์ชัน บนฮาร์ดแวร์ AMD และเลือก epoch โดยพิจารณาจากอัตราการยอมรับสูงสุด ไม่ใช่ loss ต่ำสุด

อัตราการยอมรับคือตัวเลขที่ชี้ขาดว่าดราฟเตอร์มีคุณค่ามากเพียงใด จากเกณฑ์มาตรฐาน 5 รายการที่ขนาดแบตช์เท่ากับ 1 และอุณหภูมิเท่ากับ 0 LFM2.5-2.6B-DSpark มีค่าเฉลี่ยโทเคนที่ถูกยอมรับ 4.83 โทเคนต่อขั้นตอนการถอดรหัสบน H100 และ 4.42 บน M4 Max — คิดเป็นประมาณครึ่งหนึ่งของบล็อกที่ถูกยอมรับ ซึ่งเป็นที่มาของความเร็วที่เพิ่มขึ้นสองเท่า

การเร่งความเร็วที่ติดป้ายกำกับ

ตัวเลขทั้งหมดต่อไปนี้มาจากการวัดของ Liquid AI เอง — SGLang บน H100 80GB ตัวเดียวใน BF16 และ llama.cpp พร้อมแบ็กเอนด์ Metal บน M4 Max MacBook Pro ใน FP16 GGUF ขนาดแบตช์ 1 อุณหภูมิ 0 — และยังไม่มีฝ่ายอิสระใดทำซ้ำได้ ณ เวลาที่เขียนนี้:

• ค่าเฉลี่ย H100 — 2.67×, จาก 323 ถึง 864 tokens/s. ตามเกณฑ์วัด: MATH500 3.06×, HumanEval 2.56×, MBPP 2.64×, GSM8K 2.22×, MT-Bench 2.87×.

• M4 Max ค่าเฉลี่ย — 2.27×, จาก 61 ถึง 139 tokens/s. แยกตามเกณฑ์มาตรฐาน: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Tool calling — ในสถานการณ์การเรียกใช้ฟังก์ชันหลายเครื่องมือ เวลาแฝงเฉลี่ยลดลง 57%

• บริบทของตระกูล — ตัวแบบร่าง (drafter) ที่ใหญ่ที่สุดในตระกูลคือ LFM2.5-8B-A1B-DSpark ทำความเร็วได้ถึง 3.18 เท่าบน H100 และตัวแบบร่าง 1.2B ทำได้ถึง 2.87 เท่าบน M4 Max ส่วนตัวเลข 2.6B ที่กล่าวถึงข้างต้นจัดว่าอยู่ระดับกลางๆ ของกลุ่ม

สองสิ่งที่เกี่ยวกับตัวเลขเหล่านั้นสำคัญกว่าแค่ค่าเฉลี่ย หนึ่ง พวกมันถูกวัดที่อุณหภูมิ 0 และแบตช์ไซส์ 1 — ซึ่งเป็นคอนฟิกที่เอื้อต่อการเก็งกำไร (speculation) และเป็นคอนฟิกที่งานเอเจนต์แบบอินเทอร์แอคทีฟบนอุปกรณ์ส่วนใหญ่ใช้ การรับประกันความเหมือนกันก็ยังคงอยู่ตรงนั้น: การถอดรหัสแบบ speculative จะตรวจสอบทุกโทเคนที่เสนอมา ดังนั้นภายใต้การถอดรหัสแบบ greedy ข้อความที่ส่งออกมาจะตรงกับที่ตัวเป้าหมายจะผลิตออกมาเพียงลำพังอย่างแน่นอน สอง ช่องว่างนั้นแคบลงเมื่อความพร้อมกัน (concurrency) เพิ่มขึ้น: บน H100 ตัวเดียว Liquid รายงานว่าข้อได้เปรียบของ DSpark ลู่เข้าที่แบตช์ไซส์ประมาณ 128 ดังนั้น drafter จึงเป็นตัวช่วยเรื่องเลเทนซีสำหรับงานอินเทอร์แอคทีฟและงานที่ใช้เครื่องมือหนัก ไม่ใช่กระสุนเงินด้านปริมาณงานดิบสำหรับเซิร์ฟเวอร์ที่ทำงานเต็มพิกัด

สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน

ยืนยันแล้ว ในแง่ที่ว่า repo นั้นเปิดเป็นสาธารณะและตรวจสอบได้: drafter ถูกแจกจ่ายในรูปแบบ Safetensors (BF16) และ GGUF; มันทำงานคู่กับ LFM2.5-2.6B ที่ผ่านการ post-training แล้ว ไม่ใช่กับตัว base; การรองรับตั้งแต่เปิดตัวได้ถูกเพิ่มเข้าไปในต้นทางของ llama.cpp (พร้อม Metal kernels ที่เป็นเวอร์ชันทอลอง) และใน SGLang; มันได้รับอนุญาตภายใต้ LFM Open License v1.0 ของ Liquid; และ — สำคัญสำหรับผู้ที่วางแผนใช้งานรอบๆ ตัวมัน — การ์ดโมเดลระบุว่าไม่มีผู้ให้บริการ inference ใดรองรับมัน ดังนั้นนี่จึงเป็นคอมโพเนนต์ที่ต้องรันด้วยตัวเอง

ยังไม่ได้รับการยืนยัน: ว่าการเพิ่มความเร็วนั้นเกิดขึ้นซ้ำได้บนฮาร์ดแวร์และการกำหนดค่าอื่น ๆ (ไม่มีใครนอกเหนือจาก Liquid ที่เผยแพร่ผลการวัด), ว่า drafter จะทำงานอย่างไรเมื่อใช้การสุ่มตัวอย่าง (sampling) แทนการถอดรหัสแบบ greedy (greedy decoding), และว่าตัวเลขความหน่วงของการเรียกใช้เครื่องมือที่ 57% จะยังคงเป็นจริงในสภาพแวดล้อม agent จริง นอกเหนือจากสภาพแวดล้อม benchmark ที่ Liquid ใช้ ทั้งนี้ ไม่มีข้อใดข้างต้นเป็นข้อกล่าวหา — การเปิดตัวเพิ่งจะผ่านไปเพียงวันเดียว — แต่มันคือความแตกต่างระหว่างตัวเลขที่ดูมีแนวโน้มดีกับตัวเลขที่ผ่านการยืนยันแล้ว

กำลังรันมัน

ใน SGLang คุณใช้บิลด์ที่รองรับ DSpark เปิดเซิร์ฟเวอร์โดยชี้ไปที่โมเดลเป้าหมาย และระบุชื่อ drafter: อัลกอริทึม speculative คือ DSPARK เส้นทางของ draft model ชี้ไปที่ LiquidAI/LFM2.5-2.6B-DSpark และ block size อ่านได้จาก config.json ของ draft ส่วนใน llama.cpp คุณโหลด GGUF เป้าหมายโดยใช้ GGUF ของ draft เป็น draft model และตั้งค่า spec type เป็น draft-dspark โดย block size อ่านจาก metadata ในไฟล์ sidecar การผสานรวมทั้งสองอย่างถูกส่งขึ้นไปยังต้นทางแล้ว จึงไม่จำเป็นต้องใช้ forks — แค่บิลด์ที่ใหม่พอที่จะมีทั้งสองอย่างนี้ก็พอ

เมื่อใดที่คุ้มค่าที่จะเพิ่ม

LFM2.5-2.6B-DSpark ใช้หน่วยความจำเพิ่มเติมประมาณ 0.3GB เมื่อคุณกำลังใช้งานเอเจนต์ 2.6B จริงในสภาพแวดล้อมที่ Liquid ออกแบบมาให้มันทำงาน — บนโทรศัพท์ แล็ปท็อป หรืออุปกรณ์เอจ — สำหรับงานแบบอินเทอร์แอกทีฟหรือเรียกใช้เครื่องมือที่ไวต่อเลเทนซีและรันแบบ greedy นี่คือโปรไฟล์ที่ตัวเลข 2.27× บนอุปกรณ์และการลดเลเทนซีการเรียกเครื่องมือ 57% นั้นทำงานได้จริง มันน่าสนใจน้อยลงถ้าคุณให้บริการที่แบตช์สูงบนเซิร์ฟเวอร์ (ความเร็วจะลู่เข้าหา 1×) หรือถ้าเวิร์กโหลดของคุณรันที่อุณหภูมิสูงกว่าศูนย์ ซึ่งตัวเลขที่รายงานไว้จะไม่ครอบคลุมอีกต่อไป และถ้าคุณใช้รุ่น 8B-A1B ของตระกูลนี้ โปรดสังเกตกรณีขอบ: ความเร็วบนอุปกรณ์ของมันตอนนี้อยู่ที่ประมาณ 1.18× เท่านั้น เนื่องจากการตรวจสอบ draft tokens กระตุ้นผู้เชี่ยวชาญ (experts) ในแบ็กเอนด์ Metal ของ llama.cpp มากขึ้น — Liquid ระบุว่าประเด็นนี้เป็นที่ทราบกันดี

ไม่มีอะไรเกี่ยวกับ DSpark ที่เปลี่ยนแปลงตำแหน่งการทำงานของเอเจนต์ 2.6B — โดยการออกแบบแล้ว มันคือเรื่องของการโฮสต์ด้วยตนเอง (self-host) และมันจะอยู่เคียงข้างโมเดลแบบโฮสต์ที่คุณเรียกใช้อยู่แล้ว การผสมผสานระหว่าง drafter ในเครื่องกับ API endpoint อีกเป็นโหล คือสิ่งที่เลเยอร์การจัดเส้นทาง (routing layer) ถูกสร้างขึ้นมาเพื่อยุบรวมให้เป็นหนึ่งเดียว: คีย์ API เดียวที่ใช้กับโมเดลกว่า 200 รายการ, การสลับไปใช้ตัวสำรองอัตโนมัติเมื่อผู้ให้บริการมีประสิทธิภาพลดลง, และราคารายการของผู้ให้บริการที่ส่งผ่านโดยคิดมาร์กอัป 0% ดังนั้นการเปรียบเทียบต้นทุนระหว่างแบบ local กับแบบโฮสต์สำหรับเอเจนต์ระดับ 2.6B จึงยังคงอ่านเข้าใจได้ แทนที่จะต้องไปไล่ดูในสเปรดชีต

วิธีอ่าน LFM2.5-2.6B-DSpark ในวันนี้อย่างถูกต้องคือ มองมันเป็นคำกล่าวอ้างเรื่องความเร็วที่มีแนวโน้มดี วัดโดยผู้จำหน่าย และยังไม่ผ่านการตรวจสอบโดยอิสระ ซึ่งผูกติดอยู่กับ checkpoint จริงที่ดาวน์โหลดได้และรันได้จริง หากคุณจะปรับใช้เอเจนต์ 2.6B บนอุปกรณ์ drafter ตัวนี้ลองใช้ได้ไม่แพงและถอดออกง่าย — แค่เพิ่ม speculative flags สองตัวในคำสั่ง SGLang คง greedy decoding ไว้ แล้ววัดกับ workload ของคุณเองก่อนจะเชื่อตัวเลข 2.3× repo มีให้แล้ว ส่วนที่ยังเปิดอยู่คือการตรวจสอบโดยอิสระ