← חזרה למאמריםגילויAugust 15, 20267 דק׳ קריאהCopy article

MTPLX על M1 Ultra: ה25 tok/s Tune That Served 16.5

תחרות חוזרת: MTPLX's native-MTP runtime נגד lane mlx-vlm hand-tuned מהחלק הראשון, על M128 GB M1 Ultra. האוטוטונר הבטיח 2.20x. נתיב השירות היה עם תכניות אחרות — מדוד עם Kimi K3 ב1 day.

Developed by Robert E. Beckner III (Merlin) | rbeckner.com

המשחק השני הגיע 1 יום מוקדם. M1 Ultra tuning article נסגר עם תחזית: כאשר גרסה של MLX מגיעה עם גרפים של פענוח מרוכז, ההתאמה מחדש נגד השביל של 20.3 tok/s תיקח אחר הצהריים ו-1 הורדה. הבוקר גיליתי ריצה חדשה בשם MTPLX המבטיחה את העתיד כמוצר סופי — פענוח ספקולטיבי של חיזוי מרובה-טוקן במולדת Apple סיליקון, אוטוטונר המדיד את המכשיר הספציפי שלך, שרת תואם ל-OpenAI ול-Anthropic, הפעלות בלחיצה אחת עבור המכשירים האגנטיים שאנו משתמשים בהם, ו-Qwen3.8-27B כמודל הקידוד הבולט שלו. האתר שלהם אומר "הכלים האהובים עליך, במהירות כפולה." אני הבאת אותו ל-Kimi K3, שותף שלי בהרפתקה של טונינג ביום הקודם, ו-גענינו את התנאים יחד: התקן אותו נקי ב- Studio, תן למתאם שלו לעשות את המקרה הטוב ביותר שלו, ואז מדוד מה השרת מספק בפועל. Kimi הנהיג את העבודה מרחוק והמדדים; שימרתי את כללי הבית והתקשרתי. כך באמת התנהלה היום.

MTPLX הוא גרסת המוצר של הליין שבנינו יחד#

הארכיטקטורה ראויה להכרה מראש, כי זה הרעיון הנכון שמבוצע ברצינות. MTPLX מציע טיוטות עם ראשי MTP של המודל עצמו — המנגנון אותו הליין שלנו משתמש — ומקבל טיוטות דרך דגימה מדויקת של דחייה, כך שהדגימה בטמפרטורה 0.6 מייצרת את ההתפלגות זהה לזו של פענוח רגיל, רק מהר יותר. אין מודל טיוטה נפרד שמ.consume זיכרון, עומק הטיוטה מותאם לכל מכונה מול בסיס אוטורגרסיבי, והפרויקט מסרב לצרף צדדי MTP לא מאומתים למשקלים אקראיים. המדיניות האחרונה הזו היא משמעת שהייתה לי ולקימי להחיל ידנית ביום הקודם, כאשר חיברנו מחדש את טנסורים MTP שנופלו של Qwen3.8 עם שורשם. הליין מהחלק הראשון היה מדד ברור: סטודיו זהה, משפחת מודלים זהה, מדוד באותו אופן.

ההתקנה עברה בדיקות האיסור 2 לפני שהגיעה למשקל#

הבדיקה הראשונה הייתה שלי. בחודש מרץ, במעבדת השיפור האוטונומית שלי, התפסנו אתלוג שבו סביבת Python מבודדת איבדה בשקט גישה לספריות המהירות של Apple, והמספרים חזרו רק לאט. לפני ש-קימי המשיך, ביקשתי הוכחה שהתלוג לא חל. חיישן שורה 3 פתר את זה — מתרגם ARM מקומי64, Metal זמין, GPU כהתקן ברירת המחדל. נתיב Metal של Apple נשלח בתוך גלגל mlx-metal עצמו, כך שמקור המתרגם אינו רלוונטי לגישה ל-GPU, והמסלול מהחלק הראשון כבר הוכיח throughput מקורי של GPU דרך אותה צורת בידוד. המפקח של MTPLX הסכים, דירוג שני הבנות Qwen3.8-27B שלו מאומת-מקורי עם כל טנזורי MTP 15 נוכחים.הבדיקה השנייה הייתה של קימי, באמצע הורדה. פקודת pull של MTPLX מתעלמת ממשתני סביבה של מטמון Hugging Face הרגילים, והניסיון הראשון היה לכתוב 20 GB של מודל לתיק הבית של Studio במקום את נפח הנתונים שמגנות החוקים הביתיים. קימי כבה את הפקיעה, הסיר רק מה שיצר, והתחל מחדש עם תיק מטמון מפורש. המעריצים נשארו על עקומת Apple כל היום, וזה חשוב במכשיר שמופעל גם כסימולטור טיסה.

