Wyciek Qwen 4: PR SGLang dotyczący host-stagingu pokazuje, jak tabela PLE o rozmiarze 47,7 GiB mieści się na jednym GPU

Liczba, która zdecyduje, czy Qwen 4 jest modelem, który możesz obsłużyć samodzielnie, to nie liczba jego parametrów. To 47,7 GiB — rozmiar tablicy osadzeń n-gramów, która towarzyszy architekturze Qwen4, oddzielonej od wag, i musi gdzieś istnieć, gdy model dekoduje. Pull request otwarty w repozytorium SGLang 18 września 2026 r., zatytułowany [Qwen4-Exp] Dodaj staging na hoście dla PLE opartego na plikach, to próba powstrzymania tej tablicy przed dyktowaniem, ile pamięci RAM potrzebuje maszyna, zanim w ogóle zacznie działać. Qwen 4 wciąż nie został wydany: brak karty modelu, brak wag, brak wpisu w katalogu, brak daty. Jedynym wydanym modelem, który urzeczywistnia tę architekturę, jest Qwen3.8-Flash-Next, wersja preview z otwartymi wagami opublikowana 26 sierpnia 2026 r., której konfiguracja deklaruje model_type=qwen4_exp — ten sam ciąg, który nadaje nazwę pull requestowi. Jego produkcyjny odpowiednik Qwen3.8-Flash to wersja, do której wywołujący API może dziś faktycznie dotrzeć. Wszystko w tym tekście o Qwen 4 to wnioski wyciągnięte z tej wersji preview i z kodu silnika; pull request jest otwarty i nie został scalony, więc czytaj to wszystko jako sygnał, a nie jako wdrożoną funkcję.

Czym naprawdę jest sygnał

Pull request sgl-project/sglang#40235 nie jest premierą i nie został scalony. Opiera się na jednym commicie, otwarty przez współtwórcę Dev-Jahn, scalający gałąź o nazwie task/ple-host-staged do głównej linii SGLang. Dziewięciu właścicieli kodu zostało poproszonych o recenzję i wszyscy widnieją jako oczekujący, więc co najmniej jedna zatwierdzająca recenzja stoi między tym a gałęzią main. Trzy zadania CI — podstawowy test PR, dodatkowy test PR i uruchomienie AMD ROCm — kończą się niepowodzeniem na otwartym commicie. Taki jest normalny stan dużej zmiany w silniku w toku i dlatego najciekawsze w tym PR nie polega na tym, czy zostanie scalony, lecz na tym, co jego autor musiał zmierzyć, aby to uzasadnić. Opis zawiera około 1400 dodanych linii, w tym testy, oraz tabelę benchmarków, która jest najbardziej konkretnymi publicznymi danymi, jakie ktokolwiek opublikował na temat uruchamiania tej architektury na pojedynczym GPU.

Dlaczego stół to cała historia

Osadzenia na warstwę są strukturalną osobliwością tej generacji. Podczas gdy zwykły model umieszcza jedno osadzenie tokenu na początku, projekt Qwen4 zawiera dużą tablicę n-gramów — bigramów i trigramów, haszowanych do słownika znacznie większego niż słownik tokenizatora — i przez cały stos zasila z niej wyszukiwania osadzeń na warstwę. Materiały zapowiedzi samej Alibaby opisują komponent n-gramowy jako dziesiątki miliardów parametrów na dodatek do 125B-parametrowego trzonu MoE; społecznościowe analizy udostępnionego checkpointu szacują rozmiar pliku tablicy na 47,7 GiB. Liczby te pochodzą od dostawcy i ze źródeł społecznościowych, a nie z niezależnego odtworzenia, a dokładny związek między tablicą z zapowiedzi a tym, co zostanie wydane jako Qwen 4, nie jest znany.

