Campionamento con sharding dei batch di Qwen4Exp: all'interno della PR vLLM #61018, e cosa dice su Qwen 4

Il numero più informativo nella pull request #61018 di vLLM è una perdita: 1,5%. È il limite superiore che l'autore attribuisce alla propria modifica — all'incirca da 0,6 a 0,8 millisecondi risparmiati su un passo medio di 42 millisecondi, misurati su una macchina che non possiede, in una patch che non può eseguire affatto. La pull request, intitolata "[Model] Qwen4Exp: support batch-sharded sampling (compute_logits_local)" e aperta il 10 ottobre 2026 dal contributor kimseunghyun-kr, aggiunge tre righe di codice del modello a due file affinché l'architettura Qwen4Exp possa imboccare un percorso di campionamento che vLLM ha rilasciato ad agosto. È una bozza. Sono 14 righe di codice del modello più 57 righe di test. E vale comunque la pena leggerla con attenzione, per ciò su cui quelle tre righe stanno mettendo una pezza: Qwen4Exp è l'architettura dentro Qwen3.8-Flash-Next, il modello open-weight da 125 miliardi di parametri che il vendor ha pubblicato il 24 agosto 2026 come "un'anteprima sperimentale dell'architettura che costituirà la base di Qwen4" — e un bug a due percorsi nella metà solo testuale di quell'architettura è esattamente il tipo di dettaglio che si scopre solo osservando il livello di serving anziché il post di lancio.

Per non lasciare ambiguità sull'inquadramento, perché qui conta: Qwen 4 stesso non è ancora stato rilasciato. Il fornitore ha indicato quattro livelli di Qwen 4 — Qwen 4 Max, Flash, Plus e 27B — alla sua conferenza Apsara il 2026-09-22, e non ha pubblicato pesi, identificatore, prezzo, lunghezza del contesto né benchmark per nessuno di essi. Nulla di ciò che segue è un rilascio. Questo è un resoconto di quanto sappiamo finora su una singola pull request in bozza, e tutto ciò che in esso riporta un numero è o un timestamp che puoi verificare, o una cifra che il contributore ha inserito nel corpo della propria PR, o un valore letto da un file di configurazione pubblico di un modello.

Che cos'è il campionamento con sharding a batch, in un paragrafo

Il parallelismo tensoriale suddivide i pesi di un modello tra le GPU; la proiezione del vocabolario è il singolo tensore più ampio nello stack, quindi ogni rank calcola normalmente solo la propria fetta del vocabolario — e poi ogni rank esegue un all-gather, cosicché ognuno finisce per contenere i logits completi per ogni richiesta nel batch. Il campionamento sharded inverte questo scambio. Invece di replicare il vocabolario tra i rank, suddivide in shard il batch: ogni rank campiona una fetta delle richieste, e i rank si scambiano fette di vocabolario tra loro tramite un all-to-all. La documentazione CLI di vLLM descrive il flag in modo semplice — «Ogni rank campiona una fetta del batch invece che ogni rank campionarlo tutto» — e indica i vincoli: --enable-batch-sharded-sampling è impostato su False per impostazione predefinita, richiede tensor_parallel_size maggiore di 1, almeno tensor_parallel_size sequenze massime e un valore non negativo per max_logprobs. L'ultima riga di quella documentazione è l'aggancio su cui si basa questa pull request: «I modelli aderiscono implementando compute_logits_local».

La funzionalità in sé non è nuova. vLLM l'ha integrata come PR #50465 — «[Model Runner V2] batch-sharded sample», di Giancarlo Delfin — il 2026-08-24, lo stesso giorno in cui sono stati pubblicati i pesi di Qwen3.8-Flash-Next. La motivazione in quel caso era memoria e latenza: materializzare i logit target completi costa nell'ordine di dimensione del batch × (token speculativi + 1) × dimensione del vocabolario, e lo sharding riduce quell'allocazione di un fattore pari al grado di tensor parallel, consentendo al contempo che il lavoro di top-k e top-p del sampler venga eseguito in parallelo. È il passo abilitante, non la destinazione: il testo stesso della PR segnala i draft-logits shardizzati come lavoro futuro.

Perché tre righe erano tutto il lavoro

Ecco il difetto reale, ed è un buon difetto perché è invisibile dall'esterno del codice. L'implementazione Qwen4Exp di vLLM viene distribuita come due classi. Qwen4ExpForConditionalGeneration è il wrapper visione-linguaggio — una torre di visione Qwen3-VL avvitata al modello linguistico — e Qwen4ExpForCausalLM è il percorso solo testo. Il wrapper eredita compute_logits_local da Qwen3_5ForConditionalGeneration, che inoltra la chiamata a language_model.compute_logits_local. Ma la classe del modello linguistico verso cui il wrapper puntava non ha mai definito quel metodo.

