Die Eviction des KV Cache kann LLM-Fehler in der Produktion verbergen

Ja. Die Eviction des KV Cache kann LLM-Fehler verbergen, weil eine Serving-Richtlinie möglicherweise für die Attention relevante Zustände verwirft und anschließend nicht genügend Informationen besitzt, um das Ausmaß des Schadens allein anhand des erhaltenen Cache zu schätzen.

Ein am 23. Juli 2026 eingereichtes Paper grenzt dieses Problem präzise ein: Deterministische, wertblinde Top-k-Eviction kann den dadurch verursachten Fehler des Attention-Outputs nicht konsistent anhand des erhaltenen Zustands schätzen. Die vorgeschlagene Alternative bewahrt eine Wahrscheinlichkeitsstichprobe des verworfenen Tails und erstellt ein statistisches Zertifikat rund um den geschätzten Fehler. Die Methode verbesserte in den berichteten Experimenten die Zuordnung von Fehlerursachen, doch der Prototyp ist langsamer, die Experimente reichen nur bis zu einem Kontext von 16K und 8B Parametern, und das Paper beweist keine End-to-End-Korrektheit der Antworten.

Vergleiche vor dem Rollout jede mögliche Cache-Behandlung mit einer Full-Cache-Kontrolle anhand derselben eingefrorenen Requests. Zähle die Fälle, in denen der Full Cache besteht und der Kandidat scheitert. Teste Eviction, Quantisierung, Offload und Wiederverwendung getrennt, damit jeder Vergleich eine einzelne Fehlerquelle isoliert.

Lesestufe: Fortgeschritten. Dieser Leitfaden setzt voraus, dass du Transformer-Inferenz, Attention und grundlegende Model-Evaluation verstehst.

Inhalt

Warum die Eviction des KV Cache Fehler verbergen kann

Der Attention-Output hängt von den erhaltenen Einträgen und den Einträgen ab, die die Richtlinie entfernt. Nachdem eine deterministische Richtlinie den Tail verworfen hat, kann ein Monitor, der nur die ausgewählte Menge sieht, die fehlenden Werte nicht untersuchen.

ArXiv:2607.21475 untersucht dieses Beobachtbarkeitsproblem. Das negative Ergebnis gilt für deterministische, wertblinde Top-k-Eviction: Der erhaltene Zustand allein kann keine konsistente Schätzung des durch die Eviction verursachten Fehlers des Attention-Outputs ermöglichen. Das Ergebnis besagt nicht, dass jede deterministische Richtlinie schlechte Outputs erzeugt. Es besagt, dass diese Richtlinienklasse ihren verursachten Fehler nicht zuverlässig allein anhand dessen zertifizieren kann, was sie behalten hat.

Die vorgeschlagene Methode bewahrt Belege über den verworfenen Tail. Sie zieht per Poisson-Sampling Einträge, die andernfalls verschwinden würden, wendet eine Hájek-Korrektur an und kombiniert diese Schätzung mit einem Varianz-Zertifikat für die erhaltene Menge.

Gemessen: Das Fehlerzertifikat erreichte über 12.096 Attention-Replay-Zellen eine Abdeckung von 0,97. Eine separate Studie mit realen Workloads verwendete etwa 74.000 Generierungen, um die Zuordnung von Fehlerursachen zu testen. In dieser Studie erreichte das Zertifikat eine AUC von 0,73–0,75 bei der Unterscheidung zwischen cachebedingten Fehlern und inhärenten Modellfehlern. Das Output-Confidence-Signal erreichte bei derselben Zuordnungsaufgabe 0,47–0,54.

Gemessen: Output Confidence sagte den Gesamtfehler besser voraus. Die beiden Signale beantworten unterschiedliche Fragen:

Abgeleitet: Niedrige Output Confidence kann nicht als alleiniger Alarm für Cache-Regressionen dienen. Sie kann eine schwache Antwort markieren, ohne ihre Ursache zu identifizieren, während sich eine selbstsichere Antwort dennoch ändern kann, nachdem die Cache-Richtlinie nützlichen Zustand entfernt hat.

Das Paper berichtet außerdem negative und operative Ergebnisse. Drei von sieben vorregistrierten Aussagen schlugen fehl. Der Prototyp benötigte 0,043 Sekunden pro Token, verglichen mit 0,023 bei deterministischer Eviction und 0,015 beim Full Cache. Die Experimente umfassten Kontexte bis 16K, Modelle bis 8B und einen Single-Turn-Proxy. Die Autoren liefern keinen Satz, der das Zertifikat mit der End-to-End-Korrektheit von Aufgaben verknüpft.

Praktische Interpretation: Behandle das Zertifikat unter den untersuchten Bedingungen als Signal zur Ursachenbestimmung. Es zertifiziert keine Produktionsreife.

Vier Cache-Behandlungen, vier Zuverlässigkeitsfragen

Teams fassen mehrere Eingriffe häufig unter „KV-Cache-Optimierung“ zusammen. Jeder Eingriff verändert einen anderen Teil der Inferenz.