Nie ulega wątpliwości, jaka jest konsekwencja inżynieryjna. Tabela pomocnicza o rozmiarze 47,7 GiB, do której trzeba zaglądać przy każdym kroku dekodowania, nie jest czymś, co można po cichu wepchnąć w kąt VRAM. Na karcie 96 GB konkuruje bezpośrednio z pamięcią podręczną KV; na mniejszych kartach po prostu się nie mieści. Dlatego SGLang, który zapewnił wsparcie od pierwszego dnia dla wersji zapoznawczej pod koniec sierpnia, spędził kolejne trzy tygodnie, tworząc jeden pull request po drugim dotyczący tej jednej struktury danych, a nie modelu wokół niej.

Co było zepsute przed tym PR-em?

SGLang miał już dwa sposoby na utrzymanie tabeli, a oba miały twardą krawędź.

• Tryb przypięty przechowuje całą tabelę w pamięci RAM hosta i odczytuje ją stamtąd. Działa, jest szybki i sprawia, że wymagania dotyczące pamięci hosta są bezwzględne — nie istnieje mniejsza wersja tego rozwiązania.

• Oparte na plikach, dodane wcześniej w osobnym pull requeście, przechowuje tablicę w pliku rzadkim i pozwala kernelowi gather odczytać mapowanie bezpośrednio, dzięki czemu to pamięć podręczna stron systemu operacyjnego decyduje, jak duża część tablicy jest rezydentna. Haczyk jest natury sprzętowej: ta ścieżka bezpośredniego odczytu wymaga, aby GPU zgłaszało cudaDevAttrPageableMemoryAccessUsesHostPageTables — możliwość, którą sam tekst PR-a opisuje jako „klasa GB10”. Na GPU, które jej nie ma, backend plikowy jest kategorycznie odrzucany i pozostaje tylko opcja pinned.

Powstała w ten sposób luka nie jest teoretyczna. Osobne zgłoszenie złożone wobec tej samej ścieżki kodu dokumentuje użytkownika na dwóch kartach RTX 3090, u którego udział w tabeli przypadający na rank wyniósł 23,84 GiB wobec 23,56 GiB dostępnej pamięci — brakowało 0,28 GiB, a 188 GiB pamięci RAM hosta pozostawało wolne. W tej konfiguracji backend plikowy został odrzucony przez kontrolę sprzętową, a zwykła flaga CPU-offload zgłasza wyjątek w połączeniu z flagą PLE offload. Brak trzystu megabajtów przy stu osiemdziesięciu gigabajtach zapasu to dokładnie ten rodzaj problemu, który ten pull request ma wyeliminować.

Jakie zmiany w host staging?

Mechanizm, który dodaje ten PR, to warstwa stagingowa między plikiem a urządzeniem. Zamiast prosić GPU o dereferencję stron hosta, komponent działający po stronie CPU odczytuje potrzebne wiersze przez istniejące mapowanie loadera i doradza jądru wciągnięcie tych stron z wyprzedzeniem; a zmienna środowiskowa, SGLANG_QWEN4_PLE_FILE_PREFETCH, wyłącza tę podpowiedź, jeśli chcesz mierzyć bez niej. Każda warstwa PLE otrzymuje następnie dwa przypięte bufory po 8 192 wiersze — około 1,25 MiB każdy przy FP8 — oraz jednego workera. Wiersze są gromadzone w jednym buforze, podczas gdy drugi jest kopiowany do urządzenia, dzięki czemu gromadzenie i transfer nakładają się, zamiast odbywać się szeregowo. Identyfikatory n-gramów są haszowane na hoście, a nie na urządzeniu. Odtwarzanie grafu otrzymuje wywołanie przygotowujące przed każdym odtworzeniem, a wątek uruchamiający czeka na poprzedni krok.

Ten ostatni szczegół to koszt, a PR mówi o tym wprost: około 0,5 do 1 milisekundy dodanej na krok dekodowania względem przypiętej ścieżki. Cała reszta to zysk. Zmierzono na pojedynczym RTX PRO 6000 Blackwell z 96 GB, hoście AMD EPYC z 377 GiB RAM, CUDA 13.2, przy użyciu publicznych checkpointów FP8 i NVFP4 modelu Qwen3.8-Flash-Next:

• Pamięć podręczna stron hosta, FP8 TP4/EP4 — 71 GB przypięte i bez limitu, w porównaniu z 49 GB przy limicie 64 GB, 15 GB przy 32 GB i 6 GB przy limicie 24 GB