Quindi i due percorsi si trovavano in stati diversi. Un deployment vision-language di Qwen3.8-Flash-Next poteva seguire il percorso sharded; uno solo testo no, perché il metodo a cui il wrapper delegava non esisteva. La correzione consiste in un unico metodo, identico nelle copie NVIDIA e AMD del file del modello:

• Il metodo restituisce self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — lo shard di vocabolario proprio del rank, senza gather e senza materializzazione dell'intero vocabolario su alcun rank.

• Segue quello che la PR definisce "lo stesso schema di 3 righe di Qwen3.5 e MiniMax M3", un punto su cui vale la pena soffermarsi: altre due famiglie di modelli nello stesso repository avevano già aderito. Qwen4Exp era semplicemente quella che non l'aveva fatto.

Il file di test è il punto in cui l'onestà della patch è più facile da verificare e in cui i suoi limiti sono più facili da vedere. Ha 57 righe, è parametrizzato sia sui moduli NVIDIA sia su quelli AMD e non scarica un modello. L'helper costruisce la classe con object.__new__, sostituisce nn.Identity per la testa del modello linguistico e installa un finto processore di logits che restituisce il proprio input più uno registrando al contempo come è stato chiamato. Il primo test verifica che un 4.0 in ingresso diventi 5.0 e che la chiamata registrata avesse skip_gather=True. Il secondo avvolge il modello linguistico nella classe di generazione condizionale e verifica che la delega arrivi a destinazione. Questo è un vero test del cablaggio e un test di nient'altro — nessun kernel viene esercitato, nessun confine di rango viene attraversato e il numero di GPU coinvolte è zero.

Entrambi questi fatti sono dichiarati nella PR anziché sepolti. Il docstring stesso del file di test definisce Qwen4Exp "un minuscolo test double solo CPU". La sezione di validazione dell'autore osserva che non riusciva affatto a importare il modello sulla sua configurazione macOS, perché la build di transformers che aveva non includeva una Qwen4ExpConfig. L'esecuzione CUDA era ancora in sospeso. Il benchmark end-to-end — dataset agentico MLPerf, 20 sessioni concorrenti, tre bracci da 60 minuti — era ancora in sospeso. Il percorso dei logits del drafter MTP stesso è segnalato come non verificato. LoRA è già rifiutato dal flag a monte, quindi è fuori ambito anziché una regressione. C'è anche una riga che rivela che la bozza è stata scritta con l'assistenza dell'IA, e il trailer del commit nomina Claude Opus 5.5 come coautore, il che è il tipo di divulgazione che dovrebbe essere normale in uno stack di queste dimensioni e per lo più non lo è.

La stima dell'1,5%, e le misurazioni a cui si affianca

La stima del contributore è una traccia nsys con 16 sessioni concorrenti su Qwen3.8-Flash-Next-FP8 con tensor parallelism 8 e expert parallelism su otto schede A100-SXM4-40GB: circa 1,6 millisecondi di un passo da 42 millisecondi, ridotti a circa un terzo di quello, per un guadagno end-to-end da 1,5 a 2%. Il suo punto principale è l'aritmetica — 0,6-0,8 ms su 42 ms. Nota cosa è collegato a questo: 42 ms è un valore di latenza inter-token, quindi una riduzione dell'1,7% è una riduzione dell'1,7% sul tempo di generazione dei token, non una dichiarazione di throughput in astratto.

Il confronto onesto è con i numeri mergiati della funzionalità padre stessa, perché quelli sono stati misurati end-to-end da qualcuno con l'hardware. Nelle esecuzioni Speed-Bench 2K/2K pubblicate nella PR #50465, il campionamento batch-sharded ha portato DeepSeek V4 con DSpark a 7 token speculativi e concorrenza 64 da 2,62 a 2,66 richieste al secondo — un guadagno di throughput dell'1,53% — con la latenza mediana inter-token in calo del 3,09% e il tempo al primo token in aumento dell'1,45%. Su MiniMax M3 con DSpark a 8 token speculativi, il throughput delle richieste è aumentato del 5,38% e il TPOT mediano è sceso dell'8,33% da 15,61 a 14,31 millisecondi. E lo stesso piano documenta dove non aiuta: con concorrenza da 4 a 16 le esecuzioni sono risultate piatte o leggermente negative, con il ramo a concorrenza 16 in calo dello 0,54% sul throughput e dell'1,89% sulla lunghezza di accettazione.

