5个最好的 LiteLLM 替代方案：换掉它之前，先想清楚你要替换哪个职责

先把话放这儿：如果你的 LiteLLM 现在跑得好好的，这篇你大概率不用看完，直接翻到最后一节。真正让人动念头换掉它的，从来不是它"不够强"，而是那些很具体、很烦的时刻——半夜 proxy 的 worker 把内存啃到底，被 OOM Killer 一枪撂倒；跑在 Kubernetes 上 RSS 一路往上爬，官方生产文档自己都建议你"每隔 N 个请求回收一次 worker"；config.yaml 膨胀到两三百行，改一个 model 别名全组都得屏住呼吸；升一个小版本，fallback 的行为悄悄变了，线上才发现。这些才是有人在 Slack 里敲出"我们是不是该换个网关"的真正导火索。

所以这篇文章不打算给你评一个"五选一的冠军"。因为"LiteLLM 的替代方案"这个说法本身就有点误导——几乎没人是整体把 LiteLLM 换掉的，大家换掉的是它承担的某一两个具体职责。想清楚这一点，选型会一下子简单很多。顺带一提，如果你对 LiteLLM 本身还不熟，可以先看我们那篇 LiteLLM 完整教程 打个底，这里默认你已经用过它了。

一、先想清楚：你要替换 LiteLLM 的哪个职责

LiteLLM 其实在同时替你干四件事，外加一件它压根不碰、但你迟早要面对的：

• 统一接口：把 OpenAI、Anthropic、Gemini、一堆国产模型各不相同的 SDK，抹成一个 OpenAI 格式的调用。这是它最核心、也最难被完整替代的价值。
• 成本追踪：谁花了多少、哪个 key 超了预算，给你一本账。
• 故障转移：主线路挂了自动切备用、多 key 轮换躲限速。
• 可观测：日志、延迟、报错、每次调用的 token 数。
• 自主推理：这一件 LiteLLM 不干——真正把模型跑起来的那台 GPU，到底是谁的？

下面五个"替代方案"，各自只精准地咬住其中一两件：OpenRouter 接管的是"统一接口 + 故障转移"，而且是托管的；Portkey 咬的是"统一接口 + 可观测 + 治理/guardrails"；LangSmith 其实只做"可观测/评估"这一件，把它当网关替代品是理解错了；Cloudflare AI Gateway 在边缘上给你"可观测 + 缓存 + 成本追踪"，但它是透传的；vLLM/Ollama 干的是完全不同的第五件——"自主推理"。看懂这张分工图，你就不会再纠结"到底哪个最好"，而是直接问自己"我缺的是哪一件"。

二、一张能一眼扫完的对比表

表里最该被记住的一列是第二列"接管哪件事"。你会发现没有任何一个能把 LiteLLM 那四件事整体端走——因为 LiteLLM 本来就是把好几件事缝在一起的东西。下面逐个说，谁值得多讲我就多讲，边角的就两句带过。

三、OpenRouter：想省事就它，别多想

核心定位：一个托管的模型聚合中转。一个 API key、一个 base_url，背后接着 400 到 500 多个模型、60 多家供应商。你不用自己维护任何东西，主线路慢了或挂了，它在边缘层自动切到别的供应商，你的应用基本无感。

接入难度低到有点好笑——很多时候真的就是改一个环境变量：

# OpenRouter：把 base_url 一换，OpenAI SDK 直接接上
export OPENAI_API_KEY="sk-or-..."
export OPENAI_BASE_URL="https://openrouter.ai/api/v1"

性能上它比很多人预期的要好。它跑在边缘，路由本身只加大约 15 到 25 毫秒的开销；在 2026 年的一次公开延迟测评里，OpenRouter 的首 token 时间甚至比直连 OpenAI 还快了约 70 毫秒（因为它离用户更近、且选的是当下最快的供应商实例）。近 90 天的可用性数据是 99.99%。对"只想稳定地在 GPT 和 Claude 之间来回切"的团队，这套东西省心得没话说。

