LFM2.5-VL-3B-DSpark เทียบกับ LFM2.5-VL-3B: คุณไม่ได้เลือกอันใดอันหนึ่ง คุณแค่แนบมันเข้าไป

การค้นหาที่นำผู้คนมาที่นี่คือการเปรียบเทียบ แต่คำตอบที่ตรงไปตรงมาคือ LFM2.5-VL-3B-DSpark และ LFM2.5-VL-3B ไม่ใช่สองสิ่งที่คุณต้องเลือกอย่างใดอย่างหนึ่ง ตัวที่สองคือโมเดลภาษาภาพขนาด 3.1B ที่คุณดาวน์โหลดและให้บริการได้ ส่วนตัวแรกคือโมเดลร่างที่มีพารามิเตอร์ 279.5M ซึ่งมีอยู่เพียงเพื่อทำหน้าที่นำหน้าโมเดลตัวที่สองและทำให้มันถอดรหัสได้เร็วขึ้น ถ้าดึงตัวดราฟต์ออกจากสแตก มันก็ไม่ให้ผลลัพธ์ใด ๆ คุณไม่สามารถวัดประสิทธิภาพมันแบบลำพังได้ เพราะ "แบบลำพัง" ไม่ใช่การตั้งค่าที่มันรองรับ การเปรียบเทียบที่แท้จริงคือ LFM2.5-VL-3B ที่ทำงานลำพัง เทียบกับโมเดลเดียวกันที่ทำงานโดยมีตัวดราฟต์ต่อพ่วงอยู่

อ่านแบบนั้นแล้วการตัดสินใจก็ยุบเหลือเพียงคำถามเดียว: หน่วยความจำที่เพิ่มขึ้นและความซับซ้อนของรันไทม์ที่เพิ่มขึ้นให้ความหน่วง (latency) แก่คุณมากพอที่จะมีความสำคัญต่อเวิร์กโหลดของคุณหรือไม่? ตัวเลขของ Liquid AI เองบอกว่าใช่สำหรับงานที่เน้น decode และบอกอย่างชัดเจนว่าไม่เมื่อ prefill ครอบงำ ไม่มีฝ่ายใดในสองฝ่ายนั้นที่ถูกทำซ้ำนอกบริษัท

จุดตรวจทั้งสองแห่งที่วางเคียงข้างกัน

สิ่งที่แตกต่างกันระหว่างทั้งสองคือเรื่องราวทั้งหมด ดังนั้นจึงคุ้มค่าที่จะวางสองรีโพซิทอรีไว้เคียงข้างกันก่อนที่การถกเถียงเรื่องความเร็วจะเริ่มขึ้น

• บทบาท — LFM2.5-VL-3B สร้างข้อความและตอบคำถามเกี่ยวกับรูปภาพ; LFM2.5-VL-3B-DSpark เสนอโทเค็นให้โมเดลนั้นตรวจสอบ และไม่สร้างสิ่งใดที่ใช้งานได้ด้วยตัวเอง

• พารามิเตอร์ — 3.1B สำหรับโมเดลเป้าหมาย, 279.5M BF16 สำหรับดราฟเตอร์ ซึ่ง Liquid ประเมินว่าเป็นการเพิ่มจำนวนพารามิเตอร์ 8.9%

• สถาปัตยกรรม — โมเดลเป้าหมายเป็นโมเดลไฮบริดที่สร้างบนแกนหลัก LFM2.5-2.6B พร้อมตัวเข้ารหัสภาพ SigLIP2 NaFlex; ดราฟเตอร์คือ 4 เลเยอร์ความสนใจแบบเต็มที่ขนาดซ่อน 2,048 พร้อม Grouped-Query Attention รวมถึงส่วนหัว Markov และส่วนหัวความเชื่อมั่น

• หน้าต่างบริบท — 32,768 โทเค็นสำหรับโมเดลเป้าหมาย; โมเดลร่างไม่มีบริบทเป็นของตัวเอง และสืบทอดบริบทของโมเดลเป้าหมาย

• ตัวเข้ารหัสภาพ — SigLIP2 NaFlex 400M บนโมเดลเป้าหมาย; ตัวร่างไม่มีเลยและไม่เคยเห็นภาพโดยตรง

• คำศัพท์ — 128,000 และ embedding กับ LM head ของ drafter ถูกผูกเข้ากับ target แทนที่จะทำซ้ำขึ้นมาใหม่ จึงเป็นเหตุผลว่าทำไมภาระหน่วยความจำจึงน้อยกว่าที่จำนวนพารามิเตอร์ 279.5M จะบ่งชี้

