Wyciek Qwen 4: SGLang sharduje Qwen4Exp Prefill, dając 18% szybszy TTFT i 1 GiB z powrotem na GPU

Pull request otwarty w repozytorium SGLang o 03:47 UTC dziś rano, 2026-10-08, obiecuje coś, czego żadne ogłoszenie Qwen 4 jeszcze nie dało: liczbę. Nosi tytuł feat(qwen4-exp): enable LayerNorm sequence parallelism for GR and PLE, a na czterech GPU H20 uruchamiających model o otwartych wagach Qwen3.8-Flash-Next w FP8 jego autor raportuje zyski w czasie do pierwszego tokenu wynoszące 17,7–18,4% przy wejściu 32K i 14,6–14,7% przy wejściu 235K, około gigabajta szczytowej pamięci odzyskanej na każdą GPU oraz nawet o 22% większą przepustowość wejściową. Qwen 4 jako taki — rodzina, którą dostawca nazwał, ale której nie wydał na konferencji Apsara w Hangzhou 2026-09-22 — wciąż nie został wydany: brak wag, brak identyfikatora i brak ceny. Jedynym modelem, który dziś urzeczywistnia architekturę Qwen4Exp, jest Qwen3.8-Flash-Next, opublikowany 2026-08-26, a jego zarządzany bliźniak Qwen3.8-Flash to wersja, do której faktycznie może dotrzeć wywołujący API. Co następuje należy więc czytać dokładnie jako to, czym jest: sparowane pomiary jednego inżyniera, dołączone do otwartego, roboczego, nie scalonego pull requesta, o obwiedni serwowania rodziny modeli, która jeszcze nie istnieje.

Najpierw źródło, ponieważ to materiał z przecieku i to rozróżnienie naprawdę ma znaczenie. Sygnałem jest sgl-project/sglang#43048, otwarty 2026-10-08 o 03:47 UTC przez konto GitHub shiyang814-cpu, ostatnio zmodyfikowany o 03:55 UTC i wciąż oznaczony jako wersja robocza, bez odnotowanej recenzji zatwierdzającej i bez scalenia. Zmienia sześć plików — dwa pliki testowe, plik modelu Qwen4Exp, moduł LayerNorm-SP, fabrykę granic warstw i hook grupy argumentów — o +345 i −50 linii. Każda liczba wydajności poniżej pochodzi z opisu PR, jest własnym, porównawczym pomiarem OFF/ON autora i nie została przez nikogo odtworzona. Trzy uruchomienia CI dla rewizji na czubku gałęzi są oznaczone jako nieudane. Nic tutaj nie jest wdrożoną funkcją.

Co tak naprawdę zmienia pull request

Równoległość sekwencji nie jest zmianą modelu ani nową możliwością. To przepięcie tego, gdzie kilka warstw wykonuje swoje obliczenia. Jej rodowód sięga równoległości sekwencji w stylu Megatron — sztuczki z arXiv:2205.05198 — a SGLang już to dostarcza: sam docstring modułu wyjaśnia mechanizm, który ponownie wykorzystuje: że przy czystej równoległości tensorowej wierszowo równoległa operacja all_reduce jest algebraicznie równoważna operacji reduce_scatter, po której następuje all_gather. Ponieważ te dwie operacje kolektywne przenoszą dokładnie tyle samo bajtów, ile przenosi pojedyncza operacja all_reduce, którą zastępują, rozdzielenie operacji w ten sposób nie pociąga za sobą żadnego dodatkowego wolumenu komunikacji. Daje to swobodę, by regiony normalizacji i resztowe działały na podzielonych wzdłuż sekwencji aktywacjach — przy czym każda ranga równoległości tensorowej przechowuje jedną-1/tptą część wierszy tokenów — co zmniejsza przejściową pamięć aktywacji, którą prefill długiego kontekstu musi utrzymywać.

