Qwen 4-läcka: SGLangs Host-Staging-PR visar hur 47,7 GiB PLE-tabellen får plats på en GPU

Talet som kommer att avgöra om Qwen 4 är en modell som du kan serva själv är inte dess parameterantal. Det är 47,7 GiB – storleken på n-gram-inbäddningstabellen som följer med Qwen4-arkitekturen, separat från vikterna, och måste ligga någonstans medan modellen avkodar. En pull request som öppnades i SGLang-repositoriet den 18 september 2026, med titeln [Qwen4-Exp] Lägg till host-staging för filbaserad PLE, är ett försök att hindra den tabellen från att diktera hur mycket RAM en maskin behöver innan den kan köras över huvud taget. Qwen 4 är fortfarande inte släppt: inget modellkort, inga vikter, ingen katalogpost, inget datum. Den enda släppta modellen som instansierar denna arkitektur är Qwen3.8-Flash-Next, förhandsversionen med öppna vikter som publicerades den 26 augusti 2026, vars konfiguration deklarerar model_type=qwen4_exp – samma sträng som ger pull requesten dess namn. Dess produktionssyskon Qwen3.8-Flash är den version en API-anropare faktiskt kan nå i dag. Allt i den här artikeln om Qwen 4 är slutsatser dragna från den förhandsversionen och från engine-koden; pull requesten är öppen och inte sammanslagen, så läs allt som en signal, inte som en levererad funktion.

Vad signalen faktiskt är

Pull-begäran sgl-project/sglang#40235 är inte en lansering och den är inte mergad. Den ligger på en enda commit, öppnad av bidragsgivaren Dev-Jahn, och sammanfogar en gren som heter task/ple-host-staged med SGLangs huvudlinje. Nio kodägare har begärts för granskning och alla visas som väntande, så minst en godkännande granskning står mellan detta och main. Tre CI-jobb – bas-PR-testet, det extra PR-testet och AMD ROCm-körningen – misslyckas på den öppna commiten. Det är det normala tillståndet för en stor motorändring under arbete, och det är också anledningen till att det intressanta med denna PR inte är huruvida den landar utan vad dess författare var tvungen att mäta för att argumentera för den. Beskrivningen innehåller ungefär 1 400 tillagda rader inklusive tester, och en benchmarktabell som är den mest konkreta offentliga datan någon har publicerat om att köra denna arkitektur på en enda GPU.

Varför tabellen är hela historien

Per-Layer Embeddings är den strukturella egendomligheten i den här generationen. Där en normal modell lägger en tokeninbäddning i början bär Qwen4-designen en stor n-gram-tabell – bigram och trigram, hashade till en vokabulär långt större än tokenizerns – och matar in per-lager-inbäddningsuppslagningar från den genom hela stacken. Alibabas eget förhandsvisningsmaterial beskriver n-gram-komponenten som tiotals miljarder parametrar ovanpå MoE-kroppen med 125B parametrar; community-teardowns av den släppta checkpointen anger att tabellfilen är 47,7 GiB. Dessa siffror kommer från leverantörs- och communitykällor snarare än oberoende reproduktion, och det exakta förhållandet mellan förhandsvisningens tabell och vad Qwen 4 faktiskt levererar är okänt.

Det som inte råder något tvivel om är den ingenjörsmässiga konsekvensen. En sidotabell på 47,7 GiB som måste konsulteras vid varje avkodningssteg är inget man tyst kan trycka in i ett hörn av VRAM. På ett 96 GB-kort konkurrerar den direkt med KV-cachen; på mindre kort får den helt enkelt inte plats. Det är därför SGLang, som etablerade stöd från dag 0 för förhandsversionen i slutet av augusti, har tillbringat de följande tre veckorna med att producera den ena pull requesten efter den andra om just denna enda datastruktur i stället för om modellen runt den.

Vad var trasigt innan den här PR:en?

SGLang hade redan två sätt att hålla tabellen, och båda hade en hård kant.

• Pinnat håller hela tabellen i värddatorns RAM och läser den därifrån. Det fungerar, det är snabbt, och det gör kravet på värddatorns minne absolut — det finns ingen mindre version av den.

• Filbaserad, som lades till tidigare i en separat pull request, håller tabellen i en gles fil och låter gather-kärnan läsa mappningen direkt, så att operativsystemets sidcache avgör hur mycket av den som är resident. Haken är av hårdvarukaraktär: den direkta läsvägen kräver att GPU:n rapporterar cudaDevAttrPageableMemoryAccessUsesHostPageTables — den förmåga som PR:ens egen text beskriver som "GB10-klassen". På en GPU utan den avvisas filbackendet direkt och pinned är det enda alternativ som återstår.

