כרטיס כותרת הירו עם הכיתוב 'Qwen4-Exp QSA מגיע ל-Ascend של Huawei' מתחת לתג 'לא מאומת — PR טיוטה, לא ממוזג', עם כותרת המשנה 'בתוך SGLang PR #41855 — נתיב ה-prefill האופציונלי של CANN', שלושה צ'יפים עם הכיתוב 'נפתח ב-2026-09-30', 'דגל כבוי כברירת מחדל' ו-'Ascend 910C / CANN 9.0', ושורת כותרת תחתונה עם הכיתוב 'נתונים שדווחו על ידי תורמים; לא שוחזרו באופן עצמאי.' הלוגו של OrcaRouter משולב בפינה הימנית התחתונה.
Guides & Insights

Qwen4-Exp QSA מגיע ל-Ascend של Huawei: מבט פנימה אל ה-PR של prefill ב-CANN בהצטרפות מרצון ב-SGLang

מחבר

Alistair Wren

תאריך פרסום

מודלים אחרונים · 20צפו בכל המודלים →
בנצ'מרקים: Artificial Analysis · מתעדכן יומית
חזרה לכל הפוסטים

ב-30 בספטמבר 2026, תורם פתח את בקשת המשיכה #41855 של SGLang, שכותרתה „[NPU] הוספת תשומת־לב דלילה של CANN אופציונלית עבור prefill של QSA ב-Qwen4-Exp,” והחלק המעניין אינו האריתמטיקה. זה החומרה. לארכיטקטורת Qwen4Exp יש כעת נתיב תשומת־לב דליל שנכתב ביד עבור מאיץ Ascend 910C של Huawei, מאחורי דגל שכבוי כברירת מחדל, בבקשת משיכה בטיוטה שטרם מוזגה — בעוד שהמודל שאליו שייך שם הארכיטקטורה, Qwen4-Exp, מעולם לא פורסם בשום צורה. הצ'קפוינט היחיד שנושא את הארכיטקטורה הזו במשקלים פתוחים הוא עדיין Qwen3.8-Flash-Next, תצוגה מקדימה מסוג mixture-of-experts בת 125 מיליארד פרמטרים, שהספק פרסם ב-Hugging Face ב-24 באוגוסט 2026, ואשר הכרטיס שלה למעשה מצהיר שהארכיטקטורה שלה היא qwen4_exp. Qwen 4 עצמו — דרגות Max, Flash, Plus ו-27B שהספק ציין בכנס Apsara שלו ב-22 בספטמבר 2026 — עדיין אין לו משקלים, אין מזהה, אין מחיר ואין תאריך. אז זהו מאמר של מה־שידוע־עד־כה על חפץ הנדסי, לא השקה: עוד מחסנית שירות של ספק שמחליטה בשקט שארכיטקטורה שטרם שוחררה שווה תמיכה מוקדמת.

מה שבקשת המשיכה בעצם מוסיפה

השינוי הוא בכוונה קטן ובכוונה צר. חמישה קבצים, קומיט אחד, +355 שורות מול ענף ראשי בקומיט b87a241, נושא את SGLang npu תווית. המחבר, w1ida, מציין את הכוונה מראש: נתיב CANN main-attention אופציונלי עבור Qwen4-Exp QSA eager prefill, הבנוי על torch_npu.npu_sparse_flash_attention, כאשר האינדקסר, בחירת ה-Top-K, תקציב הטוקנים ותוכן ה-KV-cache כולם נשארו בדיוק כפי שהיו.

