Open WebUI 社群提出壓縮快取改進，長對話摘要可能重算逾十萬 token

Open WebUI 社群於 11 月 1 日提出對話壓縮改進請求，指出摘要流程可能重新處理已快取的長篇歷史。作者在 Apple Silicon、oMLX 與 Qwen 27B 的環境中回報：約 11.7 萬 token 的對話，平常利用快取約四秒開始回應，壓縮請求卻在六分鐘後仍未完成。兩者分別是首段回應時間與尚未完成的等待時間，不能直接換算加速倍率。原始提案

作者將原因指向 _generate_summary：流程把歷史訊息攤平成單一使用者訊息，再套入摘要提示。即使文字內容相近，送入模型的 token 前綴也已改變。前綴快取依賴共同前綴重用 KV 狀態；vLLM 官方文件亦說明，這類機制省下的是輸入預填運算，無法直接縮短新 token 的生成時間。這提供技術背景，但並非對 oMLX 個案的獨立驗證。快取機制說明

提案建議保留原本系統提示、工具與訊息排列，在尾端追加摘要指令。作者表示，透過本機代理改寫請求後，117,316 個輸入 token 中有 116,736 個命中快取，約占 99.5%，摘要於 99.6 秒完成。這仍是單一作者、特定環境的量測；公開議題未附完整代理實作，也未證明各推論服務都能得到相同結果。量測與方案

另一項限制是推理輸出：11 月 2 日另有使用者要求讓壓縮請求單獨關閉思考，回報推理文字可能進入摘要，且額外生成拖長等待。對本機部署而言，改用專用摘要模型又可能增加記憶體占用或模型切換成本。後續需求

截至查核，兩案均仍開放，不能視為已發布的效能改善。工程團隊值得追蹤摘要請求的快取命中量、預填耗時、推理與正式摘要的 token 分配，以及摘要是否保留任務限制；只量測一般聊天速度，可能漏掉長對話跨入壓縮階段的成本。