Litelm: LiteLLM 的極簡替代方案
Litelm 是一個極簡主義的 Python 函式庫，旨在提供 LiteLLM 的核心路由與翻譯功能，而不具備原專案的龐大功能集。它將程式碼庫縮減至約 2,900 行，並且僅依賴兩個主要的依賴項目：openai 與 httpx。
核心功能與 API
Litelm 為模型路由、訊息翻譯、串流、工具使用與嵌入（embeddings）提供了一條精簡的路徑。它被設計為 LiteLLM 的直接替換方案（drop-in replacement），鏡像了其函式名稱、參數與回應類型。這使得開發者只需透過更改 import 語句即可從 LiteLLM 切換到 Litelm。
支援的功能
- 模型路由：將
provider/model語法映射到正確的 API 端點。 - 訊息翻譯：處理包括 Anthropic、Bedrock、Cloudflare 與 Mistral 在內的供應商的格式轉換。
- 串流：支援串流回應並包含
stream_chunk_builder。 - 工具使用：支援函式呼叫（function calling）與工具定義。
- 嵌入 (Embeddings)：為嵌入模型提供路由與翻譯。
- 文本補全 (Text Completions)：支援標準的文本補全端點。
- OpenAI 回應 API：維持與 OpenAI 風格的回應物件相容性。
已移除的功能
為了實現輕量化的足跡，Litelm 移除了 LiteLLM 中常見的幾項高階管理功能：
- Router Class：沒有內建的負載平衡或自動回退（fallbacks）機制。
- Proxy Server：沒有整合的代理伺服器功能。
- 快取與預算管理：沒有內建的快取、成本追蹤或支出管理。
- Token 計數：沒有整合的 token 計數工具。
- 進階模態：不支援影像生成、音訊、OCR 或微調（fine-tuning）。
- Agents 與 Guardrails：沒有整合的代理框架、排程器或護欄機制。
供應商支援與整合
Litelm 使用 provider/model-name 語法支援 19 個供應商。它也支援任何與 OpenAI 相容的端點，可透過 api_base 參數進行設定。
| 供應商 | 環境變數 | 處理器類型 |
|---|---|---|
| OpenAI | OPENAI_API_KEY |
OpenAI SDK |
| Anthropic | ANTHROPIC_API_KEY |
Custom |
| Groq | GROQ_API_KEY |
OpenAI-compat |
| Mistral | MISTRAL_API_KEY |
Custom |
| xAI | XAI_API_KEY |
OpenAI-compat |
| OpenRouter | OPENROUTER_API_KEY |
OpenAI-compat |
| Azure | AZURE_API_KEY |
OpenAI SDK (Azure) |
| Bedrock | AWS_ACCESS_KEY_ID |
Custom |
| Cloudflare | CLOUDFLARE_API_TOKEN |
Custom |
| Together | TOGETHERAI_API_KEY |
OpenAI-compat |
| Fireworks | FIREWORKS_API_KEY |
OpenAI-compat |
| DeepSeek | DEEPSEEK_API_KEY |
OpenAI-compat |
| Perplexity | PERPLEXITYAI_API_KEY |
OpenAI-compat |
| DeepInfra | DEEPINFRA_API_TOKEN |
OpenAI-compat |
| Gemini | GEMINI_API_KEY |
OpenAI-compat |
| Cohere | COHERE_API_KEY |
OpenAI-compat |
| Ollama | N/A | OpenAI-compat |
| vLLM | N/A | OpenAI-compat |
| LM Studio | N/A | OpenAI-compat |
技術實作與狀態
Litelm 目前處於 Alpha 階段。專案維護者已驗證其為 DSPy 的直接替換方案，所有七個執行路徑（Predict、CoT、typed signatures、串流、嵌入、工具使用與多輸出）均已證實可正常運作。
開發方法論
該軟體是使用混合人類-AI 的方法開發的。在 2026 年 5 月 14 日之前編寫的程式碼是由 Claude Code (Claude Opus 4.6/4.7) 輔助完成的，隨後的程式碼則是透過 Pi 使用 GPT-5.5 編寫的。維護者對來自上游 LiteLLM 專案的 360 個核心路徑提交（commits）進行了手動審計，以確保相容性。
錯誤處理
Litelm 將供應商特定的錯誤映射到標準化的異常階層，包括 ContextWindowExceededError、RateLimitError 與 AuthenticationError。
社群社群回饋與觀點
Hacker News 上的社群討論突顯了重視極簡主義者與依賴 Litelm 所移除的「臃腫」功能的使用者之間的分歧。
"對於許多 LiteLLM 的使用者來說，許多已被移除的功能（例如成本追蹤、串流、快取）... 算是核心價值主張。"
其他使用者指出技術上的疑慮，特別是建議從 httpx 遷移至 httpx2 以應對維護問題。
一些開發者認為，隨著前沿 LLM 的出現，建立一個自定義路由器的確是一件小事，這暗示著專門用於此目的的函式庫變得不再必要，因為 AI 編碼工具使得撰寫自定義客戶端變得更加容易。
"使用前沿 LLM，這是一個 30 分鐘的專案。我看不出為什麼有人會使用別人的路由器。"
最後，一些使用者讚揚了 AI 供應商之間的高度互操作性，指出「OpenAI 相容」標準已成為業界廣泛 API 互操作性成功的罕見範例。
Sources
相關
- 專案
- 專案
- 專案
- 專案