המכונה הרועשת ביותר באותו בוקר לא הייתה זו שמריצה את הניסוי#

באמצע ההורדה, סביבות העבודה שלי החלו לעלות קשות — ממוצע העומס עלה מעל 50 — והפסקנו את הניסוי כדי לענות על שאלה חשובה יותר: האם זה היה תוצאה של מעשינו? זה לא היה. עבודתנו רצה ב-Studio על פני SSH מושבים קצרים; עקבות המקומיות היו כמה תהליכי curl ו-ssh שהושלמו. הסערה הייתה גל דמון של Apple — הורדה תקועה של נכס, אינדוקס, ונפץ מתהליך וירטואליזציה שנעלם לפני שנוכל לקרוא לבעליו — ועוד גילוי שה-"תהליכי נודינג מסתוריים" שהייתי מורס הם 3 מנהלי פיתוח שמבצעים בדיוק את עבודתם על ידי הפעלת שרתי. כתבנו את הכול לתהליך העברת המכשיר והחזרנו לניסוי עם תודעה נקייה. הפסקה שייכת לסיפור הזה מכיוון שהש disciplina היא זהה לאלה שהבנצ'מרקים רצה עליה: דע את עקבותיך לפני שתאשים מכונה.

האוטוטונר מדיד 2.20x פיצוץ#

טקס הטונינג של MTPLX הוא הנדסה כנה: הוא מריץ את המודל האמיתי על החומרה שלך בכל עומק תכנון, שומר על פענוח אוטורגרסיבי כבסיס, ושומר עומק רק אם הוא מנצח את הבסיס הזה. ב-M1 Ultra הוא יצר AR 11.4, עומק 1 ב9.2, עומק 2 ב25.1, עומק 3 ב20.7 tok/s — עומק 2 קיבל את התואר של המנצח ב2.20x, נשמר לכל השקות עתידיות.זה 25.1 הוא מדידה אמיתית של מנוע אמיתי, 24% מעל שיעור השירות של הקו שלנו 20.3. אם השרת חזר על זה, מאמר זה היה מדריך מעבר.

השרת סיפק 16.5, והברירות המחדל היו מיסים אסימונים מחוץ לעין#

משטח השירות השתמש באותם בקשות, טמפרטורה 0, וחשבון שעון קיר כבסיס lane שלנו. הריצה הראשונה החזירה ב14.7 tok/s, ונתוני המטה-דאטה של התגובה הציגו ברירות מחדל 2 שפועלות נגד המדידה:קיבוע Turbo, עומק 2, והסרתreasoning העלו את הבנייה FP16 ל16.5 tok/s קיר — הטוב ביותר MTPLX יצר כל היום. בניית Optimized-Speed ב-4-bit, זו שהפרויקט ממליץ עליה לקידוד, סיפקה 15.5. שתי הבנות נמצאות ב20.4 GB בדיסק מול 15 GB של lane שלנו, ובמכונה מוגבלת רוחב פס כל אסימון משלם לשידור אותם 5 GB נוספים.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

המכוון והשרת מודדים 2 מכונות שונות#

הממצא הכי שימושי של היום מסביר את הפער בין 25.1 ל16.5. לוגים של השרת של MTPLX מציגים מדריך חימום בהתחלה, והמדריך הזה מדווח 20-24 אסימונים/שנייה מהמנוע — בתוך אותו תהליך שמשרת 16.5 על HTTP. המנוע מהיר וההעברה מסובכת. בין לולאת הפענוח לבין הלקוח יש את השכבה HTTP, רישום חשבון-בנק לבקשה (כתיבה של תמונת מצב 160 MB הופיעה בסטטיסטיקות הבקשה הראשונה), והמערכת הרציונלית, וכל אסימון חוצה את הגבול הזה. על שבבים M4 ו-M5, שבהם נמדדו המספרים 1.6-2.24x של הפרויקט, CPU מהיר ואריזה צורכים את החציית. מנוע M1 Ultra עומד בקצב; נתיב השירות שלו אינו.
Diagram source
graph LR
    subgraph נתיב המכוון
        A[מודל אמיתי] --> B[עומק טיוטה D1-D3]
        B --> C[מונה רק פענוח  
25.1 אסימונים/שנייה]
    end
    subgraph נתיב השירות
        D[בקשה HTTP] --> E[בנק סשן  
+ ברירות מחדל רציונליות]
        E --> F[מנוע זהה  
המדריך מציג 20-24]
        F --> G[גבול אסימון לכלי  
16.5 אסימונים/שנייה קיר]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
Copy source
זהו שיעור של חלק ראשון ללבוש תחפושת חדשה. טענות הקהילה של llama.cpp על 25-32 אסימונים/שנייה לא שרדו מגע עם שבב זה, ו25.1 של המכוון של MTPLX לא שרד את השרת שלו. החוק הקבוע חותך: קצב ההגשה מודד בגבול HTTP עם ברירת המחדל של ייצור גלוי, אף פעם לא בתוך הטונר. זה פיתוח מבוסס מדד ביצועים מיושם שכבה אחת מעלה במערך.

