Trapelamento di Qwen 4: SGLang suddivide in shard il prefill di Qwen4Exp per un TTFT più rapido del 18% e un GiB recuperato per GPU

Una pull request aperta nel repository SGLang alle 03:47 UTC di questa mattina, 2026-10-08, promette qualcosa che nessun annuncio di Qwen 4 ha ancora prodotto: un numero. È intitolata feat(qwen4-exp): abilita il parallelismo di sequenza LayerNorm per GR e PLE, e su quattro GPU H20 che eseguono il checkpoint open-weight Qwen3.8-Flash-Next in FP8, il suo autore riporta miglioramenti del tempo al primo token del 17,7–18,4% con input a 32K e del 14,6–14,7% con input a 235K, circa un gigabyte di memoria di picco restituita per GPU, e fino al 22% in più di throughput in input. Qwen 4 stesso — la famiglia che il fornitore ha nominato ma non ha rilasciato alla conferenza Apsara di Hangzhou il 2026-09-22 — è ancora inedito, senza pesi, senza identificatore e senza prezzo. L'unico modello che oggi incarni l'architettura Qwen4Exp è Qwen3.8-Flash-Next, pubblicato il 2026-08-26, e la sua controparte gestita Qwen3.8-Flash è la versione che un chiamante API può effettivamente raggiungere. Quindi leggete quanto segue per quello che è esattamente: le misurazioni appaiate di un ingegnere, allegate a una pull request aperta, in bozza e non ancora unita, sull'inviluppo di servizio di una famiglia di modelli che non esiste ancora.

Prima le fonti, perché questo è un pezzo su una fuga di notizie e la distinzione fa davvero la differenza. Il segnale è sgl-project/sglang#43048, aperto il 2026-10-08 alle 03:47 UTC dall'account GitHub shiyang814-cpu, toccato per l'ultima volta alle 03:55 UTC e ancora contrassegnato come bozza, senza alcuna revisione di approvazione registrata e senza merge. Modifica sei file — due file di test, il file del modello Qwen4Exp, il modulo LayerNorm-SP, una factory di confine tra layer e un hook di gruppo di argomenti — per +345 e −50 righe. Ogni cifra sulle prestazioni riportata di seguito proviene dalla descrizione della PR, è la misurazione OFF/ON appaiata dell'autore stesso e non è stata riprodotta da nessuno. Tre esecuzioni CI sulla revisione alla punta del branch sono contrassegnate come fallite. Nulla di ciò che è qui è una funzionalità rilasciata.

Cosa cambia effettivamente la pull request

Il parallelismo di sequenza non è un cambiamento del modello e non è una nuova funzionalità. È un ricablaggio di dove alcuni layer eseguono i loro calcoli. La sua discendenza risale al parallelismo di sequenza in stile Megatron — il trucco da arXiv:2205.05198 — e SGLang lo implementa già: la docstring del modulo spiega il meccanismo che riutilizza, ovvero che sotto puro parallelismo tensoriale un row-parallel all_reduce è algebricamente un reduce_scatter seguito da un all_gather. Poiché quelle due collettive spostano esattamente gli stessi byte del singolo all_reduce che sostituiscono, dividere l'operazione in quel modo non costa alcun volume di comunicazione extra. Ciò che si guadagna è la libertà di far funzionare le regioni di normalizzazione e residuali su sequence-sharded attivazioni — con ogni rank del parallelismo tensoriale che detiene un 1/tp-esimo delle righe di token — il che riduce la memoria di attivazione transitoria che il prefill a contesto lungo deve mantenere viva.

Ciò che questa particolare pull request fa è estendere quel percorso esistente dall'architettura su cui era stato validato all'architettura Qwen4Exp. Durante il prefill, le attivazioni Gated Residual e Per-Layer Embedding restano shardate lungo la dimensione dei token attraverso il gruppo TP. Prima dell'attenzione, prima di GDN, prima di QSA e prima che venga eseguito il blocco Mixture-of-Experts, le righe complete dei token vengono raccolte di nuovo con un all-gather, il calcolo tensor-parallel esistente a righe complete viene eseguito invariato dietro un fallback condiviso, e un reduce-scatter somma poi i contributi parziali e ripristina lo shard di ciascun rank. Il decode non tocca mai il nuovo percorso. La funzionalità è raggiungibile tramite l'opzione che già esiste — --enable-layernorm-sp — senza alcun flag specifico per Qwen4Exp, e in assenza del flag il codice si comporta esattamente come faceva prima.

Perché Qwen4Exp è l'architettura che ha bisogno di questo

