同一模型的两张面孔
OpenRouter是一个热门的AI推理路由平台，它将用户请求分发到数十家GPU供应商。开发者用iMessage AI助手Olly在OpenRouter上处理了超过1800万条消息后，总结了一份详尽的避坑指南。核心发现令许多开发者意外：用户调用deepseek/deepseek-v4-flash时，实际被分配到约20家不同的托管公司，而它们的性能表现差异之大，足以让依赖该模型构建的生产系统面临严重风险。同一份模型权重，在不同供应商的GPU上运行，产生的输出质量可以相差整整20个百分点。
基准测试揭示的鸿沟
OpenRouter在平台上为每个供应商运行相同基准测试：GPQA Diamond衡量知识能力，TAU-Bench Airline评估工具调用准确率。DeepSeek V4 Flash 0731的结果表明，DeepSeek自家服务在GPQA上达到90%，TAU得分81%。而DigitalOcean托管的相同权重模型，GPQA仅75%，TAU只有58%。大部分供应商在工具调用任务上比官方低5至7分，但有四个供应商在知识测试上出现断崖式下降。对于构建智能代理的应用场景而言，TAU才是关键指标——20分的差距绝非噪声，而是可以决定用户能否成功完成任务的实质差异。
视觉任务的隐藏缺陷
该开发者在图像任务中发现了更令人不安的现象。他用三张简单的测试图片——一个字母、一块纯色、一个文字背景图——分别在两家视觉模型的每个供应商端点上运行。结果DeepInfra的Qwen端点把字母K识别为R，将红色描述为蓝色，把单词umbrella说成funny，而同一权重的其他四个端点全部正确。MiniMax的两个供应商端点甚至完全没有收到图像输入，但仍然返回200状态码，假装处理成功。这意味着开发者如果不主动验证每个供应商的视觉能力，生产环境中可能长期使用着无法正确处理图像的端点，而系统日志不会发出任何警告。
推理力度的虚标问题
reasoning.effort参数在OpenRouter上被所有供应商接受，但实际效果因模型和供应商而异。开发者针对DeepSeek V4 Flash 0731，将每个供应商分别固定在low、high、max三档推理力度，各运行三次，监控推理token输出量。结果发现在某些供应商上，推理力度的调整完全不产生任何效果，输出token数相同；而在另一些供应商上，max设置的推理token量是low的五倍以上，但答案质量并无明显提升。这意味着开发者为高级推理能力付费，却可能只获得与基础设置相同的输出。
流式输出的未决问题
OpenRouter支持中间件层在请求送达模型前修改消息内容，其中一个用法是将模型名称中的推理标签插入聊天前缀，以强制启用扩展思考模式。然而，这种技巧在供应商之间的兼容性参差不齐，部分供应商对注入的思考标记完全忽略，导致开发者以为已启用深度推理，实际仍运行在标准模式。此外，流式传输模式下每个供应商的延迟和分块策略不同，有些在第一个token到达前的首字节延迟可达数秒，对交互式应用的用户体验产生直接影响。
日志与切换的盲区
开发者指出，OpenRouter的日志功能对调试供应商问题至关重要，但许多开发者未意识到不同供应商的错误处理方式差异巨大。有些供应商在过载时直接返回503错误，有些则静默截断输出或返回部分结果。当某个供应商出现问题时，OpenRouter的自动切换机制会将流量转移到备选供应商，但这个过程往往对用户透明，开发者可能不知道自己的系统正在使用一个性能更差的供应商。
实践建议与底线
文章最后给出几条具体建议：首先，不要依赖平台展示的基准测试排名，而是用自己应用的真实提示词对候选供应商进行A/B测试；其次，每天监控各供应商的通过率和平均成本，因为性能表现会随时间波动；第三，对于视觉任务，必须主动验证每个供应商端点是否真正传递和处理了图像输入，而非只检查HTTP状态码；最后，在供应商切换后重新运行基准测试，因为同一供应商在不同模型上的表现可能完全不同。这位开发者用1800万条消息的真实经验证明，在AI推理路由的世界里，读基准测试不如跑真实工作流可靠。