7 篇文章 含有標籤「reliability」

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

三個數字概括了這個月：24 個安全性修正、94 個 bug 修正，以及78 個功能提交。以下各節將逐一拆解，並說明我們對零已回報回歸的公開承諾，以及 LiteLLM gateway 逐步遷移到 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 容器做了 2 件非常不同的事。它同時是 LLM 資料平面，/chat/completions，/v1/messages、embeddings、passthroughs，其延遲的額外負擔以個位數毫秒計算，且流量高量且突發。它也同時是 管理控制平面 — 金鑰、團隊、SSO、稽核記錄，以及驅動 dashboard 的支出／使用量分析，其中單一請求就可能掃描數百萬筆資料列。

把兩者跑在同一個 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 事件迴圈會凍結，直到引擎關閉所需的時間為止——在生產環境中通常是 30–120 秒，因為引擎在對失去回應的資料庫進行 TCP close 操作時卡住。

在迴圈凍結期間，沒有任何 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，這是我們打造的一套長時間執行的發佈驗證系統，用來在回歸問題到達使用者之前將其攔截。