6 篇文章 含有標籤「ai-gateway」

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

最後更新：2026 年 6 月

代理程式基礎架構已經開始分成三層：模型、harnesses，以及 runtime。我們認為第四層即將出現：統一的代理程式控制平面。這將能從一個地方呼叫存在於不同代理程式 runtime 中的代理程式。

原因在於，公司不會把每個代理程式都執行在同一個 runtime 上。程式碼代理程式可能會執行在 Bedrock AgentCore 或 Claude Managed Agents 上。資料代理程式可能會在 Elastic、Databricks，或 Snowflake 內執行。內部工作流程代理程式可能會執行在自建基礎架構上。控制平面之所以浮現，是因為公司希望有一個地方可以使用所有這些代理程式，不論它們是在何處建置或執行。

但只有登錄系統還不夠。任何人都可以建立一份代理程式清單。

更難的問題是呼叫。代理程式 runtime 會暴露類似的基本元素——代理程式、session、事件、工具——但它們不是透過相同的 API 暴露這些元素。所以如果您想要一個地方真正使用這些代理程式，而不只是列出它們，控制平面就必須管理代理程式 runtime、排程、記憶體，以及 session。

這和 LiteLLM 在模型上看到的模式相同。公司不只需要模型目錄，他們需要一個介面來呼叫它們。唯一的變化是，現在的基本元素是代理程式 session，而不是模型請求。

未來的堆疊​

重要的轉變是，閘道不再只是路由模型請求。它正在路由代理程式工作。

有了 LLM，堆疊變成了：

• 模型： GPT、Claude、Gemini、Llama
• 推論提供者： OpenAI、Anthropic、Bedrock、Vertex、Azure、vLLM
• 閘道： 路由、備援、記錄、支出追蹤、驗證、計費
• 應用程式： copilot、工作流程、內部工具、產品

有了代理程式，我們認為堆疊會變成：

• 模型： Claude、GPT、Gemini、開源模型
• harnesses： Claude Code、Codex、OpenCode、Hermes、DeepAgents
• 代理程式 runtime： Claude Managed Agents、Bedrock AgentCore、Gemini Enterprise Agent Platform、自架 runtime
• 代理程式控制平面： 多 runtime 平台，讓團隊管理代理程式 runtime、排程、記憶體，以及 session。
• 應用程式： 程式碼代理程式、支援代理程式、資料代理程式、安全代理程式

為什麼公司會需要這個​

在 LiteLLM，我們已經看到團隊在多個代理程式 runtime 之間協作。有些人正在 Claude Managed Agents 上開發，其他人則在 N8N 或 Cursor 上。

這種碎片化使得在這些平台上建立的代理程式很難被共享，也讓每個人都能受益於到目前為止所做的工作變得困難。

只要讓代理程式存在於一個地方，所有人都可以利用這些代理程式——即使 PR Babysitter Agent 是寫在 Claude Managed Agents 上，而不是每個人都能直接存取。

這就是控制平面問題。

這也是我們認為 AI 閘道會往上層移動的原因。閘道一開始是管理模型請求。但當代理程式成為 AI 的主流使用案例時，閘道也必須管理代理程式 session。

我們正在打造什麼​

LiteLLM Agent Platform 是我們在這個方向上的實驗。

LiteLLM Agent Platform 是一個以 Rust 為基礎的 AI 閘道與代理程式控制平面。目標是讓團隊能跨多個 runtime 註冊、呼叫、觀察並治理代理程式。

我們先從程式碼代理程式開始，因為需求非常明顯。它們是長時間執行、有狀態、工具密集，而且成本高到需要真正的基礎架構。

我們已經看到早期使用者對這種模式有共鳴。有些公司希望 LAP 作為不同團隊在不同 runtime 上建立的代理程式的中央控制平面。範例來說，一個團隊可能會在 Elastic 的 runtime 上建立一個代理程式來分析 Kibana 記錄，但公司可能希望透過共用閘道在內部公開這個代理程式。

這是我們認為即將到來的架構：模型變得可互換，harnesses 變得專門化，runtime 變得受管理，而閘道則成為代理程式工作的控制平面。

如果這和您看到的情況一致，我們很希望收到對 LiteLLM Agent Platform 的回饋：

https://github.com/LiteLLM-Labs/litellm-agent-platform

常見問題​

LiteLLM 會打造第二個產品嗎？​

不會。LAP 是一個實驗性專案。目標是快速學習，並隨著時間把合適的部分帶回 LiteLLM。

LAP 已可用於正式環境嗎？​

不行。LAP 仍處於 pre-v0。隨著我們和早期使用者及貢獻者合作，API 可能會變動。

如果您想要貢獻，請提出 issue 或加入我們的 Discord：

