14 篇文章 含有標籤「incident-report」

日期： 2026 年 9 月 7 日至 2026 年 9 月 9 日
受影響版本： v1.100.0
嚴重性： 中等（單一客戶的生產環境中斷；影響範圍小，且需要無法連線的 Redis）
狀態： 已在 v1.100.1 中修正

注意： 如果您正在執行 v1.100.0，請升級至 v1.100.1 或更新版本。v1.99.1 及更早版本不受影響。v1.100.0 dev 與 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。

**日期：**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 使用系統訊息方式的一項文件不佳的變更，但客戶之所以使用閘道，正是因為不需要追蹤提供者的怪異行為。忠實轉譯請求（包括其快取語意）是我們的核心工作，而這次我們沒有做好。這篇文章會精確說明發生了什麼事、為什麼我們的測試與審查沒能抓到，以及我們做了哪些改變，避免這類回歸再次釋出。

2026 年 5 月 11 日，來自 Aikido Security 的資安研究人員發現了一起名為 "Mini Shai-Hulud" 的協同供應鏈攻擊，該攻擊發布了超過 170 個 npm 套件與 2 個 PyPI 套件的惡意版本，其中包括 mistralai==2.4.6。

LiteLLM 不受影響。 我們透過 httpx 直接經由 HTTP 呼叫 Mistral 的 API，且在程式碼庫中的任何地方都不會匯入 mistralai Python SDK。

重點摘要；​

• LiteLLM 不會安裝或匯入 mistralai 套件。 我們呼叫 Mistral 的 API 方式與呼叫其他所有提供者相同（透過 httpx）。這個遭入侵的套件在任何 LiteLLM 環境中都不會被執行。
• 這次攻擊未使任何 LiteLLM 使用者憑證面臨風險。 惡意程式在 import mistralai 時執行。由於 LiteLLM 從未觸發該匯入，因此負載永遠不會執行。
• LiteLLM 使用者無需採取任何行動。 如果您為了自己的應用程式程式碼，已在相同環境中另外安裝 mistralai==2.4.6，請立即遵循 Mistral AI 的指引。

日期： 2026 年 4 月 持續時間： 修正上線前，跨多個客戶部署發生多次事故 嚴重性： 高；在 Kubernetes 中表現為完整的 proxy 服務中斷 狀態： 已解決

注意： 此修正自包含 PR #26225 的版本開始可用（於 2026 年 4 月 29 日合併）。

摘要​

當上游 Postgres 資料庫變得無法連線時，LiteLLM proxy 的 Prisma 重連路徑會呼叫 await self.db.disconnect()。在 prisma-client-py 下，該呼叫會在 Rust query-engine 子處理程序上觸發一個同步的 subprocess.Popen.wait()。由於 wait() 不會讓出執行權，只要引擎關閉所需的時間，asyncio 事件迴圈就會卡死；在生產環境中，當引擎卡在對無回應資料庫的 TCP close 操作上時，這通常會持續 30–120 秒。

在迴圈凍結期間，沒有任何 coroutine 會執行，包括 /health/liveliness。Kubernetes 的存活探針逾時，kubelet 便以 SIGKILL 終止該 pod。從操作人員的角度來看，proxy 彷彿已經死亡，儘管根本問題其實只是 reconnect 邏輯本應撐過去的暫時性 DB 中斷。

影響： 任何 Postgres 短暫變得無回應的客戶，都會看到 proxy pod 被終止並重新啟動，而不是在 DB 恢復後優雅降級並重新連線。此問題由 FLock 對外回報，並在內部重現。

感謝所有參加我們 town hall 的人。

我們想利用那段時間說明我們目前所知、到目前為止已採取的行動，以及未來如何改進 LiteLLM 的發布與安全流程。這篇貼文是該更新的書面版本。 投影片請見此處

狀態： 調查進行中 最後更新： 2026 年 3 月 27 日

更新（3 月 30 日）： LiteLLM 的全新安全版本現已可用（v1.83.0）。這是由我們新的 CI/CD v2 管線發佈，該管線加入了隔離環境、更強的安全閘道，以及更安全的 LiteLLM 發佈分離機制。

日期： 2026 年 3 月 18 日 持續時間： 不明 嚴重性： 高 狀態： 已修復

摘要​

當自訂 guardrail 傳回完整的 LiteLLM request/data dictionary 時，LiteLLM 記錄的 guardrail 回應可能包含 secret_fields.raw_headers，其中包括含有 API 金鑰或其他憑證的明文 Authorization 標頭。

這些資訊接著可能傳播到會消耗 guardrail 中繼資料的記錄與可觀測性表面，包括：

• LiteLLM UI 中的 spend logs： 對可存取 spend-log 資料的管理員可見
• OpenTelemetry traces： 對任何可存取相關 telemetry 後端的人可見

LLM 呼叫、proxy 路由，以及提供者執行都不會因這個 bug 而被阻擋。影響是敏感請求標頭在可觀測性與記錄路徑中被暴露。

日期： 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 提供者的請求因連線錯誤而失敗。

日期： 2026 年 2 月 24 日
期間： 持續進行中（直到修正部署）
嚴重性： 高（適用於在不同 API 金鑰之間對 Responses API 進行負載平衡的使用者）
狀態： 已解決

摘要​

