LFM3-Omni-2B กับ MiniCPM-V 4.7 1B: เมื่อโมเดลที่เล็กกว่าอ่านได้ดีกว่า

ในทางทฤษฎีแล้ว นี่ไม่ใช่การแข่งขันที่ยุติธรรม LFM3-Omni-2B มีพารามิเตอร์ 2.17 พันล้านตัว; MiniCPM-V 4.7 1B ถูกวางตลาดในฐานะโมเดล 1B โมเดลที่ใหญ่กว่าควรชนะ benchmark ด้านวิสัยทัศน์ แต่กลับไม่เป็นเช่นนั้น MiniCPM ทำคะแนนได้ 86.1 บน OCRBench เทียบกับ 80.6, 69.5 บน MMStar เทียบกับ 55.67, 56.9 บน MMMU เทียบกับ 42.44 และ 74.3 บน MathVista เทียบกับ 62.5 benchmark ด้านวิสัยทัศน์ทุกรายการที่การ์ดทั้งสองมีร่วมกันล้วนเอื้อต่อโมเดลที่มีชื่อเล็กกว่า และมักทิ้งห่างอย่างมาก อีกทั้ง MiniCPM ยังมีหน้าต่างบริบทใหญ่กว่าแปดเท่า Fusion มีค่าใช้จ่ายต่อการเรียกใช้สูงกว่าการกำหนดเส้นทางไปยังโมเดลเดียว โดยคิดในราคา ราคาตามรายการของผู้ให้บริการ โดยไม่มีการบวกเพิ่ม

มีสามเหตุผลที่อธิบายเรื่องนั้น และไม่มีเหตุผลใดเลยที่เป็นข้อบกพร่องของโมเดลทั้งสอง MiniCPM-V 4.7 1B เป็นโมเดลเฉพาะทางที่ใช้งบพารามิเตอร์ทั้งหมดไปกับการมองเห็น LFM3-Omni-2B เป็นโมเดลอเนกประสงค์ที่ใช้งบไปกับการมองเห็น การได้ยิน และการพูด และตัวเลข MiniCPM ที่สำคัญที่สุด — 86.1 บน OCRBench — วัดด้วยการตั้งค่า visual token 4× ซึ่งแลกการประมวลผลกับรายละเอียดในแบบที่เพดาน 2,048 โทเคนต่อภาพทำไม่ได้ การเข้าใจการแลกเปลี่ยนนั้นคือทั้งหมดของการตัดสินใจ

ทำไมโมเดลที่เล็กกว่าจึงอ่านได้ดีกว่า

MiniCPM-V 4.7 1B สร้างขึ้นจากแนวคิดเดียว: บีบอัดโทเค็นภาพตั้งแต่เนิ่น ๆ และให้ผู้ใช้เลือกว่าจะบีบอัดแรงแค่ไหน โมเดลใช้การบีบอัดโทเค็น 4× หรือ 16× ภายในตัวเข้ารหัสภาพ ก่อนที่โมเดลภาษา จะได้เห็นข้อมูลใด ๆ ที่ 16× จะประหยัดและรวดเร็ว เหมาะกับการสร้างคำบรรยายและคำอธิบายฉาก ที่ 4× จะเก็บโทเค็นไว้มากกว่าสี่เท่า ซึ่งเป็นสิ่งที่ OCR เอกสารและการอ่านแผนภูมิที่มีข้อมูลหนาแน่นต้องการ ตัวเลขพาดหัวของ OpenBMB รายงานที่การตั้งค่า 4×

