Das Kontextfenster ist die Obergrenze dafür, wie viele Tokens ein Modell auf einmal „sehen" kann: der Prompt, der Gesprächsverlauf, abgerufene Dokumente und die bereits erzeugte Antwort des Modells – alles der Reihe nach in einer einzigen Sequenz. Es bestimmt die Größe der Werkbank des Modells, nicht seine Intelligenz. In ein Fenster von 1M Tokens passen tausende Seiten Dokumente – doch das heißt nicht, dass das Modell jede Seite auch wirklich nutzen kann.
Was steckt eigentlich in einem Kontextfenster?
Im Fenster liegen keine Dateien, sondern Tokens. Prompt, Gesprächsverlauf, abgerufene Textstücke und Tool-Ausgaben werden in Tokens zerlegt und der Reihe nach in dieselbe Sequenz gepackt; das Modell unterscheidet „vorher" und „nachher" nur über Positionskodierungen – ein Konzept von „Ordnern" kennt es nicht. 1M Tokens entsprechen grob 750.000 englischen Wörtern, also deutlich über tausend Seiten Dokumenten. Doch Vorsicht: Das heißt nur „es passt hinein", nicht „es wird behalten".
Die versteckte Rechnung des Aufmerksamkeitsmechanismus
Das Modell liest diese Sequenz mit Self-Attention: Für jedes neue Token wird die Relevanz zu jedem einzelnen vorherigen Token berechnet, der Rechenaufwand wächst also quadratisch mit der Sequenzlänge – doppelte Länge, vierfacher Aufwand im Attention-Teil. Die größere Rechnung ist der KV-Cache: Die Key- und Value-Vektoren jedes Tokens müssen während der Inferenz im GPU-Speicher resident bleiben, um Neuberechnungen zu vermeiden. Am Beispiel Llama-3.1-8B: etwa 128KB Cache pro Token – bei 128K Kontext also rund 16GB, bei 1M Tokens rund 128GB VRAM. „Fenster verdoppeln" ist nie gratis: Es frisst VRAM, verzögert die erste Antwort und treibt die Preise für Long-Context-API-Aufrufe nach oben.
Es passt hinein – warum findet das Modell es dann nicht?
Die Rechnung bezahlen zu können heißt nicht, sie gut zu nutzen. Die Aufmerksamkeitsgewichte werden per Softmax normiert, ihre Summe ist immer 1: Je mehr Tokens, desto dünner verteilt sich die Aufmerksamkeit auf jedes einzelne. Das Stanford-Experiment „Lost in the Middle" (2023) zeigte das anschaulich: Steht die entscheidende Information am Anfang oder Ende des Kontexts, findet das Modell sie schnell und treffsicher; versteckt man sie in der Mitte, kann die Trefferquote um über 20 Prozentpunkte fallen – schlechter, als gar keinen Kontext zu geben. Die größere Kluft steckt in der Art, wie wir testen: „Needle in a Haystack" prüft nur, ob ein Satz gefunden wird – das bestehen fast alle Modelle mit Bestnote. Doch NVIDIAs RULER-Benchmark stellt auf realistische Aufgaben wie Multi-Hop-Verfolgung und Aggregation um, und nur die Hälfte der Modelle, die 32K versprechen, bleibt bei 32K Länge auf akzeptablem Niveau. Zwischen nominellem und effektivem Fenster liegen oft mehrere Faktoren.
Drei weit verbreitete Missverständnisse
Missverständnis 1: Größeres Fenster heißt, das Modell merkt sich mehr. Das Fenster ist eine Werkbank, keine Festplatte. Ein größeres Fenster fügt dem „Langzeitwissen" in den Modellparametern nichts hinzu – es lässt das Modell nur mehr Material auf einmal ausbreiten. Ist das Gespräch zu Ende und das Fenster geleert, „merkt" sich das Modell nichts; gesprächsübergreifendes Gedächtnis kommt von externen Mechanismen wie Retrieval-Augmented Generation.
Missverständnis 2: Langer Kontext macht RAG überflüssig. Eine ganze Wissensdatenbank ins Fenster zu kippen ist teuer und langsam: Eingabe-Tokens werden nach Volumen abgerechnet, und Latenz bis zum ersten Token sowie VRAM-Verbrauch kosten bei ultralangen Kontexten echtes Geld. Die gängige Praxis macht das Gegenteil – erst mit semantischer Suche auf die relevantesten Passagen filtern, dann im Fenster genau lesen; für Fragen, deren Antwort über mehrere Dokumente zusammengesetzt werden muss, gibt es strukturierte Verfahren wie GraphRAG. Langes Fenster und Retrieval sind Partner, keine Gegner.
Missverständnis 3: Tokenzahl gleich effektives Gedächtnis. Bei Aufgaben, die wirkliches Schlussfolgern verlangen, kann die effektive Länge eines nominell mit 1M Tokens beworbenen Modells nur ein Bruchteil davon sein – „hineinpassen" und „gut nutzen" sind zwei Paar Schuhe. Wenn Sie das nächste Mal die Zahl auf einer Modellkarte sehen, fragen Sie eins weiter: Wie viel Genauigkeit bleibt bei der Länge, die meine Aufgabe braucht?
Wie man die Fenstergröße-Zahl richtig liest
Zuerst die Aufgabe: Ein paar Verträge lesen oder ein Code-Repository analysieren – dafür reichen meist einige zehn K bis 128K. Bei Q&A über den ganzen Korpus liegt der Engpass meist in der Retrieval-Qualität, nicht in der Fensterobergrenze. Dann die Effektivität: In Long-Context-Benchmarks wie RULER oder LongBench die reale Leistung bei der Ziellänge prüfen, nicht nur das beworbene Maximum. Und schließlich die Kosten: Eingabe-Tokens für lange Kontexte kosten mehr pro Token, und der KV-Cache begrenzt die Parallelität – das Fenster ist nicht besser, weil es größer ist, sondern dann richtig, wenn es in ausreichender Länge am stabilsten läuft und am wenigsten kostet.
