4 篇文章 含有標籤「caching」

是的，您可以在 Auto-Routing 中使用 prompt 快取。 兩者是相輔相成，而非彼此抵消。我們在五個資料集上進行了測量，其中兩個會回報提供者的快取實際做了什麼。

**日期：**2026 年 7 月 4 日至 2026 年 7 月 10 日
受影響版本： v1.91.0 和 v1.91.1
嚴重性： 中等（靜默成本回歸；不影響正確性）
狀態： 已在 v1.91.2 修正

注意： 如果您透過 LiteLLM 在 Amazon Bedrock 上執行 Claude Code，且使用 v1.91.0 或 v1.91.1，請升級至 v1.91.2 或更新版本。

摘要​

在 7 月 4 日到 7 月 10 日之間，執行 v1.91.0 或 v1.91.1 的代理程式，會在透過 Amazon Bedrock 的 Invoke API 路由 Claude Code 工作階段時，靜默破壞 Anthropic 提示快取。對於回報此問題的客戶而言，暖工作階段的快取命中率從大約 90% 降到 25% 到 45%，而團隊每日支出在相同用量下上升了 2 到 3 倍。請求仍然回傳 200，且完成內容正確；唯一的症狀是快取未命中率與帳單。

原因是：PR #31364 將 role: "system" 中每個 messages 項目移到 Invoke 路徑上的頂層 system 欄位，這會讓工具定義與系統提示之後的每個快取斷點失效。修正已於 7 月 10 日隨 v1.91.2 釋出（#32578、#32831、#32882），並附上在修正前程式碼上會失敗的回歸測試。

這個結果完全由我們承擔。觸發因素是 Claude 新模型與 Claude Code 使用系統訊息方式的一項文件不佳的變更，但客戶之所以使用閘道，正是因為不需要追蹤提供者的怪異行為。忠實轉譯請求（包括其快取語意）是我們的核心工作，而這次我們沒有做好。這篇文章會精確說明發生了什麼事、為什麼我們的測試與審查沒能抓到，以及我們做了哪些改變，避免這類回歸再次釋出。

LiteLLM 現已支援在 Valkey 上進行語意提示快取。如果您執行的是搭載 valkey-search 模組的 Valkey 叢集（包括 AWS ElastiCache for Valkey），您可以透過 type: valkey-semantic 將 LiteLLM 指向它，並取得基於嵌入的快取命中，而無需架設 Redis Stack 或獨立的向量資料庫。

日期： 2026 年 2 月 27 日 持續時間： 約 6 天（2 月 21 日合併 -> 2 月 27 日修正） 嚴重性： 高 狀態： 已解決

注意： 此修正自 LiteLLM v1.81.14.rc.2 或更高版本開始可用。

摘要​

一項用於改善 Redis 連線池清理的變更引入了迴歸問題，會關閉仍被 proxy 積極使用的 httpx 用戶端。LLMClientCache（一個記憶體中的 TTL 快取）將 Redis 用戶端與 httpx 用戶端都存放在相同的驅逐政策下。當快取項目過期或被驅逐時，新的清理程式碼會對被驅逐的值呼叫 aclose()/close()；這對 Redis 用戶端運作正確，但會摧毀系統中其他部分仍持有參考且正在用於 LLM API 請求的 httpx 用戶端。

影響： 任何命中快取 TTL（預設 10 分鐘）或容量上限（200 筆項目）的 proxy 實例，都會在其下方被關閉 httpx 用戶端，導致對 LLM 提供者的請求因連線錯誤而失敗。