想用OpenRouter？先看清这些坑
So you want to use OpenRouter?
我运营着运行在iMessage上的AI助手Olly，通过OpenRouter处理了超过1800万条消息。看似简单的调用背后，实则处处是坑。同一模型在不同Provider手中的表现天差地别，有的甚至存在视觉盲区或返回空内容却报200 OK。量化精度并非质量的保证，工具调用的解析也常因Provider而异。从DeepSeek到GLM，每个Provider的“私有”优化和Bug都不同。本文基于真实生产环境经验，总结了10个关键陷阱，包括如何正确测试、处理空响应以及理解不同Provider的协议差异。在OpenRouter上，选择Provider比选择模型更重要。
当你在OpenRouter上请求deepseek/deepseek-v4-flash时，你得到的可能是约20家你从未听说过的公司中任意一家的服务，它们在纸面上是同一个模型，但在现实中却截然不同。
HN 评论区
199- joshstrange
这和我自己小得多的 OpenRouter 使用经验完全吻合。它简直不可靠到令人发指，你被迫要固定（pin）特定的提供商，即便如此，结果依然像作者发现的那样全凭运气。
OpenRouter 兜售的是“像大宗商品一样随意切换提供商”的理念，但这与事实相去甚远。提供商 A 往往无法被 B 或 C 无缝替换（正如作者所发现的）。这简直让人抓狂，你坐在那里会忍不住想：“难道 OpenRouter 其实是个裸奔的皇帝吗？还是我搞错了？”
我热爱 OpenRouter 的_理念_，也许 Stripe 能改善这种状况，但我目前找到的唯一理智的使用方式，就是死死锁定提供商，锁到我都怀疑是不是该直接用这些提供商算了。
如果不锁定提供商，你迎接的将是一场痛苦和不可靠的噩梦（模型能力参差不齐、速度忽快忽慢等等）。
- jmward01
以上所有观点我都同意，但还有更多。让我最终离开并转向单一提供商的原因是 Token 缓存。我不得不持续屏蔽那些无法正确缓存的提供商。我看到性能暴跌，然后去查日志，发现系统轮换进了一家新提供商，而发给它的每个请求都没有缓存，因为这家提供商显然已经坏了。这种情况已经发生过几次，基本上彻底摧毁了成本节省（而且这些提供商的质量通常也很差）。他们难道不监控这些简单的事情吗？他们自己的日志就清楚地显示了某些提供商的这种模式。如果提供简单的缓存率统计，他们几乎可以瞬间屏蔽这些提供商。
- vova_hn2
> 同一个模型的基准测试结果会大相径庭
提供商可能在不披露的情况下提供量化（quantized）版本。这真是一件憾事，因为对于某些任务，我完全愿意用准确性换取成本。但不幸的是，除非你在自己（或租赁）的硬件上运行模型，否则你根本无法明确选择你想要的量化程度。
顺便问一下，有人知道 LLM Gateway 是否也存在同样的问题吗？我正在考虑尝试它，但还没动手。
- neya
OpenRouter 最“棒”的地方大概就是他们的响应里硬编码了 200 OK 状态码。
我以前经常收到内容为空的响应（content: ""），我一度反复检查自己的代码，怀疑是不是自己哪里写错了，直到我意识到大多数 AI 提供商的基础设施也是靠“氛围感”（vibe coded）堆出来的，想跟这种状况对抗纯属徒劳。
- wren6991
没错，这描述得很准确。有些提供商简直就是骗局。我遇到过一家提供 GLM-5.2 的提供商，其速度高达 200 tps（荒谬地高），而且坏得离谱：它会在一次对话中完整读取同一个文件 20 次，迅速将上下文堆到 30~40 万 token，然后对我收取预填充（prefill）费用。我直接把它拉进了黑名单，但他们还是先从我口袋里骗走了几美元。
另一个常见的烦心事是，请求被路由到一家每秒只吐出 ~1 个 token 的提供商（哪怕是像 DeepSeek V4 Flash 这样的小模型）。如果你取消请求，你依然要为预填充和生成的那几个 token 付费；如果你不取消，你可能得等上 10 分钟才能结束这一轮对话。
整体体验其实还不错，也是尝试新模型的最佳途径，但他们似乎对提供商不做任何真正的审核，也不施加任何质量标准，偶尔就会让你吃大亏。
- rolfus
这些信息非常有用，而且来得正是时候！我在新发布的跑步追踪器中使用了 OpenRouter（用于实时指导和跑后复盘）。我随时间对大量模型进行了基准测试，以评估它们在这一特定任务上的能力，并注意到有时模型会毫无理由地表现不佳。今后我肯定会把模型提供商纳入我的基准测试套件中！
- binarymax
这简直是铁证如山。我们正使用 OpenRouter 进行一些研究任务，这让我开始怀疑一切。我怀疑很多模型提供商都遇到了类似的问题：https://forum.level1techs.com/t/why-your-local-llm-feels-dum... （HN 讨论：https://news.ycombinator.com/item?id=49402232）
- numlocked
我是 OpenRouter 的联合创始人兼 COO。
感谢大家在这里的反馈。其中一些情况我们已知晓，一些我们还不清楚。有些我们可以修复，有些则是推理（inference）本身固有的问题（而且我们实际上已经大幅改善了这种情况）。
从理念上讲，OpenRouter 试图做两件事，这两件事有时是相互矛盾的：
1. 让你能够利用众多提供商的大量算力，并且“开箱即用”，无需操心。
2. 提供海量的推理选项，让你可以选择截然不同的价格/性能权衡、数据政策、地理目的地、创新硬件等。
这两者天生就是“奇怪的床伴”，我们仍在努力改进，试图让它们同时成立。
关于这篇文章的一些快速想法：
1. 基准测试：没错！各提供商的基准测试结果确实不同。我们在实时端点上持续运行基准测试，监控中位性能，如果某提供商的波动超过一个标准差，就会将其踢出默认路由池。我们非常努力（并持续投入）以确保提供次级推理服务的提供商无法钻空子，并且我们的路由机制会主动避开它们。所以那张图表是准确的（那是我们的图表），并且它直接影响我们的路由决策！
2. 那个问题确实很糟糕，我们会修复它。抱歉。
3. 当我们接入新提供商时，我们会运行与作者基本相同的测试，以验证参数是否按预期工作。如果参数 […]