Random Attention vs. scorebasierte KV-Eviction auf Reasoning-Traces

Ein Paper von Salesforce AI Research landete im September 2026 mit einer Behauptung der besten Sorte — einem negativen Resultat mit Belegen: Über vier Reasoning-Modelle und sechs Reasoning-Tasks hinweg hält eine zufällige KV-Cache-Eviction-Policy mit Prompt-Schutz auf den getesteten Tasks einen starken scorebasierten Evictor ein und liefert im vLLM-Setup des Papers 32–43 % höheren Durchsatz als dieser Vergleich, weil kein Wichtigkeits-Score berechnet wird¹². Wer Serving-Infrastruktur baut, für den ist das keine Kuriosität. Es ist eine direkte Prüfung dessen, was die Forschung der letzten drei Jahre zum Thema „welcher gecachte Token wird später wichtig" tatsächlich gekauft hat — und findet wenig zusätzlichen Genauigkeitsnutzen des Scorings auf seinen Reasoning-Traces. Agenten-Traces untersucht das Paper nicht.

Dieser Guide nimmt die Behauptung auf der Ebene auseinander, die uns interessiert: was die outlier-zentrierte Eviction-Literatur zu optimieren behauptet, was das Paper tatsächlich gemessen hat, warum eine zufällige Policy einer scorebasierten gleichziehen kann (und in welchen Settings sie es nachweislich nicht kann), was die gesamte Lesart widerlegen würde, und wann man trotzdem für einen gelernten Evictor zahlen sollte. Provenienz zuerst, wie immer: Das ist Salesforce Research plus UIUC, unter der Führung von Heng Wang und Kollegen, mit Autoren wie Shelby Heinecke (Salesforce AI Research) sowie Jiawei Han und Heng Ji (UIUC)¹. Ein Hersteller-Forschungslabor, das über eine Komponente, die es selbst nicht verkauft, veröffentlicht „Eure ausgeklügelte Scoring-Passe ist nichts wert", hat eine ordentliche Anreizstruktur — aber die Durchsatzversprechen des Papers hängen daran, dass seine vLLM-Integration der faire Vergleich ist, und Salesforce liefert Serving-Stacks. Den Effizienzabschnitt also mit der üblichen Vorsicht lesen.

1. Was outlier-zentrierte KV-Eviction zu lösen behauptet

Mehrere scorebasierte Eviction-Methoden schätzen die künftige Wichtigkeit eines Tokens aus Cache-Statistiken; strukturelle Baselines wie StreamingLLM arbeiten mit festen Positionsregeln. Signale und Schutzregeln unterscheiden sich. Eine spätere Veröffentlichung bedeutet keinen streng besseren Score. Die Tabelle trennt die Mechanismen:

In Prosa:

• H2O (2023) — akkumulierte Aufmerksamkeit: behalte die Tokens, die seit ihrem Eintritt in den Cache die meiste Attention-Masse erhalten haben; die „Heavy Hitter" sollen die tragenden sein³.
• StreamingLLM (2023) — gar kein Score, aber das strukturelle Prior, das alle kopiert haben: die ersten paar Attention-Sink-Positionen plus ein zusammenhängendes Recency-Fenster⁴.
• SnapKV (2024) — Attention aus einem recenten Fenster von Queries, max-gepoolt über Nachbarpositionen: Was die letzten Queries angeschaut haben, sagt voraus, was künftige anschauen werden⁵.
• R-KV (2025) — SnapKV-Score gemischt mit einer Redundanz-Strafe (mittlere Cosine-Ähnlichkeit eines Keys zu allen anderen gecachten Keys), damit ein wiederholter Gedanke nicht doppelt behalten wird⁶.
• VaSE (2026) — bewertet Values statt Keys: Ein kleiner Bruchteil der Value-Zustände hat abnormal große Magnituden, und VaSEs eigene Ablation zeigt: Verwirft man die größten Magnituden, kollabiert GSM8K auf 14,3 % — 38,9 Punkte unter zufälliger Eviction — weil das Modell in repetitive Reasoning-Schleifen fällt⁷. Das ist das reinste Outlier-Schutzargument der Familie: Die Verteilung hat schwere Ränder, und die Ränder sind tragend.
• TriAttention (2026) — positionsabhängige Key-Statistiken: Pre-RoPE Query-/Key-Vektoren konzentrieren sich um feste Nicht-Null-Zentren, Key-Wichtigkeit ist also eine kalibrierte trigonometrische Funktion des Q/K-Abstands, plus Q/K-Normen⁸.

