Laya על Apple Silicon: מה שהיציאה ל-MLX נותנת לכם, ומה שהיא לא

Laya הוא מודל החלטה שלעולם לא כותב משפט. Convai Innovations העלתה את המשקלים שלה ל-Hugging Face ב-2026-09-18, ולמחרת מפתח בשם mizorewww פרסם Laya-MLX — הסבה עצמאית שמריצה את כל שלושת הצ'קפוינטים של Laya באופן נייטיבי על Apple Silicon דרך MLX, בלי PyTorch, בלי מנוע הרצה של Transformers ובלי קריאה לענן. אותה הסבה מדווחת על חציון של 13.42 ms לשאלה אנגלית קצרה אחת על הצ'קפוינט 421M, 7.39 ms על זה הרב-לשוני 322M, ואפס טוקני פלט, על M3 Max. בינתיים Kev, המשפחה הפתוחה האחרת שרודפת אחרי אותו רעיון של החלטות מטופסות, בנויה על Qwen3.5-4B-Base ונזקקה לבקאנד שני שלם לפני שהייתה שמישה ב-Mac, כי ל-PyTorch אין קרנלים לשכבות ה-DeltaNet שלה על ה-GPU של Apple. שני פרויקטים, אותו שבוע, אותה מטרה, ורק אחד מהם הוסב בצורה נקייה. ההבדל הזה הוא הסיפור, והוא סיפור של סביבת הרצה ולא סיפור של מודל.

הסיבה שזה שווה מאמר היום היא לא שלייה חדשה. היא שעד 2026-09-19 לא הייתה דרך להריץ מודל החלטות מבוסס-טיפוסים על Mac בלי לגרור יחד איתו מחסנית PyTorch, ולשאלה שלקורא באמת יש — האם אני יכול להריץ את זה על הלפטופ שלי, ועל מה אני מוותר — סוף סוף יש תשובה מדידה. אז הקטע הזה עוסק במסלול ההגשה, במספרים שמאחוריו, ובמקומות שבהם המספרים מפסיקים לומר את מה שהם נראים.

ראשית, מה Laya אינה

Laya אינה LLM. היא אינה אוטורגרסיבית: מעבר קדימה דו-כיווני אחד על המצב ועל השאלות שלך, והתוצאה היא תשובות בעלות טיפוס. אין פענוח טוקן-אחר-טוקן, אין שרשרת מחשבה, אין JSON מחולל שצריך לפרסר, ואין טוקני פלט לחייב עליהם. שלושת פרימיטיבי התשובה הם בחירה (בחר אחת מתוך N אפשרויות בעלות שם), ניקוד (רמת רובריקה אורדינלית) ו-noul (הסתברות מכוילת שמשהו נכון).

זה חשוב לאופן שבו אתה קורא כל מספר במאמר הזה. כשהפורט מדווח 13.42 ms, הוא לא מדווח על 13.42 ms כדי להפיק כמה מאות טוקנים כפי שמדד השוואה של יצירה היה עושה. הוא מדווח על הפעולה כולה. השוואה בין השהיה של מודל החלטות לבין טוקנים לשנייה של LLM היא השוואה בין שתי עבודות שונות, וכל מאמר שעושה זאת — כולל הפוסט הוויראלי "מהיר פי 50 מ-Jev" שהופץ לאחר ההשקה — מציג טענה שהעבודה שבבסיס הדבר אינה תומכת בה.

מה שהפורט בעצם מדד

הנתונים האלה הם של מחבר הפורט עצמו, נלקחו על מכונה מוצהרת, ויש לקרוא אותם עם המכונה והשיטה מצורפות. Laya-MLX מדד אותם על M3 Max עם 40 ליבות GPU ו-128 GiB של זיכרון מאוחד, ב-FP16, כאשר טעינת המודל אינה נכללת.

• שאלה קצרה אחת, P50 — 13.42 ms על הצ'קפוינט האנגלי של 421M, 7.39 ms על הצ'קפוינט הרב-לשוני של 322M.

• שאלה קצרה אחת, P95 — 13.92 ms ו-7.79 ms בהתאמה.

