Christoph Kind LogoCHRISTOPH KIND
Das Context Window verstehen: Wie LLMs mit langen Kontexten umgehen

Das Context Window verstehen: Wie LLMs mit langen Kontexten umgehen

Artikel-Übersicht

In diesem Beitrag dreht sich alles um das Context Window – das Arbeitsgedächtnis von Sprachmodellen. Du lernst:

  • Was das Context Window ist und wie es mit Tokens zusammenhängt
  • Wie groß Kontextfenster 2026 sind – von 128k bis über 1 Million Token, mit konkreten Modellbeispielen
  • Wie lange Kontexte technisch möglich werden: Self-Attention und ihre O(n²)-Skalierung, Positionskodierung mit RoPE und RoPE-Skalierung, sowie effiziente Attention
  • Warum der KV-Cache lange Kontexte teuer und langsam macht – inklusive Kosten- und Latenzfolgen
  • Das "Lost in the Middle"-Phänomen: Warum Infos in der Mitte schlechter genutzt werden
  • Den Unterschied zwischen Kontextfenster und effektiv nutzbarem Kontext (Needle-in-a-Haystack-Tests)
  • Praktische Strategien: Kontext kuratieren, Prompt-Caching, RAG statt „alles reinkippen", und die richtige Positionierung wichtiger Infos

Am Ende findest du eine kompakte Zusammenfassung mit praktischen Tipps und echte Ressourcen zum Weiterlesen. Los geht's! 🚀

Einleitung: Das Gedächtnis, das keine Erinnerung ist

Stell dir vor, du sprichst mit einer extrem klugen Kollegin, die ein perfektes Kurzzeitgedächtnis hat – aber nur für genau das, was gerade vor ihr auf dem Tisch liegt. Sobald ein Blatt vom Tisch fällt, ist es für sie nicht mehr existent. Genau so funktioniert ein Large Language Model (LLM): Alles, worüber es „nachdenken" kann, muss gleichzeitig auf seinem Tisch liegen. Dieser Tisch heißt Context Window (Kontextfenster).

Das Faszinierende: Diese Tische sind in den letzten Jahren riesig geworden. Wo Modelle 2022 noch mit ein paar tausend Token auskamen, jonglieren manche Modelle 2026 mit über einer Million Token – das sind grob 750.000 Wörter oder mehrere dicke Romane auf einmal. Klingt nach „Problem gelöst, einfach alles reinkippen"? Leider nein. Größere Kontextfenster bringen eigene Tücken mit: Kosten, Latenz und das überraschende Phänomen, dass Modelle ausgerechnet die Mitte ihres Kontexts gerne übersehen.

In diesem Beitrag schauen wir gemeinsam unter die Haube. Du musst kein Mathe-Genie sein – ich erkläre alles mit Analogien, kleinen Tabellen und Code-Schnipseln. Danach verstehst du nicht nur, was das Context Window ist, sondern auch, warum es sich so verhält, wie es sich verhält, und vor allem, wie du es in deinen eigenen Projekten optimal einsetzt.

Was ist das Context Window eigentlich?

Das Context Window ist die maximale Menge an Text (genauer: Token), die ein Modell gleichzeitig verarbeiten kann – Eingabe (Prompt) und Ausgabe (Antwort) zusammengenommen. Es ist die harte Obergrenze des „Arbeitsspeichers" für eine einzelne Anfrage.

Drei Dinge sind dabei wichtig zu verstehen:

  1. LLMs sind zustandslos. Das Modell „erinnert" sich nicht an frühere Gespräche. Bei jedem Aufruf schickst du den gesamten relevanten Verlauf erneut mit. Was nicht im Context Window steht, existiert für das Modell nicht.
  2. Das Fenster teilen sich Input und Output. Wenn ein Modell 200.000 Token Kontext hat und du 190.000 Token Eingabe schickst, bleiben nur noch ~10.000 für die Antwort. Manche Anbieter trennen ein separates Output-Limit (z. B. 64k oder 128k) vom Gesamtfenster ab.
  3. Es ist kein Langzeitgedächtnis. Für dauerhaftes Wissen braucht es andere Mechanismen – etwa eine Datenbank, ein Memory-Tool oder Retrieval (dazu später mehr).

