SGLang-Diffusion supporta Qwen-Image-2.1 dal giorno zero: generazioni in 2,75 s su una B200

Qwen-Image-2.1 è stato reso pubblico il 20 settembre 2026, e il team di SGLang-Diffusion aveva già pronto un percorso di serving ad attenderlo. Il supporto day-zero copre i tre compiti che il modello svolge — generazione text-to-image, editing multi-immagine e output RGBA trasparente — e arriva con qualcosa di più raro di una pull request mergiata: latenze misurate su hardware specifico, pubblicate insieme alla configurazione che le ha prodotte. Su una singola NVIDIA B200, 1024×1024 a 40 step, i numeri di SGLang si attestano a 2,748 secondi per una generazione e 3,358 secondi per un edit. La pull request di supporto, sgl-project/sglang#39983, è stata aperta il 17 settembre — tre giorni prima che i pesi fossero scaricabili — ed è per questo che i numeri esistono davvero, invece di essere promessi per il futuro.

Cosa significa "day zero" qui, e perché la tempistica è la parte interessante

Il supporto per un framework viene di solito annunciato nello stesso momento del rilascio di un modello e reso disponibile settimane dopo. Il caso di SGLang va nella direzione opposta. L'implementazione è stata scritta rispetto a un checkpoint non ancora pubblico, il che costringe gli autori a gestire l'architettura reale invece di una scheda tecnica: il diffusion transformer, il VAE RGBA a 64 canali, il condizionamento Qwen3-VL, l'input con più immagini di riferimento e RGBA in ingresso e in uscita.

Questa è la ragione per fidarsi di una tabella di latenza più che di un elenco di capacità. Un modello che non è mai stato servito non ha numeri misurati, e un numero che arriva con hardware, risoluzione, numero di step e precisione allegati può essere verificato da chiunque abbia la stessa scheda. I dati di SGLang sono etichettati come una configurazione specifica, non come un'affermazione generale sul modello.

Il resto degli strumenti è arrivato nella stessa finestra temporale. ComfyUI ha rilasciato il supporto nativo, Diffusers ha integrato QwenImage21Pipeline, vLLM-Omni ha aggiunto l'esecuzione step-wise e la quantizzazione FP8, e LightX2V ha aggiunto l'accelerazione con il supporto AMD Radeon tramite ROCm. I framework sono la parte di un rilascio che decide se qualcuno al di fuori di un laboratorio può usarlo.

I numeri, e ciò che non dicono

Il lavoro su SGLang pubblica la latenza per richiesta, non il throughput. Questa distinzione conta se stai dimensionando un servizio anziché eseguire una demo: una singola generazione da 2,7 secondi ti dice il tempo di andata e ritorno, non quanti utenti concorrenti riesce ad assorbire una scheda. Le configurazioni pubblicate, tutte a 1024×1024 e 40 step:

• B200, pesi residenti, FlashAttention — 2,748 s in generazione, 3,358 s in editing, dopo una correzione alla Q/K-norm e una modifica alla LayerNorm, ciascuna delle quali ha ridotto i tempi di qualche punto percentuale.
• RTX PRO 6000 Blackwell, 96 GB, residente — 8,23 s in generazione, 9,85 s in editing con un'occupazione di picco di 40,1 GiB; 10,28 s e 10,66 s con il diffusion transformer in offload, portando il picco a 26,1 GiB.
• DGX Spark, 1× GB10, eager, decodifica VAE completa — 35,36 s in generazione, 42,23 s in editing, 35,49 s e 42,21 s per le varianti trasparenti. Questi tempi includono la serializzazione PNG. I grafi CUDA interrompibili hanno prodotto pixel identici senza alcun beneficio di velocità misurabile (35,96 s contro 35,64 s), e il batching e le configurazioni multi-Spark non sono stati affatto sottoposti a benchmark.
• RTX 4090, 24 GB, offload layerwise, solo denoise — 26,69 s in BF16 base con SDPA, 10,31 s con Cache-DiT (2,59×), 5,59 s con Cache-DiT più il set di kernel INT8 (4,77×), 4,74 s aggiungendo Sage attention (5,63×).

Su quelle righe pendono due avvertenze oneste. Primo, sono latenze di singola richiesta, e la riga 4090 misura solo il denoising — il text encoder e il VAE restano fuori dal cronometro. Secondo, gli autori di SGLang inquadrano la verifica più ampia come funzionale, non valutativa: l'output BF16 non è bit-exact tra collocazioni diverse, e la quantizzazione o il parallelismo tensoriale cambiano i numeri. Più veloce e diverso non equivale a più veloce e migliore.

Perché il percorso con output trasparente è quello da tenere d'occhio

