研究代理程式在讀完每個頁面的前 8,000 個字元後，就能完成一份報告。如果其網頁工具在來源中途截斷，而代理程式自行補齊空缺，您就會得到一個完成的執行，卻帶有未經證實的主張。

在成千上萬次執行中，您需要找出受影響的工作階段，以及它們的共同點。LiteLLM Lens 使用代理程式來完成這項工作。

以下說明其幕後運作方式：審查者會平行檢視執行結果，分組代理程式會連結相關觀察，而調查員會將每個候選模式與原始追蹤結果比對。

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

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

Published: Oct 3, 2026

Tin LoAI Product Engineer, LiteLLM

在 BerriAI，我們打造了 Moyai Devin，一個在雲端執行的內部工程代理程式。團隊成員可以在 Slack 中交辦任務、在網頁應用中追蹤進度，並請它準備 pull request。

本週，我們將 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 倍。

最後更新：2026 年 9 月 18 日

Auto Router 在選定的模型能回應之前，必須先為分類付費。在我們的基準測試中，TypeSafe JEV 分類請求的速度比 Haiku 快 5.43 倍，比較的是分類器中位延遲：126.81 ms 對 688.40 ms。依登錄表定價的分類器成本低 96.12%，在標題中四捨五入為 96%

JEV 與我們基準測試中預期的層級相符率為 95.00%，Haiku 則為 73.75%。此結果取決於此處使用的提示、層級定義、指示與上下文。預期層級是以合成提示撰寫，未經獨立審查。此比較不代表一般分類準確度，亦不代表最終答案的品質

Auto-Router 可以在請求從簡單工作變成較困難的任務時，在不同層級之間移動對話。Responses API 用戶端可能會讓這種切換變得困難，因為先前的回應可能包含只有建立它的部署才能解密的加密推理內容

LiteLLM 現在會保留可讀的歷史記錄，並移除新選定層級無法驗證的加密推理。請求可以繼續送往所選模型，而不是因為 invalid_encrypted_content 而失敗

這項修正已包含在 LiteLLM v1.102.x 發行線，並已合併於 PR #40280

在 CLI 中預測快取成本、按層級設定速度、讓團隊管理 routers，並查看所選模型與節省金額。

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

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

我們已更新 Auto-Router，以因應 Claude Code 和 Codex 封裝請求的方式。現在它會從分類中移除更多 harness 上下文、保留加密的委派任務，並清楚顯示分類器實際收到的內容

Heuristic v1 會為七個提示信號評分，包括推理語言、程式碼、技術詞彙與提示長度。您可以針對路由器所處理的流量調校這些信號。

這個實驗性的路由器會依代理程式所處的階段為每個回合選擇模型，在 SWE-bench Verified 子集合上，以比固定 Claude Opus-5 低 46% 的成本，達到相同品質。

complexity router 的 LLM 分類器現在可以比您的模型呼叫更積極地壓縮。在內部測試中，這讓分類成本在共享壓縮原本已節省的基礎上再降低 32%，且路由準確度沒有變化。

Heuristic v2，LiteLLM 的新 AutoRouter 分類器，效率最高可比 Heuristic v1 高 45%：以更低成本，在更短時間內解決更多任務。 只有分類器改變了。

LiteLLM Auto Router Fusion 在 21 個 Terminal-Bench 任務中解決了 14 個；Claude Fable-5 單獨則解決了 9 個。 Fusion 會在多個模型上平行執行任務，並由其中一個模型將候選成果綜合成單一答案。兩個分支都執行了相同的 21 個任務。

Auto-Router 會先詢問請求有多難，來挑選模型。這次版本新增了接下來緊接著的問題：請求是否適合我們挑選的模型，而該模型是否真的看得到它？

我們已展示 Auto-Router 在正式環境節省 51% 以及 疊加 prompt caching 節省 69%。接下來我們最常聽到的問題總是相同：「它在我的流量上也能維持品質嗎？」

您可以預期從第一天起使用 Auto Router 大約可減少 40% 的成本，隨著 tier maps 的調整還會更多。我們的一位正式環境使用者分享了他的統計數據，展示在大規模下會是什麼樣子。

他們將 Auto-Router 部署到 dev、staging 和 prod 執行個體中的 450+ 位使用者，並節省了 $12,249，涵蓋 270k+ 次請求。

自動路由器在 Terminal-Bench 2.0 的 21 個任務子集上，以 27% 更低的成本達到與 Claude Opus-5 相同的解題率。 每個 arm 都執行相同的 21 個任務，因此比較是同類相較。

我們讓設定與測試 Auto-Router 比以往任何時候都更容易，而且透過可自訂的層級名稱 + 分類器系統提示，您可以超越複雜度路由。

是的，您可以在 Auto-Routing 中使用 prompt 快取。 兩者是相輔相成，而非彼此抵消。我們在五個資料集上進行了測量，其中兩個會回報提供者的快取實際做了什麼。

自動路由承諾在不降低答案品質的前提下，讓帳單更小。我們以把每個請求都送往 claude-opus-5 的基準來衡量兩個面向：8,619 個評分過的提示，以及對 14,000 則真實對話的成本模擬。

最後更新：2026 年 7 月

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

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

我們的目標是用代理程式將公司的生產力提升 10 倍。

三週前，我們開始打造一個能夠承接 30% 工程票券的代理程式。以下是截至目前我們的所學。

最後更新：2026 年 4 月

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

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

CI/CD v2 現已於 LiteLLM 上線。