LFM3-Omni-2B ใช้แนวทางตรงกันข้าม โดยประมวลผลภาพที่ความละเอียดดั้งเดิม แต่จำกัดงบภาพไว้ที่ 2,048 โทเคนต่อภาพ และเพดานนี้ใช้ร่วมกับตัวเข้ารหัสเสียง เส้นทางวิดีโอ และตัวถอดรหัสคำพูดภายในเครือข่ายแบบ dense ขนาด 2.17B เพดาน 2,048 โทเคนเป็นทางเลือกที่สมเหตุสมผลสำหรับแบบจำลองที่ต้องติดตั้งบนโทรศัพท์ไปพร้อมกับอีกสามมอดัลลิตี แต่มันเป็นเพดานแข็งว่าลายละเอียดของหน้าเอกสารจะส่งไปถึงแบบจำลองภาษาได้มากแค่ไหน และ DocVQA 92.47 บ่งชี้ว่าแบบจำลองรีดศักยภาพออกมาได้มาก — แต่ OCRBench 80.6 บอกว่าไม่พอที่จะเอาชนะโมเดลเฉพาะทางที่ใช้โทเคนได้มากกว่า 4 เท่าในหน้าเดียวกัน

ยังมีปัจจัยที่สองที่เงียบกว่า หน้าต่างบริบทของ MiniCPM คือ 262,144 โทเคน ของ LFM3-Omni-2B คือ 32,768 สำหรับภาพหน้าจอเพียงภาพเดียว ทั้งสองไม่มีความสำคัญ แต่สำหรับ PDF 40 หน้า วิดีโอยาว หรือบทสนทนาเกี่ยวกับเอกสารหลายรอบ ความแตกต่างนี้ไม่ใช่แค่แถวในผลเบนช์มาร์ก — แต่คือว่างานนั้นเป็นไปได้เลยหรือไม่

ข้อมูลจำเพาะ โดยไม่มีการปัดเศษแบบการตลาด

มีตัวเลขหนึ่งตัวที่ต้องแก้ไขก่อนการเปรียบเทียบใด ๆ MiniCPM-V 4.7 1B ถูกเรียกว่าเป็นโมเดล 1B และจำนวนพารามิเตอร์แบบ dense ของมันอยู่ที่ประมาณ 1.3 ถึง 1.55 พันล้าน ขึ้นอยู่กับว่าจะนับ vision tower อย่างไร แถบด้านข้างของ Hugging Face ปัดเป็น "2B params" ซึ่งเป็นสาเหตุที่โมเดล 1B กลายเป็นดูเหมือนโมเดล 2B ในแคตตาล็อก ขนาดไฟล์เป็นตัวชี้วัดที่ซื่อสัตย์: ประมาณ 3.1 GB ใน BF16 เทียบกับ 4.3 GB สำหรับ LFM3-Omni-2B

• พารามิเตอร์ — แบบ dense 2.17B สำหรับ LFM3-Omni-2B เทียบกับประมาณ 1.3B ถึง 1.55B แบบ dense สำหรับ MiniCPM-V 4.7 1B

• อินพุต — ข้อความ, รูปภาพ, วิดีโอพร้อมเสียง, เสียง 16 kHz เทียบกับข้อความ, รูปภาพ, หลายรูปภาพ และวิดีโอ

• เอาต์พุต — ข้อความและเสียงพูด 24 kHz เทียบกับข้อความเท่านั้น

• บริบท — 32,768 โทเค็น เทียบกับ 262,144 โทเค็น

• โทเค็นภาพ — จำกัดไว้ที่ 2,048 ต่อภาพ เทียบกับการบีบอัด 4× หรือ 16× ที่สลับได้ภายในเอนโคเดอร์

• สัญญาอนุญาต — LFM Open License v1.0 เทียบกับ Apache-2.0

• การเผยแพร่ — 27 ตุลาคม 2026 เทียบกับ 12 ตุลาคม 2026

• พื้นที่หน่วยความจำที่ใช้ — ประมาณ 4.3 GB BF16 เทียบกับประมาณ 3.1 GB BF16 ต้องใช้ VRAM ประมาณ 5 GB ในการให้บริการ

ทุกแถวที่การ์ดทั้งสองใบมีร่วมกัน

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

