Lokale LLMs mit langem Kontext 2026: 128K-, 256K- und 1M-Modelle im Vergleich

Die Kontextlänge ist die maximale Zahl an Token, die ein Modell in einer Anfrage verarbeiten kann: Ihr Prompt, alle Dokumente, der bisherige Gesprächsverlauf und die Antwort des Modells zusammengerechnet. Ein Token entspricht etwa 0,75 englischen Wörtern, 128K Token sind also etwa 100.000 Wörter und 256K Token etwa 200.000 Wörter.

Das angegebene Fenster ist das Maximum, das die Modellarchitektur unterstützt. Das nutzbare Fenster ist die Länge, bei der die Antworten für Ihre Aufgabe genau bleiben, und es ist kürzer.

Lange Fenster sind wichtig für ganze Codebasen, Verträge, lange Transkripte, Buchkapitel und Agenten-Sitzungen, in denen sich Tool-Ausgaben ansammeln. Die Ollama-Dokumentation empfiehlt mindestens 64.000 Token für Agenten, Websuche und Coding-Tools.

Drei Dinge bestimmen die Grenze auf Ihrem eigenen Rechner: das Fenster des Modells, der Speicher, den sein KV-Cache bei dieser Länge braucht, und wie zuverlässig es Text bei dieser Länge nutzt. Die folgenden Abschnitte behandeln jeden Punkt der Reihe nach.

Mehrere: Qwen3.5, Qwen3.8 und Gemma 4 (ab 12B) nennen in der Ollama-Bibliothek 256K-Fenster, NVIDIA Nemotron 3 Nano 30B nennt 1M und Llama 4 Scout nennt 10M. Vor 2026 veröffentlichte Modelle enden meist bei 128K.

Die Tabelle zeigt das Fenster laut Model Card oder Ollama-Bibliothek. Eine Erweiterung auf längeren Kontext, etwa YaRN, ist eine vom Hersteller dokumentierte Option, die zusätzliche Konfiguration und zusätzlichen Speicher braucht.

Llama 4 Scout nennt 10M Token, doch seine Model Card gibt die Long-Context-Benchmarks bei einem 128K-Fenster an, und der Ollama-Download umfasst 67 GB. Llama 4 Maverick nennt 1M, ist aber ein Download von 245 GB und braucht Server-Hardware.

Ollama-Tags können sich in der Fenstergröße unterscheiden: qwen3:8b und qwen3:14b nennen 40K, qwen3:4b und qwen3:30b dagegen 256K. Lesen Sie die Kontextangabe auf der Ollama-Seite des Modells, bevor Sie planen.

Der Speicher für langen Kontext besteht aus den Modellgewichten plus dem KV-Cache, und der KV-Cache hängt von der Architektur ab, nicht nur vom Fenster. Der KV-Cache speichert die Attention-Keys und -Values jedes Tokens im Kontext und wird zusätzlich zu den Gewichten belegt.

KV-Bytes pro Token = 2 (Keys und Values) × Full-Attention-Schichten × KV-Heads × Head-Dimension × Bytes pro Wert (2 beim Standard-f16-Cache). Llama 3.1 8B: 2 × 32 × 8 × 128 × 2 = 131.072 Bytes (128 KiB) pro Token, das sind 16 GiB bei 128K Token und mehr als das Dreifache seines 4,9-GB-Downloads.

Neuere Architekturen senken diese Kosten. Gemma 4 nutzt in den meisten Schichten Sliding-Window-Attention (ein 1.024-Token-Fenster bei 12B, 26B und 31B), gpt-oss in jeder zweiten Schicht (128 Token), Qwen3.5 und Qwen3.8 nutzen in drei von vier Schichten lineare Gated-DeltaNet-Attention, und Nemotron 3 Nano hat nur 6 Attention-Schichten von 52. Nur Full-Attention-Schichten wachsen mit dem Fenster.

Die folgenden Werte sind aus der veröffentlichten Konfiguration jedes Modells berechnet, nicht gemessen. Laufzeitumgebungen belegen zusätzliche Compute-Puffer und Cache-Implementierungen unterscheiden sich, prüfen Sie die reale Nutzung daher mit ollama ps.

Eine Quantisierung des KV-Cache verkleinert ihn: Laut Ollama-Dokumentation braucht q8_0 etwa halb so viel Speicher wie f16 und q4_0 etwa ein Viertel, bei q4_0 mit geringem bis mittlerem Genauigkeitsverlust.

