Cosa contiene il Context Window
I modelli linguistici non conservano memoria tra le richieste; il Context Window è la loro intera memoria di lavoro per una singola chiamata. È riempito di token - in inglese circa tre quarti di parola ciascuno - e comprende il prompt di sistema, eventuali turni precedenti di una conversazione, i documenti forniti per il retrieval e i token che il modello genera in risposta. Quando un compito supera il window, i token più vecchi devono essere scartati o riassunti - ecco perché le lunghe esecuzioni di agenti e i compiti su grandi codebase sono limitati dalla dimensione del context. I modelli Open-Weight attuali che serviamo, come MiniMax M2.7, offrono window di circa 192K token.
Durante l'inferenza l'intero context di input viene letto nella fase di prefill, dove il modello elabora ogni token del prompt in parallelo per costruire il suo stato interno - la KV-cache - prima di poter emettere il primo token. Ogni token generato durante il decode attinge poi a quel context memorizzato. Il Context Window non è quindi solo un limite di capacità; è ciò che viene elaborato a ogni richiesta, e la sua dimensione plasma direttamente le prestazioni della richiesta.
Perché la lunghezza del context guida velocità e costo
Il costo del context non è lineare. Il meccanismo di attention al cuore del transformer confronta ogni token con ogni altro token, quindi il lavoro nel prefill scala quadraticamente con la lunghezza del prompt: un prompt di 1.000 token comporta nell'ordine di un milione di interazioni di attention, mentre 10.000 token ne comportano cento milioni. In termini di produzione, un prompt di 128K token può richiedere diversi secondi di prefill, e un prompt di un milione di token decine di secondi, prima che compaia un singolo token di output. Ecco perché i valori di time to first token sono privi di significato senza la lunghezza dell'input che li sottende.
Il context consuma anche memoria, e la memoria è il vincolo determinante durante la generazione. La KV-cache mantiene le keys e i values per ogni token nel window e cresce con la lunghezza del context - per un grande modello dense può raggiungere decine di gigabyte con un context di 128K. Rileggere quella cache più i pesi del modello per ogni token generato è un problema di larghezza di banda della memoria, non di calcolo - ecco perché la generazione a context lungo è dove l'utilizzo delle GPU tende a crollare e dove l'hardware incentrato sulla memoria aiuta di più. Metodi come PagedAttention gestiscono la cache in modo più efficiente per aumentare quante richieste a context lungo un sistema può servire contemporaneamente.
Leggere criticamente le dichiarazioni sul context
Un Context Window ampiamente pubblicizzato non significa che un modello lo utilizzi tutto bene, o velocemente. Due provider che servono lo stesso modello con lo stesso window nominale possono differire nettamente per quanto velocemente eseguono il prefill di un prompt lungo e per quanto elegantemente degradano sotto carico - differenze che un numero da titolo nasconde. Quando il context conta per il tuo workload, confronta il tempo di prefill alla tua reale lunghezza di input e la velocità di output sostenuta, non solo il window massimo. Sulla nostra infrastruttura EU, il prefill gira su hardware dataflow progettato per mantenere i dati on-chip, riducendo l'attesa che un prompt lungo impone prima che compaia il primo token.
Fonti
Termini correlati
Prefill vs. Decode
Le due fasi dell'inferenza LLM - elaborazione parallela del prompt vs. generazione token per token.
TTFT (Time to First Token)
Quanto tempo un utente attende tra l'invio di una richiesta e la visualizzazione del primo token della risposta.
Token al Secondo
L'unità standard per la velocità di generazione degli LLM - e perché lo stesso numero può significare due cose diverse.
Guarda queste metriche misurate dal vivo sulla nostra infrastruttura EU - numeri reali da hardware di produzione, verificati in modo indipendente.