Cosa determina davvero la tua bolletta per la generazione di immagini
Indice
Abbiamo aggiunto la generazione di immagini a un gateway pensato per gli LLM di testo e abbiamo misurato cosa determina il costo su quattro variabili: modello, risoluzione, numero di immagini e qualità. La leva più importante è la qualità, un parametro che quasi tutte le API di immagini espongono e che quasi tutti i chiamanti lasciano al valore di default. Risoluzione, prompt caching e batching contano molto meno di quanto si pensi.
TL;DR
- La manopola
qualitydi gpt-image fa oscillare il costo di circa 36 volte alla stessa risoluzione: 196 / 1.756 / 7.024 token di output fatturati ($0.0060 / $0.053 / $0.211) per low/medium/high a 1024x1024. - La scelta del modello è una leva da 6.4 volte: $0.0060 per immagine su gpt-image-2 a bassa qualità contro $0.0387 su gemini-2.5-flash-image.
- La risoluzione conta a malapena: passare da 1024x1024 a 2048x2048 ha solo raddoppiato il costo per immagine di gpt-image-2.
- La generazione di immagini non ha il prompt caching, e
n=4rifattura il prompt quattro volte; la fatturazione per token vince sotto circa 1.000 token di output, quella fissa per immagine vince sopra.
Come si differenziano i modelli di immagini
I modelli di immagini non sono intercambiabili tra loro. Divergono su diversi assi, e solo uno di questi (la forma di fatturazione) riguarda il prezzo. Il catalogo attivo a colpo d’occhio:
| Famiglia | Fatturazione | Parametro quality | Batch n>1 | Risoluzione |
|---|---|---|---|---|
gpt-image (OpenAI) | per token | ✓ low/med/high | ✓ | fino a ≈2K |
gemini-image (Google) | per token | ✗ | ✗ 1/chiamata | 1K (gemini-3: fino a 4K) |
qwen-image / wan2.7 (Alibaba) | flat/immagine | ✗ | ✓ | 512²–2048² |
seedream (BytePlus) | flat/immagine | ✗ | ✗ 1/chiamata | ≥1920² (4.5/5.0) |
Gli assi che ti fregano se dai per scontato che un modello si comporti come un altro:
- Forma di fatturazione. Per token (
gpt-image,gemini) o flat per immagine (qwen,wan,seedream). È l’asse che decide la tua bolletta, ed è l’argomento della prossima sezione. - Il parametro
quality. Sologpt-imagece l’ha (low/medium/high). Gemini cambia la fedeltà in base al tier del modello (flashopro) o aimage_size; i modelli flat non hanno una manopola del genere. Quel singolo parametro fa oscillare la bolletta di circa 36×, quindi è la leva di costo principale, trattata più sotto. - Il batch (
n>1) non è universale.gpt-image,qwenewanrestituiscono più immagini per chiamata. Tutti i modelli di immagini Gemini e Seedream fanno una sola immagine per chiamata: conn=2ottieni un400, quindi devi lanciare N richieste e orchestrare il batch da solo. - I limiti di risoluzione tagliano da entrambe le parti.
gemini-2.5-flash-imagesi ferma a 1K (1 MP), mentregemini-3arriva a 2K/4K (e la sua bolletta all’incirca raddoppia passando da 1K a 4K). Seedream 4.5/5.0 impongono un limite minimo di circa 1920² e rifiutano qualsiasi cosa più piccola.qwen-imagesta nella fascia 512²–2048². La risoluzione più alta non è sempre disponibile, e abbassare la risoluzione per risparmiare non è sempre permesso. - Le manopole di controllo e l’image-to-image variano. Solo alcuni modelli accettano
seed,negative_promptoguidance_scale, e il limite di immagini di riferimento per l’editing va da 3 (gemini-2.5) a 16 (gpt-image).
Il parametro quality ha una proprietà poco intuitiva. Per gpt-image un output token è un’unità di fatturazione, non una misura del file che ricevi. OpenAI assegna il conteggio a partire da una tabella pubblicata di tariffe per (quality × size) (272 / 1.056 / 4.160 token per low / medium / high a 1024² su gpt-image-1), quindi il conteggio è fissato da quality, non derivato dai byte restituiti. L’abbiamo verificato: lo stesso prompt a 1024² sui tre tier ha prodotto PNG identici da 1024×1024 di dimensione all’incirca uguale (circa 0,9 MB), eppure fatturati 196, 1.756 e 7.024 token. Stessa risoluzione, stessa dimensione in byte, 36× il costo. Paghi lo sforzo di rendering, non i pixel, ed è per questo che leggi usage invece di valutare a occhio l’output.
Una capacità che nessuno di questi modelli ha è il prompt caching, di solito la prima idea di risparmio a cui si pensa. La generazione di immagini è stateless: non c’è conversazione né stato KV da riutilizzare, l’oggetto usage non porta campi di cache e (come misuriamo più sotto) nemmeno il batching condivide il prompt. Il caching è una funzionalità della chat, non delle immagini, il che esclude un’ipotesi comune per tagliare il costo delle immagini.
Le misure
Stesso prompt di prodotto in stile e-commerce, generazioni reali attraverso il gateway, con il costo calcolato dai valori usage restituiti confrontati con le tariffe pubblicate di ciascun modello. Cinque risultati, ognuno da uno sweep separato.
1. Il costo è l’immagine, non il prompt. Nel text-to-image (un prompt in ingresso, un’immagine in uscita) il conto è per il 97–100% token di output: una generazione 1024² con gpt-image-2 sono 21 token di input e 196 di output (circa $0,0001 più $0,0059), e gemini-2.5-flash-image usa 10 token di input. Il prompt che scrivi è un errore di arrotondamento, ma solo perché è testo. Dai invece un’immagine in pasto al modello (image-to-image, tipo “rendi blu questa tazza”) e l’input tokenizza in grande:
| Modello | input t2i | input i2i (1 rif) | Output |
|---|---|---|---|
gpt-image-2 (low) | 21 tok | 1.043 tok | 196 tok |
gemini-2.5-flash-image | 10 tok | 1.297 tok | 1.290 tok |
L’input aumenta di 50–130×, e scala in modo lineare: ogni riferimento in più aggiunge circa 1.025 token su gpt-image-2 (1, 2 e 3 riferimenti misurati a 1.043, 2.068 e 3.093). A bassa qualità quei token di input superano l’output generato di cinque a uno. Il principio vale in entrambi i casi: il costo è l’immagine, che tu la generi o la fornisca, e non è mai il prompt. Il resto di questo articolo resta nel text-to-image; l’economia completa dell’image-to-image è un approfondimento a sé.
2. La scelta del modello è una leva da 6×. Richiesta 1024² identica, qualità di default:
| Modello | Fatturazione | Costo / immagine |
|---|---|---|
gpt-image-2 | token · leva quality | $0,0060 |
gpt-image-1-mini | token · leva quality | $0,0085 |
seedream-4-0 | flat per richiesta | $0,030 |
qwen-image-2.0 | flat per richiesta | $0,035 |
gemini-2.5-flash-image | token · nessuna leva quality | $0,0387 |
Un divario di 6,4× tra il percorso più economico e quello più caro, dettato interamente da quanti token di output emette ogni modello.
3. La risoluzione incide poco. Passando gpt-image-2 da 1024² a 2048², il costo per immagine è rimasto pressoché piatto (da $0,0060 a $0,0121); i token di output non sono proporzionali ai pixel. gemini-2.5-flash-image ha restituito gli stessi 1.290 token qualunque dimensione richiedessimo, perché è solo 1K e size cambia solo l’aspect ratio. (I tier image di gemini-3 rispettano image_size, raddoppiando circa il costo da 1K a 4K, ma 2.5-flash-image, il modello di cui calcoliamo qui il costo, no.) I modelli flat per immagine sono indipendenti dalla risoluzione per definizione. Finora il modello per-token sembra difficile da battere.
4. La qualità è il punto di svolta. Sweep di gpt-image-2 sui vari tier di qualità:
| quality | 1024² | 2048² |
|---|---|---|
| low | $0,0060 (196 tok) | $0,0121 (397 tok) |
| medium | $0,053 (1.756 tok) | $0,107 (3.568 tok) |
| high | $0,211 (7.024 tok) | $0,428 (14.272 tok) |
I token di output scalano di circa 9× da low a medium e di circa 36× da low a high. A bassa qualità il modello per-token è l’opzione più economica; a media o alta supera il prezzo flat per immagine ($0,03–0,035). Il punto di svolta è dove lo colloca l’aritmetica, intorno ai 1.000 token di output ($0,03 ÷ $30/M): low sta sotto, medium sta sopra. Questo corregge anche una nostra conclusione precedente. “Il per-token è sempre il più economico” era un artefatto del testare alla qualità low di default.

