所以你想用 OpenRouter？

So you want to use OpenRouter? — simonwillison.net · 14 小时前 · 🤖 AI / ML

OpenRouter 的卖点之一是「自动处理回退，并为每个请求挑选最具性价比的选项」，你用一个 API 端点调用某个模型，由它路由到当时最合适的后端供应商。Mohamed Moustafa 指出，这个设计会带来一整类容易被忽视的问题：不同供应商运行不同的推理软件、优化与配置，因此同一个 OpenRouter 端点背后并不总是等价的同一个模型。具体差异包括量化级别不同，有的供应商用 FP8 甚至更低比特，有的用 FP16 或 BF16，输出质量与幻觉率随之变化；上下文窗口长度不一致，长提示词可能在某个供应商那里被截断；提示模板与系统提示的处理方式不同，有的供应商会改写或剥离系统提示；函数调用与工具使用的支持程度参差；tokenizer 实现差异导致 token 计数与计费口径不一致；部分供应商有自己的内容审核层，会在返回前过滤或改写内容；logprobs、推理过程是否返回、是否支持并行工具调用也不统一。更麻烦的是回退机制本身：同一个请求可能落到不同供应商，甚至同一段多轮会话中途切换后端，导致行为突变、评测结果不可复现、线上问题难以归因。成本方面也存在隐性代价：提示缓存通常无法跨供应商复用，回退到另一家意味着缓存全部失效，命中率下降直接推高成本与延迟；而「最具性价比」的路由策略可能选到量化更激进、单位成本更低的供应商，造成静默的质量退化——用户看到的是同一个模型名，拿到的却是更差的回答。作者的结论是，应该把 OpenRouter 当作路由器而不是等价层：在生产环境中显式固定或允许、拒绝特定供应商，按供应商分别做评测，记录每次请求实际落到了哪一家，并对关键负载考虑直连供应商 API。

核心论点

• 同一个 OpenRouter 端点背后的模型并不等价：不同供应商的量化级别、上下文窗口、采样默认值、系统提示处理、工具调用支持与内容审核策略都可能不同，用户看到的是同一个模型名称，实际得到的输出质量、可处理提示长度与行为边界却可能明显不同，这类差异在基准测试里通常被平均掉。
• 回退机制破坏可复现性：请求可能被路由到不同供应商，甚至在同一段多轮对话中途切换后端，导致同一份提示词在不同时间得到不同结果，评测数据无法复现，线上故障也无法归因到具体后端，这对需要严格对照实验的团队是硬伤。
• 成本与性能存在隐性代价：提示缓存通常无法跨供应商复用，一旦回退到另一家，缓存全部失效，命中率下降会同时推高成本与首 token 延迟；而「最具性价比」的路由可能选中量化更激进、单价更低的供应商，形成静默的质量退化，账单看起来更便宜但输出更差。
• 可行的缓解措施是：使用供应商偏好设置中的排序、允许与拒绝列表把路由约束到可信后端，按供应商分别跑评测，在日志中记录每次请求实际命中的供应商以便归因，对质量敏感的负载直接连接指定供应商的 API，把 OpenRouter 当作便利层而不是等价层。

💡 为什么值得读: 因为它把一个被当作「一个端点调用所有模型」的便利抽象拆开，逐条列出量化、缓存、上下文与回退带来的隐性成本，让准备把它放进生产环境的人先看清自己到底在买什么。

🏷️ OpenRouter, LLM, API, routing

---