Was das Context Window enthält
Modelle behalten zwischen Anfragen nichts; das Context Window ist ihr gesamter Arbeitsspeicher für einen Aufruf. Es ist mit Tokens gefüllt - im Englischen grob drei Viertel eines Worts je Token - und umfasst den System-Prompt, frühere Gesprächsrunden, für Retrieval bereitgestellte Dokumente und die Tokens, die das Modell als Antwort erzeugt. Übersteigt eine Aufgabe das Window, müssen die ältesten Tokens verworfen oder zusammengefasst werden - deshalb sind lange Agenten-Läufe und Aufgaben über große Codebasen durch die Context-Größe begrenzt. Aktuelle Open-Weight-Modelle, die wir betreiben, etwa MiniMax M2.7, bieten Windows von rund 192K Tokens.
Während der Inferenz wird der gesamte Eingabe-Context in der Prefill-Phase gelesen: Das Modell verarbeitet jedes Prompt-Token parallel, um seinen internen Zustand - den KV-Cache - aufzubauen, bevor es das erste Token ausgeben kann. Jedes im Decode erzeugte Token greift dann auf diesen gespeicherten Context zurück. Das Context Window ist also nicht nur eine Kapazitätsgrenze, sondern das, was bei jeder Anfrage verarbeitet wird - und seine Größe prägt direkt, wie die Anfrage performt.
Warum die Context-Länge Geschwindigkeit und Kosten treibt
Die Kosten des Context sind nicht linear. Der Attention-Mechanismus im Kern des Transformers vergleicht jedes Token mit jedem anderen, sodass die Arbeit im Prefill quadratisch mit der Prompt-Länge wächst: Ein Prompt mit 1.000 Tokens umfasst in der Größenordnung eine Million Attention-Interaktionen, 10.000 Tokens hingegen hundert Millionen. In der Praxis kann ein Prompt mit 128K Tokens mehrere Sekunden Prefill benötigen und einer mit einer Million Tokens Dutzende Sekunden, bevor ein einziges Ausgabe-Token erscheint. Deshalb sind Time-to-First-Token-Werte ohne die zugrunde liegende Eingabelänge bedeutungslos.
Context verbraucht außerdem Speicher, und Speicher ist die bindende Beschränkung bei der Generierung. Der KV-Cache hält Keys und Values für jedes Token im Window und wächst mit der Context-Länge - bei einem großen Dense-Modell kann er bei 128K Context zweistellige Gigabyte erreichen. Diesen Cache samt Modell-Weights für jedes erzeugte Token erneut zu lesen, ist ein Memory-Bandbreiten-Problem, kein Rechenproblem - weshalb bei langem Context die GPU-Auslastung einbricht und speicherzentrierte Hardware am meisten hilft. Verfahren wie PagedAttention verwalten den Cache effizienter, um mehr Long-Context-Anfragen gleichzeitig bedienbar zu machen.
Context-Angaben kritisch lesen
Ein groß beworbenes Context Window heißt nicht, dass ein Modell es ganz - oder schnell - nutzt. Zwei Anbieter, die dasselbe Modell mit demselben nominalen Window betreiben, können sich stark unterscheiden, wie schnell sie einen langen Prompt prefillen und wie sauber sie unter Last skalieren - Unterschiede, die eine Schlagzeilen-Zahl verbirgt. Wenn Context für Ihren Workload zählt, vergleichen Sie die Prefill-Zeit bei Ihrer realen Eingabelänge und die anhaltende Ausgabe-Geschwindigkeit, nicht nur das maximale Window. Auf unserer EU-Infrastruktur läuft Prefill auf Dataflow-Hardware, die Daten on-chip hält und so die Wartezeit verkürzt, die ein langer Prompt vor dem ersten Token erzeugt.
Quellen
Verwandte Begriffe
Prefill vs. Decode
Die zwei Phasen der LLM-Inferenz - parallele Prompt-Verarbeitung vs. Token-für-Token-Generierung.
TTFT (Zeit bis zum ersten Token)
Wie lange ein Nutzer zwischen dem Absenden einer Anfrage und dem Erscheinen des ersten Tokens der Antwort wartet.
Token pro Sekunde
Die Standardeinheit für die LLM-Generierungsgeschwindigkeit - und warum dieselbe Zahl zwei verschiedene Dinge bedeuten kann.
Sehen Sie diese Metriken live auf unserer EU-Infrastruktur gemessen - echte Zahlen von Produktionshardware, unabhängig verifiziert.