Quanti token ha il mio prompt?

I modelli linguistici non leggono caratteri né parole. Leggono token: frammenti prodotti suddividendo il testo secondo un vocabolario fisso appreso dai dati di addestramento.

Le parole comuni sono di solito un singolo token. Le parole rare vengono spezzate in più pezzi. Gli spazi vengono in genere attaccati all’inizio del token successivo: ecco perché la stessa parola può contare in modo diverso a seconda che apra o meno una frase.

Misurata con il tokenizer di GPT-4o, la parola unbelievable isolata vale tre token: un + bel + ievable. Scritta come compare davvero in una frase, con il suo spazio iniziale, è un token solo: unbelievable. È la regola dello spazio iniziale all’opera: la voce che il modello ha appreso è la forma con lo spazio davanti, perché è così che la parola ricorre quasi sempre nel testo corrente. the e international si comportano allo stesso modo, un token ciascuno con lo spazio attaccato.

È per questo che i conteggi dei token sembrano imprevedibili. L’unità non è linguistica, è statistica. È la frequenza nel corpus di addestramento a determinare se qualcosa vale un token o quattro.

Per la prosa in inglese, misurata con il tokenizer di GPT-4o su registri che vanno dalla scrittura colloquiale ai testi tecnici di consultazione:

• 1 token ≈ 4,3–5,9 caratteri
• 1 token ≈ 0,75–0,95 parole
• 1.000 parole ≈ 1.050–1.350 token
• Una pagina standard (~500 parole) ≈ 530–680 token

Il registro conta più di quanto ammettano la maggior parte delle regole pratiche. La scrittura informale e colloquiale si colloca verso il fondo di quell’intervallo, intorno ai 1.060 token ogni mille parole, perché riutilizza un piccolo vocabolario di parole comuni che stanno ciascuna in un solo token. La prosa tecnica densa — comprese le guide di questo sito — si colloca verso l’estremo opposto, intorno ai 1.310, perché i termini specialistici vengono spezzati in più pezzi. La cifra secca più nota, 1.300 token ogni mille parole, è l’estremo tecnico dell’intervallo, non il suo centro: sovrastima quindi la scrittura ordinaria di circa un quinto. Ed è la direzione giusta in cui sbagliare, quando si pianifica lo spazio di una finestra di contesto.

Queste stime crollano rapidamente fuori dalla prosa ordinaria:

Tipo di contenuto	Approssimativamente
Prosa in inglese	0,75–0,95 parole per token, a seconda del registro
Codice	Circa 1,2 volte i token della prosa a parità di caratteri, e circa 1,5 volte per lo stesso concetto espresso nei due modi
JSON con chiavi lunghe	Molto alto: punteggiatura e virgolette sono token separati
Cinese, giapponese, coreano	Circa 0,6–0,7 token per carattere: meno di un token ciascuno, ma diverse volte quanto spende l’inglese a parità di numero di caratteri
Cirillico, Devanagari, arabo	Circa 1,4–1,6 volte l’inglese a parità di testo
URL e hash	Altissimo: le stringhe casuali si tokenizzano male
Spaziature ripetute	Economiche, non costose: il byte-pair encoding fonde le sequenze lunghe, quindi quaranta spazi consecutivi sono un solo token

Il divario multilingue è reale, ma molto più contenuto di quanto racconti il folklore. Misurate sulle pagine inglesi di questo sito contro le rispettive traduzioni professionali, la versione giapponese costa circa 1,7 volte l’inglese, quella coreana circa 1,5, la cinese circa 1,2, l’hindi circa 1,6 e l’araba circa 1,4. Con il vecchio tokenizer cl100k_base le stesse coppie stavano a 2,3, 2,3, 1,7, 4,7 e 2,9 volte: è da lì che arriva la cifra ripetuta ovunque del «due o tre volte l’inglese». Allora era vera; i vocabolari più recenti hanno in gran parte colmato il divario.

Ogni famiglia di modelli usa il proprio tokenizer con il proprio vocabolario, quindi lo stesso testo produce conteggi diversi.

I modelli GPT usano varianti del byte-pair encoding: cl100k_base per i modelli dell’era GPT-4, o200k_base per quelli più recenti. Claude usa un tokenizer diverso, con un vocabolario diverso. I modelli aperti come Llama e Mistral ne hanno ciascuno uno proprio.

