MiniCPM-V 4.7 ใส่โมเดลวิชันขนาด 35B ลงใน 3 GB: ไขข้อกล่าวอ้าง 100 tok/s

โมเดลขนาด 35,000 ล้านพารามิเตอร์ไม่สามารถบรรจุลงในสามกิกะไบต์ได้ แต่ MiniCPM-V 4.7 35B-A3B ก็ทำงานได้ในพื้นที่ราวสามกิกะไบต์อยู่ดี และทั้งสองประโยคก็เป็นความจริง — นั่นคือกลเม็ดทั้งหมด และเป็นเหตุผลว่าตัวเลขที่หมุนเวียนเกี่ยวกับการเปิดตัวครั้งนี้คุ้มค่าที่จะหยุดพิจารณาให้ดี โมเดลนี้เป็นรายการ sparse mixture-of-experts ตัวแรกของ OpenBMB ในสาย MiniCPM-V: จัดเก็บพารามิเตอร์ 35.2 พันล้านตัว เปิดใช้งานประมาณ 3 พันล้านตัวต่อโทเค็น สัญญาอนุญาต Apache-2.0 น้ำหนักโมเดลอยู่บน Hugging Face รองรับการอ่านภาพ ชุดภาพหลายภาพ และวิดีโอ และตอบกลับเป็นข้อความ ตั้งแต่ 10 ตุลาคมเป็นต้นมา ยังรันใน llama.cpp ต้นน้ำได้ด้วย ซึ่งเป็นที่ที่คนส่วนใหญ่ได้รู้จักมัน สิ่งที่ตามมาจะแยกตัวเลขสามตัวที่ทุกคนพูดซ้ำ — 3 GB, 35B และตัวเลข 100 tok/s — และแสดงว่าตัวเลขใดบ้างที่ OpenBMB เผยแพร่จริง โมเดลโฮสต์กว่า 200 โมเดล คีย์เดียว ราคาตามรายการของผู้ให้บริการส่งต่อโดยไม่มีมาร์กอัป 0% ดูว่า OrcaRouter จัดเส้นทางอะไรบ้าง เช็กพอยต์แบบเปิดน้ำหนักยังคงอยู่บนฮาร์ดแวร์ของคุณ ส่วนทางออกแบบโฮสต์คือปลายทางเดียว ความล้มเหลวของ AI และเหตุการณ์ของเอเจนต์ที่ถูกบันทึกไว้เบื้องหลังการเปิดตัวแบบนี้ ถูกรวบรวมไว้ใน the OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง ระดับความมั่นใจ และสถานะการโต้แย้งของตัวเอง

สามกิกะไบต์ พารามิเตอร์สามหมื่นห้าพันล้านตัว และไม่มีความขัดแย้ง

การคำนวณจะดูเหมือนเป็นไปไม่ได้ก็ต่อเมื่อคุณถือว่า “in memory” หมายถึง “ทั้งหมด” MiniCPM-V 4.7 35B-A3B เก็บพารามิเตอร์ไว้ในหน่วยความจำประมาณ 3 พันล้านตัว และสตรีม experts ที่เหลือเข้ามาเมื่อเราเตอร์ร้องขอ กรอบแนวคิดใน model card เองเรียกว่า Lookahead Expert Scheduling ซึ่งเป็นตัวทำนายเส้นทางระดับข้ามเลเยอร์ที่ดึง experts ที่เลเยอร์ถัดไปมีแนวโน้มจะต้องใช้ล่วงหน้า โดยซ้อนทับการโหลดนั้นกับการคำนวณที่กำลังดำเนินอยู่แล้ว model card ระบุอย่างระมัดระวังว่าการทำนายมีผลเพียงขับเคลื่อนการดึงล่วงหน้าและการจัดตารางเท่านั้น โทเคนยังคงเป็นไปตามเส้นทางจริงของโมเดล และ expert ที่ตัวทำนายพลาดไปจะถูกโหลดและประเมินเหมือนกับ expert อื่น ๆ