现在说烦人的地方。第一，那 5.5% 不是抽你的 token，而是抽你充进去的钱——你每充一笔 credit，信用卡通道扣 5.5%，加密货币 5%，每笔还有 $0.80 的最低手续费。这是实打实的毛利损耗，量大了肉疼。第二，BYOK（自带上游 key）的算法在 2026 年 7 月 14 日改过一次：以前是按请求数给免费额度（PAYG 每月 100 万次、企业版 500 万次），现在改成按"列表价推理额度"计——PAYG 每月 $25,000 以内免费，企业版 $200,000，超出的部分，按这次调用在 OpenRouter 平台上本来会花多少钱、收你 5%。如果你本来就想用自己的上游 key 省钱，这笔账得重新算。第三，也是工程师最该在意的一点：它的路由是个黑盒，你不完全控制到底是哪家供应商、哪个量化版本在给你服务，同一个模型名，不同后端的实际质量可能有差异。

一句话：如果你只是想在几家闭源大模型之间切、不想自己运维——OpenRouter，别多想。但如果你对成本颗粒度、对"到底谁在服务我"这件事很敏感，这层黑盒会让你不舒服。国内直连的中转选择更多，可以对照我们的 AI API 中转站对比 一起看。

四、Portkey：全能，但换了个东家

核心定位：网关 + 可观测 + guardrails 三合一。它一直是"想要一个统一网关、又要企业级观测和护栏"这类需求里最完整的那一个——路由、限速、策略执行、每次模型交互的可见性都在一套里，据官方口径每月处理的 token 已经是万亿级。单看能力，它比 OpenRouter 更"企业向"，比 LangSmith 更"网关向"。

一句话：能力上它依然是这五个里最全面的网关型选手。但在 2026 年年中这个时间点，我不会拿一个全新的、追求供应商中立的项目去押它——先观望，等收购后的产品方向落定再说。反过来，如果你已经在 Palo Alto 的生态里、且 guardrails/合规是硬需求，收购对你是加分项。

五、LangChain / LangSmith：把它当网关替代品是选错了轴

先纠正一个常见的误解：把 LangChain/LangSmith 列进"LiteLLM 替代方案"，其实是选错了轴。LangChain 是应用编排框架，LangSmith 是追踪/评估/可观测平台——它们都不是网关，不做"把各家 SDK 抹成一个格式"这件 LiteLLM 的核心工作。

但如果你从 LiteLLM 那儿真正想要、又一直没得到满足的，恰好是可观测那一件——想看清每次调用的完整调用链、想搭一套评估（eval）流程——那 LangSmith 是个正经答案，它在 trace 树和评估这块比 LiteLLM 自带的日志深得多。

代价有两层。一是它不是透传代理，你得改代码埋点，不像换个 base_url 那么无痛。二是价格会咬人：免费的 Developer 档只有每月 5,000 条 trace、14 天留存、1 个席位；Plus 档 $39/席/月，含 1 万条基础 trace，超出按 $2.50/千条计，想要 400 天长留存的 trace 则是 $5.00/千条。席位是线性叠加的，10 个人就是 $390/月起步。真正的坑在 trace 超额——一个 5 人团队如果每月产生 200 万条 trace，账单能冲到 5,000 多美元/月。埋点之前一定先估算调用量，别等账单来了才发现。

一句话：你缺的是"看清每次调用发生了什么"和一套评估流程，才选 LangSmith；如果你要的是网关，它答非所问。

六、Cloudflare AI Gateway：被低估的边缘白捡

核心定位：架在边缘的一层控制面，给你可观测、缓存、限速、成本追踪。它是这五个里最容易被忽略、但在对的场景下性价比最高的一个。

它的经济账很漂亮：核心网关功能免费，没有按次调用的费用；免费档每月给 10 万条日志，超了就走 Workers Paid（$5/月起）拿到 100 万条日志。2026 年新上的 Unified Billing 还能让你把第三方模型（OpenAI 等）的用量直接并进 Cloudflare 账单，代价是充值时加收 5%。缓存这块是真省钱——命中的请求直接从边缘返回，根本不打上游。

一句话：如果你本来就在 Cloudflare 上，想要的又正好是可观测、缓存和一个限流的收口点——这层几乎是白捡的，运维成本接近零。但别指望它给你 LiteLLM 那种"一个格式打天下"的统一接口。

七、自托管 vLLM / Ollama：这是另一条轴