Glappet som uppstår är inte teoretiskt. En separat rapport som lämnats in mot samma kodväg dokumenterar en användare med två RTX 3090s vars andel per rank av tabellen uppgick till 23,84 GiB mot 23,56 GiB användbart minne – 0,28 GiB för lite, medan 188 GiB värd-RAM stod ledigt. I den konfigurationen avvisades filbackend av hårdvarukontrollen och den vanliga CPU-offload-flaggan utlöses när den kombineras med PLE-offload-flaggan. Att vara trehundra megabyte kort med hundraåttio gigabyte över är precis den typ av problem som den här pull requesten finns för att ta bort.

Vilka ändringar i värdstaging?

Mekanismen som PR:en lägger till är ett staginglager mellan filen och enheten. I stället för att be GPU:n att dereferera värdminnessidor läser en CPU-sidokomponent de rader den behöver via lastarens befintliga mappning och råder kerneln att hämta in dessa sidor i förväg; en miljövariabel, SGLANG_QWEN4_PLE_FILE_PREFETCH, stänger av rådgivningen om du vill mäta utan den. Varje PLE-lager får sedan två pinnade buffertar med 8 192 rader – cirka 1,25 MiB vardera vid FP8 – och en arbetare. Rader samlas in i en buffert medan den andra kopieras till enheten, så insamlingen och överföringen överlappar i stället för att serialiseras. N-gram-identifierare hashas på värden i stället för på enheten. Grafåteruppspelning får ett förberedelseanrop före varje återuppspelning, och den startande tråden väntar på föregående steg.

Den sista detaljen är kostnaden, och PR:en säger det rakt ut: ungefär 0,5 till 1 millisekund extra per avkodningssteg jämfört med den låsta sökvägen. Allt annat är vinsten. Mätt på en enda RTX PRO 6000 Blackwell med 96 GB, en AMD EPYC-värd med 377 GiB RAM, CUDA 13.2, med de publika FP8- och NVFP4-checkpointarna för Qwen3.8-Flash-Next:

• Host-sidcache, FP8 TP4/EP4 — 71 GB pinnat och utan tak, jämfört med 49 GB vid ett tak på 64 GB, 15 GB vid 32 GB och 6 GB vid ett tak på 24 GB

• Avkodningslatens, samma körningar — 8,62 ms per token vid samtidighet 1 fastlåst, jämfört med 9,16 / 9,20 / 9,12 ms över de tre begränsade filkörningarna

• Concurrency 16 — 16,54 ms pinnad jämfört med 17,62 / 17,85 / 17,37 ms takbegränsad, vilket är 893 tokens per sekund ner till 827–840

• Prefill-genomströmning — 620 tokens per sekund vid 8k låst jämfört med 624 / 630 / 631 begränsat; vid 32k, 1 347 jämfört med 1 358 / 1 359 / 1 361

• NVFP4 TP2 — 69 GB pinnat jämfört med 24 GB med filbackend vid ett tak på 32 GB, vid 8,87 ms jämfört med 9,18 ms

• Single-GPU NVFP4 — 69 GB pinnat mot 51 GB vid ett tak på 64 GB, vid 6,44 ms mot 6,73 ms

• Alternativet som det slår — att läsa samma fil via värddatorns minneshantering på den GPU:n gav 10,8 ms vid samtidighet 1 och 46,5 ms vid samtidighet 16, vilket PR:en beskriver som 2,8× den pinnade latensen vid den samtidigheten

Noggrannhetssidan rapporteras vara felfri. Deterministisk greedy-utdata över åtta promptar med 256 token var tokenidentisk mellan den pinnade vägen och filvägen på FP8 TP4, och GSM8K landade på 97,6 % för den pinnade vägen mot 98,0 % för filvägen vid 64 GB-gränsen – en skillnad på sex frågor som författaren tillskriver variation mellan körningar snarare än offload-vägen. Alla dessa siffror är pull request-författarens egna, uppmätta en gång, på en maskin, och ingen har reproducerat dem.

Kostnaderna som PR medger

