Prezzi multimodali: cosa fatturano davvero immagini, audio e video

Un transformer prende una sequenza di vettori. Non ha opinioni su da dove arrivino. Il Capitolo 8 gli dava in pasto embeddings cercati da un token id; niente nell’architettura richiede quella ricerca.

Quindi: taglia l’immagine in quadrati fissi, appiattisci ogni quadrato in una lista di numeri e passa ogni lista attraverso un singolo layer lineare appreso per ottenere un vettore della larghezza del modello. Una patch 32 × 32 di pixel a colori è composta da $32 \times 32 \times 3 = 3072$ numeri; la proiezione $E \in \mathbb{R}^{d \times 3072}$ la trasforma in un vettore $d$-dimensionale, esattamente la forma con cui arriva un token di testo. È tutto qui, ed è l’articolo il cui titolo lo dice: un’immagine vale 16 × 16 parole.¹ Aggiungi un positional encoding perché il modello sappia quale quadrato era dove, intreccia i risultati con gli embeddings del testo, e la sequenza letta dal modello è in parte immagine e in parte frase.

Tre articoli l’hanno trasformato in prodotto. CLIP ha addestrato un image encoder e un text encoder a concordare, su quattrocento milioni di coppie raccolte dal web, ed è lì che l’idea che pixel e parole possano condividere uno spazio ha smesso di essere un’ipotesi.² Flamingo ha innestato un vision encoder congelato su un language model congelato con pochi layer di collegamento addestrati.³ LLaVA ha mostrato che il ponte poteva essere una singola proiezione lineare e che l’instruction-following poteva essere insegnato con dati generati, ed è per questo che ogni modello vision-language open da allora ha più o meno la stessa forma.⁴

La conseguenza per la tua fattura è immediata e poco glamour: le patch sono posizioni nella sequenza, quindi sono token di input, quindi le paghi alla tariffa di input. Quanti siano è aritmetica, e ogni provider la fa diversamente.

Ogni regola qui sotto è implementata dalla documentazione del provider e verificata sugli esempi svolti nella stessa documentazione.

OpenAI copre l’immagine con patch 32 × 32 e moltiplica il conteggio per un fattore per modello. Se il conteggio delle patch supera il budget per quel modello e quel livello di dettaglio, l’immagine viene ridimensionata finché ci sta:

Anthropic la copre con patch 28 × 28, un visual token ciascuna, e limita sia il lato lungo sia il conteggio dei token — 1.568 pixel e 1.568 token sui modelli standard-tier, 2.576 e 4.784 sul tier ad alta risoluzione. Le immagini troppo grandi vengono ridimensionate alla dimensione massima che rispetta entrambi.⁵

Google non conta affatto i pixel. Un’immagine con entrambi i lati pari o inferiori a 384 pixel costa una quota fissa di 258 token. Qualsiasi cosa più grande viene tagliata in tile da 258 token ciascuna, e la griglia di tile deriva da un’unità di crop pari a $\lfloor \min(w,h) / 1.5 \rfloor$.⁶

export function openaiImageTokens(
  w: number, h: number,
  { maxDim, patchBudget, multiplier }: { maxDim: number; patchBudget: number; multiplier: number },
) {
  const fit = Math.min(1, maxDim / Math.max(w, h));      // never enlarges
  w = Math.floor(w * fit); h = Math.floor(h * fit);
  let patches = Math.ceil(w / 32) * Math.ceil(h / 32);   
  if (patches > patchBudget) {
    const s = Math.sqrt((32 * 32 * patchBudget) / (w * h));
    const adj = s * Math.min(
      Math.floor((w * s) / 32) / ((w * s) / 32),
      Math.floor((h * s) / 32) / ((h * s) / 32));
    patches = Math.ceil(Math.floor(w * adj) / 32) * Math.ceil(Math.floor(h * adj) / 32);
  }
  return Math.ceil(patches * multiplier);                
}

export function anthropicVisualTokens(
  w: number, h: number,
  { maxLongEdge, maxTokens }: { maxLongEdge: number; maxTokens: number },
) {
  const tok = (a: number, b: number) => Math.ceil(a / 28) * Math.ceil(b / 28);
  const long = Math.max(w, h), short = Math.min(w, h);
  for (let L = Math.min(long, maxLongEdge); L >= 1; L--) {     
    const t = tok(L, Math.round((short * L) / long));
    if (t <= maxTokens) return t;                              
  }
  return 0;
}

export function geminiImageTokens(w: number, h: number) {
  if (w <= 384 && h <= 384) return 258;
  const crop = Math.floor(Math.min(w, h) / 1.5);               
  return Math.ceil(w / crop) * Math.ceil(h / crop) * 258;      
}

