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 מציע טיוטות עם ראשי MTP של המודל עצמו — המנגנון אותו הליין שלנו משתמש — ומקבל טיוטות דרך דגימה מדויקת של דחייה, כך שהדגימה בטמפרטורה 0.6 מייצרת את ההתפלגות זהה לזו של פענוח רגיל, רק מהר יותר. אין מודל טיוטה נפרד שמ.consume זיכרון, עומק הטיוטה מותאם לכל מכונה מול בסיס אוטורגרסיבי, והפרויקט מסרב לצרף צדדי MTP לא מאומתים למשקלים אקראיים. המדיניות האחרונה הזו היא משמעת שהייתה לי ולקימי להחיל ידנית ביום הקודם, כאשר חיברנו מחדש את טנסורים MTP שנופלו של Qwen3.8 עם שורשם. הליין מהחלק הראשון היה מדד ברור: סטודיו זהה, משפחת מודלים זהה, מדוד באותו אופן.
הבדיקה הראשונה הייתה שלי. בחודש מרץ, במעבדת השיפור האוטונומית שלי, התפסנו אתלוג שבו סביבת 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 היא זהה לאלה שהבנצ'מרקים רצה עליה: דע את עקבותיך לפני שתאשים מכונה.
טקס הטונינג של 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 שפועלות נגד המדידה:
מצבreasoning ברירת המחדל הוא פעיל, ו-Qwen3.8 חושב לפני שהוא עונה. על בקשה פשוטה עד 10, 44 של ה64 אסימונים שנוצרו נסתרו בחשיבה שהלקוח אף פעם לא מציג. עומסים אמיתיים משלמים עבור אסימונים אלה, לכן שיעור הקיר כבר כולל אותם — אבל הבקשות של הטונר לא נושאות מס כזה.
פרופיל הריצה Turbo, עם קרנלים מאומתים קומפייל, הוא כלל השקה של האפליקציה המקומית של Mac. טרמינל mtplx serve מתרגם לפרופיל Sustained במקום, כך שבדרך שורת הפקודה לא רואה את הקרנלים המהירים אלא אם תבקש.
קיבוע 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
הממצא הכי שימושי של היום מסביר את הפער בין 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
זהו שיעור של חלק ראשון ללבוש תחפושת חדשה. טענות הקהילה של llama.cpp על 25-32 אסימונים/שנייה לא שרדו מגע עם שבב זה, ו25.1 של המכוון של MTPLX לא שרד את השרת שלו. החוק הקבוע חותך: קצב ההגשה מודד בגבול HTTP עם ברירת המחדל של ייצור גלוי, אף פעם לא בתוך הטונר. זה פיתוח מבוסס מדד ביצועים מיושם שכבה אחת מעלה במערך.
נתתי ל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 רשומות:
מספר הטונר הוא הגג של המנוע, והמסלול המשרת קובע כמה ממנו תשמרו. מדוד בגבול את הלקוחות שמצאצאים באמת.
ברירת המחדל היא חלק מהמדד. מצבי רציונליות, פרופילים בזמן ריצה, ומטעני סשן כולם מבלים אסימונים או זמן, ומלחמה הוגנת מציב אותם באופן מפורש בשני הצדדים.
הדיסק הוא תקציב היפותזה. 2 אתגר בונה ב20.4 ג״ב בכל פעם שנרכש ב1 אחר הצהריים של ודאות, והוודאות זולה יותר כשהבייטים יוצאים בלוח הזמנים.
הסימטריה המרגיעה של הזוג היא שחלק ראשון הסתיים על ידי תורמת את הניסוי המדויק הזה, והניסוי הגיע באריזת מוצר עם אמנות אמיתית בתוכו — דגימה מדויקת, טונינג לכל מכונה, אימות כנה. האמנות הייתה אמיתית והפסד היה אמיתי, ושני הממצאים יצאו מהיום אותו של מדידה, סערת CPU וכל זה. הרפתקה עם לוח תוצאות היא הטיפוס הטוב ביותר, והדבר הזה היה עם Kimi K3 קורא כל מדד לידיי — אותו החזר מרוכב שאני מקבל מטיפול local AI gains as infrastructure. המדריך מחזיק את מקומו, הדיסק דק, רשימת הבדיקה ארוכה יותר, והאתגר הבא כבר מוכן לנסות.