LiteLLM - 統一 100+ 大模型的開源 AI 閘道器

解決什麼

企業在接入多個 LLM 提供商時常遇到三大痛點:每家廠商 SDK 格式不同(OpenAI 的 messages vs Anthropic 的 prompt)、鑑權方式各異(API Key/IAM/OAuth)、成本和日誌分散難以統一管控。LiteLLM 通過統一閘道器層抹平差異,讓開發者用 OpenAI 的呼叫格式即可切換 100+ 模型提供商(包括 Bedrock、Azure OpenAI、VertexAI、國產通義千問等),同時在閘道器層實現虛擬金鑰管理、成本追蹤、速率限制和負載均衡。

為何火

該專案獲 Y Combinator W23 批次孵化,在 Hacker News 上因供應鏈攻擊事件引發廣泛關注:2026 年 7 月其 PyPI 包 1.82.7/1.82.8 版本被植入惡意程式碼,僅 import litellm 即觸發後門,攻擊者通過入侵創始人 GitHub 賬號推送惡意版本。事件暴露出兩點爭議:1) 專案維護者賬號安全管理存在漏洞;2) 攻擊者在 GitHub issue 區用數百個機器人賬號刷屏試圖壓制討論(類似 Trivy 專案遭遇的手法)。儘管官方已撤回惡意版本併發布安全公告,但社群對其依賴安全性產生質疑,部分使用者表示"即使只用輕量封裝也會遷移走"。

技術層面的吸引力在於其 Rust 核心 + Python SDK 架構實現了 8ms P95 延遲(1k RPS 壓測),且被 Stripe、Netflix、Google ADK 等大廠採用。統一介面讓團隊無需重寫程式碼即可在 GPT-4/Claude/Gemini 間切換,配合 Admin UI 視覺化管理金鑰和預算。

核心功能

• 多模型統一呼叫:支援 /chat/completions、/embeddings、/images 等 OpenAI 相容端點,覆蓋 100+ 提供商(含國內文心一言、智譜 GLM)
• 企業級管控:虛擬金鑰(Virtual Keys)隔離團隊許可權、預算告警、請求日誌持久化到 PostgreSQL、Guardrails 內容過濾
• 負載均衡與容錯:多模型間自動 fallback、基於延遲的智慧路由、速率限制防濫用
• Agent 協議支援:實現 A2A(Agent-to-Agent)協議,對接 LangGraph、Bedrock AgentCore 等框架
• 成本追蹤:即時計算 token 消耗費用,按使用者/團隊維度生成賬單報表

安裝

Python SDK 方式(適合直接整合到程式碼):

uv add litellm  # 或 pip install litellm

自託管閘道器方式(推薦生產環境):

# Docker Compose 啟動(需先配置 .env 檔案)
docker-compose up -d
# 或快速測試
uv tool install 'litellm[proxy]'
litellm --model gpt-4o  # 預設監聽 4000 埠

⚠️ 安全建議:生產環境務必鎖定版本號(如 litellm==1.93.0)並驗證 SHA256 雜湊,避免供應鏈攻擊風險。

適合誰

• 多雲 LLM 架構團隊:需要在 AWS Bedrock、Azure OpenAI、自建模型間靈活切換
• 成本敏感型企業:需要精細化追蹤各部門/專案的 LLM 呼叫費用
• 合規要求高的場景:需要自託管閘道器避免資料經過第三方 SaaS(如 Portkey)
• Agent 應用開發者:需要統一管理多個 AI Agent 的模型呼叫和鑑權

不適合:個人開發者若只用單一模型提供商(如純 OpenAI),直接用官方 SDK 更簡單;對供應鏈安全極度敏感的團隊可能需要 fork 後自行審計程式碼。

社群評價

Hacker News 討論熱度 938 點,但幾乎全是負面情緒:

• 安全恐慌:多名使用者表示"即使只 import 就觸發惡意程式碼,太可怕了",有工程師因 Chrome 預載入惡意域名被安全團隊誤判感染,不得不重置憑證和重灌系統
• 信任崩塌:評論指出"創始人和 CTO 的 GitHub 賬號被攻破"(krrishdholakia),攻擊者還在 issue 區用 100+ 機器人賬號刷屏壓制討論,手法與此前 Trivy 專案遭遇的攻擊類似
• 遷移意向:有使用者明確表態"只是用它做輕量封裝,現在會完全遷移走,風險不值得",反映出供應鏈攻擊對開源專案聲譽的長期傷害
• 技術細節:安全研究員在 PyPI Inspector 發現惡意程式碼連線 checkmarx.zone/raw 和 models.litellm.cloud/ 兩個 C&C 域名

儘管官方已撤回惡意版本並加強賬號安全(啟用 2FA、輪換 Token),但社群普遍認為此次事件暴露了專案在供應鏈防護上的薄弱環節。

選型對比

維度	LiteLLM	Portkey(商業)	Kong AI Gateway
部署方式	自託管/開源	託管 SaaS	自託管/企業版
模型覆蓋	100+ 提供商	50+ 提供商	主流模型
成本	免費(自維護)	按請求量收費	企業授權費
延遲	8ms P95	~20ms(經 SaaS 中轉)	取決於配置
供應鏈風險	曾遭攻擊需自審	SaaS 託管相對安全	企業級安全審計

取捨建議:若團隊有運維能力且需要完全資料自主權,LiteLLM 自託管是最佳選擇;若追求開箱即用和安全託管,Portkey 更省心但有廠商鎖定風險;Kong 適合已有 API 閘道器基礎設施的大型企業。

已知坑

1. 供應鏈安全:PyPI 包曾被植入惡意程式碼,生產環境必須鎖定版本並驗證雜湊值,建議通過 Docker 映象部署而非直接 pip 安裝
2. Issue 積壓嚴重:4044 個未關閉 issue 反映維護者響應壓力大,複雜問題可能得不到及時支援
3. 許可協議不明:GitHub 顯示 NOASSERTION,商用前需聯絡官方確認授權(企業版需付費)
4. 國內網路限制:部分提供商(OpenAI/Anthropic)需配置代理,且官方文件的某些示例域名可能被牆
5. 資料庫依賴:閘道器模式強依賴 PostgreSQL,需額外維護資料庫高可用;虛擬金鑰等功能必須啟用 STORE_MODEL_IN_DB=True
6. 配置複雜度:.env 需手動填寫所有提供商的 API Key,初次配置容易遺漏導致呼叫失敗

來源: GitHub BerriAI/litellm + Hacker News 討論 "Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised"