Lokales Qwen-Kontextfenster bricht früh ab: KV-Cache, Backend und GPU-Limits prüfen

Du hast für ein lokales Qwen-Modell 128K Kontext eingestellt, doch der Lauf scheitert vielleicht schon bei etwa 72K, wird praktisch unbenutzbar langsam oder beendet die Antwort, ohne Vorgaben vom Anfang zu beachten. Meist fehlt nicht ein einzelner „richtiger Schalter“: Gewichtsquantisierung, KV-Cache, Inferenz-Backend und die Verteilung auf die Hardware bestimmen gemeinsam die Grenze.

Mit dem folgenden Verfahren findest du nicht nur heraus, ob 128K irgendwie startet, sondern welches Fenster stabil, schnell genug und inhaltlich verlässlich ist. Du ordnest zuerst das Symptom ein und änderst anschließend pro Test genau eine Variable. So kannst du begründet entscheiden, ob du den KV-Cache, das Backend, die GPU-Verteilung oder das Ziel selbst ändern solltest.

Die direkte Antwort: Das konfigurierte Fenster ist eine Obergrenze, keine Zusage

Eine Einstellung von 128K fordert das Backend lediglich auf, Speicher für eine Eingabe dieser Größenordnung vorzubereiten. Das Setup kann nur funktionieren, wenn diese Rechnung aufgeht:

model weights + KV cache + runtime workspace + safety margin ≤ memory the backend can actually use

Die Modellgewichte belegen beim Laden einen großen, weitgehend festen Anteil. Der KV-Cache speichert Zustände früherer Token und wächst mit der behaltenen Sequenz; Arbeitsbereiche und temporäre Puffer hängen zusätzlich von Backend, Batch-Größe und verwendeten Kernels ab. Selbst nach erfolgreicher Allokation können Latenz oder Fernabruf früher unbrauchbar werden als der Speicher.

Du brauchst deshalb drei getrennte Antworten: Passt die Eingabe, wird sie schnell genug verarbeitet und nutzt das Modell Informationen vom Anfang noch korrekt? Der Maximalwert in einer Oberfläche beantwortet keine dieser Fragen allein.

Ordne zuerst das Symptom ein, sonst optimierst du die falsche Komponente

„128K wird nicht erreicht“ kann mehrere völlig unterschiedliche Fehler bedeuten. Wähle die Zeile, die deinem Lauf am nächsten kommt, und beginne dort.

Symptom	Wahrscheinlichere Richtung	Erste Prüfung
Beim Laden oder Anlegen des langen Kontexts tritt sofort OOM auf	Gewichte und KV-Cache konkurrieren um VRAM; ein Gerät kann seinen Anteil nicht allokieren	Peak und freien Speicher jeder GPU getrennt erfassen
Das Backend scheitert wiederholt nahe derselben Tokenzahl	Cache-Format, Backend-Implementierung oder Allokationsgrenze	Modell und Hardware fixieren; nur Cache oder Backend ändern
Der Prompt wird angenommen, aber Prefill oder Generierung werden extrem langsam	Bandbreite, GPU-übergreifender Verkehr, Kernels oder zu hohes Ziel	Prompt-Verarbeitung und Generierung getrennt messen
Die Ausgabe endet, aber frühe Regeln oder Fakten fehlen	Qualität des effektiven Kontexts statt reine Kapazität	Fakten an vielen Positionen im Prompt abfragen
Identische Läufe bestehen nur manchmal	Zu wenig Reserve, parallele Last oder instabile Laufzeit	Andere Last entfernen und denselben Test dreimal wiederholen

Wenn alles in den Speicher passt, aber zu langsam ist, löst ein kleinerer Cache-Typ nicht automatisch das ganze Problem. Wenn die Eingabe passt, aber frühere Informationen verloren gehen, verbessert zusätzliche VRAM-Kapazität nicht zwingend die Qualität.

Was ein gemeldeter Sprung von 72K auf 128K zeigt – und was nicht

In einem Konfigurationsbericht vom 23. September 2026 beschrieb Nigel Hungerford-Symes Qwen3.8-27B (Unsloth UD-Q5_K_M) auf einer RTX 5060 Ti mit 16GB und einer RTX 3070 mit 8GB. Laut Bericht nutzte die 128K-Konfiguration beellama.cpp + kvarn5 KV + MTP n=2, erreichte bei kurzem Kontext etwa 36 tok/s und bei 126K etwa 18 tok/s. Das frühere Setup mit mainline llama.cpp und q8_0 KV sei ungefähr bei 72K stehen geblieben.

Der Bericht ist ein nützlicher Hinweis, weil sich die nutzbare Grenze auf genau dieser Maschine mit dem Inferenz-Stack verschob. Er isoliert die Ursache jedoch nicht: Backend, KV-Cache-Verfahren und weitere Laufzeiteinstellungen änderten sich gemeinsam. Daraus folgt weder, dass kvarn5 allein den Sprung bewirkte, noch dass die gemessenen Geschwindigkeiten auf andere Hardware übertragbar sind.

