MiniCPM-V 4.7 1B על iPhone יומיומי: מה המשמעות האמיתית של "פועל מעבר ל-Pro Max"
- OrcaחדשOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 לכל 1M טוקנים · 12 tok/s
- deepseekחדשDeepSeek: DeepSeek V4.1 Flash 10172026-10-1745אינטליגנציה
- DeepSeekחדשDeepSeek: DeepSeek V4.1 Flash2026-10-1740אינטליגנציה
- OrcaחדשOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 לכל 1M טוקנים · 156 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952אינטליגנציה
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856אינטליגנציה
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 לכל 1M טוקנים · 1054 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238אינטליגנציה
- OpenAIOpenAI: GPT-6 Sol2026-09-2248אינטליגנציה
- AnthropicAnthropic: Claude Opus 5.52026-09-2258אינטליגנציה
- xAIGrok 4.72026-09-2146אינטליגנציה
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 לכל 1M טוקנים · 76 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 לכל 1M טוקנים · 964 tok/s
- OpenAIOpenAI: GPT-6 Astra2026-09-0453אינטליגנציה77כתיבת קוד
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241אינטליגנציה76כתיבת קוד
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245אינטליגנציה76כתיבת קוד
- AnthropicAnthropic: Claude Fable 5.12026-09-0153אינטליגנציה82כתיבת קוד
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 לכל 1M טוקנים · 47 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 לכל 1M טוקנים · 101 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642אינטליגנציה72כתיבת קוד
MiniCPM-V 4.7 1B הוא מודל חזותי-לשוני בעל 1.55 מיליארד פרמטרים ש-OpenBMB העלתה ל-Hugging Face ב-6 באוקטובר 2026 ותיארכה ל-12 באוקטובר בהערות ההפצה שלה. יש לו כרטיס מודל, אחד עשר אחים מכומתים, תג Ollama ואפליקציית הדגמה על-מכשיר. מה שאין לו הוא גרסה של הסיפור שמחזיקה מעמד כשמתמחרים את החומרה. הטענה שמסתובבת בחוגי מפתחים — שהמודל פועל כעת באפליקציית OnDeviceLLM על אייפונים רגילים, ולא רק על Pro Max עם 12GB — היא החלק שראוי לבחון מקרוב, כי "פועל על טלפון" ו"פועל על הטלפון שלך" מופרדים בכ-3 GB של מרווח זיכרון שאין לרוב האייפונים. כשלי ה-AI והתקריות של סוכנים המתועדים מאחורי שחרורים כמו זה נאספים בOrcaRouter AI Incident Archive שבו כל ערך נושא מקורות משלו, חומרה, דירוג מהימנות וסימון שנוי במחלוקת.
הנה תמונת המצב, כשהתפרים גלויים. כל מה שלהלן נקרא ישירות מקבצי המשקולות, מתיעוד של OpenBMB עצמה, או ממפרטים שפורסמו על ידי Apple. כאשר מספר מגיע מפוסט של מפתח ולא מארטיפקט שניתן לשחזור, המאמר מציין זאת.
מה שבאמת ידוע, ומה שרק נטען
המודל אמיתי וניתן להורדה. צ'קפוינט ה-BF16 מכיל 1,554,476,272 פרמטרים, שהם כ-3.1 GB בדיסק. המאגר כולל כרטיס מודל מלא — נדירות בהיסטוריה הקרובה של המשפחה הזו — שמציין עמוד שדרה טקסטואלי Qwen3.5, מגדל חזותי SigLIP2 עם 27 שכבות ברוחב חבוי של 1152, אריחי קלט בגודל 980 פיקסלים, חלון הקשר של 262,144 טוקנים ורישוי Apache 2.0. הרשומה ב-README של OpenBMB עצמה מתארכת את השחרור ל-2026-10-12; מאגר Hugging Face נוצר ב-2026-10-06. פער ששת הימים הוא הפיגור בין העלאה להכרזה שהמשפחה הזו ידועה בו, וזו הסיבה שכתבה מאוקטובר יכולה עדיין לכנות מאגר בן שישה ימים "השקה שקטה".
מה לא מבוסס על ידי שום ארטיפקט הוא הטענה הספציפית שה-1B פועל ב-OnDeviceLLM על "אייפונים יומיומיים מעבר ל-12GB Pro Max". פוסט של מפתח הוא המקור למסגור הזה. המאגר הציבורי של פרויקט OnDeviceLLM — שהוא ערכת התחלה לאפליקציות צ'אט ותרגום לא מקוונות, ולא מוצר App Store משווק — יש לו אפס כוכבים והדחיפה האחרונה אליו הייתה ב-27 ביולי 2026. הוא קודם למשקולות של MiniCPM-V 4.7 בעשרה שבועות, כך שכל תמיכה במודל הזה בו היא חדשה ולא מתועדת. התייחסו ל"כבר פועל ב-OnDeviceLLM" כדיווח של מי שעשה זאת, ולא כמסלול פריסה נתמך על ידי ספק.
ההבחנה הזו חשובה כי נתוני המכשיר של הספק עצמו כלל לא מתייחסים ל-1B.
המספר 3 GB שייך ל-35B, לא ל-1B
הטענה המרכזית של OpenBMB — „13+ טוקנים/שנייה עם זיכרון של 3 GB בלבד ב-iPhone 17 Pro Max” — מיוחסת ל-35B-A3B גרסת ה-Mixture-of-Experts, שרצה על ה-iPhone הגדול ביותר שאפל מוכרת. הטכניקה שמאחוריה, Lookahead Expert Scheduling, מחזיקה את רוב משקולות המומחים על SSD ומביאה מראש את אלה שהשכבה הבאה צפויה להזדקק להם. זהו הישג מרשים בהנדסת מערכות, וזה הסיבה לכך שהשם 35B ממשיך להופיע בסיקור הקשור לטלפונים.
ה-1B לא זקוק לשום דבר מזה. זהו מודל צפוף שנכנס לזיכרון לחלוטין. על הנייר זה הופך אותו לדמוקרטי יותר מבין השניים, וזו הסיבה שלזווית של "אייפון יומיומי" יש סיכוי. אבל האריתמטיקה פחות ידידותית ממה שהמסגור מרמז:
• משקלי BF16 — 3.1 GB בדיסק, ובערך אותו נפח בזיכרון לאחר הטעינה, לפני מטמון KV או אקטיבציות ראייה • Q8_0 GGUF — 1.08 GB של משקלים, בתוספת מקרן ראייה בנפח 0.90 GB בהגדרת דחיסה של פי 4, או 1.11 GB בפי 16 • Q4_K_M GGUF — 0.67 GB של משקלים, עם אותה תקורת מקרן • מקרן ראייה — זה החלק שאנשים שוכחים; הוא אינו מתכווץ עם קוונטיזציית מודל השפה, והוא נספר פעם אחת לכל מודל טעון • הקשר — עד 262,144 טוקנים על הנייר; כל טוקן במטמון KV הוא זיכרון נוסף שכרטיס המודל אינו מתקצב
בנייה ב-Q4 עם פרוג'קטור 16× מגיעה לכמעט 1.8 GB של משקולות. הוסיפו מטמון KV פעיל עבור כמה אלפי טוקנים של שיחה ומצייני מקום לתמונות, ואתם מבקשים מאפליקציה משהו בטווח של 2.2–2.8 GB. ב-Pro Max עם 12GB זה נוח. ב-iPhone עם 8GB, שבו מערכת ההפעלה וכל אפליקציה אחרת שנמצאת בזיכרון כבר מתחרות על אותו מאגר, אפליקציה שמבקשת 2.5 GB מבקשת חלק גדול ממה שנשאר. iOS תאשר לה זאת, או שהיא תבצע jetsam לאפליקציה תחת לחץ.
למה שורת ה-RAM באייפון היא המפרט האמיתי
אפל אינה מפרסמת את כמות ה-RAM של iPhone במפרטי השיווק שלה, ומעולם לא עודדה מפתחים להתייחס לטלפון כמחשב שזיכרון שלו ניתן להפנות אליו בכתובות. זהו האילוץ שאליו נתקלת הטענה "מעבר ל-12GB Pro Max". דגמי Pro Max נושאים כבר כמה דורות יותר זיכרון מהדגמים הסטנדרטיים, והפער בין "הטלפון בסרטון הביקורת" לבין "הטלפון בכיס של הקורא" הוא בדיוק הפער שעליו נשען סיפור העיבוד על המכשיר של הדגם הזה.
הגרסה הכנה של הטענה צרה יותר ועדיין מעניינת: מודל ראייה של מיליארד פרמטרים שפעם דרש מחשב נייד או טלפון דגל נכנס כעת בתקציב הזיכרון של טלפון בינוני, אם אתה משתמש בכימות של 4 סיביות ומסתפק בהקשר קצר יותר. זוהי ירידה אמיתית בדרגת החומרה. זה לא אותו דבר כמו "פועל על כל iPhone", וההבדל ראוי לציון מפורש כי הוא קובע אם קורא יכול לשחרר את הדבר.
כרטיס המודל לא מכריע את העניין. הוא מתעד תמיכה ב-iOS, Android ו-HarmonyOS, תמיכת שבבים מיום 0 מ-Rockchip, Houmo, Intel, AMD ו-Arm, ומקשר למאגר פריסה בקצה עם אפליקציות וקוד מקור. בשום מקום הוא אינו מפרט זיכרון התקן מינימלי, מטריצת התקנים שנבדקו, או קצב טוקנים לכל התקן עבור ה-1B. ההתקן היחיד שמצוין בנכסי ההדגמה של ה-1B עצמו הוא iPhone 17 Pro Max — אותו התקן שמופיע בכותרת ה-35B.
במה המודל באמת טוב, ב-1B
הסיבה שחישוב הזיכרון הזה שווה את המאמץ היא שמודל של מיליארד פרמטרים שמבצע הבנת מסמכים ומסכים בטלפון הוא קטגוריית מוצר שונה מזו של צ׳אטבוט. המשמעות היא שקבלה, טופס, תפריט, תווית או צילום מסך יכולים להפוך לטקסט מובנה בלי סבב ברשת — בלי העלאה, בלי עלות לכל תמונה, בלי רצפת השהיה שנקבעת על ידי מגדל סלולרי.
הנתונים שפרסמה OpenBMB עבור מודל ה-1B, כולם מדווחים על ידי הספק ואף אחד מהם לא שוחזר באופן עצמאי נכון למועד כתיבת הדברים, מעמידים את OCRBench על 86.1, את MathVista על 74.3, את CharXiv Reasoning על 48.8, את LongVideoBench על 53.4 ואת MotionBench על 54.55. ההשוואה המרכזית של הספק היא מול Qwen3.5 0.8B, שלטענתו הוא גובר עליו הן בציון הכולל והן ביעילות ההסקה, ומול MiniCPM-V 4.6, שלטענתו הוא מציג לעומתו שיפור בכל היכולות המרכזיות. אלה הם מבחני הבנצ'מרק של הספק עצמו, שהורצו על ידי הספק, וכרטיס המודל מציג אותם בתור תרשימים ולא כטבלה עם פרטי ה-harness.
שני פרטים ארכיטקטוניים חשובים יותר מהציונים לכל מי שמפרס את זה בפועל:
• דחיסת טוקנים חזותיים משולבת של 4×/16× — הקורא בוחר בכל בקשה אם תמונה הופכת לרצף טוקנים מפורט או לרצף חסכוני, כך שסריקת קבלה ותמונה ממוזערת יכולים להשתמש באותה פריסה • דחיסה מוקדמת בתוך ViT, שאולה מ-LLaVA-UHD v4 — הטוקנים החזותיים נחתכים בתוך מקודד הראייה ולא אחריו, וזה מה שהופך את מסלול ה-4× לחסכוני מלכתחילה • חיתוך — תמונות ברזולוציה גבוהה מפוצלות לאריחים בגודל 448×448 בתוספת סקירה ברזולוציה נמוכה, כאשר מספר החתיכות הוא פרמטר זמן ריצה (הכרטיס ממליץ על 36 לתמונות, 1 לווידאו) • דגימת וידאו — max_num_frames מוגדר כברירת מחדל ל-128, ו-stack_frames מרכיב תתי-פריימים לגריד, וכך טלפון מצליח לעבור הקלטת מסך בלי להחזיק כל פריים בזיכרון
עבור מקרה השימוש של קבלה שההנחיה מזכירה, הצינור הוא: לכידה, הקטנה למשהו קרוב ל-980 פיקסלים בצלע הארוך, הרצה ב-4× עם מספר פרוסות גבוה, ובקשה לפלט מובנה. מסלול ה-4× ב-36 פרוסות הוא ההגדרה היקרה; מסלול ה-16× הוא בערך רבע מהטוקנים וזה המקום שבו הטלפון נשאר מגיב. האם 16× מספיק כדי לקרוא קבלה תרמית היא שאלה שרק התמונות שלך יכולות לענות עליה, ואף מבחן בנצ'מרק שפורסם בכרטיס לא מדווח על דיוק OCR לפי מצב הקטנת רזולוציה.
הפער בין "דמו" ל"אפליקציה"
שלושה דברים עומדים בין דמו עובד לבין אפליקציית iOS שמוכנה להפצה, ואף אחד מהם אינו המשקלים של המודל.
הראשון הוא אריזה. המודל מסופק בפורמטים Transformers, GGUF, AWQ, GPTQ ו-int4. רק ל-GGUF יש מריץ בוגר על המכשיר ב-iOS — llama.cpp וקרוביו — ורק מאגר ה-GGUF נושא את קובץ מקרן הראייה הנפרד (mmproj) הדרוש למסלול הרב-מודלי. אם תתחילו מה-checkpoint של BF16 בציפייה לקובץ יחיד שמתחבר ישירות, תגלו שהמקרן הוא ארטיפקט שני עם גודל משלו.
השני הוא התקציב התרמי. מודל 1B שמייצר כמה מאות אסימונים הוא עומס התפרצות; מודל 1B שמבצע OCR לדף בן 36 פרוסות הוא עומס מתמשך. קובץ ה-GIF להדגמה של הספק הוא הקלטת מסך, לא מעקב תרמי. שום נתון שפורסם בכרטיס לא מספק אסימונים מתמשכים לשנייה בשום טלפון, וזה המספר שקובע אם אפליקציית סריקה מרגישה מיידית במסמך השלישי או במסמך השלושים.
השלישי הוא שאר הסטאק שלכם. הסקה על המכשיר מטפלת בתמונה. היא אינה מטפלת בחלק שבו אתם מתאימים את הקבלה שחולצה מול ספר חשבונות, מסלימים שורה דו-משמעית למודל גדול יותר, או עוברים לגיבוי כשהטלפון ישן מספיק כדי שהאפליקציה תסרב לטעון את המשקלים. זהו הגבול שבו ראוטר מצדיק את מקומו במקום להחליף משהו: OrcaRouter מציב יותר מ-200 מודלים מתארחים מאחורי נקודת קצה אחת תואמת OpenAI בתוספת מחיר של 0%, ומעביר ישירות את מחיר המחירון של כל ספק, עם מעבר אוטומטי לגיבוי ו-DSL לניתוב עבור תצורות ראשי-וגיבוי. מחלץ בצד הטלפון יכול להעביר את המקרים הלא-ודאיים שלו למודל ראייה מתארח, ואותו מפתח משמש לשני המסלולים. MiniCPM-V 4.7 1B עצמו אינו בקטלוג הזה — זהו צ'קפוינט שאתם מריצים בעצמכם — ולכן הראוטר הוא מסלול ההסלמה, ולא הדרך לקרוא למודל הזה.
תבנית השחרור השקט, ומדוע היא ממשיכה לייצר את הבלבול הזה
MiniCPM-V 4.7 הגיע ללא אירוע השקה. המאגר של 35B-A3B הופיע ב-6 באוקטובר 2026 ללא כרטיס מודל כלל — הכרטיס נחת שישה ימים לאחר מכן לצד הודעת השחרור המתוארכת. מודל ה-1B עקב אחר אותו דפוס: קודם המאגר, אחר כך התיעוד, וגילוי קהילתי לאורך כל הדרך. בחלל שבין לבין, הסיקור מתמלא מכל ארטיפקט שקיים, ולכן פרסומים מוקדמים תיארו מודל MoE של 35B ואז נאלצו להתעדכן כאשר ה-1B והכרטיס שלו הופיעו.
זו לא ביקורת על ההנדסה של OpenBMB. זה תיאור של האופן שבו מידע על המודל הזה מתפשט, וזו הסיבה שטענה כמו "פועל על מכשירי iPhone יומיומיים" יכולה לנוע מהר יותר מנתוני הזיכרון שמסייגים אותה. המאגר הוא המקור הראשוני. הכרטיס הוא המקור הראשוני. צילום מסך של מפתח של אפליקציה שעובדת בטלפון שלו הוא נקודת נתונים, לא מפרט.
מה לעשות עם זה, באופן קונקרטי
אם יש לך Pro Max או iPad. הורד את Q8_0 GGUF ואת המקרן 16×, הרץ אותו דרך llama.cpp או Ollama, ובדוק את המסמכים שלך בשתי הגדרות ה-downsample. תקבל מסלול OCR ו-image-QA מקומי עובד בתוך אחר צהריים, וה-1B קטן מספיק כדי להשאיר אותו טעון לצד אפליקציות אחרות.
אם יש לך iPhone רגיל. התחל עם Q4_K_M והמקרן 16×, הגבל את מספר הפרוסות למשהו צנוע, ומדוד. האריתמטיקה של הזיכרון אומרת שזה אמור להתאים; התנהגות החום וה-jetsam בשימוש ממושך היא החלק שאיש לא פרסם. בדוק על המכשיר הישן ביותר שאתה מתכוון לתמוך בו, לא על החדש ביותר.
אם אתם בונים מוצר. התייחסו למודל שעל המכשיר כמסלול המהיר ולמודל המתארח כמסלול הנכונות. ההסלמה היא החלטת ניתוב, ובנייתה מהיום הראשון זולה יותר מאשר להוסיף אותה בדיעבד אחרי כרטיס התמיכה הראשון על קבלה שהטלפון פירש לא נכון.
הטענה שאיתה נפתח המאמר הזה — שמודל מולטימודלי עם 1B פרמטרים רץ כעת על טלפונים מתחת לדרג Pro Max — סבירה מבחינת חשבון הזיכרון ואינה מוכחת על סמך התיעוד שפורסם. זהו מצב רגיל למודל כה צעיר, וזו סיבה לבחון במקום להמתין. המשקולות הן Apache 2.0, הקוונטיזציות קיימות, והדבר היחיד שעומד בינך לבין תשובה הוא אחר צהריים עם החומרה שלך.
שורה תחתונה: MiniCPM-V 4.7 1B הוא מודל ראייה אמיתי ומתועד ברישיון Apache-2.0 שנכנס בכ-1.8 GB ב-Q4 יחד עם מקרן הראייה שלו — קטן מספיק כדי שטלפונים בטווח הביניים יהיו יעד סביר ולא רק ה-Pro Max עם 12GB. היצרן לא פרסם מטריצת מכשירים או נתון זיכרון מינימלי, והטענה בדבר "אייפון יומיומי" מקורה בדוח מפתח ולא בכרטיס המודל. בדקו במכשיר שלכם לפני שאתם מתכננים על סמך זה.
