Calcolare e prevedere i costi delle API

I costi delle API per le applicazioni basate su LLM possono diventare sorprendentemente elevati su larga scala. Una singola query che sembra economica, con un costo di 0,002 $, arriva a 200 $ se viene eseguita 100.000 volte. Senza previsione e monitoraggio dei costi, le funzionalità di AI possono generare fatture cloud impreviste, superiori all'intera spesa per l'infrastruttura.

La buona notizia è che i costi degli LLM sono completamente prevedibili prima di inviare una richiesta: conosce il modello, può contare i token di input con tiktoken e stimare i token di output in base all'impostazione max_tokens o alle medie storiche. Integrare la previsione dei costi nell'applicazione fin dal primo giorno evita sorprese in fattura.

OpenAI addebita separatamente i token di input e i token di output; questi ultimi costano in genere 3-4 volte di più. I prezzi variano in base al modello. Come riferimento per il 2025, verifichi sempre la pagina dei prezzi aggiornata perché può cambiare:

• gpt-4o-mini: circa 0,15 $/milione di token di input, circa 0,60 $/milione di token di output
• gpt-4o: circa 2,50 $/milione di token di input, circa 10,00 $/milione di token di output
• text-embedding-3-small: circa 0,02 $/milione di token

La differenza di costo tra i modelli è enorme: gpt-4o è circa 17 volte più costoso di gpt-4o-mini per token di input. La scelta del modello è la leva più importante per controllare i costi: inizi sempre dal modello meno costoso che soddisfa i requisiti di qualità.

Crei uno strumento di stima dei costi da chiamare prima di inviare ogni richiesta. Questo strumento conta i token di input con tiktoken, stima i token di output dal parametro max_tokens, recupera il prezzo per modello e restituisce il costo stimato in dollari. Lo utilizzi durante lo sviluppo e registri i risultati, così acquisirà familiarità con il costo dei diversi tipi di query.

Dopo ogni chiamata API, l'oggetto di risposta contiene il numero effettivo di token utilizzati. Lo estragga per registrare i costi reali e confrontarli con le stime. Nel tempo, la differenza tra i token di output stimati ed effettivi indica quanto accuratamente sta prevedendo l'utilizzo, mentre i log forniscono una suddivisione dei costi per funzionalità o segmento di utenti.

Una volta noto il costo medio per richiesta e il volume previsto di richieste, proiettare i costi mensili è semplice. Crei un foglio di calcolo per il modello dei costi o un semplice script Python che consenta di testare diverse ipotesi: cosa succederebbe se il numero di utenti attivi giornalieri raddoppiasse? E se aggiungessimo una funzionalità che effettua 3 chiamate API per ogni azione dell'utente invece di 1?

La leva più importante per ridurre i costi consiste nell'utilizzare il modello meno costoso che soddisfa i requisiti di qualità. Per molte attività, gpt-4o-mini offre prestazioni paragonabili a gpt-4o, ma a un costo circa 17 volte inferiore. Prima di scegliere automaticamente il modello più potente, esegua un benchmark del modello meno costoso sull'attività specifica e passi a quello più costoso solo se la qualità scende al di sotto della soglia stabilita.

Una strategia di instradamento a livelli è ancora più efficace: classifichi le richieste in arrivo in base alla complessità e indirizzi le query semplici verso modelli economici e quelle complesse verso modelli costosi. Anche indirizzare il 70% del traffico verso il modello economico e il 30% verso quello costoso consente di risparmiare circa il 70% dei costi di AI.

Ogni token nel prompt ha un costo. Un prompt di sistema prolisso, che potrebbe essere condensato senza perderne il significato, aumenta direttamente il costo dell'API per ogni richiesta. Misurate il numero di token dei vostri prompt e cercate opportunità per rendere la formulazione più concisa. Allo stesso modo, spesso è possibile sostituire esempi few-shot lunghi con equivalenti più brevi senza sacrificare la precisione.

