תמיכת vLLM ב-Nanbeige4.2-3B נוחתת: מודל הסוכן הלולאתי 3B של BOSS Zhipin עוזב את עידן ה-Fork-בלבד

Nanbeige4.2-3B — המודל הסוכני הקומפקטי שמעבדת Nanbeige של BOSS Zhipin שחררה בסוף יולי 2026 — עומד להפוך לזמין לשירות על התקנת vLLM רגילה בפעם הראשונה. בקשת משיכה שנפתחה ב-9 בספטמבר 2026 מוסיפה את הארכיטקטורה לרישום המודלים של vLLM דרך הקצה האחורי של transformers. אם היא תתמזג, הפקודה vllm serve Nanbeige/Nanbeige4.2-3B תהפוך לפקודה רגילה במקום טקס מזלג ספק. זה שינוי אמיתי במה שמארח עצמי יכול לעשות: במשך ששת השבועות מאז שהמודל שוחרר, כל מנוע שירות שהכרטיס מודל שלו מפרט — vLLM, SGLang, llama.cpp, Ollama — הצביע על מזלג שמתוחזק על ידי Nanbeige, לא על התקנה ללא שינוי.

המודל עצמו אינו החדשה; הוא זמין להורדה מאז השבוע האחרון של יולי. החדשה היא שעידן ה-fork-בלבד מסתיים, והוא מסתיים השבוע. SGLang מיזגה הטמעה מקורית של Nanbeige4.2 לתוך ה-main branch שלה ב-5 בספטמבר, ו-pull request של vLLM נפתח ארבעה ימים לאחר מכן. שניהם תמיכה רשמית, בהתקנה רגילה, בארכיטקטורה שכל מנוע התייחס אליה בעבר כאל מקרה מיוחד. להלן, הכל מסומן: מה ה-pull requests בעצם עושים, מה מאומת לעומת מה שעדיין פתוח, טענות ה-benchmark של הספק, והמספרים העצמאיים ששמים אותן בהקשר.

מה השתנה השבוע, בדיוק?

ה-pull request של vLLM הוא vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)", שנפתח ב-9 בספטמבר על ידי מהנדס Nanbeige ועדיין פתוח נכון למועד כתיבת הדברים. הוא קטן במתכוון — שני קבצים. הראשון מוסיף שורה לרג'יסטרי המודלים של vLLM שממפה את שם הארכיטקטורה של Hugging Face, NanbeigeForCausalLM, אל TransformersForCausalLM — מנגנון ה-fallback הגנרי של vLLM שמריץ מודל דרך מנוע ה-transformers. השני מוסיף את NanbeigeModelArchConfigConvertor, שתפקידו היחיד הוא לומר ל-vLLM כמה שכבות לתקצב: הוא מחזיר את num_hidden_layers של ה-config כפול num_loops, מכיוון שה-transformer הלולאתי של Nanbeige חוזר על ערמת השכבות שלו, ו-vLLM חייב להתאים את גודל ה-KV-cache ומופעי ה-attention בהתאם.