I vocabolari divergono soprattutto su codice e testi non inglesi, quindi è lì che divergono di più anche i conteggi.

In pratica questo significa:

• Un conteggio fatto con un tokenizer è una stima per qualsiasi altro modello.
• Solo il tokenizer del fornitore dà un numero esatto per la sua fatturazione.
• Pianifica il budget con un margine, invece di aderire esattamente al limite.

Il nostro Contatore di token mostra fianco a fianco un conteggio GPT-4o e una stima Claude. Il numero GPT-4o è un conteggio reale del tokenizer. Quello di Claude, deliberatamente, no: Anthropic non pubblica un tokenizer che possiamo eseguire nel tuo browser, quindi si tratta di una stima basata sui caratteri, con un token ogni 3,5 caratteri. Sulla prosa in inglese quella stima si colloca dal 22 al 50% sopra il conteggio GPT-4o — circa un terzo per la scrittura tipica — quindi leggi lo scarto come l’ampiezza di una stima, non come una differenza misurata tra le due famiglie di modelli. La coppia basta comunque per capire se un prompt è comodamente dentro il limite o pericolosamente vicino; quando il numero deve essere esatto, usa il contatore del fornitore.

Costo. I prezzi delle API sono per token, con input e output tariffati separatamente; l’output costa in genere molte volte di più. Raddoppiare un system prompt raddoppia quel costo a ogni singola chiamata: il genere di cosa invisibile nei test e costosa su larga scala.

Limiti di contesto. La finestra copre tutto: system prompt, cronologia della conversazione, documenti recuperati, il messaggio corrente e lo spazio riservato alla risposta. Le chat lunghe falliscono non perché un messaggio sia lungo, ma perché la cronologia si accumula.

Troncamento. Quando l’input supera il limite, qualcosa viene eliminato: spesso in silenzio, e spesso i contenuti più vecchi. Un modello che ha «dimenticato» le tue istruzioni molto spesso le ha semplicemente viste troncate.

Suddivisione per il retrieval. Spezzare i documenti per l’embedding funziona a token, non a caratteri. Blocchi dimensionati per numero di caratteri risultano incoerenti, e blocchi tagliati a metà frase si recuperano male, quindi una pipeline di retrieval ha bisogno di uno strumento di suddivisione che rispetti la struttura di frasi e paragrafi. Il nostro Suddividi testo non è quello strumento: taglia blocchi di dimensione fissa fino a 2.000 caratteri, spezzando in corrispondenza dello spazio più vicino così che nessuna parola resti divisa a metà, il che significa che un blocco può finire a metà frase. Usalo per far entrare un documento lungo in una finestra di contesto o in un limite di incollaggio, non per produrre blocchi di embedding per il retrieval.

Le riduzioni più efficaci, approssimativamente in ordine:

1. Riduci la cronologia della conversazione. In una chat lunga supera di gran lunga tutto il resto. Riassumi i turni vecchi invece di reinviarli parola per parola.
2. Elimina le istruzioni ridondanti. Ripetere una regola in tre modi non la rende tre volte più probabile da seguire. Triplica però in modo affidabile il costo di quella regola.
3. Rimuovi gli artefatti di formattazione. Caratteri invisibili, spaziature ripetute e righe decorative di separazione vengono tutti tokenizzati. Presi singolarmente costano meno di quanto si creda, perché il byte-pair encoding fonde le sequenze lunghe: quaranta spazi consecutivi sono un token e una riga di separazione di quaranta trattini ne vale due, contro i tredici della frase che la precede. Restano comunque puro sovraccarico e, in un documento con una riga di separazione tra una sezione e l’altra, si sommano. Rimuovere caratteri invisibili elimina quelli che non si vedono.
4. Accorcia le chiavi JSON nei prompt strutturati. {"n": ...} contro {"customer_full_name": ...}, moltiplicato su mille record, fa una grande differenza.
5. Invia solo gli estratti pertinenti. Recuperare tre paragrafi rilevanti batte incollare un intero documento, e di solito produce anche risposte migliori oltre che più economiche.

Cosa non aiuta: rimuovere la normale punteggiatura, cancellare gli articoli o scrivere in stile telegrafico. Il risparmio è marginale e il danno alla qualità dell’output no.