Wichtigste Erkenntnisse
- Alle wichtigen lokalen LLMs 2026 — Qwen3, Gemma 3, Llama 3.1, Mistral Small 3.1 — unterstützen 128K Token nativ. Langer Kontext ist Standard, kein Unterscheidungsmerkmal mehr.
- Empfehlung für die meisten Nutzer: Qwen3 14B bei Q4_K_M. Verarbeitet 128K Token in ~12 GB RAM mit 15-25 Tok/s auf Apple M5 Pro. Auf 8-GB-Geräten: Qwen3 4B — gleiche Kontextlänge, geringere Qualität, voll nutzbar.
- RAM skaliert mit Kontextlänge UND Modellgröße. Ein 7B-Modell Q4_K_M benötigt ~6 GB bei 4K und ~14 GB bei 128K. Qwen3 14B Q4_K_M verbraucht ~12 GB bei 128K auf Apple Silicon (Unified Memory hilft).
- "Lost in the Middle" gilt weiterhin: LLMs verpassen Details aus mittleren Kontextabschnitten. Abhilfe: wichtige Infos an den Anfang, RAG für Suche, oder überlappende Chunks.
- Langer Kontext eignet sich für holistische Analyse vollständiger Dokumente. RAG eignet sich für suchintensive Aufgaben. Nach Aufgabentyp wählen, nicht nach Kontextgröße.
- Ollama nutzt standardmäßig 2048 Token -- nicht 128K. num_ctx explizit in einer Modelfile setzen. Apple M5 (16-32 GB, 200 GB/s) und M5 Pro (36-64 GB, 307 GB/s) eignen sich gut für 128K-Inferenz.
📍 In einem Satz
Alle großen lokalen LLMs von 2026 unterstützen nativ 128K Token; Qwen3 14B Q4_K_M verarbeitet 128K in ~12 GB RAM bei 15–25 Tok/s — aber Ollama begrenzt standardmäßig auf 2048 Token, also immer num_ctx im Modelfile setzen.
💬 In einfachen Worten
Kontextlänge ist, wie viel Text eine KI auf einmal "sehen" kann. 128K Token ≈ 96.000 Wörter — genug für einen ganzen Roman. Der Haken: Modelle verlieren Genauigkeit bei Informationen, die in der Mitte sehr langer Eingaben vergraben sind ("Lost in the Middle"). Die wichtigsten Fakten an den Anfang des Prompts stellen.
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 |
|---|---|---|---|
| Qwen3 14B Q4_K_M | 128K | ~32-64K zuverlässig | ollama run qwen3:14b |
| Qwen3 4B Q4_K_M | 128K | ~16-32K zuverlässig | ollama run qwen3:4b |
| Gemma 3 12B Q4_K_M | 128K | ~32K zuverlässig | ollama run gemma3:12b |
| Llama 3.1 8B Q4_K_M | 128K | ~32K zuverlässig | ollama run llama3.1:8b |
| Llama 3.2 3B | 128K | ~16K zuverlässig | ollama run llama3.2:3b |
| Mistral Small 3.1 24B | 128K | ~32K zuverlässig | ollama run mistral-small3.1 |
| Qwen3 8B Q4_K_M | 128K | ~32K zuverlässig | ollama run qwen3:8b |
| DeepSeek-R1 14B Q4_K_M | 128K | ~32K zuverlässig | ollama run deepseek-r1:14b |
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.3 8B Q4_K_M | ~6 GB | ~9 GB | ~14 GB |
| Qwen3 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.3 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. Qwen3'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 Qwen3 hält alle Daten On-Premises. Qwen3 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?
Die wichtigsten lokalen Modelle im Juni 2026 — Qwen3, Gemma 3, Llama 3.1, Mistral Small 3.1 — unterstützen alle nativ 128K Token, was die große Mehrheit der Langdokument-Anwendungen abdeckt. 1M-Token-Inferenz lokal erfordert spezialisierte Hardware (150+ GB VRAM). Für die meisten Anwender ist Qwen3 14B mit 128K-Kontext die praktische Lösung.
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.3 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.3 Technical Report -- Meta AI, 2024
- EU AI Act Official Text -- Europäisches Parlament, 2024