Die Methoden nutzen unterschiedliche Signale: frühere Attention, Position, Key-Redundanz, Value-Magnitude oder Key-Geometrie. Nicht alle beruhen auf einer Outlier-Prämisse. Der Salesforce-Vergleich fragt, ob diese Ranking-Signale nach Kontrolle von Prompt-Schutz und Cache-Budget zusätzliche Endgenauigkeit liefern.

Das Salesforce-Paper kontrolliert Prompt-Schutz und Cache-Budget und fragt, wie viel das verbleibende Ranking auf seinen Reasoning-Tasks beiträgt.

2. Das Gegenargument: auf Reasoning-Traces kauft das Ranking nichts

Die getestete Methode ist fast schon provokant einfach. Random Attention tut genau zwei Dinge:

1. Die Frage schützen. Jede Prefill-Position — System-Prompt, Chat-Template, die Frage selbst — wird nie verworfen.
2. Den Rest streuen, pro Head. Jede verbleibende Position bekommt einen i.i.d. gleichverteilten Zufallsscore; jeder KV-Head behält unabhängig sein Top-K. Keine Statistiken, keine Kalibrierung, keine Scoring-Passe — ein RNG-Wurf und ein Top-K pro Eviction-Runde².

Der Evaluationsraster: Qwen3-4B/14B/32B und Phi-4-reasoning über MATH500, GPQA-Diamond, AIME 2025/2026, HMMT und LiveCodeBench-v6, bei einem festen Cache-Budget um 4×-Kompression (~3× bei LiveCodeBench), jede Zelle abgesichert mit gepaarten, Problem-geclusterten Bootstrap-Konfidenzintervallen und Sign-Tests². Die Kernaussagen, hier aus Tabelle 1 des Papers nachgerechnet:

• Random Attention schlägt SnapKV um 4,3–35,3 Punkte je nach Modell und Task (z. B. Phi-4-reasoning LiveCodeBench: 0,667 gegen 0,314 — ein Abstand von 35,3 Punkten).
• Es liegt statistisch gleichauf oder vor VaSE und R-KV auf Mathe- und Wissenschafts-Tasks in den drei Modellen des Hauptrasters — Ausnahme: im Qwen3-14B-Anhangsraster bleibt VaSE auf AIME signifikant vorn — und liegt „signifikant vorn in 31 der 60 Basisvergleiche" des Hauptrasters¹.
• Gegen TriAttention — die stärkste Baseline — Gleichstand auf den meisten Zellen; TriAttentions einziger signifikanter Sieg im ganzen Hauptraster ist Code-Reasoning auf Qwen3-32B, mit etwa drei Punkten, was das Paper auf die Prompt-Länge zurückführt, nicht auf die Auswahlqualität².
• Full Attention bleibt die Decke (z. B. Qwen3-4B MATH500: 0,939 voll gegen 0,874 zufällig bei 4×) — Eviction kostet also weiterhin Genauigkeit; die Behauptung des Papers ist, dass kein Selektor mehr davon zurückholt als ein Münzwurf, sobald der Prompt geschützt ist.

Dann die kontrollierten Experimente, in denen das Paper seinen Lohn verdient:

Der Prompt ist der fragile Teil. Frühere Methoden sind sich uneinig, ob der Prompt überlebt: TriAttention pinnt ihn per Regel; SnapKV, R-KV und VaSE überlassen ihn dem Score und behalten nur Attention Sinks. Gibt man jeder Methode dieselbe Behalte-den-Prompt-Regel, verschwindet der Großteil der Abstände zwischen den Methoden. Der Gewinn der Regel ordnet sich exakt nach der Menge an Prompt, die jeder Score zuvor still verloren hatte: SnapKV, der am wenigsten von der Frage behält, gewinnt bis zu +22,5 Punkte (Phi-4 GPQA-D); R-KV, der ohnehin das Meiste behielt, bewegt sich um höchstens ~2 Punkte. Und die signal-freien Zeilen machen den Punkt brutal deutlich: Ein Recency-Fenster ohne Prompt-Schutz erzielt 0,246 auf Qwen3-4B MATH500; mit der Regel 0,843 — ein Swing von +59,7 Punkten, der jeden Selektor-Unterschied der Tabelle dwarf². Derselbe Confound, so das Paper, erklärt, warum frühere Arbeiten zufällige Baselines weit hinter der gescorten Auswahl sahen: Ihre zufälligen Baselines verloren den Prompt².

