Qwen 4-lek: SGLang's Host-Staging-PR laat zien hoe de PLE-tabel van 47,7 GiB op één GPU past

Het getal dat bepaalt of Qwen 4 een model is dat je zelf kunt serveren, is niet het aantal parameters. Het is 47,7 GiB — de grootte van de n-gram-embeddingtabel die naast de Qwen4-architectuur meegaat, los van de gewichten, en ergens moet leven terwijl het model decodeert. Een pull request die op 18 september 2026 in de SGLang-repository is geopend, met de titel [Qwen4-Exp] Host-staging toevoegen voor bestandsgebaseerde PLE, is een poging om te voorkomen dat die tabel bepaalt hoeveel RAM een machine nodig heeft voordat hij überhaupt kan draaien. Qwen 4 is nog steeds niet uitgebracht: geen modelcard, geen gewichten, geen catalogusvermelding, geen datum. Het enige uitgebrachte model dat deze architectuur instantieert, is Qwen3.8-Flash-Next, de open-weight preview die op 26 augustus 2026 is gepubliceerd, en waarvan de configuratie model_type=qwen4_exp aangeeft — dezelfde string die de pull request zijn naam geeft. Het productiebroertje Qwen3.8-Flash is de versie die een API-gebruiker vandaag daadwerkelijk kan bereiken. Alles in dit stuk over Qwen 4 is een gevolgtrekking uit die preview en uit enginecode; de pull request is open en niet samengevoegd, dus lees het allemaal als een signaal, niet als een uitgebrachte capaciteit.

Wat het signaal eigenlijk is

Pull request sgl-project/sglang#40235 is geen release en is niet gemerged. Het staat op één commit, geopend door bijdrager Dev-Jahn, die een branch met de naam task/ple-host-staged samenvoegt in de hoofdlijn van SGLang. Er zijn negen code owners aangevraagd voor review en allemaal staan ze op 'wachtend', dus minstens één goedkeurende review staat tussen dit en main. Drie CI-jobs — de basis-PR-test, de extra PR-test en de AMD ROCm-run — falen op de open commit. Dat is de normale toestand van een grote enginewijziging in ontwikkeling, en het is ook de reden waarom het interessante deel van deze PR niet is of hij landt, maar wat de auteur moest meten om het te bepleiten De beschrijving bevat ongeveer 1.400 toegevoegde regels, inclusief tests, en een benchmarktabel die de meest concrete openbare data is die iemand heeft gepubliceerd over het draaien van deze architectuur op één GPU.

Waarom de tabel het hele verhaal is

Per-Layer Embeddings zijn de structurele eigenaardigheid van deze generatie. Waar een normaal model één token-embedding vooraan plaatst, draagt het Qwen4-ontwerp een grote n-gramtabel — bigrammen en trigrammen, gehasht naar een vocabulaire die veel groter is dan die van de tokenizer — en voedt daarmee door de hele stack heen per-laag embedding-lookups. Alibaba's eigen previewmateriaal beschrijft de n-gramcomponent als tientallen miljarden parameters bovenop het MoE-lichaam van 125 miljard parameters; community-teardowns van de vrijgegeven checkpoint schatten het tabelbestand op 47,7 GiB. Die cijfers komen van leveranciers- en communitybronnen in plaats van uit onafhankelijke reproductie, en de exacte relatie tussen de tabel uit de preview en wat Qwen 4 ook daadwerkelijk uitlevert, is onbekend.

Wat buiten kijf staat, is de technische consequentie. Een zijtabel van 47,7 GiB die bij elke decodeerstap moet worden geraadpleegd, is niet iets dat je rustig in een hoekje van het VRAM kunt wegzetten. Op een kaart van 96 GB concurreert die rechtstreeks met de KV-cache; op kleinere kaarten past die simpelweg niet. Daarom heeft SGLang, dat eind augustus day-0-ondersteuning voor de preview opzette, de daaropvolgende drie weken de ene pull request na de andere geproduceerd over deze ene datastructuur in plaats van over het model eromheen.

Wat was er kapot vóór deze PR

SGLang had al twee manieren om de tafel vast te houden, en beide hadden een harde rand.

• Pinned houdt de hele tabel in het host-RAM en leest die daaruit. Het werkt, het is snel, en het maakt de host-geheugenvereiste absoluut — er bestaat geen kleinere versie van.

• Bestandsgebaseerd, eerder toegevoegd in een aparte pull request, houdt de tabel in een sparse bestand en laat de gather-kernel de mapping rechtstreeks lezen, zodat de page cache van het besturingssysteem bepaalt welk deel ervan resident is. Het addertje zit hem in de hardware: dat rechtstreekse leespad vereist dat de GPUcudaDevAttrPageableMemoryAccessUsesHostPageTables rapporteert — de capaciteit die de tekst van de PR zelf omschrijft als "de GB10-klasse". Op een GPU zonder die capaciteit wordt de file-backend botweg geweigerd en is pinned de enige optie die overblijft.

