Qwen 4 QSA erhält Decode-Context-Parallelität: Einblick in vLLMs Draft-PR für Qwen3.8-Flash-Next

Am 29.09.2026 erschien im vLLM-Repository ein Draft-Pull-Request mit dem Titel „[Model][DCP] Support Qwen4Exp QSA“, und für das Modell, das er beschreibt, enthält er die konkretesten Serving-Zahlen, die in diesem Monat überhaupt veröffentlicht wurden: gepaarte Durchläufe von Qwen3.8-Flash-Next auf vier GPUs, die zeigen, dass die KV-Token-Kapazität von 9.759.529 auf 17.603.636 steigt, die maximale Parallelität von 37,23× auf 67,15× und die Zeit bis zum ersten Token von 1.869 ms auf 767 ms fällt. Qwen3.8-Flash-Next ist die Open-Weight-Vorschau mit 125 Milliarden Parametern auf Mixture-of-Experts-Basis, deren Hugging-Face-Karte sie als „eine Vorschau auf die Qwen4-Architektur“ beschreibt; der Pull-Request fügt Decode-Context-Parallelität zu dem Sparse-Attention-Pfad hinzu, auf dem diese Architektur aufbaut. Qwen4 selbst – die Stufen Qwen4 Max, Flash, Plus und 27B, die der Anbieter auf seiner Apsara-Konferenz am 22.09.2026 nannte – ist noch nicht veröffentlicht, ohne Gewichte, ohne Kennung, ohne Preis und ohne Termin. Betrachten Sie das also als das, was es ist: kein Launch, kein Benchmark, sondern ein Engineering-Artefakt, das zeigt, wie der Serving-Spielraum von Qwen4 erweitert wird, bevor die Familie existiert.

Dies ist ein Beitrag zum bisherigen Wissensstand, und die Quellenlage ist wichtiger als sonst. Der Pull Request ist ein offener, nicht gemergter Entwurf — vllm-project/vllm#59279, am 2026-09-29 eröffnet von Sungsoo Ha, einem NVIDIA-Softwareentwickler, und liegt weiterhin als Entwurf vor. Jede unten stehende Zahl ist die eigene gepaarte Messung des Autors, berichtet im PR-Text, erhoben an einer früheren Revision derselben Arbeit. Nichts hiervon ist unabhängig geprüft, nichts hiervon ist in einem Release gelandet, und der vom Autor angefügte Vorbehalt ist gewichtig genug, dass er unten einen eigenen Abschnitt bekommt.

Was der Pull Request tatsächlich ändert

Decode Context Parallelism – DCP – ist eine Serving-Technik, keine Modelländerung. Statt dass eine einzelne GPU-Gruppe einen vollständigen KV-Cache hält, verteilt DCP diesen Cache über Ranks, sodass jeder Rank nur seinen Ausschnitt des Kontexts liest, während die Attention-Ergebnisse am Ende über die Ranks hinweg zusammengeführt werden. Der Punkt ist die Kapazität: Mit partitioniertem Cache kann ein Deployment auf derselben Hardware weit mehr gleichzeitigen Long-Context-Traffic bewältigen – genau die Einschränkung, die zum Tragen kommt, wenn jede Anfrage eine Viertelmillion Tokens mit sich führt.

Die Komplikation besteht darin, dass Qwen Sparse Attention — QSA — keine einfache Attention-Schicht ist. Wie die Modellkarte von Qwen3.8-Flash-Next angibt, komprimiert ein leichtgewichtiger Indexer Keys mit einem Kompressionsverhältnis von 4 in Mikroblöcke, bewertet sie und wählt die besten 512 Blöcke aus, etwa 2.048 Token-Positionen, während die finale Softmax- und Value-Aggregation weiterhin auf den unkomprimierten K und V ausgeführt wird. Das bedeutet, dass QSA mehr Zustand als ein KV-Cache mit sich führt: Es gibt den Haupt-Cache, und es gibt die Selector- und Side-Caches, die der Indexer verwaltet. Die generische DCP-Implementierung in vLLM weiß nichts davon.