Der Trace schützt sich selbst. Reasoning-Traces sind auf zwei Ebenen redundant. Im Text formuliert das Modell um, was es gerade verwendet. Und über Heads: Jeder KV-Head hält seine eigene Kopie jedes Tokens, und Eviction entscheidet pro Head, welche Kopien sterben. Ein Planted-Fact-Experiment quantifiziert das Pooling über Heads: Der beste einzelne Retrieval-Head von Qwen3-4B liefert einen gepflanzten Wert allein nur in einem kleinen Teil der Versuche; mehrere Heads zusammen fast immer; das Pooling ist superadditiv — Form und Ort der überlebenden Kopien spielen keine Rolle, nur ob irgendwo eine brauchbare Kopie überlebt². Unabhängige Zufallsziehungen pro Head sind exakt die Policy, die „mindestens eine überlebende Kopie" maximiert — Rechnung in Abschnitt 3.

Needle-Finding ist die eine echte Fähigkeit — und sie transferiert nicht. Ein Passwortsperiment (einmal genannt, nie wiederholt): Random Attention reproduziert das Passwort nie; R-KV, der beste Needle-Finder, findet es meistens. Aber R-KV führt nur eine Spalte des Hauptrasters an, während TriAttention, die stärkste Gesamt-Baseline, beim Needle fast nichts zurückholt. Aggregierte Stärke und Needle-Finding sind dissociiert — und Reasoning-Traces formulieren eine tragende Tatsache selten genau einmal².

Unabhängige Konvergenz: VestigeKV. Eine andere Gruppe, in derselben Woche publizierend (arXiv:2609.03949, 3. Sept. 2026), erreichte ein komplementäres Negativresultat aus der Gegenrichtung: Auf einem NoPE-MLA-Modell kollabiert Auswahl nach beobachteter Attention — der H2O/SnapKV-Mechanismus in seiner reinsten Form — auf 0,00–0,33 Needle-Retrieval bei lang gehaltenen Caches, weil die Wichtigkeit eines Tokens zum Eviction-Zeitpunkt noch nicht beobachtet wurde⁹. Ihre Lösung ist kein besserer Score, sondern eine andere Topologie: Die Top-m-Zeilen bleiben in einem attendierten Tier, alles andere wandert — exakt, nie gelöscht — in ein GPU-residentes Archiv. Die konvergente Lektion beider Papers: Der interessante Designraum ist nicht „bessere Wichtigkeitsschätzungen", sondern was strukturell nie verloren geht (Random Attention: der Prompt; VestigeKV: alles, nur eben womöglich abseits des Tiers) plus was die Wiederfindbarkeit tatsächlich bestimmt (Abdeckung und Redundanz, nicht Rang).

Die Durchsatz-Deltas. In vLLM auf einer H200 (1k-Token-Prompts, 32k-Generierungen, 128 Anfragen — Qwen3-32B auf 96 gedeckelt) liefert Random Attention: 2.046 gegen 1.494 Tok/s (Qwen3-4B), 1.737 gegen 1.212 (Phi-4-reasoning), 1.819 gegen 1.303 (Qwen3-14B), 923 gegen 700 (Qwen3-32B) — also 32–43 % über TriAttention bei identischer Genauigkeit und Budget (nachgerechnet: +37/+43/+40/+32 %) und das 1,6-fache bis 2,7-fache Full-Attention-Durchsatz². Der Mechanismus ist profan und wichtig: Bei 32k Tokens pro Anfrage begrenzt der KV-Cache, nicht die Rechenleistung, wie viele Anfragen gleichzeitig laufen — jedes Verdoppeln des Cache-Gewinns ist geteilt und langweilig. Die Rest-Reihenfolge macht die Scoring-Passe. Jede Eviction-Runde kostet unter Random Attention laut Paper gemessene 0,30 ms (es verdichtet nur), unter TriAttention aber 1,47–1,64 ms (es bewertet zuerst, Kandidaten-Keys durch vLLMs Blocktabellen, Schicht für Schicht); bei 128 parallelen Anfragen, die jeweils etwa alle 64 Tokens verdichtet werden, wird bei nahezu jedem Decode-Schritt irgendeine Anfrage verdichtet — und vLLM verdichtet an einem Synchronisationspunkt, heißt: Der ganze Batch wartet, während eine Anfrage bewertet. Ein paar Millisekunden mal Zehntausende Verdichtungseignisse — die Scoring-Passe frisst ein Drittel des Durchsatzes².