ความแตกต่างนั้นมีผลลัพธ์ที่วัดได้ ที่เก็บ GGUF เผยแพร่โมเดลทั้งหมดในทุกการควอนไทซ์ที่ใช้กันทั่วไป และไม่มีไฟล์ใดในนั้นมีขนาดสามกิกะไบต์:

• Q4_K_M — 21.2 GB บนดิสก์

• Q8_0 — 36.9 GB

• F16 — 69.4 GB

• ตัวโปรเจ็กเตอร์วิชัน — 0.9 GB เมื่อบีบอัด 4 เท่า, 1.1 GB ที่ f16

ดังนั้น "3 GB" จึงเป็นตัวเลขหน่วยความจำที่คงอยู่ในเครื่องภายใต้ expert streaming บนโทรศัพท์ ไม่ใช่ขนาดดาวน์โหลด และไม่ใช่ข้อกำหนด VRAM สำหรับเดสก์ท็อป หากคุณกำลังวางแผนการดีพลอย ตัวเลขที่กำหนดดิสก์และครั้งแรกที่โหลดคือ 21.2 GB ที่ Q4_K_M และตัวเลขที่กำหนดขนาดพื้นที่ใช้งานในสภาวะคงที่บนโทรศัพท์คือ ~3 GB ของผู้จำหน่าย ทั้งสองตัวเลขอยู่ในรีลีส พวกมันตอบคำถามที่ต่างกัน และการรายงานส่วนใหญ่ได้ยุบทั้งสองให้เป็นตัวเลขเดียว

100 tok/s มาจากที่ใด และไม่ได้มาจากที่ใด

นี่คือส่วนที่ควรพูดตรง ๆ OpenBMB ไม่ได้เผยแพร่ตัวเลข 100 tok/s สำหรับ MiniCPM-V 4.7 ตัวเลขบนการ์ดโมเดลคือ 13+ โทเค็น/วินาที บน iPhone 17 Pro Max ที่หน่วยความจำประมาณ 3 GB นั่นคือข้อกล่าวอ้างเรื่องทรูพุตบนอุปกรณ์เพียงข้อเดียวที่การเปิดตัวนี้ระบุ และเป็นการวัดโดยผู้จำหน่ายบนฮาร์ดแวร์ที่ไม่มีใครนอกห้องแล็บเคยจำลองซ้ำได้

ค่าตัวเลขที่สูงกว่านี้มีอยู่จริง และค่าดังกล่าวมาจากอาร์ติแฟกต์ที่แตกต่างออกไป ฟอร์ก llama.cpp-omni ของ OpenBMB — ซึ่งเป็นรีโพซิทอรีที่บรรจุการปรับแต่งประสิทธิภาพสำหรับการทำงานบนอุปกรณ์ — เผยแพร่ตารางของตนเองสำหรับเป้าหมาย 35B-A3B โดยจัดแบ่งตามการปรับแต่งที่เปิดใช้งาน:

• iPhone 18 Pro Max, 12 GB — ค่าพื้นฐาน 3.38 tok/s, 11.34 เมื่อใช้ Lookahead Expert Scheduling, 17.16 เมื่อเพิ่ม mixed precision, 20.51 เมื่อใช้ DSpark draft head ร่วมด้วย

• iPad Pro 11-inch M4, 16 GB — ค่าพื้นฐาน 2.97 tok/s, 9.81 ด้วย LES, 14.92 ด้วย mixed precision, 17.39 ด้วย DSpark

นั่นคือตัวเลขบนอุปกรณ์ที่เผยแพร่สูงสุดสำหรับโมเดลนี้ และจุดสูงสุดของบันไดคือ 20.51 tok/s ซึ่งเป็นหนึ่งในห้าของ 100 ช่องว่างนี้สำคัญเพราะมันเปลี่ยนว่าโมเดลนี้มีไว้เพื่ออะไร ที่ 13 tok/s แอปบนมือถือตอบคำถามเกี่ยวกับรูปภาพได้ในสองสามวินาที ที่ 100 tok/s คุณคงกำลังพิจารณามันเป็นตัวอ่านรอบแรกแบบสตรีมมิงสำหรับวิดีโอ อย่างแรกคือผลิตภัณฑ์จริง อย่างที่สองไม่ใช่สิ่งที่จัดส่งจริง และใครก็ตามที่ตั้งงบประมาณตามตัวเลขในทวีตจะผิดหวังไปห้าเท่า