Was #59279 laut seiner Beschreibung tut, ist, DCP über die QSA-spezifischen Teile aufzuklären:

• Jeder Rang liest seinen eigenen Teil des Haupt-KV-Caches; dagegen bleiben QSAs Selektor und Seitencaches repliziert über Ränge hinweg, statt aufgeteilt zu sein.

• Attention-Ergebnisse werden nach dem Split-Read über die Ranks hinweg zusammengeführt.

• Der Selektor und der Haupt-KV-Cache werden in einer Cache-Gruppe gehalten, sodass sie nicht auseinanderdriften können.

• Synthetische V2-Batches werden daran gehindert, QSA-Seitencaches zu schreiben.

Das letzte Paar von Details ist der interessante Teil, wenn es Ihnen um Korrektheit statt um Durchsatz geht. Ein geshardeter Attention-Cache, der still und leise nicht mit einem replizierten Selektor übereinstimmt, ist die Art von Fehler, die sich als langsamer Genauigkeitsverfall bei langem Kontext statt als Absturz zeigt, und die Änderung legt ausdrücklich Wert darauf, die beiden im Gleichschritt zu halten. Der Autor gibt außerdem an, dass KI-Unterstützung verwendet wurde, und Codex wird als Co-Autor genannt – das sollte man klar sagen, denn bei einem Draft-PR dieser Art ist es eine berechtigte Frage, wer was geschrieben hat.

Die gepaarten Zahlen und wie sie ermittelt wurden

Der Testplan ist spezifisch genug, um prüfbar zu sein, weshalb die Ergebnisse es wert sind, zitiert zu werden. Beide Arme bedienen Qwen/Qwen3.8-Flash-Next-FP8 auf vier GPUs mit Tensor-Parallelität 4 und aktivierter Experten-Parallelität, bei --gpu-memory-utilization 0.90 mit aktiviertem Prefix-Caching. Der einzige Unterschied zwischen den beiden Armen ist --decode-context-parallel-size: weggelassen für DCP=1, auf 2 gesetzt für DCP=2, mit einem Neustart zwischen den Armen, damit der Benchmark mit einem kalten Cache beginnt. Die Last ist ein AgentX-256k-Trace bei 128 Nutzern über 900 Sekunden; die Genauigkeit ist EvalScope für GSM8K plus der eingecheckte MRCR-Evaluator, sechsmal pro Arm ausgeführt, wobei der erste Lauf nach dem Neustart verworfen wird.

Die gemeldeten Durchsatz-Deltas, DCP=2 gegenüber DCP=1:

• KV-Tokens — 9.759.529 vs. 17.603.636, eine 1,80-fache Erhöhung der Cache-Kapazität.

• Maximale Parallelität — 37,23× vs. 67,15×, außerdem 1,80×.

• Anfragen pro Sekunde — 1,69 vs. 2,30, 1,36×.

• Eingabe-Token pro Sekunde — 128.730 vs. 179.702, 1,40×.

• Zeit bis zum ersten Token — 1.869 ms vs. 767 ms, 2,44× niedriger.

• Inter-Token-Latenz — 43,48 ms vs. 26,27 ms, 1,66× niedriger.

• Prefix-Cache-Trefferrate im stationären Zustand — 67,85 % gegenüber 88,98 %, ein Zugewinn von 21,1 Prozentpunkten.

Die Genauigkeit, angegeben als Mittelwert ± Stichprobenstandardabweichung über die Post-Warmup-Läufe hinweg, war praktisch konstant: MRCR-Aggregat 0,8630 ± 0,0005 bei DCP=1 gegenüber 0,8697 ± 0,0153 bei DCP=2 und GSM8K 0,9788 ± 0,0020 gegenüber 0,9790 ± 0,0016. Die 2-Nadel- und 4-Nadel-MRCR-Stichproben lagen in beiden Versuchsarmen konstant bei 0,9960 bzw. 0,9906, sodass die gesamte Schwankung von Lauf zu Lauf aus den 8-Nadel-Stichproben kam — und ein DCP=2-Aggregatlauf erzielte 0,8970, während die anderen vier zwischen 0,8620 und 0,8632 lagen. Das ist eine echte Streuung, kein Rauschen, das man einfach wegdiskutieren kann, und sie wird im PR genannt, statt beschönigt zu werden.