3. Die Mathematik: Warum kann eine Zufalls-Policy einer gelernten gleichziehen?

Dass eine Zufalls-Policy mit einer gelernten gleichzieht, sollte sich falsch anfühlen. Man schreibe aus, wann das nicht geht — und das Agenten-Setting beginnt zu ergeben.

Wo Zufall verliert: einmalig genannte Fakten. Wird eine bestimmte Tokenfolge später benötigt und kann ein Selektor sie identifizieren, garantiert zufälliges Behalten ihr Überleben nicht. Das Passwort-Experiment des Papers illustriert das: Random Attention scheitert in diesem Test, während R-KV den Code deutlich häufiger wiederfindet². Das ist Evidenz für den getesteten Probe-Task, keine Messung an Retrieval-Augmented Generation oder Agenten-Tool-Ausgaben. Eine Überlebenswahrscheinlichkeit von K/T pro Head bei einer einzelnen Ziehung ist nur eine Vereinfachung; wiederholte Evictions und mehrteilige Tokenfolgen ändern die tatsächliche Wahrscheinlichkeit.

Warum Zufall auf den getesteten Reasoning-Traces funktionieren kann. Prompt-Schutz erhält die ursprüngliche Frage, und das Modell wiederholt Arbeitsinformationen häufig während der Generierung. Unabhängige Ziehungen pro Head verteilen außerdem die behaltenen Positionen. Bei einer hypothetischen einzelnen Eviction mit H = 8 unabhängigen Heads und Behaltensquote p = 0,25 pro Head ist die Wahrscheinlichkeit, dass wenigstens ein Head eine bestimmte Position behält, 1 − (1 − p)^H ≈ 0,900. Das ist keine gemessene Erfolgswahrscheinlichkeit der Wiederfindung: Weitere Evictions, Abhängigkeiten zwischen Heads und eine brauchbare Repräsentation spielen ebenfalls eine Rolle. Das Planted-Fact-Experiment zeigt, dass mehrere überlebende Heads helfen können. Auf den getesteten MATH500-Traces schneidet jedoch sogar die Kontrolle mit derselben Zufallsziehung für alle Heads fast gleich ab; dort trägt die Redundanz im Text schon viel².

Eine deterministische scorebasierte Policy kann verschiedene Positionen pro Head auswählen, weil ihre Scores head-spezifisch sein können. Es wäre falsch zu behaupten, alle solchen Policies verwürfen denselben Token in jedem Head. Der kontrollierte Befund ist enger: Bei gleichem Prompt-Schutz und Cache-Budget steigern die getesteten scorebasierten Policies die Endgenauigkeit auf diesem Reasoning-Raster selten gegenüber zufälligem Behalten. Das Passwort-Experiment markiert eine Grenze, an der inhaltsabhängige Auswahl nützt.

Zu den absoluten Zahlen — warum Eviction auf diesen Workloads in Bytes von „nutzlos" bis „zwingend" reicht: Ein Qwen3-4B-Token kostet 2 · 2 Bytes · 8 KV-Heads · 128 Dims · 36 Schichten = 147.456 Bytes ≈ 144 KiB in fp16 (Qwen3-32B: 256 KiB pro Token). Ein 32.768-Token-Trace ist also 4,5 GiB (32B: 8,0 GiB) KV pro Sequenz — auf einer 141-GB-H200 ist das die Begrenzung der parallelen Anfragen, weshalb 4×-Kompression die Batch-Kapazität grob vervierfacht — ein Gewinn, den jede Evictor-Methode einheimst; wie viel davon am Ende in Durchsatz ankommt, entscheidet der Scorer (bei Random Attention: 1,6- bis 2,7-facher Full-Attention-Durchsatz). Die Bytes-Rechnung erklärt den gemeinsamen Speichervorteil bei gleichem Budget. In der gemessenen vLLM-Integration ist der Overhead der Wichtigkeitsbewertung ein wesentlicher verbleibender Durchsatzunterschied zwischen den verglichenen Evictors.