การตีความคำกล่าวอ้าง 100 tok/s อย่างตรงไปตรงมาคือ มันเป็นการบีบอัดข้อเท็จจริงแยกกันสามข้อ — 3 GB, ทำงานบนเครื่อง, เร็วกว่ารุ่นก่อนหน้าอย่างมาก — ให้เป็นตัวเลขเดียวที่ไม่มีแหล่งข้อมูลใดมีอยู่จริง การปรับปรุงจากรุ่นสู่รุ่นเป็นเรื่องจริงและมีขนาดใหญ่: 3.38 ถึง 20.51 tok/s คือการขยับ 6 เท่าบนอุปกรณ์ระดับเดียวกัน ซึ่งทำได้ด้วยการซ้อนเทคนิคสามอย่าง ไม่ใช่ด้วยชิปที่ใหญ่ขึ้น

การเปิดตัวไม่ได้เกิดขึ้นเพียงวันเดียว และวันที่ก็สำคัญ

MiniCPM-V 4.7 เปิดตัวในลักษณะเดียวกับที่การเปิดตัวโมเดลเปิดน้ำหนักหลาย ๆ ตัวเป็นอยู่ในตอนนี้ นั่นคือ ไฟล์มาก่อน คำอธิบายตามมาทีหลัง และการรองรับในเฟรมเวิร์กนั้นอยู่ตรงกลางระหว่างสองสิ่งนั้น

• 6 ตุลาคม 17:40 UTC — {{1}}โมเดล 1B พร้อมตัวแปร AWQ, GPTQ และ int4{{/1}} ปรากฏบน Hugging Face พร้อมกับ{{2}}บิลด์ GGUF เมื่อเวลา 18:05{{/2}}

• 7 ตุลาคม 07:07 UTC — รีโพซิทอรี 35B-A3B เปิดตัวแล้ว ยังไม่มีโมเดลการ์ด

• 8 ตุลาคม — หัว speculative-decoding ของ DSpark สำหรับทั้งสองขนาด และบิลด์ FP8 ของ 35B

• 10 ตุลาคม 18:42 UTC — llama.cpp ผสานการรองรับโมเดล

• 12 ตุลาคม — OpenBMB คอมมิตการ์ดโมเดล ประกาศว่าใช้ Apache-2.0 และประกาศการเปิดตัวเป็นผลิตภัณฑ์ที่มีเอกสารประกอบ

• 15 ตุลาคม — หัว DSpark ถูกเชื่อมโยงจาก main card พร้อมดราฟต์ GGUF สำหรับทั้งสองเป้าหมาย

ลำดับเหตุการณ์นั้นอธิบายความสับสนจำนวนมากในรายงานข่าวรองได้เป็นอย่างดี ผู้ที่ได้รู้จักโมเดลผ่าน llama.cpp ในสัปดาห์ที่สองของเดือนตุลาคมกำลังรันรีลีสที่ยังไม่มีอยู่จริงอย่างเป็นทางการ โดยไม่มีแท็กไลเซนส์และไม่มีแผนภูมิ benchmark และตัวเลข throughput ของพวกเขาสะท้อนการเลือกควอนไทซ์ของเฟรมเวิร์กเอง มากกว่าสิ่งใดที่ OpenBMB ทดสอบ benchmark ไว้

การรองรับ llama.cpp: รวมแล้ว และยังไม่เสร็จสมบูรณ์นัก

