Verstehen der Fenster von Kontext

#Was das Kontextfenster enthält

Laut der Dokumentation von Ollama ist die Kontextlänge die maximale Anzahl an Tokens, auf die das Modell im Speicher zugreifen kann. Alles zählt zu diesem einen Budget: die Systemnachricht, der Gesprächsverlauf, die Dateien oder Dokumentpassagen, die Sie einfügen, Ihre letzte Frage und die Antwort, die das Modell gerade schreibt. Bei einem Reasoning-Modell zählen auch die Denktokens mit. Wenn die Gesamtzahl das Kontextfenster überschreitet, muss etwas wegfallen: Die Tools kürzen in der Regel den Anfang oder lehnen die Anfrage ab. Das Modell hat kein Gedächtnis außerhalb dieses Fensters, es sei denn, ein externes System (Zusammenfassung, RAG) führt ihm erneut Informationen zu.

#Das Token: die Einheit, die das Fenster füllt

Ein Token ist kein Wort: Es ist ein Textfragment, das vom Tokenizer des Modells definiert wird, oft eine Silbe oder ein häufiges Wort. Ein seltenes oder langes Wort benötigt mehrere Tokens. Französisch verbraucht für gleichwertige Inhalte im Allgemeinen mehr Tokens als Englisch, weil die meisten Tokenizer hauptsächlich auf englischen Texten trainiert wurden. Das genaue Verhältnis variiert von Modell zu Modell: Verlassen Sie sich nicht auf eine Faustregel, sondern messen Sie nach. Die API von Ollama gibt bei jeder Anfrage prompt_eval_count zurück, die Anzahl der Tokens im Prompt.

curl http://localhost:11434/api/generate -d '{"model":"qwen3:8b","prompt":"Bonjour le monde","stream":false}'
# lisez prompt_eval_count et eval_count dans la réponse JSON

Faustregel

Eine A4-Seite mit dichtem französischem Text entspricht je nach Tokenizer ungefähr tausend Tokens: Überprüfen Sie dies mit prompt_eval_count anhand Ihres eigenen Dokuments.

Ein Buch

Mehrere Hunderttausend Tokens: Ohne Aufteilung passt das nicht in ein Kontextfenster von 32.000 oder 64.000 Tokens.

Eine Antwort

Ein Reasoning-Modell kann vor der sichtbaren Antwort Tausende von Denktokens erzeugen, die Platz im Kontextfenster beanspruchen.

#Welche Kontextfenstergröße wählen?

Ollama legt seinen Standardwert je nach Grafikspeicher fest: etwa 4 000 Tokens (4k) bei weniger als 24 GiB VRAM, 32k zwischen 24 und 48 GiB und 256k ab 48 GiB. Dieselbe Seite empfiehlt mindestens 64 000 Tokens für Aufgaben, die einen großen Kontext erfordern, wie Websuche, Agenten und Coding-Tools. Neuere Modelle weisen deutlich höhere Maximalwerte aus: Der Katalog von QuelLLM gibt beispielsweise etwa 256 000 Tokens für Kimi K2.5 und etwa 1 Million für Kimi K3, DeepSeek V4 Flash und GLM 5.2 an. Aber ein angegebener Maximalwert ist kein auf Ihrem Computer nutzbarer Kontext: Der Speicher und manchmal auch die Qualität stehen dem entgegen.

Bei der Dimensionierung treten häufig zwei Fallstricke auf. Erstens muss auch die Antwort in das Kontextfenster passen: Wenn Sie 31.000 der 32.000 Tokens mit einem Dokument belegen, bleibt kaum Platz für die Antwort, und ein Reasoning-Modell stoppt mitten im Denkprozess. Zweitens wächst in einem Gespräch der Verlauf mit jeder Runde: Ein Kontextfenster, das für die erste Nachricht ausreicht, kann bei der zwanzigsten bereits voll sein. Planen Sie daher für den ungünstigsten Fall Ihrer Nutzung, nicht für den Durchschnitt, und halten Sie etwa ein Fünftel des Kontextfensters als Reserve frei.

