
הדלף של Qwen 4: ה-PR של SGLang ל-Host-Staging מראה כיצד טבלת ה-PLE בגודל 47.7 GiB נכנסת ל-GPU אחד
- OrcaחדשOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 לכל 1M טוקנים
- orcaחדשOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 לכל 1M טוקנים
- deepseekחדשDeepSeek: DeepSeek V4.1 Flash2026-09-1040אינטליגנציה
- openaiOpenAI: GPT-6 Astra2026-09-0453אינטליגנציה77כתיבת קוד
- googleGoogle: Gemini 3.8 Flash2026-09-0241אינטליגנציה76כתיבת קוד
- qwenQwen: Qwen3.8 Max (0902)2026-09-0245אינטליגנציה76כתיבת קוד
- anthropicAnthropic: Claude Fable 5.12026-09-0153אינטליגנציה82כתיבת קוד
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 לכל 1M טוקנים
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642אינטליגנציה72כתיבת קוד
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 לכל 1M טוקנים
- z-aiZ.ai: GLM 5.32026-08-1845אינטליגנציה75כתיבת קוד
- obsidianQwen3.8 27B2026-08-1534אינטליגנציה68כתיבת קוד
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1236אינטליגנציה69כתיבת קוד
- grokSpaceXAI: Grok 4.62026-08-1244אינטליגנציה77כתיבת קוד
- metaMeta: Muse Spark 1.22026-08-0540אינטליגנציה72כתיבת קוד
- qwenQwen: Qwen3.8 Max2026-08-0345אינטליגנציה76כתיבת קוד
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3135אינטליגנציה69כתיבת קוד
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 לכל 1M טוקנים
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
המספר שיכריע אם Qwen 4 הוא מודל שתוכל להריץ בעצמך אינו מספר הפרמטרים שלו. הוא 47.7 GiB — גודל טבלת ההטמעות ה-n-gram שנלווית לארכיטקטורת Qwen4, נפרדת מהמשקולות, וצריכה להתקיים במקום כלשהו בזמן שהמודל מפענח. בקשת משיכה (pull request) שנפתחה במאגר SGLang ב-18 בספטמבר 2026, בשם [Qwen4-Exp] Add host staging for file-backed PLE, היא ניסיון למנוע מאותה טבלה להכתיב כמה זיכרון RAM נדרש למכונה לפני שהיא יכולה לרוץ בכלל. Qwen 4 טרם שוחרר: אין כרטיס מודל, אין משקולות, אין רשומה בקטלוג, אין תאריך. המודל היחיד ששוחרר ומממש את הארכיטקטורה הזו הוא Qwen3.8-Flash-Next, תצוגת המשקולות הפתוחות שפורסמה ב-26 באוגוסט 2026, ושהתצורה שלה מצהירה model_type=qwen4_exp — אותה מחרוזת שמעניקה לבקשת המשיכה את שמה. אחיו לייצור Qwen3.8-Flash הוא הגרסה שמי שקורא ל-API יכול למעשה להגיע אליה היום. כל מה שבכתבה הזו על Qwen 4 הוא הסקה מאותה תצוגה מקדימה ומקוד המנוע; בקשת המשיכה פתוחה ולא מוזגה, אז יש לקרוא את כל זה כאות, לא כיכולת ששוחררה.
מהו האות בפועל
![A screenshot of the GitHub pull request page for sgl-project/sglang#40235, titled '[Qwen4-Exp] Add host staging for file-backed PLE', shown open with Dev-Jahn wanting to merge 1 commit into sgl-project:main from Dev-Jahn:task/ple-host-staged, counters reading Conversation 0, Commits 1, Checks 119 and Files changed 21, and a diff stat of +1,476 lines and -168. The Motivation section quotes the existing file backend (#37068) keeping the 47.7 GiB n-gram PLE table in a sparse file and requiring cudaDevAttrPageableMemoryAccessUsesHostPageTables, glossed as the GB10 class, and notes the HMM alternative running at 2.8x the pinned TPOT at concurrency 16 on an RTX PRO 6000 with an FP8 TP4 64 GB memory cap. The Modifications section lists PageCacheRowSource in qwen4_exp_ple_rows.py advising pages with POSIX_FADV_WILLNEED, PleHostStaging in qwen4_exp_ple_staging.py giving each PLE layer two pinned 8192-row buffers of 1.25 MiB each at FP8 plus one worker, host-side n-gram hashing in hash_contexts_numpy, and a CUDA-graph replay preparation step costing 0.5 to 1 ms per decode step over pinned. The right rail lists nine requested reviewers all awaiting review, with a note that at least 1 approving review is required to merge.](https://cms.orcarouter.ai/api/media/file/2-1002.png)
בקשת משיכה sgl-project/sglang#40235 אינה השקה והיא אינה ממוזגת. היא יושבת על קומיט אחד, שנפתח על ידי התורם Dev-Jahn, וממזגת ענף בשם task/ple-host-staged אל הקו הראשי של SGLang. תשעה בעלי קוד התבקשו לסקור, וכולם מוצגים כממתינים, כך שלפחות סקירה מאשרת אחת עומדת בין זה לבין main. שלוש משימות CI — בדיקת ה-PR הבסיסית, בדיקת ה-PR הנוספת, והרצת AMD ROCm — נכשלות על הקומיט הפתוח. זהו המצב הרגיל של שינוי מנוע גדול בתהליך, וזו גם הסיבה שהחלק המעניין ב-PR הזה אינו אם הוא נוחת אלא מה שהמחבר שלה היה צריך למדוד כדי לטעון בעדו. התיאור כולל בערך 1,400 שורות שנוספו כולל בדיקות, וטבלת בנצ'מרק שהיא הנתונים הציבוריים הקונקרטיים ביותר שמישהו פרסם על הרצת ארכיטקטורה זו על GPU בודד.
למה הטבלה היא כל הסיפור
הטמעות לפי שכבה הן המוזרות המבנית של הדור הזה. בעוד שמודל רגיל מציב הטמעת טוקן אחת בחזית, העיצוב של Qwen4 מכיל טבלת n-gram גדולה — ביגרמות וטריגרמות, מגובבות לאוצר מילים גדול בהרבה מזה של הטוקנייזר — ומזין ממנה חיפושי הטמעות לפי שכבה לאורך כל הסטאק. חומר התצוגה המקדימה של עליבאבא עצמה מתאר את רכיב ה-n-gram כעשרות מיליארדי פרמטרים על גבי גוף ה-MoE בעל 125B פרמטרים; פירוקים קהילתיים של נקודת הביקורת ששוחררה מציבים את קובץ הטבלה על 47.7 GiB. נתונים אלה מגיעים ממקורות ספקים וקהילה ולא משחזור בלתי תלוי, והקשר המדויק בין הטבלה של התצוגה המקדימה לבין מה ש-Qwen 4 מספק אינו ידוע.
מה שאין עליו ספק הוא ההשלכה ההנדסית. טבלת צד של 47.7 GiB שחייבים לעיין בה בכל שלב פענוח אינה משהו שאפשר לדחוף בשקט לפינה של VRAM. בכרטיס של 96 GB היא מתחרה ישירות במטמון ה-KV; בכרטיסים קטנים יותר היא פשוט לא נכנסת. זו הסיבה ש-SGLang, שסיפקה תמיכת day-0 עבור התצוגה המקדימה בסוף אוגוסט, הקדישה את שלושת השבועות הבאים לייצור pull request אחד אחרי השני על מבנה הנתונים הבודד הזה ולא על המודל שסביבו.
מה היה שבור לפני ה-PR הזה
ל-SGLang כבר היו שתי דרכים להחזיק את הטבלה, ולשתיהן היה קצה קשה.
• מוצמד שומר את כל הטבלה בזיכרון ה-RAM של המארח וקורא אותה משם. זה עובד, זה מהיר, וזה הופך את דרישת הזיכרון של המארח למוחלטת — אין גרסה קטנה יותר שלו.
• מבוסס-קבצים, שנוסף קודם לכן בבקשת משיכה נפרדת, שומר את הטבלה בקובץ דליל ומאפשר לליבת ה-gather לקרוא את המיפוי ישירות, כך שמטמון העמודים של מערכת ההפעלה קובע כמה ממנה נשאר בזיכרון. הבעיה היא חומרתית: מסלול הקריאה הישירה הזה דורש שה-GPU ידווח על cudaDevAttrPageableMemoryAccessUsesHostPageTables — היכולת שטקסט בקשת המשיכה עצמו מכנה בשם "סוג ה-GB10". ב-GPU ללא יכולת זו, ה-backend מבוסס-הקבצים נדחה outright ו-pinned היא האפשרות היחידה שנותרה.
הפער שנוצר אינו תיאורטי. דיווח נפרד שהוגש כנגד אותו נתיב קוד מתעד משתמש על שני RTX 3090s שחלקו לכל דרגה בטבלה הגיע ל-23.84 GiB לעומת 23.56 GiB של זיכרון שמיש — חסר 0.28 GiB, כש-188 GiB של זיכרון RAM של המארח עומדים פנויים. בתצורה הזו, ה-backend של הקבצים נדחה על ידי בדיקת החומרה, ודגל ה-CPU-offload הרגיל מעלה שגיאה כשמשלבים אותו עם דגל ה-PLE offload. להיות חסר שלוש מאות מגה-בייט עם מאה שמונים ג'יגה-בייט פנויים הוא בדיוק צורת הבעיה שה-pull request הזה נועד להסיר.
אילו שינויים בסטייג'ינג של המארח
המנגנון שה-PR מוסיף הוא שכבת ביניים בין הקובץ להתקן. במקום לבקש מה-GPU לבצע דה-רפרנס לדפי המארח, רכיב בצד ה-CPU קורא את השורות שהוא צריך דרך המיפוי הקיים של הטוען ומייעץ לליבה למשוך את הדפים האלה מראש; משתנה סביבה, SGLANG_QWEN4_PLE_FILE_PREFETCH, מכבה את ההמלצה אם ברצונך למדוד בלעדיה. כל שכבת PLE מקבלת אז שני חוצצים מוצמדים של 8,192 שורות — כ-1.25 MiB כל אחד ב-FP8 — ו-worker אחד. שורות נאספות לתוך חוצץ אחד בזמן שהאחר מועתק להתקן, כך שהאיסוף וההעברה חופפים במקום להתבצע באופן סדרתי. מזהי N-gram מחושבים כ-hash במארח ולא בהתקן. הרצת גרף חוזרת מקבלת קריאת הכנה לפני כל הרצה חוזרת, והחוט המשגר ממתין לשלב הקודם.
הפרט האחרון הזה הוא המחיר, וה-PR אומר זאת בפשטות: בערך 0.5 עד 1 אלפיות שנייה נוספות לכל שלב פענוח מעל הנתיב המוצמד. כל השאר הוא הרווח. נמדד על RTX PRO 6000 Blackwell בודד עם 96 GB, מארח AMD EPYC עם 377 GiB של זיכרון RAM, CUDA 13.2, תוך שימוש בנקודות הביקורת הציבוריות FP8 ו-NVFP4 של Qwen3.8-Flash-Next:
• מטמון דפים של המארח, FP8 TP4/EP4 — 71 GB נעוץ וללא הגבלה, לעומת 49 GB בתקרה של 64 GB, 15 GB ב-32 GB, ו-6 GB בתקרה של 24 GB
• השהיית פענוח, אותן הרצות — 8.62 ms לטוקן במקביליות 1 במצב מוצמד, לעומת 9.16 / 9.20 / 9.12 ms בשלוש הרצות הקובץ המוגבלות
• מקביליות 16 — 16.54 ms במצב מוצמד לעומת 17.62 / 17.85 / 17.37 ms במצב מוגבל, שהם ירידה מ-893 אסימונים לשנייה ל-827–840
• תפוקת Prefill — 620 טוקנים לשנייה ב-8k נעוצים לעומת 624 / 630 / 631 מוגבלים; ב-32k, 1,347 לעומת 1,358 / 1,359 / 1,361
• NVFP4 TP2 — 69 GB מוצמדים לעומת 24 GB עם מנגנון הקבצים בתקרה של 32 GB, ב-8.87 ms לעומת 9.18 ms
• NVFP4 על GPU בודד — 69 GB נעוץ לעומת 51 GB במגבלה של 64 GB, ב-6.44 ms לעומת 6.73 ms
• החלופה שהוא גובר עליה — קריאה של אותו קובץ דרך ניהול זיכרון המארח באותו GPU הניבה 10.8 ms ברמת מקביליות 1 ו-46.5 ms ברמת מקביליות 16, שה-PR מתאר כפי 2.8 מהשהיית ה-pinned באותה רמת מקביליות

צד הדיוק מדווח כתקין. פלט חמדני דטרמיניסטי על פני שמונה פרומפטים של 256 טוקנים היה זהה טוקן-בטוקן בין המסלול הנעוץ למסלול הקובץ ב-FP8 TP4, ו-GSM8K יצא 97.6% במסלול הנעוץ לעומת 98.0% במסלול הקובץ במגבלת 64 GB — פער של שש שאלות שהמחבר מייחס לשונות בין הרצות ולא למסלול ה-offload. כל המספרים האלה הם של מחבר ה-pull request עצמו, נמדדו פעם אחת, על מכונה אחת, ואף אחד לא שחזר אותם.
העלויות שה-PR מודה בהן
קריאה הוגנת של בקשת המשיכה הזו כוללת גם את מה שהיא מסרבת לעשות. כמה מצבי הרצה נדחים בזמן הבנייה במקום להיות מורדים בשקט, וכל דחייה מציינת את ה-backend המוצמד כמסלול נסיגה: גרפי CUDA של prefill, attention data-parallel, מסלול הריבוב prefill-decode, חפיפה של שתי אצוות, גרפי הפענוח של DLLM, וגרפי אימות ragged קומפקטיים — כולם בחוץ. לא פחות חשוב, היא לא מוסיפה דגל חדש ולא מתג חדש למשתמש — מסלול ה-staging הוא מה ש-backend הקבצים עושה בחומרה שפעם לא יכלה להשתמש בו בכלל. והרצת הדיוק נושאת הסתייגות שהמחבר מוסר ביוזמתו: ההרצות המוגבלות מעולם לא החזיקו את הטבלה כולה, משום שהטבלה היא 47.7 GiB והמגבלות יורדות עד 24 GB, כך שעומס עבודה עם דפוס גישה שטוח ובלתי צפוי באמת על פני כל הטבלה אינו מה שנמדד.
למה זה חשוב ספציפית ל-Qwen 4
הסר את פרטי המנוע והתבנית ניתנת לקריאה. אליבאבא שלחה תצוגה מקדימה של ארכיטקטורה ב-26 באוגוסט עם הוראות לקהילת הקוד הפתוח להכין סביבות ריצה, קוונטיזציה ומנועי הסקה לפני המשפחה המלאה. SGLang עשתה זאת, ואז בילתה שלושה שבועות בהגשת pull requests על הרכיב האחד שהופך את הארכיטקטורה למגושמת לפריסה. אם קוראים זאת כתחזית, זו הצהרה על מה ש-Qwen 4 ידרוש מהחומרה שלך, לא על מה שהוא יכול לעשות בבנצ'מרק.
זה גם מחדד את שאלת לוח הזמנים. Qwen 4 טרם שוחרר, וההשערות מספטמבר סביבו מצביעות על כנס Apsara של Alibaba ב-22–24 בספטמבר בהאנגג'ואו — המקום שבו הוכרזו הדורות הקודמים של Qwen. שום דבר מזה אינו מאושר, והדפוס ממחזור התצוגה המקדימה האחרון הוא שתצוגה מקדימה של ארכיטקטורה קודמת למשפחה המלאה בחודשים ולא בשבועות. פתיחת בקשת משיכה שלושה ימים לפני אותו כנס מרמזת ותו לא.
הסיכום הכנה של מה שזה אומר לקורא: Qwen 4 לא קיים, Qwen3.8-Flash-Next קיים, והשני אומר לך כמה יעלה לך להריץ את הראשון. אם טבלת 47.7 GiB ממשיכה להתכווץ בטביעת הרגל האפקטיבית שלה — ושלושה שבועות של בקשות משיכה אומרים שעובדים על זה קשה — אז רף הפריסה של משפחת Qwen 4 נמוך ממה ששבוע ההשקה של התצוגה המקדימה הציע.
מה אפשר למעשה לעשות עם זה היום
שום דבר ב-pull request הזה אינו זמין ב-main, והמודל שאליו הוא מכוון אינו משהו שאפשר לקרוא לו דרך API. ה-checkpoint Qwen3.8-Flash-Next עם המשקולות הפתוחות הוא סיפור של אירוח עצמי: אתה מושך את המשקולות, מגיש אותן בעצמך, ונתיב ה-PLE המגובה בקבצים הוא מה שאתה קורא עליו. הוא אינו מנותב כאן. מה שכןמנותב הוא גרסת הייצור — Qwen3.8-Flash, נגיש בתור qwen/qwen3.8-flash במחיר 0.15 דולר למיליון טוקני קלט ו-0.47 דולר למיליון טוקני פלט, עם חלון הקשר של מיליון טוקנים וקלט של טקסט, תמונה וווידאו — והגדול יותר, Qwen3.8-Max במחיר 2.00 ו-6.00 דולר.

ההבחנה הזו היא המועילה עבור קורא שמחליט מה לעשות השבוע. תצוגת ה-preview היא מחקר שאתה מריץ בעצמך; הווריאנט המוגש הוא נתיב הייצור של אותה ארכיטקטורה, והוא נמצא במרחק נקודת קצה אחת. OrcaRouter מעביר הלאה את מחיר המחירון של הספק ב-0% תוספתולכן שינוי מחיר מצד ספק בנקודת הקצה הזו יופיע באותו יום ולא במחזור החיוב הבא, וכל מודל במפתח נגיש דרך כתובת בסיס אחת תואמת OpenAI במקום חוזה, SDK ואישורים נפרדים לכל ספק. עבור ארכיטקטורה צעירה כל כך — שבה עבודת המנוע עדיין נוחתת מדי שבוע ומפת הדרכים טרם פורסמה — מעבר אוטומטי בין ספקים הוא הדרך המעשית להסתמך על הווריאנט המוגש בלי להמר את נתיב הייצור על זמן הפעילות של ספק בודד. כל זה נוגע למודלים שאפשר לקרוא להם היום. זה לא אומר דבר על Qwen 4, שאינו אחד מהם.
מה שאנחנו עדיין לא יודעים
האם Qwen 4 תשלח את אותה טבלה באותו גודל. האם ה-pull request ימוזג בכלל — יש לו שלוש הרצות CI כושלות ועדיין אין ביקורות. והאם הקנס של 0.5 עד 1 אלפית שנייה לכל צעד מחזיק מעמד מחוץ לקונפיגורציות בעלות המקביליות הנמוכה של המחבר. והאם Alibaba תאמר משהו ב-Apsara ב-22 בספטמבר. לפי העדויות הנוכחיות, הדבר הבטוח ביותר להסיק לגבי Qwen 4 הוא לא מה הציונים שלו, אלא כמה מכונות התעשייה בונה רק כדי להתאימו — וזה כשלעצמו דבר שימושי לדעת לפני שלמודל יש שם בקטלוג כלשהו.
השוואות במאמר הזה1
זוהה מתוך המאמר הזה · בנצ'מרקים: Artificial Analysis · מתעדכן יומית
