LiteLLM 是你自行執行的開源、OpenAI 相容代理伺服器：它位於你自己的供應商帳戶前方，讓程式透過一個端點和一種金鑰格式連接各供應商（其文件）。團隊尋找替代方案有兩個互不相關的原因。營運：自行託管的代理伺服器是另一項需要修補、擴展並處理警示的服務。供應鏈：2026 年 3 月 24 日，攻擊者向 PyPI 發布了兩個植入後門的 LiteLLM 版本，讓許多此前未將相關風險納入成本考量的團隊正視「建置中的套件」所帶來的攻擊面。本次整理將每種動機對應到真正能解決它的工具，也包括繼續使用 LiteLLM 的理由；這個理由比本次搜尋中的七篇供應商清單文章所暗示的更有力。
先聲明偏向：Kunavo 是我們的產品，因此列在第一位。以下每個其他工具都會獲得真誠的建議；我們審核過的詳細資訊位於比較頁面，而兩個我們尚未評估的方案，僅按照其官方網站所述的層級介紹。
候選清單
| 替代方案 | 類型 | 選擇它的理由 |
|---|---|---|
| Kunavo | 託管式推理閘道（轉售存取權） | 沒有代理伺服器，也沒有供應商帳戶；多數模型低於牌價 |
| OpenRouter | 託管式推理閘道（轉售存取權） | 一個錢包涵蓋最長的模型尾端 |
| Portkey | 託管式控制平面（BYO keys） | 保留供應商金鑰，停止執行代理伺服器 |
| Helicone | 可觀測性層（BYO 金鑰） | 執行它的唯一原因是記錄與成本追蹤 |
| TrueFoundry | 企業 AI 閘道 | 採購部門需要 SLA 和可聯絡的供應商 |
| MLflow AI Gateway | 自行託管、開源 | 與 LiteLLM 形態相同，但屬於不同專案 |
| Cloudflare AI Gateway | 邊緣代理程式（BYO 金鑰） | 在你自己的金鑰上提供快取、速率限制與分析 |
最關鍵的區別
LiteLLM 同時承擔兩項工作，而多數替代方案只承擔其中一項。它是代理伺服器（透過一個端點連接多個供應商），也是BYO-key 工具（供應商帳戶仍由你持有）。託管式推理閘道—— Kunavo、OpenRouter —— 兩者都替換：你不必執行代理伺服器，也不必持有供應商帳戶，因為閘道保管上游憑證並向你收取用量費用。託管式控制平面—— Portkey、TrueFoundry —— 只替換前者：你停止營運代理伺服器，但保留帳戶。了解你要替換的是哪一半，就能解開這份清單的大部分內容。這個模式詳見LLM 閘道指南。
真正讓人開始搜尋的原因
這次搜尋的最高結果不是清單文章，而是一個討論供應鏈攻擊的 Reddit 討論串。以下根據LiteLLM 自己的安全更新說明事件經過：在2026 年 3 月 24 日，攻擊者將 litellm==1.82.7 和 litellm==1.82.8 發布到 PyPI，並在發佈的 wheel 中注入惡意程式碼。它們從 10:39 UTC 起上線約 40 分鐘，之後由 PyPI 隔離。入侵源頭被追溯至 LiteLLM CI/CD 安全掃描工作流程中的Trivy 相依性；攻擊者繞過官方發布流程，直接上傳到 PyPI。根據SecurityWeek，超過 2,500 個組織受到影響。
LiteLLM 的修復措施已公開，而且規模相當大：移除遭入侵的套件、輪替維護者憑證、聘請 Mandiant 進行鑑識，並透過重建後的 CI/CD 流程發布 v1.83.0，加入隔離的建置環境、更嚴格的發布閘門與由 cosign 簽署的 Docker 映像。如果你使用的是 1.83.0 或更高版本，且未在那 40 分鐘的時間窗內執行遭植入的版本，這起事件對你而言就已結束。
這件事仍會促使人們尋找替代方案，原因在於結構，而不是 LiteLLM 本身。自行託管的代理伺服器是建置中的一個套件，因此你的 CI/CD 與叢集都在其影響範圍內。這句話值得仔細思考 —— 本頁所有自行託管的替代方案都同樣適用，包括 MLflow AI Gateway；而這也是託管端點唯一能消除的事情：你呼叫的是 HTTPS URL，因此沒有可被植入的套件，也沒有任何閘道程式在你的網路中執行。
坦白說，另一半是：託管式閘道並不更安全，只是暴露方式不同。你的 API 金鑰與提示詞文字會經過他人的基礎設施，你承擔的是對方的入侵風險，而不是自行修補的風險。如果提示詞文字不能離開你的基礎設施，自行託管才是正確答案，本頁其餘內容所談的是你不應該做出的取捨。
1. Kunavo — 沒有代理伺服器，也沒有供應商帳戶
Kunavo 是託管式推理閘道：一個 OpenAI 相容的 base URL、一個 sk-kn- 金鑰、一個隨用隨付餘額；上游供應商的憑證由我們持有，而不是由你持有。與 LiteLLM 相比，這是不同的分工方式 —— 你不必執行代理伺服器，也不必分別維護 Anthropic、Google 和 OpenAI 的帳戶。
價格：目錄中大多數項目的標價都低於供應商的官方費率 —— Claude Sonnet 4.6 為每 100 萬個詞元 $2.10 / $10.50，而 Anthropic 的價格為 $3.00 / $15.00。LiteLLM 不收加價，因為它不轉售任何服務；你支付的費用依你與供應商的合約而定，因此比較的是我們的費率與你直接向供應商購買的費率，而不是與零比較。涵蓋範圍：使用同一個金鑰與餘額支援聊天、圖片、影片和音樂模型。它不做的事：路由你自己的供應商金鑰 —— 這是 LiteLLM 保留、而我們不替換的 BYO-key 部分。詳細資訊：Kunavo 與 LiteLLM 比較。
2. OpenRouter — 最長的模型尾端
另一個託管式推理閘道；當目錄廣度比單位價格更重要時，應該選它：來自大量供應商的數百個模型共用一個錢包，另提供免費層級與 Kunavo 沒有的自帶金鑰路由。如果你離開 LiteLLM 是因為想停止持有帳戶，OpenRouter 和 Kunavo 是兩種現實可行的形態。Kunavo 與 OpenRouter 比較會將兩者並列，OpenRouter 整理則涵蓋該領域的其他內容。
3. Portkey — 保留金鑰，放下營運負擔
建立在你現有供應商帳戶之上的託管式控制平面：提供路由、故障轉移、防護與可觀測性，不需要自行執行代理伺服器。如果你選擇 LiteLLM 是因為它的路由和預算功能，而唯一想放棄的是營運工作，這就是最接近的替代方案。詳細資訊：Kunavo 與 Portkey 比較。
4. Helicone — 如果可觀測性是全部理由
許多 LiteLLM 部署存在，是因為有人需要請求記錄與按團隊歸因的成本，而代理伺服器是取得這些功能的方式。如果這描述了你的情況，在現有供應商呼叫之上加一層可觀測性，會比執行一個閘道小得多。詳細資訊：Kunavo 與 Helicone 比較。
5. TrueFoundry — 採購部門需要供應商時
在這次搜尋中排名第 2，並有自己的 LiteLLM 比較文章。它是以延遲開銷、部署彈性、SLA、治理與可供稽核的控制項銷售的企業 AI 閘道（其產品頁面）。我們尚未評估它，因此本項是指引而非推薦：如果你的阻礙是開源代理伺服器沒有支援合約，這就是能解決該問題的類別；但請記得這份比較是由該供應商撰寫的。
6. MLflow AI Gateway — 同類開源替代方案
排名第 3，也是本頁最接近 LiteLLM 本身的方案：一個開源、自行託管的閘道，位於你自己的供應商金鑰前方，並作為 MLflow 專案的一部分維護。需要明確說明的是：用另一個自行託管的代理伺服器替換原方案，會保留部署模式，也因此保留上方所描述的攻擊面。這是合理的選擇 —— 如果你不滿的是專案本身，而不是模型，這就是你要的方案。
7. Cloudflare AI Gateway — 在邊緣提供快取與限制
位於你現有供應商帳戶前方的輕量代理伺服器：提供回應快取、速率限制、重試與分析，不轉售推理服務。它可以與任何推理來源組合，而不是替換推理來源，包括 Kunavo 或 OpenRouter。詳細資訊：Kunavo 與 Cloudflare AI Gateway 比較。
LiteLLM 仍然是正確選擇的情況
- 提示詞文字不能離開你的基礎設施。受監管資料、隔離網路環境，或託管式閘道根本無法滿足的政策要求。自行託管才是答案，唯一的問題是選擇哪個自行託管的代理伺服器。
- 您已協商供應商合約。 在 Anthropic、OpenAI 或 Google 的承諾消費額或企業費率，比任何轉售商列出的內容都更有價值，而 BYO-key 工具能讓您持續使用這些服務。
- 您使用它按金鑰設定的預算和團隊路由。 這些功能正是許多 LiteLLM 部署存在的原因；在假設只需替換基底 URL 就完成整個遷移前，請先確認您的替代方案涵蓋這些功能。
- 您希望能自行閱讀與修補原始碼。 能控制開源代理伺服器是一項實際特性，而 2026 年 3 月的事件並未使這項特性消失——那是發布流程遭入侵，且已完成修復，不是代理伺服器本身的缺陷。
切換只需兩行
這裡所有轉售推理服務的替代方案都支援 OpenAI 線路協定，因此從 LiteLLM 代理遷移只需進行 base_url 和金鑰替換——要求與回應的結構不變：
# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
api_key=os.environ["LITELLM_MASTER_KEY"],
base_url="http://litellm.internal:4000",
)
# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
api_key=os.environ["KUNAVO_API_KEY"],
base_url="https://api.kunavo.com/v1",
)
resp = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)不是兩行就能完成的部分，是 LiteLLM 在路由之外所做的任何事情：按金鑰設定預算、團隊扇出、自訂回呼。請先盤點這些項目。線路層級的細節請參閱 OpenAI 相容 API 指南，而 閘道應替您處理的事項則涵蓋用來檢查替代方案的功能集合。
常見問題
最佳 LiteLLM 替代方案是什麼？
取決於你要替換的是什麼。如果你想停止執行代理伺服器並停止持有供應商帳戶，Kunavo 或 OpenRouter 這類託管推理閘道可以一次替換兩者。如果你想保留自己的供應商金鑰，但不想自行營運代理伺服器，Portkey 或 TrueFoundry 是託管式 BYO-key 控制平面。如果你執行 LiteLLM 的唯一原因是記錄與成本追蹤，Helicone 單獨就能涵蓋這些需求。如果你想使用自行託管的開源方案，MLflow AI Gateway 是最接近的同類替代品。
為什麼 2026 年大家在尋找 LiteLLM 的替代方案？
有兩個分開的原因。營運方面很普通：自行託管的代理伺服器是一項需要修補、擴展並安排人員處理警示的服務。第二個原因則很具體 —— 2026 年 3 月 24 日，攻擊者向 PyPI 發布了兩個植入後門的 LiteLLM 版本；根據SecurityWeek，這起事件影響了超過 2,500 個組織。LiteLLM 此後已輪替憑證並重建發布流程，因此對多數團隊而言，問題不是 LiteLLM 現在是否安全，而是是否要在建置中加入這項相依性。
2026 年 3 月供應鏈攻擊中，哪些 LiteLLM 版本遭到入侵？
litellm==1.82.7 和 litellm==1.82.8。根據LiteLLM 自己的安全更新，它們於 2026 年 3 月 24 日 10:39 UTC 起在 PyPI 上線，約 40 分鐘後由 PyPI 隔離。LiteLLM 將入侵追溯至 CI/CD 掃描工作流程中的Trivy 相依性，並聘請 Mandiant 進行鑑識，透過重建後的流程發布 v1.83.0，使用隔離的建置環境與已簽署的 Docker 映像。
託管式 AI 閘道比自行託管 LiteLLM 更安全嗎？
不是更安全，而是暴露方式不同。託管式閘道會將套件從你的建置中移除，也會將代理伺服器從叢集中移除，因此遭植入的版本無法透過它接觸你的 CI/CD 或 Kubernetes 節點。相對地，你的 API 金鑰與提示詞文字會經過第三方，你承擔的是該供應商的入侵風險，而不是自己的風險。不能將提示詞文字傳出自有基礎設施的團隊應自行託管；這是信任模型的選擇，而不是安全分數的比較。
有開源的 LiteLLM 替代方案嗎？
MLflow AI Gateway 是最接近的同類方案：開源、自行託管的閘道，透過單一端點代理你自己的供應商金鑰，並作為 MLflow 專案的一部分維護。它在這次搜尋中排名第 3，是形態上最接近 LiteLLM 本身的替代方案。
如何從 LiteLLM 遷移？
如果你要遷移到另一個 OpenAI 相容端點，遷移只需要替換 base_url 和 API 金鑰 —— 請求與回應格式不變，模型名稱也以相同方式沿用。不是兩行就能完成的部分，是 LiteLLM 除了路由之外替你處理的工作：預算執行、按團隊分發金鑰，以及任何自訂回呼。在切換前，請確認替代方案涵蓋其中哪些功能。
什麼時候應該繼續使用 LiteLLM？
當提示詞文字不能離開你的基礎設施、你已經談妥並想繼續使用供應商合約、你需要按金鑰設定預算與團隊路由功能，或你想使用可以自行閱讀與修補的開源代理伺服器時，就應該留下。這些都是實際優勢，而 2026 年 3 月的事件並未消除其中任何一項 —— 那是發布流程遭入侵，且已完成修復，不是代理伺服器功能本身的缺陷。