En rättvis läsning av den här pull requesten omfattar också vad den vägrar göra. Flera exekveringslägen avvisas vid konstruktion i stället för att tyst degraderas, och varje avvisning anger den pinnade backend:en som reserv: prefill-CUDA-grafer, dataparallell attention, prefill-decode-multiplexeringsvägen, överlappning mellan två batchar, DLLM-avkodningsgraferna och kompakta ragged-verifieringsgrafer är alla uteslutna. Lika viktigt är att den inte lägger till någon ny flagga och ingen ny användarvänd omkopplare – stagingvägen är vad filbackend:en gör på hårdvara som tidigare inte kunde använda den alls. Och noggrannhetskörningen har ett förbehåll som författaren självmant tar upp: de begränsade körningarna rymde aldrig hela tabellen, eftersom tabellen är 47,7 GiB och gränserna går så lågt som 24 GB, så en arbetsbelastning med ett genuint platt, oförutsägbart åtkomstmönster över hela tabellen är inte vad som mättes.

Varför detta är särskilt viktigt för Qwen 4

Skala bort motordetaljerna, och mönstret framträder tydligt. Alibaba släppte en arkitekturförhandsvisning den 26 augusti med instruktioner till öppen källkods-gemenskapen att förbereda körtider, kvantisering och inferensmotorer inför den fullständiga familjen. SGLang gjorde det och ägnade sedan tre veckor åt att skicka in pull requests om den enda komponent som gör arkitekturen besvärlig att driftsätta. Läst som en prognos är det ett uttalande om vad Qwen 4 kommer att kräva av din hårdvara, inte om vad den kan göra i ett benchmark.

Det skärper också frågan om tidslinjen. Qwen 4 har inte släppts, och septemberryktena kring det pekar mot Alibabas Apsara Conference den 22–24 september i Hangzhou — platsen där tidigare generationer av Qwen tillkännagavs. Inget av detta är bekräftat, och mönstret från den senaste förhandsvisningscykeln är att en arkitekturförhandsvisning föregår hela familjen med månader snarare än veckor. En pull request som öppnas tre dagar före konferensen är bara en antydan och inget mer.

Den ärliga sammanfattningen av var detta lämnar en läsare: Qwen 4 existerar inte, Qwen3.8-Flash-Next gör det, och den andra berättar vad den första kommer att kosta dig att köra. Om tabellen på 47,7 GiB fortsätter att krympa i effektivt fotavtryck – och tre veckors pull requests säger att det arbetas hårt med det – då är tröskeln för att driftsätta Qwen 4-familjen lägre än vad förhandsversionens lanseringsvecka antydde.

Vad du faktiskt kan göra med det här idag

Ingenting i den här pull requesten finns på main, och modellen som den riktar sig mot är inte något man kan anropa via ett API. Checkpointen med öppna vikter Qwen3.8-Flash-Next är en historia om egen hosting: du hämtar vikterna, du servar dem själv, och den filbaserade PLE-vägen är det du läser om. Den routas inte här. Det som är routat är produktionsvarianten — Qwen3.8-Flash, nåbar som qwen/qwen3.8-flash till $0.15 per miljon indatatokens och $0.47 per miljon utdatatokens, med en kontext på 1M tokens och text-, bild- och videoindata — och den större Qwen3.8-Max till $2.00 och $6.00.

Den distinktionen är den användbara för en läsare som ska avgöra vad som ska göras den här veckan. Förhandsversionen är forskning du kör själv; den serverade varianten är samma arkitekturs produktionsväg, och den ligger bara en endpoint bort. OrcaRouter för vidare leverantörens listpris till 0 % påslag, så en prisändring från en leverantör på den endpointen syns samma dag i stället för vid nästa faktureringscykel, och varje modell på nyckeln nås via en enda OpenAI-kompatibel bas-URL i stället för ett separat avtal, SDK och en separat autentiseringsuppgift per leverantör. För en arkitektur så ung – där motorarbetet fortfarande landar varje vecka och färdplanen ännu inte har publicerats – är automatisk redundansväxling mellan leverantörer det praktiska sättet att vara beroende av den serverade varianten utan att satsa en produktionsväg på en enda leverantörs drifttid. Allt detta handlar om de modeller du kan anropa i dag. Det säger ingenting om Qwen 4, som inte är en av dem.

Det vi fortfarande inte vet

Om Qwen 4 kommer att leverera samma tabell i samma storlek. Om pull-förfrågan ens mergas – den har tre misslyckade CI-körningar och inga granskningar ännu. Om straffet på 0,5 till 1 millisekund per steg håller utanför författarens konfigurationer med låg samtidighet. Och om Alibaba säger något på Apsara den 22 september. Med nuvarande underlag är den säkraste slutsatsen om Qwen 4 inte vad den får för poäng, utan hur mycket maskineri branschen bygger bara för att få den att passa – vilket i sig är en användbar sak att veta innan modellen har ett namn i någon katalog.