Qual è l'LLM più economico per lingua? Costi dei tokenizer

Non esiste un unico LLM più economico per i testi multilingue. Sullo stesso brano, GPT-5.5 fattura meno token per le lingue europee, l’hindi e il coreano; Kimi K2.5 è il più efficiente per il cinese, DeepSeek per il giapponese. Claude Fable 5, Opus 4.8 e Sonnet 5 condividono lo stesso tokenizer: hanno restituito conteggi identici per ogni campione inviato. Non sono mai i più efficienti. Lo stesso paragrafo inglese viene fatturato come 90 token grezzi da Claude e 55 da DeepSeek; il sovrapprezzo netto va da 1.3x per il giapponese a 2.2x per il cinese. Il token è l’unità di fatturazione, quindi il costo dell’input dipende da due fattori che raramente compaiono nelle pagine dei prezzi: quanta informazione una lingua concentra nei caratteri e quanto bene il tokenizer di ogni modello comprime quel sistema di scrittura. I due fattori si moltiplicano e il risultato non è quello suggerito dal conteggio per carattere.

TL;DR

• Claude Fable 5, Opus 4.8 e Sonnet 5 condividono un tokenizer e non sono mai i più efficienti: in tutti i casi richiedono 1.2-2.3x token rispetto al conteggio più basso.
• Il tokenizer più economico cambia in base alla lingua: GPT-5.5 per le lingue europee, l’hindi e il coreano; Kimi per il cinese; DeepSeek per il giapponese.
• Per carattere, CJK sembra costare 3x di più. A parità di significato, però, il cinese è vicino alla parità, mentre giapponese e coreano richiedono 1.5-2.4x token.
• Il costo è il prodotto tra densità del sistema di scrittura e copertura del tokenizer; una copertura insufficiente moltiplica il costo (GLM fattura l’hindi a 4.9x rispetto al proprio inglese).
• Localizzare raramente fa risparmiare; conviene scegliere il modello in base ai token richiesti per ciascuna lingua.

I conteggi sono stati misurati tramite il gateway Synthorai il 2026-07-08, usando sempre il conteggio restituito dal provider e mai un tokenizer locale. Ogni ripetizione ha prodotto risultati identici.

L’unità di fatturazione è il token, non il testo

La fatturazione avviene per token, ma un token non corrisponde né a un carattere né a una parola. Ogni modello usa un proprio tokenizer, con un proprio vocabolario, e la stessa frase produce conteggi diversi. Il numero ottenuto viene poi moltiplicato per il prezzo unitario del token. Cambiano quindi due variabili contemporaneamente: quanti token genera il testo e quanto costa ciascun token.

La maggior parte delle pagine dei prezzi mostra solo il secondo dato. Questo articolo misura il primo. Abbiamo inviato tre brani semanticamente allineati a sette modelli (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5) e registrato il numero di token fatturati come input.

Un testo narrativo informale, ambientato in un mercato del sabato, è disponibile in nove lingue. Una spiegazione tecnica, sui retry con exponential backoff, e una breve notizia, su una votazione relativa al bilancio comunale, sono disponibili in inglese, cinese, giapponese, coreano, tedesco e hindi. Completano il set una funzione Python e un payload JSON per una tool call. Le versioni non inglesi sono traduzioni automatiche prodotte con istruzioni di fedeltà e senza compressione, poi verificate manualmente a campione. La verbosità della traduzione è un fattore di disturbo reale; la sezione sul registro qui sotto ne stima l’impatto intorno al 20%.

Il conteggio proviene sempre dal provider. Per Claude abbiamo eseguito una vera chiamata Messages e letto usage.input_tokens, perché al momento il gateway non espone count_tokens. Per i modelli compatibili con OpenAI abbiamo effettuato una piccola chiamata e letto usage.prompt_tokens. In questo modo evitiamo esattamente il problema di un tokenizer locale che non coincide con la fattura. C’è anche un controllo importante: ogni richiesta include un framing fisso, come chat template e indicatori di ruolo, che vale alcuni token. Misuriamo quindi un campione di riferimento di due caratteri e lo sottraiamo. Tutti i rapporti riportati nell’articolo escludono questo overhead e confrontano il testo, non il framing.

Lo stesso testo con cinque tokenizer