• สัญญาอนุญาต — ทั้งคู่เผยแพร่ภายใต้สัญญาอนุญาต LFM1.0 ของ Liquid ซึ่งบน Hugging Face ถูกจัดเป็น "other" แทนที่จะเป็นสัญญาอนุญาตของ OSI ดังนั้นโปรดอ่านข้อกำหนดก่อนนำไปใช้งานเชิงพาณิชย์

• รูปแบบ — โมเดลเป้าหมายเผยแพร่ในรูปแบบการควอนไทซ์ safetensors, GGUF, ONNX และ MLX ส่วนโมเดลร่างเผยแพร่ในรูปแบบ safetensors และ GGUF F16 ไฟล์เดียวขนาดประมาณ 567 MB

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

สิ่งที่ผู้ยกร่างแก้ไข และสิ่งที่ปล่อยไว้ตามเดิม

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

ซึ่งหมายความว่าตัวเลขคุณภาพทุกตัวที่คุณหาได้สำหรับ LFM2.5-VL-3B ใช้ได้เหมือนเดิมกับการกำหนดค่าที่จับคู่กัน ในการประเมินของ Liquid เอง โมเดลเป้าหมายได้คะแนน 80.7 บน ScreenSpot-v2, 61.5 บน BLINK, 58.3 บน MuirBench, 73.1 บน MME, 63.3 บน MMStar, 81.3 บน ChartQA และ 88.7 บน POPE — ทั้งหมดเป็นรายงานจากผู้ขาย ไม่มีอันใดถูกทำซ้ำอย่างเป็นอิสระ และทั้งหมดเป็นจริงเท่าเทียมกันไม่ว่าจะมีดราฟเตอร์ต่ออยู่หรือไม่ ไม่มีการแลกเปลี่ยนระหว่างคุณภาพกับความเร็วให้ต้องชั่งน้ำหนักตรงนี้ และหน้าเปรียบเทียบใด ๆ ที่นำเสนอเช่นนั้นได้ตีความโมเดลผิด

สิ่งที่เปลี่ยนแปลงคือต้นทุนของโทเค็นในเวลานาฬิกา Liquid วัดความเร็วในการถอดรหัสที่เพิ่มขึ้นตั้งแต่ 2.04× ถึง 2.66× บน H100 เครื่องเดียวใน BF16 ผ่าน SGLang ที่ขนาดบล็อก 9, 2.30× ถึง 3.13× บน Apple M5 Max ผ่าน MLX-VLM ที่ขนาดบล็อก 8 และ 1.57× ถึง 2.14× บน M3 Ultra ผ่าน llama.cpp เมื่อวัดแบบ end-to-end การรันเดียวกันให้ผลที่ 1.64×–2.27×, 1.56×–2.62× และ 1.30×–1.77× ตามลำดับ คู่ตัวเลขเหล่านี้คือข้อโต้แย้งทั้งหมด: การถอดรหัสดีขึ้นประมาณสองเท่าของแบบ end-to-end และช่องว่างนั้นคือส่วนของภาระงานที่ drafter แตะต้องไม่ได้

ปัญหาการเติมข้อมูลล่วงหน้า ตามที่ผู้ขายระบุ

ประโยคที่มีประโยชน์ที่สุดในประกาศของ Liquid เองคือประโยคที่โต้แย้งการตีความพาดหัวข่าวของตนแบบไม่จำกัด การอนุมานด้วยภาพและภาษา (vision-language inference) ต้องจ่ายต้นทุนการเติมข้อมูลล่วงหน้า (prefill) ซึ่งการอนุมานด้วยข้อความไม่ต้องจ่าย: ภาพจะถูกส่งผ่านตัวเข้ารหัสภาพ (vision encoder) จากนั้นโครงข่ายหลักทางภาษา (language backbone) จะประมวลผลโทเค็นภาพหลายร้อยรายการที่ตัวเข้ารหัสนั้นปล่อยออกมา บนอุปกรณ์ปลายทาง (edge device) การเติมข้อมูลล่วงหน้านั้นคิดเป็นสัดส่วนใหญ่ของเวลาหน่วงตั้งแต่ต้นจนจบ (end-to-end latency) การถอดรหัสแบบคาดการณ์ (speculative decoding) เร่งความเร็วเฉพาะการถอดรหัส (decode) เท่านั้น — การเข้ารหัสภาพและการเติมข้อมูลล่วงหน้าไม่เปลี่ยนแปลง ในกรณีที่การเติมข้อมูลล่วงหน้าครองสัดส่วนหลัก การเพิ่มความเร็วในการถอดรหัส 3 เท่าจะกลายเป็นชัยชนะแบบต้นจนจบที่เล็กลงมาก

