Trapelamento di Qwen 4: la PR di host-staging di SGLang mostra come la tabella PLE da 47,7 GiB entri in una singola GPU

Il numero che deciderà se Qwen 4 è un modello che puoi servire da solo non è il suo numero di parametri. È 47,7 GiB — la dimensione della tabella di embedding n-gram che accompagna l'architettura Qwen4, separata dai pesi, e deve risiedere da qualche parte mentre il modello decodifica. Una pull request aperta nel repository SGLang il 18 settembre 2026, intitolata [Qwen4-Exp] Aggiungi staging host per PLE basato su file, è un tentativo di impedire che quella tabella detti quanta RAM serve a una macchina prima che possa essere eseguito affatto. Qwen 4 non è ancora rilasciato: nessuna model card, nessun peso, nessuna voce di catalogo, nessuna data. L'unico modello rilasciato che istanzia questa architettura è Qwen3.8-Flash-Next, l'anteprima open-weight pubblicata il 26 agosto 2026, la cui configurazione dichiara model_type=qwen4_exp — la stessa stringa che dà il nome alla pull request. Il suo gemello di produzione Qwen3.8-Flash è la versione che un chiamante API può effettivamente raggiungere oggi. Tutto in questo pezzo su Qwen 4 è un'inferenza da quell'anteprima e dal codice del motore; la pull request è aperta e non unita, quindi leggi tutto come un segnale, non come una capacità già rilasciata.

Ciò che il segnale è realmente

Pull request sgl-project/sglang#40235 non è un lancio e non è stata unita. È ferma su un commit, aperta dal contributore Dev-Jahn, che unisce un branch chiamato task/ple-host-staged nella mainline di SGLang. Nove code owner sono stati richiesti per la review e tutti risultano in attesa, quindi almeno una review approvativa separa questa PR dalla mainline. Tre job CI — il test PR di base, il test PR aggiuntivo e l'esecuzione AMD ROCm — stanno fallendo sul commit aperto. È la condizione normale di un grande cambiamento del motore in corso, ed è anche il motivo per cui la parte interessante di questa PR non è se verrà unita, ma cosa il suo autore ha dovuto misurare per sostenerla. La descrizione contiene circa 1.400 righe aggiunte, inclusi i test, e una tabella di benchmark che è il dato pubblico più concreto che chiunque abbia pubblicato sull'esecuzione di questa architettura su una singola GPU.

Perché la tabella è tutta la storia

Gli embedding per livello sono la stranezza strutturale di questa generazione. Dove un modello normale colloca un unico embedding di token all'inizio, il design di Qwen4 porta con sé una grande tabella di n-gram — bigrammi e trigrammi, sottoposti a hashing in un vocabolario molto più ampio di quello del tokenizer — e da essa alimenta ricerche di embedding per livello lungo tutto lo stack. Il materiale di anteprima di Alibaba descrive la componente n-gram come decine di miliardi di parametri in aggiunta al corpo MoE da 125 miliardi di parametri; le analisi della community del checkpoint rilasciato collocano il file della tabella a 47,7 GiB. Tali cifre provengono da fonti del fornitore e della community anziché da una riproduzione indipendente, e l'esatta relazione tra la tabella dell'anteprima e qualunque cosa Qwen 4 rilasci è sconosciuta.

Ciò che non è in dubbio è la conseguenza ingegneristica. Una tabella laterale da 47,7 GiB che deve essere consultata a ogni passo di decodifica non è qualcosa che si possa spingere silenziosamente in un angolo della VRAM. Su una scheda da 96 GB compete direttamente con la KV cache; sulle schede più piccole semplicemente non entra. Ecco perché SGLang, che ha introdotto il supporto day-0 per l'anteprima alla fine di agosto, ha trascorso le tre settimane successive producendo una pull request dopo l'altra su questa singola struttura dati anziché sul modello che la circonda.

Cosa era rotto prima di questa PR

SGLang aveva già due modi per mantenere la tabella, ed entrambi avevano un limite rigido.

• Pinnedmantiene l'intera tabella nella RAM dell'host e la legge da lì. Funziona, è veloce e rende assoluto il requisito di memoria dell'host — non ne esiste una versione più piccola.

• Basato su file, aggiunto in precedenza in una pull request separata, mantiene la tabella in un file sparse e consente al kernel di gather di leggere direttamente il mapping, così è la page cache del sistema operativo a decidere quanta parte ne rimanga residente. Il problema è di natura hardware: quel percorso di lettura diretta richiede che la GPU dichiari cudaDevAttrPageableMemoryAccessUsesHostPageTables — la capacità che il testo stesso della PR definisce "la classe GB10". Su una GPU che non la possiede, il backend file viene rifiutato del tutto e pinned è l'unica opzione rimasta.