Wählen Sie zuerst nach Speicher: Gewichte plus KV-Cache beim benötigten Kontext müssen passen, mit 2 bis 3 GB Reserve für Betriebssystem und Laufzeitumgebung. Die folgenden Empfehlungen sind Rechnungen auf Basis der Tabelle oben, keine Qualitätsrankings; wir haben die Genauigkeit bei langem Kontext nicht gebenchmarkt.

Das angegebene Fenster ist eine architektonische Obergrenze, keine Qualitätsgarantie. Liu et al. (2023) stellten fest, dass Sprachmodelle am genauesten antworten, wenn der relevante Text am Anfang oder Ende der Eingabe steht, und weniger genau, wenn er in der Mitte steht: der „Lost in the Middle“-Effekt.

RULER (Hsieh et al., 2024) testete 17 Modelle, die alle 32K Token oder mehr angeben; nur etwa die Hälfte behielt bei 32K eine zufriedenstellende Leistung. NoLiMa (Modarressi et al., 2025) testete 13 Modelle mit mindestens 128K; bei 32K fielen 11 davon unter 50 % ihres Kurzkontext-Werts, und GPT-4o sank von 99,3 % auf 69,7 %.

Diese Studien sind älter als die meisten Modelle in diesem Leitfaden. Verstehen Sie sie als Beleg für das Muster, nicht als Messwerte für ein hier genanntes Modell. Um ein Modell selbst zu prüfen, verstecken Sie einen Fakt bei 10 %, 50 % und 90 % eines langen Prompts, fragen Sie mit anderen Worten danach und wiederholen Sie das bei 32K, 64K und 128K.

Wenn es auf Genauigkeit ankommt, setzen Sie kritische Anweisungen und Fakten an den Anfang oder das Ende des Prompts, rufen Sie nur die relevanten Passagen ab (siehe RAG-Abschnitt unten) oder verarbeiten Sie lange Dokumente in überlappenden Abschnitten.

Ollama wählt den Standardkontext nach Ihrem VRAM: 4K Token unter 24 GiB, 32K von 24 bis 48 GiB und 256K ab 48 GiB. Eingaben über den aktiven Kontext hinaus werden abgeschnitten, das Modell sieht den Anfang eines langen Dokuments dann nie.

Sie können den Kontext über den Schieberegler der Ollama-App, die Umgebungsvariable OLLAMA_CONTEXT_LENGTH, /set parameter num_ctx in ollama run, ein Modelfile oder die API-Option num_ctx einstellen. Prüfen Sie das Ergebnis mit ollama ps.

In LM Studio öffnen Sie „My Models“, klicken auf das Zahnrad eines Modells und stellen Kontextgröße und Flash Attention ein. In llama.cpp legt -c die Kontextgröße fest (0 lädt sie aus dem Modell), -fa steuert Flash Attention, und --cache-type-k sowie --cache-type-v quantisieren den KV-Cache.

Ollama quantisiert den KV-Cache nur bei aktivem Flash Attention, und die Einstellung gilt global für alle Modelle. OLLAMA_KV_CACHE_TYPE=q8_0 braucht etwa halb so viel Speicher wie f16 und q4_0 etwa ein Viertel.

Das kann sein: Petrov et al. (2023) stellten fest, dass derselbe Text je nach Tokenizer in einer Sprache bis zu 15-mal mehr Token brauchen kann als in einer anderen. Ob japanischer, chinesischer, koreanischer oder arabischer Text betroffen ist, hängt vom Tokenizer des Modells ab.

Rechnen Sie Seiten nicht mit der englischen Regel von 0,75 Wörtern pro Token in Token um. Zählen Sie die Token mit dem Modell, das Sie verwenden wollen: ollama run <model> --verbose gibt nach einer Antwort die Token-Anzahl des Prompts aus.

Planen Sie das Fenster pro Sprache und pro Modellfamilie, denn Tokenizer unterscheiden sich zwischen Modellfamilien.

Nutzen Sie RAG, wenn die Antwort in wenigen Passagen einer großen Sammlung steht, und langen Kontext, wenn das Modell über ein zusammenhängendes Dokument schlussfolgern muss.

RAG (Retrieval-Augmented Generation) ruft die relevantesten Textabschnitte ab, oft insgesamt nur wenige tausend Token, und hält den Prompt kurz. Langer Kontext erhält Querverweise, etwa Klauseln in einem Vertrag oder Aufrufketten in einer Codebasis, die Chunking zerschneiden kann.

Viele Setups kombinieren beides: ganze Abschnitte statt Fragmente abrufen und in ein 32K- bis 128K-Fenster legen. Siehe Beste lokale RAG-Tools für lokale Optionen und RAG erklärt für die Methode.