事件報告：重試麵包屑記憶體成長導致 v1.100.0 發生 OOM
日期： 2026 年 9 月 7 日至 2026 年 9 月 9 日
受影響版本： v1.100.0
嚴重性： 中等（單一客戶的生產環境中斷；影響範圍小，且需要無法連線的 Redis）
狀態： 已在 v1.100.1 中修正
注意： 如果您正在執行
v1.100.0，請升級至v1.100.1或更新版本。v1.99.1及更早版本不受影響。v1.100.0dev 與 rc 預發行版本、v1.101.0-dev.1，以及v1.101.0-dev.2都存在相同缺陷；v1.101.0-rc.1及更新版本不受影響。
摘要
在 2026 年 9 月 7 日至 2026 年 9 月 9 日期間，一位在 nginx 後方執行 litellm-database:v1.100.0 的企業客戶，經歷了其 proxy 叢集中兩波核心 OOM kill：依客戶統計有數十次 kill，某個 worker process 的 RSS 達到 61 GB，而平台停機期間則出現數千次 HTTP 502 與數萬次 HTTP 499。
這必須同時滿足兩個條件：客戶流量所使用的提供者持續失敗，因此 router 不斷重試；同時 Redis 無法連線，因此每個完成的請求都會將那些重試的累積結果完整記錄下來。重試之所以無界增長，是因為 PR #38133（8 月 24 日）的一行變更，將重試麵包屑——router 為每次失敗的 LLM 嘗試保留的紀錄——在儲存前先經過一個既有的憑證遮罩 helper。這個 helper 對其原始輸入是正確的，但它假設自己是在複製一棵普通樹；麵包屑不是樹，它包含一個指回即將被追加到其中的同一個 list 的指標。若在不保留該共享參照的情況下複製它，就會把自 2023 年 12 月以來在記憶體中成本為零的結構，變成每次重試都大約加倍的結構；直到一個成本追蹤錯誤處理器在 Redis 中斷期間，於每個請求上都把它轉成 log 字串，而單次配置最終達到 27 GB。
我們在 PR #39491 中修正了底層成長問題，該 PR 於 9 月 3 日合併，並納入 v1.101.0-rc.1。該修正未在兩天後該版本被標記為 stable 之前回補到 v1.100.0。我們於 9 月 9 日將其回補到 stable/1.100.x（PR #40455），並發布 v1.100.1。
我們完全承擔這個結果。這個缺陷以我們本可發現的形式存在；在 stable release 前三天提交的一張 ticket 正確指出同一段程式碼路徑中的成長問題，而我們自己的修正 PR 又把那張 ticket 中一個未經測試的推測，變成了明確陳述的事實。本文其餘部分會說明這些事情是如何發生的，以及我們正在做哪些改變，確保這類缺陷不會再以同樣方式進入 stable release。