Eine schöne Analogie: Das Context Window ist wie der Schreibtisch, der Trainingsdatensatz ist wie das studierte Wissen im Kopf, und eine externe Datenbank ist wie das Archiv im Keller. Das Modell kann nur mit dem arbeiten, was auf dem Schreibtisch liegt – auch wenn im Kopf und im Keller noch viel mehr steckt.

Tokens: Die Währung des Context Windows

Modelle lesen keine Wörter, sondern Token. Ein Token ist ein Textbaustein – mal ein ganzes Wort, mal eine Silbe, mal nur ein Satzzeichen. Der Tokenizer zerlegt deinen Text in diese Bausteine.

Als grobe Faustregel für Englisch gilt: 1 Token ≈ 4 Zeichen ≈ 0,75 Wörter. Für Deutsch liegt der Wert etwas ungünstiger, weil unsere Komposita („Donaudampfschifffahrtsgesellschaft") und Umlaute in mehr Token zerfallen. Ein paar Beispiele:

Text ungefähre Tokenzahl
„Hallo Welt" 2–3 Token
Ein durchschnittlicher Satz (20 Wörter) ~27 Token
Eine A4-Seite Text ~500–650 Token
Ein 300-seitiges Buch ~150.000 Token
Eine große Codebase (mittleres Repo) 500.000+ Token

Warum ist das wichtig? Weil alles in Token bezahlt und limitiert wird. Die Kontextgröße wird in Token angegeben, die API-Preise sind pro Million Token, und das „Lost in the Middle"-Problem hängt an Token-Positionen. Wer mit LLMs arbeitet, sollte ein Gefühl für Tokenzahlen entwickeln.

Wichtig: Schätze Tokenzahlen nicht mit fremden Tokenizern. Jedes Modell tokenisiert anders. Tools wie tiktoken (von OpenAI) zählen für andere Modelle falsch – bei Code oder nicht-englischem Text teils deutlich. Nutze die offizielle Token-Zähl-Funktion deines Anbieters, etwa den count_tokens-Endpunkt:

from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("dokument.md").read()}],
)
print(resp.input_tokens)  # exakte Tokenzahl für genau dieses Modell

Wie groß sind Kontextfenster 2026?

Die Entwicklung der letzten Jahre ist atemberaubend. Hier eine Momentaufnahme gängiger Modelle Mitte 2026 (Kontextgrößen ändern sich schnell – prüfe immer die offizielle Doku des Anbieters):

Modell Context Window Besonderheit
Claude Opus 4.8 / Sonnet 4.6 1.000.000 Token 1M zum Standardpreis, kein Long-Context-Aufschlag
Claude Haiku 4.5 200.000 Token schnelles, günstiges Modell
Gemini 3 Pro 1.000.000 Token (Input) bis 64k Output
Gemini 3.1 Pro bis 2.000.000 Token kontext-gestaffelte Preise
GPT-5.4 272k Standard, bis 1M (API) 2× Preisaufschlag oberhalb 272k
Grok 4 2.000.000 Token größtes zuverlässiges Produktions-Window via API
Llama 4 Scout bis 10.000.000 Token experimentell, riesiges Window

Mit Stand Mitte 2026 liefern über ein Dutzend Frontier-Modelle Fenster von 1 Million Token und mehr. Der Trend ist klar: 128k gilt heute fast schon als „Standard", 1M ist der neue Premium-Bereich, und einzelne Modelle experimentieren mit zwei- bis zehnstelligen Millionen-Fenstern.