Het gat dat hierdoor ontstaat is niet theoretisch. Een afzonderlijk rapport over hetzelfde codepad documenteert een gebruiker met twee RTX 3090's van wie het aandeel per rank in de tabel uitkwam op 23,84 GiB tegenover 23,56 GiB bruikbaar geheugen — 0,28 GiB tekort, terwijl er 188 GiB aan host-RAM vrij stond. In die configuratie werd de bestandsbackend door de hardwarecontrole afgewezen en geeft de gewone CPU-offloadflag een foutmelding in combinatie met de PLE-offloadflag. Driehonderd megabyte tekortkomen terwijl er honderdtachtig gigabyte over is, is precies het soort probleem dat deze pull request beoogt weg te nemen.

Welke wijzigingen in host-staging

Het mechanisme dat de PR toevoegt is een staginglaag tussen het bestand en het apparaat. In plaats van de GPU te vragen hostpagina's te derefereren, leest een component aan de CPU-zijde de rijen die het nodig heeft via de bestaande mapping van de loader en adviseert de kernel om die pagina's vooraf binnen te halen; een omgevingsvariabele, SGLANG_QWEN4_PLE_FILE_PREFETCH, schakelt het advies uit als je zonder dit wilt meten. Elke PLE-laag krijgt dan twee gepinde buffers van 8.192 rijen — ongeveer 1,25 MiB per stuk bij FP8 — en één worker. Rijen worden in de ene buffer verzameld terwijl de andere naar het apparaat wordt gekopieerd, zodat het verzamelen en de overdracht elkaar overlappen in plaats van te serialiseren. N-gram-identificaties worden op de host gehasht in plaats van op het apparaat. Graph-replay krijgt een voorbereidingsaanroep vóór elke replay, en de lancerende thread wacht op de vorige stap.

Dat laatste detail is de kostprijs, en de PR zegt het ronduit: ongeveer 0,5 tot 1 milliseconde toegevoegd per decodestap ten opzichte van het vastgezette pad. Al het overige is de opbrengst. Gemeten op één RTX PRO 6000 Blackwell met 96 GB, een AMD EPYC-host met 377 GiB RAM, CUDA 13.2, met de publieke FP8- en NVFP4-checkpoints van Qwen3.8-Flash-Next:

• Host-paginacache, FP8 TP4/EP4 — 71 GB vastgezet en zonder limiet, tegenover 49 GB bij een limiet van 64 GB, 15 GB bij 32 GB, en 6 GB bij een limiet van 24 GB

• Decode-latentie, dezelfde runs — 8,62 ms per token bij concurrency 1 vastgezet, tegenover 9,16 / 9,20 / 9,12 ms over de drie capped file-runs

• Concurrency 16 — 16,54 ms gepind tegenover 17,62 / 17,85 / 17,37 ms met limiet, wat neerkomt op een daling van 893 tokens per seconde naar 827–840

• Prefill-doorvoer — 620 tokens per seconde bij 8k vastgezet versus 624 / 630 / 631 begrensd; bij 32k, 1.347 versus 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB vastgezet versus 24 GB met de bestandsbackend bij een limiet van 32 GB, bij 8,87 ms versus 9,18 ms

• Single-GPU NVFP4 — 69 GB gepind versus 51 GB bij een limiet van 64 GB, bij 6,44 ms versus 6,73 ms

• Het alternatief dat het verslaat — het lezen van hetzelfde bestand via hostgeheugenbeheer op die GPU gaf 10,8 ms bij concurrency 1 en 46,5 ms bij concurrency 16, wat in de PR wordt omschreven als 2,8× de pinned latency bij die concurrency

De nauwkeurigheidskant wordt als schoon gerapporteerd. Deterministische greedy-uitvoer over acht prompts van 256 tokens was token-identiek tussen de gepinde en de bestandspaden op FP8 TP4, en GSM8K kwam uit op 97,6% gepind tegen 98,0% bestand bij de limiet van 64 GB — een gat van zes vragen dat de auteur toeschrijft aan variatie van run tot run in plaats van aan het offload-pad. Al deze cijfers zijn van de auteur van de pull request zelf, één keer gemeten, op één machine, en niemand heeft ze gereproduceerd.

De kosten die de PR toegeeft