#Wie viel Speicher kostet der Kontext?

Jedes Token im Kontextfenster hinterlässt in jeder Schicht des Modells einen Schlüssel und einen Wert, die im KV-Cache gespeichert werden. Der Speicherbedarf pro Token lässt sich aus vier Architekturgrößen berechnen: der Anzahl der Schichten, der Anzahl der Schlüssel-Wert-Heads, der Dimension eines Heads und der Speichergröße einer Zahl (2 Bytes bei FP16). Die Formel lautet: 2 (Schlüssel und Wert) × Schichten × KV-Heads × Head-Dimension × 2 Bytes. Achtung: Entscheidend sind die Schlüssel-Wert-Heads, nicht die Attention-Heads, da sich bei neueren Modellen mehrere Attention-Heads dieselben Schlüssel-Wert-Heads teilen (grouped-query attention). Eine Berechnung mit der Anzahl der Attention-Heads überschätzt den Cache beim untenstehenden Modell um den Faktor vier.

Nehmen wir Qwen3-8B: Die offizielle Modellbeschreibung nennt 36 Schichten und 8 Key-Value-Heads (gegenüber 32 Query-Heads), und die öffentlich verfügbare Konfiguration legt die Dimension eines Heads auf 128 fest. Der Speicherbedarf beträgt 2 × 36 × 8 × 128 × 2 = 147.456 Byte pro Token, also 144 KiB.

Zwei Maßnahmen verkleinern den Cache. Die erste ist die Quantisierung des Caches: Laut Ollamas FAQ benötigt der Typ q8_0 etwa halb so viel Speicher wie FP16 bei sehr geringem Qualitätsverlust, q4_0 etwa ein Viertel bei einem deutlicheren Qualitätsverlust mit großen Kontexten. Beide setzen voraus, dass Flash Attention aktiviert ist. Die zweite Maßnahme besteht darin, das Kontextfenster auf die benötigte Größe zu verkleinern. Unser Leitfaden zum KV-Cache erläutert die Einstellungen im Detail.

#Die Kontextlänge einstellen

#Unter Ollama

Ollama ermöglicht es, die Standardlänge beim Start des Servers festzulegen, sie für eine Sitzung zu ändern oder sie pro Anfrage über die API anzugeben.

# Valeur par défaut pour tout le serveur
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Pour une session interactive
>>> /set parameter num_ctx 16384

# Pour un modèle personnalisé (Modelfile)
FROM qwen3:8b
PARAMETER num_ctx 16384

Führen Sie nach dem Laden ollama ps aus: Die Spalte CONTEXT zeigt die zugewiesene Länge an, und die Spalte PROCESSOR gibt die Verteilung zwischen GPU und CPU an. Wenn ein Teil auf der CPU läuft, reduzieren Sie den Kontext oder wählen Sie ein kleineres Modell.

#Unter LM Studio

In LM Studio wird die Kontextlänge beim Laden des Modells in den Ladeeinstellungen festgelegt. Eine Änderung des Werts erfordert, das Modell neu zu laden. Achten Sie vor der Bestätigung auf die angezeigte Speicherschätzung.

#Ein vierstufiger Einstellungsprozess

1. 01
   Den tatsächlichen Bedarf messen

   Senden Sie Ihr Dokument oder Ihren typischen Gesprächsverlauf und lesen Sie prompt_eval_count ab. Rechnen Sie die erwartete Antwortlänge hinzu sowie die Länge der Denkphase, falls das Modell eine solche erzeugt.
2. 02
   Fenster auswählen

   Wählen Sie den kleinsten Wert, der diese Gesamtmenge mit 20 % Reserve abdeckt. Wenn Sie einen Agenten oder ein Programmierwerkzeug verwenden, wählen Sie mindestens 64.000 Tokens, wie von Ollama empfohlen.
