OpenRouter 与 LiteLLM：按实际工作负载比较总运行成本
OpenRouter 和自行运行的 LiteLLM 代理，会把不同责任交给团队。应按真实工作负载比较模型访问、供应商账单、基础设施、升级与故障处理；软件价格或 token 单价都无法单独决定选择。
发布 2026-09-23 · 更新 2026-09-29 · KeepRouter Editorial · 6 分钟阅读
OpenRouter 与 LiteLLM 都可以放在使用 OpenAI 风格客户端的应用后面，但运营决策在于团队准备购买什么服务、自己运行什么系统。OpenRouter 通过自己的服务提供托管访问和路由；LiteLLM 同时提供 Python SDK 和可由团队运行的代理。本文比较的是自行运行 LiteLLM Proxy 的情况；若选择托管版，需要另做商务与运维工作表。
有用的比较从工作负载开始：多少应用调用哪些供应商，推理费由哪些账户支付，请求失败后谁来处理。OpenRouter 对比页与 LiteLLM 对比页介绍一般适用条件。这里的目标是一张能够随流量与人力变化而重新计算的成本表。
填价格前，先写清责任归属
| 责任 | 托管 OpenRouter 路径 | 自行运行 LiteLLM Proxy |
|---|---|---|
| 网关运行时 | 服务方运行 | 团队自行运行 |
| 供应商访问 | 使用服务可用线路或相应账户选项 | 配置实际使用的供应商账户与线路 |
| 代理升级 | 服务方控制部署 | 团队测试并部署版本 |
| 用量查看 | 服务记录及支持的导出方式 | 配置代理计量及相关依赖 |
| 故障调查 | 应用证据加服务支持和状态 | 应用、代理、数据库与供应商证据 |
| 功能要求 | 符合服务契约 | 符合已部署代理和供应商契约 |
这是责任分配，而不是质量或可靠性排名。已经拥有平台团队的组织，可能很容易承担代理运维；小团队则可能希望减少一个需要部署的服务。仅凭“开源”或“托管”两个词，都无法得出成本结论。
使用假设透明的总成本公式
对每个候选估算：推理费用 + 平台费用 + 基础设施 + 运维时间 + 在评估期内分摊的迁移费用。存储与可观测能力单独收费时也应计入；与实际账单有关的税费或支付费用应保持可见。供应商当前价格应来自其官网，不要复制旧对比文章里的固定费率。
假设两条路径的每月推理工作负载都是 $600。路径 A 另收 $40 服务费用，需要两小时维护；路径 B 需要 $70 基础设施和六小时运维。假设内部人力成本每小时 $50，两者在迁移成本之前分别为 $740 与 $970。以上数字只是演示工作表，并非 OpenRouter、LiteLLM 或 KeepRouter 的报价。
如果团队已有相关基础设施，路径 B 的新增运维只需要一小时，在基础设施假设不变的情况下，其总额会变为 $720。模型账单没有变化，团队条件却能改变决策。应说明计算的是新增现金支出、分摊人力成本，还是两者兼有，不能在没有解释的情况下混为一谈。
比较三种工作负载形态
| 工作负载 | 需要回答的问题 | 可能改变选择的证据 |
|---|---|---|
| 单个应用探索多个模型 | 托管访问能否满足必要能力 | 实际请求通过且账户费用可接受 |
| 多团队已有供应商合同 | 共享 Key、预算与归属是否值得增加代理 | 按团队核对的用量与明确运维负责人 |
| 功能依赖供应商专有能力 | 哪条路径保留准确行为 | 该能力的端到端固定案例 |
第一类要计算开通供应商账户和维护多个集成的工作；第二类要计算代理部署、数据库维护、备份、Key 生命周期、升级及告警处理；第三类则先测试功能，再计算价格。一条不满足条件的线路，不会因为其他文本能力单价低就变得适用。
LiteLLM 的消费追踪文档说明费用记录和配置方法。这些记录有助于归属，但代理估算仍需要与供应商实际计费规则核对。OpenRouter 的供应商路由文档说明请求可用控制。应核查应用真正依赖的选项，不能把名称接近的网关功能视为可以互换。
建立包含失败情况的小规模验证
选择一组固定任务、一个文本模型，以及一种必要的工具或结构化输出流程。记录准确模型和供应商策略、输入输出单位、完成任务、失败尝试、耗时与扣费。还应在受控环境中测试一次实际有意义的超时和错误凭证。普通文本调用成功，并不能说明团队可以顺利调查生产中的工具循环故障。
将结果保存为有日期和固定实验标识的记录。最小工作表可以使用以下列：
candidate, sdk_version, proxy_version, model_id, provider_policy,
task_id, accepted_result, attempts, input_tokens, cached_tokens,
output_tokens, elapsed_ms, recorded_charge, operator_minutes缺失的扣费或时间不要填成零，应标记未知，并在宣布哪条路径更优之前解决。任务验收应使用应用真正需要的条件。如果请求靠重试获救，就把此前尝试与恢复耗时一起计算，而不是只保留最后一笔成功请求。
决策中保留迁移和维护费用
现有应用可能使用 OpenRouter 专属路由字段、原生 SDK 方法或账户功能。迁移到 LiteLLM 时，需要明确映射，不能只改主机；反方向迁移也可能失去团队原来控制的选项。盘点这些依赖，并在代表性任务通过前保留完整回滚配置。
记录代理升级、数据库故障、供应商 Key 过期和价格不一致分别由谁处理。有自己的运行历史时，用历史估算这些任务频率；没有历史时，使用区间并写清未知项，不能把推测包装成精确的全年节省额。
把现金支出与分摊工时分开
工作表同时展示两种合计：新增现金支出，以及现金加分摊工程时间。固定薪资工程师的时间会占用产能，但不一定形成这个月新增账单。这解释了为什么同一套自托管适合某个团队，却给另一个团队增加负担。LiteLLM 成本追踪指南覆盖请求费用，基础设施与维护应自行加入，不能把代理费用看板当成全部运营成本。
KeepRouter 在工作表中的位置
对于符合其公开端点和账户模式的工作负载，KeepRouter 是另一个可以评估的托管目录选项。选择 Claude Sonnet 4.6这样的准确条目，用 API 费用计算器按公开单位估算，再验证请求和扣费。这里列出 KeepRouter，不代表它具备相同的供应商选择、自托管或功能覆盖能力。
最终应选择满足工作负载、且责任成本可持续承担的路径。供应商合同、流量、必要功能或人员安排变化时，重新检查决策。托管与自托管指南提供更广的架构问题，而这张工作表让问题具体到可以执行和复核。
常见问题
开源软件等于零成本网关吗？
不等于。除推理费外，还要计算基础设施、配置、升级、存储和故障处理。
本文比较了所有 LiteLLM 产品吗？
没有。本文聚焦自行运行的代理；托管服务需要按当前商务与运行方式另行比较。
文中的美元数字是厂商报价吗？
不是。它们是演示运维投入如何改变总成本的假设工作表数据。
成本比较应该用什么指标？
先确认必要功能满足条件，再比较每个合格工作负载的总成本，包括重试和运维。
参考的一手资料
本文最近复核 2026-09-29
- [1] OpenRouter pricing
- [2] OpenRouter provider routing
- [3] LiteLLM proxy and SDK documentation
- [4] LiteLLM spend tracking