當在具有不同 API 金鑰的部署之間對 OpenAI 的 Responses API 進行負載平衡時（例如，不同的 Azure 區域或 OpenAI 組織），包含加密內容項目（例如 rs_... reasoning items）的後續請求會失敗，錯誤如下：

{
  "error": {
    "message": "The encrypted content for item rs_0d09d6e56879e76500699d6feee41c8197bd268aae76141f87 could not be verified. Reason: Encrypted content organization_id did not match the target organization.",
    "type": "invalid_request_error",
    "code": "invalid_encrypted_content"
  }
}

加密內容項目在密碼學上與建立它們的 API 金鑰所屬組織綁定。當路由器將後續請求負載平衡到使用不同 API 金鑰的部署時，解密就會失敗。

• 帶有加密內容的 Responses API 請求： 路由到錯誤部署時會完全失敗
• 初始請求： 不受影響。只有包含加密項目的後續請求會失敗
• 其他 API 端點： 沒有影響。Chat completions、embeddings 等功能皆正常運作

日期： 2026 年 2 月 23 日
期間： 約 3 小時
嚴重性： 高（適用於具有提供者萬用字元存取規則的使用者）
狀態： 已解決

摘要​

當將一個新的 Anthropic 模型（例如 claude-sonnet-4-6）加入 LiteLLM 模型成本對照表，並觸發成本對照表重新載入時，對新模型的請求會被拒絕，並顯示：

key not allowed to access model. This key can only access models=['anthropic/*']. Tried to access claude-sonnet-4-6.

重新載入正確更新了 litellm.model_cost，但從未重新執行 add_known_models()，因此 litellm.anthropic_models（供萬用字元解析器使用的記憶體內集合）仍然是舊資料。即使成本對照表已知曉該新模型，對 anthropic/* 萬用字元而言，它仍然是不可見的。

• LLM 呼叫： 對新加入的 Anthropic 模型的所有請求都遭到 401 阻擋。
• 既有模型： 不受影響。只有在過時的提供者集合中缺少的模型受到影響。
• 其他提供者： 對任何提供者萬用字元（例如 openai/*、gemini/*）都存在相同的錯誤類別。

日期： 2026 年 1 月 22 日 持續時間： 約 4 天（直到修正於 2026 年 1 月 26 日合併） 嚴重性： 高 狀態： 已修復

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

摘要​

一個 PR（#19467）意外地從 proxy_server.py 中的 FastAPI 應用程式初始化移除了 root_path=server_root_path 參數。這導致代理程式在提供 UI 時忽略 SERVER_ROOT_PATH 環境變數。當 LiteLLM 部署在具有路徑前綴的反向代理之後（例如 /api/v1 或 /llmproxy）時，使用者發現所有 UI 頁面都回傳 404 Not Found。

• LLM API 請求： 無影響。API 路由未受影響。
• UI 頁面： 使用 SERVER_ROOT_PATH 的部署中，所有 UI 頁面都回傳 404。
• Swagger/OpenAPI 文件： 透過設定的根路徑存取時無法運作。

日期： 2026 年 2 月 16 日 持續時間： 約 3 小時 嚴重性： 高（針對 vLLM embeddings 使用者） 狀態： 已解決

摘要​

一個原本用來修正 OpenAI SDK 行為的提交（dbcae4a）因為在 API 請求中明確傳入 encoding_format=None，導致 vLLM embeddings 失效。vLLM 會拒絕此項並顯示錯誤："unknown variant \`, expected float or base64"`。

• vLLM embedding 呼叫： 完全失敗 - 所有請求都被拒絕
• 其他提供者： 無影響 - OpenAI 與其他提供者皆正常運作
• 其他 vLLM 功能： 無影響 - 只有 embeddings 受影響

日期： 2026 年 2 月 13 日 持續時間： 約 3 小時 嚴重性： 高 狀態： 已解決

注意： 此修正將自 LiteLLM 的 v1.81.13-nightly 或更高版本開始提供。

摘要​

Claude Code 開始將不受支援的 Anthropic beta 標頭傳送給非 Anthropic 提供者（Bedrock、Azure AI、Vertex AI），造成 invalid beta flag 錯誤。LiteLLM 在未進行提供者特定驗證的情況下轉送了所有 beta 標頭。當透過 LiteLLM 將 Claude Code 請求路由至這些提供者時，使用者會遇到請求失敗。

• 對 Anthropic 的 LLM 請求： 無影響。
• 對 Bedrock/Azure/Vertex 的 LLM 請求： 在出現不受支援的標頭時，會以 invalid beta flag 錯誤失敗。
• 成本追蹤與路由： 無影響。

日期： 2026 年 1 月 27 日 持續時間： ~20 分鐘 嚴重程度： 低 狀態： 已修正

摘要​

model_prices_and_context_window.json 中一筆格式錯誤的 JSON 項目被合併到 main（562f0a0）。這導致 LiteLLM 悄悄回退到已過時的本機 model cost map 副本。使用較舊套件版本的使用者僅對較新的模型（例如 azure/gpt-5.2）失去成本追蹤。沒有任何 LLM 請求被阻擋。

• LLM 請求與 proxy 路由： 無影響。
• 成本追蹤： 受影響的僅是本機備份中未包含的較新模型。較舊模型不受影響。此事件持續約 20 分鐘，直到提交被還原。