Esegui ciascuna contro i numeri stampati dal suo vendor:

OpenAI, gpt-5.4 at detail:high (2048 px, 2,500 patches, 1.2x)
  1024x1024 -> 1024 patches -> 1229 tokens   doc says 1229   MATCH
  2048x2048 -> 2500 patches -> 3000 tokens   doc says 3000   MATCH

Anthropic, the published table (one tier per row shown)
  200x200    std   64 @ 200x200     doc   64, not resized    OK
  1000x1000  std 1296 @ 1000x1000   doc 1296, not resized    OK
  1092x1092  std 1521 @ 1092x1092   doc 1521, not resized    OK
  1920x1080  std 1560 @ 1456x819    doc 1560, 1456x819       OK
  2000x1500  std 1564 @ 1269x952    doc 1564, 1269x952       OK
  3840x2160  hi  4784 @ 2576x1449   doc 4784, 2576x1449      OK

Google, the worked example
  960x540 -> crop 360 -> 3 x 2 = 6 tiles     doc says 6      MATCH

Vengono stampate nove corrispondenze; l’esecuzione completa ne verifica quindici, perché la tabella di Anthropic dà entrambi i tier per tutte e sei le dimensioni. Le regole ora sono tue da eseguire su qualsiasi fotografia tu abbia: queste sono le uniche tre funzioni di questo capitolo che non puoi ottenere da una pagina prezzi.

Passa la stessa fotografia 4:3 attraverso tutte e tre a sei dimensioni:

Leggi l’ultima colonna dall’alto verso il basso. Una volta che l’immagine supera 384 pixel, il numero non cambia mai più, e non è una coincidenza né un tetto. Rimetti l’unità di crop dentro la formula dei tile, per un’immagine larga almeno quanto è alta:

La dimensione si cancella. Gli image tokens di Google dipendono dall’aspect ratio e da nient’altro. Una fotografia 4:3 è quattro tile, che sia una miniatura o un poster. Quel singolo fatto algebrico è l’intera spiegazione dello zero nella tabella dei risparmi sopra, e nessuna pagina prezzi lo dice.

Le altre due colonne invece hanno un cap, ad altezze diverse e per ragioni diverse — Anthropic su un tetto dichiarato di token, OpenAI su un budget di patch dopo un limite di pixel — ed è per questo che le tre curve si incrociano a dimensioni diverse.

Ora rompiamolo. Il modo ovvio per spendere meno con un vision model è chiedere meno dettaglio, quindi invia detail: "low":

1600x1200   low = 2280   high = 2280   ratio 1.00
3200x2400   low = 3687   high = 2942   ratio 1.25

Chiedere meno dettaglio è costato il 25 % in più. Non è un bug e OpenAI lo dice in una riga della tabella di sizing: su quella famiglia di modelli, low usa un limite di 2048 pixel con un budget di 6.144 patch, mentre high usa lo stesso limite di pixel con un budget di 2.500 patch, «so it can use more tokens than high».⁷ La parola low indica un’impostazione di fedeltà, non un prezzo: su due delle cinque famiglie di modelli documentate non compra alcun risparmio, e su una di quelle due costa di più.

Fin qui abbiamo parlato di un modello che legge un’immagine. Produrla usa un meccanismo senza alcun token, ed è per questo che viene venduta a immagine invece che a parola.

I vendor pubblicano la generazione di immagini come prezzo per immagine. Non lo è. I modelli GPT Image emettono image tokens specializzati il cui conteggio dipende da dimensione e qualità richieste; moltiplica i conteggi pubblicati per la tariffa di output immagine pubblicata di GPT Image 1, $40 per milione, e confronta con i prezzi per immagine sulla stessa pagina:

Nove valori derivati contro nove valori pubblicati, ogni coppia concorde entro $0.002.¹¹ Google è ancora più esplicita e fa la conversione per te nella pagina prezzi: output immagine a $60 per milione di token, «output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image».¹²

Quindi un prezzo per immagine è un prezzo per token con il conteggio incorporato. Va bene, e nasconde qualcosa. Prendi la tabella della generazione attuale e dividi al contrario:

quality   1024x1024            1024x1536
low       $0.006 -> 200 tok    $0.005 -> 167 tok
medium    $0.053 -> 1767 tok   $0.041 -> 1367 tok
high      $0.211 -> 7033 tok   $0.165 -> 5500 tok

