Tokenizzazione: perché lo stesso testo in italiano costa più che in inglese

Hai un assistente che gira sulle API, un prompt che funziona, e una bolletta che non torna. Poi, per curiosità, traduci in inglese lo stesso prompt, stesse istruzioni, stesso contenuto, stesso modello, e il contatore dei token cala. Non del due per cento: di un quarto, di un terzo. Non hai cambiato niente di ciò che il modello deve fare: hai cambiato solo la lingua in cui gliel’hai chiesto. Non è un bug della piattaforma e non è un tuo errore di configurazione. È una cosa che succede prima che il modello venga interpellato, e ha un nome preciso.

In questo articolo scoprirai:

• La stessa richiesta in italiano fa salire il contatore: perché non è un tuo errore
• Cosa succede davvero: la tokenizzazione taglia il testo in pezzi di vocabolario
• Il conto, parola per parola: 18 parole italiane contro 16 inglesi
• Quando questo ti costa davvero: volume, finestra di contesto, troncamento
• Cosa si fa per pagare meno token, senza smettere di scrivere in italiano

La stessa richiesta in italiano fa salire il contatore: perché non è un tuo errore

Il posto in cui te ne accorgi è sempre lo stesso: la pagina di consumo. Nella console del Claude API vedi gli input tokens per chiamata; nella dashboard di OpenAI vedi la stessa cosa; nell’API di Gemini c’è un metodo count_tokens che ti dice quanto pesa una richiesta prima di mandarla. Chi lavora in italiano nota una cosa ricorrente: il costo per chiamata è sistematicamente più alto di quello che si legge nei tutorial e nelle stime dei fornitori, che sono scritti quasi tutti in inglese.

Il secondo posto in cui si vede è la finestra di contesto. Un chatbot che risponde su un manuale: la versione inglese del documento entra intera, quella italiana viene troncata, e il retrieval comincia a perdere pezzi. Terzo posto: le stime di progetto. Hai preventivato un agente su una media di token misurata su documenti inglesi, e a fine mese il conto è più alto del previsto senza che nessuno abbia cambiato il codice.

Le regole a spanne sui token sono tarate sull’inglese

Le regole a spanne che circolano nascondono il problema perché sono tarate sull’inglese. La documentazione di Anthropic sul conteggio dei token dice: «1 token is approximately 4 characters or 0.75 words in English. The exact count varies by language and content type». Quella di Google è ancora più esplicita: «For Gemini models, a token is equivalent to about 4 characters» e «100 tokens is equal to about 60-80 English words». In entrambi i casi la parola chiave è English: quelle proporzioni non valgono per l’italiano, e nessuno lo scrive in grassetto al posto tuo.

Cosa succede davvero: la tokenizzazione non legge parole, ma pezzi di vocabolario

La tokenizzazione è il passaggio in cui il testo, prima di arrivare al modello, viene tagliato in pezzi presi da un vocabolario fisso, costruito statisticamente sul corpus di addestramento: le sequenze di caratteri frequenti in quel corpus diventano un pezzo solo, quelle rare vengono spezzate in due, tre o quattro pezzi. Poiché quei vocabolari sono costruiti in larga parte su testo inglese, una parola italiana perfettamente comune può frantumarsi in più token mentre il suo equivalente inglese ne occupa uno. E quello che paghi, e quello che riempie la finestra di contesto, sono i token, non le parole.

Pre-tokenizzazione e morfologia: dove l’italiano perde token

Sopra questo c’è un secondo strato, la pre-tokenizzazione: prima dei merge di vocabolario il testo viene tagliato su spazi e punteggiatura. È il motivo per cui l’apostrofo italiano è particolarmente caro: «dell’azienda» viene spezzato al segno di elisione prima che il vocabolario possa provare a tenerlo insieme. Aggiungici la morfologia, costruire, costruiremo, costruirebbero, costruendolo sono quattro forme distinte, dove l’inglese usa build più una parolina separata, e capisci perché l’italiano si frammenta più dell’inglese in modo strutturale, non occasionale. Se vuoi il quadro di cosa avviene dopo, dai token alla risposta generata, l’abbiamo raccontato in come funziona un large language model.

