Token e tokenizzazione: capire cosa mangia un LLM

#Perché parlare di token

Quando parli con un LLM locale attraverso Ollama o LM Studio, scrivi frasi. Il modello, invece, non vede mai le tue frasi così come sono. Prima ancora del primo calcolo, il tuo testo viene trasformato in una sequenza di numeri, ciascuno dei quali rappresenta un token. Tutto ciò che fa il modello — capire, generare — avviene al livello di questi token, non delle parole.

Capire i token non è un dettaglio accademico. È ciò che spiega tre cose molto concrete: perché un documento «entra» o meno nella finestra di contesto, perché il tuo modello genera a una certa velocità (i famosi token al secondo) e perché la fatturazione di un'API cloud o un limite di contesto si esprimono sempre in token, mai in parole.

#Che cos'è esattamente un token

Un token è un frammento di testo: a volte una parola intera, spesso una parte di parola, a volte un semplice carattere o un segno di punteggiatura. Non è né una lettera né una parola in senso stretto — è un'unità statistica scelta dall'algoritmo di tokenizzazione per rappresentare il testo nel modo più efficiente possibile.

La regola empirica più utile: in inglese, 1 token ≈ 4 caratteri ≈ 0,75 parole. In altre parole, 100 token equivalgono a circa 75 parole inglesi. Per il francese, il rapporto è nettamente meno favorevole; ci torneremo più avanti.

"chat"

Una parola frequente e breve: spesso 1 solo token.

"anticonstitutionnellement"

Una parola rara e lunga: suddivisa in più token (anti / constitution / nelle / ment…).

" " (spazio)

Lo spazio è generalmente unito all'inizio del token successivo, non è un token a sé.

"123456"

I numeri sono spesso suddivisi cifra per cifra o in piccoli gruppi.

😀

Un emoji può costare diversi token da solo.

Alle parole molto comuni viene assegnato un singolo token perché ricorrono ovunque nei dati di addestramento. Le parole rare, tecniche o in una lingua poco rappresentata vengono ricostruite a partire da frammenti più piccoli, il che le rende più «costose» in termini di token.

#Come un testo è veramente suddiviso

La maggior parte dei modelli LLM moderni utilizza una famiglia di algoritmi chiamata BPE (Byte Pair Encoding) o le sue varianti (WordPiece, Unigram). Il principio: partire dai caratteri grezzi, poi unire progressivamente le coppie di simboli più frequenti del corpus di addestramento fino a ottenere un vocabolario di dimensione fissa — tipicamente compreso tra 32.000 e 200.000 token a seconda del modello.

1. 01
   Suddivisione iniziale

   Il testo viene ridotto ai suoi byte o caratteri di base. Niente viene perso: ogni stringa può essere rappresentata.
2. 02
   Fusioni apprese

   Il tokenizer applica l'elenco di fusioni apprese durante l'addestramento (ad esempio « t » + « ion » → « tion ») nell'ordine di frequenza.
3. 03
   Conversione in identificatori

   Ogni token finale viene sostituito dal suo numero nel vocabolario. Il modello non gestisce altro che questi interi.

Conseguenza importante: il vocabolario viene fissato durante l'addestramento. Un modello addestrato soprattutto su testi in inglese avrà un vocabolario ottimizzato per l'inglese e suddividerà il francese in frammenti più piccoli e più numerosi. È questa l'origine del costo aggiuntivo per chi usa il francese.

#Perché il francese costa più dell'inglese

A parità di contenuto, un testo francese consuma comunemente dal 15 al 30 % di token in più rispetto alla sua traduzione inglese. Su alcuni modelli molto incentrati sull'inglese, la differenza può superare il 50 %. Tre ragioni si sommano.

Vocabolario non equilibrato

I tokenizzatori sono addestrati principalmente sull'inglese: le parole inglesi comuni hanno un token dedicato, quelle francesi no.

Accenti e caratteri speciali

é, è, à, ç, œ… sono più rari nel vocabolario e a volte vengono suddivisi in più token (o addirittura in byte).

Morfologia più ricca