Ten konkretny pull request rozszerza istniejącą ścieżkę z architektury, na której została zwalidowana, na architekturę Qwen4Exp. Podczas prefillu aktywacje Gated Residual i Per-Layer Embedding pozostają shardowane wzdłuż wymiaru tokenów w obrębie grupy TP. Przed attention, przed GDN, przed QSA i przed uruchomieniem bloku Mixture-of-Experts pełne wiersze tokenów są ponownie all-gatherowane, istniejące obliczenia tensor-parallel na pełnych wierszach działają bez zmian za wspólnym fallbackiem, a reduce-scatter następnie sumuje częściowe wkłady i przywraca shard każdego ranka. Decode w ogóle nie dotyka nowej ścieżki. Funkcja jest osiągana przez opcję, która już istnieje — --enable-layernorm-sp — bez flagi specyficznej dla Qwen4Exp, a przy braku flagi kod zachowuje się dokładnie tak, jak wcześniej.

Dlaczego Qwen4Exp to architektura, która tego potrzebuje

Powód, dla którego ma to znaczenie konkretnie dla Qwen4Exp, a nie w równym stopniu dla każdego modelu, tkwi w samym projekcie architektury. Qwen3.8-Flash-Next stosuje projekcje Gated Residual do wszystkich wierszy tokenów w każdej warstwie dekodera — konfiguracja deklaruje cztery strumienie rezydualne i rząd wąskiego gardła równy 320 w 48 warstwach — a Per-Layer Embedding dodaje drugą replikowaną projekcję, wykonywaną wiersz po wierszu tokenów, na wierzchu tego. W ramach równoległości tensorowej obie te operacje są powielane identycznie na każdym ranku, ponieważ nie mają własnej macierzy wag podzielonej na shardy przez TP, która wymuszałaby podział. Podział ich wymiaru tokenów na shardy usuwa bezpośrednio replikowaną pracę, a jak ujmuje to sekcja motywacji PR-a, dzieje się to przy zachowaniu istniejącego układu równoległości tensorowej i semantyki redukcji attention, GDN/QSA oraz MoE — co czyni tę zmianę bezpieczną, a nie sprytną.

Warto powiedzieć wprost, co to oznacza dla czytelnika. Najciekawsze w tym PR nie jest to, że SGLang przyspiesza. Chodzi o to, że architektura Qwen4 niesie koszty przypadające na warstwę, które skalują się wraz z liczbą tokenów, a nie z liczbą parametrów, i to właśnie te koszty dają się we znaki przy długich prefillach. To swoisty odcisk palca projektu — coś, o czym karta specyfikacji nigdy nie wspomina.

Zmierzone delty

Benchmark autora ustala jedną konfigurację i przełącza flagę: cztery GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, tensor parallel 4 i expert parallel 4, rozmiar chunked prefill 8192, backendy prefill i decode FlashInfer dla liniowej uwagi, ta sama konfiguracja serwera dla OFF i ON, naprzemienne restarty usługi OFF → ON → OFF → ON oraz stałe wejścia tokenów z żądaniami rozgrzewającymi. Każda liczba poniżej pochodzi z tego zestawu i nie została poddana audytowi:

• Wejście 32K, rozmiar partii 1 — TTFT poprawiło się o 17,72–18,36%, opóźnienie end-to-end około 16%, przepustowość wejściowa około 20%

• Wejście 235K, rozmiar partii 1 — TTFT poprawił się o 14,63–14,71%, opóźnienie end-to-end około 14%, przepustowość wejściowa około 17%

• Wejście 32K, rozmiar partii 4 — TTFT poprawiony o 18,74%, opóźnienie end-to-end o 18,14%, przepustowość wejściowa o 22,14%

• Pamięć szczytowa — spadek o około 1,0 GiB na GPU

Dekodowanie, rozmiar partii 1 — czas na token wyjściowy praktycznie bez zmian

Ostatnią linijkę trzeba przeczytać dwa razy, a autor otwarcie mówi dlaczego: ta optymalizacja jest włączona tylko dla prefill, więc dekodowanie pojedynczego strumienia nie zyskuje na niej nic. Poprawa czasu na token przy batchu 4, tam gdzie występuje, odzwierciedla zmniejszone opóźnienia planowania wynikające z równoczesnych długich faz prefill, a nie szybszy kernel dekodowania. Jeśli mieliście nadzieję, że to opowieść o przepustowości, to nie — to opowieść o opóźnieniu do pierwszego tokenu i o pamięci, a te dwa ograniczenia decydują, czy żądanie o rozmiarze 235K tokenów da się w ogóle obsłużyć.

Błąd układu, który musieli najpierw naprawić

