OpenRouter 与直接调用：如何选择 LLM 调用方式

将大语言模型调用用于生产的三种方式

1）直接调用提供商 API

你接入单一供应商的端点，并自行负责其余部分：重试、回退、用量跟踪、密钥轮换和故障转移。

在以下情况下，这是最直接的路径：

• 你已经确定了要使用的模型，
• 延迟很重要，
• 合规要求供应商链条更精简，
• 并且你的流量足够稳定，可以根据单个提供商的限制进行规划。

2）网关 / 聚合服务 / 中转服务

你将请求发送到一个中间层，由它转发给众多提供商中的一个。OpenRouter 是最知名的例子，但这种模式并不限于某一家公司。

在以下情况下，这种方式很有吸引力：

• 你希望通过一次集成获得多种模型选择，
• 你需要回退路由，
• 你经常进行模型实验，
• 或者你不想管理多个供应商的 SDK 和计费账户。

3）自行托管

你在自己的基础设施上运行开放模型，通常通过自己的路由器提供访问。

在以下情况下，这种方式更有优势：

• 数据控制权不可妥协，
• 用量足够大，能够让硬件保持高利用率，
• 或者你需要可预测的每 Token 成本，并且能够承担运维负担。

实际使用中的差异

人们往往忽略这一点： 最佳选择通常不能只看 Token 单价。还要考虑整个故障链条。

这张表掩盖了一个重要事实： 网关很少能凭空省钱。只有当它能避免过度设计、减少停机时间，或让你自动将任务路由到满足要求且成本最低的模型时，才会节省成本。

成本究竟如何变化

如果所有任务都使用同一个模型，直接调用通常最简单，也最便宜。但大多数实际系统更复杂：

• 产品内的聊天功能使用高端模型，
• 客服回复草稿使用更便宜的模型，
• 摘要任务使用小型快速模型，
• 而突发流量需要额外容量来承接。

这时，中转服务就能发挥作用。原因并不是它的标价更低，而是它让你能够集中制定路由决策。

一个简单的策略可以是这样的：

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

这份配置不针对特定厂商，而是一个合理的路由器应有的结构。实际使用中，节省成本靠的是避免浪费：

• 不要把每个信息提取任务都交给最昂贵的模型，
• 不要对不稳定的提供商无限重试，
• 不要仅仅为了每逢周五激增的那 2% 流量，就一直维护另一套集成。

一个常见陷阱： 如果你的应用涉及工具调用或副作用，重试可能导致操作重复执行。如果网关在请求超时后重试，模型可能再次发出相同的函数调用。如果没有幂等键和周密的工具设计，“有用的回退机制”就会变成“重复创建工单”或“重复扣款”。

网关何时真正有用

当以下一个或多个条件成立时，我会考虑使用聚合器或中转服务：

• 你仍在摸索工作负载的特点。 在早期，你还不知道 GPT-5.5、Claude Opus 4.8、Sonnet 4.6、Gemini 3 或某个开放模型，哪个最适合你的任务。
• 你希望按任务路由，而不是按厂商路由。 分类器可以将短提示词发送给便宜且快速的模型，并在 Fable 5 这类模型确实更适合时，将长上下文任务交给它。
• 你需要快速的故障回退方案。 如果某家提供商开始限流，中转服务可以在用户察觉之前转移流量。
• 你不想管理五套计费系统。 一张账单和一套集成，比同时管理多个密钥、配额和支出仪表板更容易。
• 你的多租户产品需要抽象层。 网关让你可以在底层更换提供商，而无需重写应用。

如果你的团队规模较小，这一点尤其有用。我见过一些创业团队，他们花在对接提供商专用重试逻辑上的时间，比创造产品价值的时间还多。中转服务可以将这些工作集中到一处。

何时直接调用更合适

当你重视以下任意一点时，直接使用提供商 API 通常更有优势：

• 最低延迟。 当产品的延迟预算紧张时，少一跳就很重要。如果你希望交互在 300 毫秒内完成，让用户感觉“即时响应”，额外的网络和路由开销可能会占掉相当大的一部分预算。
• 严格的合规边界。 每增加一个数据处理方，就会多一项合作关系、一套数据保留规则和一次合同审查。
• 厂商专属功能。 一些提供商提供的能力，会被聚合器在统一接口时抹去，或迟迟得不到支持。
• 高且可预测的调用量。 一旦用量稳定下来，自建路由可能比为中间层付费更便宜。
• 更清晰的支持渠道。 出现问题时，相互推诿的情况更少。