Aber – und das ist die entscheidende Botschaft dieses Artikels – die beworbene Fenstergröße ist nicht dasselbe wie der effektiv nutzbare Kontext. Ein 1M-Fenster bedeutet nicht, dass das Modell auf Position 743.219 genauso zuverlässig liest wie auf Position 12. Dazu kommen wir gleich. Erst einmal: Warum ist es überhaupt so schwierig, große Fenster zu bauen?

Wie lange Kontexte technisch möglich werden: Self-Attention und O(n²)

Das Herzstück moderner LLMs ist der Transformer und seine Self-Attention. Vereinfacht gesagt: Damit das Modell den Kontext „versteht", schaut jedes Token auf jedes andere Token und gewichtet, wie relevant es ist. Wenn du das Wort „sie" liest, muss das Modell herausfinden, auf welches frühere Substantiv sich „sie" bezieht – Attention macht genau das.

Hier liegt das fundamentale Problem: Wenn jedes der n Token mit jedem anderen Token verglichen wird, entstehen n × n Vergleiche. Die Rechenkomplexität wächst also quadratisch – in der Informatik notiert als O(n²).

Was das praktisch bedeutet, zeigt diese Tabelle:

Kontextlänge relative Attention-Rechenlast
1.000 Token 1× (Basis)
10.000 Token 100×
100.000 Token 10.000×
1.000.000 Token 1.000.000×

Verdoppelst du den Kontext, vervierfachst du (grob) den Aufwand der Attention-Schicht. Ein 1M-Kontext ist gegenüber einem 1k-Kontext nicht 1.000-mal, sondern theoretisch eine Million Mal aufwendiger in diesem Schritt. Genau deshalb waren riesige Kontextfenster lange technisch und wirtschaftlich unmöglich – und deshalb ist es ingenieurtechnisch eine echte Leistung, dass es sie heute überhaupt gibt.

Positionskodierung und RoPE: Reihenfolge ins Spiel bringen

Es gibt ein zweites, subtileres Problem. Self-Attention behandelt Token zunächst wie eine ungeordnete Menge – „die Katze jagt den Hund" und „den Hund jagt die Katze" wären für sie identisch. Das Modell braucht also eine Möglichkeit, die Position jedes Tokens zu kennen.

Die heute dominierende Technik heißt RoPE (Rotary Position Embedding). Die elegante Idee: Statt Positionsinformationen separat dazuzuaddieren, rotiert RoPE die Query- und Key-Vektoren um einen Winkel, der von der Position abhängt. Dadurch wird die relative Position zweier Token direkt in das Attention-Skalarprodukt eingebaut – ohne zusätzliche trainierbare Parameter und ohne die Attention-Formel zu verkomplizieren. Man kann es sich wie ein Uhrwerk vorstellen: Jede Position dreht den Zeiger ein Stückchen weiter, und das Modell „liest" am Winkel ab, wie weit zwei Wörter auseinanderliegen.

Das Problem: Ein Modell, das auf z. B. 8.000 Token trainiert wurde, hat diese Rotationswinkel nie für Position 500.000 gesehen. Schickt man ihm einen viel längeren Kontext, gerät es ins Straucheln – die Winkel werden zu „fremd".

Hier kommt RoPE-Skalierung ins Spiel. Verfahren wie NTK-aware scaling und YaRN (Yet another RoPE extensioN) strecken bzw. interpolieren die RoPE-Frequenzen klug, sodass das Modell ein viel längeres Fenster nutzen kann, oft mit nur kurzem Nachtraining. YaRN skaliert dabei nicht nur die Frequenzen, sondern auch die Query- und Key-Tensoren selbst, um hochfrequente Informationen zu erhalten, die bei naiver Skalierung verloren gingen. Das Schöne: Diese Anpassung kostet bei fester Fenstergröße keinen zusätzlichen Rechen- oder Speicheraufwand. So entstehen aus „8k-Modellen" nachträglich „128k-" oder „1M-Modelle".

