Wichtigste Erkenntnisse
- Llama 4 Scout (MoE) unterstützt bis zu 10M Token. DeepSeek V4-Flash und Qwen 3.6 unterstützen 1M bzw. 256K Token (bis 1M via YaRN erweiterbar). Mai 2026 markiert die erste Generation millionentoken-fähiger Open-Source-Modelle.
- Praktischer Kontext nach Modellgröße: 7B-8B-Modelle liefern zuverlässige Qualität bei 16K-32K Token. 70B+ und MoE-Modelle erweitern dies auf 256K-1M Token. Llama 4 Scout kann volle Millionen-Token-Kontexte auf ausreichend VRAM verarbeiten.
- RAM skaliert sowohl mit Kontextlänge als auch Modellgröße. Qwen 3.6 27B bei Q4_K_M benötigt ~22 GB bei 128K, ~65+ GB bei 1M Token.
- Lost in the Middle gilt weiterhin: LLMs verpassen Details aus mittleren Abschnitten des Kontexts. Abhilfe: wichtige Informationen an den Anfang stellen, RAG für Suche nutzen oder in überlappenden Blöcken verarbeiten.
- Langer Kontext eignet sich für holistische Analyse vollständiger Dokumente (Codebasen, Verträge, Bücher). RAG eignet sich für suchintensive Aufgaben über viele Dokumente.
- Ollama nutzt standardmäßig 2048 Token -- nicht 128K oder 1M. num_ctx explizit in einer Modelfile setzen.
Was ist die Kontextlänge und warum ist sie für lokale LLMs wichtig?
Die Kontextlänge ist die maximale Anzahl von Token, die ein Modell in einem einzigen Inferenz-Aufruf verarbeiten kann -- die kombinierte Größe von Eingabe (Dokument, Gesprächsverlauf, Systemprompt) und Ausgabe (Modellantwort). Ein Token ≈ 0,75 Wörter auf Deutsch; 128K Token ≈ 96.000 Wörter.
Für lokale LLM-Anwendungen ermöglicht langer Kontext: Zusammenfassung ganzer Bücher oder langer Berichte, Analyse vollständiger Codebasen in einem Prompt, Verarbeitung stundenlanger Meeting-Transkripte und Pflege langer Gesprächsverläufe ohne Verlust früherer Inhalte.
Der entscheidende Unterschied liegt zwischen der beworbenen Kontextlänge (was die Modellarchitektur unterstützt) und der praktischen Kontextlänge (wo die Qualität zuverlässig bleibt). Ein Modell kann technisch 128K Token unterstützen, aber bei Informationen ab dem 100K-Token-Mark Qualitätseinbußen zeigen.
Welche lokalen LLMs unterstützen 128K-Token-Kontext im Jahr 2026?
| Modell | Kontextfenster | Praktisches Limit | Ollama-Befehl |
|---|---|---|---|
| Llama 3.1 8B | 128K | ~32K zuverlässig | ollama run llama3.2 |
| Llama 3.2 3B | 128K | ~16K zuverlässig | ollama run llama3.2:3b |
| Llama 3.3 70B | 128K | ~64K zuverlässig | ollama run llama3.3:70b |
| Qwen2.5 7B | 128K | ~32K zuverlässig | ollama run qwen2.5:7b |
| Qwen2.5 72B | 128K | ~64K zuverlässig | ollama run qwen2.5:72b |
| Mistral Small 3.1 24B | 128K | ~32K zuverlässig | ollama run mistral-small3.1 |
| Gemma 2 2B | 8K | ~6K zuverlässig | ollama run gemma2:2b |
| Mistral 7B v0.3 | 32K | ~16K zuverlässig | ollama run llama3.2 |
Wie viel RAM benötigt die Verarbeitung langer Kontexte?
Der RAM-Verbrauch skaliert sowohl mit Modellgröße als auch Kontextlänge. Der KV-Cache speichert Attention-Zustände für alle verarbeiteten Token -- dieser wächst linear mit der Kontextlänge.
Ein 7B-Modell bei Q4_K_M mit 4K-Kontext benötigt ~6 GB RAM. Dasselbe Modell mit 32K-Kontext benötigt ~8-9 GB RAM. Bei 128K-Kontext: ~12-16 GB RAM.
| Modell | 4K-Kontext | 32K-Kontext | 128K-Kontext |
|---|---|---|---|
| Llama 3.1 8B Q4_K_M | ~6 GB | ~9 GB | ~14 GB |
| Qwen2.5 14B Q4_K_M | ~9 GB | ~12 GB | ~18 GB |
| Mistral Small 3.1 24B Q4_K_M | ~14 GB | ~17 GB | ~24 GB |
| Llama 3.3 70B Q4_K_M | ~40 GB | ~45 GB | ~55 GB |
Warum ist der praktische Kontext kürzer als das beworbene Maximum?
LLMs mit RoPE-Positionscodierungen (verwendet von Llama, Qwen, Mistral) können technisch Token bis zur maximalen Kontextlänge verarbeiten, aber die Qualität verschlechtert sich in einem bekannten Muster namens "Lost in the Middle"-Effekt.
LLMs nutzen am besten Informationen am Anfang und Ende des Kontextfensters. Informationen in der Mitte eines sehr langen Kontexts werden weniger zuverlässig abgerufen. Ein Modell mit 128K-Fenster beantwortet zuverlässig Fragen zu Inhalten in den ersten 32K Token und letzten 16K Token, verfehlt aber Details im 40K-80K-Bereich.
Praktische Zuverlässigkeitslimits nach Modellgröße: 3B-Modelle ≈ 8K-16K; 7B-8B-Modelle ≈ 16K-32K; 70B-Modelle ≈ 64K zuverlässig.
Lange Kontextfenster ermöglichen mehr Eingabe, aber die Promptstruktur bestimmt, ob das Modell diesen Kontext effektiv nutzt. Techniken wie RAG und Prompt-Chaining finden Sie im Prompt-Engineering-Leitfaden.
Wie setzt man die Kontextlänge in Ollama?
Ollama nutzt standardmäßig 2048 Token Kontext. So nutzt man das volle Kontextfenster eines Modells:
Die Kontextfenstergröße bestimmt, wie viel Text ein Modell verarbeiten kann. Für eine Erklärung, warum Modelle frühere Eingaben vergessen, siehe Kontextfenster erklärt.
# Set context length at runtime
ollama run llama3.2 --ctx 32768
# Or create a custom model with a Modelfile
cat << EOF > Modelfile
FROM llama3.1:8b
PARAMETER num_ctx 32768
EOF
ollama create llama3.1-32k -f Modelfile
ollama run llama3.1-32k
Lange Kontextfenster lokaler LLMs: Regionaler Kontext
EU / DSGVO + KI-Gesetz: Das EU-KI-Gesetz (gültig ab Februar 2025) klassifiziert KI-Systeme, die personenbezogene Daten im Großmaßstab verarbeiten, als potenziell hochriskant. Lokale Langkontext-Inferenz für die Analyse von Rechtsdokumenten, Zusammenfassung von Krankenakten oder HR-Dokumentenverarbeitung fällt in diese Risikostufe. Lokales Ausführen eliminiert das Drittanbieter-Datenprozessor-Risiko nach DSGVO Art. 28.
Für BSI-Compliance bei lokaler Dokumentenverarbeitung: Ein 7B-Modell bei Q4_K_M mit 32K-Kontext (~9-10 GB RAM auf Standard-Workstation) bietet zuverlässige Qualität für bis zu 50-seitige Dokumente bei vollständigem Datenschutz. Llama 3.1 8B und Mistral Small 3.1 sind die empfohlenen EU-Compliance-Optionen.
Für CNIL-Richtlinien zur KI und personenbezogenen Daten: Lokale Inferenz via Ollama ohne externe API-Aufrufe erfüllt die Anforderung, dass Daten nicht ohne gültige Rechtsgrundlage durch Drittanbieter verarbeitet werden.
Japan (METI): Japanische Dokumente benötigen 1,5-2× mehr Token als äquivalente englische Dokumente. Qwen2.5's nativer Tokenizer verarbeitet japanischen Text 30-40% effizienter als Llama.
China: Unter Chinas Datensicherheitsgesetz erfordert die Verarbeitung sensibler Dokumente durch Cloud-APIs zusätzliche Compliance. Lokale Inferenz via Qwen2.5 hält alle Daten On-Premises. Qwen2.5 ist für chinesische Dokumente 30-40% token-effizienter als Llama.
Häufige Fehler bei langen Kontextfenstern in lokalen LLMs
- Annahme, dass 128K-Kontext genauso gut wie 4K funktioniert: Der "Lost in the Middle"-Effekt bedeutet, dass Informationen von vor 30K-80K Token weniger zuverlässig abgerufen werden. Lange Dokumente in 16K-32K-Abschnitte aufteilen.
- Ollamas Standard-Kontextgröße nicht erhöhen: Ollama nutzt standardmäßig 2048 Token. Immer num_ctx explizit setzen: PARAMETER num_ctx 32768 in Modelfile oder --ctx zur Laufzeit.
- Langen Kontext bei unzureichendem RAM ausführen: Ein 7B-Modell mit 128K-Kontext auf 8 GB RAM verursacht massiven Swap-Verbrauch. Modellgewichte (~4,5 GB) plus 128K-KV-Cache (~8+ GB) überschreiten 8 GB. Kontext auf 32K reduzieren oder 16+ GB RAM verwenden.
- Vergessen, dass TTFT bei langem Kontext skaliert: Bei 32K-Kontext kann die Zeit bis zum ersten Token (TTFT) 5-15 Sekunden betragen. Diese Prefill-Phase skaliert linear mit der Kontextlänge.
- RAG und langen Kontext verwechseln: RAG ist besser für Suche über viele Dokumente. Langer Kontext ist besser für die vollständige Analyse kohärenter Dokumente (Verträge, Codebasen).
Häufig gestellte Fragen
Kann ich ein ganzes Buch mit einem lokalen LLM zusammenfassen?
Ein typisches 300-seitiges Buch hat 90.000-120.000 Wörter -- etwa 120K-160K Token. Dies übersteigt das zuverlässige Kontextfenster der meisten 7B-Modelle. Für 7B-Modelle: Buch in 20K-Wort-Kapitel aufteilen, jedes zusammenfassen, dann die Zusammenfassungen zusammenfassen.
Wie viele Seiten Text passen in 32K Token?
Ungefähr 50-70 Seiten Standardtext bei 250 Wörtern pro Seite. Ein 32K-Token-Kontext fasst einen Kurzroman, ein vollständiges Forschungspapier mit Anhängen oder ein komplettes technisches Spezifikationsdokument.
Verlangsamt das Erhöhen der Kontextlänge die Inferenz?
Ja -- die Verarbeitung eines 32K-Kontexts dauert auf gleicher Hardware etwa 3-4× länger als ein 4K-Kontext, aufgrund der quadratischen Skalierung der Attention-Berechnung. Die Generierungsgeschwindigkeit wird nicht wesentlich beeinflusst, aber die Zeit bis zum ersten Token skaliert mit der Eingabelänge.
Welches lokale LLM verwaltet RAG besser als langen Kontext?
Für Dokumentensuche ist RAG oft effektiver als die Eingabe ganzer Dokumente als Kontext. RAG ruft 3-5 relevante Blöcke ab und stellt nur diese dem Modell bereit.
Was ist der KV-Cache und warum wächst er mit der Kontextlänge?
Der KV-Cache speichert Attention-Zustände für jedes verarbeitete Token. Daher benötigt ein 32K-Kontext 8× mehr KV-Cache-Speicher als ein 4K-Kontext. Die Modellgewichte bleiben gleich -- nur der KV-Cache wächst.
Können lokale Modelle 1M-Token-Kontexte wie Gemini 3.1 Pro verarbeiten?
Nein -- Stand April 2026 unterstützt kein lokal ausführbares Modell 1M-Token-Kontexte. Das 1M-Token-Fenster von Gemini 3.1 Pro erfordert Googles TPU-Infrastruktur. Lokal ist 128K das Maximum auf Consumer-Hardware.
Was ist das "Lost in the Middle"-Problem und wie vermeide ich es?
LLMs rufen Informationen am Anfang und Ende des Kontextfensters zuverlässig ab, verfehlen aber Details in der Mitte. Wichtige Informationen an den Promptanfang stellen, RAG nutzen oder lange Dokumente in überlappenden 16K-32K-Abschnitten verarbeiten.
Wie überprüfe ich, welche Kontextlänge Ollama verwendet?
`ollama show <modell>` ausführen -- die Ausgabe listet num_ctx. Zeigt es 2048, nutzt Ollama den Standard. Zum dauerhaften Ändern: Modelfile mit PARAMETER num_ctx 32768 erstellen und `ollama create <name> -f Modelfile` ausführen. Aktive Sitzungen mit `ollama ps` prüfen.
Was ist besser für Dokument-Q&A: langer Kontext oder RAG?
RAG ist in der Regel effektiver und RAM-effizienter für Dokument-Q&A. RAG ruft 3-5 relevante Blöcke (4K-8K Token gesamt) ab und vermeidet das "Lost in the Middle"-Problem. Langer Kontext ist besser, wenn das Modell die gesamte Dokumentstruktur verstehen muss.
Muss ich bei lokaler LLM-Langkontext-Verarbeitung die DSGVO beachten?
Ja, wenn Sie personenbezogene Daten verarbeiten. Lokale Inferenz via Ollama -- ohne externe API-Aufrufe -- erfüllt DSGVO Art. 28 (keine Auftragsverarbeitung durch Dritte) und Art. 5 (Datensparsamkeit). BSI-Grundschutz empfiehlt dokumentierten Modell-Einsatz: Ollama-Tags mit Versionsnummer sind prüfbar. Für medizinische oder juristische Dokumente: 7B-Modell auf lokaler Workstation (nicht Cloud) ist die DSGVO-konforme Wahl.
Kann ein Mittelständler Ollama für Dokumentenverarbeitung einsetzen?
Ja. Für KMU ist ein 7B-Modell (Q4_K_M, 32K-Kontext) auf einer Workstation mit 16 GB RAM die kosteneffektivste Option. Hardwarekosten: ~1.500-2.500 € einmalig. Betrieb: Open Source, kein laufendes API-Budget. Llama 3.1 8B verarbeitet 50-seitige Dokumente zuverlässig. Für Datenschutz-sensible Branchen (Steuerberatung, Medizin, Recht): On-Premises-Betrieb ist die BSI-empfohlene Lösung.
Quellen
- Lost in the Middle: How Language Models Use Long Contexts -- Liu et al., 2023
- Ollama Context Length Configuration -- Ollama-Dokumentation
- Llama 3.1 Technical Report -- Meta AI, 2024
- EU AI Act Official Text -- Europäisches Parlament, 2024