Quel pattern è l'elemento da portare via. Il campionamento shardizzato conviene quando il campionamento è pesante e il batch è ampio — elevata concorrenza, molti token speculativi, top-k e top-p che fanno un lavoro reale — e costa un po' quando il batch è abbastanza piccolo che l'all-to-all è puro overhead. Una stima dell'1,5% per un solo modello che aderisce è coerente con questo, non in tensione con esso: le cifre del 5,38% e dell'8,33% appartengono a modelli diversi con budget speculativi diversi, e il modello in questa PR ha la propria configurazione, il proprio vocabolario di 248.320 token e il proprio percorso di decodifica speculativa.

Niente di tutto ciò è sottoposto ad audit. I numeri della PR padre sono i run appaiati di un unico collaboratore su un solo nodo; i numeri dello smoke test qui sono una traccia su hardware che l'autore non possiede, da una revisione della patch che, a suo dire, è stata misurata solo con 16 sessioni. Una misurazione di un singolo collaboratore e di una singola configurazione è un segnale utile sulla direzione e una scarsa base per un piano di capacità. Il motivo per cui vale la pena scrivere dell'argomento è la direzione, non il decimale.

Cosa dice il cluster di patch circostante su Qwen4Exp

Una bozza di PR non sarebbe una storia. La storia è che Qwen4Exp è diventato un target di serving sostenuto nella settimana in cui questo è atterrato, e la patch più piccola in quel cluster è quella che rende leggibile il pattern. Nei sette giorni fino al 2026-10-10, vLLM ha portato, dallo stesso contributore e altri: un percorso di cache KV principale FP8 per l'attenzione sparsa su Ampere, con capacità KV aumentata di 1,83× su otto A100 e 1,87× su quattro RTX 3090 e circa 2,7× le richieste a concorrenza 16, al costo di circa il 6% in più di TPOT di decodifica a singolo stream; una correzione per il padding W4A4 MoE a tensor-parallel 1 e expert parallelism; un percorso AMD che fa fallback da operazioni AITER FP8 MoE non supportate e serve in fp16; una correzione che porta lo stato di short-convolution PLE attraverso la modalità align; e un kernel di decodifica che spacchetta i byte e4m3 quattro alla volta per registro su sm_80. Uno di essi, un ritocco del piano H200 M=4 merged QSA LL-GEMM, è stato unito a main il 2026-10-09.

Leggi quell'elenco nel suo insieme e dice qualcosa di concreto. L'architettura Qwen4Exp — quella che il fornitore non ha rilasciato — viene messa a punto contemporaneamente per Ampere, Hopper, ROCm e il fallback fp16, in un progetto che offre supporto dal giorno zero per modelli che le persone possono effettivamente scaricare. Il motivo non è misterioso: Qwen3.8-Flash-Next è un modello reale, scaricabile e molto usato, ed è costruito sull'architettura che Qwen 4 utilizzerà. Se i pesi di Qwen 4 arriveranno mai con questo aspetto è ignoto e il fornitore non ha detto nulla, ma l'inviluppo di serving viene ampliato pubblicamente, e questa è un'informazione verificabile in un modo in cui una presunta finestra da ottobre a novembre non lo è.

Anche parte della forma architetturale è pubblica, per chiunque legga la configurazione anziché l'annuncio. La configurazione di Qwen3.8-Flash-Next elenca un vocabolario di 248.320 token su 48 layer, 512 esperti con 10 routed più uno condiviso attivi per token a una larghezza intermedia degli esperti di 640, una dimensione nascosta di 2.560 e un contesto nativo di 262.144 token descritto come estensibile a un milione. È un ibrido: la lista dei tipi di layer alterna tre blocchi di attenzione lineare con un blocco di attenzione completa, e i blocchi di attenzione completa usano il percorso di attenzione sparsa con un indexer a una testa che comprime le chiavi di un fattore quattro e mantiene un budget di 2.048 posizioni. C'è una tabella di embedding per layer al layer 2, un embedding n-gram con un vocabolario di 20 milioni di voci — quella è la tabella da 47,7 GiB che le altre patch di questo cluster stanno occupando a fare host-staging — e una testa MTP a un layer per il decoding speculativo. Il riassunto della model card stessa è "125B con 6B attivati, più 51B di embedding n-gram e 4B di MTP". Un vocabolario di 248.320 voci è il motivo per cui vale la pena shardare la proiezione dei logits fin dall'inizio.

Ciò che questo non cambia per te

Vale la pena essere precisi, perché un insieme di patch così denso può sembrare un lancio. Niente di quanto sopra è stato integrato, e un suo elemento — il lavoro sulla cache KV FP8 di Ampere — è esplicitamente non convalidato in CI perché la CI di vLLM non dispone di una A100. Non esiste una versione rilasciata di vLLM che si possa installare oggi e che includa l'opt-in per il campionamento shardizzato di Qwen4Exp. Non esiste alcun benchmark indipendente del comportamento di serving di Qwen3.8-Flash-Next con una qualunque di queste modifiche; ogni numero citato sopra proviene dai corpi delle PR, il che li rende segnalati dai contributori e non verificati nel senso specifico che nessuna terza parte ha riprodotto l'esecuzione. E il numero di punta nella PR che ha dato origine a questo pezzo è 1,5%, che è un guadagno reale in uno stack di serving e non un motivo per cambiare la scelta di un modello.