Najbardziej informacyjną częścią tego pull requesta nie jest tabela przyspieszenia. Jest nią sekcja o fizycznym układzie wierszy PLE, ponieważ pokazuje, co stos serwujący Qwen4Exp wciąż robi źle.

Per-Layer Embedding działa na stałym fizycznym buckecie grafu CUDA, podczas gdy tylko prefiks wierszy w tym buckecie może przechowywać rzeczywiste tokeny. Dopełnienie musi zatem zostać zastosowane, zanim sekwencja zostanie podzielona na shardy, a nie po. W końcowym fragmencie żądania o 235K tokenów, liczby autora to 5 624 przetworzonych tokenów w fizycznym buckecie o 8 192 wierszach przy TP 4, a jedynym poprawnym układem jest ranga 0 przechowująca 2 048 prawidłowych wierszy, ranga 1 przechowująca 2 048 prawidłowych wierszy, ranga 2 przechowująca 1 528 prawidłowych wierszy plus 520 wierszy dopełnienia, oraz ranga 3 przechowująca 2 048 wierszy dopełnienia. Podzielenie najpierw 5 624 przetworzonych wierszy — oczywista implementacja — wstawia dopełnienie między globalnie ciągłe prawidłowe zakresy i psuje wynik. Autor odnotowuje, że prawdziwy test 235K OFF/ON dał identyczne 16-tokenowe zachłanne wyjście dopiero po poprawieniu tego układu.

To drobny szczegół o dużym znaczeniu. Ścieżka PLE w SGLang została dodana tak niedawno, że wciąż można było napotkać błąd w kolejności tokenów tego typu, a osoba, która go znalazła, pisała rozszerzenie sequence-parallel. Wsparcie serwowania tej architektury od dnia zerowego nie jest ukończone; jest aktywnie budowane publicznie przez współtwórców, układ po układzie.

Co cię to kosztuje: ograniczenia

Flaga, która pomaga tylko niektórym wdrożeniom, jest użyteczna tylko wtedy, gdy wiesz którym. PR wyraźnie określa swoje wymagania, a konfiguracje poza nimi kończą się niepowodzeniem podczas walidacji argumentów, zamiast po cichu się degradować:

• Rozmiar równoległości tensorowej musi być większy niż 1 — wdrożenie na pojedynczym GPU nic nie daje, ponieważ nie ma rang, na które można by podzielić

• Rozmiar równoległości ekspertów musi być równy rozmiarowi równoległości tensorowej

• Rozmiar równoległości potokowej musi wynosić 1

• Uwaga równoległa względem danych musi być wyłączona

• Dekodowanie spekulacyjne musi być wyłączone

Ostatnie ograniczenie jest tym, za którym stoi prawdziwa decyzja. Dla rzadkiego modelu, który aktywuje około 6B parametrów na token, dekodowanie spekulatywne jest jedną z niewielu dźwigni, które przyspieszają dekodowanie, a ta funkcja jawnie wyłącza tę dźwignię w zamian za zysk w prefillu. Jeśli Twoje obciążenie to długi prompt i krótkie wyjście — analiza dokumentów i bazy kodu, streszczanie wideo, duży kontekst czytany raz — wymiana jest po prostu dobra. Jeśli Twoje obciążenie to krótki prompt i długa generacja, rezygnujesz z rzeczy, która Ci pomagała, i kupujesz liczbę, która Cię nie dotyczy. Wymóg, aby parallelizm ekspertów równał się parallelizmowi tensorowemu, jest drugim, na który warto zwrócić uwagę: oznacza to, że geometria shardingu MoE musi dokładnie pokrywać się z geometrią TP, co wyklucza kilka skądinąd rozsądnych układów wielowęzłowych.

Co to mówi o harmonogramie Qwen 4

Spójrz na ten diff inaczej, a zobaczysz kalendarz. Moduł LayerNorm-SP w SGLang na gałęzi main zawiera dziś jawną listę dozwolonych architektur, dla których tę funkcję zweryfikowano, i w chwili pisania tego tekstu lista ta zawiera dokładnie jeden wpis, Qwen3ForCausalLM — każda inna architektura jest odrzucana już na etapie konstrukcji, jeśli przekażesz tę flagę. Dodanie Qwen4Exp do tej ścieżki nie jest więc drobną modyfikacją dojrzałej abstrakcji; to pierwszy raz, gdy architektura Qwen4 trafia do optymalizacji, która powstała o kilka generacji wcześniej.

