Qwen 4 QSA ottiene il parallelismo del contesto di decodifica: dentro la PR in bozza di vLLM per Qwen3.8-Flash-Next

Il 29 settembre 2026, è apparsa una pull request in bozza nel repository vLLM intitolata “[Model][DCP] Support Qwen4Exp QSA,” e per il modello che descrive, contiene i numeri di serving più concreti che chiunque abbia pubblicato in tutto il mese: esecuzioni abbinate di Qwen3.8-Flash-Next su quattro GPU che mostrano una capacità di token KV che passa da 9.759.529 a 17.603.636, una concorrenza massima da 37,23× a 67,15×, e un tempo al primo token che scende da 1.869 ms a 767 ms. Qwen3.8-Flash-Next è l'anteprima open-weight, mixture-of-experts da 125 miliardi di parametri, la cui scheda Hugging Face la descrive come “Un'anteprima dell'architettura Qwen4”; la pull request aggiunge il parallelismo di contesto in decodifica al percorso di attenzione sparsa su cui quell'architettura è costruita. Qwen4 stesso — i livelli Qwen4 Max, Flash, Plus e 27B che il fornitore ha annunciato alla sua conferenza Apsara il 22 settembre 2026 — non è ancora rilasciato, senza pesi, senza identificatore, senza prezzo e senza data. Quindi leggilo per quello che è: non un lancio, non un benchmark, ma un artefatto ingegneristico che ti dice come l'envelope di serving di Qwen4 viene ampliato prima che la famiglia esista.

Questo è un articolo su ciò che sappiamo finora, e l'attribuzione delle fonti conta più del solito. La pull request è una bozza, aperta e non ancora mergiata — vllm-project/vllm#59279, aperta il 2026-09-29 da Sungsoo Ha, ingegnere software NVIDIA, e ancora in stato di bozza. Ogni numero riportato di seguito è una misurazione appaiata dell'autore stesso, riportata nel corpo della PR, effettuata su una revisione precedente dello stesso lavoro. Nulla qui è stato verificato in modo indipendente, nulla qui è approdato in una release, e l'avvertenza che l'autore allega è abbastanza rilevante da avere una sezione dedicata qui sotto.

Cosa cambia effettivamente la pull request

Il parallelismo del contesto di decodifica — DCP — è una tecnica di serving, non una modifica del modello. Invece di un unico gruppo di GPU che detiene un'intera KV cache, DCP suddivide quella cache tra i rank, così ogni rank legge solo la sua porzione di contesto mentre i risultati dell'attenzione vengono combinati tra i rank alla fine. Il punto è la capacità: con la cache partizionata, un deployment può gestire molto più traffico concorrente a contesto lungo sullo stesso hardware, che è esattamente il vincolo che si fa sentire quando ogni richiesta trasporta un quarto di milione di token.

La complicazione è che Qwen Sparse Attention — QSA — non è un semplice livello di attenzione. Come specificato nella scheda del modello Qwen3.8-Flash-Next, un indicizzatore leggero comprime le chiavi in micro-blocchi con un rapporto di compressione di 4, assegna loro un punteggio e mantiene i migliori 512 blocchi, all'incirca 2.048 posizioni di token, mentre il softmax finale e l'aggregazione dei value vengono ancora eseguiti sui K e V non compressi. Ciò significa che QSA mantiene più stato di una KV cache: c'è la cache principale, e ci sono le cache del selettore e quelle laterali che l'indicizzatore conserva. L'implementazione DCP generica in vLLM non ne sa nulla.

Ciò che fa #59279, secondo la sua descrizione, è insegnare a DCP le specificità di QSA:

• Ogni rank legge la propria parte della principale cache KV, mentre il selettore di QSA e le cache laterali rimangono replicate tra i rank anziché partizionate.

• I risultati dell'attenzione vengono combinati tra i rank dopo la lettura suddivisa.

• Il selettore e la cache KV principale sono mantenuti in un unico gruppo di cache, quindi non possono separarsi.

• Ai batch Synthetic V2 è impedito di scrivere nelle cache laterali QSA.

