几乎所有出现这种比较的地方，比较框架都是错误的，而搜索结果中的第四项就说明了这一点：它是 LiteLLM 自己的 OpenRouter 文档页面。LiteLLM 提供 OpenRouter 集成，是因为两者并非替代关系——它们处于不同层级。 LiteLLM 是你部署在自己持有的提供商账户之上的代理；OpenRouter 是替你持有提供商账户并转售模型访问权限的托管服务。代理需要一个来源；OpenRouter 就是其中一个来源。许多团队会有意同时运行两者。
利益相关声明：Kunavo 是我们的产品，并且它属于本页面的 OpenRouter 一侧——它是托管式模型来源，而不是代理。它不是 LiteLLM 功能的替代品，本页面也没有声称它是。
用一张表说明层级差异
| LiteLLM | OpenRouter | |
|---|---|---|
| 它是什么 | 你部署的软件 | 托管式服务 |
| 谁持有提供商凭据 | 你 | OpenRouter |
| 它是模型来源吗？ | 不是——它需要后端提供来源 | 是 |
| 谁负责运营 | 你：部署、打补丁、扩容、处理告警 | 你这边无人负责 |
| 推理成本 | 你自己的提供商费率 | 提供商费率加上购买额度时收取的费用 |
| 提示词文本可以留在你的基础设施中吗？ | 是 | 否 |
向下阅读“它是模型来源吗”这一行，整个比较框架就会清晰起来。其他所有差异都源于这一点。
将两者结合使用，这是常见情况
前置使用 LiteLLM，后端使用 OpenRouter：你的应用连接到一个内部端点，LiteLLM 执行按密钥预算和团队路由，OpenRouter 提供模型目录，而你无需在每个提供商处开设账户。任何 OpenAI 兼容端点都可以以同样方式接入，因此添加第二个来源用于故障转移只需几行配置：
# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
- model_name: claude-sonnet
litellm_params:
model: openrouter/anthropic/claude-sonnet-4.6
api_key: os.environ/OPENROUTER_API_KEY
# A second source behind the same proxy — any OpenAI-compatible
# endpoint works the same way.
- model_name: claude-sonnet-backup
litellm_params:
model: openai/claude-sonnet-5
api_base: https://api.kunavo.com/v1
api_key: os.environ/KUNAVO_API_KEY这才是“vs”问题通常应有的形式：不是该选哪一个，而是在托管式来源之上是否还需要代理层。
真正只需要一个时
- 仅使用 OpenRouter——你没有提供商账户，也不想拥有任何账户，并且托管式网关已经提供了你所需的路由功能。在这里添加 LiteLLM 只会增加一个需要运营的服务，几乎没有其他收益。此类别的替代方案：OpenRouter 汇总。
- 仅使用 LiteLLM——你已经拥有提供商账户，可能还享有协商费率，而你缺少的是控制能力：统一端点、按密钥设置预算、路由策略，以及始终不离开你基础设施的提示词文本。无论价格如何，转售商都无法提供最后一项。
- 两者都不用——你想要路由和治理能力，却不想运营服务。这就是托管式 BYO-key 控制平面，属于两者之外的第三类：LLM 网关的四种类别。
在决定使用哪一个之前需要检查的两件事
LiteLLM 一侧：运维范围。自托管代理是构建系统中的一个软件包，因此你的 CI/CD 和集群都会落入它的影响范围——这并非假设，因为2026 年 3 月的供应链事件已经展示了这一点。LiteLLM 的响应力度很大，对于使用 v1.83.0 或更高版本的用户，事件已经关闭，但这一架构层面的结论适用于每个自托管代理。
OpenRouter 一侧：价格下限。按目录价转接并在购买额度时收取费用的转售商，并不会自动比你自己的账户便宜；如果你的账户使用公开目录价，也不会自动更贵。值得进行的比较，是针对你所使用的模型，将你的实际费率与网关的实际费率逐模型对比。Kunavo 的大多数模型价格低于提供商官方费率，这也是从另一个方向进行的同一比较：Kunavo 与 OpenRouter 的比较。
线协议兼容性，让切换成本保持较低
两者都使用 OpenAI 线协议，任何托管式替代方案也一样（OpenRouter 文档 · LiteLLM 文档）。无论你选择哪一个，选错的代价都只是 base_url 和密钥更改，这是本页面最有用的事实：这个决定不值得一些团队为之投入数周时间。详情请参阅 OpenAI 兼容 API 指南。
常见问题
OpenRouter 和 LiteLLM 有什么区别？
它们位于不同的层。LiteLLM 是你部署的软件——一个使用你持有的 API 密钥连接模型提供商的代理服务，它本身不是模型来源。OpenRouter 是托管服务，由它持有提供商凭据，并通过一个钱包转售模型访问权限，因此它是模型来源，但不是你运行的软件。实际影响是：LiteLLM 后面至少需要一个提供商账户，而 OpenRouter 可以作为这个账户。
可以同时使用 LiteLLM 和 OpenRouter 吗？
可以，而且这是有文档支持的组合方式，而不是权宜之计——LiteLLM 提供了 OpenRouter 提供商集成。常见架构是让 LiteLLM 作为应用连接的代理，将 OpenRouter 作为其后端来源之一，从而在无需持有每个提供商账户的情况下，通过 OpenRouter 的目录获得 LiteLLM 的按密钥预算和团队路由功能。
LiteLLM 比 OpenRouter 便宜吗？
LiteLLM 不增加推理成本，因为它不转售任何内容——你支付的是自己的提供商账户费用，加上运行它所需的基础设施成本和运维工程时间。OpenRouter 收取提供商费率，并在购买额度时收取费用。因此，就单位价格而言，如果你已经拥有费率较优惠的提供商账户，LiteLLM 更划算；而在你没有这些账户时，结论会反过来：仅仅因为没有网关抽成，一个必须按目录价创建的账户并不意味着它会比转售商的费率更便宜。
我应该选择 OpenRouter 还是 LiteLLM？
不要先问哪个更好，而要问你缺少什么。如果你已经拥有提供商账户，需要对这些账户进行路由、预算和治理，那么 LiteLLM 正是为此服务的。如果你没有提供商账户，也不想管理任何账户，那么应选择 OpenRouter。如果这两个问题你都没有解决，你可能需要同时使用两者；而如果你想要路由功能却不想运营服务，那么两者都不是答案——你需要的是托管式 BYO-key 控制平面。
2026 年供应链攻击之后，使用 LiteLLM 安全吗？
2026 年 3 月 24 日事件发生后，LiteLLM 通过重建的 CI/CD 流水线发布了 v1.83.0，并轮换了维护者凭据，采用了 Mandiant 取证和签名 Docker 镜像。如果你使用的是 1.83.0 或更高版本，该事件对你而言已经关闭。完整事件经过及其在架构层面的含义——自托管代理是构建系统中的一个软件包——在选择自托管方案之前值得阅读。
Kunavo 在这个比较中处于什么位置？
Kunavo 位于 OpenRouter 一侧，而不是 LiteLLM 一侧：Kunavo 是托管式网关，负责保存上游提供商凭据，因此它是模型的另一种来源，而不是由你部署的代理。LiteLLM 部署可以像指向 OpenRouter 一样指向 Kunavo，通过 LiteLLM 的 OpenAI 兼容提供商，并设置 base URL。它不是 LiteLLM 功能的替代品。