ה־"3B פרמטרים פעילים" של MiniCPM-V 4.7 לא נמצא בכרטיס המודל — מדדתי אותו מתוך המשקלים

המספר החוזר ביותר בהקשר של MiniCPM-V 4.7 35B-A3B אינו מופיע בשום מקום בתיעוד שלו עצמו. הטענה — "רק 3B פרמטרים פעילים (!) — הוא פועל אפילו על iPhone" — מגיעה מפוסט של צד שלישי ב-13 באוקטובר 2026, וכרטיס הדגם של הספק, ה-README של המאגר והערות ההשקה שלו אינם מציינים כלל נתון של פרמטרים פעילים. זו אינה כל כך ביקורת על הטענה אלא פער שכדאי לסגור: ה-checkpoint מקודד את התשובה של עצמו. לכן, לפני כל דבר אחר כאן, שלפתי את אינדקס ה-safetensors ואת הכותרת של כל shard עבור openbmb/MiniCPM-V-4.7-35B-A3B וספרתי. לשם השוואה, הדגם האחר באותו פוסט — Qwen3.8-27B, שיצא ב-13 באוגוסט 2026 — הוא 27B צפוף ואין בו עמימות כזו לפתור: כל פרמטר פעיל בכל טוקן. השאלה המעניינת היא אם "3B פעילים" שורד מפגש עם המשקולות, והתשובה היא: הוא שורד, אבל רק אם מגדירים את המילה "פעיל" בדרך של הספק, והמספר הישר קרוב יותר ל-4B ברגע שסופרים את החלקים שאי אפשר להימנע מהרצתם.

ספר החשבונות, כפי שנקרא מנקודת הביקורת עצמה

קובץ האינדקס מפרט 40 שכבות שפה וכן מגדל ראייה ומקרן, 35,212,875,824 פרמטרים בסך הכול ב-BF16 — 70.43 GB של משקולות להורדה. זה תואם את "35B" בשם. השאלה של MoE היא מהו החלק מכך שנוגעים בו בכל טוקן:

• סך הכול מאוחסן — 35.21 מיליארד פרמטרים, 70.43 GB ב-BF16. כל מומחה נמצא בדיסק בין אם הוא בשימוש ובין אם לא.

• תקציב הניתוב — 8 מומחים נבחרים לכל טוקן, מתוך 256, בכל שכבת MoE. מוגדר ב-config.json בתור num_experts_per_tok: 8. כל מומחה קטן: 3.15M פרמטרים.

• נתיב MoE לכל שכבה — 8 מומחים (25.17M) + מומחה משותף (3.15M) + שער הניתוב (0.52M) ≈ 28.83M.

• מסלול קשב לכל שכבה — הארכיטקטורה היברידית: 30 מתוך 40 השכבות משתמשות בקשב לינארי (33.72M כל אחת), 10 משתמשות בקשב מלא (27.26M כל אחת). סך הכול ≈ 2.44B על פני כל 40 השכבות עבור קשב בתוספת אריתמטיקת MoE, החוזר לכל טוקן.

• בנוסף למה שאי אפשר לדלג עליו — הטבעות טוקנים 508.2M, ראש LM 508.2M, מגדל ראייה 522.3M, מקרן 30.7M.

• שתי התשובות שניתן להגן עליהן — ~2.44B פעילים במסלול ה-attention וה-MoE בלבד; ~4.01B אם סופרים גם אמבדינגים, ראש פלט, מגדל ראייה ומקרן, שאותם בקשת ראייה אכן מפעילה.

אז "3B active" אינו שגוי. זה עיגול של 2.44B כלפי מעלה, והוא נופל בפער שבין שני המספרים שלמעלה. הוא רק אינו נתון ש-OpenBMB פרסמה, והוא אינו אותו דבר כמו הסיומת "A3B" — הסיומת הזו היא חלק משם המודל, והחומרים של הספק עצמו לעולם אינם הופכים אותה למדידה.

למה הסיומת והמספר אינם אותו דבר?

