Come funziona davvero la tokenizzazione GPT (e perché la tua fattura dipende da essa)

Ogni chiamata API a un grande modello linguistico viene misurata intoken— né caratteri né parole. I token sono l’unità che il modello consuma effettivamente dopo che il testo è stato codificato da un tokenizzatore a byte-pair encoding(BPE). Capire come funziona la tokenizzazione è importante perché (a) determina la tua fattura, e (b) è il motivo per cui “un documento da 1000 parole” non si mappa in modo preciso a “un costo di 1000 token.”

Come funzionano i tokenizzatori BPE

L’algoritmo in poche righe:

1. Inizia con un vocabolario di singoli byte (256 voci).
2. Trova la coppia adiacente di voci del vocabolario più frequente in un grande corpus di addestramento.
3. Aggiungi quella coppia come nuova voce del vocabolario.
4. Ripeti finché il vocabolario raggiunge la dimensione target (50k-100k voci per i modelli moderni).
5. Per tokenizzare un nuovo testo, sostituisci avidamente le coppie dalla corrispondenza più lunga alla più corta.

Risultato: le parole inglesi comuni come “the”, “and”, “understanding” diventano ciascuna un token singolo. Le parole rare come “rambunctious” vengono divise in 2-4 token. Emoji e caratteri non inglesi spesso richiedono 2-6 token ciascuno.

Conteggi di token per contenuti comuni

Conteggi approssimativi di token per GPT-4 (tokenizzatore cl100k_base):

La cifra di riferimento per l’inglese è ~750 parole per 1.000 token. Le scritture non latine costano significativamente più token per carattere perché non erano rappresentate così densamente nel corpus di addestramento.

Perché il divario di costo è importante

Il pricing per token significa che il contenuto non inglese costa 2-4 volte di più per la stessa idea. Un documento da 1.000 parole costa:

• Inglese: ~1.300 token → $0,013 al prezzo di input GPT-4o (~$10/M token).
• Russo: ~3.500 token → $0,035 (2,7 volte di più per lo stesso contenuto).
• Cinese: ~1.500 token (per carattere, le scritture dense compensano leggermente) → $0,015.

Per un’azienda di traduzione o un sistema di supporto multilingue, l’asimmetria del costo per lingua si accumula rapidamente. Anthropic, OpenAI e Google pubblicano i costi dei token per modello; il costo effettivo del contenuto dipende da quale lingua e formato stai pagando.

Differenze di tokenizzatore tra i modelli

Ogni famiglia di modelli ha il proprio tokenizzatore:

• OpenAI cl100k_base (GPT-3.5, GPT-4): vocabolario di ~100.000 token. Il tokenizzatore inglese moderno di riferimento.
• OpenAI o200k_base (GPT-4o, serie o): vocabolario di 200.000 token. Migliore per non inglese e codice. Un dato documento richiede circa il 10-15% di token in meno rispetto a cl100k.
• Tokenizzatore Anthropic Claude:proprietario. Approssimativamente simile alla densità di cl100k per l’inglese; differisce in modo misurabile per codice e non inglese. Anthropic pubblica un endpoint di conteggio token per stimare prima dell’invio.
• Google Gemini: usa SentencePiece. Densità approssimativamente comparabile a cl100k.

Implicazione: lo stesso prompt inviato a GPT-4o vs Claude vs Gemini non produce conteggi di token identici. Il budget su più provider richiede una stima di token per provider, non una singola regola “1 parola ≈ 1,3 token”.

Dove la tokenizzazione influenza la progettazione del prompt

1. Costi di contesto lungo. Una finestra di contesto da 100k token che contiene tutta la tua documentazione è ottima finché non realizzi che il costo per chiamata è $1+ per un utilizzo tipico. I conteggi di token si accumulano nelle conversazioni multi-turno.
2. JSON vs linguaggio naturale. Chiedere output JSON costa circa il 30-50% di token in più rispetto a chiedere prosa semplice comparabile. La punteggiatura di JSON viene tokenizzata in modo aggressivo.
3. Compiti di codice. Il codice è circa 2 volte più denso in token rispetto alla prosa. Un file da 200 righe potrebbe essere 2.000-3.000 token. Gli strumenti che includono tutto il tuo repository come contesto si accumulano velocemente.
4. Lingue non inglesi. 2-4 volte più token per carattere. Per i prodotti multilingue questo è un costo di primo ordine.

