Capire la finestra di contesto

#Cosa contiene la finestra di contesto

Secondo la documentazione di Ollama, la lunghezza del contesto è il numero massimo di token a cui il modello ha accesso in memoria. Tutto si somma in questo unico budget: il messaggio di sistema, la cronologia della conversazione, i file o i brani di documenti che incolli, la tua ultima domanda e la risposta che il modello sta scrivendo. Per un modello di ragionamento, contano anche i token di riflessione. Quando il totale supera la finestra, qualcosa deve essere eliminato: gli strumenti generalmente troncano la parte iniziale oppure rifiutano la richiesta. Il modello non ha alcuna memoria al di fuori di questa finestra, a meno che un sistema esterno (riassunto, RAG) non gli reintroduca informazioni.

#Il token: l'unità che riempie la finestra

Un token non è una parola: è un frammento di testo definito dal tokenizer del modello, spesso una sillaba o una parola comune. Una parola rara o lunga ne occupa diversi. Il francese consuma in genere più token dell'inglese per un contenuto equivalente, perché la maggior parte dei tokenizer è addestrata soprattutto sull'inglese. Il rapporto esatto varia da modello a modello: invece di affidarti a una regola empirica, misura. L'API di Ollama restituisce prompt_eval_count, il numero di token del prompt, a ogni richiesta.

curl http://localhost:11434/api/generate -d '{"model":"qwen3:8b","prompt":"Bonjour le monde","stream":false}'
# lisez prompt_eval_count et eval_count dans la réponse JSON

Regola pratica

Una pagina A4 di testo fitto in francese corrisponde all’incirca a un migliaio di token, a seconda del tokenizer: verifica con prompt_eval_count sul tuo documento.

Un libro

Diverse centinaia di migliaia di token: fuori dalla portata di una finestra di 32.000 o 64.000 token senza suddivisione in parti.

Una risposta

Un modello di ragionamento può generare migliaia di token di riflessione prima della risposta visibile, che consumano la finestra.

#Quale dimensione della finestra scegliere

Ollama fissa il valore predefinito in base alla memoria video: circa 4 000 token (4k) sotto i 24 GiB di VRAM, 32k tra 24 e 48 GiB, 256k a partire da 48 GiB. La stessa pagina raccomanda almeno 64 000 token per i compiti che richiedono un contesto ampio, come la ricerca web, gli agenti e gli strumenti di programmazione. I modelli recenti dichiarano limiti massimi molto più elevati: il catalogo QuelLLM indica ad esempio circa 256 000 token per Kimi K2.5 e circa 1 milione per Kimi K3, DeepSeek V4 Flash e GLM 5.2. Ma un limite massimo dichiarato non equivale a un contesto utilizzabile sul tuo computer: i limiti della memoria, e talvolta della qualità, ne impediscono l'utilizzo.

Due insidie nel dimensionamento ricorrono spesso. Innanzitutto, la finestra deve contenere la risposta: se riempi 31.000 dei 32.000 token con un documento, non rimane quasi nulla per rispondere e un modello di ragionamento si fermerà nel bel mezzo della riflessione. Inoltre, in una conversazione, la cronologia cresce a ogni turno: una finestra sufficiente al primo messaggio può essere saturata al ventesimo. Prevedi quindi il caso peggiore del tuo utilizzo, non il caso medio, e lascia un margine di circa un quinto della finestra.

#Quanta memoria occupa il contesto

Ogni token presente nella finestra lascia in ogni layer del modello una chiave e un valore, memorizzati nella cache KV. Il costo per token si calcola a partire da quattro valori dell'architettura: il numero di layer, il numero di teste chiave-valore, la dimensione di una testa e la dimensione di un numero (2 byte in FP16). La formula è: 2 (chiave e valore) × layer × teste KV × dimensione della testa × 2 byte. Attenzione: sono le teste chiave-valore che contano, non le teste di attenzione, perché i modelli recenti ne condividono diverse (grouped-query attention). Il calcolo con le teste di attenzione sovrastima la cache di un fattore quattro per il modello qui sotto.

Prendiamo Qwen3-8B, la cui scheda ufficiale indica 36 strati e 8 teste chiave-valore (contro 32 teste di query), mentre la configurazione pubblica fissa la dimensione di una testa a 128. Il costo è di 2 × 36 × 8 × 128 × 2 = 147.456 byte per token, ovvero 144 KiB.

Due accorgimenti riducono la cache. Il primo è la quantizzazione della cache: la FAQ di Ollama indica che il tipo q8_0 consuma circa la metà della memoria del FP16 con una perdita molto ridotta, mentre q4_0 ne consuma circa un quarto con una perdita più evidente nei contesti lunghi; entrambi richiedono che Flash Attention sia attivata. Il secondo consiste nel ridurre la finestra a quanto ti serve. La nostra guida sulla cache KV descrive in dettaglio le impostazioni.

