Qwen-Image-2.1-Turbo vs Qwen-Image-2.1: cosa è cambiato davvero tra il checkpoint base e quello accelerato

Stesso componente di generazione visiva da 7B. Stessi 32 livelli DiT a flusso singolo. Stesse sette preimpostazioni di risoluzione, stessa superficie unificata di generazione e modifica, stessa licenza non commerciale, stessa classe di pipeline per caricarlo. Qwen-Image-2.1-Turbo e Qwen-Image-2.1 non sono due modelli tra cui scegliere in base alle capacità — il checkpoint Turbo è un fine-tune della base, e il repository lo dichiara nei propri metadati. Ciò che li separa è una singola traiettoria di campionamento, e il modo in cui quella traiettoria viene memorizzata. Uno esegue quaranta passi. L'altro ne esegue otto, e rifiuta di ricevere istruzioni diverse al momento della chiamata. Tutto ciò che c'è di interessante nella coppia è in quella seconda frase.

Inizia dalle parti che sono identiche

Prima delle differenze, vale la pena mappare ciò che è uguale, perché è più esteso di quanto suggerisca l'etichetta "Turbo" ed è ciò che rende attraente lo scambio.

• L'architettura. La scheda Turbo afferma che "utilizza la stessa architettura di generazione visiva da 7B" di Qwen-Image-2.1. Il progetto descrive quel componente come 7B parametri su 32 livelli Single-Stream DiT. Nulla nel repository Turbo annuncia un backbone più piccolo, potato o ri-architettato.

• Le capacità. Entrambi i checkpoint sono descritti come in grado di eseguire la generazione da testo a immagine e la modifica delle immagini. Turbo eredita la superficie del modello base anziché ripeterla: la scheda del modello base documenta la trasparenza RGBA nativa, fino a 10 immagini di riferimento e modifiche locali specificate da cerchi, annotazioni dipinte o maschere separate, con conservazione dell'identità per persone e prodotti.

• Le risoluzioni. La scheda di Turbo dice di "usare gli stessi preset di risoluzione di Qwen-Image-2.1" e poi li elenca: 1:1 a 2048 × 2048, 4:3 a 2400 × 1792, 3:4 a 1792 × 2400, 3:2 a 2528 × 1696, 2:3 a 1696 × 2528, 16:9 a 2752 × 1536 e 9:16 a 1536 × 2752. La scheda del modello base elenca la tabella identica. Entrambe le schede usano il livello di risoluzione 2048 per i loro esempi.

• Il percorso di caricamento. Entrambi si caricano tramite QwenImage21Pipeline in Diffusers. La guida rapida della scheda Turbo è la guida rapida della scheda base con il nome del checkpoint modificato e bfloat16 scritto dtype invece di torch_dtype.

• I documenti.Entrambi sono concessi in licenza secondo il Qwen-Image-2.1 Research License Agreement, entrambi riportano license: other con license_name: qwen-research, ed entrambi hanno un file LICENSE che si trova nel repository accanto ai pesi.

Se hai già Qwen-Image-2.1 configurato, allora la superficie di migrazione è davvero contenuta. Ed è esattamente per questo che vale la pena soffermarsi sull'unico argomento che non si comporta come ti aspetti.

La pianificazione è uscita dal tuo codice ed è passata al checkpoint

Sul modello base, il numero di passi lo decidi tu. L'esempio text-to-image della scheda di Qwen-Image-2.1, il suo esempio di editing e il suo esempio di trasparenza RGBA passano tutti num_inference_steps=40, e quel numero è un argomento fornito al momento della chiamata nel modo consueto di Diffusers. Nulla su quella scheda ti dice che il checkpoint ha delle opinioni sulla schedulazione.

Su Turbo, il programma di campionamento è metadati del checkpoint. La scheda afferma che il checkpoint "include il proprio programma di campionamento consigliato, quindi è pronto all'uso senza configurare manualmente lo scheduler", e poi, nella sezione sul campionamento, spiega cosa significa in pratica: "Il programma di campionamento consigliato a 8 passaggi viene salvato con il checkpoint e caricato automaticamente. Impostare solo num_inference_steps non lo sovrascrive."

Ne derivano due cose, ed è facile sbagliarle entrambe in direzioni opposte.

Il primo è che otto non è un valore predefinito che si può aumentare a piacere. Se volete sapere come si comporta Turbo a dodici o venti passaggi, la scheda vi dice che l'unica via è un argomento sigmas esplicito al momento della chiamata — e poi chiude la porta all'esperimento osservando che altri schemi "non sono stati valutati per questo checkpoint". È un fornitore che vi sta dicendo che la configurazione a otto passaggi è quella che garantisce, e che qualsiasi altra cosa è territorio inesplorato in cui vi addentrate da soli. È una frase insolitamente onesta e va letta come un confine, non come un invito.