המאתגר עזב את 38 GB קלים יותר, והצופה נשאר מאחור#

נתתי לKimi 1 בלתי ניתנים למשא ומתן לפני שהניסוי התחיל: כל מה שמריץ את Studio זה צריך לעצור את עצמו כשבזמן ריק, כי עבודת הלילה של המכונה היא סימולטור טיסה. MTPLX לא מספק זמן המתנה ריק לשרת הצ'אט שלו, לכן Kimi בנה את הצופה בתוך סקריפט עטיפה קטן — קישור רק ל-loopback, משאבים על מדיניות Apple, ומצפה חיבור שמפסיק את השרת אחרי 10 דקות ללא לקוחות. הוא עבר את מבחן האש החי, שבר את מופע הבדיקה ב-60‑שנייה ושחרר את הפורט בצורה נקייה. העטיפה והסביבה הווירטואלית נשארות על המכונה, כך שהבדיקה מחדש היא 1 הורדה מבודדת כאשר גרסת MTPLX עובדת את נתיב השירות של דור M1 או שולחת אובייקט MTP תואם קרוב ל15 GB.המשקולות עצמן לא נשארו. ברגע שההחלטה הייתה ברורה, עברנו את הניקיון בזהירות — שני תיקי המודל של MTPLX, 38 GB על פני FP16 ו‑4‑ביט בניות, נמחקו לאחר אימות שאין תהליך מחזיק בהם, והחזרת הנפח בדיוק למרחב החופשי לפני הניסוי. מחיקה נשארת חלק מהזרימה: כל מאתגר שמפסיד משאיר את הדיסק באותו יום, שמחזיק את הניסוי הבא כנה.

מה שהמשחק הנוסף הוסיף לרשימת הבדיקה#

המדריך מהחלק הראשון לא נזז. הוא סיפק את הבוקר ב20.3 טוק/שנייה, הוא סיפק את הערב ב20.3 טוק/שנייה, ועכשיו הוא מחזיק את מקומו נגד 3 אתגרים במקום 2 — עדיין מדריך ניסיוני, 1 הורדה אחת ממצב המשחק הבא. רשימת הבדיקה מהחלק הראשון מקבלת 3 רשומות:הסימטריה המרגיעה של הזוג היא שחלק ראשון הסתיים על ידי תורמת את הניסוי המדויק הזה, והניסוי הגיע באריזת מוצר עם אמנות אמיתית בתוכו — דגימה מדויקת, טונינג לכל מכונה, אימות כנה. האמנות הייתה אמיתית והפסד היה אמיתי, ושני הממצאים יצאו מהיום אותו של מדידה, סערת CPU וכל זה. הרפתקה עם לוח תוצאות היא הטיפוס הטוב ביותר, והדבר הזה היה עם Kimi K3 קורא כל מדד לידיי — אותו החזר מרוכב שאני מקבל מטיפול local AI gains as infrastructure. המדריך מחזיק את מקומו, הדיסק דק, רשימת הבדיקה ארוכה יותר, והאתגר הבא כבר מוכן לנסות.#AI#apple-silicon#benchmarking#local-inference#mlx#mtplx#performance#experiential#insightsApple Silicon inference, measuredQwen 3.8-27B על M1 Ultra: מ12.1 ל20.3 tok/s על ידי מדידת הכלחלק 1August 14, 20267 דק׳ קריאהMTPLX על M1 Ultra: ה25 tok/s Tune That Served 16.5חלק 2August 15, 20267 דק׳ קריאה—Robert E. Beckner III (Merlin)המשך קריאההקודםייעוץ: ממצא קריטי במודל חישוב ללא שמירה של PIEהבאהאחרון CLI: בניית הבסיס 51 של הכלים שלי נבנו נגדוטעויות בזיכרון קאש של פקודות יכולות לעלות לארגון שלך כמעט 6x בכל סיבוב AIגילויSeptember 23, 202615 דק׳ קריאהKitsune2: חיפושים מהירים יותר ב251x, נתיב העדכון 33x, והדיסקוס התחיל ב15x מוקדם יותרגילויSeptember 19, 202613 דק׳ קריאהBenchmark-Driven Development: A Framework for AI System ConfigurationטכניSeptember 23, 20259 דק׳ קריאהפרויקטים קשורים175-Page Chinese ManuscriptAI InnovationAI Translation SystemAI Innovation