• Opóźnienie dekodowania, te same przebiegi — 8,62 ms na token przy concurrency 1 (pinned), w porównaniu z 9,16 / 9,20 / 9,12 ms w trzech przebiegach z ograniczonym plikiem

• Współbieżność 16 — 16,54 ms w trybie pinned w porównaniu z 17,62 / 17,85 / 17,37 ms w trybie capped, co oznacza spadek z 893 tokenów na sekundę do 827–840

• Przepustowość prefill — 620 tokenów na sekundę przy 8k z przypięciem w porównaniu z 624 / 630 / 631 z ograniczeniem; przy 32k, 1,347 w porównaniu z 1,358 / 1,359 / 1,361

• NVFP4 TP2 — 69 GB przypięte wobec 24 GB z backendem plikowym przy limicie 32 GB, przy 8,87 ms wobec 9,18 ms

• NVFP4 na pojedynczym GPU — 69 GB pamięci przypiętej wobec 51 GB przy limicie 64 GB, przy 6,44 ms wobec 6,73 ms

• Alternatywa, którą przebija — odczyt tego samego pliku przez zarządzanie pamięcią hosta na tym GPU dał 10,8 ms przy współbieżności 1 i 46,5 ms przy współbieżności 16, co PR opisuje jako 2,8× opóźnienia pamięci przypiętej przy tej współbieżności

Stronę dokładności raportuje się jako bez zastrzeżeń. Deterministyczne, zachłanne wyjście dla ośmiu promptów o długości 256 tokenów było identyczne co do tokenów między ścieżką pinned a ścieżką file na FP8 TP4, a GSM8K wypadł na poziomie 97,6% dla pinned wobec 98,0% dla file przy limicie 64 GB — różnica sześciu pytań, którą autor przypisuje zmienności między uruchomieniami, a nie ścieżce offloadu. Wszystkie te liczby pochodzą od samego autora pull requesta, zostały zmierzone jednokrotnie, na jednej maszynie, i nikt ich nie odtworzył.

Koszty, do których przyznaje się PR

Rzetelna lektura tego pull requesta obejmuje także to, czego on odmawia zrobienia. Kilka trybów wykonania jest odrzucanych już na etapie konstrukcji, a nie po cichu degradowanych, i każde odrzucenie wskazuje przypięty backend jako rozwiązanie zapasowe: prefill CUDA graphs, data-parallel attention, ścieżka multipleksowania prefill-decode, nakładanie się dwóch batchy, grafy dekodowania DLLM oraz kompaktowe grafy weryfikacji ragged — wszystkie są wykluczone. Równie istotne jest to, że nie dodaje żadnej nowej flagi ani żadnego nowego przełącznika widocznego dla użytkownika — ścieżka staging to po prostu to, co robi backend plikowy na sprzęcie, który wcześniej w ogóle nie mógł z niej korzystać. A przebieg dokładnościowy niesie zastrzeżenie, które autor podaje dobrowolnie: przebiegi z ograniczeniami nigdy nie trzymały całej tabeli, ponieważ tabela ma 47,7 GiB, a ograniczenia schodzą aż do 24 GB, więc mierzono coś innego niż obciążenie o naprawdę płaskim, nieprzewidywalnym wzorcu dostępu do całej tabeli.

Dlaczego ma to szczególne znaczenie właśnie dla Qwen 4

Odłóż na bok szczegóły silnika, a wzorzec staje się czytelny. Alibaba opublikowała 26 sierpnia zapowiedź architektury wraz z instrukcjami dla społeczności open source, jak przygotować środowiska uruchomieniowe, kwantyzację i silniki wnioskowania przed pełną rodziną. SGLang to zrobił, a następnie spędził trzy tygodnie na zgłaszaniu pull requestów dotyczących tego jednego komponentu, który sprawia, że architektura jest trudna do wdrożenia. Odczytane jako prognoza, to stwierdzenie o tym, czego Qwen 4 będzie potrzebować od twojego sprzętu, a nie o tym, co potrafi osiągnąć w benchmarku.