Die systemorientierte Übersicht in arXiv:2607.08057 klassifiziert das Feld anhand zeitlicher Planung, räumlicher Platzierung und Migration sowie struktureller Repräsentation und Speicherung. Diese Taxonomie eignet sich auch als Evaluationsgrenze. Ein Full-Cache-BF16-Control im Vergleich zu einem evicted-FP8-Kandidaten verändert gleichzeitig zwei strukturelle Variablen. Ein gescheiterter Kandidat kann nicht erkennen, ob Eviction, Quantisierung oder deren Zusammenspiel die Regression verursacht hat.

Praktische Interpretation: Teste jeden Cache-Eingriff als eigenes Experiment. Kombiniere sie erst, nachdem die einzelnen Behandlungen bestanden haben.

Richtlinien, die mehr nützlichen Zustand bewahren

Zwei weitere Papers zeigen, dass das Design der Richtlinie bei gleichem Speicherbudget mehr Qualität bewahren kann. Keines liefert eine universelle Produktionsschwelle.

VaSE, arXiv:2606.03928, schützt Value-Zustände mit hoher Magnitude und bewahrt gleichzeitig stochastische Vielfalt. Auf Qwen3-4B und Qwen3-14B über sechs Reasoning-Aufgaben hinweg erreichte die Methode ungefähr eine 4-fache Cache-Kompression und verbesserte die Ergebnisse gegenüber der stärksten Eviction-Baseline um 4,4 beziehungsweise 4,9 Punkte. Ein Setup mit 16K und einer einzelnen A100 erreichte 3,1× Tokens pro Sekunde.

Diese Messungen decken nur Decode, Qwen3-Modelle und kein Production-Batching ab. Sie belegen nicht denselben Gewinn für eine andere Modellfamilie, Serving-Engine, Parallelitätsstufe oder einen anderen Workload.

K-VEC, arXiv:2606.29563, koordiniert die Abdeckung der Speicherung über Attention-Heads und Layer hinweg. Auf Llama 3.1 8B über 16 LongBench-Subsets verbesserte die Methode die Scores bei einem Budget von `B=128` um bis zu 10,35 Punkte und im Durchschnitt um 1,61 Punkte. Die Evaluation verwendet eine Modellfamilie und eine Benchmark-Suite, und die Methode erhöht den Prefill-Aufwand.

Praktische Interpretation: Value-aware-, stochastische und coverage-aware Richtlinien verdienen Plätze als Kandidaten in einer Evaluation. Dein Full-Cache-Lauf bleibt die lokale Quelle der Wahrheit.

Warum Quantisierung eine separate Kontrolle benötigt

Die FP8-KV-Cache-Quantisierung reduziert die Präzision, anstatt Tokens zu entfernen. Ihre Fehler können die Anwendung dennoch ohne einen Engine-Fehler erreichen.

Eine offizielle vLLM-FP8-Untersuchung, veröffentlicht am 22. April 2026, berichtete, dass die Needle-Accuracy bei langen Kontexten mit BF16-Cache von 91 % auf 13 % mit FP8 fiel, bevor eine zweistufige Accumulation-Korrektur eingeführt wurde. Die Korrektur stellte die Accuracy auf 89 % wieder her. In der besten berichteten FP8-Konfiguration betrug die Decode-Steigung 54 % derjenigen von BF16.

Gemessen: Ein numerischer Pfad erzeugte eine schwere Regression, und eine Korrektur auf Kernel-Ebene stellte den größten Teil der verlorenen Accuracy wieder her.

Nicht belegt: FP8-Cache verursacht diese Regression nicht universell und liefert auch nicht universell diesen Speedup. Das Ergebnis hängt von Implementierung, Modell, Hardware, Attention-Pfad und Benchmark ab.

vLLM Issue #37554 ergänzt eine eng begrenzte Warnung: Ein Reporter fand eine stille Beschädigung der FP8-KV-Skalierung bei einem Hybridmodell. Dieser Bugreport kann keine allgemeine Aussage über FP8 oder hybride Architekturen stützen.

Eine LocalLLaMA-Diskussion vom 7. April enthält widersprüchliche Berichte aus der Praxis über Cache-Formate und Qualität. Diese Berichte können Testfälle nahelegen, doch eine kontrollierte Evaluation muss über einen Rollout entscheiden.

Der vLLM-v0.26.0-Release vom 25. Juli enthält 411 Commits von 212 Contributors und erweitert die Sichtbarkeit in Bezug auf KV-Tiering, Offload-Metriken und Cache-Wiederverwendung. Release-Aktivität und neue Observability-Features beweisen weder eine breite Produktionsnutzung noch Korrektheit.

Ein gepaarter Full-Cache-Validierungsworkflow

Definiere „Full Cache“ als das native Attention-Verhalten des Modells ohne zusätzliche Eviction oder Cache-Quantisierung. Halte Modellgewichte, Tokenizer, Runtime-Version, Attention-Backend, Sampling-Einstellungen, Prompt-Tokens und Output-Validator innerhalb jedes Paars konstant.

1. Führe eine Ablationsmatrix aus

Verwende mindestens vier Behandlungen:

Der Vergleich nur von A mit D kann eine kombinierte Regression aufdecken, aber keine Ursache zuweisen. Die Läufe B und C liefern die fehlenden Kontrollen.