מוסכמות שמות ברחבי האקוסיסטם של משקולות פתוחות מרמזות על ספירת פרמטרים פעילים: מודל בשם 30B-A3B, או 235B-A22B, אומר לך שהוא מפעיל בערך אותו מספר פרמטרים לכל טוקן. המשתמע מכך הוא בדרך כלל אמין — אבל זו מוסכמה, לא חוזה, ו-MiniCPM-V 4.7 הוא מקרה שבו שום דבר בכרטיס, ב-README או בפוסט ההשקה לא ממיר את "A3B" למספר שאפשר לתכנן סביבו זיכרון. עד שמישהו סופר, הסיומת היא תווית.

הספירה שלמעלה היא אריתמטיקה, לא הסקה מאותה תווית. זו גם הסיבה לכך שהמספרים ~2.44B ו~4.01B נבדלים: השאלה אם לספור את טבלת ההטמעות ואת ראש הפלט היא החלטה אמיתית, לא דקדקנות. במודל צפוף, ההטמעות הן פרוסה קטנה מתקציב של 27B. במודל דליל, שבו מסלול החישוב לכל טוקן הוא רק כמה מיליארדי פרמטרים, טבלת הטמעות של 508M וראש LM של 508M כבר אינם רעש — יחד הם מהווים כחמישית מהמסלול הפעיל, והם נשמרים ברוחב מלא בעוד המומחים מכומתים.

מסקנה אחת שראוי לומר בבירור: היחס בין פרמטרים מאוחסנים לפרמטרים פעילים כאן הוא בערך 8.8 ל־1 לפי הקריאה הצרה. זו כל הסיבה לכך שמודל 35B יכול להיות משווק כמודל טלפון, וזו גם הסיבה שהוא אינו כזה באותו אופן שמודל 3B צפוף הוא. האחסון אינו מתכווץ כאשר הראוטר מתעלם ממומחה.

הטענה לגבי iPhone היא טענה נפרדת עם בסיס ראיות נפרד

כל דבר קונקרטי לגבי הביצועים על המכשיר במהדורה הזו הוא דיווח של הספק ולא שוחזר. הנתון הספציפי הוא 13+ טוקנים לשנייה בכ-3 GB של זיכרון ב-iPhone 17 Pro Max, כאשר אותו צ'קפוינט הודגם ב-iPad M4. OpenBMB מייחסת זאת לשלוש טכניקות שפועלות יחד — Lookahead Expert Scheduling, שחוזה ניתוב חוצה שכבות וטוענת מומחים מראש, קוונטיזציה עדינה ברמת השכבה, ו-DSpark speculative sampling — ומתארת את התוצאה כמודל ה-MoE הפתוח-מקור הראשון שרץ בצורה חלקה על המכשיר בלי לאבד יכולות. אין מדידה בלתי תלויה של התפוקה הזו ברשומה הציבורית, אין שחזור על ידי צד שלישי, ואין פירוט מפורסם של איזו קוונטיזציה מניח נתון ה-3 GB.

זה חשוב מסיבה ספציפית: 3 GB הוא המספר שקובע אם הטענה מעניינת מבחינתך, והוא המספר שאנחנו יודעים עליו הכי פחות. MoE של 35B שרוב משקלי המומחים שלו יושבים באחסון פלאש אינו מודל של 3 GB — הוא מודל שקבוצת העבודה השוהה שלו במקרה נכנסת ל-3 GB ברגע שתחזיות ניתוב, prefetch ומטמון מומחים מכומת כולם עושים את עבודתם. אלו בדיוק התנאים שבהם תפוקת הבנצ'מרק ותפוקת העולם האמיתי מתפצלות — הפרומפט הראשון מחמם את המטמון, וההתנהגות שנותנת לך 13 טוקנים בשנייה בהדגמה היא לוח זמנים, לא תכונה של המשקלים.

התייחסו ל-13 טוקנים לשנייה כאל טענה על טכניקה, לא על הצ'קפוינט. הצ'קפוינט הוא מה שאפשר לאמת היום: 35.21B מאוחסנים, 8 מתוך 256 מומחים מנותבים לכל טוקן, ~2.44B עד ~4.01B פעילים בהתאם למה שסופרים, Apache-2.0, כימותי day-0 ב-GGUF, AWQ, GPTQ, int4 ו-FP8, ורשימת ספקים של שבבים נתמכים הכוללת את Rockchip, Houmo, Intel, AMD ו-Arm.

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

