KV Cache Eviction Can Hide LLM Failures in Production

はい。KV cache eviction は LLM の失敗を隠す可能性があります。サービングポリシーが重要だった attention state を破棄し、保持された cache だけでは損傷の大きさを推定するのに十分な情報がなくなる場合があるためです。

2026年7月23日に投稿された論文は、この問題の境界を明確に示しています。決定論的で value-blind な top-k eviction では、保持された state だけから、それによって生じた attention-output error を一貫して推定することはできません。提案された代替手法では、破棄された tail の確率サンプルを保持し、推定誤差を中心とした統計的な証明を構築します。この手法は報告された実験で failure attribution を改善しましたが、prototype は低速で、実験は 16K context と 8B parameters までにとどまり、end-to-end の answer correctness は証明していません。

導入前に、同じ固定済みリクエストに対して、候補となる各 cache treatment を full-cache control と比較してください。full cache では成功し、候補では失敗したケースを数えます。eviction、quantization、offload、reuse は別々にテストし、各比較で1つの誤差要因だけを切り分けられるようにします。

読者レベル: 上級者向け。このガイドでは、transformer inference、attention、基本的な model evaluation を理解していることを前提とします。

目次

KV cache eviction が失敗を隠す理由

Attention output は、保持された entry と、ポリシーによって削除された entry の両方に依存します。決定論的なポリシーが tail を破棄した後では、選択された set しか見えない monitor は、欠落した value を調べられません。

ArXiv:2607.21475 は、この observability problem を研究しています。この negative result が対象とするのは、決定論的で value-blind な top-k eviction です。保持された state だけでは、eviction によって生じた attention-output error を一貫して推定できません。この結果は、すべての決定論的ポリシーが poor output を生成するという意味ではありません。この policy class は、保持した情報だけを使って、自身が生じさせた error を信頼性高く証明できないという意味です。

提案手法は、破棄された tail に関する evidence を保持します。本来なら消える entry を Poisson-sample し、Hájek correction を適用し、その推定値を retained-set variance certificate と組み合わせます。

測定結果: Error certificate は、12,096 個の attention replay cell にわたって 0.97 の coverage を記録しました。別の real-workload study では、failure attribution のテストに約 74,000 generations を使用しました。その study では、certificate は cache-induced failure と inherent model failure を区別する AUC 0.73–0.75 を達成しました。同じ attribution task で、output confidence は 0.47–0.54 に達しました。

測定結果: Output confidence のほうが overall failure の予測に優れていました。2つの signal は異なる問いに答えます。

推論: Low output confidence を cache-regression alarm として単独で使うことはできません。原因を特定せずに weak answer を検出する可能性がある一方、cache policy が有用な state を削除した後でも、confident answer が変化する可能性があります。

この論文は、negative result と operational result も報告しています。事前登録された7つの claim のうち3つが失敗しました。Prototype は token あたり 0.043 秒かかりました。これは deterministic eviction の 0.023 秒、full cache の 0.015 秒と比較した値です。実験対象は、最大 16K の context、最大 8B の model、単一ターンの proxy でした。著者らは、certificate と end-to-end task correctness を結び付ける theorem を提示していません。

実務上の解釈: Certificate は、研究対象となった条件下での attribution signal として扱ってください。production readiness を証明するものではありません。

4つの cache treatment、4つの信頼性に関する問い

チームは複数の intervention を「KV cache optimization」としてまとめがちです。しかし各 intervention は inference の異なる部分を変化させます。

ArXiv:2607.08057 の system-aware survey は、この分野を temporal scheduling、spatial placement and migration、structural representation and retention に分類しています。この taxonomy は evaluation boundary としても機能します。full-cache BF16 control と evicted FP8 candidate を比較すると、2つの structural variable が同時に変化します。候補が失敗しても、regression の原因が eviction、quantization、または両者の interaction のどれなのかは特定できません。

実務上の解釈: 各 cache intervention を独立した experiment としてテストしてください。個別の treatment が合格してから、それらを組み合わせます。

より有用な state を保持するポリシー

他の2つの論文は、同じ memory budget でより多くの quality を保持できる policy design を示しています。いずれも universal production threshold は提供していません。

VaSE, arXiv:2606.03928 は、高 magnitude の value state を保護しながら stochastic diversity を保持します。Qwen3-4B と Qwen3-14B を6つの reasoning task で評価した結果、約 4× の cache compression を達成し、最も強い eviction baseline を 4.4 points と 4.9 points 上回りました。16K、single-A100 の構成の1つでは、3.1× tokens per second に達しました。

これらの測定は decode のみ、Qwen3 model、production batching なしという条件に限られます。別の model family、serving engine、concurrency level、workload で同じ gain が得られることは示していません。

K-VEC, arXiv:2606.29563 は、attention head と layer 間の retention coverage を調整します。Llama 3.1 8B を16個の LongBench subset で評価した結果、budget が `B=128` のとき、score を最大 10.35 points、平均 1.61 points 改善しました。この evaluation は1つの model family と1つの benchmark suite を使用しており、この手法は prefill work を追加します。

実務上の解釈: Value-aware、stochastic、coverage-aware な policy は evaluation の候補として検討する価値があります。full-cache run は、引き続きローカル環境における source of truth です。

