Puntata 210
Puntata 210 — Context window estesa
Livello: 🧙 Maestro Yoda · Capitolo 19 · Architetture
Nel 2018 il contesto era 512 token. Nel 2026 è 2 milioni. Non perché siamo diventati più bravi a fare attention — ma perché abbiamo imparato a fingere che lo siamo.
Cos’è il context, davvero
Il context window è il massimo numero di token che il modello può vedere in input + output durante una singola chiamata.
Nel 2018: 512. Nel 2026: 200k è “minimo decente”, 1-2M è frontiera, 10M è in fase di ricerca.
Ma “context lunga” non è un singolo dato di targa. È un insieme di metriche:
- Lunghezza massima accettata — quanto puoi metterci dentro senza errore (claim del paper).
- Lunghezza in cui funziona davvero — quanto puoi metterci prima che la qualità crolli (effective context).
- Costo per token al crescere del context — economia, non solo capacità.
- Latenza al crescere del context — ms per token al variare di
n.
I provider amano comunicare la prima. Il vero stato dell’arte sta nelle altre tre.
I tre colli di bottiglia
1. Compute: O(n²) della self-attention
Il dot product QK^T è una matrice n × n. Per n = 1M è un terabyte di valori, non gestibile esplicitamente.
Soluzioni:
- FlashAttention (Dao 2022/2023/2024) — tiling/streaming, niente materializzazione. Vedi puntata 208.
- Linear attention / SSM / Mamba — complessità lineare via approssimazione (vedi 205).
- Local + global attention — Longformer, BigBird: ogni token vede solo una finestra locale, più alcuni token globali.
- Sparse attention — Sliding window, dilated, strided.
2. KV cache: O(n) in memoria per ogni generation step
Durante l’inferenza autoregressive, devi tenere in memoria K e V di tutti i token già visti, per ogni layer, per ogni testa.
Per Llama-3 70B a 128k context con GQA: ~20-30 GB di KV cache da sola, per un singolo utente. Per 100 utenti contemporanei in chat: insostenibile.
Soluzioni:
- GQA, MLA, MQA (vedi 208) — riduzione strutturale della KV cache.
- Quantization della KV cache (8-bit, 4-bit, 2-bit) — meno memoria a costo di qualità.
- Compression: KV cache pruning, eviction policy (StreamingLLM, H2O, SnapKV) — eliminare token “vecchi”.
- Paged Attention (vLLM) — gestione tipo paging del sistema operativo per condividere memoria fra utenti.
3. Qualità: “il modello legge davvero?”
Il vero scandalo del context lungo. Test classici:
Needle in a Haystack (NIAH): nascondi un fatto specifico (“Marco è nato a Treviso”) in 500k token di rumore, chiedi al modello di estrarlo. I migliori modelli del 2024 hanno fatto >95% accuracy. Nel 2026 si fanno test multi-needle, multi-hop, e i risultati sono più mediocri.
RULER (Hsieh et al., 2024): benchmark a 13 task su context lunghi. Mostra che molti modelli “1M-context” cominciano a degradare drasticamente già a 32k–64k token.
LongBench, ZeroSCROLLS, InfiniteBench: benchmark suite specifici.
Risultato osservato: c’è un gap strutturale fra “lunghezza dichiarata” e “lunghezza effettiva”. Tipicamente l’effettiva è 1/2 - 1/4 della dichiarata.
Storia delle estensioni: 8 mosse chiave
- Sparse attention (Longformer 2020, BigBird 2020): sliding window + token globali. Primo salto a 4-16k.
- FlashAttention (2022): cambia il costo della long-context attention da insostenibile a tollerabile.
- RoPE + scaling (2023): Linear Interpolation, NTK-aware, YaRN, LongRoPE. Estende modelli pretrainati a 32k, 128k senza retrain costoso. Vedi puntata 207.
- Continued pretraining su long-context data (2023-24): training su sequenze realmente lunghe (anziché solo scaling tricks). Llama-3.1 a 128k, DeepSeek-V3.
- Gemini 1.5 (2024): 1M token effettivi con qualche test pulito. Mistura di Ring Attention (Liu et al.), MoE, e training su dataset specifici long-context.
- Sliding Window Attention + Global tokens (Mistral, Gemma 2): pattern ibrido in cui solo alcuni layer fanno full attention.
- State Space hybrids (Jamba, Samba 2024): Mamba per il bulk, attention solo per i lookup chirurgici.
- In-context retrieval / RAG nativi (2025): il modello impara a “cercare” dentro il context invece di leggere linearmente. Cohere Command-A, Phi-4.
Stato dell’arte (maggio 2026)
| Modello | Context max | Effettivo (RULER-like) | Note |
|---|---|---|---|
| GPT-5 | 400k | ~200k buoni | input + output combinati |
| Claude 4.7 Opus | 200k (1M Enterprise) | ~120k buoni | very strong NIAH |
| Gemini 2.5 Pro | 2M | ~500k buoni | leader assoluto su long-context |
| Llama-4 | 128k | ~80k buoni | open weight |
| DeepSeek V3 | 128k (con YaRN) | ~90k buoni | open, training cheap |
| Mistral Large 2 | 128k | ~70k buoni | open |
| Cohere Command-A | 256k | ~150k buoni | nativo per RAG |
| Phi-4 | 128k | ~80k buoni | piccolo ma chirurgico |
Numeri da prendere con cautela: benchmark evolvono velocemente e claim commerciali sono ottimisti.
Trade-off: 1M context non è sempre quello che vuoi
Tentazione classica: “non faccio RAG, butto tutto il PDF da 800 pagine nel context”. Problemi:
- Costo lineare in $. Anche con prezzi crollati, 500k token di input × ogni query = budget che evapora.
- Latenza first-token alta. Non solo si genera output lentamente: il prefill di un context da 500k token è 10-30 secondi. Inaccettabile per chat interattiva.
- Quality variabile. Il modello “perde le cose nel mezzo” (Lost in the Middle, Liu et al. 2023): performa meglio su info all’inizio e alla fine del context. Mid-context è il punto debole.
- Caching aiuta solo se la prima parte è stabile. Se il documento cambia ogni volta, niente cache.
Pattern saggio del 2026: RAG resta vincente per la maggior parte dei task aziendali. Context lungo è la scelta giusta quando:
- Il documento è davvero piccolo (50k-100k) e cambia ogni volta.
- Servono relazioni globali che la chunking distrugge (analisi narrativa di un libro, dipendenze in un codebase).
- Latenza non è critica (analisi batch).
Tecniche di runtime
Anche con un modello da 1M context, la pratica reale richiede ottimizzazioni:
- Prompt caching: caching del prefisso (es. system prompt + documenti) per riusarlo fra chiamate. Anthropic, OpenAI, Google offrono prompt caching con sconti del 50-90%.
- Streaming context: per audio/video infinito, si fa “rolling window” del context — droppando i token più vecchi mano a mano. StreamingLLM (Xiao et al., 2024) ha mostrato come fare in modo robusto.
- Memoria esterna: invece di context lungo nativo, esponi al modello un tool di lookup su memory store esterno (vedi 272).
- Hierarchical summarization: pre-comprimi sezioni del documento in summary, esponi solo le summary + chunk rilevanti.
Glossario lampo
- Effective context length — la lunghezza in cui il modello mantiene qualità accettabile, tipicamente < lunghezza dichiarata.
- NIAH — Needle In A Haystack, benchmark per testare se il modello legge davvero il context.
- Prefill — la prima fase dell’inferenza in cui il modello processa il prompt prima di iniziare a generare. Dominata dal context length.
- TTFT — Time To First Token. Diventa il bottleneck con context lunghi.
TEST hands-on
- Scegli un modello con context dichiarato 128k (es. Llama-3.1-8B-Instruct via Ollama o un’API). Costruisci un prompt di ~80k token con un singolo “ago” (fatto specifico) nascosto a metà.
- Chiedi al modello di estrarre il fatto. Funziona? Prova varando la posizione dell’ago: inizio, metà, fine.
- Costruisci poi una versione multi-needle (3 fatti distribuiti) e chiedi al modello di estrarli tutti. Conta il recall.
- Misura TTFT e tokens/sec a context 1k, 8k, 32k, 80k. Confronta. Vedrai il prefill esplodere.
- Bonus: prova lo stesso esperimento con Gemini 2.5 Pro su un context di 1M token usando l’API gratuita. Riesce a recuperare l’ago? E quanto costa in dollari quella singola chiamata?
Take-away
“Context da 1 milione di token” è la nuova versione di “100 mega di RAM, ti basterà per sempre”. È vero per molti casi pratici, è inadeguato per quelli ambiziosi, è economicamente sostenibile solo per i privilegiati. Il vero stato dell’arte non è “quanto entra”, è “quanto il modello legge davvero, in quanto tempo, a che costo”.
➡️ Prossima puntata: Reasoning models a livello architetturale — o-series, deep thinking, e perché pensare costa.