LRUはKVキャッシュ論文が示唆するより手強い
LRU is harder to beat than the KV-cache papers suggest
68,266件のClaude CodeリクエストとMooncakeの23,608件をプレフィックスキャッシュシミュレータで再生し、LRUを3通りで超えようとして失敗。キャパシティ圧迫下では再計算の33.1%が10秒以内のツールループ由来で、5分TTLは一度も発火せず。TTL律速と容量律速では最適化すべき対象が逆になる。
キャパシティが律速する場合、それはTTLを支配し、引き起こされる再計算はアイドルセッションの話とは似ても似つかない。
HNでの議論
56- chaboud
私はしばらくレイテンシに敏感なLLMシステムを構築してきて、ping-pongでオーバーラップする非同期コンテキスト構築のような、pre-fillを考慮したメカニズムに大きく依存するようになった。インタラクティブなメカニズムでは、たとえ稀であっても最悪のケースは問題になる。
おもちゃ/簡略化したバージョンはここにある：
https://github.com/chaboud/goulash
そこには変異率の考慮（一種の時間的なShannon的符号化/順序付け）が含まれている（RoPEに優しい構造化もいくつか）。注：これは休暇中のプロジェクトであり、本業ではないが、同様の原則はより大きなモデルでも当てはまる。
- augment_me
私が少し腹立たしく感じるのは、そしてこのような明らかにLLMが実行したアブレーションが捉え損ねていると感じるのは、先行研究についての何らかの考察や、これが最善であるという何らかの証明だ。あなたには分からない、レバーを引いて何かを得た、それが最善なのか？もっと良くできるのか？制約は何なのか？
個人の研究者として、あなたには問題に対して大規模な総当たり探索を実行するための2200万ドルはない。あなたは自分の小さなサブスクリプションに制約され、問題の可能な解決策の海にほとんど足先を浸すことしかできない。だからClaudeにあなたの問題に対して自動研究ループを実行させ、それを要約させても、LRUキャッシュの欠点やトレードオフが何であったか、どうすれば解決できるかを知らないのだから、価値はゼロだ。
- eru
> それはうまくいかなかった、そしてなぜうまくいかなかったかは、そのポリシーがあったであろうよりも興味深いことが判明した。
さすがClaudeの言い回しだ。
皮肉はさておき、我々のAIエージェントがこうした実験を安価に行い、人々がついにnull findingsを公表する気になるようなこれらの記事を公表できるようにしてくれたことは嬉しい。とても役に立つ！
- talolard
私はneocloudで推論に取り組んでいるが、意見は私個人のものである。
経済性、ひいては推論に投入できるツールは、さまざまなスケールで変化する。
「露骨な」作為的な例として、gb300ではGPUがnvlinkを介して超高速で通信し、カードはKVキャッシュをDRAMに、そしてディスクにオフロードできる。これらのツールを多用するエージェント的ワークロードには「十分速い」。
これらが相まって、十分に高いスケールと適切なシナリオでは、KVキャッシュに非常識なTTLを設定しても、SLAとトークンエコノミクスを余裕で満たせるということになる。
- bob1029
LRUはLLM関連のほとんどのものにとって理想的な戦略のように思える。この領域のすべてはrecency biasに関するものだ。これはこの文脈では問題ではなく特徴だと思う。
長期にわたるタスクについてエージェントに修正情報を与えるとき、私が最後に望むのは、それが新しい情報であるという事実を統計的に補正しようとすることだ。私はこの新しい情報に古い情報を支配してほしい。