L’immagine più grande è quella più economica a ogni qualità. Una canvas 1024 × 1536 ha il 50 % di pixel in più rispetto a una 1024 × 1024 e costa il 23 % di token in meno a medium. OpenAI lo segnala in una frase che salteresti — «a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting» — e sulla generazione precedente del modello funzionava al contrario, con il ritratto che costava il 50 % in più del quadrato.¹¹ Ogni default di 1024x1024 scritto prima di quel cambiamento ora è l’opzione costosa.

Chiedi a tre prodotti di pronunciare gli stessi 519 caratteri — circa 38 secondi di audio — e ottieni tre sistemi di unità da due vendor:

Lo stesso vendor vende entrambe le unità: tts-1 di OpenAI è prezzato per milione di caratteri, mentre gpt-4o-mini-tts è prezzato per milione di token, $0.60 in ingresso e $12.00 in uscita.¹³ Quindi «il text-to-speech più economico» non è una domanda con una risposta finché non dici che cosa stai facendo pronunciare.

E le due unità sono cieche a cose opposte. Un prezzo per carattere non vede la durata: scegli una voce lenta e deliberata, o aggiungi pause, e la fattura non si muove mentre l’audio si allunga. Un prezzo per secondo non vede il contenuto: trenta secondi costano uguale, che siano un paragrafo tecnico denso o qualcuno che conta fino a dieci. Cambia la voce e soltanto uno dei tuoi due vendor ricalcola il prezzo.

La trascrizione va nella direzione opposta ed è la riga più semplice dell’intera fattura — per minuto di audio, piatta:

whisper                  $0.005960     ($0.006 / min)
gpt-transcribe           $0.004470     ($0.0045 / min)
gpt-4o-mini-transcribe   $0.002980     ($0.003 / min)
gpt-live-transcribe      $0.016887     ($0.017 / min)

Nota l’ultima riga rispetto alla terza: farlo live, mentre le parole arrivano, costa 5,7 volte farlo su un file già finito. Quel divario è il prezzo di non poter fare batch, ed è ciò che rende costosa la sezione successiva.

Ora il numero che decide se la voce è una feature o un prodotto.

La chiamata: una conversazione di supporto da dieci turni, 149 parole, che a 150 parole al minuto dichiarate fa 59,6 secondi di parlato — 21,2 pronunciati dal chiamante, 38,4 restituiti. Le conversioni in token sono dei provider stessi. OpenAI: «audio tokens in user messages are 1 token per 100 ms of audio, while audio tokens in assistant messages are 1 token per 50 ms».¹⁴ Google: 25 token al secondo, in entrambe le direzioni, cosa che la sua pagina prezzi conferma pubblicando $12.00 per milione e $0.018 al minuto sulla stessa riga.¹²

La conversazione si accumula esattamente come diceva il Capitolo 16, perché il meccanismo è lo stesso: «the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive».¹⁴ Solo che ora la cronologia è misurata in audio tokens.

Ora il confronto che decide il prodotto, tutti e quattro normalizzati a un minuto:

Trentotto volte. Non trentotto per cento. Lo scambio identico, condotto in suono invece che in testo, è quasi due ordini di grandezza più caro, e nessuna parte di quel divario è un margine che qualcuno ha scelto di applicare: è il tasso di conversione. Un secondo di audio dell’assistant è venti token. Quello stesso secondo porta 2,5 parole al tasso dichiarato, e la trascrizione misurata è a 1,26 token per parola, quindi come testo sono 3,15 token. Il suono è un pacchetto 6,3 volte più voluminoso per lo stesso significato, e ciascuno dei suoi token viene fatturato a 5,3 volte la tariffa di output testuale e 16 volte la tariffa di input testuale. Moltiplica un rapporto di volume per un rapporto di prezzo e l’ordine di grandezza è già lì prima che inizi qualsiasi contabilità.

Dalla tabella derivano direttamente due conseguenze operative.

L’audio caching non è un’ottimizzazione, è il business model. L’input audio cached è $0.40 per milione contro $32.00 fresco — uno sconto del 98,75 % che dimezza la chiamata. La regola è quella del Capitolo 16, invariata: la cache corrisponde a un prefisso, quindi qualsiasi cosa inserita all’inizio della conversazione a metà chiamata la distrugge, e il posto naturale in cui mettere «il chiamante ora è verificato» è proprio lì.

E niente di ciò che fai nel client annulla la fatturazione di un suono. L’utente parla sopra l’assistant, il tuo codice ferma la riproduzione, lo speaker tace. Qualunque cosa fosse già stata generata era già stata addebitata, perché la fatturazione matura quando la risposta viene creata; e secondo la regola del Capitolo 16 tutto ciò che resta nella conversazione viene reinviato, come audio input, a ogni turno successivo. Il Capitolo 14 lo diceva sull’interruzione di uno stream testuale. Nella voce costa trenta volte di più.