Nun das Argument, ausdrücklich als Argument und nicht als Fakt: Die Outlier-zentrierte Linie (H2O-Heavy-Hitter, VaSE-Value-Ränder, CurDKV-Leverage-Scores, TriAttention-Positions-Statistiken) hat ihre Evaluationsmethodik vom langen Kontext geerbt (Perplexity-artige und Long-Input-Benchmarks), wo die Nadel-Rahmung wörtlich ist — ein Fakt, einmal genannt, in einem langen Heuhaufen. Reasoning- und Agenten-Traces invertieren die Datenlage: kurzer Prompt, lange selbst generierte Ausgabe, der Cache füllt sich mit dem Restaten und Kopf-Duplizieren des Modells. Es ist eine plausible Hypothese — gestützt auf Tabellen 1 und 2 des Papers, das Planted-Fact-Experiment und konvergent auf VestigeKVs unabhängigen Befund, dass Auswahl nach beobachteter Attention (H2O, SnapKV) auf einem NoPE-MLA-Modell auf 0,00–0,33 Needle-Retrieval kollabiert, weil Wichtigkeit noch nicht beobachtet wurde⁹ —, dass ein erheblicher Teil der Eviction-Literatur auf eine Trace-Verteilung überindiziert ist, für die ihre Signale nie gebaut waren, und dass die Benchmark-Auswahl, nicht die Signalqualität, die berichteten Lücken trieb. Der letzte Satz ist unsere Schlussfolgerung, nicht die Behauptung des Papers; das Paper beweist sie nur für seinen Raster.

4. Was würde „Zufall genügt" widerlegen

Die ehrlichen Fehlermodi, in absteigender Sorge:

1. Workload-Scope. Alles oben gilt für Reasoning-Traces: kurzer Prompt, lange selbst generierte Ausgabe, Budget bei 2–4×-Kompression. Ein Needle-in-Haystack-RAG-Workload — lange Eingabe, viele Dokumente, einmal genannte Fakten — ist exakt das Niedrigrang-Regime, in dem Abschnitt 3 sagt, dass Zufall verlieren muss; das Passwort-Experiment in §5.3 des Papers ist eine Miniatur davon, und Zufall erzielt dort null. Wer „zufällige Eviction genügt" als Universalanspruch liest, liest das Paper über.
2. Der Prompt-Pinning-Confound ist das ganze Paper. Reduziert sich das Resultat auf „der Prompt zählt, frühere Baseline warfen ihn weg", ist das Delta ein Benchmark-Konstruktionsartefakt, und ein gelernter Scorer mit Prompt-Schutz könnte Zufall auf Workloads mit langen, teilweise nützlichen Prompts schlagen. Das Paper antizipiert das: Unter gematchtem Schutz liegen die geschützten Baselines auf mehreren Zellen dennoch 1–3 Punkte hinter Zufall — ein kleines, aber real existierendes Restdelta zugunsten von Zufall, das die stärkste Version der Behauptung ist. Aber TriAttentions Code-Sieg auf Qwen3-32B zeigt: Gelernte Signale sind nicht buchstäblich wertlos.
3. Ein-Framework-Deployment. Die 32–43 %- Durchsatzmarge ist in einer einzigen vLLM-Integration gemessen, und das Paper räumt ein, dass TriAttentions In-Framework-Scorer nicht gefused war („der dreifache Abstand zu TriAttention hier spiegelt eine ungefusste Neuimplementierung seines Scorers"). Ein gefuster Scorer-Kernel könnte große Teile der Effizienzmarge zurückholen; die Genauigkeits-Parität allerdings ist kernel-unabhängig.
4. Trace-Bias. Die sechs Tasks sind Mathe, Wissenschaft, Code — Domänen, in denen Modelle stark wiederholen. Agenten-Traces mit Tool-Call-Ausgaben (JSON-Payloads, Stacktraces, veraltete abgerufene Dokumente) enthalten weit mehr einmal-genannten, nie wiederholten Inhalt als Mathe; das Passwort-Experiment legt nahe, dass Zufall ihn verwirft. Tool-Call-Lücken sind zudem temporal strukturiert (Interaktionsgrenzen) — ein gelerntes Signal könnte sie nahezu kostenlos ausnutzen.
5. Replikation allgemein. Ein Paper, ein Labor, v1 bei Einreichung, drei Qwen3-Modelle plus Phi-4 — die Modellvielfalt ist dünner als die Taskvielfalt. SGLang-Replikation, GPT-OSS-/Llama-Familien-Modelle und die Agenten-Trace-Benchmarks 2027 sind allesamt offen.

5. Praktische Anleitung: Wann gelernte Eviction das Geld wert ist

Wo die Hit-Rate pro Byte aufhört zu zählen, sollte man aufhören, dafür zu zahlen. Die Entscheidung als Matrix über die zwei Arbeitslast-Achsen, die Abschnitt 3 als die eigentlich entscheidenden gezeigt hat:

In Prosa:

• Reasoning-Model-Serving unter Memory-Budget, hohe Trace-Redundanz, kurze Prompts: Prompt (und Sinks) pinnen, den Trace pro Head gleichverteilt zufällig verwerfen. Keine Kalibrierung, kein Tuning, keine Scoring-Passe — und es ist der Boden, den jedes neue Selektionssignal bei gematchtem Budget und gematchtem Prompt-Schutz schlagen muss². Die 32–43 %-Durchsatzmarge ist heute in vLLM real.
• Long-Context-Retrieval-Workloads (lange Eingabe, kurze Ausgabe): Das Nadel-Regime ist real, gelernte Signale verdienen dort ihren Score, und VestigeKV-artiges, query-unabhängiges Archiv-Tiering zeigt einen dritten Weg — in ein Tier auslagern statt löschen —, der auf Needle-Tasks sowohl Zufall als auch gescortes Verwerfen schlägt⁹. Der Scoping-Satz des Papers selbst: Sein Setting unterscheidet sich, weil „einem kurzen Prompt eine lange Generierung folgt, sodass der eigene Trace des Modells den Cache füllt"².
• Memory-Bandbreiten-gebundenes Decoding mit wenig Prefix-Sharing: Pro Sequenz begrenzt die Eviction-Qualität weiterhin die Genauigkeit pro Byte; ohne geteilte Präfixe und mit kurzen Sequenzen bringt Eviction wenig und riskiert OOM — wer aber verdichtet, für den ist der Scoring-Passe-Overhead, den das Paper quantifiziert (wenige ms pro Eviction-Runde × eine Verdichtung alle paar Decode-Schritte × Ganz-Batch-Synchronisations-Stalls), eine Serving-Durchsatz-Posten im Kostenschlüssel — einplanen.
• Agenten-Traces in Produktion: Der Schuh passt — hohe Prompt-/System-Präfix-Wiederverwendung, Tool-Call-Grenzen, wiederholte Pläne — überwiegend das zufallsfreundliche Regime, aber die Tool-Result-Payloads sind das Nadel-Risiko. Liest Ihr Agent fünfzehn Züge später eine Zahl aus einer Tool-Antwort, wurde dieser Wert genau einmal genannt; ein inhaltsabhängiges Signal (R-KV-artige akkumulierte Attention) ist der bekannte Weg, ihn zu behalten. Erst die eigenen Traces charakterisieren, dann wählen.

Die übertragbare Lektion ist nicht „Zufall gewinnt." Sie ist, dass das Paper das Problem neu rahmt: Die Eviction-Genauigkeit entscheidet sich daran, was man schützt, nicht daran, wie man den Rest rankt. Die offenen Fragen, die es hinterlässt — lange, teilweise Gerüst-Prompts budgetieren (Code-Prompts allein liefen 6× die Tokens von MATH500 unter demselben Tokenizer, bis zur Hälfte des Budgets²) und seltene einmal genannte Fakten zurückgewinnen — sind exakt dort, wo die nächste Runde echter Selektionsarbeit hin sollte. Und wer heute keine Zufall-mit-Prompt-Baseline im Eviction-Pipeline hat, weiß nicht, wie viel Genauigkeit der eigene Scorer kauft. Wahrscheinlich fast nichts. Nachmessen.

Quellen