To dodatkowo wyostrza kwestię harmonogramu. Qwen 4 nie został wydany, a wrześniowe spekulacje wokół niego wskazują na konferencję Apsara Conference firmy Alibaba w dniach 22–24 września w Hangzhou — miejsce, w którym ogłaszano poprzednie generacje Qwen. Nic z tego nie zostało potwierdzone, a wzorzec z ostatniego cyklu zapowiedzi jest taki, że zapowiedź architektury poprzedza pełną rodzinę o miesiące, a nie tygodnie. Pull request otwarty trzy dni przed tą konferencją daje do myślenia i nic ponadto.

Uczciwe podsumowanie tego, w jakim miejscu stawia to czytelnika: Qwen 4 nie istnieje, Qwen3.8-Flash-Next istnieje, a ten drugi mówi ci, ile będzie cię kosztowało uruchomienie pierwszego. Jeśli efektywny ślad tabeli 47,7 GiB stale się zmniejsza — a trzy tygodnie pull requestów świadczą, że pracuje się nad tym intensywnie — to próg wdrożenia dla rodziny Qwen 4 jest niższy, niż sugerował tydzień premiery wersji zapoznawczej.

Co tak naprawdę możesz z tym dzisiaj zrobić

Nic z tego pull requesta nie jest dostępne na main, a model, którego dotyczy, nie jest czymś, co można wywołać przez API. Otwarty checkpoint Qwen3.8-Flash-Next to historia self-hostingu: pobierasz wagi, sam je serwujesz, a ścieżka PLE oparta na plikach to właśnie to, o czym czytasz. Nie jest tu routowany. To, co jest routowane, to wariant produkcyjny — Qwen3.8-Flash, dostępny jako qwen/qwen3.8-flash w cenie 0,15 USD za milion tokenów wejściowych i 0,47 USD za milion wyjściowych, z kontekstem 1 mln tokenów oraz wejściem tekstowym, obrazowym i wideo — a także większy Qwen3.8-Max w cenie 2,00 USD i 6,00 USD.

To rozróżnienie jest tym użytecznym dla czytelnika, który decyduje, co zrobić w tym tygodniu. Wersja zapoznawcza to badania, które prowadzisz samodzielnie; udostępniany wariant to produkcyjna ścieżka tej samej architektury i dzieli go od ciebie jeden endpoint. OrcaRouter przekazuje ceny katalogowe dostawców przy 0% marży, więc zmiana ceny dostawcy na tym endpoincie pojawia się tego samego dnia, a nie dopiero w następnym cyklu rozliczeniowym, a każdy model dostępny na kluczu jest osiągalny przez jeden bazowy URL zgodny z OpenAI, zamiast osobnej umowy, SDK i poświadczeń dla każdego dostawcy. W przypadku architektury tak młodej — w której prace nad silnikiem wciąż trafiają do kodu co tydzień, a mapa drogowa nie została opublikowana — automatyczne przełączanie awaryjne między dostawcami to praktyczny sposób, by polegać na udostępnianym wariancie, nie stawiając produkcyjnej ścieżki na dostępność jednego dostawcy. Wszystko to dotyczy modeli, które możesz wywołać już dziś. Nie mówi nic o Qwen 4, który nie należy do nich.

Czego wciąż nie wiemy

Czy Qwen 4 zostanie wydany z tą samą tabelą w tym samym rozmiarze. Czy ten pull request w ogóle zostanie scalony — ma trzy nieudane przebiegi CI i jeszcze żadnych recenzji. Czy kara od 0,5 do 1 milisekundy na krok utrzyma się poza konfiguracjami autora o niskiej współbieżności. I czy Alibaba powie cokolwiek na Apsara 22 września. Na podstawie obecnych dowodów najbezpieczniejszym wnioskiem dotyczącym Qwen 4 nie jest to, jakie wyniki osiąga, lecz to, jak dużo maszynerii branża buduje tylko po to, by go zmieścić — co samo w sobie jest użyteczną rzeczą do wiedzenia, zanim model trafi pod jakąkolwiek nazwą do jakiegokolwiek katalogu.