11 篇文章 含有標籤「reliability」

感謝所有參加我們 9 月 town hall 的朋友。我們介紹了產品中的安全性更新、穩定性更新與新功能，包括預設在 Rust 上執行的 OCR，以及超過我們 8 月設定的 80% 目標的測試覆蓋率。

自 LiteLLM v1.102.0-rc.1 起，OCR 預設在 Rust 上執行。

感謝所有參加我們八月 town hall 的人。我們在會中分享了本月的安全性與穩定性工作，以及最新的產品更新：79 項安全修補、375 項 bug 修復、142 個功能 commit、新任安全總監、公開狀態儀表板，以及來自 production 的 Auto-Router 結果。

感謝所有參與我們 7 月線上大會的人。我們藉此分享本月的安全與穩定性工作，以及最新的產品更新：38 項安全修補、317 項錯誤修正、140 個功能提交，重點包括新的 Rust 基準測試與 Autorouter V2 的推出。

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

這個月有三個數字最能代表：24 項安全修正、94 個 Bug 修正，以及 78 項功能提交。以下各節將逐一說明，並介紹我們對零已回報回歸的公開承諾，以及 LiteLLM 閘道逐步遷移至 Rust 的進展。

最後更新：2026 年 6 月

在過去一年中，我們從使用者與社群聽到同樣的聲音：他們想要能執行的最快、最輕量的 AI 閘道。我們聽到了。現在我們正透過將 LiteLLM 遷移到 Rust 來回應，並承諾將額外負擔降到低於 1ms、記憶體低於 100MB 的可部署二進位檔。到了這次遷移完成時，您將擁有一個純 Rust 伺服器，能承載您 100% 的 AI 流量，且每個熱路徑操作（包含驗證與速率限制）都在 Rust 中執行。

之所以重要，是因為在真實負載下，CPU 與記憶體會隨著並行度上升，而 pods 會在最糟糕的時候被 OOM-kill。今天 LiteLLM Python proxy 在負載下的記憶體峰值約為 359MB，而這個成本會隨著您執行的每個 pod、區域與重試而倍增。

我們已經在基準測試中看到成效。Rust 閘道的吞吐量約為 15x（每秒 453 到 6,782 個請求），使用的記憶體約少 11x（359MB 到 32MB），且將每次請求的額外負擔從 Python 路徑上的約 7.5ms 降到約 0.05ms，遠低於我們承諾的 1ms。

您會得到什麼​

您部署單一 Rust 二進位檔。它使用約 65MB 的記憶體，閘道額外負擔維持在 1ms 以下，而您的設定中沒有任何東西會改變：相同的 config.yaml、相同的資料庫、相同的用戶端 API、相同的提供者。您保留 LiteLLM 對 100+ 個 LLM 提供者的涵蓋，並透過一個 OpenAI 相容 API 提供，包含 /chat/completions、/messages、/responses，以及 LiteLLM 今天支援的其他每個 LLM 端點，如今成為您能自行主機部署的最快、最輕量 LLM 閘道。

這不是 v2，也不是重寫。沒有新的主要版本需要遷移，也沒有任何東西要您更改。熱路徑下的執行階段會變得更快、更輕量，而您的設定會維持完全不變。

我們會以謹慎的方式發布。每條路由只有在通過我們完整的對等與端到端測試套件後才會移到 Rust，且會先在正式環境執行，然後下一條路由才開始。穩定性是優先事項，我們以每次發佈零回歸為目標。

最後更新：2026 年 5 月

LiteLLM proxy 容器做兩件非常不同的事。它既是 LLM data plane，/chat/completions、/v1/messages、embeddings、passthroughs，這些工作的延遲開銷以個位數毫秒計算，而且流量量大且具突發性。它同時也是金鑰、團隊、SSO、稽核記錄，以及支撐儀表板的支出／使用量分析的 管理控制平面，其中單一請求就可能掃描數百萬列資料。

把兩者跑在同一個 event loop 上，控制平面做得最慢的事情，就會決定資料平面最快的事情能達到的可靠性下限。這篇文章說明我們如何透過提供 componentized deployment 模型，提升 LiteLLM 在大規模下的可靠性。

日期： 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 對外回報，並在內部重現。

最後更新：2026 年 4 月

企業級 AI 閘道部署將 Redis 放在幾乎每個請求的熱路徑上：速率限制、快取查詢、支出追蹤。當 Redis 正常時，延遲影響僅有個位數毫秒，終端使用者幾乎察覺不到。當它劣化時，正式環境中的 AI 閘道就必須不受影響地持續運作。

在 100+ 個 Pod 上大規模執行 LiteLLM，意味著必須在失敗模式出現之前先為其設計。簡單的情況是 Redis 完全當機：快速失敗，回退到資料庫，繼續提供請求服務。困難的情況，也是會拖垮閘道的情況，是 緩慢 的 Redis：仍然接受連線、仍然回應，但每次操作都會在 20 到 30 秒後逾時。

感謝所有參加我們 4 月 town hall 的朋友。

我們在這次會議中分享了 CI/CD v2 的改進、產品穩定性工作，以及接下來在可靠性與產品藍圖上的優先事項。

隨著 LiteLLM 的採用持續成長，外界對可靠性、效能與營運安全性的期待也隨之提高。要滿足這些期待，不能只靠以正確性為中心的測試，還需要驗證系統在真實世界條件下，隨時間推移會如何表現。

這篇文章介紹 LiteLLM Observatory，這是我們打造的一套長時間執行的發佈驗證系統，用來在回歸問題到達使用者之前將其攔截。