6 篇文章 含有標籤「performance」

在過去兩週，我們處理了兩個重大的產品品質問題：

1. MCP Gateway 沒有單一的憑證解析類別。
2. 透傳 API 的記憶體消耗過高。

在同一期間，我們總共推出了 134 個錯誤修正。這篇文章先介紹這兩個重大變更，接著說明其餘的 AI 工程與可靠性工作、完整細目，以及我們接下來要做什麼。

最後更新：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，且會先在正式環境執行，然後下一條路由才開始。穩定性是優先事項，我們以每次發佈零回歸為目標。

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

我們涵蓋了安全強化、版本發布編號變更、新產品發布（MCP 工具集、on-behalf-of OAuth）、效能提升，以及我們迄今最大的一個押注——LiteLLM Agent Platform。

最後更新：2026 年 5 月

LiteLLM proxy 容器做了 2 件非常不同的事。它同時是 LLM 資料平面，/chat/completions，/v1/messages、embeddings、passthroughs，其延遲的額外負擔以個位數毫秒計算，且流量高量且突發。它也同時是 管理控制平面 — 金鑰、團隊、SSO、稽核記錄，以及驅動 dashboard 的支出／使用量分析，其中單一請求就可能掃描數百萬筆資料列。

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

我們如何透過替換單一、簡單的中介軟體基底類別，改善 LiteLLM proxy 的延遲與吞吐量

我們的設定​

LiteLLM proxy 伺服器有兩層中介軟體。第一層是 Starlette 的 CORSMiddleware（由 FastAPI 重新匯出），這是一個純 ASGI 中介軟體。然後我們還有一個名為 PrometheusAuthMiddleware 的簡單 BaseHTTPMiddleware。

PrometheusAuthMiddleware 的工作是驗證對 /metrics 端點的請求。它預設不啟用，您可以在 proxy 設定中透過旗標啟用：

litellm_settings:
    require_auth_for_metrics_endpoint: true

這個中介軟體會檢查兩件事：請求是否打到 /metrics，以及是否已啟用驗證？如果兩項檢查都未通過——而大多數請求都是如此——它就會直接原樣放行請求。

class PrometheusAuthMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        if self._is_prometheus_metrics_endpoint(request):
            if self._should_run_auth_on_metrics_endpoint() is True:
                try:
                    await user_api_key_auth(request=request, api_key=...)
                except Exception as e:
                    return JSONResponse(status_code=401, content=...)
        response = await call_next(request)
        return response

    @staticmethod
    def _is_prometheus_metrics_endpoint(request: Request):
        if "/metrics" in request.url.path:
            return True
        return False

看起來無害。繼承 BaseHTTPMiddleware，實作 dispatch()，完成。這正是您會在 Starlette 文件¹中看到的內容。

簡介​

我們第一季的效能目標，是在單一具備 4 顆 CPU 與 8 GB RAM 的執行個體上，積極朝次毫秒級 Proxy 額外負擔邁進，並持續擴大這個界線。我們更廣泛的目標，是讓 LiteLLM 具備低部署成本、輕量且快速的特性。本文說明支撐這項努力的架構方向。

Proxy 額外負擔指的是 LiteLLM 本身所引入的延遲，與上游提供者無關。

為了衡量它，我們以相同的 QPS（例如 1,000 QPS）直接對提供者與透過 LiteLLM 發出相同工作負載，並比較延遲差異。為了降低雜訊，負載產生器、LiteLLM 與模擬 LLM 端點都在同一台機器上執行，確保差異反映的是 Proxy 額外負擔，而不是網路延遲。