Stesso prompt, gpt-image-2, 1024². low / medium / high fatturano 196 / 1.756 / 7.024 token di output, ovvero $0,006 / $0,053 / $0,215: un divario di 36× a risoluzione identica. Per uno scatto di prodotto pulito come questo i tre sono difficili da distinguere, quindi il tier più economico spesso basta. Imposta quality in base al lavoro invece di lasciare high come default.
5. Non puoi condividere un prompt tra più immagini. Generare n immagini in una singola chiamata non ammortizza il prompt. gpt-image-2 lo fattura N volte: i token di input sono passati da 28 a 112 con n=4, e un prompt di brand lungo è passato da 499 a 1.996. Il costo per immagine era identico a n=1 e n=4. Senza nemmeno caching, non c’è alcun meccanismo di condivisione del costo del prompt per la generazione di immagini. Paghi per immagine di output, e il prompt viene rifatturato ogni volta.
La regola di decisione
Per il text-to-image tutto si riduce alla qualità, non ai fattori che di solito si danno per scontati:
- Qualità bassa / bozza / thumbnail: un modello a token con qualità (
gpt-image, circa $0,006–0,012). Il più economico a qualsiasi risoluzione fino a circa 2K. - Qualità media / alta: tariffa fissa per richiesta (
seedream/qwen, $0,03–0,035). Il conto a token esplode ($0,05–0,43 nei nostri test) e la tariffa fissa è sia più economica sia indipendente dalla qualità. gemini(circa $0,039 alla risoluzione 1K di default) raramente è la scelta più conveniente. Viene battuto dagpt-imagein bassa qualità e dalla tariffa fissa per richiesta in media e alta. Non ha una levaquality; sceglieresti il suo tier Pro o unimage_sizepiù alto per la qualità dell’output, non per il prezzo.- La risoluzione fa variare il costo di circa 2× all’interno di uno stesso tier di qualità, non abbastanza da cambiare la scelta. È la qualità a cambiarla.
n>1, caching e batching non riducono mai il costo per immagine. Non c’è nulla da condividere.- Image-to-image: usa di default la tariffa fissa per immagine. Un’immagine di riferimento è input, e solo i modelli a token la fanno pagare (circa 1.025 token ciascuna); i modelli a tariffa fissa la includono gratis. Per l’editing di solito vincono
seedream/qwen.gpt-imageresta più economico solo per modifiche di bassa qualità con pochi riferimenti (intorno a 5 supera il prezzo fisso), e perde non appena salgono qualità o numero di riferimenti.
L’e-commerce è l’esempio più chiaro. Supponi di generare le foto prodotto inviando lo stesso lungo prompt di brand per ogni articolo del catalogo, e di dare per scontato che il caching di quel prompt ripetuto faccia risparmiare. Non funziona per due motivi: il prompt non è mai stato il costo (lo è l’immagine), e per la generazione non c’è comunque alcun caching. Dato che le immagini prodotto reali sono di qualità media o superiore, la scelta giusta è un modello a tariffa fissa per immagine, più economico e più prevedibile a prescindere da quanto sono ripetitivi i tuoi prompt.
I vincoli di capacità visti nella sezione iniziale possono comunque ribaltare la scelta: modelli che generano una sola immagine per chiamata, risoluzioni minime e massime, limiti di data residency e quali leve (seed, negative_prompt, guidance_scale) un modello espone. Scegli in base al costo, poi verifica che le capacità siano adatte.
Perché puoi fidarti di questi numeri
Queste cifre derivano dallo usage reale confrontato con i listini di ogni vendor, non da stime. La fatturazione delle immagini sul nostro gateway è sessionless: si chiude solo su un 2xx (una generazione fallita non viene mai addebitata), verifica in anticipo il costo nel caso peggiore prima di qualsiasi spesa, e fattura al massimale una risposta priva di usage invece di lasciarla passare silenziosamente a $0. Il principio è lo stesso che applichiamo ovunque: fidati del costo reale, non della cifra che il vendor ti passa. È lo stesso metodo che abbiamo usato per verificare se un gateway mente sul cache.
In sintesi
La generazione di immagini sembra l’ennesimo endpoint, ma l’unità di fatturazione è cambiata. Per il text-to-image la leva non è il prompt (niente caching, niente condivisione via batch) né la risoluzione. È la qualità: gpt-image è il più economico in bassa, la tariffa fissa per immagine (seedream / qwen) vince in media e alta, con il punto di incrocio intorno ai 1.000 token di output. Imposta la qualità in modo consapevole, abbina il modello a essa e controlla il costo. Quando passi dalla generazione all’editing, con un’immagine di riferimento in input, rifai i conti: l’immagine di input diventa il costo.
FAQ
Il prompt caching riduce il costo della generazione di immagini?
No. La generazione è stateless: l’oggetto usage non ha campi di cache, e il batching rifattura il prompt per ogni immagine. Il costo è l’immagine in output, non il testo.
Costa meno il per-token o il per-image?
Dipende dalla qualità. Per qualità bassa o draft conviene un modello con la leva quality come gpt-image (circa $0.006–0.012). Per media o alta conviene il forfait per immagine, come seedream/qwen ($0.03–0.035), perché la fattura per-token si impenna. Per l’image-to-image la bilancia pende ancora di più verso il forfait: le immagini di riferimento sono incluse gratis, mentre il per-token aggiunge circa 1.025 token a testa.
Fonti
- OpenAI: Image generation API
- OpenAI: gpt-image per-token pricing
- Google: Gemini API pricing (image output tokens)
- OpenAI: Prompt caching (why it does not apply to image generation)
Tutto verificato il 2026-06-19. Non è una consulenza finanziaria; verifica i prezzi attuali prima di farci affidamento.