Qwen 4 QSA zyskuje równoległość kontekstu dekodowania: wewnątrz szkicowego PR-a vLLM dla Qwen3.8-Flash-Next

29 września 2026 r. w repozytorium vLLM pojawił się szkicowy pull request zatytułowany „[Model][DCP] Support Qwen4Exp QSA”, a w odniesieniu do opisywanego modelu zawiera najbardziej konkretne liczby dotyczące serwowania, jakie ktokolwiek opublikował w całym miesiącu: sparowane przebiegi Qwen3.8-Flash-Next na czterech GPU pokazujące, że pojemność tokenów KV wzrasta z 9 759 529 do 17 603 636, maksymalna współbieżność wzrasta z 37,23× do 67,15×, a czas do pierwszego tokenu spada z 1 869 ms do 767 ms. Qwen3.8-Flash-Next to mający otwarte wagi, 125-miliardowy model typu mixture-of-experts w wersji preview, którego karta na Hugging Face opisuje go jako „Zapowiedź architektury Qwen4”; pull request dodaje równoległość kontekstu dekodowania (decode context parallelism) do ścieżki sparse-attention, na której opiera się ta architektura. Sam Qwen4 — warianty Qwen4 Max, Flash, Plus i 27B, które dostawca wymienił na swojej konferencji Apsara 22 września 2026 r. — wciąż nie został wydany: brak wag, brak identyfikatora, brak ceny i brak daty. Czytaj więc to jako to, czym jest: nie premierę, nie benchmark, lecz artefakt inżynieryjny, który mówi, jak rozszerzana jest obwiednia serwowania Qwen4, zanim ta rodzina powstanie.

To materiał o tym, co wiemy do tej pory, a kwestia źródeł ma większe znaczenie niż zwykle. Pull request to wersja robocza, otwarta i niezmergowana — vllm-project/vllm#59279, otwarty 2026-09-29 przez Sungsoo Ha, inżyniera oprogramowania w NVIDIA, i nadal pozostaje w wersji roboczej. Każda liczba poniżej to własny pomiar sparowany autora, podany w treści PR, wykonany na wcześniejszej wersji tej samej pracy. Nic tutaj nie zostało niezależnie zweryfikowane, nic tutaj nie trafiło do wydania, a zastrzeżenie, które autor dołącza, jest na tyle istotne, że ma poniżej własną sekcję.

Co tak naprawdę zmienia pull request

Decode context parallelism — DCP — to technika serwowania, a nie zmiana modelu. Zamiast jednej grupy GPU przechowującej całą pamięć podręczną KV, DCP dzieli tę pamięć podręczną między rangi, dzięki czemu każda ranga odczytuje tylko swój wycinek kontekstu, a wyniki uwagi są na końcu łączone między rangami. Chodzi o pojemność: gdy pamięć podręczna jest podzielona, wdrożenie może utrzymać znacznie więcej jednoczesnego ruchu z długim kontekstem na tym samym sprzęcie, co jest dokładnie tym ograniczeniem, które daje się we znaki, gdy każde żądanie niesie ćwierć miliona tokenów.

Komplikacja polega na tym, że Qwen Sparse Attention — QSA — nie jest zwykłą warstwą uwagi. Jak określa to karta modelu Qwen3.8-Flash-Next, lekki indekser kompresuje klucze do mikrobloków przy współczynniku kompresji 4, ocenia je i zachowuje najlepsze 512 bloków, czyli około 2048 pozycji tokenów, podczas gdy końcowy softmax i agregacja wartości nadal działają na nieskompresowanych K i V. Oznacza to, że QSA przechowuje więcej stanu niż pamięć podręczna KV: istnieje główna pamięć podręczna oraz pamięci podręczne selektora i boczne, którymi zarządza indekser. Ogólna implementacja DCP w vLLM nie ma o tym wszystkim pojęcia.

To, co robi #59279 zgodnie z jego opisem, to uczenie DCP części specyficznych dla QSA:

• Każdy rank odczytuje własną część głównego KV cache, natomiast selektor i boczne cache QSA pozostają replikowane między rankami, a nie shardowane.

• Wyniki uwagi są łączone między rangami po odczycie rozdzielonym.

• Selektor i główny cache KV są przechowywane w jednej grupie pamięci podręcznej, więc nie mogą się rozjechać.

• Partie syntetyczne V2 nie mogą zapisywać do bocznych pamięci podręcznych QSA.

Ta ostatnia para szczegółów jest najciekawsza, jeśli zależy ci na poprawności, a nie na przepustowości. Shardowana pamięć podręczna uwagi, która po cichu nie zgadza się z replikowanym selektorem, to rodzaj błędu, który objawia się powolnym spadkiem dokładności przy długim kontekście, a nie awarią — a zmiana wprost mówi o utrzymywaniu tych dwóch elementów w zgodzie. Autor zaznacza też, że korzystano z pomocy AI, a Codex jest wymieniony jako współautor — warto to powiedzieć wprost, bo w szkicu PR o takim kształcie zasadne jest pytanie, kto co napisał.

