Qwen4-Exp QSA kommt zu Huaweis Ascend: Ein Blick in SGLangs Opt-in-CANN-Prefill-PR

Am 30.09.2026 eröffnete ein Mitwirkender den SGLang-Pull-Request #41855 mit dem Titel „[NPU] Opt-in-CANN-Sparse-Attention für Qwen4-Exp QSA-Prefill hinzufügen“, und das Interessante daran ist nicht die Arithmetik. Es ist die Hardware. Die Qwen4Exp-Architektur verfügt jetzt über einen handgeschriebenen Sparse-Attention-Pfad für Huaweis Ascend-910C-Beschleuniger, hinter einem Flag, das standardmäßig deaktiviert ist, in einem Entwurfs-Pull-Request, der noch nicht zusammengeführt wurde — während das Modell, zu dem dieser Architekturname gehört, Qwen4-Exp, noch nie in irgendeiner Form veröffentlicht wurde. Der eine Checkpoint, der diese Architektur in offenen Gewichten trägt, ist weiterhin Qwen3.8-Flash-Next, die 125-Milliarden-Parameter-Mixture-of-Experts-Vorschau, die der Anbieter am 24.08.2026 auf Hugging Face veröffentlichte und deren Karte ihre Architektur tatsächlich als qwen4_exp deklariert. Qwen 4 selbst — die Max-, Flash-, Plus- und 27B-Stufen, die der Anbieter auf seiner Apsara-Konferenz am 22.09.2026 nannte — hat noch immer keine Gewichte, keine Kennung, keinen Preis und kein Datum. Das ist also ein Beitrag zum bisherigen Wissensstand über ein Engineering-Artefakt, nicht über einen Launch: ein weiterer Serving-Stack eines Anbieters, der still und leise entscheidet, dass eine unveröffentlichte Architektur es wert ist, früh unterstützt zu werden.

Was der Pull Request tatsächlich hinzufügt

Die Änderung ist bewusst klein und bewusst eng gefasst. Fünf Dateien, ein Commit, +355 Zeilen gegenüber einem Main-Branch bei Commit b87a241, mit dem SGLang-npu-Label. Der Autor, w1ida, erklärt vorab die Absicht: einen Opt-in-CANN-Main-Attention-Pfad für Qwen4-Exp QSA Eager-Prefill, aufgebaut auf torch_npu.npu_sparse_flash_attention, wobei der Indexer, die Top-K-Auswahl, das Token-Budget und der KV-Cache-Inhalt genau so belassen wurden, wie sie waren.

