LFM3-Omni-2B לעומת MiniCPM-V 4.7 1B: כשהמודל הקטן יותר קורא טוב יותר

על הנייר זה לא קרב הוגן. LFM3-Omni-2B יש לו 2.17 מיליארד פרמטרים; MiniCPM-V 4.7 1B משווק כדגם 1B. הדגם הגדול יותר אמור לנצח במבחני הראייה. הוא לא. MiniCPM משיג 86.1 ב-OCRBench לעומת 80.6, 69.5 ב-MMStar לעומת 55.67, 56.9 ב-MMMU לעומת 42.44, ו-74.3 ב-MathVista לעומת 62.5. כל מבחן ראייה ששני הכרטיסים חולקים מעדיף את הדגם עם השם הקטן יותר, בדרך כלל בפער ניכר, ול-MiniCPM גם חלון הקשר גדול פי שמונה.Fusion עולה יותר לכל קריאה מאשר ניתוב לדגם יחיד. הוא מחויב לפי מחיר המחירון של הספק ללא תוספת.

שלושה דברים מסבירים זאת, ואף אחד מהם אינו פגם באף אחד מהמודלים. MiniCPM-V 4.7 1B הוא מומחה שהשקיע את כל תקציב הפרמטרים שלו בראייה. LFM3-Omni-2B הוא מודל כללי שהשקיע את תקציבו בראייה, בשמיעה ובדיבור. והמספר של MiniCPM שהכי חשוב — 86.1 ב-OCRBench — נמדד עם הגדרת 4× של אסימונים חזותיים, שמחליפה מחשוב תמורת פירוט באופן שמגבלה של 2,048 אסימונים לתמונה אינה יכולה. הבנת הוויתור הזה היא כל ההחלטה.

למה המודל הקטן קורא טוב יותר

MiniCPM-V 4.7 1B בנוי סביב רעיון אחד: לדחוס אסימונים חזותיים בשלב מוקדם, ולתת למשתמש לבחור עד כמה חזק לדחוס. המודל מיישם דחיסת אסימונים של פי 4 או פי 16 בתוך מקודד הראייה, לפני שמודל השפה רואה דבר. בדחיסת פי 16 הוא זול ומהיר, ומתאים לכיתוב ותיאור סצנות. בדחיסת פי 4 הוא שומר על פי ארבעה יותר אסימונים, וזה מה שנדרש ל-OCR של מסמכים ולקריאה של תרשימים צפופים. המספרים המובילים של OpenBMB מדווחים בהגדרת פי 4.

LFM3-Omni-2B נוקט בגישה ההפוכה. הוא מעבד תמונות ברזולוציה מקורית אך מגביל את התקציב החזותי ל-2,048 טוקנים לתמונה, ומגבלה זו משותפת עם מקודד אודיו, נתיב וידאו ומפענח דיבור בתוך רשת צפופה של 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, וספירת הפרמטרים הצפופה שלו היא בערך 1.3 עד 1.55 מיליארד, תלוי איך סופרים את מגדל הראייה. סרגל הצד של Hugging Face מעגל אותו ל־„2B params”, וכך מודל 1B נראה כמו מודל 2B בקטלוג. גודל הקובץ הוא המדריך האמין: כ־3.1 GB ב־BF16, לעומת 4.3 GB עבור LFM3-Omni-2B.

• פרמטרים — 2.17B צפוף עבור LFM3-Omni-2B לעומת כ-1.3B עד 1.55B צפוף עבור 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, בערך 5 GB של VRAM להגשה.

כל שורה משותפת לשני הכרטיסים

ההשוואה נקייה באופן חריג עבור טבלה חוצת־מעבדות, מפני ששני הספקים מדווחים על אותם ארבעה מערכי נתוני ראייה, ושניהם מודלים לא־הסקתיים שהוערכו במצב 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 — 42.44 לעומת 56.9. פער של 14.5 נקודות בהיסק רב-מודלי ברמת אוניברסיטה.

• MathVista mini — 62.50 לעומת 74.3. פער של 11.8 נקודות במתמטיקה חזותית.

ארבע שורות, ארבעה הפסדים, פערים שבין חמש לחמש־עשרה נקודות. אין אף שורה שבה מודל ה־omni מנצח, וזו תוצאה נקייה יותר מזו שהניבה השוואת LFM3 מול LFM2.5, וגם קשה יותר לתרץ אותה. הקריאה הניתנת להגנה ביותר היא שמומחה בנפח 1.4B עם חלון הקשר של 256K ותקציב טוקנים של 4× הוא פשוט קורא טוב יותר מגנרליסט בנפח 2.17B עם חלון הקשר של 32K ותקרת תמונה של 2,048 טוקנים. קיבולת שמושקעת במודאליות אחת עדיפה על קיבולת המחולקת בין ארבע, בקנה מידה הזה.

שתי הסתייגויות צריכות להיאמר יחד, משום שאף אחד משני הכרטיסים אינו מציין אותן מיוזמתו. ה-86.1 של MiniCPM נמדד בדחיסה של פי 4, ואותו מודל בהגדרת ברירת המחדל שלו של פי 16 היה מקבל ציון נמוך יותר ועולה פחות להרצה — הכרטיס אינו מפרסם את המספר הזה. וכרטיס המודל של OpenBMB אינו כולל כלל טבלת בנצ'מרקים; הנתונים מופיעים כפרוזה ותמונות גרף בעמוד המוצר, שזו צורת פרסום חלשה יותר מאשר טבלה עם הערת מתודולוגיה. שתי קבוצות המספרים הן טענות של הספק. כיוון הפער עקבי מספיק כדי שסביר שהוא ישרוד בדיקה עצמאית; הגודל המדויק כנראה שלא.

