22 בספטמבר 2026 האקדמיה ארכיון
מבזקים
שיאומי מדווחת על קיצור מחזור מו״פ מחודש ליומיים באמצעות מודל MiMo-V2.6-Pro GPT-6 אוטומט 20.8% מפרויקטי עבודה מרחוק, אבל זה עדיין קרוב לרצפה מרכזי נתונים בפנסילבניה: התנגדות תושבים עוצרת השקעות עתק שיאומי משיקה שלושה מודלים חדשים: דגל 1T פרמטרים וגרסה מואצת פי 10 OpenRouter משיק Batch API עם הנחה של 50% על רוב המודלים
מוצרים

גרסת Grok 4.7 קפצה ל-60 אחוז ב-Vals Index, אבל המחיר למשימה זינק כמעט פי שלושה

גרסת Grok 4.7 קפצה ל-60 אחוז ב-Vals Index, אבל המחיר למשימה זינק כמעט פי שלושה

העדכון האחרון של SDK שיחרר שיפור נאה בביצועים של Grok 4.7, מ-54 אחוז ליותר מ-60 אחוז במדד Vals Index, אלא שהקפיצה הזו מגיעה עם תג מחיר כבד: עלות כמעט משולשת לכל משימה. חוקר המודלים Lisan al Gaib הציף את הפער הזה ב-X וסימן אותו כ"עדיין חשוד", כשהוא מצביע על אנומליה בדפוס השימוש בטוקנים ששום אופטימיזציה רגילה לא מסבירה בקלות.

המספרים שמאחורי הקפיצה

Vals Index הוא בנצ'מרק שבודק יכולת של מודלים לבצע משימות קידוד והנדסה מול סביבות ריצה אמיתיות, לא רק שאלות ידע סטטיות. השיפור של שש נקודות אחוז נראה מרשים על הנייר, אבל כשמתרגמים אותו לעלות בפועל (פי שלושה יותר דולרים לכל משימה שהושלמה) היחס עלות-תועלת מתהפך. במונחים של פרודקשן, זה אומר שארגון שיריץ את הגרסה החדשה באותו נפח עבודה ישלש את חשבון ה-API שלו בלי לקבל תפוקה פרופורציונלית.

אנומליה במטמון: 90 אחוז מול 47 אחוז

הניתוח של Lisan al Gaib מתמקד במנגנון המטמון (caching) של טוקני קלט. בגרסה 4.6 ההנחה הסבירה היא שכ-90 אחוז מהטוקנים מגיעים מהמטמון, כלומר הבקשות חוזרות על אותו הקשר ומנצלות את הזיכרון ביעילות. בגרסה 4.7, כדי להסביר את הזינוק בעלות, צריך להניח שרק 47 אחוז מהטוקנים נמשכים מהמטמון. ירידה כזו חדה בשיעור ה-cache hit לא מוסברת בשינויי SDK סטנדרטיים, והיא מרמזת על שינוי מהותי באופן שבו המודל בונה את ההקשר או על באג במנגנון המטמון עצמו.

עונש אורך בתהליך RL

לדברי גורם המקורב לפיתוח, ייתכן שתהליך הלמידה בחיזוק (RL) העניש יותר מדי תשובות ארוכות, מה שגורם למודל לוותר על משימות קשות מוקדם מדי, גם כשהוא מסוגל לפתור אותן. זו תופעה מוכרת: כשפונקציית התגמול דוחפת לקיצור, המודל לומד "לברוח" ממסלולי חשיבה ארוכים שדווקא מובילים לפתרון נכון. התוצאה פרדוקסלית, הציון בבנצ'מרק עולה כי המשימות הקלות נפתרות מהר יותר, אבל המשימות הקשות נזנחות, והעלות הכוללת מטפסת כי המודל מייצר יותר סבבי ניסיון-וטעייה לפני שהוא מוותר.

התשובה של מאסק: xhigh ו-Grok Build

אילון מאסק הגיב ישירות לשרשור והציג את הפתרון שלו: הפעלת מצב "xhigh" בגרסה 4.7, לצד כלי בשם Grok Build. הניסוח, "Godspeed, you glorious bastard… Per aspera ad Astra", משאיר מעט מקום לספק לגבי הטון: זה לא תיקון הנדסי יבש אלא דחיפה אגרסיבית לקצה גבול היכולת, כנראה על חשבון יעילות חישובית. מצב xhigh ככל הנראה מגדיל את תקציב הטוקנים ומאפשר חיפוש עמוק יותר במרחב הפתרונות, מה שמסביר הן את שיפור הציון והן את הזינוק בעלות.

מה זה אומר למפתחים שבונים על Grok

בשורה התחתונה, גרסה 4.7 עם SDK מעודכן נותנת יותר נקודות בבנצ'מרק, אבל רק למי שמוכן לשלם את המחיר. מי שרץ בפרודקשן עם רגישות לעלות צריך לבדוק היטב את שיעור ה-cache hit אצלו לפני שמעדכן, ולשקול אם מצב xhigh רלוונטי ל-use case שלו או שהוא רק מנפח את החשבון. בינתיים, הפער בין 54 ל-60 אחוז ב-Vals Index נראה פחות כמו פריצת דרך ויותר כמו trade-off מכוון שמאסק מוכן לקחת.