Was diese Zahlen nicht belegen

Der Vorbehalt steht im PR-Text, und er ist nicht klein. Die Messung der gepaarten AgentX- und Genauigkeitsergebnisse erfolgte auf einer früheren QSA-DCP-Revision, unter Verwendung eines vLLM-Nightlys auf Basis von Commit 3df4ae153eb. Der finale saubere Commit im Pull Request enthält einen nachfolgenden QSA-Lokalisierungs-Kernel-Fix und hat eine fokussierte B200-Validierung bestanden – aber die vollständigen AgentX- und Genauigkeitsbewertungen wurden auf genau dieser Quelle nicht wiederholt. Mit anderen Worten: Die Durchsatz-Story und der ausgelieferte Diff sind nicht dasselbe Artefakt, und der Autor sagt das auch.

Darüber hinaus gilt die übliche Disziplin, und sie gilt streng. Dies sind Zahlen aus einer einzigen Konfiguration von einem einzigen Mitwirkenden auf einem einzigen Vier-GPU-Setup. Sie sind herstellernah statt neutral: Ein Framework-Mitwirkender, der eine Framework-Änderung misst, ist eine normale und nützliche Sache, aber es ist kein Audit, und kein Dritter hat den Lauf reproduziert. Es gibt keine veröffentlichte vLLM-Version, die man heute installieren kann und die diese Änderung enthält, denn die Änderung wurde nicht gemergt. Und DCP=2 ist ein Zwei-Wege-Split einer bestimmten Shape – die Deltas sind kein Versprechen darüber, was DCP=4 oder DCP=8 tun würden, und nichts in dem PR behauptet, dass sie eines wären.

Warum ein Serving-PR zu einer unveröffentlichten Architektur trotzdem Ihre Zeit wert ist

The obvious objection: the model in the title does not exist, so why care? Because the thing being tuned is not Qwen 4. It is Qwen3.8-Flash-Next, and that model does exist — Alibaba published it on 2026-08-24 as a 125B-parameter MoE with 6B activated, a 51-billion-parameter n-gram embedding table, a 4B MTP head for speculative decoding, 48 layers arranged as twelve repeats of three Gated DeltaNet blocks followed by one QSA block, 512 experts with 10 routed and 1 shared active, and a native context of 262,144 tokens that the card says is extensible to 1,000,000. It is the reference implementation of the Qwen4 architecture in open weights, and QSA — the micro-block sparse attention that this pull request is teaching DCP to shard — is the single most distinctive part of it.

Was diese Zahlen beschreiben, ist, was passiert, wenn man diesen 262K-Kontext nicht mehr als etwas behandelt, das eine einzelne GPU-Gruppe vollständig halten muss. Der 1,80-fache Sprung bei KV-Token-Kapazität und Parallelität ist die Rechnung, die hinter dem Aufteilen eines Caches in zwei Teile steckt – das am wenigsten überraschende Ergebnis in der Liste. Die interessanteren Werte sind die Latenzwerte: 2,44-mal niedrigere Zeit bis zum ersten Token und 1,66-mal niedrigere Inter-Token-Latenz bei gleicher angebotener Last, dazu eine Verbesserung um 21 Punkte bei der Prefix-Cache-Trefferquote im eingeschwungenen Zustand. Sie zeigen, dass der DCP-Pfad nicht lediglich Kapazität auf Kosten der Latenz erkauft – in diesem gepaarten Durchlauf brachte er beides. Das ist die Art von Veränderung, die für jeden von Bedeutung ist, der Agent-Traffic mit sehr langen System-Prompts bedient, denn das Prefix-Cache-Verhalten bei langem Kontext ist üblicherweise der Punkt, an dem der Long-Context-Durchsatz unbemerkt zusammenbricht.