Quell'ultima coppia di dettagli è la parte interessante se ti interessa la correttezza piuttosto che il throughput. Una cache di attenzione shardata che silenziosamente discorda da un selettore replicato è il tipo di bug che si manifesta come un lento decadimento dell'accuratezza su contesti lunghi anziché come un crash, e la modifica è esplicita nel mantenere i due allineati. L'autore afferma anche che è stato utilizzato l'ausilio dell'AI e Codex è accreditato come coautore — vale la pena dirlo chiaramente, perché in una PR in bozza di questa forma è una domanda legittima chiedersi chi abbia scritto cosa.

I numeri appaiati, e come sono stati ottenuti

Il piano di test è abbastanza specifico da essere verificabile, motivo per cui i risultati meritano di essere citati. Entrambi i rami servono Qwen/Qwen3.8-Flash-Next-FP8 su quattro GPU con parallelismo tensoriale 4 e parallelismo degli esperti abilitato, a --gpu-memory-utilization 0.90 con il caching dei prefissi attivo. L'unica differenza tra i due rami è --decode-context-parallel-size: omesso per DCP=1, impostato a 2 per DCP=2, con un riavvio tra i rami in modo che il benchmark inizi da una cache fredda. Il carico è una traccia AgentX 256k con 128 utenti per 900 secondi; l'accuratezza è EvalScope per GSM8K più il valutatore MRCR incluso nel repository, eseguito sei volte per ramo con la prima esecuzione dopo il riavvio scartata.

I delta di throughput riportati, DCP=2 rispetto a DCP=1:

• Token KV — 9,759,529 vs 17,603,636, un aumento di 1,80× della capacità di cache.

• Concorrenza massima — 37,23× vs 67,15×, anche 1,80×.

• Richieste al secondo — 1,69 contro 2,30, 1,36×.

• Token di input al secondo — 128.730 vs 179.702, 1,40×.

• Tempo al primo token — 1.869 ms vs 767 ms, 2,44× inferiore.

• Latenza inter-token — 43,48 ms vs 26,27 ms, 1,66× inferiore.

• Tasso di successo della cache dei prefissi a regime — 67,85% vs 88,98%, un guadagno di 21,1 punti percentuali.

L'accuratezza, riportata come media ± deviazione standard campionaria sulle esecuzioni post-warmup, era sostanzialmente piatta: l'aggregato MRCR 0,8630 ± 0,0005 con DCP=1 rispetto a 0,8697 ± 0,0153 con DCP=2, e GSM8K 0,9788 ± 0,0020 rispetto a 0,9790 ± 0,0016. I campioni MRCR a 2 needle e 4 needle erano fissi a 0,9960 e 0,9906 su entrambi i bracci, quindi tutto il movimento da esecuzione a esecuzione proveniva dai campioni a 8 needle — e una delle esecuzioni aggregate con DCP=2 ha ottenuto 0,8970, mentre le altre quattro si sono attestate tra 0,8620 e 0,8632. Questa è una dispersione reale, non rumore che si possa liquidare con un gesto, ed è dichiarata nella PR anziché essere attenuata.

Ciò che questi numeri non stabiliscono

L'avvertenza è nel testo della PR e non è di poco conto. I risultati abbinati di AgentX e accuratezza sono stati misurati su una precedente revisione di QSA DCP, usando una nightly di vLLM basata sul commit 3df4ae153eb. Il commit finale pulito nella pull request include una successiva correzione del kernel di localizzazione QSA e ha superato la validazione mirata su B200 — ma le valutazioni complete di AgentX e accuratezza non sono state ripetute su quella esatta fonte. In altre parole: la storia del throughput e la diff rilasciata non sono lo stesso artefatto, e l'autore lo dice.

Inoltre, vale la solita disciplina, e qui vale in modo severo. Questi sono numeri relativi a una singola configurazione, provenienti da un unico contributore su un'unica configurazione a quattro GPU. Sono affini al fornitore anziché neutri: che un contributore del framework misuri una modifica al framework è una cosa normale e utile, ma non è un audit indipendente, e nessuna terza parte ha riprodotto l'esecuzione. Non esiste alcuna versione rilasciata di vLLM che tu possa installare oggi e che contenga questa modifica, perché la modifica non è stata sottoposta a merge. E DCP=2 è una suddivisione a due vie di una forma specifica — i delta non sono una promessa su ciò che farebbero DCP=4 o DCP=8, e nulla nella PR afferma che lo siano.