מספר הפרמטרים הפעילים הוא מדד חישובי עקיף. הוא אומר לך כמה כפל מטריצות מתבצע לכל טוקן, מה שמתורגם לכמה מהר רץ פענוח תלוי-GPU. הוא לא אומר לך כמה זיכרון אתה צריך כדי להחזיק את המודל, אשר נקבע לפי הסכום הכולל — 70.43 GB של משקולות BF16, או בערך רבע מכך ב-4-bit, לפני שאתה מביא בחשבון מטמון KV. במודל עם חלון הקשר של 256K, גם המטמון הזה אינו בגדר שגיאת עיגול.

• מהירות פענוח — נשלטת על ידי הפרמטרים הפעילים (~2.44B–4.01B כאן). זה מה שטענת 13 הטוקנים/שנייה מתייחסת אליו.

• זיכרון תושב — נשלט על ידי סך הפרמטרים (35.21B מאוחסנים), ואז נחתך באמצעות קוונטיזציה ובאמצעות כל קבוצת מומחים שתישאר תושבת.

• אחסון וטעינה — נקבעים לפי מלוא 70.43 GB ב-BF16. ניתוב דליל אינו מפחית את ההורדה.

• רוחב פס, לא FLOPS — בטלפון האילוץ המגביל הוא להעביר מומחים דרך אפיק זיכרון, וזו הסיבה שטכניקת התזמון קיימת, וזו הסיבה שספירת פעילים בלבד אינה מנבאת דבר לגבי השהיה בנייד.

המסקנה המעשית: אם יש לך GPU עם מספיק זיכרון להכיל את המשקלים המקוונטים, מספר הפרמטרים הפעילים הוא שקובע את התפוקה שלך, ו"3B active" הוא דבר טוב. אם אתה הסיבה לכך שהביטוי "רץ על iPhone" מופיע בפוסט, המספר הכולל הוא זה שקובע את ההיתכנות, ועבודת התזמון של היצרן היא החלק שהופך את המספר הכולל לנסבל. שתי הקריאות של אותה כותרת נכונות, והן לא אותה קריאה.

ההשוואה בפוסט ההוא צריכה שתי תוויות, לא אחת.

המסגור שהניע את הסבב הזה היה מקומי מול חומרה יקרה: MiniCPM-V 4.7 35B-A3B בתור המודל שמעניק לך את אותה יכולת בלי המערכת, מול Qwen3.8-27B בתור המודל שהיה חכם יותר אך נזקק למערכת. חצי היכולת של זה מגיע מכרטיס המודל של Qwen עצמו, והוא מדווח על ידי הספק כמו כל דבר אחר בעמוד הזה. המספרים המפורסמים של Qwen עבור Qwen3.8-27B כוללים 90.3 ב-LiveCodeBench v6, 89.2 ב-GPQA Diamond, 84.3 ב-OSWorld-Verified ו-79.0 ב-QwenSWEBench, והערך שלנו בקטלוג עבורו מציין אותם כתוצאות סוכניות וקידוד חזקות באופן יוצא דופן עבור מודל צפוף בנפח 27B. השאלה אם הוא היה "חכם יותר מ-Opus 4.6" היא טענה מהפוסט ברשת החברתית, ואין לפני הערכה בלתי תלויה שמכריעה זאת — לכן לא אנסח זאת מחדש כעובדה.

ההבדל המבני הוא זה שאפשר באמת לבדוק: Qwen3.8-27B הוא dense, כך שכל 27B הפרמטרים שלו פעילים, וטביעת הזיכרון שלו וחשבון החישוב שלו הם אותו מספר. MiniCPM-V 4.7 35B-A3B מפריד בין שני המספרים האלה בפער של בערך פי תשעה. זה כל הטיעון הארכיטקטוני, והוא אמיתי. הוא רק לא זהה להשוואת בנצ׳מרק, והפוסט שהפך אותו למפורסם ערבב בין השניים.

היכן נתב משנה את ההחלטה, והיכן שלא

שני דברים נכונים כאן וראויים להפרדה, מפני שהם מצביעים בכיוונים מנוגדים.