La tabella mostra il conteggio grezzo dei token di input del brano narrativo, suddiviso per lingua e tokenizer. I tre modelli Claude condividono una colonna perché hanno restituito conteggi identici per ogni campione; torneremo sul punto più avanti. Gli altri due brani seguono lo stesso schema e vengono inclusi nelle analisi successive. La colonna dei caratteri indica la lunghezza della versione in ciascuna lingua. I sistemi di scrittura concentrano il significato in modo diverso: per esprimere lo stesso contenuto, al cinese bastano 77 caratteri, mentre l’inglese ne richiede 254.

Emergono subito due dati. La colonna Claude contiene un solo valore per tre modelli perché Claude Fable 5, Opus 4.8 e Sonnet 5 hanno restituito conteggi identici per tutti i campioni, incluse lingue, codice e JSON. Tutti e tre usano il tokenizer introdotto con Opus 4.7, quindi il conteggio di uno vale anche per gli altri. Inoltre, questa colonna contiene il valore più alto in ogni riga, tranne per l’hindi, dove i 192 token di GLM sono ancora peggiori. Normalizzando i conteggi netti in modo che il modello più efficiente di ogni lingua valga 1.00, si ottengono i rapporti seguenti. L’overhead viene sottratto prima del calcolo, quindi questi valori non coincidono con la semplice divisione delle celle grezze riportate sopra.

Il pareggio a quattro nella riga inglese non dipende dall’arrotondamento: DeepSeek, GLM, GPT-5.5 e Kimi producono esattamente 50 token netti per quel brano. Claude richiede da 1.3x a 2.2x token rispetto al tokenizer più efficiente su questo testo, e da 1.2x a 2.3x considerando tutti e tre i brani. È una caratteristica del vocabolario che si applica a ogni chiamata per l’intera vita del modello. I brani tecnico e giornalistico confermano la classifica: sommando entrambi, Claude fattura il cinese come 212 token netti contro i 114 di Kimi (1.9x) e l’hindi come 477 contro i 210 di GPT-5.5 (2.3x). Non esiste però un vincitore assoluto. La colonna più efficiente cambia con la lingua:

• GPT-5.5 è il più efficiente per tedesco, francese, spagnolo, italiano, hindi e coreano, ed è a pari merito per l’inglese. Il pareggio e i risultati per fr/es/it valgono solo per il brano narrativo. Il suo vocabolario è ottimizzato per i sistemi di scrittura latini e mantiene buoni risultati anche con devanagari e hangul.
• Kimi K2.5 è il più efficiente per il cinese e resta competitivo nell’intero gruppo CJK.
• DeepSeek-v4 è il più efficiente per il giapponese e segue da vicino sul cinese.
• GLM 5.2 si colloca a metà classifica per gran parte delle lingue, ma presenta i valori peggiori della matrice per l’hindi: 2.59x rispetto al modello più efficiente sul testo narrativo, con 179 token netti contro i 69 di GPT-5.5. Sui brani formali va ancora peggio ed è l’unica colonna a superare persino Claude.

La penalizzazione non riguarda solo la prosa. Sulla funzione Python, Claude richiede 1.61x token rispetto al modello più efficiente; sul JSON della tool call, 1.29x. Nel JSON il divario è minore perché il testo strutturato è composto soprattutto da punteggiatura e brevi chiavi ASCII, che tutti i tokenizer gestiscono in modo simile. In un agent di lunga durata che reinvia a ogni turno un ampio schema degli strumenti, questo costo aggiuntivo si accumula. È proprio in questo scenario che il caching diventa utile. La serie sul prompt caching ne descrive il funzionamento.

La trappola del costo per carattere: CJK sembra peggiore di quanto venga fatturato

Le tabelle precedenti confrontano i modelli. Se invece si mantiene fisso il modello, anche la lingua modifica il conteggio, ma non nel modo suggerito dai caratteri grezzi. Il dato sui tokenizer citato più spesso è il numero di token per carattere, e CJK domina questa metrica. Su Claude, il cinese richiede circa 114 token netti ogni 100 caratteri, il coreano 106 e il giapponese 94, contro i 32 dell’inglese. Considerando solo questa colonna, CJK sembra comportare un sovrapprezzo di 3x. Ma non è la metrica giusta: si paga il significato, non il numero di caratteri, e il brano allineato esprime lo stesso contenuto in ogni lingua. La tabella mostra entrambe le prospettive su Claude, per il testo narrativo:

Le due colonne a destra raccontano storie diverse. Il cinese è il caso più evidente: ha la densità per carattere più alta dell’insieme, ma per esprimere lo stesso significato costa solo 1.07x rispetto all’inglese in questo brano. In 77 caratteri esprime ciò per cui l’inglese ne usa 254. L’elevato costo per carattere viene quindi moltiplicato per un numero di caratteri molto ridotto e i due effetti quasi si compensano. La compensazione rimane visibile su tutti e tre i brani, anche se non è perfetta: il cinese richiede in media 1.17x token rispetto all’inglese di Claude e da 0.95x a 1.32x a seconda del modello. È vicino alla parità, non al 3x suggerito dalla colonna per carattere.

Giapponese e coreano mostrano il limite di questa compensazione. Entrambi hanno un’elevata densità di token per carattere, ma hangul e kana giapponesi rappresentano i suoni, all’incirca un glifo per sillaba, invece di concentrare un’intera parola in ogni carattere come fanno gli hanzi cinesi. Per questo il coreano richiede 143 caratteri e il giapponese 136 per il contenuto che il cinese esprime in 77. Un numero maggiore di caratteri moltiplicato per un costo elevato per carattere non produce una compensazione, ma amplifica il costo: su Claude, considerando i tre brani, il coreano richiede in media 1.96x token rispetto all’inglese a parità di significato, e il giapponese 1.56x. Entrambe sono lingue realmente costose, anche se la loro colonna per carattere è simile a quella del cinese.

Il tedesco è l’immagine speculare del cinese: ha un costo per carattere contenuto, pari a 48 e vicino a quello dell’inglese, ma il maggior numero di caratteri tra le lingue considerate, 289, anche per via delle parole composte. Il totale arriva comunque a 1.68x. Il costo è il prodotto dei due assi; considerarne solo uno porta a conclusioni sbagliate.

Perché i numeri cambiano: due fattori che si moltiplicano

Tutte le tabelle precedenti seguono una sola equazione:

token per un brano = (caratteri necessari per esprimere il significato) x (token per carattere)

Il primo fattore è la densità del sistema di scrittura. È una proprietà della lingua, non del modello. Non si tratta di un’eccezione propria del cinese, ma di uno spettro. Il cinese logografico concentra un morfema in ogni carattere e si trova all’estremo più denso. I kana giapponesi e l’hangul coreano rappresentano i suoni, quindi sono meno densi e richiedono più caratteri. Il devanagari e gli alfabeti latini sono ancora meno densi. La quantità di significato per carattere diminuisce progressivamente dal cinese all’inglese.

Il secondo fattore è il numero di token che il vocabolario del modello usa per ogni carattere di quel sistema di scrittura, ed è interamente specifico del modello. Un tokenizer BPE apprende merge di più caratteri dal corpus di addestramento. I sistemi di scrittura presenti più spesso ottengono token compatti; quelli meno frequenti tendono a essere codificati carattere per carattere o persino a livello di byte, facendo sì che un carattere possa diventare due o tre token. Ecco i token netti per carattere per le stesse tre lingue:

La tabella chiarisce tre aspetti. Il cinese risalta nei totali perché è estremo sul primo fattore. Anche la debole compressione del cinese da parte di Claude, 1.14 token per carattere, con alcuni hanzi ancora suddivisi in due token, non produce un totale elevato quando i caratteri sono solo 77. I modelli addestrati in Cina lo comprimono abbastanza bene, da 0.52 a 0.58, da arrivare quasi alla parità con il proprio inglese. Il sovrapprezzo dell’hindi dipende invece dal secondo fattore, non dalla densità. GLM usa 0.91 token per carattere devanagari, quasi un token per carattere, perché il suo vocabolario contiene pochissimi merge di più caratteri devanagari. GPT-5.5 ne usa 0.35 grazie alla copertura di interi gruppi sillabici: è un divario di copertura sullo stesso sistema di scrittura. Claude è costoso ovunque perché il suo valore per carattere è alto persino sull’inglese, 0.32 contro gli 0.20 di DeepSeek. Questa base specifica del modello si somma all’effetto della lingua.