Pary liczb i sposób ich uzyskania

Plan testu jest wystarczająco konkretny, by można go było zweryfikować, dlatego wyniki warto przytaczać. W obu ramionach model Qwen/Qwen3.8-Flash-Next-FP8 jest obsługiwany na czterech GPU z równoległością tensorową 4 i włączoną równoległością ekspertów, przy --gpu-memory-utilization 0.90 z włączonym buforowaniem prefiksów. Jedyna różnica między oboma ramionami to --decode-context-parallel-size: pominięty dla DCP=1, ustawiony na 2 dla DCP=2, z restartem między ramionami, aby test wydajnościowy zaczynał się od zimnej pamięci podręcznej. Obciążenie stanowi ślad AgentX 256k przy 128 użytkownikach przez 900 sekund; dokładność mierzy się za pomocą EvalScope dla GSM8K oraz ewaluatora MRCR z repozytorium, uruchamianych sześć razy na każde ramię, przy czym pierwszy przebieg po restarcie jest odrzucany.

Zgłoszone różnice przepustowości, DCP=2 w porównaniu z DCP=1:

• Tokeny KV — 9 759 529 vs 17 603 636, wzrost pojemności pamięci podręcznej o 1,80×.

• Maksymalna współbieżność — 37,23× vs 67,15×, a także 1,80×.

• Żądania na sekundę — 1,69 vs 2,30, 1,36×.

• Tokeny wejściowe na sekundę — 128 730 vs 179 702, 1,40×.

• Czas do pierwszego tokenu — 1 869 ms vs 767 ms, 2,44× niższy.

• Opóźnienie między tokenami — 43,48 ms vs 26,27 ms, 1,66× niższe.

• Wskaźnik trafień pamięci podręcznej prefiksów w stanie ustalonym — 67,85% vs 88,98%, wzrost o 21,1 punktu procentowego.

Dokładność, raportowana jako średnia ± odchylenie standardowe próby w przebiegach po rozgrzewce, była zasadniczo płaska: agregat MRCR 0,8630 ± 0,0005 przy DCP=1 w porównaniu z 0,8697 ± 0,0153 przy DCP=2, a GSM8K 0,9788 ± 0,0020 w porównaniu z 0,9790 ± 0,0016. Próbki MRCR z 2 igłami i 4 igłami były stałe na poziomie 0,9960 i 0,9906 w obu ramionach, więc cały ruch między przebiegami pochodził z próbek z 8 igłami — a jeden przebieg agregatu DCP=2 uzyskał wynik 0,8970, podczas gdy pozostałe cztery mieściły się między 0,8620 a 0,8632. To jest prawdziwy rozrzut, a nie szum, który można zignorować, i jest to podane w PR, a nie wygładzone.

Czego te liczby nie ustalają

Zastrzeżenie znajduje się w tekście PR i nie jest małe. Sparowane wyniki AgentX i dokładności zostały zmierzone na wcześniejszej wersji QSA DCP, przy użyciu nocnej kompilacji vLLM opartej na commicie 3df4ae153eb. Ostateczny czysty commit w ramach pull requesta obejmuje późniejszą poprawkę jądra lokalizacyjnego QSA i przeszedł ukierunkowaną walidację B200 — ale pełne ewaluacje AgentX i dokładności nie zostały powtórzone na tym konkretnym źródle. Innymi słowy: historia przepustowości i wysyłany diff to nie ten sam artefakt, a autor tak twierdzi.

Poza tym obowiązuje zwykła dyscyplina — i tutaj ma ona zastosowanie w pełnej sile. To liczby dla jednej konfiguracji, pochodzące od jednego współtwórcy, na jednym układzie czterech GPU. Są raczej powiązane z dostawcą niż neutralne: współtwórca frameworka mierzący zmianę w frameworku to rzecz normalna i użyteczna, ale to nie jest niezależny audyt i żadna strona trzecia nie odtworzyła tego przebiegu. Nie istnieje wydana wersja vLLM, którą można dziś zainstalować i która zawiera tę zmianę, ponieważ zmiana nie została scalona. A DCP=2 to dwuczęściowy podział jednego konkretnego kształtu — te różnice nie są obietnicą tego, jak zachowałyby się DCP=4 lub DCP=8, i nic w PR nie twierdzi, że tak jest.

Dlaczego PR dotyczący serwowania nieopublikowanej architektury wciąż jest wart twojego czasu

