Il costo dei token è una riga su sette nel costo totale di possesso di una funzionalità LLM. Un conto completo include token di input e output, ritentativi, retrieval ed embedding, uno strato di valutazione, il monitoraggio, la supervisione umana e l’infrastruttura. Il prezzo pubblicato dell’API spiega di solito meno della metà di ciò che la funzionalità costa davvero in produzione, ed è per questo che i margini lordi SaaS tradizionali dell’80-90% si comprimono al 50-60% quando le chiamate al modello entrano nel prodotto. La domanda giusta non è quanto costa un milione di token, ma quanto costa un’unità di lavoro che un cliente è disposto a pagare.
Le sette righe di costo di una funzionalità basata su un modello
La maggior parte dei team calcola il prezzo di una funzionalità IA direttamente dal listino del fornitore: tot dollari per milione di token di input, tot per l’output. Quella è una riga. La produzione ne fa emergere altre sei, e diverse sono fisse anziché legate al volume, il che le rende particolarmente pesanti all’inizio.
| Riga di costo | Che cosa copre | Comportamento |
|---|---|---|
| Token di input e output | Il prompt, il contesto recuperato e la risposta del modello | Variabile, lineare con il volume |
| Ritentativi e fallimenti | Timeout, limiti di frequenza, output respinto dalla validazione e rinviato | Variabile, con picchi sotto carico |
| Retrieval ed embedding | Generazione degli embedding, archiviazione vettoriale, query di ricerca, reindicizzazione | Misto: indicizzazione fissa, interrogazione variabile |
| Strato di valutazione | Set di test, esecuzioni di eval prima di ogni cambio di prompt o di modello | Fisso per ciclo di sviluppo |
| Monitoraggio e logging | Cattura di input e output, metriche di qualità, alert, retention | Fisso con una componente di volume |
| Supervisione umana | Revisione a campione, gestione delle escalation, etichettatura dei casi limite | Variabile in ore-persona |
| Infrastruttura e integrazione | Strato di astrazione sui fornitori, code, cache, sicurezza e permessi | Fisso, si diluisce man mano che crescete |
Perché il prezzo pubblicato dei token inganna
Tre scarti sistematici separano il listino dalla fattura.
L’output costa molto più dell’input. Presso la maggior parte dei fornitori un token di output è tariffato da cinque a otto volte un token di input. Una funzionalità che genera risposte lunghe paga quella lunghezza due volte, il che rende il tetto alla lunghezza dell’output il risparmio più economico disponibile in qualsiasi momento.
Il contesto cresce in silenzio. Nel momento in cui entra in gioco il retrieval, ogni chiamata trasporta frammenti di documenti, cronologia della conversazione e istruzioni di sistema. Un prompt che nel codice occupa tre righe sono diverse migliaia di token in volo, e quella differenza si moltiplica su ogni chiamata.
I ritentativi non compaiono mai nel piano. Una chiamata che fallisce la validazione, la formattazione o va in timeout viene rinviata e fatturata due volte. Sotto carico reale il tasso di ritentativi è di solito la differenza tra la previsione e la fattura.
La formula: il costo per unità di lavoro
Invece di seguire il consumo totale di token, definite un’unità di lavoro con significato di business: un ticket risolto, un documento riassunto, un lead arricchito, una riga classificata. L’aritmetica diventa allora questa.
| Componente | Come calcolarla | Nota |
|---|---|---|
| Costo medio di una chiamata | (token di input × prezzo input) + (token di output × prezzo output) | Misuratelo, non stimatelo |
| Chiamate per unità | Comprese le fasi di retrieval, routing, classificazione e verifica | Un agente tipico fa 3-8 chiamate per unità |
| Moltiplicatore di ritentativo | 1 diviso il tasso di successo al primo tentativo | L’85% di successo equivale a un moltiplicatore di 1,18 |
| Costo della supervisione umana | Tasso di escalation × costo orario pieno × tempo di gestione | Di solito la riga più pesante |
| Ripartizione dei costi fissi | Costo fisso totale diviso per le unità mensili | Scende al crescere del volume |
I benchmark pubblicati fino al 2026 nel servizio clienti collocano un ticket risolto dall’IA tra mezzo dollaro e due dollari a livello di unità, contro sei-dodici dollari per un contatto gestito da una persona. Il divario sembra decisivo, ma si restringe parecchio una volta reinseriti supervisione, valutazione e infrastruttura, e alcune cifre pubblicate collocano il costo pienamente caricato di una risoluzione automatizzata più vicino ai cinque dollari. La distanza tra queste due letture è esattamente la distanza tra costo dei token e costo di possesso.
Le tre leve che spostano davvero la fattura
Prima di cambiare architettura, ci sono tre sconti che i fornitori già offrono e che la maggior parte dei team non sfrutta appieno.
| Leva | Ordine di grandezza | Quando conviene |
|---|---|---|
| Caching dei prompt | Letture da cache tariffate attorno a un decimo del prezzo di input standard | Istruzioni di sistema stabili, documenti di base ricorrenti |
| Elaborazione in batch | Circa metà prezzo | Tutto ciò che non richiede una risposta in tempo reale |
| Scelta del modello per compito | Decine di volte di differenza tra le fasce di modelli | Classificazione, estrazione e routing non hanno bisogno di un modello frontier |
Che cosa comporta per il conto economico
Il software tradizionale vive all’80-90% di margine lordo perché il costo di servire un utente in più tende a zero. Una funzionalità basata su un modello rompe questo presupposto: ogni utilizzo porta con sé un costo di calcolo reale. Le pubblicazioni fino al 2026 collocano il margine lordo di queste funzionalità nella fascia 50-60%.
L’implicazione pratica non è che la funzionalità non valga, ma che il modello di prezzo debba muoversi con essa. Un prezzo per postazione, insensibile all’utilizzo, trasforma gli utenti intensivi in un deficit silenzioso: quando il cinque per cento degli utenti genera gran parte del costo di calcolo, un prezzo piatto si limita a sussidiarli. Ne parliamo separatamente nell’articolo sul prezzo di un prodotto basato su un modello, e il legame tra costo unitario e redditività complessiva nel modello unitario di un business digitale.
Come misurarlo nella pratica
- Marcate ogni chiamata API con l’identificativo dell’unità di lavoro che serve, non solo con un ID utente. Senza quello non potrete ricostruire il costo per unità a posteriori.
- Memorizzate separatamente token di input, token di output e numero di tentativi. Un totale di costo unico nasconde tutto ciò che si potrebbe correggere.
- Trattate il tasso di successo al primo tentativo come una metrica di prodotto, non di infrastruttura. Moltiplica direttamente il costo.
- Ripartite i costi fissi sulle unità ogni mese, altrimenti una funzionalità in crescita sembrerà peggiore di quanto sia.
- Fissate un tetto di costo per unità come criterio di rilascio, con lo stesso peso di un criterio di qualità. Una funzionalità che sfonda il tetto non va in produzione.
Quest’ultimo punto si collega a una questione più ampia: come si definiscono condizioni di accettazione per un sistema il cui output è probabilistico. Lo spieghiamo nell’articolo sui criteri di accettazione di una funzionalità IA, e il versante commerciale più ampio rientra nelle nostre aree di competenza.
Domande frequenti
Che quota del costo totale di possesso rappresenta la fattura dell’API?
Non esiste un numero unico, ma nei deployment con supervisione umana, uno strato di valutazione e monitoraggio, la riga API è di solito minoritaria nel costo totale. Più il prodotto è automatizzato e meno supervisionato, maggiore diventa la sua quota. Per questo le sette righe vanno calcolate e non dedotte da un listino.
Come si stima il costo prima che esista la produzione?
Fate passare un campione rappresentativo di alcune centinaia di unità di lavoro reali attraverso l’intera pipeline e misurate token, chiamate e ritentativi come effettivamente avvengono. Stimare dal solo prompt porta quasi sempre a sottovalutare, perché ignora il contesto recuperato e i fallimenti.
Un modello più piccolo è sempre più economico?
No. Un modello economico che fallisce più spesso produce ritentativi, output più lunghi ed escalation verso persone, che costano tutti più del divario di prezzo dei token. Il confronto corretto è il costo per unità di lavoro completata con successo, non il prezzo per milione di token.
Quando conviene passare a un modello self-hosted?
Quando il carico è ristretto, ripetitivo e ad alto volume, e quando il costo o la latenza dell’API è diventato il vincolo determinante. A basso volume o su un compito ampio, il costo di ingegneria e manutenzione di un modello gestito in proprio supera di solito il risparmio.
Se si segue una sola metrica, quale dovrebbe essere?
Il costo per unità di lavoro completata con successo, rivisto ogni mese. Assorbe il prezzo dei token, il tasso di fallimento, le escalation e l’efficienza del retrieval, ed è l’unica cifra direttamente confrontabile con il vostro prezzo e con il costo dell’alternativa umana.