Il motivo per cui questo è importante specificamente per Qwen4Exp, e non allo stesso modo per ogni modello, risiede nel design stesso dell'architettura. Qwen3.8-Flash-Next applica proiezioni Gated Residual a tutte le righe di token in ogni strato decoder — la configurazione dichiara quattro flussi residui e un rango di bottleneck di 320 su 48 strati — e Per-Layer Embedding aggiunge una seconda proiezione replicata, riga di token per riga di token, sopra a ciò. Sotto tensor parallelism, entrambe queste operazioni sono duplicate in modo identico su ogni rank, perché non portano con sé una propria matrice di pesi shardata per TP che ne forzi una suddivisione. Lo sharding della loro dimensione token rimuove direttamente il lavoro replicato, e come dice la sezione motivazionale della PR, ciò avviene preservando il layout tensor-parallel esistente e la semantica di riduzione di attention, GDN/QSA e MoE — che è la parte che rende la modifica sicura anziché ingegnosa.

Vale la pena dire chiaramente cosa significa per il lettore. La cosa interessante di questa PR non è che SGLang stia diventando più veloce. È che l'architettura Qwen4 comporta costi per livello che scalano con il numero di token anziché con il numero di parametri, e sono quei costi a farsi sentire sui prefill lunghi. Questa è un'impronta progettuale, ed è il tipo di cosa che una scheda tecnica non menziona mai.

I delta misurati

Il benchmark dell'autore fissa una configurazione e attiva/disattiva il flag: quattro GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, tensor parallel 4 ed expert parallel 4, dimensione del prefill a blocchi 8192, backend di prefill e decode con attenzione lineare FlashInfer, la stessa configurazione del server per OFF e ON, riavvii del servizio alternati OFF → ON → OFF → ON, e input di token fissi con richieste di warmup. Ogni cifra riportata di seguito proviene da quella configurazione e non è verificata:

• Input 32K, dimensione batch 1 — TTFT migliorato del 17,72–18,36%, latenza end-to-end circa 16%, throughput in input circa 20%

• Input da 235K, batch size 1 — TTFT migliorato del 14,63–14,71%, latenza end-to-end circa il 14%, throughput di input circa il 17%

• Input 32K, dimensione batch 4 — TTFT migliorato del 18,74%, latenza end-to-end 18,14%, throughput in input 22,14%

• Memoria di picco — ridotta di circa 1,0 GiB per GPU

• Decodifica, batch size 1 — tempo per token di output sostanzialmente invariato

L'ultima riga è quella da leggere due volte, e l'autore è franco sul perché: questa ottimizzazione è abilitata solo per il prefill, quindi il decode a singolo stream non ne trae nulla. Il miglioramento del tempo per token con batch-4, dove compare, riflette minori ritardi di scheduling dovuti a prefill lunghi concorrenti, non un kernel di decode più veloce. Se speravi che questa fosse una storia di throughput, non lo è — è una storia di latenza al primo token e di memoria, e questi sono i due vincoli che decidono se una richiesta da 235K token sia servibile o meno.

Il bug di layout che hanno dovuto correggere per primo

La parte più informativa della pull request non è la tabella degli speedup. È la sezione sul layout fisico delle righe PLE, perché mostra ciò che lo stack di serving di Qwen4Exp continua a sbagliare.

Per-Layer Embedding opera su un bucket fisico fisso del grafo CUDA, mentre solo un prefisso delle righe in quel bucket può contenere token reali. Il padding deve quindi essere applicato prima che la sequenza venga suddivisa in shard, non dopo. Nell'ultimo chunk di una richiesta da 235K token, i numeri dell'autore sono 5.624 token elaborati all'interno di un bucket fisico da 8.192 righe con TP 4, e l'unico layout corretto è il rank 0 che contiene 2.048 righe valide, il rank 1 che contiene 2.048 righe valide, il rank 2 che contiene 1.528 righe valide più 520 righe di padding, e il rank 3 che contiene 2.048 righe di padding. Suddividere prima in shard le 5.624 righe elaborate — l'implementazione ovvia — inserisce padding tra intervalli validi globalmente contigui e corrompe il risultato. L'autore registra che un vero test OFF/ON da 235K ha prodotto un output greedy identico da 16 token solo dopo che questo layout è stato corretto.

Questo è un piccolo dettaglio con una grande implicazione. Il percorso PLE in SGLang è stato aggiunto così di recente che un bug nell'ordinamento dei token di questo tipo era ancora raggiungibile, e la persona che l'ha trovato stava scrivendo l'estensione sequence-parallel. Il supporto di serving day-zero per questa architettura non è finito; viene attivamente costruito, in pubblico, dai contributori, un layout alla volta.

Quanto ti costa: i vincoli

Un flag che aiuta solo alcuni deployment è utile solo se sai quali. La PR dichiara esplicitamente i suoi requisiti, e le configurazioni al di fuori di essi falliscono durante la validazione degli argomenti invece di degradarsi silenziosamente:

• La dimensione del parallelismo tensoriale deve essere maggiore di 1 — un deployment su GPU singola non ottiene alcun vantaggio, perché non c'è alcun rank da shardare

• La dimensione del parallelismo degli esperti deve essere uguale alla dimensione del parallelismo tensoriale

• La dimensione del parallelismo pipeline deve essere uguale a 1

• L'attenzione data-parallel deve essere disabilitata

• La decodifica speculativa deve essere disabilitata