Che il fenomeno sia misurato e non aneddotico lo dice il lavoro di Petrov, La Malfa, Torr e Bibi presentato a NeurIPS 2023: «The same text translated into different languages can have drastically different tokenization lengths, with differences up to 15 times in some cases». Quindici volte è il caso peggiore, su lingue con altri sistemi di scrittura; l’italiano sta molto più vicino all’inglese, ma non ci sta sopra.

Il conto, parola per parola: 18 parole italiane contro 16 inglesi

Prendiamo un’istruzione vera, il tipo di riga che sta in ogni system prompt di un assistente documentale.

Italiano: «Rispondi in modo conciso e cita sempre la fonte del documento che hai usato per costruire la risposta.» → 18 parole, 102 caratteri (spazi e punto compresi).
Inglese: «Answer concisely and always cite the source of the document you used to build the answer.» → 16 parole, 89 caratteri.

Da dove escono i token: 1,66 per parola in italiano

Parole e caratteri li puoi ricontare a mano: sono esatti. I token vanno derivati, e qui va detto da dove escono. La misura di riferimento più pulita che abbiamo trovato è un’analisi indipendente che confronta il costo in token di cinque lingue (non una fonte primaria: un lavoro pubblico e riproducibile). Tokenizza le 50.000 parole più frequenti per lingua del corpus OpenSubtitles 2018 con o200k_base, il tokenizer uscito con GPT-4o e usato dai modelli OpenAI successivi, pesando le parole per frequenza d’uso reale. Risultato: 1,16 token per parola in inglese contro 1,66 in italiano, cioè un sovrapprezzo del 43% (francese e tedesco 1,52, spagnolo 1,56).

Applicati alla nostra istruzione: 18 × 1,66 ≈ 30 token in italiano, 16 × 1,16 ≈ 19 token in inglese. Il divario è del 58%, più alto del 43% di listino, perché i due effetti si moltiplicano: l’italiano usa più parole per dire la stessa cosa (18 contro 16) e spende più token per parola. Controprova con la regola dei 4 caratteri: 89 / 4 dà 22 contro i 19 stimati, stesso ordine di grandezza. Sull’italiano la stessa regola dà 102 / 4 ≈ 26 contro 30 e sbaglia per difetto in modo netto, perché in italiano un token copre in media 3,4 caratteri invece di 4,7. È esattamente la frammentazione, vista dall’altro lato.

Quando il conto sui token non si trasferisce

Quando questa spiegazione non vale: il sovrapprezzo dell’italiano non è una costante, e i conti fatti su un tokenizer non si trasferiscono a un altro. La documentazione di Anthropic avvisa che i modelli da Claude 4.7 in avanti usano un tokenizer nuovo che «produces approximately 30% more tokens for the same text», vale anche per l’inglese. E se il tuo prompt è fatto in gran parte di codice, JSON, schemi di tool o numeri, il divario fra le lingue quasi svanisce, perché quel contenuto non è prosa italiana.

Quando questo ti costa davvero: volume, finestra di contesto, troncamento

Su una chiamata sola il 43% non si vede. Si vede sul volume. Prendiamo un assistente di primo livello con 4.000 conversazioni al giorno; assumiamo 3.700 token di input e 300 di output per conversazione, ordine di grandezza tipico di un assistente di primo livello. Sono 120.000 chiamate al mese. Su Claude Haiku 4.5 (1 $/MTok in input, 5 $/MTok in output, listino Anthropic) il conto inglese fa 444 $ di input più 180 $ di output: 624 $ al mese. Lo stesso servizio in italiano, con lo stesso contenuto, pesa 1,43 volte tanto: 892 $ al mese, cioè 3.216 $ in più all’anno per aver parlato la lingua dei tuoi clienti. Sullo stesso volume, su un modello di fascia Sonnet (3 $ e 15 $/MTok) le stesse chiamate passano da 1.872 $ a 2.677 $ al mese.

Meno testo italiano nella stessa finestra di token

Il secondo costo non è in dollari, è in capienza. Con 200.000 token di finestra ci stanno circa 172.000 parole inglesi (200.000 / 1,16) ma solo 120.000 italiane (200.000 / 1,66): la stessa finestra tiene circa il 30% di testo italiano in meno. Su un sistema RAG questo si traduce in meno chunk recuperati per risposta, e su una conversazione lunga nel troncamento della storia, che è il meccanismo per cui l’assistente «dimentica» quello che gli hai scritto dieci turni prima. Non è il modello che è distratto: è il budget di token che è finito prima. Il fatto che le finestre da un milione di token siano diventate standard sposta il problema più in là: non lo cancella, perché quei token li paghi tutti.

