Difyコミュニティでコンテキスト圧縮とキャッシュの競合を議論、性能データはDifyで未再現

Difyのリポジトリでは10月26日、エージェントのコンテキスト圧縮がプレフィックスキャッシュを損なうか調査する提案が出された。報告者によると、自作エージェントが要約リクエストを作成する際に古いチェックポイントを削除したため、プロンプトの先頭部分が以前のリクエストと一致しなくなり、多数のトークンでプリフィル計算が再実行されたという。ただし作者は後に、測定環境はApple M3 Ultraと256 GBメモリを搭載したマシン上のoMLXであり、Difyではないと明言した。出典：コミュニティ提案

この懸念には、明確な仕組み上の根拠がある。vLLMのプレフィックスキャッシュは、同一のプロンプトプレフィックスに対応するKVブロックを再利用する。そのハッシュには前のブロックのハッシュと現在のブロックのトークンが含まれる。そのため、後半のテキストが同じでも、前半の内容が変わると後続ブロックの再利用が妨げられる可能性がある。この種のキャッシュが主に削減するのは入力のプリフィル計算であり、新しいトークンを生成する際のデコード時間を直接短縮するものではない。出典：vLLM設計ドキュメント、機能説明

この議論の技術的な価値は、数値の意味を明確にした点にもある。提案の初版では、ヒット率が10.1%から99.6%に上昇し、最初のトークンが返るまでの遅延が大幅に低下したと報告されていた。しかし作者は、異なる集計レベルの数値をそのまま比較できないと補足した。後から提示された連続ログでは、通常リクエスト、要約リクエスト、次のターンのリクエストのヒット率は、それぞれ約99.5%、96.9%、99.6%だった。要約リクエストには未キャッシュのトークンが4,989個残り、最初のトークンが返るまでの遅延は17.94秒だった。この記録が示すのは、プレフィックスを保持した場合の高いヒット率であり、当初報告された性能差の因果関係全体を単独で証明するものではない。出典：追加ログと議論

エンジニアリングチームが検証するには、圧縮前、要約リクエスト、圧縮後の最初のターンを一連の流れとして観測し、各リクエストのキャッシュ済みトークン数、未キャッシュの入力数、最初のトークンが返るまでの遅延を記録したうえで、モデルに実際に送信されたメッセージのプレフィックスと照合するとよい。履歴の保持はキャッシュの再利用に役立つ一方、コンテキスト容量や要約の目的にも関わるため、一般的な修正方法としてそのまま適用することはできない。確認時点では、issueはオープンのままで、関連する修正PRもない。次は、Dify固有の再現と回帰テストに注目する必要がある。出典：issueの状態