https://discord.gg/Nkxw3rm3EE

Harness 是提供者鎖定的下一個前沿。LiteLLM 的設計初衷是讓模型提供者之間能夠輕鬆切換。然而，隨著模型越來越飽和，下一個競爭領域就會變成 harness 與受管理的代理程式。為了讓您更容易在 harness 層切換提供者，我們推出 Lite-Harness SDK。這是一個簡單的 TypeScript+Python SDK，讓開發者能像切換模型一樣切換 harness。

它以統一的 Claude Agents SDK 規格公開各種 harness。這表示，如果您是用 Claude Agents SDK 撰寫應用程式，並且想試試其他 harness（Pi AI、Hermes、Codex、OpenCode），就可以在不重寫程式碼的情況下完成。

目前支援 3 種 harness——Claude Code、Codex 和 Pi AI。如果您希望我們新增其他 harness，請在這裡提出 issue。

運作方式如下：

TypeScript 範例

import { query } from "@lite-harness/sdk";

const prompt = "Fix the failing test";

// Claude Code harness
for await (const message of query({
  prompt,
  options: { harness: "claude-code", model: "claude-opus-4-8" },
})) {
  console.log(message);
}

// Codex harness
for await (const message of query({
  prompt,
  options: { harness: "codex", model: "gpt-5.5" },
})) {
  console.log(message);
}

Python 範例

from lite_harness import query, AgentOptions

prompt = "Fix the failing test"

# Claude Code harness
async for message in query(
    prompt=prompt,
    options=AgentOptions(harness="claude-code", model="claude-opus-4-8"),
):
    print(message)

# Codex harness
async for message in query(
    prompt=prompt,
    options=AgentOptions(harness="codex", model="gpt-5.5"),
):
    print(message)

LiteLLM AI 閘道​

Lite-Harness 支援透過 LiteLLM AI Gateway 代理 harness。這可讓模型切換、成本控制和記錄更容易。

請透過設定兩個環境變數，將 Lite-Harness 指向您的 gateway：

export LITELLM_API_BASE=https://litellm.your-company.com/v1
export LITELLM_API_KEY=sk-litellm-...

接著如常呼叫——每個底層模型請求都會經由 gateway 路由：

from lite_harness import query, AgentOptions

prompt = "Fix the failing test"

# Claude Code harness
async for message in query(
    prompt=prompt,
    options=AgentOptions(harness="claude-code", model="claude-opus-4-8"),
):
    print(message)

# Codex harness
async for message in query(
    prompt=prompt,
    options=AgentOptions(harness="codex", model="gpt-5.5"),
):
    print(message)

常見問題​

我一定要使用 LiteLLM AI Gateway 嗎？​

不需要。lite-harness 可獨立運作——只要將它指向使用原生金鑰的提供者 API。對於希望集中管理金鑰、預算、備援，以及跨所有模型呼叫的單一稽核記錄的團隊，AI Gateway 整合是可選的。

切換 harness 會改變代理程式行為嗎？​

會——這正是重點。每個 harness 都保有其原生迴圈、工具呼叫語義與提示格式。lite-harness 只是統一您「呼叫」它們的方式，而不是它們內部的運作方式。請用相同的提示在三者上執行，看看哪個組合最能完成任務。

這已準備好投入正式環境了嗎？​

lite-harness 是一個早期、實驗性的專案。目前處於公開 beta。歡迎加入我們的discord，協助我們依照您的偏好來設計它。

這在 LiteLLM OSS 中可用嗎？​

可以。lite-harness 採 MIT 授權，位於 github.com/LiteLLM-Labs/lite-harness。LiteLLM Enterprise 在其搭配的 AI Gateway 之上，提供 SSO/SCIM、air-gapped 部署、24/7 SLA，以及進階防護欄。

建議閱讀​

• LiteLLM AI Gateway — 完整功能總覽
• LiteLLM 受管理代理程式平台 — Alpha
• 跨 100+ LLM 提供者的負載平衡與路由

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

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

最後更新：2026 年 5 月

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

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

最後更新：2026 年 4 月

企業級 AI 閘道部署幾乎每個請求都會經過 Redis：速率限制、快取查詢、支出追蹤。當 Redis 健康時，其延遲貢獻只有個位數毫秒 — 使用者幾乎感受不到。當它劣化時，正式環境 AI 閘道無論如何都需要保持運作。

在 100+ 個 pod 上大規模執行 LiteLLM，意味著必須在故障模式出現之前先為它們設計。簡單的情況是 Redis 完全中斷：快速失敗、轉而使用資料庫、持續提供請求。困難的情況 — 也是會讓閘道停擺的情況 — 是 緩慢的 Redis：仍可接受連線、仍有回應，但每次操作都要 20-30 秒才逾時。