Tokenizzazione degli LLM e italiano: la tassa nascosta del 64% sulla bolletta API e come ridurla

Il 24 aprile 2026, mentre rifinivo la pipeline di ingest RAG che tiene aggiornato il knowledge base interno della mia automazione editoriale, ho fatto un esperimento controllato sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5, 240 GB NVMe). Ho preso 50 prompt operativi reali della mia pipeline personale di automazione AI, system prompt di classification, briefing per agenti di scraping, istruzioni di rewrite editoriale, tutti scritti in italiano per ovvie ragioni di dominio. Li ho tokenizzati prima con tiktoken (encoding cl100k_base per GPT-4 e o200k_base per GPT-4o e GPT-5) e poi via l'endpoint /v1/messages/count_tokens di Anthropic contro claude-opus-4-7. Stessi testi, stesso contenuto informativo. Risultato: in italiano i 50 prompt occupano in media il 64% di token in più rispetto alle loro traduzioni inglesi automatiche, con un range che va dal +37% sui testi tecnici densi di acronimi inglesi (API, MCP, GDPR) al +94% sui testi narrativi con verbi coniugati e enclitiche tipo "comunicarmelo" o "richiamandoti". Questa è la tassa nascosta più ignorata sulla bolletta API delle PMI italiane che integrano LLM in produzione.

Non è un'ipotesi mia. Aleksandar Petrov, Emanuele La Malfa e i loro coautori dell'Università di Oxford l'hanno dimostrato formalmente nel paper Language Model Tokenizers Introduce Unfairness Between Languages presentato a NeurIPS 2023. Su 17 tokenizer commerciali analizzati, lo stesso identico contenuto tradotto in lingue diverse produce sequenze di token con differenze fino a 15 volte. Per l'italiano nel tokenizer cl100k_base di GPT-4 il moltiplicatore è circa 1,64x rispetto all'inglese, esattamente il numero che ho ritrovato sperimentalmente nella mia sandbox quasi tre anni dopo, e che il tokenizer più recente o200k_base di GPT-4o e GPT-5 ha solo marginalmente attenuato. È un fatto strutturale del modo in cui questi modelli vedono il testo, non un bug temporaneo.

Perché lo stesso prompt costa il 64% in più in italiano?

Il motivo è nascosto sotto il cofano, in un componente che il marketing AI non menziona quasi mai: il tokenizzatore Byte Pair Encoding. Quando scrivi a Claude o GPT in italiano, il modello non legge "comunicarmelo" come una parola: legge una sequenza di sotto-pezzi che il suo tokenizer ha imparato a estrarre osservando miliardi di documenti. La grande maggioranza di quei documenti è in inglese (oltre il 90% nei dataset di training accessibili pubblicamente per i modelli frontier), quindi l'algoritmo BPE durante l'addestramento ha allocato token "lunghi" e semanticamente densi alle stringhe inglesi più frequenti, e ha lasciato l'italiano frammentato in pezzi più piccoli.

Concretamente: la frase inglese "I'll let you know" diventa 5 token in cl100k_base. La sua traduzione "te lo farò sapere" diventa 8 token. Stesso significato, +60% di token. Moltiplica questo squilibrio su un system prompt da 800 parole, su un retrieval RAG da 12 chunk in italiano, su un agent loop che richiama 30 volte lo stesso contesto, e capisci perché un'azienda italiana che integra LLM in produzione paga in media il 60-70% in più della sua omologa anglofona a parità di funzionalità erogata.

Il problema non si limita al portafoglio. Petrov e colleghi nel paper notano tre conseguenze pratiche che si moltiplicano tra loro:

• Costo API: input e output fatturati per token, +64% di token equivale a +64% di bolletta sulla parte non cacheable
• Context window saturato prima: se Opus 4.7 ha 200k token di context utile, in italiano ne usi davvero 122k di contenuto informativo equivalente
• Latenza più alta: il modello deve generare più token in output per produrre la stessa risposta, e il time-to-first-token su sequenze più lunghe è più alto

Per chi serve clienti PMI italiani con chatbot, agenti di customer support o pipeline di document processing, questi tre effetti compongono. Non è "un dettaglio tecnico", è un costo strutturale che entra nel TCO del progetto e che il consulente AI medio italiano non monitora perché vende dashboard e demo, non governance.

Se vuoi un'idea di come gestisco i costi LLM senza incidenti di budget

Nel mio hub dedicato all'AI per aziende raccolgo articoli tecnici sulla governance dei costi LLM, sul prompt caching workspace-level, sul monitoring di drift, su tutte le voci che il mercato italiano sottovaluta perché il dato finisce in fattura solo dopo qualche mese di produzione. Se ti riconosci nel pattern "ho integrato un LLM e mi sta sorprendendo la fattura", la lettura è da lì.

Cosa è successo con Claude Opus 4.7 ad aprile 2026