Perché una PR di serving su un'architettura non ancora rilasciata merita comunque il tuo tempo

L'obiezione ovvia: il modello nel titolo non esiste, quindi perché preoccuparsene? Perché ciò che viene messo a punto non è Qwen 4. È Qwen3.8-Flash-Next, e quel modello esiste davvero — Alibaba lo ha pubblicato il 24 agosto 2026 come MoE da 125 miliardi di parametri con 6 miliardi attivati, una tabella di embedding n-gram da 51 miliardi di parametri, una testa MTP da 4 miliardi per il decoding speculativo, 48 layer disposti come dodici ripetizioni di tre blocchi Gated DeltaNet seguiti da un blocco QSA, 512 esperti con 10 instradati e 1 condiviso attivo, e un contesto nativo di 262.144 token che la scheda dice essere estendibile a 1.000.000. È l'implementazione di riferimento dell'architettura Qwen4 in pesi aperti, e QSA — l'attenzione sparsa a micro-blocchi che questa pull request sta insegnando a DCP a shardare — è la parte più distintiva in assoluto.

Ciò che i numeri descrivono è ciò che accade quando si smette di trattare quel contesto da 262K come qualcosa che un singolo gruppo di GPU debba tenere per intero. Il salto di 1,80× nella capacità di token KV e nella concorrenza è l'aritmetica del dividere una cache in due, che è il risultato meno sorprendente della lista. Le cifre più interessanti sono quelle sulla latenza: tempo al primo token inferiore di 2,44× e latenza inter-token inferiore di 1,66× a parità di carico offerto, più un miglioramento di 21 punti nel tasso di successo della cache dei prefissi in stato stazionario. Questi dicono che il percorso DCP non si limita a comprare capacità al prezzo della latenza — in questa esecuzione accoppiata ha comprato entrambe. Questa è la forma di cambiamento che conta per chiunque serva traffico di agent con prompt di sistema molto lunghi, perché il comportamento della cache dei prefissi in contesti lunghi è di solito il punto in cui il throughput a contesto lungo muore silenziosamente.

E questo non è un intervento isolato. La stessa settimana ha prodotto un grappolo di lavoro sul motore Qwen4Exp: #59214 aggiunge piani GEMM di decodifica a bassa latenza per SM100 per le shape B200, #59010 aggiunge un kernel di prefill sparso nativo SM90 per il percorso QSA su Hopper, #58977 copre gli embedding BF16 INC PLE, e #58961 — quello che in realtà è stato sottoposto a merge, il 2026-09-28 — ha corretto una KV cache di profiling che le viste delle chiavi QSA mantenevano in vita. Letti insieme, sono l'involucro di serving dell'architettura Qwen4 che viene costruito in pubblico, nei runtime, mesi prima che la famiglia venga distribuita. Se stai pianificando per Qwen 4, il segnale utile non è una data di lancio — non ce n'è una — è ciò che i kernel e i layout della cache già presuppongono su come dovrai servirla.

Cosa puoi chiamare oggi

Se vuoi testare il comportamento su contesti lunghi sull'architettura di cui tratta questa PR, il modello da scegliere è il tier Flash che Alibaba serve effettivamente. Qwen3.8-Flash — il deployment di produzione costruito su Qwen3.8-Flash-Next, con un contesto da 1.000.000 di token e un output massimo di 131.072 token, che accetta in input testo, immagini e video — è live, ed è un unico endpoint per il modello che esegue davvero oggi l'architettura Qwen4Exp, elencato come qwen/qwen3.8-flash a 0,15 $ per milione di token di input e 0,47 $ per milione di token di output, con le letture dalla cache a 0,0184 $. Poiché quelli sono prezzi di listino del provider, passati senza alcun ricarico da parte nostra, una variazione di prezzo o di limite da parte del fornitore ti raggiunge lo stesso giorno in cui viene annunciata.