Oczywisty zarzut: model z tytułu nie istnieje, więc po co się nim przejmować? Ponieważ to, co jest dostrajane, to nie Qwen 4. To Qwen3.8-Flash-Next, a ten model istnieje — Alibaba opublikowała go 24 sierpnia 2026 r. jako MoE o 125 mld parametrów z 6 mld aktywowanych, z tablicą osadzeń n-gramowych o 51 mld parametrów, głowicą MTP o 4 mld parametrów do dekodowania spekulatywnego, 48 warstwami ułożonymi jako dwanaście powtórzeń trzech bloków Gated DeltaNet, po których następuje jeden blok QSA, 512 ekspertami z 10 aktywnymi trasowanymi i 1 współdzielonym aktywnym oraz natywnym kontekstem 262 144 tokenów, który według karty można rozszerzyć do 1 000 000. Jest to referencyjna implementacja architektury Qwen4 w otwartych wagach, a QSA — mikroblokowa rzadka uwaga, której dzielenia na shardy uczy DCP ten pull request — jest jej najbardziej charakterystycznym elementem.

To, co opisują te liczby, to to, co się dzieje, gdy przestaje się traktować ten kontekst 262K jako coś, co jedna grupa GPU musi trzymać w całości. Skok o 1,80× w pojemności tokenów KV i współbieżności to arytmetyka podziału pamięci podręcznej na dwie części, co jest najmniej zaskakującym wynikiem na liście. Ciekawsze są liczby dotyczące opóźnień: 2,44× krótszy czas do pierwszego tokenu i 1,66× niższe opóźnienie między tokenami przy tym samym obciążeniu oferowanym, plus poprawa o 21 punktów ustabilizowanego współczynnika trafień pamięci podręcznej prefiksów. Liczby te mówią, że ścieżka DCP nie tylko kupuje pojemność kosztem opóźnienia — w tym sparowanym przebiegu kupiła jedno i drugie. To jest kształt zmiany, który ma znaczenie dla każdego, kto obsługuje ruch agentów z bardzo długimi promptami systemowymi, ponieważ zachowanie pamięci podręcznej prefiksów przy długim kontekście to zwykle miejsce, w którym przepustowość długiego kontekstu po cichu umiera.

I nie jest to odosobniona poprawka. W tym samym tygodniu powstał klaster prac nad silnikiem Qwen4Exp: #59214 dodaje plany GEMM dekodowania o niskich opóźnieniach dla SM100 pod kształty B200, #59010 dodaje natywne jądro prefill z rzadkością dla SM90 dla ścieżki QSA na Hopperze, #58977 obejmuje osadzenia BF16 INC PLE, a #58961 — ten, który faktycznie został scalony, 28.09.2026 — naprawił bufor KV do profilowania, który widoki kluczy QSA utrzymywały przy życiu. Czytane razem, wyznaczają one kopertę serwowania architektury Qwen4 budowanej publicznie, w środowiskach uruchomieniowych, na miesiące przed premierą rodziny. Jeśli planujesz pod Qwen 4, użytecznym sygnałem nie jest data premiery — bo jej nie ma — lecz to, co jądra i układy pamięci podręcznej już zakładają o tym, jak będziesz musiał ją serwować.

Co możesz dziś nazwać

Jeśli chcesz przetestować zachowanie długiego kontekstu na architekturze, której dotyczy ten PR, model, po który warto sięgnąć, to poziom Flash, który Alibaba faktycznie udostępnia. Qwen3.8-Flash — wdrożenie produkcyjne oparte na Qwen3.8-Flash-Next, z kontekstem 1 000 000 tokenów i maksymalnym wyjściem 131 072 tokenów, przyjmujące dane wejściowe tekstowe, obrazowe i wideo — jest już dostępne i jest to jeden punkt końcowy dla modelu, który faktycznie uruchamia architekturę Qwen4Exp dzisiaj, wymieniony jako qwen/qwen3.8-flash w cenie $0,15 za milion tokenów wejściowych i $0,47 za milion tokenów wyjściowych, z odczytem z pamięci podręcznej po $0,0184. Ponieważ są to ceny katalogowe dostawcy przekazywane bez marży po naszej stronie, zmiana ceny lub limitu u dostawcy dotrze do Ciebie tego samego dnia, w którym zostanie ogłoszona.

Dwa uczciwe zastrzeżenia. Po pierwsze, sam Qwen3.8-Flash-Next — wagi FP8 z planu testów pull requesta, te, których potrzebowałbyś, aby odtworzyć którekolwiek z tych pomiarów lokalnie — nie ma go w naszym katalogu; udostępniana warstwa Flash to linia produkcyjna QwenCloud, a nie surowy checkpoint wersji zapoznawczej. Jeśli chcesz uruchomić dokładnie tę konfigurację z PR-a, hostujesz ją samodzielnie na czterech GPU. Po drugie, zmiana DCP nie została zmergowana, więc nic, co możesz dziś gdziekolwiek wywołać, jej nie uruchamia. Udostępniana warstwa daje ci sposób, aby dowiedzieć się, czy twoje obciążenie jest w ogóle ukształtowane pod problem, który rozwiązuje DCP: jeśli twoje prompty są długie, agentowe i zdominowane przez prefiksy, to pojemność 1,80× i delta pamięci podręcznej prefiksów to liczby, którym warto się przyglądać we własnych śladach.