Il secondo è una trappola di riproduzione senza alcun messaggio di errore allegato. Prendi l'esempio del modello base, cambia la stringa del repository con il checkpoint Turbo, lascia num_inference_steps=40 al suo posto, e il codice verrà eseguito. Non ti avviserà. Produrrà un'immagine usando la pianificazione salvata a otto passaggi, e non sarà l'output che la vetrina Turbo mostra, perché quaranta non è mai stato letto. Questo è il tipo di guasto in cui nulla sembra rotto — il rendering si completa, l'immagine è plausibile, e l'unico modo per scoprirlo è mettersi a cercare una differenza. C'è una seconda dipendenza nascosta accanto ad essa: il checkpoint richiede una build di Diffusers che comprenda i sigma di campionamento configurati nella pipeline, aggiunti nella PR #14950, che al momento in cui scriviamo si trovano nell'albero dei sorgenti di Diffusers anziché in una release con tag. L'installazione indicata è una build di PyTorch compatibile con CUDA più i sorgenti di Diffusers, transformers>=5.17.0, accelerate e pillow.

Che cosa paga per i 32 passi che non hai fatto

La scheda menziona due meccanismi, ed entrambi vale la pena conoscerli perché spiegano ciò che il checkpoint Turbo presuppone su come lo chiamerai.

• CFG 1 per impostazione predefinita. "La generazione utilizza CFG=1 per impostazione predefinita." Con una scala di classifier-free guidance pari a uno, il modello non esegue il secondo passaggio incondizionato che CFG normalmente richiede — il che è gran parte del motivo per cui una traiettoria viene accorciata senza essere semplicemente troncata. Significa anche che l'abitudine del modello di base di tarare una scala di guidance non si trasferisce; qui non c'è nulla da tarare, e la card non offre alcuna raccomandazione di guidance a cui fare riferimento.

• Caching KV del prefisso. La scheda di Turbo dice che "il caching KV del prefisso riutilizza il contesto testuale e dell'immagine di riferimento attraverso i passaggi di denoising". Si tratta di un meccanismo ereditato, non di qualcosa di nuovo per il checkpoint accelerato: l'annuncio di Qwen-Image-2.1 elenca il riutilizzo della cache KV del prefisso tra i quattro miglioramenti di punta del modello base, insieme all'attenzione a granularità mista, e le integrazioni di serving day-zero per il modello base — le voci vLLM-Omni e SGLang nell'elenco delle notizie del progetto — citano esplicitamente il caching KV del prefisso tra le funzionalità supportate. In un ciclo di quaranta passaggi quel riutilizzo è un'ottimizzazione. In un ciclo di otto passaggi conta proporzionalmente di più, perché ogni passaggio in cache rappresenta una quota maggiore del lavoro totale.

La scheda non menziona alcuna tecnica di distillazione. La scheda del modello base Qwen-Image-2.1 e il README del progetto descrivono architettura e capacità; la scheda Turbo descrive la meccanica. Se stai cercando di ragionare su quanto costano otto passi in termini di qualità, il repository non ti offre alcun metodo su cui basare il ragionamento — solo uno schedule e una serie di immagini dimostrative.

Il conteggio dei passi non è un benchmark

Questa è la parte del confronto in cui la risposta onesta è che non c'è confronto, e vale la pena essere schietti sul perché.

• Il checkpoint Turbo non ha un punteggio pubblicato. La sua scheda non riporta alcun numero di valutazione di alcun tipo. Non esiste alcun risultato di Qwen-Image-Bench per Turbo, nessun confronto affiancato con il checkpoint base, nessuna ablazione sul numero di step e nessuna tabella che mostri dove la qualità si stabilizza.

• Il punteggio del checkpoint base è dichiarato dal fornitore. L'unico dato di rilievo della linea Qwen-Image-2.1 è il risultato Qwen-Image-Bench del modello base stesso, riportato dal fornitore relativamente al checkpoint base. Non è una misurazione del checkpoint Turbo e non dovrebbe essere attribuito a quest'ultimo — l'accelerazione è esattamente ciò che ci si aspetterebbe possa spostare un simile valore, e il fornitore non ha detto di quanto.

• Nessuna delle due schede riporta tempi o memoria. Non c'è alcun dato sulla latenza, né sulla capacità di throughput né sull'occupazione di memoria per nessuno dei due checkpoint, e nessuna delle due schede indica l'hardware su cui sono stati eseguiti gli esempi. La scheda del modello base documenta almeno una sezione sull'ottimizzazione della memoria; la scheda Turbo documenta installazione, generazione, editing, sampling e aspect ratio, e si ferma lì.

Quindi l'argomento a favore di Turbo rispetto al checkpoint base è attualmente una questione di intento progettuale, non di risultati misurati. Otto passi con la stessa architettura e lo stesso livello di risoluzione 2048 dovrebbero costare sostanzialmente meno per immagine. «Sostanzialmente» ha un peso concreto in quella frase, e l'unico modo per sostituirlo con un numero è eseguire entrambi i checkpoint sul tuo carico di lavoro, che è anche l'unico modo per scoprire che effetto ha la traiettoria accorciata sulle immagini specifiche che ti interessano.

Nient'altro si è mosso, inclusa la licenza

Due cose che un lettore potrebbe ragionevolmente aspettarsi che siano cambiate, e che invece non lo sono.

