Sei centesimi. È quanto può costare una conversazione con un chatbot di supporto costruito su un modello di fascia media. Una cifra che in fase di prototipo non guarda nessuno — finché il prodotto funziona, il traffico cresce, e centomila conversazioni al mese diventano seimila dollari di fattura API. Il prototipo costava come un caffè; la produzione costa come uno stipendio.
Il problema non è che le API LLM siano care. È che il loro modello di prezzo — pagare per token, con tariffe diverse per input e output — è controintuitivo, e i costi veri emergono solo quando si ragiona per caso d’uso. Questa guida serve a fare esattamente quel ragionamento.
L’unità di misura: il token
Tutte le API LLM principali si pagano a token: i frammenti di testo in cui il modello scompone ciò che legge e ciò che scrive. In italiano un token corrisponde grosso modo a tre quarti di parola; una pagina di testo sono circa 500-700 token. Il contatore gira due volte: una per i token che entrano nel modello (il prompt, i documenti, la cronologia della conversazione) e una per quelli che escono (la risposta).
La prima cosa da notare sul listino è l’asimmetria: i token di output costano tipicamente cinque volte quelli di input. Ha una logica tecnica — generare testo richiede un passaggio completo del modello per ogni token prodotto, mentre l’input si elabora in parallelo — ma ha una conseguenza pratica precisa: un’applicazione che legge molto e scrive poco (classificazione, estrazione, ricerca) ha un profilo di costo radicalmente diverso da una che scrive molto (generazione di report, scrittura assistita).
I tre piani della tariffa
Quasi tutti i fornitori organizzano l’offerta su tre fasce, come le classi di un treno: un modello piccolo e veloce, uno intermedio, uno di punta. Prendiamo come riferimento il listino Anthropic a metà 2026, rappresentativo della struttura del mercato: Haiku 4.5 costa 1 $ per milione di token in input e 5 $ in output; Sonnet 4.6 sta a 3 $ e 15 $; Opus 4.8 a 5 $ e 25 $. Tra il piano economico e quello di punta c’è un fattore cinque, e i prezzi cambiano spesso — vale la data di stampa, non la cifra assoluta.
L’errore classico è scegliere il modello come si sceglie un’auto: il più potente che il budget consente. Ma qui la potenza si paga a ogni singola chiamata, per sempre. La domanda giusta è l’inversa: qual è il modello più piccolo che supera la soglia di qualità del mio compito? Per classificare ticket di supporto in cinque categorie, il modello di punta e quello economico danno spesso lo stesso risultato — a un quinto del prezzo. Il modello grande va riservato ai passaggi dove la differenza si vede davvero.
I moltiplicatori nascosti
Il listino racconta metà della storia. L’altra metà sta in come l’applicazione consuma token, e qui si annidano tre moltiplicatori che i preventivi ingenui ignorano.
Il primo è la conversazione multi-turno. Le API sono senza memoria: a ogni scambio bisogna rimandare l’intera cronologia. Al decimo messaggio di una chat, il modello sta rileggendo — e facendo pagare — anche i nove precedenti. Il costo di una conversazione non cresce linearmente con la sua lunghezza: cresce quasi col quadrato. È il motivo per cui il chatbot dei sei centesimi costa così: non per le risposte, ma per la cronologia riletta a ogni turno.
Il secondo è il contesto di contorno. Il prompt di sistema, le istruzioni, i documenti recuperati da un sistema RAG: tutto entra nel conteggio input a ogni chiamata. Un’applicazione RAG che allega cinque documenti da mille token a ogni domanda paga cinquemila token di «spedizione» prima ancora che l’utente abbia chiesto qualcosa.
Il terzo è il ragionamento esteso: i modelli recenti possono «pensare» prima di rispondere, e quei token di pensiero si pagano come output — la tariffa più cara — anche quando non compaiono nella risposta. Utile per i problemi difficili, uno spreco per quelli banali.
Il preventivo onesto non parte dal listino: parte dal caso d’uso. Quanti token entrano, quanti escono, quante volte al giorno — il resto è moltiplicazione.
Gli sconti che cambiano i conti
Due meccanismi, ormai standard di mercato, possono ridurre la fattura in modo drastico — a patto di progettare l’applicazione per sfruttarli.
Il prompt caching permette di «congelare» la parte stabile del prompt — istruzioni di sistema, documenti fissi, cronologia già vista — e ripagarla, alle chiamate successive, a circa un decimo del prezzo di input. È l’abbonamento ferroviario contro il biglietto singolo: la scrittura in cache costa un piccolo sovrapprezzo (sul listino Anthropic, il 25% in più sulla prima chiamata), ma già dal secondo passaggio si è in attivo. Per chatbot e agenti che rileggono la stessa cronologia decine di volte, la differenza sulla fattura può superare il 50%. Attenzione al dettaglio implementativo: la cache funziona per prefisso esatto, e basta un timestamp nel prompt di sistema per invalidarla a ogni chiamata senza che nessun errore lo segnali.
Il batch processing dimezza il prezzo — sconto tipico del 50% su tutti i token — in cambio della pazienza: le richieste vengono elaborate in modo asincrono, di solito entro un’ora, fino a un giorno. Per tutto ciò che non ha un utente in attesa dall’altra parte — classificare archivi, generare riassunti notturni, arricchire dataset — non usarlo significa pagare il doppio per una velocità che non serve a nessuno.
Il costo per caso d’uso, in pratica
Mettiamo insieme i pezzi con quattro scenari tipici, calcolati sul listino citato sopra (prezzi per 1.000 operazioni, senza sconti).
Una classificazione con il modello economico — 500 token di input, una manciata in output — costa circa 0,55 $ ogni mille documenti: a questi prezzi si etichettano archivi interi. Una query RAG con il modello intermedio — sui 6.000 token di contesto recuperato, 500 di risposta — sale a circa 26 $ per mille domande. Una conversazione di supporto di 6-8 turni, con la cronologia che si accumula, arriva intorno ai 60 $ per mille conversazioni. E un report long-form con il modello di punta — 20.000 token di materiale in ingresso, 5.000 di testo generato — costa circa 22 centesimi l’uno: 225 $ per mille report.
Stesso listino, quattro casi d’uso: tra classificare un documento e generare un report c’è un fattore quattrocento. Il costo di un’applicazione LLM lo decide l’architettura, non il fornitore. Larghezze in scala logaritmica.
La forbice è enorme, e la morale anche: due applicazioni sullo stesso identico modello possono avere costi per operazione distanti tre ordini di grandezza. Prima di negoziare col fornitore, conviene negoziare con la propria architettura — accorciare i prompt, tagliare le cronologie, spostare i compiti facili sul modello piccolo, mettere in cache ciò che si ripete, mandare in batch ciò che può aspettare.
Perché ti riguarda
Se stai costruendo qualcosa sopra un’API LLM, il momento di fare questi conti è prima di scrivere il codice, non quando arriva la prima fattura seria. Bastano tre numeri — token medi in ingresso, token medi in uscita, chiamate al giorno — e dieci minuti di foglio di calcolo per sapere se il tuo prodotto regge economicamente a diecimila utenti o solo a cento. E se i conti non tornano, quasi mai la soluzione è cambiare fornitore: è cambiare il modo in cui la tua applicazione spende token. Il listino è uguale per tutti; l’architettura no.
I commenti sono riservati agli iscritti.
Accedi per commentare