Effiziente Attention: Tricks gegen die O(n²)-Wand

Wenn die naive Attention quadratisch skaliert, wie schafft man dann 1M-Fenster zu vertretbaren Kosten? Über eine ganze Werkzeugkiste effizienterer Attention-Verfahren. Ohne zu tief einzusteigen, die wichtigsten Ideen:

  • FlashAttention: Berechnet die exakte Attention, aber speicheroptimiert. Statt die riesige n×n-Matrix komplett im Speicher zu materialisieren, wird sie blockweise verarbeitet. Das spart Speicher und ist deutlich schneller – ohne Qualitätsverlust.
  • Sparse / Sliding-Window-Attention: Nicht jedes Token muss auf alle anderen schauen. Oft reicht ein Fenster aus naheliegenden Token plus einige globale „Anker". Das senkt die Komplexität in Richtung linear.
  • Grouped-Query / Multi-Query-Attention (GQA/MQA): Mehrere Attention-Köpfe teilen sich dieselben Keys und Values. Das reduziert vor allem den Speicherbedarf des KV-Caches (gleich mehr dazu) drastisch.
  • Lineare und State-Space-Ansätze (z. B. Mamba-artige Modelle): Versuchen, Attention durch Mechanismen zu ersetzen, die linear mit der Länge skalieren.

Wichtig zu wissen: Long-Context-Inferenz ist in der Praxis weniger rechen- als speicher- und IO-gebunden. Der eigentliche Engpass ist oft nicht das Rechnen selbst, sondern das Hin- und Herschaufeln von Daten im Speicher – und das führt uns direkt zum KV-Cache.

Der KV-Cache: Warum lange Kontexte teuer und langsam sind

Hier ist die zentrale Erkenntnis, warum lange Kontexte in der Praxis Geld und Zeit kosten. LLMs generieren Text Token für Token. Für jedes neue Token müssten sie eigentlich die Attention über den gesamten bisherigen Kontext neu berechnen. Das wäre absurd teuer. Die Lösung: der KV-Cache (Key-Value-Cache).

Beim Verarbeiten des Kontexts berechnet das Modell für jedes Token einen Key- und einen Value-Vektor. Diese werden gespeichert (gecacht), damit sie bei der Generierung jedes weiteren Tokens nur noch gelesen statt neu berechnet werden müssen. Praktisch – aber dieser Cache wächst linear mit der Kontextlänge und frisst GPU-Speicher.

Eine vereinfachte Vorstellung: Pro Token im Kontext muss das Modell für jede Schicht und jeden Attention-Kopf einen Key- und Value-Vektor vorhalten. Bei großen Modellen und 1M Token summiert sich das schnell auf zig Gigabyte – nur für den Cache einer einzigen Anfrage. Das hat zwei direkte Folgen:

  1. Speicher ist der Flaschenhals. Der KV-Cache konkurriert mit den Modellgewichten um den knappen, teuren GPU-Speicher. Je länger der Kontext, desto weniger Anfragen passen gleichzeitig auf eine GPU – die Hardwarekosten pro Anfrage steigen.
  2. Latenz steigt mit der Länge. Je größer der Cache, desto mehr Daten müssen pro generiertem Token gelesen werden. Die „Time to First Token" (bis die erste Antwort kommt) und die Gesamtlatenz wachsen mit dem Kontext.

Genau hier setzen Optimierungen wie GQA/MQA und KV-Cache-Kompression an: Sie verkleinern den Cache und machen lange Kontexte überhaupt erst bezahlbar.

Kosten und Latenz: Die Rechnung in der Praxis

Übersetzen wir das in Euro und Sekunden. Du zahlst pro Token – und zwar getrennt für Input und Output. Ein paar reale Größenordnungen (Stand Mitte 2026, Preise je Million Token):

