Was im Context Window steht
Sprachmodelle behalten zwischen zwei Requests nichts im Gedächtnis. Das Context Window ist ihr gesamter Arbeitsspeicher für einen Aufruf. Es füllt sich mit Token, im Englischen etwa drei Viertel eines Worts pro Token. Dazu gehören der System-Prompt, frühere Runden eines Gesprächs, für das Retrieval bereitgestellte Dokumente und die Token, die das Modell als Antwort erzeugt. Übersteigt eine Aufgabe das Context Window, müssen die ältesten Token entfallen oder zusammengefasst werden. Deshalb begrenzt die Kontextgröße lange Agenten-Läufe und Aufgaben in großen Codebasen. Aktuelle Open-Weight-Modelle, die wir betreiben, etwa MiniMax M2.7, bieten Context Windows von rund 192K Token.
Bei der Inferenz wird der gesamte Eingabekontext in der Prefill-Phase gelesen. Dabei verarbeitet das Modell jedes Token des Prompts parallel und baut seinen internen Zustand auf, den KV-Cache. Erst danach kann es das erste Token ausgeben. Jedes Token, das im Decode entsteht, greift anschließend über die Attention auf diesen gespeicherten Kontext zurück. Das Context Window ist also nicht nur eine Kapazitätsgrenze. Es ist genau das, was bei jedem Request verarbeitet wird, und seine Größe bestimmt direkt, wie schnell der Request läuft.
Warum die Kontextlänge Geschwindigkeit und Kosten bestimmt
Die Kosten des Kontexts wachsen nicht linear. Der Attention-Mechanismus im Kern des Transformers vergleicht jedes Token mit jedem anderen. Die Arbeit im Prefill wächst deshalb quadratisch mit der Länge des Prompts: Ein Prompt mit 1000 Token bedeutet in der Größenordnung eine Million Attention-Vergleiche, einer mit 10.000 Token hundert Millionen. Im Produktionsbetrieb kann das Prefill eines Prompts mit 128K Token mehrere Sekunden dauern, bei einer Million Token Dutzende Sekunden. Erst danach erscheint das erste Ausgabe-Token. Deshalb sind Werte für die Zeit bis zum ersten Token ohne die Eingabelänge dahinter bedeutungslos.
Kontext verbraucht außerdem Speicher, und Speicher ist bei der Generierung der Engpass. Der KV-Cache hält die Keys und Values für jedes Token im Context Window und wächst mit der Kontextlänge. Bei einem großen Dense-Modell kann er bei 128K Kontext mehrere Dutzend Gigabyte erreichen. Diesen Cache und die Modellgewichte für jedes erzeugte Token erneut zu lesen, ist ein Problem der Speicherbandbreite, nicht der Rechenleistung. Deshalb bricht die Auslastung von GPUs bei langem Kontext oft ein, und genau dort hilft speicherzentrierte Hardware am meisten. Verfahren wie PagedAttention verwalten den Cache effizienter, damit ein System mehr Requests mit langem Kontext gleichzeitig bedienen kann.
Angaben zum Kontext kritisch lesen
Ein großes beworbenes Context Window heißt nicht, dass ein Modell es vollständig oder schnell nutzt. Zwei Anbieter, die dasselbe Modell mit demselben nominellen Context Window betreiben, können sich stark unterscheiden: darin, wie schnell sie einen langen Prompt verarbeiten, und darin, wie stabil sie unter Last bleiben. Eine plakative Zahl verdeckt diese Unterschiede. Wenn der Kontext für Ihren Workload zählt, vergleichen Sie die Prefill-Zeit bei Ihrer realen Eingabelänge und die dauerhafte Ausgabegeschwindigkeit, nicht nur das maximale Context Window. Auf unserer EU-Infrastruktur läuft das Prefill auf Dataflow-Hardware, die Daten auf dem Chip hält. Das verkürzt die Wartezeit bis zum ersten Token, die ein langer Prompt verursacht.
Quellen
Sehen Sie diese Metriken live gemessen auf unserer EU-Infrastruktur: echte Werte von Produktionshardware, unabhängig verifiziert.
Live-Benchmarks ansehen