Il fenomeno non è limitato ai sette modelli esaminati. Nella letteratura scientifica è chiamato token premium. Petrov et al. (NeurIPS 2023) lo hanno misurato su centinaia di coppie linguistiche, individuando le stesse due cause principali: il numero di caratteri necessario per esprimere lo stesso significato varia tra le lingue, così come la copertura del tokenizer tra i sistemi di scrittura. Per le lingue con poche risorse, hanno rilevato sovrapprezzi fino a 15x, con le stesse conseguenze: costi e latenza più elevati e una context window effettiva più piccola, perché una lingua con un token premium alto riempie lo stesso budget di contesto con meno significato. Il divario si riduce anche grazie agli investimenti dei provider. Misurazioni indipendenti stimano per il cinese un +182% di token rispetto all’inglese con i vocabolari dell’epoca di GPT-3 e un +24% con quello di GPT-4o. Sono valori vicini al +32% misurato su GPT-5.5 e alla parità rilevata sui modelli addestrati in Cina. La copertura richiede slot nel vocabolario e i provider continuano a investirvi.

Localizzare consente mai di risparmiare?

Dalla sezione precedente si potrebbe concludere che “Claude ha costi uniformi tra le lingue, quindi la localizzazione non conta” oppure che “i modelli cinesi costano meno sul cinese, quindi localizzare fa risparmiare”. Entrambe le conclusioni sono errate. La tabella confronta ogni lingua con l’inglese dello stesso modello, usando la media dei tre brani per le cinque lingue disponibili in tutti i casi:

Claude non ha costi uniformi: il coreano richiede 1.96x token rispetto al suo inglese, l’hindi 2.40x. Il cinese vicino a 1.17x è un caso specifico di quella lingua, non una proprietà del modello. Anche i modelli cinesi non scendono davvero sotto la parità sul cinese: si limitano a raggiungerla. Il valore migliore dell’intera tabella è lo 0.95x di Kimi, il cinque percento in meno rispetto al proprio inglese; tutte le altre celle hanno un costo uguale o superiore. Per hindi, giapponese e coreano, gli stessi modelli hanno una penalizzazione maggiore rispetto a Claude, non minore, perché questi sistemi di scrittura sono più distanti dai dati su cui si concentra il loro addestramento. Non esiste un “provider X economico” in assoluto: rispetto al proprio inglese, ogni modello è più efficiente nelle lingue più vicine ai suoi dati di addestramento.

Anche il registro modifica questi valori. Il brano narrativo informale è il caso più favorevole. I testi tecnico e giornalistico aumentano quasi tutti i moltiplicatori, perché i termini specialistici e i prestiti linguistici sono proprio gli elementi per cui i vocabolari non latini dispongono di meno merge. Su Claude, il tedesco passa da 1.68x nel testo informale a 2.29x in quello tecnico; l’hindi di GLM raggiunge 5.98x rispetto al proprio inglese nel testo giornalistico. Un benchmark basato su un solo brano favorisce la lingua che ha ricevuto la traduzione più semplice. Nel solo testo narrativo, Kimi portava il cinese a 0.80x; usando tre brani, il valore sale a 0.95x.

Il confronto con l’inglese dello stesso modello non è comunque la prospettiva giusta. La fattura dipende dal numero assoluto di token. Da questo punto di vista, Claude è il più costoso in otto lingue su nove; l’unico caso peggiore è l’hindi di GLM. Il contenuto cinese che risulta “economico rispetto all’inglese di Claude” richiede comunque 88 token netti su Claude contro i 40 di Kimi per il testo narrativo. La scelta corretta non è localizzare per risparmiare, ma associare il modello alla lingua: Kimi o DeepSeek per il cinese, GPT-5.5 per hindi e coreano, DeepSeek per il giapponese. Claude non è mai il vincitore sul costo in token, anche se può comunque offrire una qualità migliore.

I conteggi rappresentano solo metà della fattura

Il moltiplicatore dei token conta solo insieme al prezzo per token, e i due fattori si moltiplicano. Claude Fable 5 ha un prezzo di listino di $10 per milione di token di input, Opus 4.8 di $5 e Sonnet 5 di $3 dopo la fine del prezzo introduttivo. Sul cinese, il tokenizer condiviso conta anche 2.2x token rispetto al modello più efficiente. Questo sovrapprezzo di conteggio moltiplica qualsiasi differenza tariffaria già esistente rispetto all’alternativa verso cui si potrebbe instradare la richiesta. Può accadere anche il contrario: un modello può produrre pochi token e costare comunque di più per chiamata perché la tariffa è elevata. Nessuno dei due valori, preso da solo, determina la fattura. Non riportiamo qui le tariffe degli altri provider perché cambiano più rapidamente dei tokenizer; i conteggi precedenti costituiscono la parte più stabile del calcolo.