pull request ต้นทางที่เพิ่ม MiniCPM-V 4.7 อ่านเข้าใจได้ชัดเจนผิดปกติเกี่ยวกับสิ่งที่เปลี่ยนแปลง และคำตอบคือ แทบไม่มีอะไรเปลี่ยนในเชิงสถาปัตยกรรม โมเดลนี้แทบเหมือนกับ MiniCPM-V 4.6 ทุกประการ ส่วนต่างคือ 3D RoPE ซึ่งเป็นตำแหน่งแบบสามค่าต่อโทเคน — เวลา แถว และคอลัมน์ — แทนที่จะเป็นสเกลาร์เดี่ยวที่โมเดลภาพ-ภาษาส่วนใหญ่ใช้ การรองรับต่อยอดจากเส้นทาง 4.6 ที่มีอยู่เดิมเพื่อรองรับมิติเพิ่มเติมนั้น PR ยังระบุว่าโมเดลนี้เป็น "กำลังจะเปิดตัว" เมื่อ PR ถูกเปิดในวันที่ 25 กันยายน ซึ่งเป็นเบาะแสที่สมเหตุสมผลว่าเวตเริ่มหมุนเวียนเร็วเพียงใด

ส่วนที่ตกค้างนี้ควรรู้ไว้ก่อนที่คุณจะสร้างฟีเจอร์ grounding บนมัน ตั้งแต่การ merge นั้น upstream llama.cpp กำหนดตำแหน่งให้ image marker tokens ผิดในพรอมป์ต์ของ MiniCPM-V 4.7: ตัว image tokens เองลงตำแหน่งถูกต้อง แต่ <slice>, </slice> และ marker ท้ายแถวถูกนับเลขเหมือนข้อความธรรมดา แทนที่จะได้รับพิกัดมุม tile อย่างที่ implementation อ้างอิง get_rope_index ทำ อาการที่เห็นได้คือพิกัดที่ส่งคืนจะต่ำกว่าความเป็นจริงอย่างเป็นระบบ เมื่อคุณถามว่าสิ่งใดอยู่ตรงไหนในภาพ มีการแก้ไขพร้อม unit test อยู่ใน pull request ที่เปิดอยู่ ลงวันที่ 14 ตุลาคม และ ณ วันที่ 20 ตุลาคม ก็ยังเปิดอยู่ ถ้างานของคุณคือ "describe this" คุณจะไม่สังเกตเห็น ถ้างานคือ "give me the bounding box" คุณจะเห็น และคุณควรรอการ merge หรือใช้ fork ที่มีเส้นทางที่แก้ไขแล้ว

ยังมีอีกหนึ่งอย่างที่ยังคงอยู่ผ่านการแปลงไปกลับ: สำหรับโมเดล 1B ตัวฉายภาพ (vision projector) เป็นส่วนที่ดาวน์โหลดมีขนาดใหญ่กว่า น้ำหนัก Q4_K_M มีขนาด 672 MB ส่วนตัวฉายภาพ f16 มีขนาด 1.11 GB ดังนั้นการติดตั้งใช้งาน 1B ที่เล็กที่สุดแต่ยังมีประโยชน์จึงมีไฟล์รวมประมาณ 1.8 GB ซึ่งส่วนใหญ่เป็น "ดวงตา" มากกว่าภาษา — รายละเอียดที่ความคาดหวังแบบ "1B หมายถึง 1 GB" มองข้ามไป

จะรันอะไร และรันบนอะไร

หากเป้าหมายคือการลองใช้ภายในสัปดาห์นี้ เส้นทางที่ติดขัดน้อยที่สุดคือใช้ llama.cpp หรือ Ollama กับคลัง GGUF โดยชี้ไคลเอนต์มัลติโมดัลไปที่ไฟล์ mmproj ที่ตรงกัน บน GPU 24 GB นั้น Q4_K_M ที่ 21.2 GB เหลือพื้นที่ว่างให้บริบทน้อยมาก — หน้าต่าง 8K โทเคนบวกกับภาพแบบไทล์จะไม่พอดีอย่างสบาย ดังนั้นควรวางแผนใช้ Q4_K_S หรือควอนไทซ์ที่เล็กกว่าหากต้องการพรอมป์แบบยาวด้วย บน Mac ที่มี RAM 32 GB ขึ้นไป Q8_0 ใช้ได้และเป็นสิ่งใกล้เคียงพฤติกรรมอ้างอิงที่สุด บนโทรศัพท์ มีเพียงแอปของผู้จำหน่ายเองและฟอร์ก llama.cpp-omni ที่มีงานด้านการจัดตารางผู้เชี่ยวชาญ; llama.cpp รุ่นมาตรฐานให้ความถูกต้อง แต่ไม่ได้ 20 tok/s