ההקשר הוא השורה שמכריעה עומסי עבודה אמיתיים

הקשר של 32K הוא נדיב עבור תמונה בודדת וצר עבור מסמך. בקצב של כ-2,048 טוקנים חזותיים לתמונה, LFM3-Omni-2B יכול להחזיק בחלון שלו כתריסר תמונות מלאות לפני שהיסטוריית השיחה מתחילה להתחרות על מקום. 262,144 הטוקנים של MiniCPM-V 4.7 1B אינם שיפור צנוע; זהו סוג אחר של עומס עבודה. מסמכי PDF ארוכים, טפסים רב-עמודיים, סיכומי וידאו בני שעה ולולאות סוכן ששומרות צילומי מסך בהקשר — כל אלה אפשריים ב-256K וכל אלה מוגבלים ב-32K.

זהו ההבדל שהכי פחות מדברים עליו והמשמעותי ביותר בין שני המודלים. טבלאות בנצ׳מרק מתגמלות דיוק בתמונה בודדת; צינורות עיבוד מסמכים בסביבת ייצור נכשלים בעמוד ה-14. אם תרחיש השימוש שלך כולל יותר מקומץ תמונות לשיחה, חלון ה-32K הוא מגבלה קשה יותר מכל אחד מארבעת פערי הבנצ׳מרק שלעיל.

מה ש-MiniCPM לא יכול לעשות

הוא אינו יכול לשמוע. אין מסלול קלט אודיו, אין פלט דיבור, ואין טיפול בפס הקול של וידאו. אם היישום הוא אדם שמדבר עם מכשיר על מה שהמצלמה רואה, MiniCPM-V 4.7 1B הוא רכיב אחד בצינור עיבוד שזקוק לפחות לשני מודלים נוספים — מערכת ASR ומערכת TTS — בתוספת הדבק שמעביר טקסט ביניהם.

LFM3-Omni-2B מקפל את אותו צינור עיבוד לנקודת ביקורת אחת של 4.3 GB. ציוני האודיו שלו אינם מרשימים לעומת מודלי דיבור ייעודיים — ASR באנגלית עם שיעור שגיאות מילים של 6.36, VoiceBench 64.73 — אבל הם קיימים באותו מעבר קדימה כמו נתיב הראייה, מה שאומר שהמודל יכול לענות על שאלה מדוברת על תמונה בלי שתמלול ייכתב אי פעם. עבור כלי שטח ללא ידיים או קיוסק, זה היתרון. עבור צינור עיבוד מסמכים, זה משקל מת בתקציב הפרמטרים.

ב-OrcaRouterמיזוג מודלים הוא הדרך האחרת לקבל את שתי ההתנהגויות: פאנל שבו מומחה למסמכים ומודל Omni עונים לאותו פרומפט, והתגובה מורכבת משניהם. זו יכולת מוצר ולא טענה על שני הצ'קפוינטים האלה — אף אחד מהם לא נמצא בקטלוג שלנו היום — אבל זו התשובה הארכיטקטונית להתמודדות שבה כל מודל טוב בבירור בחצי אחר של העבודה. מיזוג עולה יותר לכל קריאה מאשר ניתוב למודל אחד, והוא שווה את זה בדיוק כשתשובה שגויה עולה יותר מהטוקנים.

ההחלטה

אם העבודה היא קריאה — OCR, חשבוניות, טפסים, תרשימים, צילומי מסך, קובצי PDF ארוכים, ממשק משתמש צפוף — MiniCPM-V 4.7 1B הוא המודל הטוב יותר בכל מדד שפורסם, יש לו פי שמונה חלון הקשר, הוא Apache-2.0 במקום רישיון מותאם עם סף הכנסות, והוא קטן יותר בדיסק. זו לא החלטה גבולית, והעובדה שהוא נקרא מודל 1B לא אמורה להסתיר זאת.

אם העבודה היא שיחה עם מכשיר שיש לו מצלמה ומיקרופון, LFM3-Omni-2B הוא היחיד מבין השניים שיכול להשתתף. הוא קורא פחות טוב, מחזיק פחות הקשר, ומשוחרר בתנאים מחמירים יותר, ולכל זה אין חשיבות אם החלופה דורשת שלושה מודלים וצינור עיבוד.

יש מקרה שלישי שראוי לתת לו שם: מוצר שזקוק לשניהם, שבו נתיב המסמכים ונתיב הקול הם תכונות נפרדות. אז הארכיטקטורה הנכונה היא לא מודל אחד אלא שניים, שמנותבים לפי סוג הבקשה — הקורא עבור מסמכים, ומודל ה-Omni עבור קול — והשאלה היחידה היא אם ברצונך להריץ את שניהם או לתת לנקודת קצה אחת להחליט. זו השאלה שאליה מקבץ ההשוואות הזה ממשיך להגיע, והיא השאלה הנכונה. המודלים קרובים מספיק בטביעת הרגל שלהם כדי שהרצת שניהם תהיה אפשרות ממשית; הם רחוקים מספיק ביכולות שלהם כדי שהרצת רק אחד מהם תהיה פשרה, לא משנה איזה מהם תבחר.

מה שישנה את ההכרעה הוא הערכה בלתי תלויה של אחד משני המודלים, ובמיוחד כזו שבוחנת את MiniCPM בדחיסת ברירת המחדל שלו של 16× ולא בהגדרת 4× שעליה מבוססים נתוני הכותרת שלו. המספר הבודד הזה יכול לסגור את רוב הפער — או להרחיב אותו. עד שמישהו יפרסם אותו, טבלאות היצרן הן מה שיש לנו, והן מצביעות בכיוון אחד.