想用 OpenRouter？這些隱藏坑你得先知道

OpenRouter 这类 API 聚合平台近年来在开发者社区里迅速走红，它的核心承诺非常诱人：你只需要对接一个端点，就能访问成百上千个模型，平台还会自动处理失败回退、为每个请求挑选当前性价比最高的后端。对搭建 AI Agent 或做快速原型的人来说，这几乎是一劳永逸的解法。然而 Simon Willison 转载的 Mohamed Moustafa 的分析却给这股热潮泼了一盆冷水，提醒开发者在享受便利之前，先看清它背后可能付出的隐性代价。核心问题在于，OpenRouter 本身并不运行模型，它只是一个路由层，真正执行推理的是背后数十家不同的供应商，而这些供应商虽然对外宣称提供同一个模型，实际却跑着各不相同的推理服务软件。有的用 vLLM，有的用 TGI，有的用 SGLang，还有的用各家自研的推理栈，每种软件在显存管理、并发策略、采样参数、上下文处理上都有一套自己的默认配置和优化取向。

这就带来一个直接后果：同样的模型名称、同样的输入，经过不同的后端，可能得到行为明显不同的输出。Moustafa 观察到的一个典型现象是，同一个请求有时被路由到 A 后端，有时被路由到 B 后端，而这两个后端对同一 prompt 的处理结果并不一致。这种不一致在细节上可能很微妙，比如输出的格式、对边界指令的遵循程度、长上下文里的信息召回准确率，甚至在同样 temperature 设置下随机性的表现都不一样。对普通聊天场景，这种差异或许无伤大雅，但一旦你把它放进需要严格格式约束的 Agent 流程、函数调用链或者需要稳定输出的生产系统里，不可预测性就会变成实打实的故障源。从技术层面拆解，这个问题的根源在于「模型」和「模型的部署实现」是两个不同的概念。

开源模型权重是公开的，但如何高效地把权重跑起来，各家有各自的工程实现和调优空间。供应商为了控制成本或提升吞吐，会调整批处理大小、量化精度、KV cache 策略、是否开启 speculative decoding 等等，这些都会悄悄改变模型的实际表现。而 OpenRouter 的自动路由机制恰恰是围绕成本和可用性来决策的，它并不会、通常也无法保证每次都把你送到同一个后端。换句话说，你买的是「某个模型」的抽象，但实际交付的是「某个后端上某个实现」的具体行为。从商业和生态角度看，这种模式其实反映了大模型消费层的一个结构性变化。

过去开发者直接对接 Anthropic、OpenAI 这类单一厂商，行为可预期但选择受限；现在聚合平台用统一接口打破了这种锁定，代价是把复杂度从接口层转移到了运行时，由调用方去承担不可预测性的风险。对绝大多数探索性项目，这个交易是划算的，因为探索阶段本来就需要广泛试错、对稳定性要求不高。但对那些把模型调用当作基础设施的生产系统，尤其是需要 SLA、需要可复现结果、需要精确控制行为的场景，把路由决策完全外包给一个以成本为导向的自动机制，就需要格外谨慎。值得注意的信号是，越来越多的工程实践开始从「依赖平台自动路由」转向「锁定特定后端」甚至「自建推理服务」。这并不意味着 OpenRouter 不好，而是说明当 AI 应用走向成熟，开发者对可控性的需求会压过对便利性的需求。未来值得观察的方向包括：聚合平台是否会引入更细粒度的后端选择能力，比如指定推理软件版本、锁定供应商、固定采样参数，让开发者在享受聚合便利的同时保留对确定性的掌控；以及 Moustafa 这类一线实践者的反馈，是否会推动平台在路由策略上增加可观测性和可配置性。对开发者的实际建议是，如果你只是在做实验、搭原型或者对输出一致性要求不高，OpenRouter 的自动路由依然非常香；但一旦进入生产，至少要把关键路径的模型调用固定到明确的后端，并在上线前做足跨后端的回归测试，把那个「看不见的后端」从黑盒变成可控变量。