Open WebUIコミュニティがキャッシュ圧縮の改善を提案、長い会話の要約で10万超のトークンが再計算される可能性

Open WebUIコミュニティは11月1日、要約処理によってキャッシュ済みの長い会話履歴が再処理される可能性があるとして、会話圧縮の改善を提案した。提案者はApple Silicon、oMLX、Qwen 27Bの環境で、約11.7万トークンの会話について、通常はキャッシュを利用して約4秒で応答が始まる一方、圧縮リクエストは6分後も完了しなかったと報告した。この2つの値は、それぞれ最初の応答までの時間と、完了していない処理の待ち時間であり、速度向上率に直接換算することはできない。元の提案

提案者は原因として_generate_summaryを挙げている。この処理では、会話履歴を1つのユーザーメッセージに平坦化したうえで、要約用プロンプトを適用する。テキストの内容が似ていても、モデルに送られるトークン列のプレフィックスは変わってしまう。プレフィックスキャッシュは共通のプレフィックスを利用してKV状態を再利用する仕組みだ。vLLMの公式ドキュメントによると、この仕組みが削減するのは入力のプリフィル計算であり、新しいトークンの生成時間を直接短縮するものではない。これは技術的な背景を示すもので、oMLXの事例を独立して検証した結果ではない。キャッシュの仕組み

提案では、既存のシステムプロンプト、ツール、メッセージの並びを維持し、末尾に要約指示を追加する方法を勧めている。提案者によれば、ローカルプロキシでリクエストを書き換えたところ、入力トークン117,316個のうち116,736個がキャッシュにヒットし、約99.5%を占めた。要約は99.6秒で完了した。ただし、これは特定の環境における一人の提案者の計測値だ。公開されたissueにはプロキシの完全な実装が添付されておらず、どの推論サービスでも同じ結果が得られることは示されていない。計測結果と提案

推論出力も別の課題だ。11月2日には別のユーザーが、圧縮リクエストでは思考を個別に無効化できるよう求めた。推論テキストが要約に含まれる可能性があり、生成量の増加によって待ち時間も長くなるとの報告があった。ローカル環境では、専用の要約モデルに切り替えると、メモリ使用量やモデル切り替えのコストが増える可能性もある。後続の要望

確認時点で、2件のissueはいずれもオープンのままで、公開済みの性能改善とは見なせない。開発チームは、要約リクエストのキャッシュヒット数、プリフィル時間、推論と要約本文それぞれのトークン配分、要約でタスク上の制約が保持されるかを追跡するとよい。通常のチャット速度だけを測ると、長い会話が圧縮段階に入った際のコストを見落とす可能性がある。