Il divario che si crea non è teorico. Un rapporto separato aperto sullo stesso percorso di codice documenta un utente su due RTX 3090 la cui quota per rank della tabella ammontava a 23,84 GiB rispetto a 23,56 GiB di memoria utilizzabile — 0,28 GiB in meno, con 188 GiB di RAM host liberi. In quella configurazione il backend file è stato rifiutato dal controllo hardware e il flag di CPU-offload ordinario solleva un errore quando viene combinato con il flag di offload PLE. Trovarsi a corto di trecento megabyte con centottanta gigabyte liberi è esattamente la forma di problema che questa pull request esiste per rimuovere.

Quali modifiche allo staging dell'host

Il meccanismo che la PR aggiunge è uno strato di staging tra il file e il dispositivo. Invece di chiedere alla GPU di dereferenziare le pagine host, un componente lato CPU legge le righe di cui ha bisogno tramite la mappatura esistente del loader e consiglia al kernel di caricare quelle pagine in anticipo; una variabile d'ambiente, SGLANG_QWEN4_PLE_FILE_PREFETCH, disattiva il suggerimento se vuoi misurare senza di esso. Ogni livello PLE riceve quindi due buffer pinned di 8.192 righe — circa 1,25 MiB ciascuno in FP8 — e un worker. Le righe vengono raccolte in un buffer mentre l'altro viene copiato sul dispositivo, così la raccolta e il trasferimento si sovrappongono invece di serializzarsi. Gli identificatori di n-gram vengono sottoposti a hash sull'host anziché sul dispositivo. Il replay del grafo riceve una chiamata di preparazione prima di ogni replay, e il thread di lancio attende il passo precedente.

Quell'ultimo dettaglio è il costo, e la PR lo dichiara chiaramente: circa 0,5 a 1 millisecondo aggiunto per passo di decodifica rispetto al percorso pinned. Tutto il resto è il guadagno. Misurato su una singola RTX PRO 6000 Blackwell con 96 GB, un host AMD EPYC con 377 GiB di RAM, CUDA 13.2, usando i checkpoint pubblici FP8 e NVFP4 di Qwen3.8-Flash-Next:

• Cache della pagina host, FP8 TP4/EP4 — 71 GB bloccati e senza limite, contro 49 GB con un limite di 64 GB, 15 GB con 32 GB e 6 GB con un limite di 24 GB

• Latenza di decodifica, stesse esecuzioni — 8,62 ms per token con concorrenza 1 fissata, contro 9,16 / 9,20 / 9,12 ms nelle tre esecuzioni con file limitato

• Concorrenza 16 — 16,54 ms con pinning rispetto a 17,62 / 17,85 / 17,37 ms con limite, ovvero da 893 token al secondo fino a 827–840

• Throughput di prefill — 620 token al secondo a 8k pinned rispetto a 624 / 630 / 631 capped; a 32k, 1.347 rispetto a 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB pinned rispetto a 24 GB con il backend file con un limite di 32 GB, a 8,87 ms rispetto a 9,18 ms

• NVFP4 su singola GPU — 69 GB pinned contro 51 GB con un tetto di 64 GB, a 6,44 ms contro 6,73 ms

• L'alternativa che batte — leggere lo stesso file tramite la gestione della memoria dell'host su quella GPU ha dato 10,8 ms con concorrenza 1 e 46,5 ms con concorrenza 16, che il PR descrive come 2,8× la latenza pinned a quella concorrenza

L'aspetto dell'accuratezza viene riportato come pulito. L'output greedy deterministico su otto prompt da 256 token è risultato identico a livello di token tra il percorso pinned e il percorso file su FP8 TP4, e GSM8K è risultato al 97,6% con pinned rispetto al 98,0% con file al tetto di 64 GB — un divario di sei domande che l'autore attribuisce alla variazione tra esecuzioni piuttosto che al percorso di offload. Tutti questi numeri sono dell'autore della pull request, misurati una sola volta, su una sola macchina, e nessuno li ha riprodotti.

I costi che il PR ammette