Il video è venduto al secondo da alcuni vendor e a clip da altri, con tier per risoluzione e talvolta per durata. Queste due forme non differiscono solo per comodità; si incrociano.

Il vendor a clip è più caro di quello al secondo sotto 1,2 secondi e 16,7 volte più economico a venti. Nessun ordinamento di quei due modelli sopravvive a un cambiamento nella lunghezza della clip, quindi «quale video model è più economico» non è una domanda sui modelli.

L’ultima riga è peggiore, ed è il cuore onesto del capitolo. mochi viene fatturato sui secondi GPU reali — il tempo di predizione misurato del job — a $0.001400 al secondo su A100 e $0.001525 su H100, che sono le tariffe della macchina noleggiata e nient’altro.¹⁵ È una tariffa perfettamente precisa e non è un prezzo, perché la quantità che moltiplica è ignota fino a dopo che ti sei impegnato a pagarla. La riga sopra assume dodici GPU-seconds per secondo di output; quadruplica quell’assunzione ed esce dalla fascia più economica, e solo a sei volte finisce a metà tabella. È l’unica tariffa in questa pagina che non puoi mettere in un preventivo.

Quindi: token, image tokens, caratteri, minuti, secondi video, clip intere, GPU seconds, unità piatte. Otto quantità, e l’unico modo per metterle su un solo asse è dichiarare un workload e prezzarlo.

Questa è l’estensione di computeCost del Capitolo 16 — lo stesso meccanismo di tier, ora con criteri che non sono la lunghezza del prompt:

export interface MediaCriteria {
  resolution?: string[]; quality?: string[];
  hasAudio?: boolean; maxDurationSeconds?: number;
}
export interface MediaTier { when?: MediaCriteria; price: number }
export type MediaRate = number | MediaTier[];

const matches = (when: MediaCriteria, u: Usage) => {
  const inList = (l?: string[], v?: string) => !l || (v !== undefined && l.includes(v));
  if (!inList(when.resolution, u.resolution)) return false;
  if (!inList(when.quality, u.quality)) return false;
  if (when.hasAudio !== undefined && when.hasAudio !== (u.hasAudio ?? false)) return false;
  if (when.maxDurationSeconds !== undefined
      && (u.videoSeconds ?? 0) > when.maxDurationSeconds) return false;   
  return true;
};

const mediaPrice = (rate: MediaRate | undefined, u: Usage): number => {
  if (rate === undefined) return 0;
  if (typeof rate === "number") return rate;
  for (const t of rate.filter((t) => t.when)) if (matches(t.when!, u)) return t.price;
  return rate.find((t) => !t.when)?.price ?? 0;      // the tier with no criteria is the default
};

export function computeCost(p: Pricing, u: Usage): number {
  let c = textCost(p, u);                             // Chapter 16, unchanged
  if (p.imageInputToken || p.imageOutputToken) {
    c += (u.imageInputTokens ?? 0) * (p.imageInputToken ?? 0)
       + (u.imageOutputTokens ?? 0) * (p.imageOutputToken ?? 0);
  } else if (p.imageUnit !== undefined) c += (u.images ?? 1) * mediaPrice(p.imageUnit, u);  
  if (p.videoSecond !== undefined) c += (u.videoSeconds ?? 0) * mediaPrice(p.videoSecond, u);
  if (p.videoUnit   !== undefined) c += (u.videoCount ?? 1)   * mediaPrice(p.videoUnit, u);
  c += (u.audioInputTokens ?? 0)       * (p.audioInputToken ?? 0)
     + (u.cachedAudioInputTokens ?? 0) * (p.cachedAudioInputToken ?? p.audioInputToken ?? 0)
     + (u.audioOutputTokens ?? 0)      * (p.audioOutputToken ?? 0)
     + (u.computeSeconds ?? 0)         * (p.computeSecond ?? 0)
     + (u.chars ?? 0)                  * (p.perChar ?? 0)
     + (u.minutes ?? 0)                * (p.perMinute ?? 0);
  return c;
}

Le due righe marcate sono dove si rompe. Una tariffa quotata per unità moltiplica u.images ?? 1; una tariffa quotata per token moltiplica qualcosa che di default è zero. Dai in pasto a entrambe un usage vuoto — la forma che ottieni quando una misurazione fallisce — e guarda:

per image (nano-banana-pro)     empty usage => $0.1500
per clip  (hailuo-02)           empty usage => $0.1500
per unit  (a cloned voice)      empty usage => $3.0000
per token (gpt-image-2)         empty usage => $0.0000
per second (veo-3.1)            empty usage => $0.0000
per GPU-second (mochi)          empty usage => $0.0000