Der Trick, mit dem es dorthin gelangt, ist einen Absatz wert, denn er erklärt, warum dies ein Layout-Adapter und kein neuer Attention-Kernel ist. Für bereits rotierte Q und K packt der Pfad den Cache als C = [K, V] und die Query als Q' = [Q, 0]. Das Produkt Q' @ C.T entspricht dann Q @ K.T, und da die gepolsterte Query nichts beiträgt, softmax(scale * Q' @ C.T) @ C liefert [P @ K, P @ V] gestapelt — sodass die V-Hälfte herausgeschnitten werden kann. Mit den Worten des Autors ist dies „ein Attention-Layout-Embedding, keine Änderung an der Attention des Modells und keine Low-Rank-KV-Kompression.“ Jeder KV-Head wird im nativen MLA-Layout zu einem unabhängigen Batch, die ursprüngliche D256-Skalierung bleibt erhalten, und das Hilfs-RoPE wird auf null gesetzt.

Die operationellen Details sind genauso wichtig wie die Mathematik:

• Aktivierung — SGLANG_NPU_QSA_NATIVE_PREFILL=1, standardmäßig aus. Nur gewöhnliches ForwardMode.EXTEND aktiviert dies; Decode, spekulative Modi, gemischtes Forward und Graph Capture bleiben alle auf den bestehenden Pfaden, und Graph Capture umgeht den Adapter vollständig.

• Hardware und dtype — BF16 mit Head-Dimension 256, Ascend 910C (Ascend910_93*), getestet mit CANN 9.0 und torch-npu 2.10. Jeder nicht unterstützte dtype oder Shape fällt stillschweigend auf den Referenzpfad zurück.

• Head-Formen — unterstützte lokale (Q-Heads, KV-Heads)-Paare sind (16,2), (24,2), (12,1), (6,1) und (3,1). CANN lehnt ein Query/KV-Verhältnis von 12 rundheraus ab — sein Tiler akzeptiert nur Zweierpotenzen —, daher werden Heads von 12→16, 6→8 oder 3→4 gepaddet und die zusätzlichen Ausgaben verworfen. Dies ist das deutlichste Zeichen im gesamten PR dafür, dass die Hardware nicht mit Blick auf Head-Verhältnisse für Sparse Attention entworfen wurde, und der Adapter absorbiert diese Diskrepanz, statt dass das Modell dafür seine Form ändert.

• Größenbeschränkungen — nur der referenzierte physische Cache-Bereich wird gepackt, begrenzt auf 262.144 Token, was der Autor als höchstens 512 MiB für den gepackten BF16-K/V-Tensor bei zwei KV-Heads berechnet. Inneres -1-Padding wird erkannt und an den Fallback weitergeleitet, weil CANN zusammenhängende gültige Slots erfordert; vollständig maskierte Zeilen behalten die bestehende Zero-Output-Konvention.

• Warum nur Prefill – die Extent- und Layout-Prüfung kopiert zwei Skalare auf den Host, und die temporären Kopien zusammen mit dem nativen Workspace kosten Speicher. Diese Synchronisation ist der Grund, warum der Pfad auf Eager-Prefill beschränkt und während des Captures deaktiviert bleibt.

Neun bestandene Tests und eine Geschwindigkeitszahl, die nicht aus diesem Branch stammte.

Die Korrektheitsnachweise sind konkret und reproduzierbar, was mehr ist, als die meisten Kernel-PRs bieten. Der Autor berichtet von 9 Tests, die in 40,772 Sekunden auf einem Ascend 910C (Ascend910_9362) mit CANN 9.0 und torch-npu 2.10.0 bestehen und ohne Checkpoint auskommen: von Null verschiedene zufällige BF16-Q/K/V gegen eine FP32-CPU-Referenz, die aus denselben BF16-Eingaben berechnet wurde, ungeordnete physische Slots bei den Breiten 1/63/64/65/2051, Standard- und explizite Skalen, vollständig maskierte Zeilen, Nullzeilen, Auswahlbreite null, nicht zusammenhängende Tensoren, kausale Tail-Restlängen von 0 bis 3 bei Kompressionsverhältnis 4, physisches Mapping für zwei Anfragen mit gemeinsamem Präfix, Wiederverwendung von Cache-Inhalten und die lokalen Head-Formen von Flash-Next bei 1 und 257 Query-Zeilen.

Der wichtigste Fall ist ein langes Prefill: 7.810 Query-Tokens gegen einen Cache mit 65.536 Tokens bei 2.051 ausgewählten Slots pro Query, alle Ausgaben endlich, wobei acht gesampelte Zeilen mit der FP32-Referenz verglichen wurden. Der beobachtete relative L2-Fehler erreichte 0,209 % bei den kleinen Head-Shape-Fällen und 0,231 % bei den gesampelten Long-Prefill-Zeilen, gegenüber Testschwellen von atol=0.025, rtol=0.025 und relativer L2 unter 0,008, wobei leere Zeilen exakt null sein müssen. Die Spitzenmenge des zugewiesenen NPU-Speichers für diesen Lauf wird mit 1.042,7 MiB angegeben – und der Autor bezeichnet sie als PyTorch-Allocator-Metrik, nicht als Board-HBM und nicht als Speicher des Gesamtmodells, was genau der richtige Vorbehalt ist, der anzubringen ist.

Dann gibt es da noch diese Zahl, die zitiert werden wird, obwohl sie es nicht sollte. Der PR-Text enthält eine Geschwindigkeitstabelle, die den bestehenden lokalen Attention-Pfad mit 2.270,79 neuen Tokens pro Sekunde und die native gepackte Haupt-Attention mit 3.890,06 zeigt – ein Zugewinn von 1,713× / +71,3 %, wobei die mittlere Zeit bis zum ersten Token von 3,109 s auf 1,812 s fällt. Der Autor stellt ausdrücklich klar, dass dies historische Prototypenmessungen vom 29.09.2026 auf einem angepassten Whittle-Next-26B-A3B-Checkpoint sind, ausgeführt bei TP1 mit W8A8-Gewichten und BF16-Attention auf 910C unter CANN 9.0, unter Verwendung der offiziellen sglang.bench_serving-Harness bei Nebenläufigkeit 1 mit sechs Anfragen, je einem Ausgabe-Token, und 36.096 zwischengespeicherten Präfix-Tokens, die vom Neu-Token-Durchsatz ausgeschlossen wurden. Dabei handelt es sich nicht um einen Benchmark des Upstream-Branches im PR, die ursprünglichen Serving-JSON-Artefakte sind im Checkout nicht vorhanden, und spätere lokale Ergebnisse von rund 5.000 Tokens pro Sekunde beruhten auf zusätzlicher nativer Indexer- und block4-Arbeit, die dieser Änderung ausdrücklich nicht zugeschrieben wird. Der Autor merkt außerdem an, dass die Indexer-Gewichte des angepassten Checkpoints inert sind und sein Budget vom Original abweicht, sodass nichts davon ein Beleg für die Korrektheit des Indexers oder die Generierungsqualität bei vollem Budget ist.

Eine Klarstellung zur Namensgebung, da sie jeden stolpern lässt, der nach dem Checkpoint sucht: Das Benchmark-Modell ist das eigene angepasste Artefakt des Mitwirkenden. Davon getrennt ist „Whittle-Next“ auch der Name einer öffentlichen Serie von MoE-Fine-Tunes, die von Qwen3.8 abgeleitet sind und von einem Hugging-Face-Konto eines Drittanbieters veröffentlicht wurden, einschließlich einer im September hochgeladenen 26B-A3B-Variante. Dabei handelt es sich nicht um das Qwen4Exp-Modell, auf das dieser PR abzielt, und sie sollten nicht als die Benchmark-Konfiguration hinter dieser 1,713×-Zahl gelesen werden.

Zwei weitere Vorbehalte stammen vom Autor, nicht von mir. Die vollständige Serving-Integration, verteilter Tensor-Parallelismus und das komplette Modell Qwen3.8-Flash-Next wurden auf diesem Branch nicht validiert; der Mitwirkende sagt, es sei beabsichtigt, es als Draft zu belassen, während die Integrations- und Abhängigkeitsfrage diskutiert wird, und fragt im PR-Text sogar, ob der Adapter zu SGLang oder in das separate sgl-kernel-npu-Repository gehört. CI ist ebenfalls nicht sauber – der Statusblock im PR-Text zeigt Fehler bei PR Test (Base), PR Test (Extra) und beim AMD-ROCm-10-Lauf. Die oben beschriebene Korrektheit ist auf Operatorebene; nichts im PR behauptet ein End-to-End-Genauigkeits- oder Durchsatzergebnis auf dem integrierten Stack.

Warum QSA der heikle Teil ist – in Zahlen

Qwen Sparse Attention ist keine herkömmliche Attention-Schicht, und die veröffentlichte Konfiguration zeigt, warum ein Beschleuniger-Hersteller einen maßgeschneiderten Pfad dafür schreiben muss. Aus der Konfiguration von Qwen3.8-Flash-Next: 48 Schichten, angeordnet als zwölf Wiederholungen von drei Gated-DeltaNet-Blöcken, gefolgt von einem Full-Attention-Block, full_attention_interval 4, Hidden-Size 2.560, Attention-Head-Dimension 256, 24 Query-Heads gegenüber 2 KV-Heads, RoPE-Dimension 64. Der Indexer, der die Attention sparse macht, ist eine Multi-Query-Struktur mit 4 Query-Heads, die sich 1 Key-Head teilen, Head-Dimension 128, einem Kompressionsverhältnis von 4 und einem Budget von 2.048 ausgewählten Mikro-Blöcken pro Query.

Dieses Budget ist der Wert, den der PR unverändert lässt. Die Sparse-Blockgröße bleibt 1, der Sparse-Modus bleibt 0, der Attention-Modus bleibt 2, und die Schnittstelle für ausgewählte Token bleibt unangetastet; native Indexer- und block4-Optimierungen sind ausdrücklich außerhalb des Umfangs. Es handelt sich also um einen Adapter, der unter einen bestehenden Auswahlmechanismus geschraubt ist, nicht um eine Neuimplementierung von QSA — was auch der Grund dafür ist, dass der Autor glaubhaft behaupten kann, dass der Inhalt des KV-Cache unverändert bleibt.

Die Model Card benennt die Designabsicht unmissverständlich: Statt einzelne Tokens auszuwählen, arbeitet QSA auf Mikroblock-Ebene, um die Long-Context-Latenz zu senken, und genau diese Mikroblock-Granularität – zusammen mit dem replizierten Selector-Zustand, der dazugehört – lässt sich nicht sauber auf einen generischen Paged-Attention-Kernel auf dem Silizium beider Anbieter abbilden.

Wo dies im Qwen4Exp-Serving-Ausbau steht

Für sich genommen ist ein einzelner PR-Entwurf zu einem Accelerator eine Kuriosität. Im Vergleich zum restlichen September ist er die vierte oder fünfte Planke einer Plattform, die öffentlich zusammengesetzt wird, bevor die Familie, der sie dient, überhaupt existiert:

• Die Architektur in offenen Gewichten — Qwen3.8-Flash-Next, 2026-08-24, ein MoE mit 125 Mrd. Parametern, davon 6 Mrd. aktiviert, eine n-Gramm-Embedding-Tabelle mit 51 Milliarden Parametern und ein 4B-MTP-Head, mit model_type: qwen4_exp und architectures Qwen4ExpForConditionalGeneration.

• Die vLLM-Seite — #53909, der PR „qwen4 fuse op“, der HyperConnection-, QSA- und PLE-Kernel hinzufügt, seit dem 26.08.2026 weiterhin offen und nicht gemergt; #59279, der Decode-Kontextparallelität zum selben QSA-Pfad hinzufügt, ein am 29.09.2026 eröffneter Entwurf; und die PLE-Offload-Arbeit, die im Laufe des Septembers gemergt wurde.

• Die SGLang-Seite — #38642 für die DFlash-Hidden-State-Erfassung, #39548 für Qwen4-Exp-PLE-CPU-Offload auf Ascend, #40235 fügt Host-Staging für die dateibasierte PLE-Tabelle hinzu, und jetzt #41855 für den Ascend-Attention-Pfad.

• Die NPU-Enablement-Linie — sglang #37570, die Qwen3.8-Flash-Next zu SGLang auf NPU hinzufügt, mit Graph Replay, MTP und Triton-Kernels (eröffnet am 02.09.2026, weiterhin offen, +2.590 Zeilen über 20 Dateien), und sgl-kernel-npu #807 für die zugehörigen Triton-Kernels (eröffnet am 17.09.2026, +4.643 Zeilen). Beide stammen von demselben Contributor. #41855 ist die Attention-Schicht, die innerhalb dieses größeren Enablement-Vorhabens liegt.

Zwei Beobachtungen, auf die ein Leser reagieren kann. Erstens: Die ganze Ascend-Qwen4Exp-Geschichte stützt sich auf eine sehr kleine Zahl von Mitwirkenden — die Enablement-PRs und das Kernel-Repository haben denselben Autor, und der Attention-Adapter stammt von einem anderen. Diese Konzentration ist ein fairer Anhaltspunkt dafür, wie weit das Ascend-Qwen4Exp-Serving davon entfernt ist, ein unterstützter Produktpfad statt eines Experiments zu sein. Zweitens ist der Kernel-Engpass nicht herstellerspezifisch: Zwei am 28. August 2026 eingereichte SGLang-Issues dokumentieren Qwen4Exp-Decode auf einem NVIDIA DGX Spark, bei dem die Kernelzeit von QSA, PLE und Gated DeltaNet dominiert und bei dem für einen NVFP4-KV-Cache gemessen wurde, dass er den Decode gegenüber fp8_e4m3 um rund 29 % verschlechtert. Die Attention- und Embedding-Schichten dieser Architektur sind überall der schwierige Teil.

Was dies nicht bedeutet

Es bedeutet nicht, dass Qwen 4 erschienen ist oder kurz davor steht. Die Qwen-4-Familie, die Alibaba am 22.09.2026 benannt hat – Max, Flash, Plus und eine 27B-Stufe – bleibt eine Roadmap ohne Modellkarte, ohne Gewichte, ohne API-Kennung, ohne Kontextfenster, ohne Lizenz und ohne Preis. Ein Framework-Adapter, der auf den internen Architekturnamen abzielt, ist ein Schritt dazu, diese Familie eines Tages gut zu bedienen; er ist kein Schritt dazu, dass die Familie existiert.

Das bedeutet nicht, dass Sie dies heute ausführen können. Der PR ist ein Entwurf mit fehlschlagender CI und ohne Merge-Termin. Selbst wenn er gemergt wird, benötigt der Pfad einen Ascend 910C, BF16, CANN 9.0 mit torch-npu 2.10 und eine von fünf spezifischen lokalen Head-Formen, und er ist Opt-in – was bedeutet, dass ein Deployment ihn auswählen muss. Der Autor hat es auch abgelehnt, eine Validierung auf Serverebene zu beanspruchen, was der Teil wäre, der Ihnen tatsächlich sagen würde, ob er unter realem Batching standhält.

Und es bedeutet nicht, dass Qwen3.8-Flash-Next ein unterstütztes Produkt auf Ascend ist, oder irgendwo sonst in einem ausgelieferten Engine-Build. Die Qwen4Exp-Pfade in beiden großen offenen Runtimes sind nicht gemergte Pull Requests. Es gibt keine veröffentlichte SGLang- oder vLLM-Version, die man installieren kann und die diese Architektur nativ bedient – der FastAPI-artige Komfort eines gehosteten Endpunkts ist etwas anderes als ein Kernel, den man selbst ausführen kann, und die Lücke zwischen beiden ist genau das, wofür PRs wie dieser da sind.

Was Sie während der Wartezeit tatsächlich anrufen können

Wenn der Grund, aus dem Sie sich für Qwen4Exp interessieren, der ist, dass Sie das Langkontext-Verhalten der Architektur testen möchten und nicht ihre Kernel-Interna, dann ist das Modell, zu dem Sie greifen sollten, die Stufe, die Alibaba tatsächlich bereitstellt. Qwen3.8-Flash — die Produktionslinie, die auf Qwen3.8-Flash-Next aufbaut, mit offiziellen integrierten Tools und einem Kontext von 1.000.000 Token — ist live auf OrcaRouter als qwen/qwen3.8-flash: Text-, Bild- und Videoeingabe, maximal 131.072 Token Ausgabe, 0,15 $ pro Million Eingabe-Token und 0,47 $ pro Million Ausgabe, Cache-Reads bei 0,0184 $. Das sind Anbieter-Listenpreise, die mit 0 % Aufschlag auf unserer Seite weitergegeben werden, sodass eine Preis- oder Limitänderung des Anbieters Sie am selben Tag erreicht, an dem sie angekündigt wird. Im zurückliegenden Sieben-Tage-Zeitraum zeigt die Live-Karte eine p50-Latenz bis zum ersten Token von 4.416 ms, etwa 106 Ausgabe-Token pro Sekunde und eine Fehlerrate von 2,68 % — eher das Profil einer Text-Stufe mit hohem Volumen als das einer Lab-Vorschau.

Zwei ehrliche Einschränkungen – und es sind dieselben zwei, die auch die verwandten Berichte zu dieser Architektur enthalten. Qwen3.8-Flash-Next selbst – der FP8-Vorschau-Checkpoint, das, was Sie bräuchten, um eine dieser Kernel-Messungen lokal zu reproduzieren – ist nicht in unserem Katalog; die ausgelieferte Flash-Stufe ist das daraus gebaute Produktions-Deployment, nicht das rohe Vorschau-Artefakt. Und keine der oben beschriebenen Ascend- oder DCP-Arbeiten existiert in irgendetwas, das Sie aufrufen können, weil nichts davon gemergt wurde. Was die ausgelieferte Stufe Ihnen bietet, ist eine kostengünstige Möglichkeit, herauszufinden, ob Ihre Workload auf das Problem zugeschnitten ist, das diese Kernel lösen – lange, präfixlastige, agentische Prompts gegen einen sehr langen Kontext. Wenn ja, entsprechen der Durchsatz und das Cache-Verhalten, die Sie dort beobachten, demselben Verhalten, zu dessen Schutz der Qwen 4 Serving-Stack abgestimmt sein wird.

Es gibt auch ein Infrastrukturargument dafür, nicht auf eine Familie zu warten, für die es noch keinen Termin gibt. Welche Stufe am Ende auch immer im Qwen-4-Line-up gewinnt, die Wechselkosten sind eher eine Routing-Frage als ein Integrationsprojekt, und eine API für 200+ Modelle ist der Weg, diese Option offen zu halten, ohne einen zweiten Vertrag oder eine Codeänderung, wenn die Gewichte eintreffen. Failover ist hier aus demselben Grund auf eine ganz bestimmte Weise wichtig: Wenn Sie gegen eine unerprobte Stufe entwickeln möchten, möchten Sie, dass die Anfrage auf etwas Stabileres ausweicht, statt fehlzuschlagen, wenn der Pfad, auf den Sie gesetzt haben, gerade einen schlechten Moment hat.

Drei Fragen, die es wert sind, direkt beantwortet zu werden.

Bedeutet SGLang #41855, dass Qwen 4 veröffentlicht oder als Vorschau verfügbar ist?

Nein, in beiden Punkten. Der Pull Request zielt auf die Qwen4Exp-Architektur ab, wie sie in Qwen3.8-Flash-Next implementiert ist, die Alibaba am 2026-08-24 veröffentlicht hat. Er berührt keine Qwen-4-Gewichte, und keine Qwen-4-Stufe hat Gewichte, die berührt werden könnten. Das Signal, das hier zu lesen ist, betrifft die Serving-Kapazität für eine Preview-Architektur, nicht die Verfügbarkeit der Familie.

Wenn auf einer Modellkarte qwen4_exp steht, ist das dann Qwen 4?

Nein – und genau darin liegt die Namensfalle der ganzen Geschichte. qwen4_exp ist der interne Architekturbezeichner, und genau den findest du in config.json für Qwen3.8-Flash-Next und sein FP8-Geschwister. „Experimentelle Architektur“ ist das entscheidende Wort: Die Gewichte sind veröffentlicht, die Architektur ist real, und das Modell ist eine Vorschau darauf, worauf die Qwen-4-Familie voraussichtlich aufbauen wird. Wenn man den Bezeichner sucht und einen SGLang- oder vLLM-PR mit Qwen4Exp im Titel findet, sagt das etwas über Engine-Arbeit aus, nicht über ein Release.

Ist das eine Ascend-gegen-NVIDIA-Geschichte?

Nicht wirklich. Derselbe Attention-Pfad brauchte auch auf der NVIDIA-Seite einen maßgeschneiderten Adapter – Decode-Context-Parallelism für QSA in vLLM und einen nativen Sparse-Prefill-Kernel für Hopper –, und die Probleme mit dem DGX Spark zeigen, dass auch dort die Kernelzeit von QSA, PLE und Gated DeltaNet das Decode dominiert. QSAs Micro-Block-Indexer und sein replizierter Selector-Zustand sind einfach nicht das, wovon generische Paged-Attention-Kernel ausgehen. Ascends Beitrag zu diesem Muster ist die schärfere Einschränkung: ein Head-Ratio-Tiler, der nur Zweierpotenzen akzeptiert, was das Padding erzwingt, das der Adapter verstecken muss.

Worauf man achten sollte

Nicht die Frage, ob das gemergt wird. Der Adapter ist ehrlich darüber, dass er ein Adapter ist, die Korrektheitstests sind ohne Checkpoint reproduzierbar, und der Autor hat die Integrationsfrage als offen gekennzeichnet, statt vorzugeben, sie sei geklärt. Worauf man achten muss, ist, was passiert, nachdem die NPU-Aktivierungszeile und dieser Attention-Pfad kombiniert werden – ob der integrierte Zweig den End-to-End-Lauf bekommt, den keiner von beiden hatte, mit echtem Batching und dem vollständigen Modell statt mit lokalen Head-Shape-Tensoren. Die 1,713×-Zahl ist diejenige, die kursieren wird, und sie ist diejenige, die auf einem anderen Build, auf einem angepassten Checkpoint und mit einem inaktiven Indexer berechnet wurde. Eine gemessene Zahl auf dem fertigen Stack wäre deutlich mehr wert als eine historische Zahl.

Bis dahin ist die ehrliche Zusammenfassung diejenige, an die sich der PR selbst hält: Die Arithmetik geht auf, das Flag ist standardmäßig aus, die CI ist rot, und das im Titel genannte Modell existiert immer noch nicht.