הטריק שהוא משתמש בו כדי להגיע לשם שווה פסקה אחת, כי הוא מסביר למה זה מתאם פריסה ולא קרנל קשב חדש. עבור Q ו-K שכבר מסובבים, המסלול אורז את המטמון כ-C = [K, V] ואת השאילתה כ-Q' = [Q, 0]. המכפלה Q' @ C.T אז שווה ל-Q @ K.T, ומכיוון שהשאילתה המרופדת לא תורמת דבר, softmax(scale * Q' @ C.T) @ C מחזיר [P @ K, P @ V] מוערמים — כך שאפשר לחתוך החוצה את חצי ה-V. במילותיו של המחבר עצמו, זה “הטמעת פריסת קשב, לא שינוי בקשב של המודל או דחיסת KV בדרגה נמוכה.” כל ראש KV הופך לאצווה עצמאית בפריסת ה-MLA המקורית, קנה המידה המקורי D256 נשמר, ו-RoPE העזר מאופס.

הפרטים התפעוליים חשובים באותה מידה כמו המתמטיקה:

• הפעלה — SGLANG_NPU_QSA_NATIVE_PREFILL=1, ברירת מחדל כבוי. רק ה-ForwardMode.EXTEND הרגיל מצטרף; פענוח, מצבים ספקולטיביים, forward מעורב ולכידת גרף נשארים כולם בנתיבים הקיימים, ולכידת גרף עוקפת את המתאם לחלוטין.

• חומרה ו-dtype — BF16 עם מימד ראש 256, Ascend 910C (Ascend910_93*), נבדק מול CANN 9.0 ו-torch-npu 2.10. כל dtype או shape לא נתמכים נופלים בשקט לנתיב הייחוס.

• צורות ראש — הנתמכים המקומיים, (ראשי Q, ראשי KV) הזוגות הם (16,2), (24,2), (12,1), (6,1) ו-(3,1). CANN דוחה לחלוטין יחס query/KV של 12 — ה-tiler שלה מקבל רק חזקות של שתיים — לכן הראשים מרופדים 12→16, 6→8 או 3→4 והפלטים הנוספים נזרקים. זה הסימן הברור ביותר בכל ה-PR שהחומרה לא תוכננה עם יחסי ראשים של sparse-attention בחשבון, והמתאם סופג את אי-ההתאמה הזו במקום שהמודל ישנה צורה עבורה.

• גבולות גודל — רק תחום ה-cache הפיזי הנזכר נארז, במוגבל ל-262,144 טוקנים, שאותם המחבר מחשב לכל היותר 512 MiB עבור טנסור ה-K/V הארוז מסוג BF16 בשני ראשי KV.-1 ריפוד פנימי מזוהה ומופנה אל מנגנון ה-fallback, מכיוון ש-CANN דורש משבצות תקפות רצופות; שורות מוסתרות במלואן שומרות על מוסכמת פלט האפס הקיימת.

• מדוע prefill בלבד — בדיקת ההיקף והפריסה מעתיקה שני סקלרים למארח, וההעתקים הזמניים יחד עם מרחב העבודה הנייטיבי גובים זיכרון. הסנכרון הזה הוא הסיבה שהנתיב מוגבל ל-prefill מסוג eager ונשמר כבוי במהלך לכידה.

A capture of the SGLang GitHub pull request #41855, titled '[NPU] Add opt-in CANN sparse attention for Qwen4-Exp QSA prefill', showing an Open state with no merged marker, the line 'w1ida wants to merge 1 commit into main from npu/qsa-cann-prefill', the npu label, and the start of the Motivation section describing the Q' = [Q, 0] and C = [K, V] packing and stating that the approach avoids modifying the indexer, Top-K selection, or KV-cache layout.

תשע בדיקות שעברו, ומספר מהירות שלא הגיע מהענף הזה

ראיות הנכונות ספציפיות וניתנות לשחזור, וזה יותר ממה שרוב בקשות ה-PR של קרנל מציעות. המחבר מדווח על 9 בדיקות שעוברות תוך 40.772 שניות על Ascend 910C (Ascend910_9362) עם CANN 9.0 ו-torch-npu 2.10.0, ללא צורך בצ'קפוינט: Q/K/V אקראיים שאינם אפס ב-BF16 מול ייחוס FP32 ב-CPU המחושב מאותם קלטי BF16, חריצים פיזיים לא מסודרים ברוחבים 1/63/64/65/2051, סקאלות ברירת מחדל ומפורשות, שורות ממוסכות במלואן, שורות אפס, רוחב בחירה אפס, טנסורים לא רציפים, שאריות זנב סיבתיות ביחס דחיסה 4 מ-0 עד 3, מיפוי פיזי של שתי בקשות עם קידומת משותפת, שימוש חוזר בתוכן המטמון, וצורות ראש מקומיות של Flash-Next ב-1 ו-257 שורות שאילתה.

מקרה הדגל הוא prefill ארוך: 7,810 טוקנים של שאילתה מול מטמון של 65,536 טוקנים עם 2,051 חריצים נבחרים לכל שאילתה, כל הפלטים סופיים, עם שמונה שורות שנדגמו שהושוו לרפרנס FP32. שגיאת L2 יחסית שנצפתה הגיעה ל-0.209% במקרי צורת הראש הקטנים ול-0.231% בשורות ה-prefill הארוך שנדגמו, מול ספי בדיקה של atol=0.025, rtol=0.025 ו-L2 יחסי מתחת ל-0.008, כאשר שורות ריקות נדרשות להיות אפס בדיוק. שיא הזיכרון המוקצה ל-NPU עבור אותה הרצה מצוין כ-1,042.7 MiB — והמחבר מתייג אותו כמדד ה-allocator של PyTorch, לא HBM של הלוח ולא זיכרון המודל המלא, וזו בדיוק ההסתייגות הנכונה לצרף.

ואז יש את המספר שיצוטט ולא צריך. גוף ה-PR כולל טבלת מהירות שמציגה את נתיב הקשב המקומי הקיים ב-2,270.79 טוקנים חדשים לשנייה ואת הקשב הראשי הארוז הנייטיבי ב-3,890.06 — שיפור של פי 1.713 / +71.3%, כאשר הזמן הממוצע לטוקן ראשון יורד מ-3.109 שניות ל-1.812 שניות. המחבר מבהיר במפורש שאלה מדידות אב-טיפוס היסטוריות שנלקחו ב-2026-09-29 על מותאם Whittle-Next-26B-A3B צ'קפוינט, שהורץ ב-TP1 עם משקולות W8A8 וקשב BF16 על 910C תחת CANN 9.0, תוך שימוש בכלי הרשמי sglang.bench_serving לבדיקת ביצועים ברמת מקביליות 1 עם שש בקשות, טוקן פלט אחד כל אחת, ו-36,096 טוקני קידומת במטמון שהודרו מתפוקת הטוקנים החדשים. הם לא בנצ'מרק של ענף ה-upstream ב-PR, ארטיפקטי ה-JSON המקוריים של serving אינם נמצאים ב-checkout, ותוצאות מקומיות מאוחרות יותר בסביבות 5,000 טוקנים לשנייה השתמשו בעבודה נוספת על אינדקסר נייטיבי ו-block4 שאינה מיוחסת במפורש לשינוי הזה. המחבר גם מציין שמשקולות האינדקסר של הצ'קפוינט המותאם הן אינרטיות והתקציב שלו שונה מהמקורי, כך ששום דבר מזה אינו ראיה לנכונות האינדקסר או לאיכות יצירה בתקציב מלא.

הבהרה אחת לגבי שמות, מכיוון שהיא תתבלבל כל מי שיחפש את הצ'קפוינט: מודל הבנצ'מרק הוא ארטיפקט מותאם של התורם עצמו. לחוד מכך, "Whittle-Next" הוא גם שמה של סדרה ציבורית של כיוונונים עדינים מבוססי Qwen3.8 מסוג MoE, שפורסמה על ידי חשבון Hugging Face של צד שלישי, כולל וריאנט 26B-A3B שהועלה בספטמבר. אלה אינם מודל Qwen4Exp שאליו מכוון ה-PR הזה, ואין לקרוא אותם כקונפיגורציית הבנצ'מרק שמאחורי הנתון 1.713×.

שתי הסתייגויות נוספות מגיעות מהמחבר ולא ממני. אינטגרציית סרווינג מלאה, מקביליות טנזורית מבוזרת והמודל המלא Qwen3.8-Flash-Next לא אומתו בענף הזה; התורם אומר שהשארת זה כטיוטה בזמן שנדונה שאלת האינטגרציה והתלות היא מכוונת, ואף שואל בגוף ה-PR אם המתאם שייך ל-SGLang או ל-sgl-kernel-npu — הריפוזיטורי הנפרד. גם ה-CI אינו נקי — בלוק מצב גוף ה-PR מציג כשלים ב-PR Test (Base), PR Test (Extra) ובהרצת AMD ROCm 10. הנכונות שתוארה לעיל היא ברמת האופרטור; אין ב-PR שום טענה לתוצאת דיוק או תפוקה מקצה לקצה בסטאק המשולב.

למה QSA הוא החלק המסורבל, במספרים

Qwen Sparse Attention אינו שכבת קשב קונבנציונלית, והתצורה שפורסמה מראה מדוע ספק מאיצים נדרש לכתוב עבורו מסלול ייעודי. מתוך התצורה של Qwen3.8-Flash-Next: 48 שכבות הפרושות כשנים-עשר חזרות של שלושה בלוקי Gated DeltaNet ואחריהם בלוק קשב מלא אחד, full_attention_interval 4, גודל נסתר 2,560, ממד ראש קשב 256, 24 ראשי שאילתה מול 2 ראשי KV, ממד RoPE 64. האינדקסר שהופך את הקשב לדליל הוא מבנה מרובה-שאילתות שבו 4 ראשי שאילתה חולקים ראש מפתח אחד, ממד ראש 128, יחס דחיסה של 4 ותקציב של 2,048 מיקרו-בלוקים נבחרים לכל שאילתה.

התקציב הזה הוא מה ש־PR משאיר קבוע. גודל הבלוק הדליל נשאר 1, המצב הדליל נשאר 0, מצב הקשב נשאר 2, וממשק האסימונים הנבחרים לא משתנה; אופטימיזציות של native indexer ו־block4 נמצאות במפורש מחוץ לתחום. כלומר, זהו מתאם שמוברג מתחת למנגנון בחירה קיים, ולא מימוש מחדש של QSA — וזו גם הסיבה לכך שהמחבר יכול לטעון באופן מהימן שתוכן ה־KV-cache לא השתנה.

A two-column scoreboard titled 'Qwen4-Exp QSA on Ascend — what was measured where'. The left column, headed 'Correctness (this branch)', reads: Suite 9 unit tests, Runtime 40.772 s, Reference FP32 CPU, Long prefill 7,810 query tokens, Relative L2 error up to 0.231%, Model needed none. The right column, headed 'Speed (historical prototype)', reads: Suite sglang.bench_serving, Tokens/s 2,270.79 to 3,890.06, Reported gain 1.713x, Mean TTFT 3.109 s to 1.812 s, Checkpoint adapted 26B-A3B, Model card not on this branch. A footer line reads that both columns are contributor-reported in SGLang PR #41855 and unaudited, and that the speed arm is a 2026-09-29 prototype, not this branch. The OrcaRouter logo is composited in the bottom-right corner.

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

היכן זה משתלב בבניית מערך השירות של Qwen4Exp

כשמסתכלים עליו לבדו, PR טיוטה אחד על מאיץ אחד הוא קוריוז. כשמסתכלים עליו על רקע שאר ספטמבר, הוא הקרש הרביעי או החמישי בפלטפורמה שנבנית בפומבי לפני שהמשפחה שאותה היא משרתת קיימת:

• הארכיטקטורה במשקולות פתוחות — Qwen3.8-Flash-Next, 2026-08-24, MoE בעלת 125B פרמטרים עם 6B פעילים, טבלת הטמעת n-gram בת 51 מיליארד פרמטרים וראש MTP של 4B, הנושאת model_type: qwen4_exp וארכיטקטורות Qwen4ExpForConditionalGeneration.

• הצד של vLLM — #53909, ה-PR ‏"qwen4 fuse op" שמוסיף קרנלים של HyperConnection, QSA ו-PLE, עדיין פתוח ולא מוזג מאז 2026-08-26; #59279, שמוסיף decode context parallelism לאותו מסלול QSA, טיוטה שנפתחה ב-2026-09-29; ועבודת ה-offload של PLE שנחתה לאורך ספטמבר.

• בצד של SGLang — #38642 עבור לכידת מצב חבוי של DFlash, #39548 עבור פריקת PLE ל-CPU ב-Ascend, #40235 שמוסיף host staging עבור טבלת PLE מגובת קובץ, וכעת #41855 עבור נתיב הקשב של Ascend.

• שורת הפעלת ה-NPU — sglang #37570, שמוסיפה את Qwen3.8-Flash-Next ל-SGLang על NPU עם graph replay, MTP ו-Triton kernels (נפתח ב-2026-09-02, עדיין פתוח, +2,590 שורות ב-20 קבצים), ו-sgl-kernel-npu #807 עבור Triton kernels הנלווים (נפתח ב-2026-09-17, +4,643 שורות). שניהם מגיעים מאותו תורם. #41855 היא שכבת ה-attention שנמצאת בתוך מאמץ ההפעלה הגדול יותר הזה.

שתי תצפיות שהקורא יכול לפעול לפיהן. ראשית, כל סיפור Ascend Qwen4Exp נשען על מספר קטן מאוד של תורמים — ה-PRs של ה-enablement ומאגר ה-kernel חולקים מחבר אחד, ומתאם ה-attention הוא מחבר אחר. הריכוז הזה הוא אומדן הוגן עד כמה שירות Ascend Qwen4Exp רחוק מלהיות נתיב מוצר נתמך ולא ניסוי. שנית, צוואר הבקבוק של ה-kernel אינו ספציפי לספק: שני issues של SGLang שהוגשו ב-2026-08-28 מתעדים פענוח Qwen4Exp על NVIDIA DGX Spark, שבו זמן הקרנל של QSA, PLE ו-Gated DeltaNet שולט, ושבו נמדד מטמון KV מסוג NVFP4 כפוגע בפענוח בכ-29% לעומת fp8_e4m3. שכבות ה-attention וה-embedding בארכיטקטורה הזו הן החלק הקשה בכל מקום.

מה זה לא אומר

זה לא אומר ש-Qwen 4 יצא, או קרוב לכך. משפחת Qwen 4 ש-Alibaba נתנה לה שם ב-2026-09-22 — Max, Flash, Plus ודרגת 27B — נשארת בגדר מפת דרכים בלי כרטיס מודל, בלי משקלים, בלי מזהה API, בלי חלון הקשר, בלי רישיון ובלי מחיר. מתאם פריימוורק שמכוון לשם הארכיטקטורה הפנימי הוא צעד לקראת הגשה טובה של המשפחה הזו יום אחד; הוא אינו צעד לקראת קיומה של המשפחה.

זה לא אומר שאפשר להריץ את זה היום. ה-PR הוא טיוטה עם CI שנכשל ואין תאריך מיזוג. גם אם ימוזג, המסלול דורש Ascend 910C, BF16, CANN 9.0 עם torch-npu 2.10, ואחת מחמש צורות ראש מקומיות ספציפיות, והוא אופט-אין — כלומר פריסה צריכה לבחור בו. המחבר גם סירב לטעון לאימות ברמת השרת, שזה החלק שלמעשה יגיד לך אם הוא מחזיק מעמד תחת אצווה אמיתית.

וזה לא אומר ש-Qwen3.8-Flash-Next הוא מוצר נתמך על Ascend, או בכל מקום אחר במהדורת מנוע שנשלחת למשתמשים. נתיבי Qwen4Exp בשני הסביבות-הרצה הפתוחות העיקריות הם בקשות-משיכה (pull requests) שלא מוזגו. אין גרסה משוחררת של SGLang או vLLM שאפשר להתקין שמשרתת את הארכיטקטורה הזו באופן מובנה — הנוחות בסגנון FastAPI של נקודת-קצה מתארחת היא דבר אחר מקרנל שאפשר להריץ בעצמך, והפער ביניהם הוא בדיוק מה שבקשות-משיכה כמו זו נועדו למלא.

מה שאפשר למעשה להתקשר אליו בזמן ההמתנה

אם הסיבה שאכפת לך מ-Qwen4Exp היא שאתה רוצה לבחון את התנהגות ההקשר הארוך של הארכיטקטורה ולא את פנימיות הקרנל שלה, המודל שאליו כדאי לפנות הוא השכבה שאליבאבא באמת מספקת. Qwen3.8-Flash — קו הייצור הבנוי על Qwen3.8-Flash-Next, עם כלים מובנים רשמיים והקשר של 1,000,000 טוקנים — זמין כעת ב-OrcaRouter בתור qwen/qwen3.8-flash: קלט טקסט, תמונה ווידאו, פלט מרבי של 131,072 טוקנים, 0.15$ למיליון טוקני קלט ו-0.47$ למיליון טוקני פלט, עם קריאות מטמון ב-0.0184$. אלה מחירי מחירון של הספק המועברים הלאה עם 0% תוספת מצידנו, כך ששינוי מחיר או מגבלה של הספק מגיע אליך באותו יום שבו הוא מוכרז. בחלון שבעת הימים האחרון הכרטיס החי מציג השהיית טוקן ראשון p50 של 4,416 מ״ש, כ-106 טוקני פלט בשנייה ושיעור שגיאות של 2.68% — הפרופיל של שכבת טקסט בנפח גבוה ולא של תצוגה מקדימה מהמעבדה.

שתי הסתייגויות כנות, ואלו הן אותן שתי הסתייגויות שנושאות איתן הכתיבות האחיות על הארכיטקטורה הזו. Qwen3.8-Flash-Next עצמו — ה-checkpoint המקדים ב-FP8, הדבר שהייתם זקוקים לו כדי לשחזר כל אחת ממדידות ה-kernel האלה באופן מקומי — אינו נמצא בקטלוג שלנו; שכבת ה-Flash המוגשת היא פריסת הייצור שנבנתה ממנו, ולא חפץ התצוגה המקדימה הגולמי. ואף לא אחת מעבודות ה-Ascend או ה-DCP שתוארו לעיל קיימת בשום דבר שאפשר לקרוא לו, משום ששום חלק מהן לא מוזג. מה ששכבת השירות כן נותנת לכם הוא דרך זולה לגלות אם עומס העבודה שלכם מעוצב לבעיה שה-kernels האלה פותרים — פרומפטים ארוכים, עתירי prefix ואג'נטיים מול הקשר ארוך מאוד. אם כן, התפוקה והתנהגות ה-cache שאתם רואים שם הם אותה התנהגות שסטאק השירות של Qwen 4 יכויל כדי להגן עליה.

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

A capture of the OrcaRouter model page for Qwen: Qwen3.8 Flash (qwen/qwen3.8-flash), showing the Qwen provider, a release date of 2026-08-26, the Quick Facts tags General Chat and High Volume, an independent-provider throughput of 106.2 output tok/s and 4,416 ms first-token latency, pricing of $0.23 cache write, $0.0184 cache read, $0.15 input and $0.47 output per 1M tokens, a PERFORMANCE panel for the seven-day window Sep 23 to Sep 30 2026 reading throughput 106.2 tok/s, first-token latency 4.4 s and error rate 3.9%, a traffic chart reading 2.57B tokens last 7 days with +6.9% versus the earlier half, a 0% markup note, and a vendor rate card cross-check block crediting Qwen Cloud, published 2026-08-26 and last checked 2026-09-30 12:08 UTC.

שלוש שאלות ששווה לענות עליהן ישירות

האם SGLang #41855 אומר ש-Qwen 4 יצא, או שניתן לתצוגה מקדימה?

לא, בשני המובנים. בקשת המשיכה (pull request) מכוונת לארכיטקטורת Qwen4Exp כפי שיושמה ב-Qwen3.8-Flash-Next, שאליבאבא השיקה ב-24 באוגוסט 2026. היא אינה נוגעת במשקולות של Qwen 4, ולאף דרג של Qwen 4 אין משקולות שאפשר לגעת בהן. האות שיש לקרוא כאן עוסק בקיבולת שירות לארכיטקטורת תצוגה מקדימה, ולא בזמינות של המשפחה.

אם כרטיס מודל אומר qwen4_exp, האם זה Qwen 4?

לא — וזו מלכודת השמות בכל הסיפור. qwen4_exp הוא מזהה הארכיטקטורה הפנימי, והוא מה שתמצאו ב-config.json עבור Qwen3.8-Flash-Next ואחיו ה-FP8. "ארכיטקטורה ניסיונית" היא המילה הקובעת: המשקלים מפורסמים, הארכיטקטורה אמיתית, והמודל הוא תצוגה מקדימה של מה שמשפחת Qwen 4 צפויה להתבסס עליו. חיפוש המזהה ומציאת PR של SGLang או vLLM עם Qwen4Exp בכותרת מספר לך על עבודת מנוע, לא על שחרור.

האם זה סיפור של Ascend מול NVIDIA?

לא ממש. גם בצד של NVIDIA אותו מסלול attention נזקק ל-adapter ייעודי — decode context parallelism עבור QSA ב-vLLM, ו-kernel prefill דליל מקורי עבור Hopper — והבעיות של DGX Spark מראות שגם שם זמן ה-kernel של QSA, PLE ו-Gated DeltaNet שולט ב-decode. ה-micro-block indexer של QSA ומצב ה-selector המשוכפל שלו פשוט אינם מה ש-kernels גנריים של paged-attention מניחים. התרומה של Ascend לתבנית היא האילוץ החדה יותר: head-ratio tiler שמקבל רק חזקות של שתיים, מה שמאלץ את ה-padding שה-adapter צריך להסתיר.

הדבר שכדאי לשים לב אליו

לא השאלה אם זה ימוזג. המתאם כן לגבי היותו מתאם, מבחני הנכונות ניתנים לשחזור בלי צ'קפוינט, והמחבר סימן את שאלת האינטגרציה במקום להעמיד פנים שהיא סגורה. הדבר שכדאי לעקוב אחריו הוא מה יקרה לאחר ששורת האפשור של NPU ונתיב הקשב הזה ישולבו — האם הענף המשולב יקבל את ההרצה מקצה לקצה שאף אחד מהם לא קיבל, על באצ'ים אמיתיים עם המודל המלא במקום על טנסורים מקומיים של צורת ראש. הנתון של 1.713× הוא זה שיסתובב, והוא זה שחושב על בילד שונה, על צ'קפוינט מותאם, עם אינדקסר לא פעיל. מספר נמדד על הסטאק המוגמר יהיה בעל ערך רב בהרבה מנתון היסטורי.

עד אז, הסיכום הכנה הוא זה שה־PR עצמו דבק בו: החשבון מסתדר, הדגל כבוי כברירת מחדל, ה־CI אדום, והמודל שבכותרת עדיין אינו קיים.