שני פרטים משרשור הביקורת חשובים לכל מי שעוקב אחרי זה. ראשית, מיפוי הרשם (registry mapping) הוא מה שגורם למודל לרוץ דרך מנוע ה‑transformers אוטומטית — מתחזק vLLM ציין שברגע שהמיפוי קיים, הדגל המפורש `--model-impl transformers` הופך למיותר, ושהיתר לפני מיזוג הוא ערך תיעוד ומיפוי רשם לבדיקת CI. שנית, המבקרים ציינו ששינוי vLLM שמוזג לאחרונה (PR #54941) עשוי כבר להפוך את ממיר ספירת השכבות למיותר, על ידי זיהוי מודולי attention ישירות במקום להסיק אותם מספירת שכבות. במילים פשוטות: התיקון עשוי להיות פשוט יותר לפני שהוא נוחת, לא מורכב יותר.

הנתיב של vLLM חשוב יותר דווקא בגלל מה שהוא לא. זו אינה הניסיון הראשון להכניס את Nanbeige4.2 ל-vLLM באופן מקורי. PR #49433, שנפתח על ידי אותו מהנדס בסוף יולי כיישום מקורי מיום האפס, נסגר ב-9 בספטמבר — באותו היום שבו הופיע ה-PR של ה-transformers-backend — לאחר שהמתחזקים טענו שיישום מודל ייעודי הוא יותר עבודה ממה שהארכיטקטורה מצדיקה, והפנו במקום זאת אל ה-transformers-backend. המסר עבור הקוראים: התמיכה הרשמית ב-vLLM מגיעה במסלול התאימות, לא באמצעות יישום מקורי מכוונן ידנית, ולהבחנה הזו יש השלכות ביצועים ממשיות שנדונות להלן.

המודל שהיה זקוק לכל הטיפול המיוחד הזה

כדי להבין מדוע Nanbeige4.2-3B שבר את כל ההנחות של מערכות הריצה (runtimes), כדאי לדעת מהו המודל. זהו מודל עם כ-4 מיליארד פרמטרים, מתוכם 3 מיליארד פרמטרים שאינם embedding, ששוחרר תחת רישיון Apache-2.0 באנגלית ובסינית, ומכוון ישירות לעומסי עבודה מסוג agentic: סוכני קוד, אוטומציה משרדית, שימוש בכלים, והפעלת טרמינל. הדוח הטכני (arXiv 2607.22083, מיום 24 ביולי 2026) מתאר אימון מוקדם (pretraining) מאפס על 28 טריליון טוקנים, ואחריו מתכון של SFT בתוספת שלושה שלבי RL הבנויים סביב אינטראקציה עם סביבות מהעולם האמיתי. חלון ההקשר מגיע ל-262,144 טוקנים. כל זה ניתן לבדיקה.

החלק שאינו רגיל הוא הארכיטקטורה. Nanbeige4.2-3B משתמש ב-"Looped Transformer": אותה מחסנית של 22 שכבות טרנספורמר מופעלת פעמיים, כך שמודל עם 3B פרמטרים מבצע בערך פי שניים חישוב לכל אסימון מאשר 3B רגיל, מבלי להוסיף משקלים. ככה המעבדה מיישבת בין מספר פרמטרים קטן לבין טענות אמת מידה שחורגות מקטגוריית המשקל שלו — המודל למעשה מקבל מעבר שני על הייצוגים של עצמו, והתצורה מבטאת שימוש חוזר זה כ-num_loops של 2 על פני 22 שכבות נסתרות (44 שלבי קשב אפקטיביים). המחיר הוא שכל מנוע הסקה צריך לדעת כיצד לטפל במחסנית שכבות שמשמשת פעמיים: כיצד לאנדקס את הקשב עבור מטמון KV וגרפי CUDA, כיצד להגדיר את גודל המטמון, וכיצד להזרים משקלים. מנוע סטנדרטי הבנוי סביב טרנספורמרים עם מעבר קדימה אחד אין לו מושג מה לעשות עם זה, ולכן קוד המודל המותאם אישית כלול במאגר ודורש trust_remote_code=True בהגדרות Hugging Face Transformers.

הקוד המותאם אישית הזה הוא גם המקום שבו נמצאים הקצוות המחוספסים ביותר של המודל. דוח עצמאי (arXiv 2608.13987, אמצע אוגוסט) תיעד חמישה באגים שמנעו מהצ'קפוינט ששוחרר להיטען ישירות ב-Hugging Face Transformers — ביניהם באפר של הטמעת מיקום סיבובית שאופס בשקט וקריאות לממשקי API של מטמון שהוסרו — ופוסטים בקהילה תיארו פתרונות עוקפים כמו use_cache=False לפני שהמודל הסכים לרוץ בכלל. כל אלה היו ניתנים לתיקון, ונקודות ביקורת וכלי הרצה מתוקנים כבר מסתובבים, אבל הדפוס הוא הנקודה: זו ארכיטקטורה חכמה שמשלמת מס חריג של חיכוך בפריסה מהיום הראשון.

המספרים, ספק ועצמאי

טענת אמת המידה המרכזית, ישירות מהדוח הטכני, היא ש-Nanbeige4.2-3B עולה על מודלים פתוחים גדולים יותר — Qwen3.5-9B ו-Gemma4-12B — בהערכות סוכן (agentic). המספר המוביל הוא SWE-Bench Verified עם 63.6 לעומת 53.1 של Qwen3.5-9B ו-44.2 של Gemma4-12B. הדוח גם מפרט GPQA-Diamond עם 87.4, HMMT-Feb-2026 עם 82.8, Terminal-Bench 2.0 עם 44.1 ו-SWE-Bench Pro עם 46.9. אף אחד מאלה לא שוחזר באופן בלתי תלוי על גבי כלי המדידה שנבחר על ידי הספק, ויש לקרוא אותם כחשבון של המעבדה על המודל שלה — אותו חשבון שתקציר כרטיס המודל מציג כמי שיושב בראש לוח המובילים של Artificial Analysis למודלים קטנים.

הדבר הקרוב ביותר לבדיקה בלתי־תלויה עד כה מגיע ממישור אחר לגמרי. במבחן ביצועים על־המכשיר של Artificial Analysis × Liquid AI שהתבצע על iPhone 17 Pro ופורסם בסוף אוגוסט, גרסת 4-bit של Nanbeige4.2-3B חלקה את הציון הממוצע הגבוה ביותר מבין 33 דגמים עובדים מתחת ל־8GB בהקשר של 16K (63, ברמה של LFM2.5-2.6B ולפני כמה דגמים מסוג 9B), ובהקשר של 64K היא קיבלה 65, שנייה רק ל־66 של Ling 3.0 Tiny. פרופיל המבחנים שלה היה בולט: הטובה ביותר בתחום MATH-500 (96%) וחזקה בקריאות פונקציות (76% ב־BFCL), אבל שיעור אי־ההזיות שלה ב־AA-Omniscience היה חלש, 33% — ומכריע לשימוש אמיתי, היא הייתה איטית. היא ייצרה בערך 14 אסימונים בשנייה ולקח לה 21.4 שניות ו־4.0 GB כדי לענות על הנחיה של 1,024 אסימונים; תחת מגבלת תשובה של 60 שניות הציון הממוצע שלה קרס מ־63 ל־18. במילים אחרות: האיכות שמנצחת דגמי 9B היא אמיתית, וכך גם המחיר של הארכיטקטורה המלולאת שמייצרת אותה.

מה התמיכה במעלה הזרם בעצם קונה לך

חיבור שני האירועים מה-upstream יחדיו מצייר תמונה מעשית פשוטה עבור מי שמארח בעצמו. אם אתה מריץ SGLang, Nanbeige4.2-3B כבר ניתן לשרת מהתקנה רגילה על בסיס התמיכה שמוזגה לענף הראשי — ללא fork, כשהפרסרים של קריאות הכלים וההיסק של המודל מחוברים לאותם גלאים של qwen3 ש-SGLang כבר כולל. אם אתה מריץ vLLM, תמיכה רגילה נמצאת במרחק merge אחד: שורת הרישום מנתבת את המודל ל-backend של transformers, ממיר הארכיטקטורה מכוון את גודל המטמון כראוי, והפרסרים של ההיסק וקריאות הכלים של qwen3 עושים בהם שימוש חוזר, וכך פועל הממשק התואם-OpenAI לקריאות לכלים.

האזהרה הכנה היא שהנתיב של vLLM הוא נתיב תאימות, לא נתיב מכוונן. הרצה של NanbeigeForCausalLM דרך TransformersForCausalLM פירושה ש-vLLM מריץ את קוד Hugging Face של המודל עצמו בתוך שכבת השרתים שלו, ולא יישום מקורי עם קרנלים מותאמים אישית וטיפול בגרפי CUDA — ההבדל הוא בדיוק מה ש-SGLang בחרה לבנות באופן מקורי. עבור מודל 3B שעלותו לכל טוקן כבר מוכפלת בשל הלולאה, נתיב ה-transformer-backend לא סביר שיהיה נתיב השרתים המהיר ביותר האפשרי, וההיסטוריה של חמשת הבאגים בקוד המותאם אישית הבסיסי פירושה שהנתיב יורש את כל המוזרויות שנותרו בו. עבור עומסי עבודה של סוכנים, שבהם תקינות קריאות לכלים והתנהגות בהקשר ארוך בדרך כלל חשובים יותר מטוקנים גולמיים בשנייה, זה עשוי להיות פשרה מקובלת; לצ'אט רגיש להשהיה כדאי לבצע בדיקות ביצועים לפני שמהמרים עליו כנתיב ייצור. ושתי מנועים עדיין רק בפיצול (fork): llama.cpp ו-Ollama ממשיכים להצביע על ענפי Nanbeige, ושרת llama.cpp המובנה ב-LM Studio עדיין לא תומך בארכיטקטורה.

מה לצפות בהמשך

שלושה דברים, וכל אחד מהם היה משנה את התמונה. ראשית, ה-PR של vLLM צריך להתמזג ולהיכלל במהדורה — עקבו אחרי השרשור והערות המהדורה של vLLM; המבקרים כבר ציינו שערך תיעוד ומיפוי checkpoints של CI נותרו לפני שהוא מוכן למיזוג. שנית, עקבו האם ממיר ספירת השכבות ישרוד את הביקורת, מכיוון שהמתחזקים מאמינים ש-PR #54941 אולי הפך אותו למיותר — סימן לעד כמה הפתרון העוקף הזה הוא פיגומים סביב הארכיטקטורה הלולאתית. שלישית, עקבו אחרי שאלת ספק האירוח: הכרטיס של Hugging Face כרגע לא מציג ספק inference שמשרת את המודל, וגם אנחנו לא מארחים אותו, כך שכיום זהו סיפור של אירוח עצמי. כשספק אכן יוסיף אותו לקטלוג, צד הניתוב הופך לשגרה — API אחד על פני קטלוג מודלים גדול, עם מחירי מחירון של הספק שמועברים הלאה ללא תוספת מחיר, הוא הדרך עם החיכוך הנמוך לבצע בדיקת A/B בין Nanbeige4.2-3B באירוח עצמי לבין המודלים המתארחים שהוא טוען שהוא עוקף. עד אז, אבן הדרך שכדאי לשים לב אליה היא זו שזה עתה קרתה: שישה שבועות אחרי השקה שכל מנוע ריצה מרכזי קיבל במשיכת כתפיים ובפיצול, שניים מהם משרתים כעת את Nanbeige4.2-3B מהתקנה ללא שינוי.