Dify 社群討論上下文壓縮與快取衝突，效能數據尚未在 Dify 重現

Dify 儲存庫於 10 月 26 日出現一項效能調查提案，要求檢查代理的上下文壓縮是否破壞前綴快取。回報者表示，自家代理在建立摘要請求時移除舊的封存檢查點，使提示前段與先前請求不一致，造成大量 token 重新進行預填運算。不過，作者隨後明確說明，量測環境是 Apple M3 Ultra、256 GB 記憶體上的 oMLX，並非 Dify。來源：社群提案

這項疑慮有明確的推論機制依據。vLLM 的前綴快取會重用相同提示前綴的 KV 區塊，其雜湊包含前一區塊的雜湊與目前區塊的 token。因此，即使後段文字相同，前段內容改變仍可能阻斷後續區塊重用。這類快取主要節省輸入的預填計算，無法直接縮短生成每個新 token 的解碼時間。來源：vLLM 設計文件、功能說明

討論的技術價值也在於釐清數據。提案最初列出命中率從 10.1% 提升至 99.6%、首 token 延遲大幅下降的結果；但作者補充，不同統計層級不能直接混用。最新提供的連續日誌中，一般請求、摘要請求與下一輪請求的命中率分別約為 99.5%、96.9% 與 99.6%。摘要請求仍有 4,989 個未快取 token，首 token 延遲為 17.94 秒；這組紀錄展示的是保留前綴後的高命中狀態，並未單獨證明最初效能差異的完整因果。來源：後續日誌與討論

對工程團隊而言，可採取的驗證方式是串接觀察壓縮前、摘要請求及壓縮後首輪，逐筆記錄快取 token、未快取輸入與首 token 延遲，再比對實際送往模型的訊息前綴。保留歷史有利於重用快取，也會牽涉上下文容量與摘要目的，不能直接套用為通用修法。截至查核時，議題仍開放，尚無關聯修補 PR；下一步應關注 Dify 專屬重現與回歸測試。來源：議題狀態