LiteLLM 推出 Rust 版輕量網關
LiteLLM-Rust 是一個用 Rust 寫的輕量 AI gateway，保留原本 config.yaml 與資料庫結構，目標是把 coding agent 的轉發延遲壓到 1ms 內。
LiteLLM-Rust 是一個給 coding agent 用的輕量 Rust AI gateway，保留 LiteLLM 原本設定與資料庫格式。
LiteLLM 這次不是改大功能。它是直接換 runtime。LiteLLM 推出 LiteLLM-Rust，主打和 Python gateway 共用 config.yaml 與資料庫 schema。目標也很直接：把 coding agent 的轉發開銷壓到 1ms 以下。
這種做法很務實。你不用重寫整套控管層。你只要換執行層。對常跑 Claude Code 這類 agent 的團隊來說，這種改法比再加一堆花俏功能更有感。
| 項目 | 內容 |
|---|---|
| 執行環境 | Rust |
| 相容性 | 共用 config.yaml 與 Postgres schema |
| 效能目標 | Claude Code 呼叫開銷低於 1ms |
| 目前支援 | E2B、Daytona |
| 授權 | MIT |
它到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
LiteLLM-Rust 的重點不是功能爆量。重點是相容。它吃同一份 config.yaml，也用同一套 Postgres schema。這表示原本的 keys、virtual keys、teams、budgets、routing rules 和 fallbacks，大多都能照舊保留。
講白了，這對平台團隊很重要。gateway 最怕的就是你只是想換 runtime，結果 auth、routing、觀測、預算控制全都要重做。那不是升級，那是搬家。LiteLLM 想把這件事變得像換容器一樣單純。
它還把啟動方式做得很像原本 Python 版本。像是 litellm-rust --config /etc/litellm/config.yaml --port 4000 這種指令，就很像真的要進 production，而不是只給 demo 看。
- 共用
config.yaml - 共用 Postgres schema
- 沿用 client SDK 與管理流程
- 保留 routing 與 budget 這些核心能力
這種設計很像在說一件事：先別談新功能，先把切換成本壓低。對開發者來說，這通常比口號有用多了。
為什麼 1ms 很在意
這次鎖定的對象很明確，就是會一直打 API 的 coding agent。像 Claude Code 這類工具，常常在一個任務裡發出很多次模型呼叫。每次多個幾毫秒，累積起來就很煩。
LiteLLM 說 Rust 版想把 request forwarding 的熱路徑壓到 sub-millisecond。這不是什麼華麗指標，但很實際。因為 agent 工作流裡，延遲不是單次成本，而是整段流程的乘數。
“Do one thing, and do it well” — Doug McIlroy
這句話放在這裡很剛好。LiteLLM-Rust 沒打算現在就取代完整 Python gateway。它先做一件事：把轉發層做薄。對 agent 工作負載來說，這比再塞一堆 dashboard 功能更合理。
- 目標：每次 Claude Code 呼叫低於 1ms
- Python gateway 被描述為毫秒級開銷
- agent 任務可能有數十次工具呼叫
- 每次少一點延遲，整體體感差很多
如果這個數字真的能在真實負載下守住，開發者會先感受到等待時間變短。這種改善很土，但很有感。
現在能用什麼，還缺什麼
目前 LiteLLM-Rust 已經支援 E2B 和 Daytona 的 sandboxing。它也支援用 cron、webhook 或 API trigger 來排程 Claude Code 執行。換句話說，它已經不只是 proxy，還開始碰 agent 執行協調。
但它還很早期。LiteLLM 列出的 roadmap 也很清楚，像 durable sessions、memory、artifacts 和 vault 都還在後面。這些東西才是把一次性 agent 變成長流程的關鍵。
如果你有做過 agent 專案，就知道 state 才是麻煩本體。模型呼叫本身不難。難的是上下文、權限、輸出保存、重試與恢復。這也是為什麼 gateway 不能只會轉請求。
- 目前可用：E2B sandboxing
- 目前可用：Daytona sandboxing
- 目前可用：cron、webhook、API trigger
- 規劃中：durable sessions、memory、artifacts、vault
這個方向很符合現在的 agent 趨勢。大家不再只做聊天介面。大家在做可執行的工作流。誰能把這層管好，誰就比較接近真正的基礎設施。
它跟 Python 版怎麼分工
LiteLLM 的態度很保守，也很合理。Python gateway 還是官方主力。它是 production-grade，也還是企業部署的推薦選項。若你需要 SSO、SCIM、air-gapped 部署、24/7 SLA 和更完整的 guardrails，LiteLLM 也把 LiteLLM Enterprise 放在那裡。
這種切法不奇怪。Rust repo 是獨立專案。它比較像實驗線。先測 agent-first 的 runtime 設計，再把學到的東西帶回主產品。這樣做比硬把所有需求塞進同一個 runtime 穩得多。
對團隊來說，選擇也很清楚。你要成熟與完整，就留在 Python。你要測低延遲與簡化執行路徑，就看 Rust。兩條線都合理，問題只在你現在要哪一種。
- Python LiteLLM：功能完整，偏企業部署
- LiteLLM-Rust：輕量，偏 agent 轉發
- Enterprise：SSO、SCIM、SLA、air-gapped
- Rust repo：MIT 授權，適合試驗
我覺得這種分工比硬推單一方案聰明。因為 AI 基礎設施本來就不是一種工作負載。有人要穩，有人要快，有人兩個都要。
產業脈絡其實很清楚
AI infra 最近的變化，不是在模型本身，而是在周邊層。gateway、router、sandbox、memory、artifact，這些東西越來越重要。因為真正上線的不是聊天機器人，而是會動手做事的 agent。
這也解釋了為什麼 Rust 會一直被拿來做基礎設施。它不是萬靈丹，但在高併發、低延遲、少記憶體的場景，確實很合適。尤其是轉發層，很多時候就是該越薄越好。
接下來要看的，不是 LiteLLM-Rust 會不會變成全能平台。那很可能不是它的目標。要看的，是有多少團隊願意為了省掉每次呼叫的幾毫秒，去換一個更簡單的執行層。
如果你現在就在跑 coding agents，我會先問一件事：你卡的是模型品質，還是基礎設施延遲？很多團隊其實兩邊都卡，只是平常先罵 prompt，沒空看網路層。
接下來該看什麼
LiteLLM-Rust 最值得觀察的，不是 demo 跑得多順，而是能不能無痛接進既有環境。只要 config 與 schema 真能沿用，遷移成本就會低很多。
真正的測試會在負載下發生。等它遇到更多 agent、更多工具呼叫、更多重試，1ms 這個目標才會知道是不是只是口號。若你有在做類似架構，現在就值得拿來比對一次。
我的建議很直接：先挑一條非核心 agent 流程試跑，再看延遲與穩定性。別一開始就全站切換。這種東西，先驗證路徑，再談擴大部署，會比較不容易踩雷。