Token

Un token è l’unità di base di input e output elaborata da un modello AI: una parola, una parte di una parola, un carattere o un byte nel testo, oppure una regione di pixel in un’immagine. Prima che un Transformer possa leggere una frase o un’immagine, un tokenizzatore suddivide l’input in token e associa ciascuno a un ID intero; il modello recupera quindi un vettore di embedding per ogni ID. Il numero di token determina sia ciò che un modello può gestire sia quanto costa: una finestra di contesto si misura in token, i modelli linguistici di grandi dimensioni (LLMs) generano testo un token alla volta e le API commerciali applicano una tariffa per ogni token di input e output.

Token a confronto con tokenizzazione e termini correlati#

• Tokenizzazione: il processo che suddivide l’input grezzo in token. Un token è una singola unità dell’output.
• Vocabolario e ID dei token: il vocabolario di un tokenizer è l’insieme fisso dei token che conosce, ciascuno associato a un ID intero. BERT usa 30,522 token, GPT-2 50,257, Llama 3 128,256 e Gemma 3 circa 262,000.
• Token speciali: marcatori della struttura di una sequenza, come i token di inizio testo, fine testo e padding, oppure il token [CLS], il cui embedding finale viene usato da BERT per la classificazione.
• Embedding: i vettori appresi che il primo livello del modello recupera per ogni ID di token e che trasferiscono nella rete il significato del token.

Token testuali#

Un vocabolario di parole intere non può comprendere ogni nome, refuso e nuovo termine, mentre i singoli caratteri producono sequenze molto lunghe. Per questo, i tokenizer moderni usano sottoparole: le parole frequenti diventano token singoli e quelle rare vengono suddivise in parti riutilizzabili. Il byte pair encoding (BPE), adattato alla traduzione automatica neurale da Sennrich e colleghi nel 2016, parte dai singoli caratteri e unisce ripetutamente la coppia adiacente più frequente finché il vocabolario non raggiunge la dimensione desiderata. I modelli GPT applicano BPE ai byte, così è possibile codificare qualsiasi testo, compresi codice ed emoji; anche WordPiece (usato da BERT) e il modello Unigram di SentencePiece sono schemi correlati basati su sottoparole. Il tokenizer BPE di CLIP, caricato qui dall’Hub di Hugging Face, mostra come vengono suddivise le parole:

from transformers import AutoTokenizer

# Load CLIP's byte-pair-encoding (BPE) tokenizer from the Hugging Face Hub
tokenizer = AutoTokenizer.from_pretrained("openai/clip-vit-base-patch32")

for text in ["bus", "double-decker bus", "unhappiness", "Ultralytics"]:
    tokens = tokenizer.tokenize(text)
    print(f"{text!r} -> {tokens} -> {tokenizer.convert_tokens_to_ids(tokens)}")

"bus" è un unico token, ID 2840; "unhappiness" viene suddivisa in un e happiness, mentre la parola rara "Ultralytics" si divide in tre parti, ultr, aly e tics. Il suffisso </w> indica la fine di una parola nel vocabolario CLIP, composto da 49,408 token, e l’encoder testuale di CLIP legge al massimo 77 token per prompt.

Token visivi#

Il Vision Transformer (ViT), presentato nell’articolo An Image Is Worth 16x16 Words, suddivide un’immagine in patch di dimensioni fisse — 16 × 16 pixel in ViT-B/16 — e proietta ogni patch in un embedding, così un’immagine di 224 × 224 pixel diventa una sequenza di 196 token. Gli embedding posizionali registrano la provenienza di ogni patch e un token di classe aggiuntivo raccoglie informazioni per la classificazione. La proiezione viene di solito implementata come una convoluzione il cui passo è pari alla dimensione del kernel:

import torch

# ViT-B/16 patch embedding: a 16x16 convolution with stride 16 turns each patch into one 768-dim token
patch_embed = torch.nn.Conv2d(3, 768, kernel_size=16, stride=16)

for size in (224, 448):
    image = torch.rand(1, 3, size, size)
    tokens = patch_embed(image).flatten(2).transpose(1, 2)  # (batch, tokens, dims)
    print(f"{size}x{size} image -> {tuple(tokens.shape)}")

Un’immagine di 224 × 224 pixel produce 196 token da 768 valori; raddoppiando il lato a 448 pixel, i token diventano 784, cioè quattro volte tanti. La self-attention confronta ogni token con tutti gli altri: quadruplicando i token, il costo dell’attenzione aumenta quindi di circa sedici volte. Per questo i modelli ad alta risoluzione usano l’attenzione a finestre, come nello Swin Transformer, oppure combinano token simili con la fusione dei token.

I modelli visione-linguaggio passano i token visivi di un encoder di immagini a un LLM insieme ai token testuali, così un unico transformer presta attenzione a entrambi e genera la risposta un token testuale alla volta:

Perché il numero di token è importante#

• Limiti di contesto: il prompt, gli eventuali documenti o immagini recuperati e la risposta generata devono rientrare tutti nella finestra di contesto del modello.
• Costo e latenza: le API applicano tariffe distinte per i token di input e di output; il tempo di generazione aumenta con il numero di token in uscita, poiché per ciascuno serve un passaggio di decodifica che legge la cache KV del modello.
• Lingue e formati: i tokenizer addestrati principalmente sull’inglese suddividono le altre lingue, il codice e i numeri lunghi in più token per parola; lo stesso contenuto costa quindi di più e riempie prima la finestra di contesto.
• Attività a livello di carattere: un modello vede token di sottoparole, quindi le attività che dipendono dalle singole lettere, come contare le lettere di una parola o invertirla, gli risultano più difficili di quanto sembri.

Applicazioni nel mondo reale#

• Generazione di testo: un LLM assegna una probabilità a ogni token del proprio vocabolario, ne estrae uno, lo aggiunge alla sequenza e ripete il processo; metodi di campionamento come il campionamento nucleus selezionano i token più probabili.
• Generazione di immagini: i modelli di immagini autoregressivi prevedono token visivi discreti da un codebook appreso, creato tramite quantizzazione vettoriale, proprio come un LLM prevede le parole.
• Rilevamento a vocabolario aperto: YOLOE-26, la versione basata su YOLO26 del modello YOLOE dell’Università Tsinghua inclusa nel pacchetto Ultralytics, trova gli oggetti a partire dai nomi delle classi inseriti come testo. Il suo metodo set_classes() tokenizza ciascun nome con il tokenizer BPE di CLIP; l’encoder testuale MobileCLIP2 di Apple trasforma i token in un embedding e il modello confronta questi embedding con le regioni dell’immagine. In questo modo può rilevare dalle sole parole un "double-decker bus", una classe assente dal dataset COCO.