Coniugazioni, concordanze ed elisioni (l', d', qu') moltiplicano le forme di una stessa parola, che sono meno ben rappresentate nel vocabolario.

Esempio concreto: la frase inglese «The cat is on the table» occupa circa 6 token. La sua versione francese «Le chat est sur la table» ne occupa piuttosto da 7 a 8 a seconda del modello. Su un intero paragrafo, la differenza diventa significativa — e si paga due volte: in spazio nella finestra di contesto e in tempo di generazione.

#Token e finestra di contesto

La finestra di contesto di un modello si misura in token, non in parole né in caratteri. Un modello dichiarato con 32.768 token di contesto può «vedere» in un dato momento l'equivalente di circa 24.000 parole inglesi — ma solo circa 18.000-20.000 parole francesi, a causa del maggiore costo in token della tokenizzazione.

Questa finestra include tutto: il system prompt, la cronologia della conversazione, il tuo messaggio attuale, i documenti incollati e la risposta in corso di generazione. Quando il totale supera il limite, il modello tronca il contenuto — generalmente quello più vecchio — e «dimentica» l'inizio dello scambio.

System prompt

Conteggiato a ogni chiamata. Un prompt di sistema prolisso consuma continuamente spazio nel contesto.

Cronologia

Ogni turno di conversazione si accumula. Una lunga discussione finisce per saturare la finestra.

Documenti (RAG, copia-incolla)

Un PDF di 10 pagine può facilmente contenere diverse migliaia di token.

Risposta generata

Anche l'output occupa spazio: bisogna riservarne abbastanza per la risposta.

#Token e velocità in locale

La velocità di un LLM si misura in token al secondo (tok/s). È l'unità universale dei benchmark. Due momenti da distinguere, spesso confusi.

Prompt / prefill

Il tempo necessario per «leggere» l'intero prompt. Più token ci sono in ingresso, più tempo impiega la prima risposta a iniziare.

Generazione / decodifica

La velocità con cui escono i token di risposta, uno per uno. È il valore in tok/s che si osserva sullo schermo.

Conseguenza diretta per il francese: poiché lo stesso contenuto corrisponde a più token, il tuo modello impiega automaticamente più tempo per elaborare un prompt in francese e generare una risposta in francese di lunghezza equivalente. La sensazione che «è più lento in francese» non è soggettiva — dipende dal numero di token.

La velocità di decodifica dipende soprattutto dal modello e dall'hardware (parametri attivi per token, larghezza di banda della memoria, quantizzazione). Ma a parità di hardware, ridurre il numero di token in ingresso — prompt di sistema più breve, cronologia sfoltita — riduce nettamente il time-to-first-token.

#Contare i token di un testo autonomamente

Il modo migliore per sviluppare una comprensione intuitiva è misurare. Ecco tre approcci, dal più semplice al più preciso.

#Stimare a occhio

Per una stima rapida senza installare nulla: dividi il numero di caratteri per 4 per l'inglese e per un valore tra 3 e 3,5 per il francese. È una stima approssimativa, ma sufficiente per capire se un documento rientra in una finestra di contesto.

#Contare in Python con il vero tokenizer

Per un conteggio esatto, usa il tokenizer del modello. La libreria tokenizers / transformers di Hugging Face carica il tokenizer reale di un modello open-weight:

from transformers import AutoTokenizer

# Remplacez par le modèle que vous faites tourner en local
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B")

texte_fr = "Le chat est sur la table."
texte_en = "The cat is on the table."

print(len(tok.encode(texte_fr)), "tokens (fr)")
print(len(tok.encode(texte_en)), "tokens (en)")

# Voir le découpage réel
print(tok.tokenize(texte_fr))

Eseguire questo script sui tuoi testi è l'esercizio più chiaro: vedrai con i tuoi occhi quali parole francesi vengono spezzate e di quanto l'inglese è più compatto.

#Leggere il conteggio dall'API Ollama

Ollama fornisce già i conteggi dei token nelle sue risposte. Il daemon è in ascolto per impostazione predefinita su http://localhost:11434; una chiamata all'API restituisce prompt_eval_count (token del prompt) e eval_count (token generati):

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "Explique la tokenization en une phrase.",
  "stream": false
}' | grep -o '"eval_count":[0-9]*'

Lì trovi anche eval_duration: dividi eval_count per la durata per ottenere il vero throughput in token al secondo, sulla tua macchina, con la tua quantizzazione.

#Risparmiare token senza perdere in qualità

Poiché ogni token ha un costo in termini di contesto e velocità, alcune semplici abitudini fanno davvero la differenza, soprattutto in francese.

Prompt di sistema conciso

Viene inviato di nuovo a ogni chiamata. Ogni frase superflua ha un costo a ogni turno.

Ridurre la cronologia

Riassumi o elimina i vecchi scambi invece di portarti dietro l'intera conversazione.

RAG piuttosto che incollare tutto

Inserisci solo i passaggi rilevanti di un documento, non l'intero documento.

Definire la lunghezza dell'output

Chiedere una risposta breve fa generare meno token, quindi permette di ottenere la risposta più velocemente.

#Per approfondire

I token sono il filo che lega diverse nozioni fondamentali. Tre guide approfondiscono direttamente questa: la prima descrive in dettaglio la finestra di contesto che i token riempiono, la seconda spiega come la quantizzazione influisce sulla velocità misurata in token al secondo, la terza mostra come il transformer elabora questi token al suo interno.