Il primo è l'ecosistema. Quando Qwen-Image-2.1 è stato rilasciato il 20 settembre 2026, l'elenco delle novità del progetto ha registrato cinque distinte integrazioni day-zero lo stesso giorno: supporto a Diffusers tramite PR #14804, supporto nativo a ComfyUI con template di workflow pubblicati per la generazione da testo a immagine e per l'editing, supporto a vLLM-Omni con esecuzione step-wise, decodifica CUDA Graph, quantizzazione FP8 e parallelismo tensoriale, supporto a SGLang con Cache-DiT e offload dei componenti, e accelerazione dal progetto LightX2V. La voce datata 9 ottobre 2026 che riguarda Qwen-Image-2.1-Turbo registra il checkpoint stesso e una nota secondo cui le API Pro e Turbo sono attive su Alibaba Cloud Model Studio. Non esiste un elenco di framework day-zero per Turbo, e ogni voce di framework nell'elenco delle novità fa ancora riferimento al modello base. Il checkpoint Turbo viene caricato tramite una classe di pipeline già esistente; il supporto per la sua schedulazione salvata è l'unico nuovo tassello, e arriva tramite il codice sorgente di Diffusers anziché una release con tag.

Il secondo è la licenza. Turbo porta con sé il Qwen Research License Agreement, esattamente come il modello base. L'accelerazione non è arrivata con un'esenzione commerciale, un livello separato o un allentamento dei termini: la restrizione non commerciale vale sul fine-tune tanto quanto sul base. I metadati stessi del repository e il file di licenza accanto ai pesi sono la prova; la sezione sulla licenza della card è una sola frase che rimanda allo stesso accordo. Se il motivo per cui gli otto passi ti interessano è che rendono il modello abbastanza economico da inserirlo in un prodotto, la licenza è proprio d'intralcio, ed è il fornitore — non questo repository — a doverne rispondere.

Endpoint ospitati e dove si colloca OrcaRouter

OrcaRouter non instrada né Qwen-Image-2.1-Turbo né Qwen-Image-2.1. Entrambi sono assenti dal nostro catalogo, e nulla qui costituisce un'offerta per servirli. Se li vuoi, le tue opzioni sono le API ospitate dal fornitore stesso, diverse piattaforme di terze parti, oppure i pesi con una build di Diffusers abbastanza recente da gestire la schedulazione di campionamento salvata nel checkpoint Turbo.

Laddove OrcaRouter è rilevante per questo particolare confronto è lo scambio che fai quando il self-hosting di un checkpoint smette di essere la risposta giusta. Passare da un modello a pesi aperti che esegui tu stesso a un endpoint per immagini ospitato non è solo un cambio di modello — è un cambio di modalità di guasto. Un processo locale fallisce in modi che puoi vedere; un endpoint ospitato fallisce in modi che dipendono da quale provider ha risposto e da ciò che accade quando uno di essi si degrada a metà richiesta. OrcaRouter mette oltre 200 modelli dietro un unico endpoint compatibile con OpenAI e trasferisce il prezzo di listino del provider senza ricarico, così una riduzione di prezzo del fornitore compare dalla nostra parte lo stesso giorno invece di aspettare un passaggio di riprezzamento. Inoltre aggiunge failover automatico tra provider, un DSL di routing per specificare quali modelli e provider può usare una richiesta, e la fusione di modelli per comporre diversi modelli in un'unica chiamata. I modelli di immagini che mettiamo in front-end sono la famiglia OpenAI GPT-Image, i livelli di Google Imagen 4, incluse le varianti fast e ultra, gli endpoint di anteprima immagini di Google Gemini e l'endpoint immagini xAI Grok Imagine.

Concretamente: se stai scegliendo tra i due checkpoint Qwen, quella è una decisione di self-hosting, e i motivi per preferire l'uno all'altro sono il comportamento dello schedule e il numero di step. Se ciò di cui hai effettivamente bisogno è un'immagine in produzione senza possedere le GPU, quella è la decisione su cui siamo in grado di aiutarti, ed è una decisione diversa.

La versione breve

• Scegli Qwen-Image-2.1 se vuoi il checkpoint il cui comportamento di campionamento corrisponde alla sua documentazione, se hai bisogno di variare il numero di step o di esplorare le schedulazioni, oppure se vuoi la release arrivata con supporto day-zero su Diffusers, ComfyUI, vLLM-Omni, SGLang e LightX2V.

• Scegli Qwen-Image-2.1-Turbo se desideri la stessa architettura e le stesse capacità con una traiettoria drasticamente più breve, sei disposto a considerare otto passaggi come fissi e a installare Diffusers dal sorgente per caricarlo.

• In entrambi i casi aspettati la stessa licenza, e non aspettarti alcun valore di qualità pubblicato per il checkpoint accelerato da confrontare con quello base. La riduzione dei passaggi è reale e documentata. Quanto costi in termini di qualità dell'immagine non è documentato da nessuna parte, e per quante volte tu legga le due schede non lo scoprirai — quella risposta esiste solo sul tuo hardware, con i tuoi prompt.