隐藏的好处是运维上的清晰性。如果调用路径是直接的，就更容易定位故障根因。调用失败时，问题通常出在你的代码或提供商一侧。使用网关时，你还需要判断责任是在中转服务、中转服务的路由层，还是上游提供商。

自托管是另一回事

自托管开放模型并不只是“更便宜的 API，只不过运行在我的服务器上”。它是一个系统工程问题。

你需要考虑：

• GPU 容量规划和利用率，
• 批处理，
• 量化，
• KV 缓存压力，
• 自动扩缩容，
• 热启动，
• 安全过滤器，
• 模型更新，
• 以及回滚流程。

优势在于控制权。如果你的工作负载稳定，且规模足够大，自托管在经济上可能很有吸引力。但只有让硬件保持充分利用，成本账才算得过来。闲置的 GPU 很昂贵，让模型服务技术栈在高负载下稳定运行所需的工程时间也同样昂贵。

另一个常见陷阱是质量漂移。某个开放模型今天也许足以胜任摘要任务，但当提示词长度、风格要求或工具使用方式发生变化时，评估结果可能会大幅下滑。不要假定“开放”就自动意味着“成本足够低，可以替代托管 API”。

实用的混合模式

在实际系统中，最佳架构通常是混合式的：

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

而在应用内部：

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

这种模式既能保持关键路径简单，又能让你灵活运用路由。我发现，团队在上线运行一个月后，往往会采用这种方式：核心用户体验使用直接调用，实验和溢出流量使用网关，只有在经济收益或隐私优势确凿时才采用自托管。

隐私、延迟与信任

到了这里，工程问题就变成了政策问题。

隐私

网关会改变你的信任边界。即使提示词会转发给上游，你仍然需要回答：

• 中转服务会记录提示词吗？
• 这些提示词会保留多久？
• 哪些次级数据处理方可以查看它们？
• 能否让特定租户始终走受限路径？
• 是否支持固定处理区域？

对于受监管的工作负载，“提供商承诺会妥善处理”还不够。你需要书面记录，以及与之相符的设计。

延迟

中转服务会增加一跳。这并不一定会让应用变慢，但确实会增加不确定性。如果你的应用请求频繁，而且 token 流式输出很重要，那么每增加一层，都可能让首个 token 的响应时间更难预测。

速率限制

直接集成会让你直接面对提供商的限制。网关可以通过将流量分散到不同提供商来缓解限制，但也可能引入自己的限流机制。换句话说，你可能只是用一种限制换了另一种。收益在于弹性，而不是不受限制。

我采用的决策原则

如果必须用一句话概括这个选择： 当你已确定模型并重视调用路径时，直接调用；当你重视选择余地和韧性时，使用网关；当控制权和稳定的利用率足以抵消运维成本时，采用自托管。

几条具体的经验法则：

• 如果你正在交付首个生产功能，而且只需要一个模型，就从直接调用开始。
• 当你至少需要两类不同的模型，或者故障转移开始出现在事故复盘中时，再加入网关。
• 只有掌握真实的利用率数据，并且有明确理由自行掌控技术栈后，才采用自托管。
• 使用网关进行路由实验，但要确保关键路径具备幂等性。
• 衡量端到端成本，而不只是 token 单价。

实践要点

• 优先选择 直接调用 API ，以获得最少的延迟开销、最简单的调试流程，以及最有力的厂商专属支持。
• 优先选择 网关／聚合器 ，如果你需要多模型路由、回退保障，或通过一套集成接入多家提供商。
• 优先选择 自托管 ，仅适用于你能让硬件保持充分利用，并能接受运维复杂性的情况。
• 建立 幂等性和规范的重试机制 ，然后再加入自动回退。
• 比较 总成本：token、加价、重试、工程时间和事故恢复。
• 请将 隐私和数据保留 ，从一开始就将其纳入决策，而不是等采购部门问起后再考虑。
• 采用 混合架构 如果你的工作负载既有高端模型调用路径，也有通用模型调用路径。

如果你愿意，我可以针对特定受众，把这篇内容改成观点更鲜明的版本，例如面向初创企业开发者、平台团队或合规要求严格的企业团队。