A jeśli interesującą cię częścią nie jest jeden model, lecz kwestia przełączania — na którym poziomie budować, skoro linia Qwen 4 wciąż nie ma nazwy — to problem routingu, a nie serwowania, a jedno API dla ponad 200 modeli to sposób, by zachować tę opcję otwartą bez drugiej umowy i bez zmiany w kodzie, gdy rodzina wreszcie się pojawi.

Pytania, na które warto odpowiedzieć bezpośrednio

Czy #59279 oznacza, że Qwen 4 już wyszedł, czy dopiero ma wyjść?

Nie. Pull request dotyczy architektury Qwen4Exp w takiej postaci, w jakiej zaimplementowano ją w Qwen3.8-Flash-Next, który Alibaba wydała 24 sierpnia 2026 r. Rodzina Qwen 4 — Max, Flash, Plus i 27B — została ogłoszona na scenie w Apsara 22 września 2026 r. i wpisana do firmowej mapy drogowej z linią następcy, której prognozowana liczba parametrów wynosi od 5 do 10 bilionów; nadal nie ma karty modelu, wag, identyfikatora API, okna kontekstowego, ceny ani daty. PR do frameworka dodający tryb równoległości do architektury w wersji preview to krok w stronę dobrego serwowania Qwen 4. Nie jest to krok w stronę istnienia Qwen 4.

Czym różni się równoległość kontekstu dekodowania od równoległości tensorowej?

Dzielą różne rzeczy i zawodzą na różne sposoby. Parallelizm tensorowy dzieli wagi i obliczenia każdej warstwy między GPU, więc każdy rank uczestniczy w każdym tokenie, ale widzi całą sekwencję. Parallelizm kontekstu dekodowania dzieli pamięć podręczną KV jako taką, więc każdy rank przechowuje i odczytuje tylko wycinek kontekstu, a częściowe wyniki uwagi są następnie scalane. TP dotyczy zmieszczenia modelu; DCP dotyczy zmieszczenia kontekstu i towarzyszącego mu ruchu współbieżnego. Właśnie ta różnica sprawia, że ten PR nie jest trywialny: selektor QSA i boczne pamięci podręczne nie mogą być po prostu dzielone na shardy tak, jak można dzielić główną pamięć podręczną KV, więc zmiana musi podzielić na shardy jedną, a pozostałe replikować, a następnie udowodnić, że te dwa elementy pozostają spójne.

Jeśli wywołam dziś Qwen3.8-Flash-Next przez hostowane API, czy już otrzymam te liczby?

Nie, a ta luka ma trzy części. Zmiana nie została scalona, więc żadna opublikowana kompilacja vLLM jej nie zawiera. Nawet po scaleniu dostawca musi wdrożyć tę kompilację i zdecydować się na uruchomienie z rozmiarem DCP większym niż jeden — to konfiguracja serwowania, a nie ustawienie domyślne. A zmierzone różnice pochodzą z wcześniejszej wersji poprawki, a nie z końcowego commita, który — jak twierdzi autor — doczekał się dotychczas jedynie ukierunkowanej walidacji na B200. Traktuj raportowane różnice jako dobrze udokumentowane górne ograniczenie tego, co to podejście daje w jednej konfiguracji, a nie jako specyfikację jakiegokolwiek endpointu, który możesz wynająć w tym tygodniu.

Otwarte pytanie

Nie chodzi o to, czy ten konkretny szkic zostanie scalony — prawdopodobnie zostanie w jakiejś formie, ponieważ dodawana przez niego obsługa pamięci podręcznej specyficzna dla QSA to prawdziwa luka, a nie preferencja. Chodzi o to, czy końcowy commit otrzyma taką samą sparowaną ewaluację, jaką otrzymała wersja pośrednia. Zmiana w serwowaniu, której twierdzenia o przepustowości pochodzą z jednego builda, a twierdzenia o poprawności z innego, jest na razie dobrze uzasadnioną propozycją, a nie zmierzonym wynikiem, a rozrzut dokładności na próbkach 8-needle MRCR jest na tyle szeroki, że powtórzenie przebiegu na dostarczonym źródle byłoby najbardziej użyteczną rzeczą, jaką ktokolwiek mógłby o tym opublikować. Do tego czasu: kierunek jest czytelny, księga nie jest zamknięta, a jedyny model architektury Qwen4 w otwartych wagach pozostaje ten z sierpnia.