使用 OpenRouter 时需要注意的路由差异
Simon Willison5 天前
OpenRouter 的一个主要卖点是：它可以自动处理故障回退，并为每次请求选择成本更优的选项。开发者只需要调用某个模型的统一 API 端点，请求就会被路由到可用的后端提供商。
但这种便利也可能带来一些实际问题。
同一个端点，不一定意味着同一种行为
不同模型提供商可能使用不同的推理服务软件、优化策略和运行参数。结果是，即使你调用的是 OpenRouter 上同一个模型端点，实际承接请求的后端不同，模型行为也可能出现差异。
这类差异可能体现在：
- 输出稳定性不同
- 推理行为不同
- 参数支持程度不同
- 响应格式或边界情况处理不同
- 性能和延迟表现不同
对于只做简单文本生成的场景，这种差异可能不明显；但如果业务依赖较强的一致性，自动路由就需要额外关注。
多模态和推理参数也可能存在差异
文章中特别提到，有些提供商即使承接的是视觉模型，也可能并不具备完整的视觉能力。
此外，类似 reasoning effort 这样的推理强度选项，在不同提供商处的处理方式也可能不同。这意味着相同请求参数并不总能得到完全一致的执行效果。
可以指定后端提供商
OpenRouter 提供了控制路由的方式。开发者可以使用 provider.only 选项，只允许请求路由到指定提供商。
如果需要查看某个模型 ID 当前有哪些可用提供商，可以使用 /endpoints 方法获取该模型对应的提供商列表。
实践建议
如果你在生产环境中使用 OpenRouter，尤其是对一致性、能力边界或多模态功能有要求的场景，建议：
- 不要默认假设同一模型端点在所有后端上行为完全一致；
- 测试不同提供商的实际表现；
- 对关键业务使用
provider.only固定后端； - 对视觉、推理强度等高级能力进行单独验证；
- 在上线前确认故障回退策略是否会引入不可接受的行为变化。
OpenRouter 的统一入口和自动路由确实能简化接入流程，但如果业务依赖可预测性，就需要把“后端提供商差异”纳入工程设计。