Modell Input $/1M Output $/1M
Claude Opus 4.8 $5,00 $25,00
Claude Sonnet 4.6 $3,00 $15,00
Claude Haiku 4.5 $1,00 $5,00

Jetzt das Gedankenexperiment: Du baust einen Chat-Assistenten und schickst bei jeder Nutzeranfrage den kompletten 200.000-Token-Verlauf mit. Bei Claude Sonnet 4.6 sind das pro Anfrage allein 0,60 $ nur für den Input – und das vor der Antwort. Bei 1.000 Anfragen am Tag sind das 600 $ täglich, nur fürs Wiederholen desselben Kontexts.

Zwei Lehren daraus:

  • Mehr Kontext = mehr Geld und mehr Wartezeit. „Einfach alles reinkippen" ist die teuerste und langsamste aller Optionen.
  • Wiederholter Kontext lohnt sich zu cachen. Genau das macht Prompt-Caching (gleich erklärt) – es kann die Kosten für den wiederkehrenden Teil um bis zu ~90 % senken.

Eine kleine Vorab-Schätzung hilft, böse Überraschungen zu vermeiden:

# grobe Input-Kostenschätzung vor dem eigentlichen Aufruf
tokens = 200_000
preis_pro_token = 3.00 / 1_000_000   # Sonnet 4.6 Input
print(f"Geschätzte Input-Kosten: {tokens * preis_pro_token:.2f} $")
# Geschätzte Input-Kosten: 0.60 $

„Lost in the Middle": Warum die Mitte verloren geht

Jetzt kommt das vielleicht überraschendste Phänomen. Selbst wenn eine Information technisch im Kontextfenster steht, heißt das nicht, dass das Modell sie auch zuverlässig nutzt. Forschung hat ein klares Muster gezeigt: Modelle achten stärker auf den Anfang und das Ende des Kontexts als auf die Mitte. Das nennt man „Lost in the Middle".

Das Muster ähnelt einer U-Kurve: Eine gesuchte Information am Anfang oder am Ende des Prompts wird sehr gut gefunden, in der Mitte deutlich schlechter. In Untersuchungen zeigen Modelle bei Informationen in der Position 30–70 % typischerweise einen Genauigkeitsabfall von 5–15 Punkten, bei 128k Kontext schwankt die positionsabhängige Trefferquote sogar um 10–25 %. Ein wesentlicher Mittäter ist die RoPE-bedingte Positions-Abschwächung über große Distanzen.

Die Analogie aus dem echten Leben: Wenn du eine 50-seitige Präsentation überfliegst, bleiben dir die erste und die letzte Folie am ehesten im Gedächtnis. Was auf Folie 27 stand? Schwierig. LLMs „ticken" hier erstaunlich menschlich.

Die praktische Konsequenz ist riesig: Wo du eine Information im Prompt platzierst, beeinflusst, wie gut sie genutzt wird. Die wichtigsten Anweisungen und das relevanteste Material gehören an den Anfang oder ans Ende – nicht vergraben in der Mitte eines Mega-Prompts.

Kontextfenster vs. effektiv nutzbarer Kontext

Damit sind wir beim Kern der Sache: Es gibt einen Unterschied zwischen dem beworbenen Kontextfenster und dem effektiv nutzbaren Kontext.