จุดที่เลเยอร์จัดเส้นทางพิสูจน์คุณค่าได้ในกรณีนี้คือฝั่งปลายทางที่เลยขีดความสามารถของการประมวลผลบนเครื่อง โมเดลที่เปิดใช้งาน 3B พารามิเตอร์บนโทรศัพท์ทำได้ดีเยี่ยมกับงานกรอบปกติ — อ่านใบเสร็จนี้ให้หน่อย ชั้นวางนี้ดูมีของเต็มไหม ป้ายนี้เขียนว่าอะไร — และบางครั้งก็จะเจอเอกสารที่ทำต่อไม่จบ OrcaRouter รวมโมเดลที่โฮสต์ไว้กว่า 200 โมเดลไว้หลังคีย์เดียว ส่งต่อราคาตามรายการของผู้ให้บริการแต่ละรายโดยไม่บวกเพิ่ม 0% ดังนั้นเมื่อผู้ให้บริการเปลี่ยนราคา การเปลี่ยนแปลงจึงมีผลทันทีในวันเดียวกัน และสลับไปใช้ระบบสำรองอัตโนมัติเมื่อต้นทางมีประสิทธิภาพลดลง รูปแบบที่ได้ผลคือ local-first พร้อมทางออกไปยังระบบโฮสต์ ไม่ใช่ local-only ชุดน้ำหนักเปิด (open-weight checkpoint) ยังคงเป็นของคุณในการโฮสต์ ส่วนเราเตอร์จัดการทุกอย่างที่โทรศัพท์ส่งต่อออกมา

MiniCPM-V 4.7 ไม่ได้ให้บริการโดย OrcaRouter และเราจะไม่สื่อเป็นนัยเป็นอย่างอื่น มันเป็นเช็กพอยต์ที่คุณรันเอง

อะไรจะช่วยกำหนดตัวเลขทั้งสามให้แน่ชัด

การวัดโดยอิสระของโมเดล 35B บนโทรศัพท์ที่ระบุรุ่นชัดเจน พร้อมระบุแอปและวิธีการควอนไทซ์ จะช่วยยุติคำถามเรื่องอัตราการประมวลผลได้ — รวมถึงว่า 20.51 tok/s จะยังผ่านการจับเวลาของคนอื่นได้หรือไม่ การประกาศนิยามของตัวเลข 3 GB — ไม่ว่าจะเป็น resident set, peak allocation หรืออย่างอื่น — จะช่วยยุติคำถามเรื่องหน่วยความจำได้ และตารางแยกตามเบนช์มาร์กที่มีคะแนนจริง แทนที่จะเป็นแผนภูมิห้าแผนภูมิแบบมีลิงก์ที่การ์ดปัจจุบันให้มา จะทำให้ตรวจสอบข้อกล่าวอ้างที่ว่า “ดีกว่า Qwen3.6 35B-A3B ในเวลาที่น้อยกว่า” เทียบกับน้ำหนักที่ OpenBMB เลือกได้ ยังไม่มีสิ่งใดในนั้นเลย จนกว่าจะมี ประโยคที่ถูกต้องคือประโยคที่น่าเบื่อ: โมเดล sparse ขนาด 35B ที่รันบนโทรศัพท์ได้ด้วยอัตราตามที่มีรายงานว่า 13+ โทเค็นต่อวินาที ในหน่วยความจำประมาณ 3 GB พร้อมดาวน์โหลด 21 GB และเส้นทางเฟรมเวิร์กแบบ merged ที่ยังมีบั๊กพิกัดที่ยังเปิดอยู่หนึ่งรายการ