一条请求该走大模型还是小模型？我把响应时间砍了一半，成本砍了七成

接入 AI API 之后，很多独立开发者会经历同一个阶段：所有功能都指向同一个「最强」的模型。简单的问题走最贵的通道，复杂的推理也是它，长文本还是它。功能跑通了，但延迟和账单开始变得不好解释。

我自己的项目也走过这段路。后来做了一件事：按场景拆分路由——通用大模型只处理真正需要它的请求，其余交给更小、更快的专用模型。效果用一句话概括：P95 延迟从约 4 秒降到 2 秒以内，月度推理成本降到原来的三成左右。下面把这条路径拆开讲。

一、先想清楚：哪些请求真的需要大模型

把日志里的请求按用途分桶，通常会发现分布远比想象中「轻」：

我自己项目里分类、抽取这类「螺丝钉」请求占了六成以上流量。它们以前和最难的长文分析挤同一条昂贵通道，纯属浪费。

二、前后对比：一次真实的拆分

拆分前后的配置大致是：

有几点经验值得单独说：

1. 小模型不是「降级」，是匹配。 一个只输出 {intent: "refund"} 的请求，用大模型得到的增益趋近于零，但延迟和成本是实打实的。分场景之后，用户感知最明显的是简单交互「秒回」。
2. 失败要能回落。 小模型跑偏时（比如抽取结果不符合 schema），网关层自动重试并升级到大模型。这保证质量下限，又不在 95% 的简单请求上浪费预算。
3. 复杂任务反而受益。 大模型通道的排队变短了，真正需要它的长文分析、代码生成延迟也更稳定。

三、为什么用统一网关做切换，而不是在代码里 if-else

你当然可以在业务代码里写 if (scene == "classify") use(modelB)。但这套逻辑会迅速腐化：模型迭代快，价格和额度随时变化，每次调整都要发版。

把路由放在统一网关层，价值主要有四点：

• 一处配置，全局生效。 模型名只写在一个地方，上游换模型、换供应商，业务代码零改动。
• 按场景设策略。 分类走便宜通道、写走大模型、抽取走中档模型，还可在网关上直接设每类请求的成本上限和限流，防止某个功能失控拖垮整月账单。
• 统一观测。 所有请求的延迟、token 用量、错误率在一个面板里，你才能回答「成本到底降没降、降在哪」——否则上面的前后对比根本算不出来。
• 快速试错。 想试一个新的小模型？在网关上开一条灰度路由，把 10% 流量切过去，看数据再决定，不用等一次完整发版。

简单说：网关把「选哪个模型」从代码问题变成了配置问题，而配置问题是可以随时优化、随时回滚的。

四、落地时的三个建议

1. 先分桶再拆分。 拿一周请求日志按上面的场景表归类，先看流量分布，通常前两类场景就能覆盖大部分优化空间。
2. 给每个场景定验收标准。 分类准确率、抽取的 schema 通过率、摘要的人工抽检——没有标准，就没法判断小模型「够用」。
3. 保留升级路径。 任何小模型场景都要能一键切回大模型，灰度期尤其如此。

结语

通用大模型和专用小模型不是竞争关系，而是分工关系。大模型负责「难而少」的部分，小模型负责「简单而多」的部分，中间用一个统一网关把它们粘起来——这是小团队在不增加运维负担的前提下，同时改善体验和成本的最短路径。

如果你正打算动手，可以先在一个支持多模型统一接入的网关上注册试用，把现有请求分桶跑一遍对比数据，再决定路由比例：https://api.thistoken.ai/register

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。