11 篇文章 含有標籤「performance」

LiteLLM 一直在長對話中數算每一個 token，只為了回答一個是或否的路由問題。

移除這項不必要的工作後，在我們本機 44 萬 token 的基準測試中，首字回應時間中位數從 553 毫秒降到 35 毫秒：降低 94%。

本週，我們將 LiteLLM proxy 上一個請求等待 Redis 的次數從 22 次降到 8 次。

一個來自具有預算之金鑰、位於具有預算與 TPM/RPM 限制之團隊、針對採用依使用量路由與 Redis 回應快取之模型群組的請求，原本會造成 22 次 Redis 往返：模型呼叫前 12 次、之後 10 次。相同的請求、相同的檢查與相同的寫入，現在只需 前 5 次、後 3 次。

本週，我們將 LiteLLM Usage 頁面大約加快了 120 倍。

在 5,000 個 API 金鑰的情況下，我們的 Usage 頁面顯示 30 天總計所花的時間超過六分鐘。我們重新設計了資料載入方式，並在我們的基準測試中將其縮短到3.2 秒。這大約是快了 120 倍。

一個與 LiteLLM 共同完成的除錯故事，以及後續的發行測試。

LiteLLM 版本升級暴露出一個長期存在的 Redis 設定錯誤，讓 Pfizer 的 gateway 吞吐量降低了約 48%，而應用程式記錄中完全沒有 HTTP 錯誤。以下說明團隊如何透過設定二分搜尋將其隔離出來，以及雙方正在建立的測試基礎架構，目的是在這類回歸上線前就先捕捉到。

最後更新：2026 年 7 月

我們正在推出 LiteLLM AI Gateway 的 Rust 早期 beta 版，並建立了 AIGatewayBench 來將其與 Portkey、Bifrost 以及目前的 LiteLLM Python proxy 進行比較。四者之中，LiteLLM Rust 閘道具有最低的 p99 額外延遲與明顯最小的記憶體占用：相較於下一個最接近的閘道（Bifrost），額外負擔大約低 7x、記憶體少 9x，且具有最低的成本占用，以及對 coding agents 而言最快的整體工作階段時間。它在原始持續吞吐量上表現不遜色，並在額外負擔、記憶體與成本方面明顯領先。

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

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

把兩者跑在同一個 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 額外負擔，而不是網路延遲。