#Regolare la lunghezza del contesto

#Con Ollama

Ollama permette di impostare la lunghezza predefinita all'avvio del server, di cambiarla per una sessione o di specificarla richiesta per richiesta tramite l'API.

# Valeur par défaut pour tout le serveur
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Pour une session interactive
>>> /set parameter num_ctx 16384

# Pour un modèle personnalisé (Modelfile)
FROM qwen3:8b
PARAMETER num_ctx 16384

Dopo il caricamento, esegui ollama ps: la colonna CONTEXT mostra la lunghezza assegnata e la colonna PROCESSOR indica la distribuzione tra GPU e CPU. Se una parte passa alla CPU, riduci il contesto o scegli un modello più piccolo.

#In LM Studio

In LM Studio, la lunghezza del contesto si regola al caricamento del modello, nei parametri di caricamento. Cambiare il valore richiede di ricaricare il modello. Controlla la stima della memoria visualizzata prima di confermare.

#Una procedura di regolazione in quattro passaggi

1. 01
   Misurare il fabbisogno reale

   Invia il tuo documento o la tua cronologia tipica e leggi prompt_eval_count. Aggiungi la lunghezza della risposta attesa e quella della riflessione, se il modello ne produce.
2. 02
   Scegliere la finestra

   Scegli il valore più piccolo che possa contenere questo totale con un margine del 20%, almeno 64.000 token se utilizzi un agente o uno strumento di programmazione, come consiglia Ollama.
3. 03
   Verificare la memoria

   Carica il modello con questa finestra ed esegui ollama ps. Il processore deve indicare 100 % GPU; altrimenti, riduci la finestra, quantizza la cache o cambia modello.
4. 04
   Testare la capacità di recuperare le informazioni

   Inserisci un fatto preciso a metà di un lungo testo e chiedi al modello di riportarlo. Se il modello non lo trova, la finestra dichiarata supera quella che riesce effettivamente a sfruttare, e diventa necessario suddividere il testo o ricorrere a un RAG.

#Una grande finestra non vuol dire lettura fedele

Una ricerca del 2023, « Lost in the Middle », mostra che le prestazioni dei modelli possono degradarsi notevolmente in base alla posizione dell'informazione nel contesto: sono spesso migliori quando l'informazione si trova all'inizio o alla fine, e peggiorano quando si trova al centro, anche per modelli dichiarati capaci di gestire contesti lunghi. Il benchmark RULER, pubblicato nel 2024, va oltre: quasi tutti i modelli testati perdono molto in precisione quando la lunghezza aumenta, e solo la metà di loro mantiene un livello soddisfacente a 32.000 token, mentre tutti dichiaravano una capacità di 32.000 token o più.

Questi lavori riguardano modelli della loro epoca e non dicono nulla sui modelli del 2026, diversi dei quali sono addestrati specificamente per contesti lunghi. Ma le indicazioni da seguire restano valide: metti l'istruzione e i fatti critici all'inizio, ripeti la domanda alla fine e fai delle misurazioni sui tuoi documenti prima di fidarti di una finestra dichiarata di diverse centinaia di migliaia di token. Il test più semplice consiste nell'inserire un'informazione precisa nel mezzo di un lungo testo del tuo settore, per poi chiederla di nuovo: se il modello la ritrova a ogni tentativo, la finestra è utilizzabile per il tuo uso; se non la trova, riduci il testo inviato oppure suddividilo in parti.

#Quando il contenuto supera il limite

Riassumere man mano

Fai generare un riassunto dello scambio ogni pochi turni e riparti con questo riassunto all'inizio del contesto: perdi alcuni dettagli, ma mantieni il filo.

Dividere il documento

Un PDF lungo viene elaborato sezione per sezione, poi le risposte parziali vengono aggregate. La guida sul chunking illustra in dettaglio le dimensioni utili.

Passare a un RAG

Quando il corpus supera largamente la finestra, recuperi i pochi passaggi pertinenti invece di inviare tutto.

Scegliere un modello con contesto più ampio

Solo se la memoria lo permette: consulta il calcolo della cache KV più sopra prima di raddoppiare la finestra.

#Per approfondire

• Quantizzare la cache KV: risparmiare VRAM
• Token e tokenizzazione: capire cosa consuma un LLM
• Scegliere la quantizzazione (Q4, Q5, Q8, FP16)
• RAG: cos'è e come funziona
• Strategie di chunking
• Calcolatore VRAM

• Fonte: documentazione Ollama, lunghezza del contesto
• Fonte: FAQ Ollama (cache KV, Flash Attention)
• Fonte: Lost in the Middle (arXiv 2023)
• Fonte: RULER, benchmark per contesti lunghi (arXiv 2024)