Wie misst man das? Mit Needle-in-a-Haystack-Tests („Nadel im Heuhaufen"). Man versteckt einen spezifischen Fakt (die Nadel) an verschiedenen Positionen in einem langen, ansonsten irrelevanten Text (dem Heuhaufen) und fragt das Modell danach. Variiert man Position und Kontextlänge, entsteht eine „Landkarte" der Zuverlässigkeit.

Die guten Nachrichten: Top-Modelle sind hier stark geworden. GPT-4.1 bewarb 100 % Recall an beliebiger Position bis 1M Token, Claude 3 meldete 99+ % auf einer verschärften Variante, Gemini 1.5 Pro erreichte 99,7 % Recall bis 1M Token.

Die wichtige Einschränkung: Der einfache Einzel-Nadel-Test ist zu leicht. Reale Aufgaben sind „Multi-Needle" – das Modell muss mehrere verstreute Infos finden und kombinieren, oft samt Schlussfolgerungen. Genau das zeigen anspruchsvollere Benchmark-Familien wie RULER, LongBench oder Multi-Needle-Suiten: Einzel-Nadel-Werte überschätzen die echte Produktionsleistung um 15–40 Punkte.

Test-Typ Was er misst Aussagekraft
Single-Needle (NIAH) eine Info finden optimistisch, oft ~100 %
Multi-Needle mehrere Infos finden realistischer, deutlich niedriger
RULER / LongBench finden + kombinieren + schlussfolgern am nächsten an der Praxis

Merksatz: Ein 1M-Kontextfenster bedeutet nicht 1M zuverlässig nutzbaren Kontext. Behandle die beworbene Zahl als Obergrenze, nicht als Versprechen. ✅

Praktische Strategien: Den Kontext klug einsetzen

Genug Theorie – wie nutzt du das alles? Hier die wichtigsten Hebel, grob nach Wirkung sortiert.

1. Relevanten Kontext kuratieren, nicht alles reinkippen. Der größte Fehler ist, aus Bequemlichkeit den kompletten Datenbestand in den Prompt zu werfen. Das ist teuer, langsam und verschlechtert wegen „Lost in the Middle" oft sogar die Qualität. Weniger, aber gezielter Kontext schlägt fast immer „mehr ist mehr".

2. RAG statt Brute Force. Bei Retrieval-Augmented Generation (RAG) speicherst du dein Wissen in einer (Vektor-)Datenbank und holst pro Anfrage nur die wirklich relevanten Stücke in den Kontext. Statt 500.000 Token Doku schickst du die 3.000 Token, die zur Frage passen. Das ist günstiger, schneller und meist präziser. Ein riesiges Kontextfenster und RAG sind übrigens keine Gegner – die besten Systeme nutzen RAG, um den Kontext mit dem Wesentlichen zu füllen.

3. Wichtiges an Anfang und Ende platzieren. Wegen der U-Kurve: Setze die Kernfrage, die zentralen Anweisungen und das wichtigste Material an den Rand des Prompts. Eine bewährte Struktur:

[System / Rolle und Kernregeln]      ← Anfang: stark beachtet
[Hintergrunddokumente, Beispiele]    ← Mitte: weniger beachtet
[Die eigentliche, präzise Frage]     ← Ende: stark beachtet

4. Prompt-Caching nutzen. Wenn du denselben großen Kontext (System-Prompt, Wissensbasis, Few-Shot-Beispiele) über viele Anfragen wiederverwendest, cache ihn. Das senkt die Kosten des wiederkehrenden Teils drastisch (Cache-Lesezugriffe kosten oft nur ~10 % des normalen Preises) und reduziert die Latenz. Wichtig: Caching ist ein Präfix-Match – schon ein geändertes Byte am Anfang (etwa ein Zeitstempel im System-Prompt) macht den Cache ungültig. Halte den stabilen Teil also wirklich stabil und vorne:

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": grosser_stabiler_kontext,   # einmal gecacht ...
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "Die variable Frage hier"}],  # ... bleibt günstig
)
# Treffer prüfen:
print(response.usage.cache_read_input_tokens)  # > 0 = Cache wurde genutzt

5. Strukturieren statt verklumpen. Klare Abschnitte, Überschriften und Auszeichnungen (z. B. XML-artige Tags oder Markdown) helfen dem Modell, sich im langen Kontext zu orientieren. Ein gut strukturierter 50k-Prompt schlägt einen unstrukturierten Textblock derselben Länge.

