Un modello di generazione immagini può diventare sei volte più rapido nella fase che occupa la GPU e offrire, alla fine, un miglioramento molto più modesto per chi aspetta il risultato. Non è un paradosso: è la differenza tra ottimizzare una funzione e progettare un servizio. Il nuovo approfondimento NVIDIA su FLUX 3 Image Klein permette di vedere questa distanza con numeri abbastanza dettagliati da ragionare sull’architettura, anziché fermarsi al solito moltiplicatore di velocità.
Il 6 novembre 2026 NVIDIA ha pubblicato misure e configurazioni di TensorRT LLM VisualGen per i checkpoint Base e distilled di Black Forest Labs. Sono benchmark del produttore, su hardware e workload specifici, non una certificazione indipendente. Proprio per questo vale la pena leggerli come una mappa dei colli di bottiglia, non come una promessa di prestazioni trasferibile a qualsiasi server.
Il numero da guardare non è il picco, ma la scomposizione della latenza
Nella configurazione NVFP4 compilata su una B200, a 2048 × 2048, NVIDIA attribuisce al denoising 14,24 secondi dei 14,70 complessivi per Base text-to-image: il 96,8%. Nel modello distilled il denoising richiede 2,28 secondi su 2,71, cioè l’84%. Nell’image-to-image Base si arriva al 97,8%; nel distilled all’89%. Non sono quattro versioni dello stesso problema: cambiano numero di step, conditioning e costo delle altre fasi.
Quando una fase pesa quasi tutto il tempo, intervenire lì è sensato. Ma una volta ridotta, il resto diventa visibile. Preparazione degli input, codifica delle immagini di riferimento, decodifica, trasferimenti e overhead del servizio non scompaiono perché abbiamo trovato un kernel migliore. È la logica della legge di Amdahl applicata alla generazione visiva: il limite del sistema è la parte che non abbiamo accelerato.
NVFP4, attention e caching: tre interventi, tre tipi di compromesso
Il primo livello è numerico. Passare da BF16 a NVFP4 sfrutta le capacità delle GPU Blackwell e riduce il costo di alcune operazioni. NVIDIA indica fino a 1,62× nel text-to-image e 1,58× nell’image-to-image su una singola B200. Il vantaggio non è un attributo astratto del formato: dipende da pesi quantizzati disponibili, implementazione dei kernel, forme dei tensori e percorso di esecuzione.
Il secondo livello è l’attenzione. Nel profilo riportato da NVIDIA, l’attenzione BF16 tradizionale assorbe circa il 60% del tempo dei kernel DiT a 2048 × 2048. Versioni FP8 e sparse riducono il lavoro, ma possono modificare l’output. Per VC-Attention FP8 NVIDIA riporta circa 1,18× su Base e 1,16× sul distilled, con valori LPIPS rispetto al riferimento; per Sol-Attention la scelta fra 12 e 16 step iniziali densi cambia il compromesso tra fedeltà e velocità.
Il terzo livello è temporale: Cache-DiT riusa risultati intermedi tra step di denoising. Nel test Base a 2048 × 2048 NVIDIA registra 1,94× con LPIPS 0,033 rispetto alla variante senza cache. Sul distilled il guadagno dichiarato scende a 1,20×. È un dato interessante proprio perché il caching non produce lo stesso rendimento su ogni modello. Se il modello fa già pochi passaggi, lo spazio per eliminare calcoli ripetuti è minore.
LPIPS, però, misura una distanza percettiva rispetto a un’immagine di riferimento: non dice da solo se il testo nell’immagine è leggibile, se un oggetto è stato aggiunto correttamente o se un edit ha conservato la parte che l’utente voleva proteggere. Una metrica di similarità è utile, ma non sostituisce test su prompt, casi limite e revisioni reali.
Otto B200 non danno otto volte la velocità
Il caso più istruttivo è il parallelismo. NVIDIA misura sul Base una mediana text-to-image di 14,90 secondi con una B200 e 3,00 secondi con otto B200: circa 4,97× sul tempo totale, contro 6,01× nella sola fase di denoising. Sul distilled il totale passa da 2,73 a 1,08 secondi: circa 2,53×, mentre il denoising accelera 4,44×. Il lavoro distribuito scala, ma gli altri passaggi e i costi di coordinamento limitano il beneficio osservato.
Questo dettaglio cambia una decisione di acquisto. Se una seconda GPU taglia la latenza percepita solo marginalmente, potrebbe essere più utile aumentare la concorrenza delle richieste, tenere code separate o ottimizzare la preparazione degli input. La risposta dipende dal carico: generazione batch, editing interattivo e API con molti utenti contemporanei non hanno lo stesso obiettivo. Una configurazione eccellente per la latenza del singolo job può non massimizzare il throughput per euro.
Come misurerei una pipeline prima di portarla in produzione
Partirei da una baseline dichiarata e riproducibile: modello e revisione esatti, precisione, risoluzione, step, guidance, GPU, versione del runtime e configurazione YAML. Poi distinguerei cold start, warmup, compilazione e inferenza a regime. NVIDIA esplicita due richieste di warmup e una media su dieci richieste per una delle sue tabelle; non bisogna confondere quel protocollo con una distribuzione di latenza di un servizio reale sotto carico.
Misurerei separatamente p50, p95 e p99 end-to-end, tempi di preprocessing e denoising, picco di memoria, immagini al minuto, consumo energetico quando disponibile e costo per output accettato. Il parametro importante è quest’ultimo: se una variante più rapida aumenta gli edit da rifare, il risparmio GPU può trasformarsi in più lavoro per chi usa lo strumento. È lo stesso problema discusso nel caso delle correzioni nelle immagini generate via API.
Per la qualità preparerei un set fisso di prompt e immagini di riferimento, con categorie diverse: testo nell’immagine, geometrie, fedeltà del soggetto, modifiche locali, preservazione dello sfondo e richieste con più riferimenti. Confronti ciechi, controlli automatici e una soglia di accettazione definita prima dei test aiutano a evitare che l’immagine più veloce venga dichiarata migliore solo perché il benchmark la premia.
Una misura pubblicata da Sogni su FLUX 3 Image Klein e altri modelli offre un secondo punto di osservazione, ma usa un ambiente e un confronto diversi: non va accostata direttamente ai secondi NVIDIA come se fossero lo stesso esperimento. È una conferma dell’importanza di specificare workload e piattaforma, non una validazione indipendente dei moltiplicatori TensorRT.
L’ottimizzazione utile è quella che cambia il servizio
La combinazione NVIDIA di compilazione, NVFP4, attenzione sparsa e caching porta, nei test dichiarati su una B200 a 2048 × 2048, il Base text-to-image da 22,36 a 6,46 secondi e l’image-to-image da 54,64 a 12,28. Sono risultati importanti e tecnicamente documentati, ma il confronto parte da BF16 non compilato. Non bisogna trasformare 3,46× e 4,45× in una previsione automatica per un’infrastruttura già ottimizzata.
La lezione più interessante non è che Blackwell renda veloce FLUX 3. È che ogni miglioramento sposta il collo di bottiglia. Prima domina il denoising, poi diventano rilevanti decodifica, orchestration, traffico tra GPU, code e qualità del risultato. Un sistema ben progettato non insegue il numero più grande in una slide: sceglie quali millisecondi eliminare in funzione di ciò che l’utente sta realmente aspettando.
\n\nDomande frequenti
Perché un denoising sei volte più veloce non rende l'intera generazione sei volte più rapida?
Perché preprocessing, decoding, comunicazione fra GPU e altri passaggi non accelerano nella stessa proporzione. La latenza totale è la somma delle fasi, non il solo tempo del denoising.
NVFP4 produce sempre immagini equivalenti a BF16?
No. La quantizzazione può modificare l’output. Bisogna confrontare le immagini su prompt rappresentativi e controllare la qualità degli edit oltre alle metriche percettive.
Che cosa misura LPIPS nei test di generazione immagini?
Una distanza percettiva tra immagini, rispetto a un riferimento. È utile per stimare differenze visive ma non dimostra da sola la correttezza semantica o la fedeltà a un’istruzione.
Conviene usare otto GPU B200 per FLUX 3 Image Klein?
Dipende da latenza richiesta, throughput, carico concorrente e costi. Nei test NVIDIA il miglioramento end-to-end con otto GPU è inferiore a otto volte e varia fra Base e distilled.