Nei sistemi RAG, il contesto recuperato costituisce spesso la parte più consistente del prompt. Restituire 10 blocchi grandi quando ne basterebbero 3 più piccoli e scelti con cura comporta uno spreco di token per ogni query. Ottimizzate il recupero per ridurre al minimo il contesto ridondante massimizzando al contempo la rilevanza.

OpenAI offre una Batch API che elabora le richieste in modo asincrono con uno sconto del 50% rispetto al prezzo standard. Se il vostro caso d'uso non è sensibile alla latenza — elaborazione di documenti, processi di analisi notturni, generazione massiva di contenuti — la Batch API può dimezzare i costi con modifiche minime al codice.

Le richieste batch vengono inviate come file JSONL, elaborate entro 24 ore, e i risultati vengono recuperati dall'API. Questa soluzione è ideale per pipeline di preelaborazione eseguite secondo una pianificazione e che non necessitano di risposte in tempo reale.

Configurate sempre limiti di spesa per impedire che i costi aumentino senza controllo. Nella dashboard di OpenAI potete impostare limiti mensili di spesa che interrompono l'accesso all'API quando viene raggiunto il limite. Impostate un limite rigido pari alla spesa massima accettabile e un limite flessibile all'80% di tale valore, così da ricevere un avviso via email prima di raggiungere il limite rigido.

Nel codice dell'applicazione, implementate un budget per utente o per funzionalità registrato nel database. Verificate il budget prima di ogni chiamata all'API e restituite un errore se è esaurito. In questo modo impedite che un singolo utente fuori controllo o un bug in un processo batch consumi l'intera quota mensile nel giro di poche ore.

La chiamata API più economica è quella che non effettuate. Implementate la memorizzazione nella cache a livello applicativo per servire dalla cache le richieste identiche invece di chiamare nuovamente l'API. Anche una semplice cache Redis indicizzata sull'hash SHA256 del prompt può eliminare una parte significativa delle chiamate ridondanti in un'applicazione di produzione.

Per gli embedding, la memorizzazione nella cache è particolarmente efficace: lo stesso testo dovrebbe essere sottoposto a embedding una sola volta. Salvate gli embedding nel database vettoriale usando il testo originale come chiave e verificate l'esistenza di un embedding prima di chiamare l'API degli embedding. In una pipeline RAG, gli embedding dei documenti vengono calcolati una volta durante l'indicizzazione e riutilizzati per ogni query che recupera quei documenti.

In produzione, dovete avere visibilità sui costi dell'IA suddivisi per funzionalità, utente e modello. Create una dashboard dei costi registrando in un database di serie temporali il numero di token di ogni chiamata API e i relativi metadati (ID utente, nome della funzionalità, modello). Aggregate quindi i dati per rispondere a domande come: quale funzionalità genera la spesa maggiore? Gli utenti avanzati stanno generando costi sproporzionati? Il costo per query è aumentato dopo una modifica al prompt?

Questa visibilità è essenziale per prendere decisioni di ottimizzazione basate sui dati invece di cercare di indovinare dove ridurre i costi. La maggior parte delle aziende scopre che il 20% delle funzionalità rappresenta l'80% della spesa per l'IA e che ottimizzare queste funzionalità ha un impatto sproporzionato.

Verificate la vostra comprensione dei concetti di AI Engineering trattati in questa lezione.

In questa lezione avete imparato che: è possibile prevedere i costi dell'API prima dell'invio contando i token di input con tiktoken e stimando i token di output, la scelta del modello è il principale fattore di costo: gpt-4o-mini può costare 17 volte meno di gpt-4o per le attività appropriate e la memorizzazione nella cache, il batching e i limiti di spesa impediscono che i costi aumentino senza controllo in produzione. Ora analizzeremo le strategie per gestire conversazioni lunghe che superano la finestra di contesto.