Due precisazioni oneste. Primo, Qwen3.8-Flash-Next stesso — i pesi FP8 nel piano di test della pull request, quelli che ti servirebbero per riprodurre localmente una qualsiasi di queste misurazioni — non è nel nostro catalogo; il tier Flash servito è la linea di produzione QwenCloud, non il checkpoint di anteprima grezzo. Se vuoi eseguire la configurazione esatta della PR, stai facendo self-hosting su quattro GPU. Secondo, la modifica DCP non è stata unita, quindi nulla che tu possa chiamare oggi, da qualsiasi parte, la sta eseguendo. Quello che il tier servito ti offre è un modo per scoprire se il tuo carico di lavoro è persino plasmato per il problema che DCP risolve: se i tuoi prompt sono lunghi, agentici e ricchi di prefissi, allora la capacità di 1,80× e il delta della cache dei prefissi sono i numeri da tenere d'occhio nelle tue stesse tracce.

E se la parte interessante per te non è un singolo modello ma la questione del passaggio — su quale livello costruire mentre la gamma Qwen 4 è ancora senza nome — quello è un problema di routing più che di serving, e una sola API per oltre 200 modelli è il modo per tenere aperta l'opzione senza un secondo contratto o una modifica al codice quando la famiglia finalmente arriverà.

Domande a cui vale la pena rispondere direttamente

#59279 significa che Qwen 4 è già uscito, o sta per uscire?

No. La pull request riguarda l'architettura Qwen4Exp così come implementata in Qwen3.8-Flash-Next, che Alibaba ha rilasciato il 2026-08-24. La famiglia Qwen 4 — Max, Flash, Plus e 27B — è stata annunciata su un palco ad Apsara il 2026-09-22 e inserita in una roadmap aziendale con una linea successoria prevista da 5 a 10 trilioni di parametri, e ancora non ha model card, né pesi, né identificatore API, né finestra di contesto, né prezzo, né data. Una PR di framework che aggiunge una modalità di parallelismo all'architettura di anteprima è un passo verso il servire bene Qwen 4. Non è un passo verso l'esistenza di Qwen 4.

In che modo il parallelismo del contesto di decodifica è diverso dal parallelismo tensoriale?

Dividono cose diverse e falliscono in modi diversi. Il parallelismo tensoriale partiziona i pesi e il calcolo di ogni layer tra le GPU, quindi ogni rank partecipa a ogni token ma vede l'intera sequenza. Il parallelismo del contesto di decodifica partiziona la cache KV stessa, quindi ogni rank detiene e legge solo una porzione del contesto e i risultati parziali dell'attenzione vengono uniti in seguito. TP serve a far entrare il modello; DCP serve a far entrare il contesto e il traffico concorrente che viaggia su di esso. Questa distinzione è esattamente il motivo per cui questa PR non è banale: il selettore e le cache laterali di QSA non possono semplicemente essere shardati come può esserlo la cache KV principale, quindi la modifica deve shardare uno e replicare gli altri, e poi dimostrare che i due rimangono coerenti.

Se oggi chiamo Qwen3.8-Flash-Next tramite un'API ospitata, ottengo già questi numeri?

No, e il divario ha tre parti. La modifica non è stata integrata, quindi nessuna build rilasciata di vLLM la contiene. Anche una volta integrata, il provider deve adottare quella build e scegliere di eseguire con una dimensione DCP superiore a uno — è una configurazione di serving, non un'impostazione predefinita. E i delta misurati provengono da una revisione precedente della patch anziché dal commit finale, che secondo l'autore ha finora ricevuto solo una validazione mirata su B200. Considera i delta riportati come un limite superiore ben documentato di ciò che l'approccio offre in una configurazione, non come una specifica di qualsiasi endpoint che puoi noleggiare questa settimana.

La questione aperta

La cosa da tenere d'occhio non è se questa specifica bozza verrà unita — probabilmente lo sarà in qualche forma, dato che la gestione della cache specifica per QSA che aggiunge colma una lacuna reale, non una preferenza. La cosa da tenere d'occhio è se la versione finale riceverà la stessa valutazione abbinata che ha ricevuto la revisione intermedia. Una modifica al serving le cui affermazioni sul throughput provengono da una build e le cui affermazioni sulla correttezza provengono da un'altra è, per ora, una proposta ben argomentata più che un risultato misurato, e la dispersione dell'accuratezza nell'MRCR a 8 needle è abbastanza ampia che ripetere l'esecuzione sul sorgente rilasciato sarebbe la singola cosa più utile che chiunque potrebbe pubblicare al riguardo. Fino ad allora: la direzione è leggibile, la questione non è chiusa, e l'unico modello con architettura Qwen4 tra i pesi aperti resta quello di agosto.