Quanto costano le API degli LLM: come calcolarlo davvero

Chi integra un LLM in un prodotto scopre in genere due cose nell'ordine sbagliato: prima che funziona, poi quanto costa a regime. La differenza tra un prototipo e mille utenti al giorno è di ordini di grandezza, e il conto riserva sorprese che i listini non rendono evidenti. In questo articolo ti spiego come calcolare il costo reale prima di trovartelo in fattura.

I prezzi cambiano in continuazione e variano molto tra fornitori: qui trovi il metodo e i rapporti tra le voci, non un listino. Le cifre esatte vanno prese dalla pagina ufficiale del fornitore.

Come si paga

Si paga a token, contati sia in entrata che in uscita, con tariffe diverse per i due. Un token è un frammento di testo: per l'italiano, indicativamente 1.000 token corrispondono a 700-750 parole. Il concetto è spiegato in cos'è un token in un LLM.

Le tre cose da sapere sul meccanismo, prima ancora dei prezzi:

1. L'output costa più dell'input, tipicamente da 3 a 5 volte tanto. Chiedere risposte concise non è solo questione di leggibilità.

2. L'italiano costa più dell'inglese, circa il 15-25% in più a parità di contenuto, perché i tokenizzatori sono ottimizzati sull'inglese.

3. Le fasce di prezzo tra modelli sono enormi. Tra un modello piccolo e uno di punta ci sono spesso uno o due ordini di grandezza. È la leva più potente che hai.

Il costo nascosto delle conversazioni

Questo è il punto che manda fuori budget la maggior parte dei progetti, ed è ciò che i listini non dicono.

Il modello non ha memoria: a ogni messaggio, l'intera conversazione viene rispedita da capo. Al ventesimo turno stai pagando come input tutti i diciannove messaggi precedenti, di nuovo.

Il costo di una conversazione non cresce in modo lineare con i turni: cresce con il quadrato. Una chat di 30 messaggi costa molto più del triplo di una da 10.

Turni	Token input cumulativi (indicativi)
5	~7.500
10	~27.500
20	~105.000
30	~232.000

Il meccanismo è spiegato per esteso in context window e token. La conseguenza pratica: una funzione di chat senza limiti è una voce di costo aperta, e va progettata di conseguenza.

Come si stima prima di partire

Il calcolo da fare su un foglio, prima di scrivere il codice:

costo per richiesta = (token input × prezzo input)
                    + (token output × prezzo output)

costo mensile = costo per richiesta
              × richieste per utente al giorno
              × utenti attivi
              × 30

I due errori sistematici in questa stima:

Sottostimare l'input. Le istruzioni di sistema, gli esempi, il contesto recuperato da un sistema RAG e la cronologia si sommano. Un prompt che "sembra corto" può portarsi dietro migliaia di token fissi a ogni chiamata.

Dimenticare i tentativi. Riprovare dopo un errore, rigenerare una risposta insoddisfacente, le chiamate di un agente che ne fa molte per completare un compito: nella pratica il numero di chiamate effettive è spesso il doppio o il triplo di quelle "utili".

Le leve per ridurre il costo

In ordine di impatto, dalla più efficace:

1. Usa il modello più piccolo che funziona. È di gran lunga la leva più potente: si parla di ridurre il costo di dieci o venti volte, non del 20%. La maggior parte dei compiti — classificare, estrarre dati, riformulare, rispondere a domande semplici — non richiede il modello di punta. Prova dal basso e sali solo se serve, invece del contrario.

2. Instrada per difficoltà. Un modello piccolo gestisce il grosso del traffico, uno grande solo i casi complessi. Su volumi seri è la differenza tra un prodotto sostenibile e uno no. Vale a maggior ragione con i modelli di reasoning, che costano molto di più.

3. Sfrutta il caching del prompt. Se la parte iniziale del prompt è identica tra le chiamate — istruzioni di sistema, esempi, un documento di riferimento — molti fornitori la mettono in cache e la fatturano a una frazione. Perché funzioni, la parte fissa deve stare all'inizio e restare identica: basta un timestamp all'inizio del prompt per invalidare tutto.

4. Limita la cronologia. Non rimandare l'intera conversazione: tieni gli ultimi N messaggi, o riassumi il resto. Un riassunto di 200 token al posto di 5.000 di storico è una riduzione enorme.

5. Chiedi output brevi. Costa la voce più cara. Se ti serve una classificazione, chiedi una parola, non un paragrafo di spiegazione.

6. Elabora in batch quando puoi. Diversi fornitori offrono modalità asincrone a costo ridotto per lavori non interattivi.

7. Metti in cache le risposte identiche. Se molti utenti fanno la stessa domanda, la seconda volta non serve chiamare il modello.

Il quadro completo delle tecniche è in come spendere meno token con l'AI.

API o modello locale?

La domanda arriva sempre a un certo punto. Il confronto onesto:

	API	Locale
Costo iniziale	Zero	Hardware
Costo variabile	Per token	Corrente
Qualità massima	I modelli migliori	Inferiore a parità di spesa
Privacy	I dati passano dal fornitore	Totale
Manutenzione	Nessuna	Tua
Volumi altissimi	Cresce sempre	Costo fisso

Il punto di pareggio è più lontano di quanto si pensi. Considerando hardware, elettricità e tempo di gestione, servono volumi consistenti perché il locale convenga economicamente.

Le ragioni valide per il locale sono soprattutto altre: dati riservati che non possono uscire, requisiti normativi, indipendenza da un fornitore. Sull'aspetto pratico ho scritto far girare un LLM in locale.

Tre accorgimenti che evitano brutte sorprese

Metti un limite di spesa sul tuo account, dal primo giorno. È la protezione più semplice contro un bug che manda in loop una chiamata.

Registra il consumo di token per funzionalità, non solo il totale. Senza questo dato non sai quale parte del prodotto ti sta costando, e ottimizzi alla cieca.

Imposta un tetto sull'output (max token) a ogni chiamata. Evita che una risposta anomala generi migliaia di token, e ti protegge anche dai loop.

In sintesi

Le API degli LLM si pagano a token, con l'output che costa diverse volte l'input e l'italiano che consuma più dell'inglese. Il costo che sfugge nelle stime è quello delle conversazioni: crescono col quadrato dei turni, perché la cronologia viene rispedita ogni volta.

La leva di gran lunga più efficace non è ottimizzare i prompt: è usare un modello più piccolo dove basta, e instradare verso quello grande solo ciò che lo richiede davvero.

Poi vengono caching del prompt, cronologia limitata e output brevi.

E prima di tutto il resto: limite di spesa attivo e consumo tracciato per funzionalità. Sono cinque minuti di lavoro che evitano il tipo di sorpresa che si scopre solo a fine mese.