Il preventivo tarato su token inglesi sbaglia del 40%

Il terzo costo è il preventivo sbagliato. Se hai stimato il progetto su benchmark inglesi, il tuo modello di costo è ottimista del 40% circa sulla parte a consumo, ed è la ragione per cui la scelta fra abbonamento e API va rifatta con i tuoi token, non con quelli del listino: ne abbiamo discusso in quando le API convengono rispetto all’abbonamento.

Cosa si fa per pagare meno token, senza smettere di scrivere in italiano

Primo: misura, non stimare. L’endpoint count_tokens del Claude API è gratuito (fino a 2.000 richieste al minuto sul tier di ingresso) e accetta lo stesso payload della chiamata reale, tool e allegati compresi. Gemini ha il suo count_tokens, OpenAI ha il tokenizer pubblico e la sua guida al conteggio. Regola operativa: conta il prompt col modello che userai davvero, e ricontalo a ogni cambio di modello, il salto del 30% sul tokenizer di Claude 4.7 rende inservibili i conteggi vecchi.

Secondo: separa le istruzioni dal contenuto. Il system prompt, gli schemi dei tool e le regole interne non li legge nessun cliente: tenerli in inglese taglia la parte fissa del conto, mentre input e output restano in italiano. Va verificato con un A/B sul tuo compito, non dato per buono: se la qualità cala, hai risparmiato nel posto sbagliato.

Caching e batch: dove si taglia il conto dei token

Terzo: il prompt caching è la leva più grossa che hai. Un system prompt italiano lungo è caro una volta e poi costa il 10% del prezzo di input a ogni lettura (moltiplicatore 0,1x sui cache hit, contro 1,25x della scrittura a 5 minuti). Per i lavori non interattivi, la Batch API taglia del 50% input e output, e i due sconti si sommano.

Quarto: non tradurre i documenti, riducili. Su un RAG conviene lavorare sui chunk, meno testo, più pertinente, invece di gonfiare il contesto sperando che il modello ci trovi la risposta. E scegli il modello per compito: la differenza fra Haiku e Opus sulla stessa mole di token italiani è di un ordine di grandezza.

Il punto è che nessuno di questi quattro interventi si decide a naso: si decide su una misura di consumo per tipo di chiamata, ripetuta nel tempo. È lo stesso lavoro che serve per capire come si tiene sotto controllo la spesa di un agente che gira ogni giorno, e che noi abbiamo fatto prima di tutto sui nostri conti, pubblicandoli in quanto costa davvero un mese di lavoro con Claude Code.

Una nota finale, per chi spera che il problema si risolva da sé: non è solo questione di vocabolari più grandi. Il lavoro di Arnett, Chang, Biderman e Bergen (NeurIPS 2025) mostra che sui token premium pesano dimensione del vocabolario e pre-tokenizzazione, e che aumentare il vocabolario non basta a livellare il divario. Nel frattempo, il conto lo paghi tu, a token.

Spezzare il testo in token è il primo dei passaggi che portano da una frase scritta a una risposta generata: il percorso completo, dall’ingresso all’uscita, mostra dove si colloca questo pezzo e cosa succede subito dopo.

Fonti:

• Petrov, La Malfa, Torr, Bibi — «Language Model Tokenizers Introduce Unfairness Between Languages» (NeurIPS 2023, abstract su arXiv)
• Arnett, Chang, Biderman, Bergen — vocabolario, pre-tokenizzazione e «token premium» fra lingue (arXiv, 2025)
• OpenAI — «Hello GPT-4o»: il modello che introduce il tokenizer o200k_base
• «Not speaking English to ChatGPT costs you» — token per parola misurati per lingua su OpenSubtitles (analisi indipendente)
• Anthropic — Token counting: rapporto token/caratteri, endpoint count_tokens e variabilità per lingua
• Anthropic — listino prezzi dei modelli Claude, prompt caching e Batch API
• OpenAI Help — cosa sono i token e come contarli
• Google — Gemini API: capire e contare i token