הראשון הוא שאנחנו לא מספקים את MiniCPM-V 4.7. הוא לא נמצא בקטלוג שלנו. אם אתה רוצה אותו, הדרך שלך היא חומרה משלך — וזה בדיוק מה שהמהדורה הזו מיועדת לו, עם משקלים, קוונטיזציות ומדריכי פריסה על המכשיר שמפורסמים לצידה. שום דבר ב-API מתארח לא עוזר לך להריץ מודל בטלפון, וזה יהיה מטעה לרמוז אחרת.

השנייה היא שהמודל שמולו נמדד זה לא נמצא באותה עמדה. Qwen3.8-27B זמין דרך ה-API שלנו, באירוח עצמי על התשתית שלנו, במחיר של $0.33 למיליון טוקנים בקלט ו-$2.40 למיליון טוקנים בפלט. אם השאלה שאתה בעצם שואל היא "האם להחליף את הקריאות המאוחסנות אצלנו ל-Qwen3.8-27B בפריסה מקומית של MiniCPM-V 4.7", התשובה הכנה היא שכדאי להריץ את הניסוי לפני שמתחייבים: נתון התפוקה על המכשיר אינו משוחזר, והשוואת היכולות היא מהכרטיס של הצד השני עצמו. זו הסיטואציה שלשמה קיים failover — לנתב חלק מהתעבורה לנתיב חדש, להשאיר את המוכח מאחוריו, ולתת לשבוע רע לעלות לך חלק מעומס עבודה במקום את כל עומס העבודה. מודל עם 0% תוספת מחיר גם שומר על חשבון ישר: כשספק משנה מחיר, המספר שאתה משלם זז באותו יום, כי אין שכבת רווח בין מחיר המחירון שלהם לחשבונית שלך.

מה שראוטר לא יכול לעשות הוא לגרום לשאלה של מקומי מול מתארח להיעלם. זו נקבעת לפי החומרה שלך, מגבלות הפרטיות שלך, והאם הורדה של 70 GB מקובלת — ומספר הפרמטרים הפעילים, בכל דרך שתעגלו אותו, לא משנה אף אחד מהשלושה.

מה יפתור את זה?

שלושה דברים, בסדר יורד של תועלת. נתון של פרמטרים פעילים שתפרסם OpenBMB, כך שהמספר שכולם חוזרים עליו יפסיק להיות אריתמטיקה של צד שלישי — כולל שלי, ושלי ניתן לשחזור מכותרות השארד אם אינך מסכים איתו. מדידה בלתי תלויה של 13 טוקנים לשנייה בטלפון, עם ציון הגדרות הקוונטיזציה, כי נתון תלוי-תזמון בלי ההגדרות שלו אינו מפרט. והערכה אמיתית שמשווה בין MiniCPM-V 4.7 35B-A3B לבין Qwen3.8-27B על אותן משימות, מכיוון שההשוואה שהפכה את המודל הזה לבולט היא כרגע תרשים של ספק אחד מול כרטיס של ספק אחר.

עד אז, הסיכום הבטוח צר יותר מהפוסט: המשקלים אמיתיים, הדלילות אמיתית, ההורדה היא 70.43 GB, ולכל טוקן המודל מבצע עבודה בשווי של בין 2.4 ל-4 מיליארד פרמטרים, תלוי איך סופרים את החלקים שאי אפשר לנתב סביבם. זו תוצאה הנדסית אמיתית. היא עדיין לא מדד ביצועים טלפוני מדוד, והיא אינה ניצחון במדד ביצועים על מודל צפוף של 27B.

מקורות: פרמטרים, מספרי מומחים, סוגי שכבות, אורך הקשר וגודל ההורדה נקראו ישירות מ-config.json ומכותרות המקטעים של safetensors של openbmb/MiniCPM-V-4.7-35B-A3B ב-13 באוקטובר 2026. מהירות במכשיר, נתון זיכרון, תוצאות בנצ'מרק ומספרי ההערכה של Qwen3.8-27B מקורם בדיווחי הספק ואינם משוחזרים. הטענות בדבר "3B פרמטרים פעילים" ו"חכם יותר מ-Opus 4.6" מקורן בפוסט ברשת חברתית של צד שלישי, ולא אצל מי מהספקים.

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