นั่นคือกฎของ Amdahl ที่ผู้จำหน่ายนำมาใช้กับผลิตภัณฑ์ของตัวเอง และมันควรกำหนดว่าใครจะอ่านหน้านี้ การถอดข้อความยาว ๆ จากหน้าสแกนเพียงหน้าเดียว คำบรรยายภาพ บทสนทนาหลายรอบที่ส่งภาพหนึ่งภาพต่อเนื่องกันไป — หนักไปทาง decode และโมเดลร่างจึงคุ้มค่ากับพารามิเตอร์ 279.5M ของมัน คำถามสั้น ๆ เกี่ยวกับภาพความละเอียดสูงขนาดใหญ่ — หนักไปทาง prefill และมันไม่คุ้มค่า เมื่อนำเป้าหมายเดียวกันไปวางบนเซิร์ฟเวอร์ที่มีการทำงานพร้อมกันสูง ภาพก็เปลี่ยนไปอีกครั้ง: Liquid วัดพรมแดนระหว่าง throughput กับ interactivity แทนที่จะเป็นตัวเลขเพียงตัวเดียว และรายงานว่า DSpark รักษาความได้เปรียบไว้ในทุกระดับการทำงานพร้อมกันที่ทดสอบ ขณะที่ช่องว่างแคบลงเมื่อการทำงานพร้อมกันเพิ่มขึ้น

บันทึกขอบเขตย่อยอีกสองรายการจากแหล่งเดียวกัน การวัดทั้งหมดใช้การประมวลผลแบบ 16-bit สำหรับทั้ง vision encoder และ language backbone และการเร่งความเร็วของโมเดลที่ผ่านการควอนไทซ์อยู่นอกขอบเขตของรีลีสนี้ หากแผนของคุณคือจับคู่ target export แบบ 4-bit กับ drafter เพราะจุดขายทั้งหมดของ 3B VLM คือการมีขนาดพอดีในหน่วยความจำไม่กี่กิกะไบต์ ชุดค่าผสมนั้นไม่ใช่สิ่งที่ถูกวัด

สิ่งที่การแนบมันทำให้คุณต้องแลกไปจริง ๆ

หน่วยความจำคือต้นทุนที่มองเห็นได้ และการ์ดใบนี้ก็ระบุปริมาณไว้อย่างชัดเจน: พารามิเตอร์เพิ่มขึ้น 8.9% ในสแตกที่นำไปใช้งานจริง ส่วนความซับซ้อนของรันไทม์คือต้นทุนที่มองไม่เห็น SGLang ต้องใช้เวอร์ชัน v0.5.19 หรือใหม่กว่า และมีบรรทัดคำสั่งเปิดใช้งานที่ต้องใส่ --speculative-algorithm DSPARK พาธของโมเดล draft และขนาดบล็อก ตัวอย่างในการ์ดเองก็ปิดใช้งาน radix cache และกำหนดสัดส่วนหน่วยความจำแบบตายตัว ซึ่งเป็นdecisionการตัดสินใจเรื่องการ deploy ที่คุณต้องพิจารณาเอง ส่วน SGLang นั้น... SGLang ต้องใช้ v0.7.2 หรือใหม่กว่า และรับตัว drafter ผ่าน --draft-model แต่ DSpark ในนั้นปัจจุบันใช้การสุ่มแบบ greedy ดังนั้นจึงต้องบังคับให้ค่าเป็น 0 ซึ่งเป็นข้อจำกัดจริงหากแอปพลิเคชันของคุณต้องอาศัยความหลากหลายจากการสุ่ม llama.cpp ทำงานผ่านตัว drafter แบบ GGUF ที่จับคู่กับ GGUF ไม่ใช่กับ safetensors ต้นฉบับ

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