Come stimare i token prima di pagare

1. Usa uno strumento di conteggio token. Il nostro contatore di token AI implementa più tokenizzatori e riporta il conteggio esatto per il tuo input.
2. Usa la libreria di tokenizzatori ufficiale. Il tiktokendi OpenAI (Python), l’API del tokenizzatore di Anthropic o i contatori di token ospitati. Questi sono la fonte di verità per la fatturazione.
3. Regola pratica. Per la prosa in inglese: 1 parola ≈ 1,3 token. Per il codice: 1 riga ≈ 8-15 token. Per il cinese: 1 carattere ≈ 1,5 token.
4. Bilancia anche l’output.Molti provider addebitano di più per l’output che per l’input (tipicamente 3-5 volte per token). Un output da 2.000 token è più costoso di un input da 2.000 token.

La ragione strutturale più profonda del BPE

I LLM moderni vedono token, non caratteri. Gli embedding, l’attenzione e l’output del modello sono tutti definiti su un vocabolario di token finito. I modelli a livello di carattere esistono ma sono più lenti (ogni carattere è una posizione di input) e più difficili da addestrare. I modelli a livello di parola non riescono a gestire le parole non viste (problema fuori vocabolario). BPE è il compromesso che ha vinto.

Per approfondire, consulta la nostra voce del glossario token GPT e la guida su come funziona il pricing dei token.

Guida: tokenizzazione di una singola frase

Frase: “The rambunctious cat’s purr 😺 was unmistakable.”(9 parole, 49 caratteri con l’emoji.)

Sotto cl100k_base (GPT-4):

• The → 1 token (parola molto comune con variante a spazio iniziale).
• rambunctious → 3 token ( ram + bunct + ious).
• cat → 1 token.
• ’s → 1 token (la contrazione apostrofo-s è una singola unione).
• purr → 1 token.
• 😺 → 3 token (i byte UTF-8 dell’emoji si dividono in più pezzi BPE).
• was → 1 token.
• unmistakable → 2 token ( unm + istakable).
• . → 1 token.

Totale: 14 token per 9 parole — un rapporto di 1,56 token per parola aumentato da rambunctious(3 token) e dall’emoji (3 token). Sostituire entrambi con alternative comuni riduce il costo: “The loud cat’s purr was unmistakable” richiede ~9 token per la stessa idea. Per un utilizzo API ad alto volume, questo tipo di ingegneria del vocabolario si accumula.

Errori comuni

• Stimare i token dal conteggio dei caratteri. La regola pratica “1 token ≈ 4 caratteri” è molto imprecisa per codice, JSON e non inglese. Un blob JSON da 1.000 caratteri può essere 400-800 token a seconda dei nomi delle chiavi e dell’annidamento.
• Dimenticare i token del prompt di sistema.Un prompt di sistema da 2.000 token è incluso in ogni richiesta e fatturato ad ogni chiamata. Gli agenti multi-turno con una cronologia di chat in crescita pagano per l’intera conversazione precedente ad ogni round, non solo per il messaggio più recente.
• I benefici della cache dipendono dalla stabilità del prefisso. La cache dei prompt (quando disponibile) si attiva solo quando la sequenza di token è byte-identica nel prefisso. Un timestamp inserito dinamicamente alla posizione 50 invalida la cache per ogni token successivo. Metti il contenuto dinamico alla fine, non nel mezzo.
• Usare il tokenizzatore sbagliato per la stima dei costi. cl100k_base e o200k_base producono conteggi di token ~10-15% diversi per lo stesso input. Se stai modellando i costi per GPT-4o usando cl100k, la stima è alta.
• Rimuovere aggressivamente gli spazi bianchi. Molti token iniziano con uno spazio iniziale. Rimuovere tutti gli spazi e concatenare le parole può produrre piùtoken, non meno, perché il tokenizzatore non riesce a usare le sue unioni comuni “ parola” e torna alle divisioni a livello di byte.