In pratica, non bisogna confrontare i prezzi di listino, ma il costo effettivo dell’input: il mix reale di traffico, conteggiato su ogni modello candidato, moltiplicato per la relativa tariffa di input. In un prodotto con molto traffico in cinese o coreano, questo calcolo può cambiare l’ordine dei modelli per costo. Il divario è stabile, da 1.5x a 2x, e non un semplice errore di arrotondamento. Per lo stesso motivo, con il caching conta il costo effettivo ponderato per l’hit rate, non la tariffa nominale. Il confronto tra provider illustra il calcolo. L’analisi tra versioni, incluso il motivo per cui Sonnet 5 conta il 41% di token in più rispetto a Sonnet 4.6 sullo stesso testo inglese, è disponibile nell’articolo sul tokenizer di Sonnet 5.

In sintesi

• Il costo in token è il prodotto tra densità del sistema di scrittura e copertura del tokenizer. La lingua determina il primo fattore, il modello il secondo; considerarne solo uno porta a conclusioni errate.
• Claude Fable 5, Opus 4.8 e Sonnet 5 richiedono da 1.2x a 2.3x token rispetto al modello più efficiente in ogni lingua, perché il loro costo per carattere è elevato persino in inglese.
• Il modello più efficiente dipende dalla lingua: GPT-5.5 per le lingue europee, l’hindi e il coreano; Kimi per il cinese; DeepSeek per il giapponese. GLM è il peggiore sull’hindi, con quasi un token per carattere.
• I registri formale e tecnico aumentano il moltiplicatore in quasi tutte le lingue; il benchmark deve usare lo stesso registro del traffico reale.
• Non conviene localizzare per risparmiare. Bisogna associare il modello alla lingua in base al numero assoluto di token, quindi moltiplicare il conteggio per la tariffa di ciascun modello per confrontare il costo effettivo.

FAQ

Quale tokenizer LLM è il più economico? Dipende dalla lingua. Su sette modelli e gli stessi brani allineati, GPT-5.5 è risultato il più efficiente per le lingue europee, l’hindi e il coreano, ed è a pari merito per l’inglese. Kimi K2.5 ha ottenuto il conteggio più basso per il cinese e DeepSeek-v4 per il giapponese. La famiglia Claude, composta da Fable 5, Opus 4.8 e Sonnet 5, non è mai stata la più efficiente: in ogni lingua e registro ha richiesto da 1.2x a 2.3x token rispetto al conteggio più basso.

Claude Fable 5, Opus 4.8 e Sonnet 5 usano lo stesso tokenizer? Sì. Tutti e tre hanno prodotto conteggi identici per ogni campione, in tutte le lingue, oltre che per codice e JSON. Usano il tokenizer introdotto con Opus 4.7, quindi il conteggio di un modello vale anche per gli altri. Il costo superiore di Fable 5 dipende interamente dal prezzo per token.

Il cinese costa più dell’inglese su Claude? Leggermente: 1.17x a parità di significato, come media dei tre brani, e circa quanto l’inglese sui modelli addestrati in Cina. Per carattere sembra molto più costoso: circa 114 token netti ogni 100 caratteri cinesi contro 32 per l’inglese. Il cinese, però, esprime lo stesso significato con circa un terzo dei caratteri, quindi i due effetti quasi si compensano.

Giapponese e coreano si comportano come il cinese? Solo in parte. Condividono l’elevata densità di token per carattere del cinese, ma hangul e kana rappresentano i suoni, quindi richiedono molti più caratteri per lo stesso brano: 136 per il giapponese e 143 per il coreano, contro i 77 del cinese. L’elevato costo per carattere non viene più compensato. A parità di significato, su Claude il giapponese richiede circa 1.6x token rispetto all’inglese e il coreano circa 2x; sui sette modelli l’intervallo va da 1.5x a 2.4x.

Come posso effettuare queste misurazioni sui miei prompt? Invia alcuni prompt reali, nello stesso registro usato in produzione, a ogni modello candidato e leggi il conteggio dei token di input restituito dal provider nei campi usage, invece di affidarti a un tokenizer locale. Un singolo brano favorevole può far sembrare una lingua più efficiente di circa il 20%, quindi usane diversi. Moltiplica poi ogni conteggio per il prezzo di input del modello per ottenere il costo effettivo sul tuo traffico.

← Torna al blog