MiniCPM-V 4.7 מכניס מודל ראייה של 35B לנפח של 3 GB: פירוק הטענה בדבר 100 tok/s

מודל בעל 35 מיליארד פרמטרים לא יכול להיכנס לשלושה גיגה-בייט. MiniCPM-V 4.7 35B-A3B רץ בכ-שלושה גיגה-בייט בכל זאת, ושתי האמירות נכונות — וזה כל הטריק, והסיבה שהמספרים שמסתובבים סביב הגרסה הזו ראויים לעצירה. המודל הוא הראשון של OpenBMB מסוג sparse mixture-of-experts בקו MiniCPM-V: 35.2 מיליארד פרמטרים מאוחסנים, כ-3 מיליארד פעילים לכל טוקן, Apache-2.0, משקולות ב-Hugging Face. הוא קורא תמונות, ערכות מרובות-תמונות ווידאו, ועונה בטקסט. מאז 10 באוקטובר הוא גם רץ ב-llama.cpp במעלה הזרם, ושם רוב האנשים פגשו אותו. מה שלהלן מפריד בין שלושת המספרים שכולם חוזרים עליהם — 3 GB, 35B, ומספר 100 tok/s — ומראה אילו מהם OpenBMB אכן פרסמה. יותר מ-200 מודלים מתארחים, מפתח אחד, מחיר המחירון של הספק מועבר הלאה בתוספת של 0%. ראה מה OrcaRouter מנתב נקודת הבדיקה במשקולות פתוחות נשארת על החומרה שלך; פתח המילוט המתארח הוא נקודת קצה אחת. הכשלים המתועדים של בינה מלאכותית ותקריות הסוכנים שמאחורי מהדורות כמו זו נאספים ב-ארכיון תקריות ה-AI של OrcaRouter שבו כל ערך נושא את המקורות שלו, חומרה, דירוג מהימנות ודגל מחלוקת.

שלושה ג'יגה-בייט, שלושים וחמישה מיליארד פרמטרים, ואין סתירה

החשבון נראה בלתי אפשרי רק אם מניחים ש״בזיכרון״ פירושו ״הכול״. MiniCPM-V 4.7 35B-A3B משאיר בזיכרון כ-3 מיליארד פרמטרים ומזרים פנימה את שאר המומחים לפי בקשת הראוטר — הניסוח של כרטיס המודל עצמו הוא Lookahead Expert Scheduling, מנבא ניתוב חוצה-שכבות שמבצע prefetch למומחים שהשכבה הבאה צפויה להזדקק להם, תוך חפיפה בין הטעינה הזו לבין חישוב שכבר בעיצומו. הכרטיס מקפיד לציין שהחיזוי משמש רק להנעת prefetch ותזמון; הטוקנים עדיין הולכים לפי הניתוב האמיתי של המודל, ומומחה שהמנבא החמיץ נטען ומוערך כמו כל מומחה אחר.

להבחנה הזו יש השלכה מדידה. מאגר 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" הוא נתון זיכרון תושב (resident memory) בהזרמת מומחים בטלפון, לא גודל הורדה ולא דרישת 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 עם הוספת דיוק מעורב, 20.51 גם עם ראש הטיוטה DSpark.

• iPad Pro 11-inch M4, 16 GB — 2.97 tok/s במצב בסיס, 9.81 עם LES, 14.92 עם דיוק מעורב, 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 — מודל ה-1B וגרסאות ה-AWQ, GPTQ ו-int4 שלו מופיעים ב-Hugging Face, ובנוסף גרסאות ה-GGUF בשעה 18:05.

• 7 באוקטובר, 07:07 UTC — מאגר 35B-A3B מפורסם. עדיין אין כרטיס מודל.

• 8 באוקטובר — ראשי פענוח ספקולטיבי של DSpark עבור שני הגדלים, וגרסת FP8 של ה-35B.

• 10 באוקטובר, 18:42 UTC — llama.cpp ממזגת תמיכה במודל.

• 12 באוקטובר — OpenBMB מעלה את כרטיס המודל, מצהירה על Apache-2.0, ומכריזה על השחרור כמוצר מתועד.

• 15 באוקטובר — ראשי DSpark מקושרים מהכרטיס הראשי, עם טיוטות GGUF עבור שני היעדים.

סדר זה מסביר חלק ניכר מהבלבול בסיקור המשני. מי שהכיר את המודל דרך llama.cpp בשבוע השני של אוקטובר הריץ גרסה שרשמית עדיין לא הייתה קיימת, ללא תג רישיון וללא טבלת בנצ'מרקים, ונתוני התפוקה שלהם משקפים את בחירות הקוונטיזציה של המסגרת עצמה ולא משהו ש-OpenBMB בחנה.

תמיכה ב-llama.cpp: מוזגה, ועדיין לא ממש הושלמה