6. Bei sehr langen Dialogen komprimieren. Wenn ein Gespräch das Fenster zu sprengen droht, fasse ältere Teile zusammen (Compaction) oder entferne veraltete Tool-Ergebnisse (Context Editing), statt blind den ganzen Verlauf mitzuschleppen.

Das Kontextfenster in der Praxis

Zwei Stellen, an denen die Theorie unmittelbar auf den Alltag trifft.

Bei lokalen Modellen ist das Kontextfenster eine Speicherentscheidung. Ollama setzt den Wert standardmäßig deutlich niedriger, als das Modell könnte — aus gutem Grund, denn der Zwischenspeicher für den Kontext wächst mit der Länge und kann bei großen Fenstern mehr Platz belegen als die Modellgewichte selbst. Erhöhen lässt er sich über einen Parameter:

PARAMETER num_ctx 32768

Wer das tut, ohne den verfügbaren Speicher zu prüfen, bekommt kein Fehlerbild, sondern eine Anwendung, die plötzlich zäh wird — weil ein Teil der Berechnung auf den Prozessor ausgelagert wird. Die Rechnung dazu steht in Welches Ollama-Modell? Auswahl nach Hardware und Zweck.

Bei Coding-Assistenten ist das Kontextfenster die eigentliche Begrenzung. Wenn ein Assistent in einem großen Projekt „den Zusammenhang nicht versteht", liegt das selten am Modell und fast immer daran, dass nur ein Ausschnitt des Projekts im Kontext liegt. Was hineingelegt wird, entscheidet das Werkzeug — deshalb unterscheiden sich Assistenten hier deutlich, obwohl sie dasselbe Modell benutzen.

Ein verwandter Punkt, der überrascht: Jeder angebundene Werkzeugserver legt seine Werkzeugbeschreibungen ebenfalls in den Kontext. Bei vielen gleichzeitig bleibt für die eigentliche Aufgabe weniger übrig — ohne dass eine Fehlermeldung erscheint. Wie sich das bemerkbar macht, steht in MCP-Server einrichten.

Zusammenfassung und praktische Tipps

Fassen wir zusammen – das Context Window ist das Arbeitsgedächtnis eines LLM, gemessen in Token, geteilt zwischen Ein- und Ausgabe. 2026 reichen Fenster von 128k bis über 1M (vereinzelt mehr) Token. Möglich wird das durch Self-Attention (mit ihrer teuren O(n²)-Skalierung), Positionskodierung via RoPE samt RoPE-Skalierung (NTK-aware, YaRN) und effiziente Attention-Verfahren wie FlashAttention und GQA. Der KV-Cache macht die Generierung schnell, frisst aber Speicher und treibt damit Kosten und Latenz. Und selbst wenn alles ins Fenster passt: „Lost in the Middle" sorgt dafür, dass die Mitte schlechter genutzt wird – beworbenes Fenster ≠ effektiv nutzbarer Kontext.

Deine Mitnehm-Checkliste:

  • Denke in Token und schätze mit dem richtigen Tokenizer (z. B. count_tokens).
  • Kuratiere den Kontext – weniger, aber relevanter, schlägt „alles reinkippen".
  • Nutze RAG für große Wissensbestände statt Brute-Force-Kontext.
  • Platziere Wichtiges an Anfang und Ende des Prompts.
  • Cache wiederkehrenden Kontext (stabiler Präfix vorne!).
  • Strukturiere lange Prompts klar mit Abschnitten und Überschriften.
  • Vertraue Benchmarks mit Vorsicht: Single-Needle überschätzt die Praxis; schau auf Multi-Needle/RULER.
  • Plane Kosten und Latenz ein: Lange Kontexte sind mächtig, aber nicht gratis.

Das Context Window ist eines der spannendsten und praktisch relevantesten Konzepte, wenn du mit LLMs baust. Wer es versteht, baut günstigere, schnellere und vor allem klügere Anwendungen. Viel Spaß beim Ausprobieren! 😊

Ressourcen