In derselben Woche entstand ein Cluster von Arbeiten an der Qwen4Exp-Engine: #59214 fügt SM100-GEMM-Pläne für latenzarmes Decoding für B200-Formen hinzu, #59010 fügt einen nativen SM90-Sparse-Prefill-Kernel für den QSA-Pfad auf Hopper hinzu, #58977 deckt BF16-INC-PLE-Embeddings ab, und #58961 – derjenige, der tatsächlich am 2026-09-28 gemergt wurde – hat einen Profiling-KV-Cache korrigiert, den QSA-Key-Views am Leben hielten. Zusammen gelesen sind sie der Serving-Rahmen der Qwen4-Architektur, die öffentlich, in den Runtimes, Monate bevor die Familie erscheint, gebaut wird. Wenn Sie für Qwen 4 planen, ist das nützliche Signal kein Startdatum – es gibt keines –, sondern das, was die Kernel und Cache-Layouts bereits darüber voraussetzen, wie Sie es werden bereitstellen müssen.

Was Sie heute anrufen können

Wenn Sie das Langkontext-Verhalten auf der Architektur testen möchten, um die es in diesem PR geht, ist das Modell der Wahl die Flash-Stufe, die Alibaba tatsächlich anbietet. Qwen3.8-Flash – das Produktions-Deployment auf Basis von Qwen3.8-Flash-Next, mit einem Kontext von 1.000.000 Token und einer maximalen Ausgabe von 131.072 Token, das Text-, Bild- und Videoeingaben akzeptiert – ist live, und es ist ein Endpunkt für das Modell, das heute tatsächlich die Qwen4Exp-Architektur ausführt, gelistet als qwen/qwen3.8-flash zu $0,15 pro Million Eingabe-Token und $0,47 pro Million Ausgabe-Token, wobei Cache-Lesevorgänge $0,0184 kosten. Da dies Anbieter-Listenpreise sind, die ohne Aufschlag unsererseits weitergegeben werden, erreicht Sie eine Preis- oder Limitänderung des Anbieters bei diesem Modell am selben Tag, an dem sie angekündigt wird.

Zwei ehrliche Einschränkungen. Erstens: Qwen3.8-Flash-Next selbst – die FP8-Gewichte im Testplan des Pull Requests, also diejenigen, die Sie bräuchten, um irgendeine dieser Messungen lokal zu reproduzieren – ist nicht in unserem Katalog; die bereitgestellte Flash-Stufe ist die QwenCloud-Produktionslinie, nicht der rohe Preview-Checkpoint. Wenn Sie die exakte Konfiguration aus dem PR ausführen möchten, betreiben Sie Self-Hosting auf vier GPUs. Zweitens: Die DCP-Änderung ist nicht zusammengeführt, sodass nichts, was Sie heute irgendwo aufrufen können, sie ausführt. Was die bereitgestellte Stufe Ihnen bietet, ist eine Möglichkeit herauszufinden, ob Ihre Workload überhaupt auf das Problem zugeschnitten ist, das DCP löst: Wenn Ihre Prompts lang, agentisch und prefix-lastig sind, dann sind die 1,80× Kapazität und das Prefix-Cache-Delta die Zahlen, auf die Sie in Ihren eigenen Traces achten sollten.

Und wenn für Sie der interessante Teil nicht ein einzelnes Modell ist, sondern die Frage des Wechsels – auf welche Stufe Sie setzen sollten, solange die Qwen-4-Reihe noch namenlos ist –, dann ist das eher ein Routing-Problem als eines des Servings, und eine API für 200+ Modelle ist der Weg, sich diese Option offenzuhalten – ohne einen zweiten Vertrag oder eine Codeänderung, wenn die Familie endlich erscheint.

Fragen, die es wert sind, direkt beantwortet zu werden

Bedeutet #59279, dass Qwen 4 veröffentlicht ist oder kurz davor steht?