בקשת ה-pull request במעלה הזרם שהוסיפה את MiniCPM-V 4.7 בהירה באופן יוצא דופן לגבי מה שהשתנה, והתשובה היא: כמעט שום דבר מבחינה ארכיטקטונית. המודל כמעט זהה ל-MiniCPM-V 4.6; הדלתא היא 3D RoPE, מיקום בעל שלושה ערכים לכל טוקן — זמן, שורה, עמודה — במקום הסקלר היחיד שרוב מודלי חזון-שפה משתמשים בו. התמיכה מרחיבה את מסלול 4.6 הקיים לשאת את הממד הנוסף הזה. ה-PR גם ציין את המודל כ"upcoming" כשהוא נפתח ב-25 בספטמבר, וזה רמז הוגן לכמה מוקדם המשקלים היו בתפוצה.

כדאי להכיר את השאריות לפני שבונים עליהן תכונת grounding. מאז אותו merge, ‏llama.cpp במעלה הזרם מקצה לטוקנים של סמני התמונה מיקומים שגויים בפרומפטים של MiniCPM-V 4.7: טוקני התמונה עצמם ממוקמים נכון, אבל <slice>, </slice> וסמני סוף השורה ממוספרים כמו טקסט רגיל במקום לקבל את קואורדינטות פינת האריח שלהם כפי שמימוש הייחוס get_rope_index עושה. התסמין הגלוי הוא שהקואורדינטות המוחזרות יושבות באופן שיטתי נמוך מדי כששואלים היכן משהו נמצא בתמונה. תיקון עם בדיקת יחידה קיים כבקשת משיכה פתוחה, מתאריך 14 באוקטובר, ונכון ל-20 באוקטובר היא עדיין פתוחה. אם עומס העבודה שלך הוא "תאר את זה", לא תבחין בכך. אם הוא "תן לי את תיבת התיחום", כן תבחין, וכדאי שתמתין למיזוג או שתשתמש בפורק שנושא את המסלול המתוקן.

עוד דבר אחד שורד את הלוך ושוב: עבור מודל ה-1B, מקרן הראייה הוא ההורדה הגדולה יותר. משקלי 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 עם 32 GB או יותר, Q8_0 הוא אפשרי וזה הדבר הקרוב ביותר להתנהגות הייחוס. בטלפון, רק האפליקציות של היצרן עצמו והפורק llama.cpp-omni נושאים את עבודת תזמון המומחים; llama.cpp הסטנדרטי נותן לך נכונות, לא את ה-20 tok/s.

המקום שבו שכבת ניתוב מצדיקה את עצמה כאן הוא בצד הרחוק של הקריאה המקומית. מודל פעיל בגודל 3B בטלפון מצוין במסגרת השגרתית — קרא את הקבלה הזו, האם המדף הזה נראה מלא, מה כתוב בשלט הזה — ולעיתים הוא ייתקל בדף שאינו יכול לסיים. OrcaRouter מעמיד יותר מ-200 מודלים מתארחים מאחורי מפתח אחד, ומעביר את מחיר המחירון של כל ספק בתוספת של 0% כך ששינוי מחיר של ספק נכנס לתוקף באותו יום, ומעבר אוטומטי לגיבוי מתבצע כאשר שירות במעלה הזרם נחלש. התבנית שעובדת היא מקומית-קודם עם פתח מילוט למודל מתארח, לא מקומית בלבד. הצ'קפוינט במשקלים פתוחים נשאר שלך לאירוח; הנתב מטפל בכל מה שהטלפון מעביר הלאה.

MiniCPM-V 4.7 לא מוגש על ידי OrcaRouter, ואנחנו לא מתכוונים לרמוז אחרת. זהו צ'קפוינט שאתם מריצים.

מה יקבע את שלושת המספרים

מדידה בלתי תלויה של מודל 35B בטלפון בעל שם, עם ציון האפליקציה והקוונטיזציה, תכריע את שאלת התפוקה — כולל האם 20.51 tok/s שורד שעון עצר של מישהו אחר. הגדרה מפורסמת של נתון 3 GB — קבוצת זיכרון תושבת, הקצאת שיא או משהו אחר — תכריע את שאלת הזיכרון. וטבלה לכל מדד עם ציונים אמיתיים, במקום חמשת התרשימים המקושרים שהכרטיס מספק כיום, תאפשר לבדוק את הטענה „טוב יותר מ-Qwen3.6 35B-A3B בפחות זמן” מול שקלול המשקלים ש-OpenBMB בחר. אף אחד מאלה עדיין לא קיים. עד שהם יהיו קיימים, המשפט המדויק הוא המשעמם: מודל דליל (sparse) בגודל 35B שרץ על טלפון בקצב מדווח של 13 פלוס טוקרים לשנייה בכ-3 GB, עם הורדה של 21 GB ונתיב framework ממוזג שעדיין יש בו באג קואורדינטות פתוח אחד.