Il 16 aprile 2026 Anthropic ha rilasciato Claude Opus 4.7 con un dettaglio che molti hanno trascurato leggendo solo i benchmark di coding: il modello arriva con un nuovo tokenizer, e per i testi italiani questo nuovo tokenizer produce in media il 35% di token in più rispetto alla versione precedente, a parità di prezzo headline ($5/M input, $25/M output). Significa che chi al 15 aprile 2026 aveva il budget mensile sotto controllo, al 17 aprile si è ritrovato a pagare il 35% in più senza aver toccato una virgola del codice di integrazione. Ne ho scritto in dettaglio nell'analisi del nuovo tokenizer Opus 4.7, qui mi limito a sottolineare la lezione: i tokenizer cambiano senza preavviso e portano con sé invalidazione delle cache prompt, ricalibrazione dei limiti rate e revisione dei contratti con i clienti basati su number-of-message.

L'equivalente in altri ambiti sarebbe se il tuo provider cloud ridenominasse silenziosamente il listino senza changelog. Il fatto che i fornitori LLM lo facciano è un'asimmetria informativa che il consulente serio deve presidiare contrattualmente, non subire.

Misurare il problema sulla tua pipeline: il metodo passo per passo

Prima di proporre soluzioni serve misurare il dato. La regola che applico nel mio laboratorio è semplice: se non puoi mostrare il numero, non puoi ottimizzarlo. Ti riporto il setup che uso per avere una baseline credibile in 30 minuti.

Per la parte OpenAI installa la libreria ufficiale tiktoken da PyPI. Per GPT-4 e GPT-3.5-Turbo l'encoding corretto è cl100k_base. Per GPT-4o, GPT-4.1, GPT-5 e i modelli reasoning o1, o3 e o4-mini è o200k_base. Non confonderli: usare l'encoding sbagliato ti dà un conteggio fuori del 5-10% e qualunque ottimizzazione successiva diventa rumore.

import tiktoken

enc_gpt4 = tiktoken.get_encoding("cl100k_base")
enc_gpt5 = tiktoken.get_encoding("o200k_base")

prompt_it = "Riepiloga in tre punti i rischi NIS2 per una PMI manifatturiera italiana"
prompt_en = "Summarize in three points the NIS2 risks for an Italian manufacturing SME"

print(f"IT cl100k: {len(enc_gpt4.encode(prompt_it))} token")
print(f"EN cl100k: {len(enc_gpt4.encode(prompt_en))} token")
print(f"IT o200k:  {len(enc_gpt5.encode(prompt_it))} token")
print(f"EN o200k:  {len(enc_gpt5.encode(prompt_en))} token")

Per la parte Anthropic non esiste una libreria locale equivalente, perché il tokenizer di Claude è proprietario e non pubblicato. C'è però l'endpoint server-side POST /v1/messages/count_tokens, gratuito e con rate limit indipendente da quello dei messaggi, secondo la documentazione ufficiale. Lo chiami con lo stesso payload di una richiesta messages normale e ti risponde con {"input_tokens": N}.

import anthropic
client = anthropic.Anthropic()

response = client.messages.count_tokens(
    model="claude-opus-4-7",
    messages=[{"role": "user", "content": prompt_it}],
)
print(f"Opus 4.7 IT: {response.input_tokens} token")

Lo script che applico tiene traccia in un CSV di slug, lingua, modello, encoding, token in input, token attesi in output (campionati da risposte reali) e costo previsto a $5 e $25 per milione. Dopo una settimana di esercizio hai distribuzione, mediana e outlier. Quel CSV è il documento di partenza per ogni decisione di ottimizzazione: senza dati, sei in territorio di buzzword.

Tre strategie concrete per ridurre il tokenaggio in produzione

A questo punto puoi attaccare il problema su tre fronti, in ordine di ROI decrescente sulla mia pipeline personale.

Prompt design difensivo: il primo intervento, quasi gratuito, è riscrivere il system prompt eliminando le forme prolisse che l'italiano tende a produrre quando un copywriter non tecnico lo trasforma in markdown. "Per favore, vorresti cortesemente fornire un'analisi dettagliata che evidenzi tutti i punti critici" diventa "Analizza ed elenca i punti critici". Stessa istruzione, da 18 a 5 token. Su un system prompt da 1.200 token che viaggia con ogni chiamata di un agent loop, una riduzione del 30% è facile e si ammortizza in giorni. Tieni l'italiano dove serve la precisione semantica (regole di business, normativa, glossario di dominio) e riscrivi in italiano essenziale tutto il resto. Non passare all'inglese: quel passo va affrontato per ragioni più mirate, vedi sotto.