RGBA è dove questo modello differisce dagli endpoint immagine che la maggior parte dei team già chiama, ed è anche dove il serving diventa scomodo. Qwen-Image-2.1 esegue il denoising in uno spazio latente che ha un canale alpha come componente di prima classe, tramite un VAE RGBA a 64 canali con compressione spaziale 16×. La trasparenza non è un post-processo da aggiungere con un modello di segmentazione; è ciò che emette il sampler.

Servire bene quel formato è più difficile che servire RGB. L'output è più grande, il VAE ha più canali da decodificare e la richiesta porta con sé un bit di modalità extra che lo scheduler deve instradare. La verifica di SGLang copre esattamente questo ambito — output PNG trasparente, alpha conservato lungo l'intero intervallo 0–255 e un PSNR RGBA di 60,69 dB su un singolo campione, con le configurazioni FP8 che superano anch'esse la generazione trasparente. Si tratta di un controllo di correttezza, non di un benchmark di qualità, e gli autori lo dicono apertamente. Stabilisce che il canale alpha è reale e sopravvive alla quantizzazione; non dice nulla sulla pulizia dei bordi su capelli, pelliccia o vetro.

Il valore pratico di uno stack di serving con un percorso di trasparenza collaudato sta nel fatto che trasforma una pipeline di tre strumenti in un'unica chiamata. La generazione con alpha, la modifica all'interno di un'immagine che ha già l'alpha e l'estrazione di un soggetto da una normale fotografia RGB in un livello trasparente passano tutte attraverso lo stesso endpoint.

Dove si inserisce questo se non stai eseguendo tu stesso la GPU

La parte scomoda del rilascio di Qwen-Image-2.1 è che non c'è alcun endpoint ospitato da chiamare. I pesi sono un download di circa 33 GB, il componente di generazione è un diffusion transformer da 7B abbinato a un text encoder Qwen3-VL 8B, e il tutto viene distribuito sotto il Qwen Research License Agreement datato 20 settembre 2026 — solo per uso non commerciale, con l'implementazione commerciale che richiede una licenza separata dal fornitore. Quindi la ricetta SGLang non è un'alternativa a un'API. È l'API, e l'operatore sei tu.

Questo cambia lo scopo di un livello di routing. OrcaRouter mette davanti oltre 200 modelli dietro un unico endpoint compatibile con OpenAI, al prezzo di listino del provider e senza alcun ricarico, failover automatico tra provider, un DSL di routing per comporre fallback e fusione di modelli per chiamate in stile panel — ma non instrada alcun modello Qwen-Image di nessuna versione, e Qwen-Image-2.1 non sarà mai una route che puoi chiamare lì. L'architettura realistica è di tipo diviso: esegui Qwen-Image-2.1 sul tuo hardware tramite SGLang per il lavoro trasparente e multi-riferimento, e invia tutto il resto ai modelli di immagini ospitati con una sola chiave. Il nostro catalogo include la linea GPT-Image di OpenAI, i livelli di Imagen 4 di Google e le anteprime di immagini Gemini, e l'endpoint per immagini Grok Imagine di xAI, tutti al prezzo di listino pass-through, così un cambio di prezzo di un fornitore su uno qualsiasi di essi è attivo dalla nostra parte lo stesso giorno.

Che aspetto ha davvero un deployment

La documentazione di SGLang include un cookbook per questo modello con comandi specifici per GPU, e l'invocazione consigliata del server è una singola riga — sglang serve --model-path Qwen/Qwen-Image-2.1 --performance-mode speed. Le richieste di generazione di immagini da testo supportano il batching dinamico opzionale; le richieste di modifica delle immagini vengono gestite come un percorso separato, e una singola richiesta può restituire più output.

Le configurazioni che sono state effettivamente verificate sono più limitate di quanto lasci intendere la matrice di compatibilità. H200, B200, RTX PRO 6000 96 GB, RTX 5090 e RTX 4090 sono coperte per la generazione e l'editing a 1024×1024 in 40 passaggi, incluse le loro varianti trasparenti, oltre al parallelismo tensoriale multi-GPU, a Ulysses e Ring attention, all'offload layerwise, alla decodifica VAE tiled parallela, a Cache-DiT, ai CUDA graphs e alla quantizzazione FP8 online e serializzata. Le ricette multi-GPU e NVFP4 su RTX PRO 6000 restano non verificate, mentre il RDMA multi-host e i ruoli disaggregati multi-rank non sono coperti. Se il tuo piano prevede quattro schede e un fabric, sei più avanti rispetto alle evidenze pubblicate.

Due cose da tenere d'occhio prossimamente. La prima è se qualcuno pubblica il throughput anziché la latenza — i numeri sulla concorrenza sono ciò che trasforma una cifra di 2,7 secondi in un piano di capacità. La seconda è la licenza: non esiste un prezzo pubblicato né un term sheet per l'uso commerciale di Qwen-Image-2.1, e finché non ci sarà, la restrizione non commerciale è tutto ciò che conta per qualunque cosa venga distribuita a un cliente.