Nutze das Beispiel als Suchrichtung. Wenn dein Fehler immer bei ähnlicher Länge auftritt, gehören Backend und KV-Cache in den kontrollierten Vergleich – nicht nur die Modelldatei.

Sichere vor jeder Änderung eine vollständige 72K-Baseline

Dokumentiere den aktuellen Zustand so, dass du ihn exakt wiederholen kannst. Sonst weißt du nach einem erfolgreichen Umbau immer noch nicht, welche Änderung geholfen hat.

Bereich	Zu erfassende Werte
Modell	Vollständiger Modellname, exakte Datei, Gewichtsquantisierung, Dateigröße
Backend	Name, Version oder Commit, Startmethode
Kontext	Angefordertes Fenster, tatsächliche Input-Token, reservierte Output-Token
KV-Cache	Datentyp oder Verfahren, Platzierung auf GPU oder Host, Kompression
Hardware	Jede GPU mit VRAM, Arbeitsspeicher, PCIe-Topologie
Platzierung	GPU-Split, Offload-Bereiche, geräteübergreifende Arbeit
Laufzeit	Batch, Parallelität, Sampling, maximales Ausgabevolumen
Ergebnis	Erfolg oder Fehler, exakter Fehlertext, Peak-VRAM/RAM, Prefill- und Generierungstempo

Behandle 16GB plus 8GB nicht wie einen einfachen gemeinsamen 24GB-Pool. Das Backend entscheidet, wo Gewichte, Cache und Arbeitsbereiche liegen. Eine Karte kann zuerst voll sein, während die andere Reserve hat; außerdem kann Geräteverkehr bei langem Kontext zum eigentlichen Engpass werden.

Teste vier Variablen getrennt statt den gesamten Stack auf einmal zu ersetzen

1. Gewichtsquantisierung verändert vor allem den festen Speicherbedarf

Die Quantisierung der Modellgewichte beeinflusst primär den Speicher, der schon beim Laden belegt wird. Kleinere Gewichte können dem KV-Cache mehr Platz lassen, garantieren aber kein längeres brauchbares Fenster und können Qualität sowie Geschwindigkeit verändern.

Um zu prüfen, ob die Gewichte den Cache verdrängen, lässt du Backend, Cache-Typ und Testprompt unverändert. Tausche nur die Gewichtsquantisierung aus und erfasse, wie viel Speicher frei wird und ob sich die Fehlergrenze wie erwartet verschiebt.

2. Der KV-Cache bestimmt den mit jedem Token wachsenden Anteil

Der KV-Cache hält wiederverwendbare Zustände für folgende Token. Bei gleichem Modell und gleicher Darstellung wächst sein Speicherbedarf typischerweise ungefähr mit der behaltenen Tokenzahl. Damit ist er einer der direktesten Hebel für langen Kontext.

Vergleiche Cache-Verfahren anhand von drei Ergebnissen: Peak-Speicher, längste stabile Eingabe und Abrufgenauigkeit. „128K passt“ ist kein ausreichender Erfolg, wenn Fernabruf schlechter wird oder das Backend instabil reagiert.

3. Das Backend entscheidet, wie Formate tatsächlich umgesetzt werden

Backends können sich bei Cache-Layout, Allokation, Multi-GPU-Platzierung und Kernels unterscheiden. Dieselbe Modelldatei und derselbe Kontextwert können daher eine andere Speicherkurve und anderes Tempo erzeugen.

Wenn ein neues Backend nur mit einem anderen Cache-Format läuft, lautet das belastbare Ergebnis zunächst: „Dieser gesamte Stack hat bestanden.“ Schreibe nicht einer einzelnen Cache-Variante die Wirkung zu. Wo möglich, folgt ein zweiter A/B-Test mit Einstellungen, die beide Backends unterstützen.

4. Hardware-Platzierung bestimmt, welche Ressource zuerst ausfällt

Bei Multi-GPU-Setups ist es ein häufiger Fehler, nur auf die Summe der VRAM zu schauen. Ein Lauf kann scheitern, weil auf einer Karte kein ausreichend großer Block verfügbar ist, der Cache dort konzentriert wird, Arbeitsraum fehlt oder GPU-übergreifende Transfers das Tempo unbrauchbar machen.

Beobachte jede GPU einzeln. Ist eine Karte fast voll, während die andere deutliche Reserve hat, solltest du Split oder Platzierung ändern, bevor du Modellqualität opferst.

Prüfe langen Kontext mit einer wiederholbaren Längenleiter

Springe nicht von einem kurzen Prompt direkt zu 128K. Eine feste Leiter zeigt, ob der Fehler abrupt auftritt oder Speicher, Tempo und Abruf schrittweise schlechter werden.

Ein sinnvoller Start ist 8K → 32K → 64K → 72K → 96K → 126K. 126K liegt nahe an 128K und lässt ein ausdrücklich reserviertes Ausgabebudget. Benötigt deine Aufgabe lange Ausgaben, reduzierst du das Input-Ziel entsprechend.

