LiteLLM vs OpenRouter：成本、控制权与故障转移

选择 LLM 网关，关键并不在于 LiteLLM 和 OpenRouter 是否都支持 OpenAI 风格的 API，而在于谁来运营这层路由。对于尚未运行生产级网关基础设施的团队，OpenRouter 是更省事的起点；当私有网络、自定义策略或持续增长的用量让控制权值得投入专人维护时，LiteLLM 的额外运维成本才更有价值。

这其实是运营模式的选择，而不是 API 格式之争

LiteLLM 是开源软件，既可以作为 Python SDK 使用，也可以部署为自托管代理。OpenRouter 则是托管式 API 和模型目录：OpenRouter 负责运营网关、整合供应商访问，并通过一个账户统一管理模型用量。

两者都能提供兼容 OpenAI 的接口，但需要承担的责任完全不同：

两种模式也可以组合使用：LiteLLM 负责内部策略和计费归属，OpenRouter 则负责特定模型的访问。

先看哪项约束会最早成为瓶颈

正确答案取决于团队最不能妥协的那个需求。

别只看 Token 账单，还要算上工程账单

LiteLLM 和 OpenRouter 收取的是不同层面的成本。OpenRouter 按底层模型价格转收费用，不加推理服务溢价；购买信用额度时，另外收取 5.5% 的费用。LiteLLM 的开源代理不收按 Token 计算的网关费用，但你需要为运行它投入基础设施和人员。

OpenRouter 的定价页是当前费用条款的依据。这里的费用对应购买信用额度，而不是简单地把每个模型的 Token 价格统一上浮 5%。

什么时候 OpenRouter 的费用反而更划算

如果团队购买的 OpenRouter 信用额度足以覆盖每月推理账单：

• 每月使用 $500 时，5.5% 的信用额度购买费用为 $27.50。
• 使用额为 $20,000 时，同样的比例是 $1,100。
• 使用额为 $50,000 时，费用为 $2,750。

这些数字代表的是 LiteLLM 在扣除托管、部署、打补丁、告警、备份和工程时间后需要击败的成本。对于每月 $500、且本来没有网关运维能力的团队，OpenRouter 往往是运维投入更低的选择，除非私有网络是硬性要求。到了 $20,000，已经拥有平台团队的组织就应该认真核算 LiteLLM。

什么时候 LiteLLM 的零网关费真的更便宜

当平台团队本来就承担了固定运维成本，或者省下的比例费用已经超过运行代理所需的增量成本时，LiteLLM 的财务吸引力才会显现。

官方的 Docker 快速入门区分了简单的无数据库代理和基于数据库的部署方式。在 Compose 流程中，PostgreSQL 用于保存模型、密钥和支出日志。LiteLLM 明确说明，没有数据库时，虚拟密钥、支出追踪和有效的预算强制执行都无法使用；此时配置的 max_budget 不能作为可靠的硬上限。

Redis 是另一个进入生产环境的分界线。LiteLLM 的 Redis 要求建议，当代理运行多个 worker 或副本时使用共享 Redis 状态。没有它，速率限制、预算、冷却时间、缓存条目和路由观测结果都会分散在不同 worker 中。单 worker 测试很便宜；支持水平扩展的生产网关则是另一套更大的系统。

不要只比较 Token 价格，应该使用下面的口径：

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

不存在适用于所有团队的统一盈亏平衡点。真正有用的输入是每月推理支出、托管成本、工程工时、待命支持覆盖，以及可能存在的合规溢价。

比较你需要实际运营的控制平面

LiteLLM 能给平台团队更多控制权，但不会替你获得供应商访问权限。OpenRouter 更适合模型发现和统一计费，但托管目录并不等同于拥有直接的供应商关系。

到了可靠性层面，两者就不再像了

两款产品都可以重试或故障转移，但故障转移的责任归属不同。OpenRouter 管理供应商池；LiteLLM 允许你定义供应商池，同时也要求你把它纳入自己的可靠性体系运营。

OpenRouter 的供应商路由文档显示，其默认行为会在可用供应商之间进行负载均衡，同时考虑价格和供应商近期的中断情况。你可以指定供应商顺序、允许或禁用回退、要求特定参数、按数据策略筛选，或按价格、吞吐量、延迟进行排序。它的模型回退指南介绍了有序的 models 列表；计费以最终处理请求的模型为准。

LiteLLM 的路由文档列出了加权或随机选择、基于用量的路由、基于延迟的路由、最少繁忙路由、基于成本的路由，以及自定义路由策略。它还支持部署优先级、冷却时间、重试和回退组。这些控制更具可编程性，但能否正确工作取决于你的配置、健康检查、共享状态和故障响应。

Agent 延迟、缓存与供应商漂移

对于一次持续很久的流式回答，多增加一次网络跳转可能并不明显。但如果 Agent 一轮要发起几十次短模型调用，网关、网络和重试延迟就会在多轮交互中不断累积。自托管的 LiteLLM 代理可以部署在靠近应用的位置；OpenRouter 则会在选定供应商之前增加一层托管服务。任何一家厂商的通用文档，都不能替代针对你的区域、模型、流式模式和并发量进行的实际测试。

路由变化也会改变缓存经济性。对于同一个模型，OpenRouter 可能在多个供应商端点之间选择；LiteLLM 也可能把请求分发到不同的已配置部署。如果工作流依赖供应商侧的提示词缓存，路由变化就可能影响缓存命中位置和 Token 成本。应当把缓存行为纳入工作负载测试。