Una lettura equa di questa pull request include ciò che rifiuta di fare. Diverse modalità di esecuzione vengono rifiutate al momento della costruzione anziché essere silenziosamente degradate, e ogni rifiuto indica il backend pinned come fallback: prefill CUDA graphs, data-parallel attention, il percorso di multiplexing prefill-decode, la sovrapposizione a due batch, i grafi di decode DLLM e i grafi compatti di verify ragged sono tutti esclusi. Altrettanto importante, non aggiunge alcun nuovo flag né alcun nuovo switch user-facing — il percorso di staging è ciò che il backend file fa su hardware che in precedenza non poteva affatto utilizzarlo. E l'esecuzione di accuratezza porta con sé un'avvertenza che l'autore fornisce spontaneamente: le esecuzioni limitate non hanno mai contenuto l'intera tabella, perché la tabella è di 47,7 GiB e i limiti scendono fino a 24 GB, quindi un carico di lavoro con un pattern di accesso genuinamente piatto e imprevedibile sull'intera tabella non è ciò che è stato misurato.

Perché questo è importante specificamente per Qwen 4

Togli i dettagli del motore e il pattern è leggibile. Alibaba ha rilasciato un'anteprima dell'architettura il 26 agosto con istruzioni per la comunità open-source per preparare runtime, quantizzazione e motori di inferenza prima della famiglia completa. SGLang lo ha fatto, e poi ha passato tre settimane a presentare pull request sull'unico componente che rende l'architettura difficile da distribuire. Letto come una previsione, è un'affermazione su ciò di cui Qwen 4 avrà bisogno dal tuo hardware, non su ciò che può fare su un benchmark.

Inoltre, acuisce la questione della tempistica. Qwen 4 non è stato rilasciato, e le speculazioni di settembre al riguardo puntano all'Apsara Conference di Alibaba, dal 22 al 24 settembre a Hangzhou — la sede in cui sono state annunciate le precedenti generazioni di Qwen. Nulla di ciò è confermato, e il pattern dell'ultimo ciclo di anteprime è che un'anteprima dell'architettura precede la famiglia completa di mesi, anziché di settimane. L'apertura di una pull request tre giorni prima di quella conferenza è indicativa e nulla più.

Il riassunto onesto di dove questo lascia il lettore: Qwen 4 non esiste, Qwen3.8-Flash-Next sì, e il secondo ti dice quanto ti costerà eseguire il primo. Se la tabella da 47,7 GiB continua a ridursi in termini di footprint effettivo — e tre settimane di pull request dicono che ci si sta lavorando sodo — allora l'asticella del deployment per la famiglia Qwen 4 è più bassa di quanto lasciasse intendere la settimana di lancio dell'anteprima.

Cosa puoi davvero fare con questo oggi

Nulla in questa pull request è disponibile su main, e il modello a cui si riferisce non è qualcosa che si possa chiamare tramite un'API. Il checkpoint open-weight Qwen3.8-Flash-Next è una storia di self-hosting: scarichi i pesi, li servi da solo, e il percorso PLE basato su file è quello di cui stai leggendo. Qui non è instradato. Ciò che è instradato è la variante di produzione — Qwen3.8-Flash, raggiungibile come qwen/qwen3.8-flash a $0,15 per milione di token in input e $0,47 per milione in output, con una finestra di contesto di 1M di token e input di testo, immagini e video — e il più grande Qwen3.8-Max a $2,00 e $6,00.

Quella distinzione è quella utile per un lettore che deve decidere cosa fare questa settimana. L'anteprima è ricerca che conduci tu stesso; la variante servita è il percorso di produzione della stessa architettura, e dista un solo endpoint. OrcaRouter trasferisce il prezzo di listino del fornitore con 0% di ricarico, così una variazione di prezzo di un fornitore su quell'endpoint si vede lo stesso giorno invece che al ciclo di fatturazione successivo, e ogni modello sulla chiave è raggiungibile tramite un unico base URL compatibile con OpenAI, invece che con un contratto, un SDK e una credenziale separati per fornitore. Per un'architettura così giovane — in cui il lavoro sul motore arriva ancora con cadenza settimanale e la roadmap non è stata pubblicata — il failover automatico tra fornitori è il modo pratico di dipendere dalla variante servita senza scommettere un percorso di produzione sull'uptime di un singolo fornitore. Tutto questo riguarda i modelli che puoi chiamare oggi. Non dice nulla su Qwen 4, che non è uno di essi.

Quello che ancora non sappiamo

Se Qwen 4 rilascerà la stessa tabella della stessa dimensione. Se la pull request verrà unita del tutto — ha tre esecuzioni CI fallite e ancora nessuna revisione. Se la penalità da 0,5 a 1 millisecondo per passo regge al di fuori delle configurazioni a bassa concorrenza dell'autore. E se Alibaba dirà qualcosa ad Apsara il 22 settembre. Alla luce delle prove attuali, la cosa più sicura da concludere su Qwen 4 non è quali punteggi ottenga, ma quanta infrastruttura l'industria stia costruendo solo per farlo entrare — il che è di per sé una cosa utile da sapere prima che il modello abbia un nome in qualsiasi catalogo.