开源权重模型冲到生产流量三成：模型路由该怎么改

过去讨论开源权重模型时，很多团队还停留在“能不能替代闭源大模型”的争论里。现在更现实的问题已经变成：哪些任务应该先交给低成本模型，哪些任务必须留给前沿闭源模型，以及这套选择如何在生产系统里稳定执行。

Vercel 在 2026 年 7 月发布的 AI Gateway Production Index 给了一个值得关注的信号：在它统计的 6 月生产流量中，open-weight 模型已经处理 29% 的 Gateway Token，但只占不到 4% 的支出。换句话说，低成本模型不再只是测试环境里的备选项，而是在真实生产流量里承担了相当一部分高频请求。

这不是“闭源模型不重要了”。同一份数据也显示，Anthropic 在 32% 的 Token 上拿到了 61% 的支出，并且在编码代理、后台代理、应用生成等高风险场景里占据更高支出份额。真正变化的是：生产 AI 系统正在分层。高频、可验证、容错较高的任务开始向低成本模型迁移；高风险、长链路、需要强规划能力的任务仍然留给更贵的前沿模型。

为什么这件事会影响 API 架构

如果团队只在代码里写死一个模型名，成本优化就只能靠人工改配置。模型更新、价格变化、供应商波动、数据合规要求都会变成一次次临时修改。

Vercel 的 7 月数据里还有两个细节值得放在一起看：

Token 量环比增长 29%，支出增长 27%，平均 Token 价格没有继续上升。
open-weight 模型份额从 4 月的 11% 增至 6 月的 29%，DeepSeek 在 Vercel AI Gateway 的 Token 占比达到 22.6%。

这说明不少应用并不是简单减少 AI 使用，而是在更精细地分配模型。低成本模型承接更多高频请求，昂贵模型保留在结果影响更大的步骤上。对团队来说，路由规则本身开始变成成本治理能力的一部分。

不要把“便宜模型”当成唯一目标

便宜不是生产路由的唯一标准。OpenRouter 在 6 月 open-weight 模型盘点中提到，DeepSeek、GLM、MiniMax、Nemotron 等模型的能力、价格、上下文长度、模态能力、许可和数据策略差异很大。某个模型在编码或长上下文任务上表现好，不代表它适合所有业务请求。

更稳的做法是先按任务类型拆分：

高频但可验证的任务：摘要、分类、抽取、格式转换、初稿生成，可以优先测试低成本模型。
需要强规划的任务：代码修改、复杂工具调用、多步代理，可以使用 open-weight 强模型试跑，但要保留前沿模型兜底。
高风险任务：影响交易、法务、权限、安全策略、客户承诺的输出，不应只按价格路由。
敏感数据任务：要把供应商地区、数据保留、是否用于训练、企业协议和 BYOK 策略纳入路由条件。

这也是为什么模型路由不该只是一段 if/else。真实系统需要同时看模型能力、价格、延迟、失败率、上下文长度、数据策略和业务风险。

供应商风险也进入了模型选择

成本之外，模型可用性正在变得更复杂。Financial Times 报道称，更多公司正在因为成本和开放权重灵活性评估中国 AI 模型；CSET 对这篇报道的摘录也指出，企业有动力把部分工作负载迁往更便宜、能力已经可用的模型。

但另一边，Wall Street Journal 报道称，中国也在考虑限制部分受欢迎模型的访问方式，以保护本土技术。这意味着团队不能只问“哪个模型现在便宜”，还要问：

如果某个模型或托管方突然不可用，是否有同类替代模型？
如果供应商修改数据政策，哪些请求需要立即切走？
如果某个地区或客户不允许跨境处理，路由层能否按项目、地区或数据类型过滤供应商？
如果低价模型输出质量波动，是否有质量阈值和自动升级策略？

模型 API 的风险已经不只是技术风险，也包括政策、合同、地区和供应链风险。把这些规则散落在业务代码里，后续会很难维护。

一个更实用的三层路由策略

团队可以先用三层策略替代“所有请求都走一个模型”。

第一层是默认模型。选择一个价格、质量、延迟都稳定的模型，承担大部分常规请求。它不一定是最强模型，但要足够可靠、可观测、容易替换。

第二层是升级模型。对复杂任务、长上下文任务、编码代理、关键客户请求设置升级条件。比如当输入长度超过阈值、工具调用失败、评估分低、用户显式要求高质量时，切到更强模型。

第三层是兜底模型。当默认模型超时、限流、输出校验失败或供应商不可用时，自动切换到备选供应商。这里的目标不是永远选择最便宜的模型，而是让服务不会因为单一模型故障而中断。

这套策略还应该配合三类观测数据：

成本：按模型、供应商、项目、用户、任务类型统计 Token 和费用。
质量：记录重试率、人工修改率、自动评估结果、用户反馈。
稳定性：跟踪延迟、限流、失败码、供应商可用性和降级次数。

当这些数据回到同一个控制层，团队才能判断“哪些请求值得用便宜模型”，而不是只看模型报价表做决定。

现在该做什么

如果你的应用还处在单模型阶段，可以先做四件事：

把模型名从业务逻辑里抽出来，放到统一调用层。
为每类请求标注任务类型、风险等级和是否包含敏感数据。
用真实请求样本测试 2 到 4 个候选模型，而不是只看公开榜单。
建立按模型和任务类型拆分的成本看板，先找出最高频、最低风险、最适合迁移的请求。

RouterHub 这类统一模型调用网关适合承担这层工作：统一入口、密钥隔离、供应商切换、成本统计、fallback 和团队维度的使用记录，都应该在调用层解决，而不是让每个业务服务单独处理。

open-weight 模型进入生产流量，不代表团队可以完全抛弃前沿闭源模型。更准确的判断是：模型选择正在从“选一个最强模型”变成“为不同任务建立一套可执行的路由策略”。谁能更快看清自己的请求结构，谁就能更早把成本、质量和稳定性放到同一张表里管理。