コーディングエージェントによるllama.cppの大規模プロンプト再処理：KVキャッシュとコンテキストスワップのデバッグ

r/LocalLLaMAの開発者が、llama-swap経由でllama.cppを利用し、長文コンテキストのコーディングエージェント（opencode + pi.dev）を実行中に深刻なパフォーマンス問題に直面しています。プロンプトの類似度が非常に高い場合でも（LCP類似度が>0.99であることが多い）、システムが定期的にKVキャッシュを破棄し、40k以上のトークンを再処理して、TTFTが数分に及んでいます。

観測された動作

• コンテキストが50kトークン以上に成長。
• 数回の正常な再利用（例：prompt eval time = 473 ms / 19 tokens）の後、n_pastが突然約4〜5kに低下。
• その後、llama.cppが全プロンプトを再処理：n_tokens = 4750 prompt eval time = 222411 ms / 44016 tokens。
• キャッシュ使用量が4676 MiBに達し、設定された制限（2500 MiB）を超過。

現在の設定

llama-server --ctx-size 150000 --parallel 1 --ctx-checkpoints 32 --cache-ram 2500 --cache-reuse 256 -no-kvu --no-context-shift

推定原因

• --cache-ramの上限オーバーフローによるキャッシュ無効化 – ログに4676 MiB使用、2500 MiB制限超過と表示。
• 初期プロンプトトークンが変更された場合のKV再利用メカニズムの不具合（opencodeによる頻繁な変更の可能性）。
• 150kのコンテキストサイズに対して--ctx-checkpointsまたは--cache-reuseが不十分。

コミュニティからの推奨事項

スレッドにはまだ回答が少ないが、明らかな最初の手順としては、--cache-ramを典型的な使用量に合わせて増やす（例：5000+ MiB）、または--ctx-sizeを減らしてキャッシュ制限内に収めること。また、opencodeが意図的にプロンプトプレフィックスを変更していないか確認し、変更している場合はシステムプロンプトを固定するか、固定プレフィックスを使用することで再利用性が向上する可能性がある。

同様の設定を実行している開発者は、ソーススレッドで動作している設定を共有してください。