Metodologia dei token AI

Il contatore di token stima quanti token utilizzerà un testo per una determinata API di modello linguistico di grandi dimensioni e moltiplica per i prezzi pubblicati attuali per stimare il costo. Entrambe le metà di questa frase hanno limiti di precisione significativi.

Stima dei token: euristica, non esatta

Ogni LLM moderno usa un tokenizer — tipicamente BPE (Byte Pair Encoding) per GPT e Claude, SentencePiece per Gemini e Llama — che converte il testo in una sequenza di ID token interi. La mappatura esatta è specifica del modello e proprietaria; eseguire il tokenizer effettivo richiede il file del modello tokenizer (tipicamente 1-5 MB) incluso nel client.

Non includiamo i tokenizer perché si aggiornano con i rilasci dei modelli e la dimensione del bundle si somma su 4+ vendor. Usiamo invece i rapporti caratteri-token pubblicati dalla documentazione di ciascun vendor:

• GPT-3.5/4/5: ~4 char per token per l’inglese; più alto per il codice; più basso per gli script non latini.
• Claude 3/4: ~3,5 char per token. Il tokenizer Claude è leggermente più aggressivo di quello GPT.
• Gemini: ~4 char per token per l’inglese.
• Llama 3/4: ~4 char per token.

Questi rapporti sono entro ~10% del vero conteggio di token per la tipica prosa inglese. Deviano maggiormente per il codice (che si tokenizza in più pezzi a causa delle divisioni degli identificatori), gli script non latini (cinese, giapponese, arabo — a volte 2-3× più token per carattere) e i dati strutturati (JSON, XML — da qualche parte tra l’inglese e il codice).

Prezzo: esatto ma obsoleto

Ogni modello ha un prezzo per token pubblicato per l’input e (separatamente) per i token di output. Codifichiamo questi prezzi in un registro che aggiorniamo manualmente quando i vendor aggiornano i loro prezzi (tipicamente ogni 1-3 mesi con il rilascio di nuovi modelli e la revisione dei prezzi di quelli vecchi).

I prezzi nel registro sono corretti al momento del deploy più recente. Per la previsione reale dei costi in produzione, controlla sulla pagina dei prezzi del vendor — e prevedi un margine del 15-30% perché il costo effettivo dipende dalla lunghezza dell’output, che è non deterministica.

Cosa modelliamo

Per ogni modello, il calcolatore stima:

• Token di input (dal prompt dell’utente).
• Token di output (da una stima fornita dall’utente o dal default del vendor).
• Costo = token_input × prezzo_input + token_output × prezzo_output.
• Il totale in USD con 6 cifre decimali.

Cosa non modelliamo

• Prezzi per input memorizzato nella cache. Diversi vendor (OpenAI, Anthropic) offrono prezzi scontati per i token di input che corrispondono a un prefisso di prompt visto di recente. Vale la pena saperlo; non è modellato qui.
• Sconti Batch API. Gli endpoint batch asincroni offrono spesso il 50% di sconto; non modellato.
• Input immagine/audio/video. I costi dei token multimodali variano per modello e vengono calcolati diversamente dal testo. In roadmap.
• Prezzi dei modelli ottimizzati (fine-tuned). I vendor applicano prezzi diversi per i fine-tune rispetto ai modelli base.

Dettagli dell’algoritmo: il ciclo di merge BPE

Sia GPT che Claude usano varianti di Byte Pair Encoding. La procedura di addestramento (Sennrich et al., 2016) parte da un vocabolario base di singoli byte e applica ripetutamente il merge:trova la coppia adiacente più frequente (a, b) nel corpus, aggiungi un nuovo token “ab” al vocabolario, sostituisci ogni occorrenza (a, b) con esso. La procedura si ferma quando il vocabolario raggiunge la dimensione target — 100.277 per cl100k_base di GPT-4o, ~128k per Llama 3, ~256k per Gemini.

La nostra euristica del rapporto di caratteri salta completamente il ciclo di merge. Per un testo con N caratteri e una media osservata di token per carattere r: token ≈ ⌈N × r⌉. Le costanti che usiamo:

Derivazione del costo: dati i token di input T_in, i token di output T_out e le tariffe per milione di token del vendor p_in e p_out, costo totale in USD = (T_in × p_in + T_out × p_out) / 1.000.000. Arrotondiamo a sei cifre decimali per preservare la precisione sotto al centesimo per i prompt brevi.

Fonti e riferimenti

Le euristiche in questa pagina sono calibrate rispetto al tokenizer di riferimento tiktoken di OpenAI su un corpus di 100k campioni di Wikipedia inglese. L’algoritmo BPE è documentato in Sennrich, Haddow & Birch (2016); SentencePiece, usato da Gemini e Llama, in Kudo & Richardson (2018). Vedi il blocco Fonti & riferimenti qui sotto per le citazioni primarie e le pagine dei prezzi dei vendor che ripetiamo.

Presupposti e limitazioni

• Calibrazione solo su prosa inglese. Le costanti token-per-carattere sono adattate al testo di Wikipedia in inglese. Codice, JSON, cinese, giapponese, arabo e altri script non latini possono deviare del 30-300% (il cinese usa tipicamente 2-3× più token per carattere).
• Nessun supporto per i prezzi dell’input memorizzato nella cache. OpenAI e Anthropic offrono entrambi sconti del 50-90% sui token del prefisso riutilizzati. La stima del costo usa il prezzo completo senza cache.
• Nessuno sconto Batch API. Gli endpoint batch asincroni dimezzano tipicamente il costo per token; non riflesso qui.
• La lunghezza dell’output è fornita dall’utente. Non possiamo prevedere la lunghezza della risposta; ±50% suT_out è tipico a seconda del prompt.
• Input visivi e audio non modellati. Ogni vendor conta i token non testuali in modo diverso (tile immagine per GPT-4o, secondi audio per Gemini, ecc.).
• Il prezzo è uno snapshot. Il registro si aggiorna mensilmente; le variazioni di prezzo dei vendor a metà mese non si riflettono fino al prossimo deploy.
• I prezzi per modelli ottimizzati e capacità riservata sono diversi. La stima usa solo le tariffe on-demand standard.

Quanto è accurata davvero la stima?

Per la tipica prosa inglese a lunghezza moderata (50-5000 caratteri), il nostro conteggio dei token è entro il 10% del vero conteggio e la nostra stima dei costi è entro il 10-15% della bolletta API effettiva. È più che sufficiente per dimensionamenti approssimativi — “questo prompt costa 1 centesimo o 1 dollaro?” — e inadeguato per la fatturazione precisa al centesimo. Per quest’ultima, usa il tokenizer ufficiale del vendor; per tutto il resto, il nostro è un utile controllo rapido.