• OCRBench — 80.6 สำหรับ LFM3-Omni-2B (806 จาก 1,000) เทียบกับ 86.1 สำหรับ MiniCPM-V 4.7 1B ช่องว่าง 5.5 จุดในการรู้จำข้อความในเอกสาร

• MMStar — 55.67 เทียบกับ 69.5 ส่วนต่าง 13.8 จุด ซึ่งมากที่สุดในชุดนี้

• MMMU validation — 42.44 เทียบกับ 56.9 ช่องว่าง 14.5 จุดในการให้เหตุผลแบบมัลติโมดัลระดับมหาวิทยาลัย

• MathVista mini — 62.50 เทียบกับ 74.3 ช่องว่าง 11.8 จุดในคณิตศาสตร์เชิงภาพ

สี่แถว แพ้สี่ครั้ง ช่องว่างระหว่าง 5 ถึง 15 คะแนน ไม่มีแถวใดที่โมเดลออมนิชนะ ซึ่งเป็นผลลัพธ์ที่สะอาดกว่าผลจากการเปรียบเทียบ LFM3 กับ LFM2.5 และเป็นผลที่อธิบายกลบเกลื่อนได้ยากกว่า การตีความที่ป้องกันได้มากที่สุดคือ โมเดลเฉพาะทางขนาด 1.4B ที่มีบริบท 256K และงบโทเคน 4× ย่อมเป็นผู้อ่านที่ดีกว่าโมเดลอเนกประสงค์ขนาด 2.17B ที่มีบริบท 32K และเพดานภาพ 2,048 โทเคน ในสเกลนี้ ความจุที่ทุ่มให้กับโมดัลิตี้เดียวชนะความจุที่แบ่งไปยังสี่โมดัลิตี้

ข้อควรระวังสองข้อนี้ควรกล่าวถึงพร้อมกัน เพราะการ์ดทั้งสองใบไม่ได้เปิดเผยข้อมูลเหล่านี้เอง ค่า 86.1 ของ MiniCPM วัดที่การบีบอัด 4× และโมเดลเดียวกันที่ค่าตั้งต้น 16× จะได้คะแนนต่ำลงและรันได้ถูกกว่า — การ์ดไม่ได้เผยแพร่ตัวเลขนั้น และการ์ดโมเดลของ OpenBMB ไม่มีตาราง benchmark เลย ตัวเลขปรากฏเป็นข้อความร้อยแก้วและภาพกราฟบนหน้าสินค้า ซึ่งเป็นการเผยแพร่ที่อ่อนกว่าตารางที่มีบันทึกระเบียบวิธี ตัวเลขทั้งสองชุดเป็นคำกล่าวอ้างของผู้ขาย ทิศทางของช่องว่างสอดคล้องกันมากพอจนน่าจะผ่านการทดสอบอิสระได้ แต่ขนาดที่แน่นอนนั้นน่าจะไม่

Context คือแถวที่ตัดสินเวิร์กโหลดจริง

บริบท 32K ถือว่าเหลือเฟือสำหรับภาพเดียว แต่คับแคบสำหรับเอกสาร ด้วยจำนวนโทเค็นภาพประมาณ 2,048 โทเค็นต่อภาพ LFM3-Omni-2B จึงเก็บภาพเต็มได้ประมาณสิบสองภาพในหน้าต่าง ก่อนที่ประวัติการสนทนาจะเริ่มแย่งพื้นที่ 262,144 โทเค็นของ MiniCPM-V 4.7 1B ไม่ใช่การปรับปรุงเพียงเล็กน้อย แต่เป็นงานคนละระดับ ทั้ง PDF ยาว แบบฟอร์มหลายหน้า สรุปวิดีโอความยาวหนึ่งชั่วโมง และลูปเอเจนต์ที่เก็บภาพหน้าจอไว้ในบริบท ล้วนทำได้ที่ 256K และล้วนถูกจำกัดที่ 32K

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

สิ่งที่ MiniCPM ไม่สามารถทำได้