นี่คือการจับคู่แบบโฮสต์ด้วยตัวเอง OrcaRouter ไม่ได้จัดเส้นทางให้ LFM2.5-VL-3B หรือดราฟเตอร์ของมัน — คุณต้องดาวน์โหลดทั้งสองอย่างและให้บริการเอง — ดังนั้นคำถามเรื่องการจัดเส้นทางจึงเกี่ยวกับทุกสิ่งที่โมเดลเล็กส่งต่อไปให้ การติดตั้งใช้งานส่วนใหญ่ที่จับคู่ VLM ขนาด 3B บน edge เข้ากับดราฟเตอร์ ยังคงมีคำถามที่โมเดลเล็กไม่ควรตอบ และการส่งคำถามเหล่านั้นไปยัง ปลายทางเดียวที่ครอบคลุมโมเดลกว่า 200 ตัว ในราคาตามที่ผู้ให้บริการแต่ละรายกำหนด พร้อมการสลับไปใช้ตัวสำรองอัตโนมัติหากผู้ให้บริการรายใดมีประสิทธิภาพลดลง ถือเป็นการผสานรวมเพียงครั้งเดียวแทนที่จะเป็นครั้งละรายผู้ให้บริการ นอกจากนี้ยังหมายความว่าทันทีที่ผู้ให้บริการลดราคา อัตราของคุณก็สะท้อนการลดราคานั้นภายในวันเดียวกัน แทนที่จะต้องรอถึงการต่อสัญญาครั้งถัดไป

ควรดาวน์โหลดอันไหน

ถ้าภาระงานของคุณเน้นการถอดรหัส (decode-heavy) และฮาร์ดแวร์ของคุณเป็นหนึ่งในสามรุ่นที่ Liquid ทดสอบ ให้ต่อ drafter เข้าไป — ข้อเสียมีขอบเขตจำกัด เพราะเอาต์พุตพิสูจน์ได้ว่าเป็นของโมเดลเป้าหมาย และค่าใช้จ่ายหน่วยความจำต่ำกว่าหนึ่งในสิบของโมเดล ถ้าความหน่วงของคุณถูกกำหนดโดยขั้น prefill เป็นหลัก หรือคุณกำลังรันโมเดลเป้าหมายแบบควอนไทซ์ หรือคุณพึ่งพาการสุ่มแบบ non-greedy ในรันไทม์ที่ยังไม่ได้ยกเลิกข้อจำกัดนั้น ให้รัน LFM2.5-VL-3B เพียงตัวเดียว มันเร็วในแบบของตัวเอง: 228 โทเคนต่อวินาทีบน M5 Max, 116 บน AMD Ryzen AI Max+ 395 และ 20 บน Galaxy S26 Ultra ทั้งหมดเป็นตัวเลขจากผู้จำหน่าย ในหน่วยความจำประมาณ 3 GB

สิ่งที่ยังไม่มีใครบอกคุณได้ในตอนนี้ก็คือ ตัวเลขของ Liquid จะยังคงใช้ได้บนฮาร์ดแวร์ของคุณหรือไม่ ณ เวลาที่เขียน drafter มีดาวน์โหลด 37 ครั้งบน Hugging Face และไม่มีการทำซ้ำอย่างอิสระของตัวเลขใด ๆ ในตารางของมัน งานวิศวกรรมนั้นมั่นคง และข้อโต้แย้งเรื่องความถูกต้องเป็นบทพิสูจน์มากกว่าข้อกล่าวอ้าง แต่ขนาดเป็นผลจากการวัด — และการวัดจากแล็บเดียวบนเครื่องชุดเดียวก็เป็นตัวเลขประเภทที่คุณควรตรวจสอบด้วยตัวเองก่อนนำไปใส่ในแผนความจุ

OrcaRouter เข้าถึงโมเดลกว่า 200+ รายการผ่านคีย์เดียว โดยราคาตามรายการของผู้ให้บริการแต่ละรายจะถูกส่งผ่านตรง ๆ ในอัตรากำไร 0% พร้อมการสลับไปยังผู้ให้บริการรายอื่นโดยอัตโนมัติเมื่อเกิดข้อขัดข้อง ราคาตามรายการของผู้ให้บริการส่งผ่านตรง ๆ ในอัตรากำไร 0% การจับคู่ในหน้านี้เป็นแบบโฮสต์เองไม่ว่าจะทางใดก็ตาม - เราเตอร์มีไว้สำหรับทุกสิ่งที่โมเดลขนาดเล็กส่งต่อไป และหมายความว่าการลดราคาของผู้ให้บริการจะปรากฏในอัตราของคุณภายในวันเดียวกัน