Teste jedes unterstützte Modell, jede Runtime, jeden Kernel und jeden Hardwarepfad separat. Das vLLM-FP8-Ergebnis zeigt, warum eine Bezeichnung wie „FP8 aktiviert“ für eine Zuverlässigkeitsentscheidung nicht genügend Details enthält.

*Bildunterschrift: Die gepaarte Full-Cache-Validierung isoliert ausschließlich beim Kandidaten auftretende Fehler, bevor Eviction oder Quantisierung die Produktion erreicht.*

2. Friere eine Workload-Matrix ein

Erstelle die Matrix aus realen Request-Formen und schließe Grenzfälle ein:

Workloads mit langen Kontexten benötigen mehr als einen synthetischen Needle-Test. Wenn das Produkt Code-Agenten oder längere Workflows ausführt, nimm repräsentative Traces auf. Tokenvolumen und Workflow-Form beeinflussen die in More Tokens, Better AI — and the Compute Bill und Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6 beschriebenen Kostenaspekte.

3. Paare Requests und isoliere den Cache-Zustand

Verwende diese Evaluationslogik:

text for each frozen_case: full = run(frozen_case, treatment=A, isolated_cache=true) candidate = run(frozen_case, treatment=candidate, isolated_cache=true)

full_pass = validate(full, frozen_case.expected_behavior) candidate_pass = validate(candidate, frozen_case.expected_behavior)

record(full_pass, candidate_pass, context_length, task_type, model, runtime, hardware, treatment)

Dieser Block ist Pseudocode, keine enginespezifische API. Verwende einen Task-Validator statt Textgleichheit, wenn mehrere Antworten korrekt sein können. Geeignete Validatoren sind Unit-Tests für generierten Code, Schema-Prüfungen für strukturierte Ausgaben, exakte Prüfungen von Tool und Argumenten, Retrieval-Assertions oder eine vorab registrierte Bewertungsrubrik.

Halte Cache-Namespaces isoliert. Wiederverwendeter Prefix-Zustand kann den Vergleich kontaminieren.

4. Miss ausschließlich beim Kandidaten auftretende Fehler

Verwende diese primäre Metrik:

text cache_induced_failure_rate = count(full passes and candidate fails) / count(full passes)

Der Nenner konditioniert die Rate auf den Erfolg des Full Cache. Ein Paar, bei dem beide Läufe scheitern, zeigt nicht, dass die Cache-Kompression den Fehler verursacht hat.

Berichte für jeden kritischen Slice den rohen Zähler und Nenner. Ein einzelner aggregierter Wert kann eine Regression bei maximalem Kontext, auf einem Modell oder unter einem Attention-Backend verbergen. Verfolge neben der gepaarten Metrik auch die Gesamtausfallrate, da Output-Confidence- und Cache-Attributionssignale unterschiedliche Fehlermodi abdecken.

5. Lege die Entscheidungsregel vorab fest

Wähle den maximal akzeptablen Wert `τ`, bevor du die Kandidatenergebnisse siehst. Lege für kritische Aufgaben strengere Regeln fest. Ein reproduzierbarer, ausschließlich beim Kandidaten auftretender Fehler kann die Ablehnung eines Kandidaten auf einem Tool-, Safety- oder Transaktionspfad rechtfertigen, selbst wenn das Aggregat unter `τ` bleibt.

Die Cache-Konfiguration gehört in die Ausführungsrichtlinie. Zeichne sie auf und erzwinge sie mit derselben Disziplin wie bei deterministischen Berechtigungen für AI-Agenten: explizite Konfiguration, beobachtbare Entscheidungen und ein Reparaturpfad, wenn die Durchsetzung fehlschlägt.

Rollout-Entscheidungen

Release-Note-Aktivität, anekdotische Berichte und durchschnittliche Benchmark-Gewinne können kein gepaartes Rollout-Gate ersetzen.

Grenzen der aktuellen Evidenz

Das stärkste Ergebnis zum Zertifikat deckt den Fehler des Attention-Outputs unter einem Single-Turn-Proxy ab, nicht die End-to-End-Korrektheit der Anwendung. Die Experimente reichen nur bis 16K und 8B, während Produktionssysteme größere Modelle, längere Kontexte, mehrere Turns, Tools und Batches ausführen können. Der gemessene Prototyp benötigt im berichteten Setup außerdem mehr Zeit pro Token als deterministische Eviction und Full Cache.

VaSE und K-VEC bleiben an bestimmte Modelle, Aufgaben, Budgets und Serving-Setups gebunden. Die vLLM-Evidenz zeigt, dass Implementierungsdetails ein Ergebnis zum Cache-Format dominieren können. Keine dieser Quellen liefert ein universell sicheres Kompressionsverhältnis.

Praktische Interpretation: Nutze die Forschung, um Kandidatenrichtlinien und Monitoring-Signale auszuwählen. Nutze die gepaarte Full-Cache-Validierung, um zu entscheiden, ob deine Implementierung die Zuverlässigkeitsgrenzen für deinen Workload einhält.

Überprüfung der Aussagen

Quellen