Quantization に別の control が必要な理由

FP8 KV cache quantization は token を削除するのではなく、precision を下げます。その error は engine error が発生しなくても application に到達する可能性があります。

2026年4月22日に公開された official vLLM FP8 investigation では、long-context needle accuracy が BF16 cache の 91% から、two-level accumulation fix 前の FP8 で 13% に低下したと報告されています。この fix により accuracy は 89% に回復しました。報告された最良の FP8 configuration では、decode slope は BF16 の 54% でした。

測定結果: ある numerical path では severe regression が発生し、kernel-level correction によって失われた accuracy の大部分が回復しました。

確立されていない点: FP8 cache が普遍的にこの regression を引き起こすことも、同じ speedup を提供することも示されていません。結果は implementation、model、hardware、attention path、benchmark に依存します。

vLLM issue #37554 は、限定的な warning を追加します。報告者は hybrid model で、silent な corrupted FP8 KV scaling を発見しました。この bug report から、FP8 や hybrid architecture に関する一般的な主張を導くことはできません。

4月7日の LocalLLaMA discussion には、cache format と quality に関する相反する practitioner report が含まれています。これらの report は test case の候補を示すことはできますが、rollout の判断は controlled evaluation に委ねる必要があります。

The vLLM v0.26.0 release は7月25日付で、212 contributors による411 commits を含み、KV tiering、offload metrics、cache reuse に関する visibility を拡大しています。Release activity と新しい observability feature は、広範な production adoption や correctness を証明するものではありません。

ペアリングした full-cache validation workflow

「full cache」は、追加の eviction や cache quantization を行わない、model 本来の attention behavior と定義します。各 pair 内では、model weights、tokenizer、runtime version、attention backend、sampling settings、prompt tokens、output validator を固定してください。

1. Ablation matrix を実行する

少なくとも4つの treatment を使用します。

A と D だけを比較すれば combined regression は明らかにできますが、原因を割り当てることはできません。Run B と C が不足している control を提供します。

サポート対象となるすべての model、runtime、kernel、hardware path を個別にテストしてください。vLLM FP8 の結果は、「FP8 enabled」のような label だけでは reliability decision に十分な詳細がない理由を示しています。

*Caption: ペアリングした full-cache validation により、eviction や quantization を production に導入する前に、候補だけで発生する failure を分離できます。*

2. Workload matrix を固定する

実際の request shape をもとに matrix を構築し、boundary case を含めます。

Long-context workload には synthetic needle test だけでは不十分です。product が code agent や extended workflow を実行する場合は、代表的な trace を含めてください。Token volume と workflow shape は、More Tokens, Better AI — and the Compute Bill と Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6 で説明されている economics に影響します。

3. Request を pair にし、cache state を分離する

次の evaluation logic を使用します。

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)

この block は pseudocode であり、engine-specific API ではありません。複数の answer が正解になり得る場合は、text equality ではなく task validator を使用してください。適切な validator には、generated code の unit test、structured output の schema check、exact tool-and-argument check、retrieval assertion、事前登録した rubric などがあります。

Cache namespace は分離してください。treatment 間で再利用された prefix state は、comparison を汚染する可能性があります。

4. Candidate-only failure を測定する

次の primary metric を使用します。

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

Denominator は full-cache success を条件とした rate です。両方の run が失敗した pair は、cache compression が failure を引き起こしたことを示しません。

すべての critical slice について、raw numerator と denominator を報告してください。1つの aggregate では、maximum context、特定の model、または特定の attention backend における regression が隠れる可能性があります。Output confidence と cache-attribution signal は異なる failure mode を扱うため、paired metric と併せて total failure rate も追跡してください。

5. Decision rule を事前に宣言する

候補の結果を見る前に、最大許容 rate `τ` を決めます。Critical task には、より厳しい rule を設定してください。再現可能な candidate-only failure は、aggregate が `τ` 未満であっても、tool、safety、transaction path での rejection を正当化する場合があります。

Cache configuration は execution policy に含めます。deterministic AI-agent permissions で使われている discipline、つまり明示的な configuration、observable decision、enforcement が失敗した場合の repair path によって記録し、適用してください。

導入判断

Release-note activity、anecdotal report、average benchmark gain は、paired rollout gate の代わりにはなりません。

現在の evidence の限界

最も強い certificate result が対象とするのは、single-turn proxy 下の attention-output error であり、end-to-end application correctness ではありません。実験は 16K と 8B で止まっていますが、production system はより大きな model、より長い context、複数ターン、tool、batch を実行する可能性があります。また、測定された prototype は、報告された setup では deterministic eviction と full cache より token あたりの処理時間が長くなっています。

VaSE と K-VEC は、特定の model、task、budget、serving setup に依存しています。vLLM の evidence は、implementation detail が cache-format result を左右し得ることを示しています。これらの source のいずれも、universal safe compression ratio を提供していません。

実務上の解釈: Research は candidate policy と monitoring signal を選ぶために使ってください。Paired full-cache validation は、あなたの implementation が workload に対する reliability limit を満たすかどうかを判断するために使います。

Claim checks

Sources