Nein. Der Pull-Request dreht sich um die Qwen4Exp-Architektur, wie sie in Qwen3.8-Flash-Next implementiert ist, das Alibaba am 2026-08-24 ausgeliefert hat. Die Qwen-4-Familie – Max, Flash, Plus und 27B – wurde am 2026-09-22 auf einer Bühne bei Apsara benannt und auf eine Unternehmens-Roadmap gesetzt, mit einer Nachfolgelinie, die auf 5 bis 10 Billionen Parameter prognostiziert wird, und sie hat immer noch keine Modellkarte, keine Gewichte, keine API-Kennung, kein Kontextfenster, keinen Preis und kein Datum. Ein Framework-PR, der der Vorschau-Architektur einen Parallelitätsmodus hinzufügt, ist ein Schritt hin zu einer guten Bereitstellung von Qwen 4. Er ist kein Schritt in Richtung der Existenz von Qwen 4.

Wie unterscheidet sich Decode-Kontext-Parallelität von Tensor-Parallelität?

Sie zerlegen unterschiedliche Dinge und scheitern auf unterschiedliche Weise. Tensor-Parallelismus partitioniert die Gewichte und die Berechnung jeder Schicht über GPUs, sodass jeder Rang an jedem Token beteiligt ist, aber die gesamte Sequenz sieht. Decode-Kontext-Parallelismus partitioniert den KV-Cache selbst, sodass jeder Rang nur einen Ausschnitt des Kontexts hält und liest; die partiellen Attention-Ergebnisse werden anschließend zusammengeführt. Bei TP geht es darum, das Modell unterzubringen; bei DCP geht es darum, den Kontext und den gleichzeitigen Datenverkehr, der darauf mitläuft, unterzubringen. Genau diese Unterscheidung ist der Grund, warum dieser PR nicht trivial ist: Der Selektor und die Side-Caches von QSA können nicht einfach in Shards aufgeteilt werden wie der Haupt-KV-Cache, also muss die Änderung einen in Shards aufteilen und die anderen replizieren und dann beweisen, dass die beiden konsistent bleiben.

Wenn ich Qwen3.8-Flash-Next heute über eine gehostete API aufrufe, bekomme ich dann bereits diese Werte?

Nein, und die Lücke hat drei Teile. Die Änderung ist nicht gemergt, daher enthält kein veröffentlichter vLLM-Build sie. Selbst nach dem Merge muss der Anbieter diesen Build übernehmen und sich dafür entscheiden, mit einer DCP-Größe über eins zu laufen – es ist eine Serving-Konfiguration, kein Standard. Und die gemessenen Deltas stammen aus einer früheren Revision des Patches statt aus dem finalen Commit, der laut Autor bisher nur eine fokussierte B200-Validierung erfahren hat. Betrachten Sie die berichteten Deltas als eine gut dokumentierte Obergrenze dessen, was der Ansatz in einer Konfiguration bringt, nicht als Spezifikation eines Endpunkts, den Sie diese Woche mieten können.

Die offene Frage

Worauf man achten muss, ist nicht, ob dieser konkrete Entwurf gemergt wird — wahrscheinlich wird das in irgendeiner Form geschehen, denn die QSA-spezifische Cache-Behandlung, die er hinzufügt, ist eine echte Lücke statt einer Präferenz. Worauf man achten muss, ist, ob der finale Commit dieselbe gepaarte Evaluierung erhält wie die Zwischenrevision. Eine Serving-Änderung, deren Durchsatzangaben aus einem Build stammen und deren Korrektheitsangaben aus einem anderen Build stammen, ist vorerst ein gut begründeter Vorschlag statt eines gemessenen Ergebnisses, und die Genauigkeitsstreuung bei den 8-Needle-MRCR-Stichproben ist breit genug, dass eine Wiederholung des Durchlaufs mit der ausgelieferten Quelle das mit Abstand Nützlichste wäre, das jemand darüber veröffentlichen könnte. Bis dahin gilt: Die Richtung ist erkennbar, das Hauptbuch ist nicht geschlossen, und das einzige Modell mit Qwen4-Architektur in offenen Gewichten bleibt das vom August.