这两个东西严格说不是"LiteLLM 的替代方案"——它们替换的是那第五件事"自主推理"，也就是你自己把模型跑起来。真实工程里，你往往不是拿 vLLM 去代替 LiteLLM，而是用 vLLM 跑模型、再在它前面架一个 LiteLLM 或别的网关。两者是叠加关系，不是二选一。

Ollama 是本地和原型阶段的王者：五分钟就能在自己电脑上把模型跑起来，配 Open WebUI、搭个不吃并发的 RAG 都很舒服。但它的天花板也很硬——默认大约只处理 4 个并发请求（OLLAMA_NUM_PARALLEL 默认甚至是 1），压力上来后大约稳定在每秒 41 token；在 128 个并发用户下，它的 P99 延迟会飙到 673 毫秒，而同场景下 vLLM 还能守在 100 毫秒以内。它还有个坑：多用户请求同一个模型时，它会把负载全压到一张 GPU 上，其他卡干瞪眼。结论很直白：Ollama 只配在你自己的机器上跑，别拿它扛生产并发。

vLLM 才是自托管生产的正解。它靠 PagedAttention 和 continuous batching 把吞吐相对朴素实现拉高了最多 24 倍，如今已经是任何正经推理栈的基线配置——出身 UC Berkeley 的 Sky Computing 实验室，现在是 PyTorch 生态的核心项目，LinkedIn、Uber 都在生产里跑它；Stripe 迁到 vLLM 后把推理成本砍了 73%（用三分之一的 GPU 扛下每天 5,000 万次调用）。代价就是运维——你得自己管 GPU、调度、扩缩容、监控，这不是改个 base_url 的活儿。

一句话：数据不能出门、规模大到自己跑更划算、或者要跑自己微调的模型——才上 vLLM 自托管；Ollama 留给你的笔记本和 demo。而且记住，跑起来之后你八成还需要在前面放个网关，绕回到前面几个方案。

八、场景化推荐（大白话版）

• 只想在 OpenAI 和 Claude 之间切、不想碰运维 → OpenRouter，别多想。认了那 5.5% 的充值手续费就行。
• 已经在 Cloudflare 上，想要可观测 + 缓存 + 限流 → Cloudflare AI Gateway，几乎白捡，一天就能接上。
• 企业场景，要 guardrails / 合规 / 审计，尤其你已经是 Palo Alto 的客户 → Portkey。反过来，如果你是新项目、看重供应商中立——先观望。
• 你真正缺的是"看清每次调用 + 能做评估" → LangSmith，但埋点前先把 trace 量估清楚，盯紧那张会膨胀的账单。
• 数据不能出门 / 规模大到自己跑更省 / 要跑微调模型 → vLLM 自托管，前面再补个网关；Ollama 只留给本地开发。

九、诚实结论：很多时候，别换

写了这么多，最反直觉、但也最该说的一句是：很多情况下，最好的"替代方案"就是别换。

让人想跑路的那个内存问题，其实有现成解法。LiteLLM 自己的生产文档就写了：配好 worker 回收——每个 worker 处理满 N 个请求就自动重启，把缓慢增长的内存压下去；同时钉死版本别乱升小版本、给进程加个内存上限。大致就是这个思路：

# 用 gunicorn 起 LiteLLM proxy，让 worker 处理满一定请求数后自动回收，
# 压住那个缓慢增长的内存（数字按你的负载调）
litellm --config config.yaml \
  --num_workers 4 \
  --run_gunicorn --max_requests 1200 --max_requests_jitter 200

而且值得一提的是，LiteLLM 自己也在往 Rust 核心迁移（现在的定位是"Rust core with Python SDK"），历史上那些卡在 Python GIL 上的高并发开销正在被逐步解决——v1.78.5 在 1000 并发下的中位数额外开销已经压到 8 毫秒。换句话说，你今天遇到的问题，可能下个版本就没了。

说句得罪人的话：大多数人换网关，是因为某个下午被坑烦了，而不是真撞到了架构天花板。先分清你撞的是天花板、还是一次配置事故，再决定要不要动手迁移。迁移本身也是有成本的，别用一个新的坑去换掉一个你其实已经会绕的旧坑。