• תפוקה של 50 שאלות — 146.8 שאלות בשנייה ו-395.0 שאלות בשנייה.

• שיא הקצאת MLX — 943.6 MiB ו-687.6 MiB.

גבול התזמון הוא החלק ששווה לקרוא פעמיים. הוא כולל הכנת פרומפט, טוקניזציה, בניית טנסורים, הסקה מסונכרנת, כיול ועיצוב תוצאות. הוא אינו כולל טעינת מודל. הרצת התפוקה של 50 שאלות השתמשה ב-batch_size=64, בעוד שברירת המחדל של ה-API היא 16, כך שצמד המספרים הזה מתאר עומס מכוון באצוות ולא את מה שעולה קריאה אינטראקטיבית בודדת. אורכי קלט שונים, מספרי שאלות שונים ותנאי ריצה שונים — כולם משנים את התוצאה. ההסתייגויות האלה הן ההבדל בין מספר לבין בנצ'מרק, וה-port מציין אותן בעצמו.

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

בדיקת הנאמנות היא התוצאה המעניינת יותר

הסבה מהירה שמשיבה תשובות שונות מהמודל שאותו היא מסבה היא חסרת ערך, וכאן הפרויקט עשה את העבודה שבאמת חשובה. כל שלושת הצ'קפוינטים תאמו את התשובה הנבחרת במעלה הזרם ב-63 מתוך 63 שאלות אימות, הן ב-FP32 והן ב-FP16 — 378 מתוך 378 השוואות. כל תצורה גם הריצה 100 קריאות חוזרות ודטרמיניסטיות ללא גידול מדיד בזיכרון הפעיל, וכל 36 קבצי המשקולות שפורסמו עברו אימות checksum קפדני מרחוק.

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

עצמאי, מתוחזק על ידי הקהילה, ועדיין לא ברשימה

הפורט אומר זאת על עצמו, פעמיים: הוא פורט MLX עצמאי, לא מהדורה רשמית של Convai Innovations. אימון וכיוונון עדין של RLCD נשארים במעלה הזרם. המשקלים מיוחסים ל-Convai Innovations. Apache-2.0 משני הצדדים.

האופן שבו ה-upstream מתייחס לכך חושף יותר מכל כתב ויתור. ה-README של Laya מכיל רשימת כלי קהילה, ונכון ל-2026-09-23 יש בה ארבעה ערכים: omp-laya-judge, laya-adk-toolkit, laya-Ascend עבור Huawei Ascend NPUs, וגם laya-apple — סביבת הרצה ל-Apple Silicon המשתמשת ב-MLX GPU וב-Neural Engine. הערך הרביעי הזה הגיע דרך בקשת משיכה #260, שמוזגה ב-2026-09-23. הפורט שהמאמר הזה עוסק בו אינו בין הארבעה. הרשימה של ה-upstream מפנה כעת את קוראי Apple Silicon לפרויקט קהילתי אחר מזה שיצא ראשון ושברשותו מדדי הביצועים.

מעקב הגיליונות של Upstream עצמו אומר את השאר. גיליון #50, "העברות ל-Apple silicon", שנפתח ב-2026-09-21, עדיין פתוח; המתחזק השיב באותו יום שתמיכת Apple Silicon נמצאת במעקב, ושהעברות קהילתיות כמו Laya-MLX בוחנות הסקת Metal נייטיב, ואז השיב שוב ב-2026-09-23 בשורה ששווה לצטט במדויק: "העברת MLX נותרת מתוחזקת על ידי הקהילה." התיקון בצד PyTorch — autocast של MPS ותיקון RoPE של transformers 4.x — נכנס כבקשת משיכה #273, שמוזגה ב-2026-09-23, כאשר סוקר באותו שרשור ציין שהוא עדיין צריך להיות משולב עם רפקטור ה-autocast הנפרד ב-#109, שנשאר פתוח. וגיליון #52, שנפתח ב-2026-09-21, מדווח על sidecar של Laya-MLX שגדל לכ-21.7 GB של זיכרון Metal לאורך מספר שעות פעולה, כאשר vmmap מייחס כ-21.4 GB לתת-המערכת הגרפית ולא ל-heap של Python; הוא מציע להגביל את מטמון ה-allocator ולנקות אותו לאחר כל הסקה, והוא עדיין פתוח.

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

האם אני יכול להריץ את זה על המחשב הנייד שלי, ועל מה אני מוותר?

ההתקנה היא פקודת pip אחת, והפורט מפרסם משקולות FP16 שהומרו מראש כך שאינך ממיר דבר בעצמך:

pip install laya-mlx

לאחר מכן import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), ולקרוא ל-agent.predict(state, questions). הדרישות הן Apple Silicon, Python 3.11+ ו-macOS 14+. הסביבה שנמדדה הייתה macOS 27.2, Python 3.12.13 ו-MLX 0.32.2 — והפורט מציין שמהדורת ה-MLX שבה השתמש סיפקה חבילות wheel עבור macOS 14, 15 ו-26 בעוד המתקין בחר בזה של 26, ושגרסאות macOS נתמכות ישנות יותר לא נבדקו במכונה ההיא.

מה שאתה מוותר עליו, ממד אחר ממד:

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

• רצפת זיכרון מול מרווח — פחות מ-1 GiB של שיא הקצאת MLX עבור שאלה קצרה נוח על כל Mac מסדרת M. זה אינו הצהרה על עומס שרת מתמשך, ו-issue #52 הוא הסיבה להיזהר אם אתה מתכנן להריץ את זה כ-sidecar ארוך-טווח ולא כקריאת ספרייה.

• רב־לשוני לעומת אנגלית — נקודת הביקורת הרב־לשונית בגודל 322M היא המהירה מבין השתיים וזו שמכסה יותר מ־100 שפות, אך הפורט נושא במכוון את האזהרה של במעלה הזרם כלשונה: נקודות הביקורת לאנגלית אינן תחליף לרב־לשונית. ניתוב ביניהן הוא התבנית המיועדת, ולא מותרות.

• מאושר על ידי מעלה הזרם לעומת מתוחזק על ידי הקהילה — זה השני. שום דבר בהערות השחרור של מעלה הזרם לא מבטיח שהפורט הזה ימשיך לעבוד לאורך שינויים במעלה הזרם.

• מהירות לעומת כיול — פורט מהיר לא מתקן דלי כיול שמגיע עם ביטחון יתר. במעלה הזרם מגבילים טמפרטורות מותאמות ל-[0.5, 5.0], והדלי שנשלח choice:11+ הוא 0.1006, מה שיחריף את הלוגיטים בערך פי עשרה וידווח על הטלת מטבע כוודאות כמעט מוחלטת. טמפרטורות כיול מותאמות קיימות מסיבה; התאם אותן על נתוני ההחזקה שלך לפני שאתה מסתעף על סמך הסתברות.