3. 03
   Speicher prüfen

   Laden Sie das Modell mit diesem Kontextfenster und führen Sie ollama ps aus. Die Prozessoranzeige muss 100 % GPU anzeigen; andernfalls verkleinern Sie das Fenster, quantisieren Sie den Cache oder wechseln Sie zu einem anderen Modell.
4. 04
   Den Abruf von Informationen testen

   Platzieren Sie eine präzise Information in der Mitte eines langen Textes und fragen Sie nach dieser Information. Wenn das Modell sie nicht findet, ist das angegebene Kontextfenster größer als der Bereich, den es tatsächlich nutzt. Dann ist eine Aufteilung des Textes oder ein RAG erforderlich.

#Ein großes Kontextfenster bedeutet nicht, dass Inhalte zuverlässig gelesen werden

Eine Studie aus dem Jahr 2023 mit dem Titel „Lost in the Middle“ zeigt, dass die Leistung von Modellen je nach Position der Information im Kontext deutlich abnehmen kann: Sie ist oft besser, wenn die Information am Anfang oder am Ende steht, und verschlechtert sich, wenn sie in der Mitte liegt, selbst bei Modellen, die mit einem langen Kontext beworben werden. Der 2024 veröffentlichte Benchmark RULER geht noch weiter: Fast alle getesteten Modelle verlieren bei zunehmender Länge deutlich an Genauigkeit, und nur die Hälfte von ihnen hält bei 32.000 Tokens ein zufriedenstellendes Niveau, obwohl für alle 32.000 Tokens oder mehr angekündigt waren.

Diese Arbeiten beziehen sich auf Modelle ihrer Zeit und sagen nichts über die Modelle von 2026 aus, von denen mehrere speziell für lange Kontexte trainiert wurden. Die empfohlene Vorgehensweise bleibt jedoch gültig: Platzieren Sie die Anweisung und die entscheidenden Fakten am Anfang, wiederholen Sie die Frage am Ende und führen Sie Messungen mit Ihren Dokumenten durch, bevor Sie sich auf ein angegebenes Kontextfenster von mehreren Hunderttausend Tokens verlassen. Der einfachste Test besteht darin, eine konkrete Information in der Mitte eines langen Textes aus Ihrem Fachgebiet unterzubringen und anschließend erneut danach zu fragen: Findet das Modell sie bei jedem Versuch, ist das Kontextfenster für Ihren Einsatzzweck nutzbar; findet es sie nicht, verkürzen Sie den übermittelten Text oder teilen Sie ihn in Abschnitte auf.

#Wenn der Inhalt überläuft

Fortlaufend zusammenfassen

Lassen Sie alle paar Gesprächsrunden eine Zusammenfassung des Austauschs erstellen und setzen Sie das Gespräch mit dieser Zusammenfassung am Anfang des Kontexts fort: Sie verlieren Details, behalten aber den roten Faden.

Das Dokument aufteilen

Ein langes PDF wird Abschnitt für Abschnitt verarbeitet, anschließend werden die Teilantworten zusammengeführt. Der Leitfaden zum Chunking erläutert die geeigneten Größen.

Wechsel zu RAG

Wenn das Korpus deutlich größer als das Kontextfenster ist, werden die wenigen relevanten Passagen abgerufen, statt das gesamte Korpus zu übermitteln.

Ein Modell mit größerem Kontext auswählen

Nur wenn genügend Speicher vorhanden ist: Ziehen Sie die obige Berechnung des KV-Caches heran, bevor Sie das Kontextfenster verdoppeln.

#Weiterführende Informationen

• KV-Cache quantisieren: VRAM sparen
• Tokens und Tokenisierung: Verstehen, was ein LLM verbraucht
• Quantisierung wählen (Q4, Q5, Q8, FP16)
• Was ist RAG und wie funktioniert es?
• Chunking-Strategien
• VRAM-Rechner

• Quelle: Ollama-Dokumentation, Kontextlänge
• Quelle: Ollama-FAQ (KV-Cache, Flash Attention)
• Quelle: Lost in the Middle (arXiv 2023)
• Quelle: RULER, Benchmark für langen Kontext (arXiv 2024)