Prompt caching workspace-level: la seconda strategia è l'invalidazione del problema. Se la maggior parte del system prompt e del contesto RAG è stabile tra una chiamata e l'altra, attivare il prompt caching workspace-level di Anthropic riduce di 10x il costo dei token cache-hit (paghi il 10% del prezzo input standard) e azzera la differenza tra italiano e inglese sulla parte cacheable. È un meccanismo che ho documentato nell'analisi del prompt caching workspace misurando una riduzione del 95% sui costi del mio assistant interno di knowledge management. Sui prompt italiani lunghi e ripetitivi è la leva più potente che esista oggi nel listino Anthropic.

Switch di lingua selettivo: il terzo intervento è chirurgico, non un sostituto dei primi due. Il system prompt tecnico e il glue code dell'agent puoi scriverli in inglese. Il content che il modello restituisce all'utente finale resta in italiano (basta una riga di istruzione "respond to the user in Italian"). Su pipeline che non toccano dominio normativo italiano specifico ho misurato un risparmio del 25-30% del tokenaggio totale senza degrado di qualità nelle risposte. Il pattern che ha funzionato meglio nella mia sandbox è il prompt bilingue stratificato: blocco istruzioni di sistema in inglese (regole, formato output, vincoli), blocco di dominio in italiano (glossario, esempi, terminologia normativa), istruzione finale in inglese che impone la lingua di risposta. Su un agent di triage editoriale che gira 1.200 volte al giorno questo schema mi ha portato la spesa mensile da circa $84 a $61 sull'API Anthropic, senza regressione misurabile nella qualità delle classificazioni. Attenzione però: per articoli giuridici, contrattualistica, glossari NIS2 o GDPR italiani devo restare in italiano anche nelle istruzioni di sistema o il modello scivola su terminologia inglese che non è straffidabile sul registro normativo italiano. Le sentenze del Garante usano "interessato", non "data subject"; i contratti usano "trattamento", non "processing"; le clausole RID parlano di "addebito", non di "direct debit". Va misurato caso per caso, mai assunto a priori.

Quando NON conviene scrivere in inglese

Gira sui blog di marketing AI una falsa scorciatoia: "scrivi tutti i prompt in inglese e risparmi il 40%". Tre obiezioni, dalla mia esperienza concreta nella pipeline personale.

Primo, se il dominio è italiano specifico (compliance, fiscale, contrattualistica) il modello in inglese tende a usare equivalenti americani che non mappano sui concetti reali. Il "consulente del lavoro" non è un "labor consultant", il "regime forfettario" non è un "flat-rate scheme" trasferibile direttamente, e l'output che ne deriva richiede review manuale che mangia il risparmio.

Secondo, i dati Osservatorio Politecnico Milano 2026 (presentati il 5 febbraio 2026) raccontano che il mercato AI italiano vale 1,8 miliardi di euro con +50% anno su anno, l'84% delle grandi aziende italiane ha acquistato licenze GenAI ma solo il 9% ha una governance strutturata. In altre parole: la maggior parte delle integrazioni in produzione lavora con prompt italiani malamente ottimizzati e nessuno dentro l'azienda è incaricato di misurarne il costo reale. Ottimizzare la tokenizzazione è un layer di governance che entra in questo gap, non una micro-ottimizzazione tecnica.

Terzo, e questo è il punto che il consulente AI medio non tratta: l'audit. Quando un revisore tecnico interno deve capire perché un agent ha preso una certa decisione, leggere i log del prompt in italiano è prerequisito di accountability. Spostare i prompt in inglese rende la pipeline più cheap ma meno auditable, e per un cliente con esposizione AI Act medio-alta è un trade-off che non puoi fare senza dichiararlo.

La regola pratica nella mia sandbox è: italiano per tutto ciò che è dominio specifico, audit-relevant o user-facing; inglese per glue code, system prompt tecnici puri, schema di tool MCP. Questo mix mi tiene tra il 25 e il 35% di risparmio sui token rispetto a un approccio "tutto in italiano per default" e mantiene la pipeline pienamente auditabile.

C'è un ultimo aspetto che vale la pena tenere a mente per chi gestisce PMI con clienti europei: il framework che sto descrivendo è un'applicazione concreta del principio di minimizzazione di GDPR Art. 5(1)(c) applicato al data processing LLM. Mandare 64% di token in più al modello significa anche mandare 64% in più di contenuto fuori dal perimetro aziendale verso il provider americano. Non è solo bolletta, è anche superficie di esposizione. Chi sta valutando se la sua pipeline LLM regge un'ispezione del Garante nel 2026 dovrebbe avere la curva token mensile sul cruscotto come ha quella della spesa cloud. Se lo sviluppi tu o lo costruisce un consulente, il monitoring è una decisione che si prende a freddo, non in emergenza dopo la prima fattura sorprendente. Se vuoi un confronto tecnico su quanto un'integrazione LLM tua o futura possa costare per un sito o un'azienda con volumi italiani reali, il modulo di preventivo gratuito è il punto di partenza in due minuti, sette domande, nessun impegno.