Ciò che cambierebbe una decisione è un'esecuzione di serving completa e sottoposta ad audit, e questa non esiste ancora. Le misurazioni di pacing che esistono per Qwen3.8-Flash-Next sono del tutto estranee a queste patch: il modello registra un Intelligence Index di 40 su Artificial Analysis, ben al di sopra della mediana di 18 per modelli open-weight di dimensioni simili, e tale cifra è indipendente da tutto ciò che è discusso qui.

Cosa puoi chiamare oggi, e l'angolo di routing

È qui che il quadro diventa pratico per chiunque abbia letto fin qui e voglia usare un modello ospitato anziché strumentarne uno. Qwen3.8-Flash-Next non è nel catalogo di OrcaRouter — non è uno dei 205 modelli che instradiamo, e qui non esiste alcun endpoint ospitato per esso. Ma il fratello di produzione di cui è l'anteprima sì: qwen/qwen3.8-flash, la release ufficiale di Qwen3.8-Flash che la model card dello stesso fornitore descrive come dotata di più funzionalità rispetto all'anteprima, tra cui un contesto di un milione di token per impostazione predefinita e strumenti integrati, è disponibile a $0,15 per milione di token in input e $0,47 per milione di token in output, passati al prezzo di listino del provider senza alcun ricarico aggiunto. Per dare un termine di paragone all'interno della stessa famiglia, qwen/qwen3.8-27b costa $0,33 e $2,40, e qwen/qwen3.8-max $2,00 e $6,00 — tutti raggiungibili con una sola chiave.

Ci sono due motivi che contano più del solito per un articolo su un'architettura non ancora rilasciata. Il primo è il costo di commutazione. Se vuoi calibrare come si comporta un modello ad attenzione sparsa sul tuo traffico prima che Qwen 4 esista, il confronto che vuoi eseguire è con qwen/qwen3.8-flash a prezzo di listino — e farlo attraverso un router significa che il modello che stai misurando e il modello su cui potresti fare fallback sono dietro lo stesso endpoint, lo stesso SDK e la stessa chiave, senza un secondo contratto da firmare. Il secondo è che ogni modifica al serving in questo cluster di patch riguarda vLLM self-hosted. Se non stai eseguendo otto A100, la capacità KV di 1,83× e il guadagno di campionamento dell'1,5% sono cose di cui leggi, non cose che ottieni. Un endpoint instradato è la versione di questo che arriva senza un passaggio di build: failover automatico se un provider si degrada, e un DSL di routing che ti permette di collocare una chiamata hosted accanto a una chiamata self-hosted in un singolo endpoint quando disponi effettivamente di hardware tuo da misurare.

L'unica cosa da non fare è leggere questo articolo come una ragione per aspettare Qwen 4. Non c'è una data. Non c'è un prezzo. Non c'è un conteggio dei pesi per la versione reale — i numeri sopra descrivono la build di anteprima, non il prodotto. Quello che esiste è uno stack di serving che viene preparato pubblicamente per un'architettura che, per ora, è scaricabile solo in forma di anteprima.

La versione breve

Tre righe che colmano un divario tra i percorsi solo-testo e vision-language di un singolo file di modello non sono, di per sé, una notizia. È il tipo di patch che verrebbe sepolta in un merge commit se qualcuno avesse il tempo di revisionarla, e potrebbe benissimo essere inglobata in una modifica più ampia o chiusa del tutto — le linee guida stesse dell'agente del bot vLLM, citate sulla PR, istruiscono i contributori assistiti dall'AI a chiudere il proprio lavoro se manca di un beneficio significativo, e 1,5% è un numero che invita a porsi quella domanda. Ciò che la rende degna della tua attenzione è la cosa che documenta: una tabella n-gram da 20 milioni di voci, un MoE da 512 esperti con dieci esperti attivi per token, un ibrido di attenzione lineare e attenzione sparsa compressa, una testa speculativa — il tutto viene messo a punto su NVIDIA e AMD, da Ampere a Hopper, prima che il prodotto che lo porta esista. Se ti interessa l'envelope di serving di Qwen4, i corpi delle PR sono dove risiedono attualmente le sue specifiche reali. Se vuoi chiamare un modello oggi, Qwen3.8-Flash è quello che c'è davvero.

Un'unica API per oltre 200 modelli, failover automatico, DSL di routing. Esplora il catalogo dei modelli OrcaRouter