Zestaw to z publicznie dostępnymi informacjami, a obraz układanki staje się spójny. Dostawca ogłosił 2026-09-22, że Qwen 4 jest w trakcie treningu, i przedstawił podglądowo cztery nazwy poziomów — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus i Qwen 4 27B — nie dołączając do żadnej z nich żadnych specyfikacji. Otwartowagowa wersja preview współdzieląca tę architekturę, Qwen3.8-Flash-Next, jest dostępna do pobrania od 2026-08-26. To, co dzieje się przez trzy tygodnie od tamtej pory, jest dokładnie tym, czego można się spodziewać między „w trakcie treningu” a „premierą”: autorzy silników dopracowują środowisko uruchomieniowe, aby wsparcie od dnia zerowego było rzeczywiste, a nie nominalne. Pull request, który sprawia, że optymalizacja obsługi działa na tej architekturze, otwarty rankiem 2026-10-08 i wciąż w wersji roboczej, jest lepszym sygnałem co do tego, jak blisko Qwen 4 jest do tego, by można go było serwować, niż jakakolwiek data, którą ktokolwiek podał. To także, z całą stanowczością, nie jest data premiery — flaga jest domyślnie wyłączona, zmiana nie została scalona, a model, na którym przeprowadzono benchmark, to wersja preview, a nie Qwen 4.

Co możesz dziś nazwać

Co jednak nie zmienia tego, co jest faktycznie dostępne dziś po południu. Qwen3.8-Flash-Next istnieje naprawdę, jego wagi są na Hugging Face i możesz hostować go samodzielnie — ale nie ma go w naszym katalogu i nie będziemy udawać, że jest inaczej. Warstwa, którą faktycznie oferujemy, to qwen/qwen3.8-flash, zarządzane bliźniacze rozwiązanie działające na tej samej architekturze Qwen4-preview, z oknem kontekstu 1 mln tokenów oraz wejściem tekstowym, obrazowym i wideo, w cenie 0,15 USD za milion tokenów wejściowych, 0,47 USD za milion tokenów wyjściowych i 0,0184 USD za milion odczytów z pamięci podręcznej. To cena katalogowa przekazywana bez marży (0%), więc gdy dostawca ją zmieni, liczba na Twojej fakturze zmieni się tego samego dnia, a nie wtedy, gdy pośrednik zaktualizuje swoją tabelę.

Jest jeszcze drugi, mniej oczywisty powód, by zwrócić tu uwagę na warstwę routingu. Wszystko w tym artykule dotyczy niesprawdzonej wersji zapoznawczej plus roboczej łatki — czegoś, co chcesz przetestować, nie stawiając na tym ścieżki produkcyjnej. Po to właśnie jest przełączanie awaryjne: ustaw wersję zapoznawczą pod tym samym kluczem co model, któremu już ufasz, obserwuj, jak zachowuje się na Twoim ruchu, i pozwól, aby żądanie przełączyło się na sprawdzoną trasę, gdy dostawca szwankuje albo punkt końcowy jest niedostępny.Jedno API do ponad 200 modeli, jeden zestaw poświadczeń, bez podpisywania drugiej umowy, aby przekonać się, czy nowa architektura jest warta Twojej uwagi.

Dwie rzeczy, na które warto stąd patrzeć, z których żadnej nie możemy przewidzieć. Pierwsza to, czy ta łatka w ogóle zostanie scalona: to wersja robocza z trzema nieudanymi przebiegami CI przy zmianie obejmującej sześć plików, zgłoszona z konta współtwórcy bez wcześniejszej historii w repozytorium, a zmienność prac nad układem wierszy PLE sugeruje, że autor wciąż iteruje. Druga to, czy lista dozwolonych rośnie — jeśli Qwen4Exp dołączy do Qwen3ForCausalLM jako zweryfikowana architektura, to przestaje to być przeciek i staje się domyślnym sposobem, w jaki model z rodziny Qwen4 jest obsługiwany na długim kontekście. Dopóki jedna z nich nie nastąpi, traktuj 18% jako obietnicę tego, dokąd zmierza środowisko uruchomieniowe, a nie liczbę, którą można wynająć.