มันไม่ได้ยิน ไม่มีเส้นทางการรับเสียงเข้า ไม่มีเอาต์พุตเสียงพูด และไม่มีการจัดการแทร็กเสียงของวิดีโอ ถ้าแอปพลิเคชันคือคนที่กำลังพูดคุยกับอุปกรณ์เกี่ยวกับสิ่งที่กล้องมองเห็น MiniCPM-V 4.7 1B ก็เป็นเพียงองค์ประกอบหนึ่งของไปป์ไลน์ที่ต้องใช้โมเดลเพิ่มอีกอย่างน้อยสองตัว — ระบบ ASR และระบบ TTS — พร้อมกับตัวเชื่อมเพื่อส่งข้อความระหว่างกัน

LFM3-Omni-2B ยุบรวมไปป์ไลน์นั้นให้เหลือเช็กพอยต์เดียวขนาด 4.3 GB คะแนนด้านเสียงของมันไม่โดดเด่นเมื่อเทียบกับโมเดลเสียงพูดโดยเฉพาะ — English ASR อัตราคำผิด 6.36, VoiceBench 64.73 — แต่คะแนนเหล่านี้เกิดขึ้นภายใน forward pass เดียวกันกับเส้นทางภาพ ซึ่งหมายความว่าโมเดลสามารถตอบคำถามที่พูดเกี่ยวกับภาพได้โดยไม่ต้องมีการเขียนถอดความเลย สำหรับเครื่องมือภาคสนามแบบใช้มือเปล่าหรือคีออสก์ นั่นคือฟีเจอร์ที่ต้องการ สำหรับไปป์ไลน์เอกสาร มันเป็นน้ำหนักส่วนเกินในงบพารามิเตอร์

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

การตัดสินใจ

ถ้างานคือการอ่าน — OCR, ใบแจ้งหนี้, แบบฟอร์ม, แผนภูมิ, ภาพหน้าจอ, PDF ยาว ๆ, UI ที่แน่นขนัด — MiniCPM-V 4.7 1B เป็นโมเดลที่ดีกว่าตามตัวชี้วัดที่เผยแพร่ทุกตัว มีบริบทมากกว่าแปดเท่า ใช้ Apache-2.0 แทนสัญญาอนุญาตแบบกำหนดเองที่มีเกณฑ์รายได้ และมีขนาดบนดิสก์เล็กกว่า นี่ไม่ใช่การตัดสินใจที่สูสี และข้อเท็จจริงที่ว่ามันถูกเรียกว่าโมเดล 1B ก็ไม่ควรทำให้มองข้ามเรื่องนี้

หากงานคือการสนทนากับอุปกรณ์ที่มีกล้องและไมโครโฟน LFM3-Omni-2B คือรุ่นเดียวในสองรุ่นที่เข้าร่วมได้ มันอ่านได้ไม่ดีเท่า มีบริบทน้อยกว่า และเปิดตัวภายใต้เงื่อนไขที่เข้มงวดกว่า แต่ทั้งหมดนั้นไม่สำคัญเลยหากทางเลือกต้องใช้ถึงสามโมเดลและไปป์ไลน์

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

สิ่งที่จะเปลี่ยนคำตัดสินได้คือการประเมินอย่างเป็นอิสระต่อโมเดลใดโมเดลหนึ่ง และที่สำคัญคือการประเมินที่ทดสอบ MiniCPM ที่ระดับการบีบอัด 16× อันเป็นค่าเริ่มต้น แทนที่จะเป็นค่า 4× ซึ่งเป็นค่าที่ตัวเลขพาดหัวของมันใช้ ตัวเลขเพียงตัวเดียวนั้นอาจปิดช่องว่างส่วนใหญ่ได้ — หรือทำให้ช่องว่างกว้างขึ้นก็ได้ จนกว่าจะมีใครสักคนเผยแพร่ผลออกมา ตารางของผู้จำหน่ายคือสิ่งที่เรามีอยู่ และมันชี้ไปในทิศทางเดียว