Een eerlijke lezing van deze pull request omvat ook wat hij weigert te doen. Verschillende uitvoeringsmodi worden bij het samenstellen afgewezen in plaats van stilzwijgend afgezwakt, en bij elke afwijzing wordt de vastgezette backend als terugvaloptie genoemd: prefill-CUDA-graphs, dataparallelle attention, het multiplexpad voor prefill-decode, overlap van twee batches, de DLLM-decodegraphs en compacte ragged verify-graphs vallen allemaal af. Even belangrijk: er komt geen nieuwe flag en geen nieuwe gebruikersgerichte schakelaar bij — het staging-pad is wat de file-backend doet op hardware die het voorheen helemaal niet kon gebruiken. En de nauwkeurigheidsrun bevat een voorbehoud dat de auteur zelf aanvoert: de begrensde runs hadden nooit de volledige tabel in het geheugen, omdat de tabel 47,7 GiB is en de limieten tot 24 GB omlaaggaan, dus een workload met een werkelijk vlak, onvoorspelbaar toegangspatroon over de hele tabel is niet wat er is gemeten.

Waarom dit specifiek van belang is voor Qwen 4

Zet de engine-details opzij en het patroon wordt leesbaar. Alibaba bracht op 26 augustus een architectuurpreview uit, met instructies voor de open-sourcegemeenschap om runtimes, kwantisatie en inference-engines voor te bereiden vóór de volledige familie. SGLang deed dat, en besteedde vervolgens drie weken aan het indienen van pull requests over de ene component die de architectuur lastig te deployen maakt. Als voorspelling gelezen is dat een uitspraak over wat Qwen 4 van je hardware zal vragen, niet over wat het op een benchmark kan.

Het verscherpt ook de tijdlijnkwestie. Qwen 4 is nog niet uitgebracht, en de speculatie in september daarover wijst naar Alibaba's Apsara Conference op 22–24 september in Hangzhou — de locatie waar eerdere Qwen-generaties werden aangekondigd. Niets daarvan is bevestigd, en het patroon uit de laatste previewcyclus is dat een architectuurpreview maanden vóór de volledige familie komt, niet weken. Een pull request die drie dagen vóór die conferentie wordt geopend, is veelzeggend en niets meer.

De eerlijke samenvatting van waar dit een lezer achterlaat: Qwen 4 bestaat niet, Qwen3.8-Flash-Next wel, en de tweede vertelt je wat het je kost om de eerste te draaien. Als de 47,7 GiB-tabel qua effectieve voetafdruk blijft krimpen — en drie weken aan pull requests zeggen dat er hard aan wordt gewerkt — dan ligt de drempel voor het uitrollen van de Qwen 4-familie lager dan de lanceringsweek van de preview deed vermoeden.

Wat je hier vandaag daadwerkelijk mee kunt doen

Niets in deze pull request is beschikbaar op main, en het model waarop hij zich richt, is niet iets dat je via een API kunt aanroepen. Het open-weight Qwen3.8-Flash-Next-checkpoint is een self-hostingverhaal: je haalt de weights op, je serveert ze zelf, en het bestandsgebaseerde PLE-pad is waar je over leest. Het wordt hier niet gerouteerd. Wat wel gerouteerd wordt, is de productievariant — Qwen3.8-Flash, bereikbaar als qwen/qwen3.8-flash voor $0,15 per miljoen invoertokens en $0,47 per miljoen uitvoertokens, met een context van 1M tokens en tekst-, beeld- en video-invoer — en het grotere Qwen3.8-Max voor $2,00 en $6,00.

Dat onderscheid is het nuttige voor een lezer die beslist wat hij deze week moet doen. De preview is onderzoek dat je zelf uitvoert; de geserveerde variant is het productiepad van dezelfde architectuur, en die is één endpoint verwijderd. OrcaRouter geeft de lijstprijs van de provider door tegen 0% opslag, dus een prijswijziging van een leverancier op dat endpoint is dezelfde dag zichtbaar in plaats van bij de volgende factureringscyclus, en elk model op de sleutel is bereikbaar via één OpenAI-compatibele base-URL in plaats van een apart contract, SDK en credential per leverancier. Voor een architectuur die zo jong is — waarbij het engine-werk nog wekelijks landt en de roadmap niet is gepubliceerd — is automatische failover tussen providers de praktische manier om van de geserveerde variant afhankelijk te zijn zonder een productiepad te wedden op de uptime van één enkele provider. Dat alles gaat over de modellen die je vandaag kunt aanroepen. Het zegt niets over Qwen 4, dat daar niet een van is.

Wat we nog niet weten

Of Qwen 4 dezelfde tabel op dezelfde grootte zal uitbrengen. Of de pull request überhaupt wordt samengevoegd — er zijn drie mislukte CI-runs en nog geen reviews. Of de penalty van 0,5 tot 1 milliseconde per stap standhoudt buiten de configuraties met lage gelijktijdigheid van de auteur. En of Alibaba op 22 september iets zegt tijdens Apsara. Op basis van het huidige bewijsmateriaal is het veiligste dat je over Qwen 4 kunt concluderen niet wat het scoort, maar hoeveel machinerie de industrie aan het bouwen is, louter om het te laten passen — wat op zichzelf iets nuttigs is om te weten voordat het model een naam heeft in welke catalogus dan ook.