כדאי לשאת שתי מגבלות נוספות, ושתיהן מגיעות מהטרַקר של upstream עצמו. action.act_probability אינו נושא כיום שום אות שמיש — הוא מחזיר 1.0 כמעט בכל קלט, וה-logits הגולמיים שלו נמצאו בקורלציה הפוכה לנכונות, עם AUROC של 0.30 על פני 396 החלטות מתויגות (issue #185). השתמשו כשער ב-confidence במקום זאת, שמגיע ל-0.77 על אותם פריטים. ושאלות noul יכולות ללכת אחרי תוויות האפשרויות שלהן ולא אחרי ה-state (issue #156) — הכרטיס של upstream עצמו מדווח על "לא" בטוח בקלט חיובי בבירור, ובאופן החזק ביותר בצ'קפוינט האנגלי. העקיפה המוצעת היא לא להושיט יד למודל אחר, אלא לעצב מחדש את השאלה: לשאול אותה כ-choice בת שתי אפשרויות עם מפתחות ניטרליים (A/B) ואת ניסוח ה"כן/לא" שלכם כתיאורי האפשרויות.

מדוע מודל החלטה אחד עובר הסבה בצורה נקייה והאחר לא

הניגוד כאן הוא ארכיטקטוני, וזה הדבר המועיל ביותר במאמר הזה לכל מי שבוחר בין שתי המשפחות.

פריימוורק הבסיס של Laya הוא ModernBERT-large, מקודד דו-כיווני הבנוי כולו מקשב (attention). קשב הוא הדבר שבו ערכת ה-GPU של Apple מצטיינת ביותר, וזה גם מה ש-MLX השקיעה בו את מאמציה. לכן ההעברה היא מימוש מחדש של שכבות שכבר היו להן מסלולים מהירים: המקודד, שכבות ה-Transformer של ראש ההחלטה, ראש הניקוד וראש הפעולה פועלים כולם ב-MLX, והטוקניזציה עדיין עוברת דרך הטוקנייזר ה-Rust של Hugging Face.

עמודי השדרה של Kev הם בסיסי Qwen3.5, ו-Qwen3.5 מערבב שכבות קשב עם שכבות Gated DeltaNet. DeltaNet הוא רקורנטי ומתעלם ממסכות קשב. יש לכך שתי השלכות. ראשית, כל שאלה חייבת לרוץ כשורה נפרדת משלה במקום לחלוק רצף ממוסך אחד, אשר פרויקט Kev מטפל בכך על ידי חישוב המצב פעם אחת ושימוש חוזר במטמון שלו לכל שורה. שנית — וזה החלק שמכאיב ב-Mac — לא היו קרנלים של PyTorch עבור השכבות האלה על ה-GPU של Apple, אז PyTorch נסוג לקוד ייחוס. jaredpalmer/kev-4b עדיין נושא את המגבלה הנובעת מכך בלשון פשוטה: בקשה של חמש שאלות שלוקחת 0.17 שניות בבנייה של Qwen3 של Kev-4B לוקחת 0.78 שניות ב-bf16 על M5.

בדוק את הניסוח הנוכחי לפני שאתה מצטט אותו, כי הוא השתנה. ה-README של מאגר Kev אומר כעת שהשרת מריץ את מודלי Qwen3.5 דרך MLX על Apple Silicon במקום, ומפרסם נתוני M5 משלו עבור בקשה של חמש שאלות עם שלוש אפשרויות בכל אחת על מצב של כ-270 טוקנים: Kev-4B ב-721 ms על מצב חדש ו-136 ms על מצב חוזר דרך מטמון הקידומת, לעומת 3,302 ms ו-847 ms בנתיב PyTorch bf16 MPS. Kev-0.8B מגיע ל-149 ms ו-28 ms. מודלי Qwen3 מהדור הקודם עדיין פועלים על PyTorch MPS רגיל, והפרויקט מכנה אותם בחירה טובה ב-Mac.

היזהר לא להפוך את זה לתוצאת מרוץ. אלה אינן מדידות ראש בראש. 13.42 ms של Laya-MLX הוא שאלה קצרה אחת על M3 Max; 721 ms של Kev הם חמש שאלות עם שלוש אפשרויות כל אחת על מצב של ~270 טוקנים על M5. מספר שאלות שונה, מספר אפשרויות שונה, אורכי מצב שונים, מכונות שונות, סביבות ריצה שונות. מה שניתן לאמת ושווה להשוות הוא צורת הבעיה, לא מנצח: מקודד קשב טהור מועבר ל-Apple Silicon בלי מאבק, ומודל היברידי עם קשב ליניארי היה זקוק ל-backend שני שלם לפני שהיה שמיש שם.

לשם מה נועד באמת מודל החלטה

אם מסירים את הבנצ'מרקים, מקרה השימוש האמיתי הוא צר, והפרויקט עצמו אומר זאת: Laya הוא בסיס מהיר להתמחות, לא מנוע החלטות ללא דוגמאות. בבנצ'מרק ה-typed-decisions של Convai עצמה, שני הצ'קפוינטים הבסיסיים משיגים 0.362 ו-0.342 במצב ללא דוגמאות, לעומת בסיס של מחלקת הרוב עם 0.461 ובסיס אקראי עם 0.318. הם מתחת לקו שהייתם מקבלים אילו תמיד הייתם עונים לתווית הנפוצה ביותר. הציון הכותרתי 0.766 שייך ל-laya-typed-decisions, הצ'קפוינט שעבר כוונון עדין על מחיצת האימון של אותו בנצ'מרק עצמו, ואסור לצטט אותו כיכולת כללית.

ההשוואה של Convai שפורסמה נגד TypeSafe Jev 1.13.0 שווה קריאה בדיוק מהסיבה הזו, והיא מסומנת בקפידה מצדם: כל נתון של Laya הוא מה שהנתב למעשה מחזיר, ונתוני Jev הם מספרים שפורסמו על ידי צד שלישי שאותם Convai מעולם לא מדדה מכיוון שאין לה גישה ל-API של TypeSafe. בהשוואה הזו, Laya המנותב מקבל 0.766 לעומת 0.727 של Jev ב-typed-decisions, עם ECE לאחר טמפרטורה של 0.081 לעומת 0.246, ושהיית p50 של 32.8 ms לעומת 236–276 ms על Tesla T4 — הבדל של פי 7.8 בשאלה אחת. זה המספר שכדאי לצטט. הנתון "מהיר פי 50 מ-Jev" שנפוץ ברשתות החברתיות אינו מופיע בתיעוד של הפרויקט או בבנצ'מרקים שלו, וההשוואה שפורסמה על ידי הפרויקט עצמו אינה תומכת בו. Jev גם מוביל במקומות שבהם הוא מוביל: ב-Banking77, Jev מקבל 0.870 לעומת 0.425 של Laya, מכיוון שהאפשרויות של Laya חולקות תקציב טוקנים קבוע, ו-77 תוויות מותירות בערך שלושה עד ארבעה טוקנים לכל אחת.

אז הצורה של פריסה אמיתית היא ראש החלטה זול, מקומי וצר — ניתוב פנייה, דירוג דחיפות, מענה לשער כן/לא — עם משהו גנרטיבי מאחוריו לחלק שצריך לכתוב. מודל ההחלטה מבצע את קריאת הסיווג במילישניות ומסלים. החצי הגנרטיבי הוא מודל אחר על סביבת ריצה אחרת, ושם נתב מצדיק את מקומו: 200+ מודלים מאחורי מפתח אחד במחיר המחירון של הספק וללא תוספת מחיר, כך ששינוי מחיר של ספק נכנס לתוקף באותו יום, ומעבר אוטומטי לגיבוי כאשר ספק מתדרדר במהלך הריצה. OrcaRouter לא משרת את Laya, והוא לא משרת את Kev או Jev — משפחת Qwen3.5 נמצאת ברשימת המודלים שלנו, ומודלי ההחלטה עצמם לא. מה שאנחנו מכסים הוא החצי הגנרטיבי של אותו מכלול, שהוא החצי שאליו אתם פונים בכל בקשה שראש ההחלטה מסלים.

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

מי צריך להריץ את זה, ומי צריך לחכות

הרץ את Laya-MLX אם אתה על Mac מסדרת M, ההחלטות שלך מוגבלות — בחירה בין אפשרויות בעלות שם, ציון לפי רובריקה, שער כן/לא — ויש לך או תוויות שעליהן לבצע כוונון עדין, או שאתה מוכן להתאים טמפרטורות כיול בעצמך. ההתקנה היא פקודה אחת, רצפת הזיכרון היא מתחת לג'יגה-בייט, ועבודת הנאמנות נעשתה ופורסמה.

רגע, אם אתה צריך הבטחות תמיכה במעלה הזרם, אם אתה מריץ sidecar ארוך טווח ורוצה ששאלת גדילת הזיכרון תיפתר במהדורה ולא בנושא פתוח, או אם השאלות שלך פתוחות. מקודד לא-אוטורגרסיבי שעונה על "מה עליי לעשות הלאה" אינו גרסה קטנה יותר של LLM שעושה את אותו הדבר. זהו כלי אחר, והוא מתפרש היטב רק כאשר השאלה כבר מעוצבת עבורו.