Bereite einen einzigen kontrollierten Testsatz vor

1. Zähle Token mit dem Tokenizer, den das Zielmodell wirklich verwendet; schätze nicht anhand von Zeichen oder Dateigröße.
2. Verteile eindeutige „Canary-Fakten“ ungefähr bei 10%, 20% und weiter bis 90%, etwa ORBIT-17 = copper.
3. Platziere je eine Codevorgabe am Anfang, in der Mitte und am Ende. Fordere im Schlussauftrag Wiederholung der Regeln und eine kleine Codeänderung.
4. Halte Reihenfolge, Sampling und Ausgabebudget bei jeder Länge identisch.
5. Entferne andere Systemlast und wiederhole jede kritische Länge dreimal.

Canary-Fakten messen Abruf, nicht die gesamte Programmierleistung. Ergänze für die endgültige Abnahme Code, Logs oder Repository-Dokumentation, die deinem Alltag ähneln.

Erfasse bei jedem Lauf dieselben Kennzahlen

Kennzahl	Welche Frage sie beantwortet
Tatsächliche Input-Token	Hat das Backend die Ziellänge wirklich angenommen?
Allokation und exakter Fehler	Wo scheitern Kapazität oder Kompatibilität?
Peak-VRAM je GPU und Peak-RAM	Welches Gerät wird zum Engpass?
Prompt-Verarbeitungszeit oder -rate	Bleibt Prefill für lange Eingaben akzeptabel?
Generierungstempo	Ist die Interaktion nach langem Prompt noch praktisch?
Zahl korrekt abgerufener Canaries	Nutzt das Modell weit entfernte Informationen?
Erfüllte Codevorgaben	Hilft das lange Fenster bei der realen Aufgabe?

Lege vor dem Test eine Bestehensgrenze fest. Ein Beispiel: drei vollständige Läufe bei der Ziellänge, kein Speicher- oder Backend-Fehler, mindestens 9 von 10 Canaries richtig sowie Prefill und Generierung innerhalb deiner Arbeitsgrenze. 9/10 ist nur ein Beispiel; entscheidend ist, die Regel vor dem Ergebnis festzulegen.

Wähle den nächsten Schritt anhand des Resultats

Bei derselben Länge tritt stabil OOM auf

Ermittle zuerst, welches Gerät voll wird. Verbraucht das Wachstum des Caches die verbleibende Reserve, vergleiche ein speichersparenderes KV-Verfahren. Lassen die Gewichte bereits beim Laden fast keinen Raum, teste eine kleinere Gewichtsquantisierung. Pro Lauf änderst du nur einen Punkt und prüfst, ob die Grenze in der erwarteten Richtung wandert.

Ein neues Backend erreicht 128K, das alte nur 72K

Behandle den neuen Stack als Kandidaten, reproduziere ihn dreimal und führe den Abruf-Test aus. Da Backend und Cache möglicherweise gemeinsam wechselten, kannst du zunächst nur bestätigen, dass die Kandidatenkombination funktioniert – nicht, dass eine einzelne Ursache bewiesen ist.

128K läuft durch, ist aber zu langsam

Das ist eine Betriebsgrenze, kein Kapazitätsfehler. Verwende ein kleineres Standardfenster und aktiviere sehr langen Kontext nur für Aufgaben, die ihn benötigen. Vergleiche zusätzlich ein kleineres Modell, ein anderes Backend oder bessere Platzierung. „Kann laufen“ und „lohnt sich täglich“ sind getrennte Entscheidungen.

128K läuft, aber Informationen vom Anfang gehen verloren

Behandle dies als Problem der effektiven Kontextqualität. Führe denselben Prompt bei 64K, 72K und 96K aus und zeichne eine Abrufkurve. Sind kürzere Eingaben klar zuverlässiger, liegt die Produktionsgrenze dort, wo Qualität besteht – nicht dort, wo Speicher gerade noch allokiert wird. Retrieval, Chunking oder eine Vorzusammenfassung können bei sehr großen Repositories irrelevanten Inhalt reduzieren.

Optimiere für ein nachgewiesenes Arbeitsfenster, nicht für den größten Menüwert

Wenn 72K deine üblichen Repositories und Logs bereits abdecken, ersetze nicht Gewichtsquantisierung, KV-Cache, Backend und GPU-Split gleichzeitig, nur um 128K anzuzeigen. Bewahre die stabile Baseline und verlange von jeder Änderung einen messbaren Vorteil bei Kapazität, Tempo oder Abruf.

Wenn deine Arbeit tatsächlich mehr als 100K Input benötigt, definierst du zuerst Längenleiter und Pass-Kriterien und vergleichst danach Cache- und Backend-Kombinationen. Eine nützliche Schlussaussage lautet: „Dieses Modell, Backend, Cache und diese Hardware bestanden 126K dreimal mit dem geforderten Tempo und Abruf“ – nicht nur „Die Konfiguration unterstützt 128K“.