Il costo per token è l'etichetta, non il prezzo
Quando un team inizia a guardare i costi LLM, la prima reazione è spesso confrontare il pricing per token dei provider. Modello A costa 3 dollari per milione di input, modello B ne costa 2.50, la scelta sembra ovvia.
In produzione, quel confronto racconta raramente la storia completa. Il costo reale di un sistema AI dipende da variabili che il pricing non mostra:
- Quanti token servono davvero per risolvere ogni task
- Quante volte il sistema deve riprovare perché la prima risposta non era abbastanza buona
- Quanto contesto stai pagando per ogni chiamata anche se cambia solo una parte
- Quante chiamate fai in totale — e quante potresti non fare affatto
Un modello più costoso per token può risultare più economico per task completato se risolve in un colpo solo ciò che uno più economico richiede due o tre tentativi. Viceversa, un modello cheap usato male può costare più di uno premium usato bene.
La prima leva: prompt caching
Il prompt caching è probabilmente la leva di costo più sottoutilizzata dai team. La logica è semplice: se stai inviando lo stesso contesto di sistema (istruzioni, policy, documentazione prodotto) a ogni chiamata, i provider moderni ti permettono di metterlo in cache e pagare una frazione del costo sui token riutilizzati.
Il risparmio tipico è nell'ordine dell'80-90% sulla porzione cached. Ma richiede disciplina architettonica:
- Separare chiaramente la parte stabile (cacheable) da quella dinamica (non cacheable)
- Mettere la parte stabile sempre all'inizio del prompt
- Evitare micro-variazioni nella parte stabile (un timestamp in mezzo, un campo utente, e la cache viene invalidata)
Se il tuo sistema attuale concatena in modo casuale contesto statico e dinamico, non stai sfruttando il caching — anche se lo hai attivato.
La seconda leva: batching dove possibile
Molti workload AI non hanno bisogno di risposte in tempo reale. Classificazione di dati, generazione di riassunti, estrazione di entità da documenti — sono tutti task che possono aspettare minuti invece di secondi.
Per questi casi, le API di batch (disponibili ormai su tutti i provider principali) offrono sconti del 50% sul pricing standard. Il vincolo è la latenza: le chiamate vengono elaborate in modalità asincrona, tipicamente entro poche ore.
La domanda operativa da porsi: quali dei miei workload AI hanno davvero bisogno della latenza real-time? Spesso la risposta è meno di quanto il team pensi. Un'analisi notturna di tutti i ticket di supporto aperti, per esempio, non ha bisogno di risposte in due secondi.
La terza leva: model routing intelligente
L'architettura multi-modello è diventata lo standard per i sistemi AI maturi. L'idea è semplice: usare il modello più potente solo dove serve, ripiegando su modelli più economici per il resto.
Un pattern tipico in un chatbot:
- Prima linea: Haiku / mini / Flash — decidono se la query è semplice e rispondono direttamente
- Seconda linea: Sonnet / standard — gestiscono la maggior parte delle query che richiedono ragionamento
- Terza linea: Opus / Pro — solo per query che le prime due hanno classificato come complesse
La matematica tipica: se l'80% delle query può essere gestito dalla prima linea, il 15% dalla seconda, e solo il 5% richiede la terza, il costo medio per query crolla rispetto a uno scenario "tutto sul flagship".
Il punto critico è il routing. Se il classificatore che decide a quale livello inviare la query sbaglia spesso, perdi tutti i guadagni in riprocessing. Un routing sbagliato sul 20% delle query può cancellare i risparmi del pattern.
La quarta leva: ridurre l'output, non solo l'input
Molti team ottimizzano il prompt di ingresso e trascurano il costo dell'output. In realtà, l'output costa tipicamente 4-5 volte più dell'input per token. Contenere le risposte è spesso la leva più efficiente.
Tre tecniche pratiche:
Structured output invece di prosa libera. Un JSON con i campi che servono è quasi sempre più corto di una risposta narrativa, e spesso più utile a valle.
Max tokens disciplinato. Se sai che una risposta utile sta in 200 token, non lasciare max_tokens=2048 per default. Il modello riempirà lo spazio che gli lasci.
Reasoning budget limitato. Per i modelli con extended thinking, il budget di ragionamento è una variabile di costo diretta. Impostarlo a low per task semplici e high solo quando serve può dimezzare il costo su workload misti.
La quinta leva: smettere di chiamare l'LLM quando non serve
Il modo più efficace di ridurre i costi LLM è non fare la chiamata. Suona banale, ma molti sistemi chiamano il modello per task che potrebbero essere risolti con codice deterministico.
Casi tipici:
- Classificazione di input strutturati: se l'utente ha selezionato "supporto tecnico" in un menu, non serve un LLM per capirlo
- Parsing di formati noti: email, date, numeri di telefono — ci sono librerie che lo fanno meglio e più velocemente
- Routing basato su keyword esatte: un
if "rimborso" in querycosta zero token - Risposte cached per query frequenti: le 50 FAQ più comuni possono essere risposte senza chiamare mai il modello
Un'architettura sana usa l'LLM dove aggiunge valore — nel ragionamento ambiguo, nella generazione di linguaggio naturale, nella gestione di casi nuovi — e usa codice tradizionale per tutto il resto.
Il costo nascosto: i retry silenziosi
Un pattern che sfugge a molti dashboard è il costo dei retry. Quando il modello produce output mal formato, il sistema riprova. Quando una chiamata va in timeout, riparte. Quando un parser fallisce sul JSON ritornato, il team spesso aggiunge un retry con prompt "correggi il formato".
Ogni retry è una chiamata piena al modello. Tre retry su ogni query che fallisce il parsing può raddoppiare o triplicare il costo medio.
La soluzione non è evitare i retry — a volte sono necessari. È tracciarli. Un dashboard di cost monitoring dovrebbe mostrare:
- Costo per chiamata "di successo al primo tentativo"
- Costo per chiamata "con retry"
- Percentuale di query che richiedono retry
Se la percentuale di retry è alta, il problema di solito non è il costo — è il design del prompt o del parser. Fixare quello riduce i costi come effetto collaterale.
Il framework di decisione per ottimizzazione
Quando i costi LLM salgono, la tentazione è fare micro-ottimizzazioni sul pricing. Spesso il guadagno maggiore sta altrove. Un ordine di priorità che funziona nella pratica:
- Stai pagando chiamate che non dovresti fare? (routing, dedup, rule-based fallback)
- Stai pagando due volte lo stesso contesto? (prompt caching, struttura dei prompt)
- Stai pagando output più lunghi del necessario? (max_tokens, structured output)
- Stai pagando il modello sbagliato per il task? (multi-model routing)
- Stai pagando retry che potresti evitare? (prompt quality, parser robusti)
- Stai pagando real-time dove potresti aspettare? (batch API)
Solo dopo aver coperto questi livelli ha senso confrontare i prezzi tra provider. La differenza tra 2.50 e 3 dollari per milione di token è marginale se stai sprecando il 40% delle chiamate per design.
La metrica che conta
Invece di $/token, il team dovrebbe monitorare $/task completato con successo. Il primo numero è un input. Il secondo è un outcome.
Un sistema che costa il 30% in più per token ma completa i task al primo tentativo — e quindi non richiede retry, escalation umane, o seconda interazione con l'utente — è spesso più economico end-to-end. Il vero costo di un sistema AI non è il prezzo dei token. È il prezzo dei task che risolve davvero.