共享的模型标识符也不代表行为完全一致。不同供应商在上下文限制、工具调用支持、延迟、量化、缓存和供应商专属参数方面都可能存在差异。OpenRouter 提供 require_parameters 等供应商筛选条件，而 LiteLLM 则把不同供应商的调用归一到统一接口。请针对 Agent 实际使用的工具 schema 和模型参数进行测试。

需要提前设计的故障模式

使用 OpenRouter，基础设施事故会变成对供应商的依赖；使用 LiteLLM，这些事故则会变成平台团队可以检查和修改的内部事件。

可观测性和隐私，边界并不相同

“自托管”不等于“私有”，“托管服务”也不代表“一定会记录每条提示词”。真正需要弄清楚的是：哪一层保存内容，哪一层保存元数据，以及请求最终会到达哪些供应商。

OpenRouter 的Zero Data Retention 文档说明，可以按账户、模型组、护栏或请求强制启用 ZDR。它区分了真正不保留数据的端点，以及不用于训练但可能临时保留数据的供应商。ZDR 只适用于推理路由；启用的工具和插件需要单独审查。

LiteLLM 可以让你更好地控制网关的网络、数据库、身份验证和日志，但责任也全部落在你身上。你需要保护代理、及时修补软件、限制管理路由、保管好供应商密钥，并逐一确认上游供应商的数据留存和训练条款。

混合架构往往是更现实的答案

当你需要稳定的内部端点和治理能力，却不想为每个模型或供应商都开通直接账户时，可以把 LiteLLM 放在 OpenRouter 前面。敏感或行为稳定的流量直接发送到批准的供应商，把探索性流量或依赖模型目录的请求交给 OpenRouter。

一个简化的配置模式如下：

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

这样一来，LiteLLM 就能负责内部密钥、预算、标签和日志。但对于经过 OpenRouter 的请求，这并不会消除 OpenRouter 的费用、托管传输或供应商策略边界。同时，混合架构会增加一次跳转和一个故障域，因此不要默认让所有请求都经过两层网关。

比较合理的拆分方式是：

1. 敏感数据、稳定的生产模型，或已有协商供应商合同的流量，走直接供应商路由。
2. 模型发现、长尾供应商和托管式供应商故障转移，走 OpenRouter 路由。
3. 应用密钥、团队、预算和内部成本归属，由 LiteLLM 统一控制。
4. 为直接供应商流量和 OpenRouter 流量分别配置仪表盘与告警。

迁移时，真正会变的并不只是端点地址

在两个网关之间迁移一个兼容 OpenAI 的客户端，改动可能很小；但迁移生产工作负载，绝不只是修改 base URL。

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter 通常使用 https://openrouter.ai/api/v1（API reference）；LiteLLM 代理通常暴露类似 http://localhost:4000 的私有端点（proxy quickstart）。但模型 ID、供应商前缀、认证方式和可选参数仍可能不同。

切换生产流量前，请测试：

1. 流式响应和超时行为。
2. 使用准确 JSON schema 的工具调用。
3. 结构化输出和严格 JSON 处理。
4. 推理、缓存和供应商专属参数。
5. 主模型返回 429、5xx 或校验错误时的回退行为。
6. 成本归属，因为计费事件发生的层级可能与应用请求不同。

API 兼容性只能帮助你完成首次接入，不能保证输出、延迟、供应商选择或计费语义完全一致。

团队选型前最常问的问题

LiteLLM 和 OpenRouter 可以一起用吗？

可以。LiteLLM 能把 OpenRouter 作为上游路由，让 LiteLLM 负责内部密钥、预算、日志或策略，同时由 OpenRouter 提供特定模型访问和供应商路由。组合后的链路会多一跳，而且这部分流量仍受 OpenRouter 的费用和托管数据边界约束。

生产 API 用哪个更便宜？

对于尚未运营网关基础设施的小团队，OpenRouter 往往能降低运维投入。当团队已经具备所需基础设施、又希望避免按比例收取的网关费用时，LiteLLM 在更高用量下可能更便宜；应该比较总成本，而不是只看 Token 价格。

LiteLLM 能访问 OpenRouter 的完整模型目录吗？

不能单靠 LiteLLM 实现。LiteLLM 在其代理快速入门中说明支持 100+ 个 LLM 和广泛的供应商，但它只能访问你配置了凭据的供应商。把 OpenRouter 添加为上游可以扩大可访问目录，但这些请求也会遵循 OpenRouter 的模型和供应商可用性。

哪个更适合隐私和合规要求？

自托管 LiteLLM 可以让你更好地控制网关的部署、日志、凭据和网络边界。OpenRouter 提供内容记录控制、供应商策略筛选、ZDR 路由，以及 Enterprise EU/US 区域选项，但它仍然位于请求链路中；做出选择前，请确认具体供应商和合同要求。

选择一个你有能力长期维护的边界：用实际网关运维成本核算比例费用，明确哪些请求可以经过托管中间层，并针对应用所需的路由和工具调用行为进行故障测试。如果团队无法承担 LiteLLM 的数据库、Redis、升级和待命维护，OpenRouter 是更诚实的默认选择；如果你已经具备这些平台能力，LiteLLM 或混合路由就能换回更多控制权，并降低持续性的网关费用。

如果想了解更多 OpenRouter 替代方案，可以查看 OpenRouter alternatives；本文有意缩小范围，重点讨论 LiteLLM 所代表的运营模式选择。