Non è successo nulla, sei volte, ed è costato tre dollari una volta e nulla cinque volte. Non è una differenza di arrotondamento; è una decisione su cosa significhi un numero assente, presa separatamente per ogni unità e mai scritta. La regola sensata è che un campo che nessuno ha misurato resta assente, perché «non misurato» e «misurato ed è venuto zero» sono cose diverse. Questa funzione è silenziosamente in disaccordo.

Il secondo fallimento è la durata. La tariffa a clip seleziona il suo tier con maxDurationSeconds rispetto a u.videoSeconds ?? 0, quindi un usage che non ha mai registrato una durata corrisponde al tier più breve:

duration recorded    ->  $0.45
duration missing     ->  $0.27

Quaranta per cento di sconto per non sapere quanto durava il video. Entrambi i bug hanno la stessa radice: un default scelto per comodità dentro una funzione il cui intero compito è essere esatta.

Una volta che i costi sono computabili, al confronto serve l’altra metà: un workload rappresentativo dichiarato, uno per engine, esposto pubblicamente così chi legge può contestarlo:

export const representative = {
  text:   { blend: [[{ promptTokens: 1e6 }, 0.25], [{ completionTokens: 1e6 }, 0.75]] },
  image:  { images: 1, imageInputTokens: 50, imageOutputTokens: 1500 },
  video:  { videoSeconds: 5, videoCount: 1, resolution: "1080p", hasAudio: true, computeSeconds: 60 },
  voice:  { chars: 1000, computeSeconds: 10 },
  stt:    { minutes: 1 },
};

Ognuna di quelle righe è un argomento. Il testo mescola un quarto di input e tre quarti di output perché l’uso reale tende verso l’output; una miscela cinquanta-cinquanta classifica i modelli diversamente. Il workload immagine assume 1.500 output token, tra i 1.056 di OpenAI per un quadrato medium e i suoi 1.584 per un ritratto medium. Il video assume cinque secondi a 1080p, e abbiamo appena visto due vendor scambiarsi di posto a 1,2 secondi. La voce compute assume sessanta GPU-seconds perché non c’è altro da assumere.

Questo è il metodo, ed è l’unico onesto disponibile: non puoi confrontare prezzi in unità diverse; puoi solo confrontare il costo di un workload che hai scritto. Qualsiasi tabella che classifica modelli multimodali senza stampare il proprio workload sta classificando le proprie assunzioni.

Ora puoi prezzare qualsiasi cosa un modello possa produrre, in qualunque unità sia venduta, e dire ad alta voce quale workload assume il tuo confronto. Questo chiude la fattura aperta dal Capitolo 16, e chiude la Parte III: tutto, dal Capitolo 14 a qui, è stato su una call — come farla, cosa metterci dentro, come campionarla, cosa restituisce, quanto costa.

Il Capitolo 22 cambia l’unità di analisi, e il cambiamento è costoso. Un agent non è una call; è un loop che decide da solo quante call fare, e l’aritmetica degli ultimi due capitoli è ciò che lo trasforma da diagramma architetturale a budget. Si apre ponendo allo stesso modello la stessa domanda due volte, con un tool aggiunto al catalogo la seconda volta, e misurando cosa ha fatto quell’unico tool: una call è diventata due, trentanove token di input sono diventati 420.

Se questo lo rende un agent dipende da quale delle due definizioni pubblicate apri, e non sono d’accordo. Una delle due non è d’accordo con sé stessa.

Ogni prezzo, formula e tasso di conversione in questo capitolo è stato letto dalla pagina del provider il 7 settembre 2026 ed è citato con quella data, perché si muoveranno tutti. I conteggi di token, i costi e i confronti sono stati calcolati su quei dati dal codice stampato sopra, su una macchina, senza effettuare alcuna chiamata API a pagamento — ed è anche la ragione onesta per cui in questo capitolo non c’è una sola affermazione sulla latenza.

Le funzioni per gli image-token, le tabelle dei costi, la scomposizione della voice call e i risultati con usage vuoto sono stati prodotti dal TypeScript stampato in questo capitolo, eseguito su Node 22. Il dialogo usato per il confronto vocale è di 149 parole ed è stato tokenizzato con tiktoken sotto l’encoding o200k_base a 188 token; la sua durata deriva da un tasso dichiarato di 150 parole al minuto, che è un parametro del confronto e non una misurazione. Ogni cifra del provider porta la footnote che nomina la pagina da cui proviene.