L'ultimo vincolo è quello dietro cui c'è una decisione reale. Per un modello sparso che attiva circa 6B parametri per token, la decodifica speculativa è una delle poche leve che accelera la decodifica, e questa funzionalità disattiva esplicitamente quella leva in cambio di un guadagno sul prefill. Se il tuo carico di lavoro prevede prompt lunghi e output brevi — analisi di documenti e codebase, riassunto di video, un contesto ampio letto una sola volta — lo scambio è semplicemente conveniente. Se il tuo carico di lavoro prevede un prompt breve e una generazione lunga, stai rinunciando alla cosa che ti stava aiutando e acquistando un numero che non si applica al tuo caso. Il requisito expert-parallel uguale a tensor-parallel è l'altro da notare: significa che la geometria di sharding MoE deve allinearsi esattamente alla geometria TP, il che esclude diverse configurazioni multi-nodo altrimenti ragionevoli.

Cosa dice questo sulla timeline di Qwen 4

Leggi il diff in un'altra ottica e ottieni un calendario. Il modulo LayerNorm-SP di SGLang sul branch main oggi contiene una allowlist esplicita di architetture per le quali la funzionalità è stata convalidata, e al momento in cui scriviamo quella allowlist contiene esattamente una voce, Qwen3ForCausalLM — ogni altra architettura viene rifiutata in fase di costruzione se si passa il flag. Aggiungere Qwen4Exp a quel percorso non è quindi un ritocco a un'astrazione matura; è la prima volta che l'architettura Qwen4 viene portata su un'ottimizzazione che la precede di generazioni.

Metti questo a confronto con la documentazione pubblica e il quadro è coerente. Il fornitore ha annunciato il 2026-09-22 che Qwen 4 è in addestramento e ha presentato in anteprima quattro nomi di fascia — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus e Qwen 4 27B — senza alcuna specifica associata ad alcuno di essi. L'anteprima open-weight che condivide l'architettura, Qwen3.8-Flash-Next, è scaricabile dal 2026-08-26. Ciò che sta accadendo nelle tre settimane successive è esattamente ciò che ci si aspetterebbe tra "in addestramento" e "lancio": gli autori dei motori che collaudano il runtime affinché il supporto day-zero sia reale anziché nominale. Una pull request che fa funzionare un'ottimizzazione di serving sull'architettura, aperta la mattina del 2026-10-08 e ancora in bozza, è un segnale migliore su quanto Qwen 4 sia vicino a essere servibile rispetto a qualsiasi data qualcuno abbia ventilato. Inoltre, va detto con enfasi, non è una data di rilascio — il flag è disattivato per impostazione predefinita, la modifica non è stata unita, e il modello su cui esegue i benchmark è l'anteprima, non Qwen 4.

Cosa puoi chiamare oggi

Niente di tutto ciò cambia quello che è effettivamente disponibile questo pomeriggio. Qwen3.8-Flash-Next esiste davvero, i suoi pesi sono su Hugging Face e puoi ospitarlo in autonomia — ma non è nel nostro catalogo, e non fingeremo il contrario. Il tier che offriamo è qwen/qwen3.8-flash, il fratello gestito che esegue la stessa architettura Qwen4-preview con una finestra di contesto da 1M token e input di testo, immagini e video, al prezzo di $0,15 per milione di token di input, $0,47 per milione di token di output e $0,0184 per milione di letture dalla cache. È un prezzo di listino passato con uno 0% di ricarico, quindi quando il fornitore lo modifica, il numero sulla tua fattura cambia lo stesso giorno, anziché attendere che un intermediario ripubblichi una tabella.

C'è una seconda ragione, meno ovvia, per occuparsi di uno strato di routing in questo contesto. Tutto in questo articolo riguarda un'anteprima non ancora collaudata più una patch in bozza — il tipo di cosa che vuoi testare senza puntarci un percorso di produzione. È a questo che serve il failover: metti l'anteprima dietro la stessa chiave del modello di cui ti fidi già, osserva come si comporta sul tuo traffico e lascia che la richiesta ricada sulla rotta nota e funzionante quando un provider vacilla o l'endpoint non c'è.Una sola API per oltre 200 modelli, un unico set di credenziali, nessun secondo contratto da firmare per scoprire se una nuova architettura merita la tua attenzione.

Due cose da tenere d'occhio da qui in avanti, nessuna delle quali possiamo prevedere. La prima è se questa patch verrà unita del tutto: è una bozza con tre esecuzioni CI fallite su una modifica di sei file da un account di contributore senza alcuna storia precedente nel repository, e la fluidità del lavoro sul layout delle righe di PLE suggerisce che l'autore stia ancora iterando. La seconda è se l'allowlist cresce — se Qwen4Exp si unisce a Qwen3ForCausalLM come architettura convalidata, allora questo smette di essere una fuga e diventa il modo predefinito in cui un modello della famiglia Qwen4 viene servito su contesto lungo. Finché una di queste cose non accade, considera il 18% come una promessa su dove sta andando il runtime, non un numero che puoi affittare.