Auto Router：使用我們的 Fuse LLM 分類器將品質與節省最大化
我們透過結合複雜度與能力評估來改進 Fuse V2，以了解每個模型在哪些情況下成功、失敗，以及何時需要升級。
12 篇文章 含有標籤「benchmarks」
檢視所有標籤Auto Router：25 個 SWE-bench 任務降低 45% 成本
我們使用 LiteLLM 的實驗性能力路由器，以 $11.15 解決了 25 個 SWE-bench Verified 任務中的 23 個。若所有 solver 請求都使用 Opus 5，我們以 $20.27 解決了 23 個任務。包含分類器請求在內，兩次執行皆啟用提示快取，我們總共少花了 45%。
AutoRouter：為您的流量調校啟發式規則
Heuristic v1 會為七個提示信號評分，包括推理語言、程式碼、技術詞彙與提示長度。您可以針對路由器所處理的流量調校這些信號。
子任務專屬路由：相同品質，成本降低 46%
這個實驗性的路由器會依代理程式所處的階段為每個回合選擇模型，在 SWE-bench Verified 子集合上，以比固定 Claude Opus-5 低 46% 的成本，達到相同品質。
介紹 AutoRouter Heuristic v2：以 45% 更低成本解決多 27% 的任務
Heuristic v2，LiteLLM 的新 AutoRouter 分類器，效率最高可比 Heuristic v1 高 45%：以更低成本，在更短時間內解決更多任務。 只有分類器改變了。
介紹 LiteLLM Fusion：比 Fable 5 多解決 56% 的任務
LiteLLM Auto Router Fusion 在 21 個 Terminal-Bench 任務中解決了 14 個；Claude Fable-5 單獨則解決了 9 個。 Fusion 會在多個模型上平行執行任務，並由其中一個模型將候選成果綜合成單一答案。兩個分支都執行了相同的 21 個任務。
Auto Router：以最高達 27% 更低成本達成 Opus 等級品質
自動路由器在 Terminal-Bench 2.0 的 21 個任務子集上，以 27% 更低的成本達到與 Claude Opus-5 相同的解題率。 每個 arm 都執行相同的 21 個任務，因此比較是同類相較。
Auto Router v1.97：使用量基準測試與更低成本下的更佳品質
🚀 協助塑造 Auto-Router
v1.97 對 auto router 做了三項變更。
- LLM 分類器現在會接收一段先前對話輪次，預設為三輪。這將追問分類的準確率從 14% 提升到 78%，成本最高為每 1,000 次請求 $0.61，且不增加額外延遲。
- 新的 Benchmarks 檢視會以 all-frontier 基準為您的路由流量定價並回報差異，這些節省現在也會出現在 Cost Optimization 總計中。
- session affinity 現在預設為關閉，這符合我們先前的文章所示：這會導致品質變差，且沒有成本改善。
兩個預設值已變更
classifier_context_window_size 現在預設為 3（僅 LLM 分類器），而 session_affinity 現在預設為 false（所有 routers）。設定檔不會被修改，但新預設值會套用到任何尚未設定的鍵，因此從未提及 session_affinity 的設定，在升級後會重新分類每一輪。明確設定任一鍵值的設定不受影響。
Prompt 快取可與 Auto Router 搭配使用
是的，您可以在 Auto-Routing 中使用 prompt 快取。 兩者是相輔相成，而非彼此抵消。我們在五個資料集上進行了測量，其中兩個會回報提供者的快取實際做了什麼。
以近乎前沿模型的品質，將 Claude Code 成本降低 75%
自動路由承諾在不降低答案品質的前提下，讓帳單更小。我們以把每個請求都送往 claude-opus-5 的基準來衡量兩個面向：8,619 個評分過的提示，以及對 14,000 則真實對話的成本模擬。
LiteLLM Rust AI Gateway 基準測試：額外負擔、記憶體與成本
最後更新：2026 年 7 月
我們正在推出 LiteLLM AI Gateway 的 Rust 早期 beta 版，並建立了 AIGatewayBench 來將其與 Portkey、Bifrost 以及目前的 LiteLLM Python proxy 進行比較。四者之中，LiteLLM Rust 閘道具有最低的 p99 額外延遲與明顯最小的記憶體占用：相較於下一個最接近的閘道（Bifrost），額外負擔大約低 7x、記憶體少 9x，且具有最低的成本占用，以及對 coding agents 而言最快的整體工作階段時間。它在原始持續吞吐量上表現不遜色，並在額外負擔、記憶體與成本方面明顯領先。
將 LiteLLM 遷移至 Rust - 打造最快、最輕量的 AI 閘道
最後更新：2026 年 6 月
在過去一年中，我們從使用者與社群聽到同樣的聲音：他們想要能執行的最快、最輕量的 AI 閘道。我們聽到了。現在我們正透過將 LiteLLM 遷移到 Rust 來回應，並承諾將額外負擔降到低於 1ms、記憶體低於 100MB 的可部署二進位檔。到了這次遷移完成時，您將擁有一個純 Rust 伺服器，能承載您 100% 的 AI 流量，且每個熱路徑操作（包含驗證與速率限制）都在 Rust 中執行。
想幫助我們打造它嗎？
我們正在開放早期 beta，並希望直接與重視快速、輕量閘道的團隊合作。如果您正是這樣，請在此註冊，我們會讓您在自己的堆疊中測試 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，且會先在正式環境執行，然後下一條路由才開始。穩定性是優先事項，我們以每次發佈零回歸為目標。