2025 年之前，谈到降本，大家的第一反应是”砍调用量”。到了 2026 年，真正把账单打下来的团队，靠的不是少调模型，而是把请求分流——同一套 Agent 工作流里，简单任务交给开源小模型，难任务才碰旗舰 API。这件事在过去半年里从”极客玩法”变成了默认架构，原因很直白：旗舰模型的输入价格一年降了 60% 以上，但它的绝对单价仍然是小模型的十几倍，而真实流量里大部分请求根本用不到那个价位的能力。
我们对 10 条生产工作流做了 92 天分流改造，覆盖 2140 万次真实请求。这篇文章不复读”开源追平闭源”的口水文，只回答三个问题：流量到底怎么分、分错了代价多大、用什么样的路由规则能把账算清楚。
一、先承认：分流不是万能药，它的收益完全取决于你的流量形状
很多团队看到”开源小模型扛了七成流量”就照抄，上线两周发现质量投诉翻倍。问题在于他们没先看自己的流量分布。我们 10 条工作流的请求构成是这样的：
| 任务类型 | 请求占比 | 长度中位数（输入 token） | 失败容忍度 | 旗舰模型月成本占比 |
|---|---|---|---|---|
| 意图分类 / 路由判断 | 31.4% | 180 | 高（错了有兜底重试） | 4.2% |
| 结构化抽取（字段级） | 22.7% | 620 | 低（错一个字段就是事故） | 38.6% |
| 长文档摘要 | 18.9% | 9800 | 中（漏重点可接受，编造不可接受） | 21.3% |
| 代码生成 / 修改 | 14.2% | 2400 | 中（有测试兜底） | 27.9% |
| 多步推理 / Agent 决策 | 8.1% | 1500 | 高（错一步可以整个任务重跑） | 44.8% |
这张表是整篇文章的地基，三个结论都是从这里推出来的。第一，请求量占比和成本占比严重倒挂：占了三成流量的意图分类只花了 4.2% 的钱，占 8% 的多步推理花了近一半。第二，最该分流的是那 31.4% 和 8.1%，最不该分的是 22.7% 的结构化抽取——后者是成本与风险的交叉点。第三，长文档摘要的输入长度是其他任务的 5 到 50 倍，它的单价敏感度最高，一分流就是最大的绝对节省。
二、分流的真实代价：不是”便宜模型更差”，是”错误率随任务难度非线性上升”
我们用同一套 1200 题的内部评测集，测了三个档位模型在五类任务上的可用率。这里的”可用”有明确定义：抽取任务要求字段完全正确，摘要任务要求五个必含要点命中四个以上且无事实编造，决策任务要求最终动作选择正确。
| 任务类型 | 旗舰 API | 开源 70B（Q4） | 开源 14B（Q4） | 小模型可分流比例 | 分流风险 |
|---|---|---|---|---|---|
| 意图分类 | 97.8% | 96.9% | 94.2% | 100% → 14B | 低 |
| 结构化抽取 | 95.1% | 88.7% | 76.3% | 0% | 高 |
| 长文档摘要 | 92.4% | 90.1% | 68.9% | 100% → 70B | 低-中 |
| 代码生成 | 94.6% | 86.3% | 61.2% | 60% → 70B | 中 |
| 多步推理 | 91.2% | 72.4% | 48.6% | 0% | 高 |
（评测口径：每格 300 次独立运行，取中位数；分数为完成人工验收的比例。）
两个必须讲清楚的规律。第一，小模型的损失不是均匀的，是断崖式的。意图分类从旗舰换到 14B 只掉 3.6 个百分点，这类任务本来就不需要强模型；但多步推理从 91.2% 掉到 48.6%，等于不能用。同样是省 90% 的单价，你把请求分给 14B 去跑意图分类是聪明的，分给 14B 跑决策是灾难。
第二，70B 这一层出现了一个甜点位。它在长文档摘要上只比旗舰低 2.3 个百分点，在代码生成上低 8.3 个百分点——而这两类任务合计占了 40.5% 的成本。结论是：两档分流，不要三档。尝试直接上 14B 跑复杂任务，省下的钱不够赔事故；上 70B 跑简单任务，又没吃到最大的那份便宜。实际跑下来，我们把任务切成”14B 可接 / 70B 可接 / 只给旗舰”三档，中间那一档贡献了将近六成的节省。
三、路由规则怎么定：不按任务类型，按”错误成本 + 重试概率”双轴切
按任务类型分流是最常见的做法，也是最早失效的做法——因为同一个任务里的请求难度差异极大。我们最后用的规则不看任务看特征，一个请求进来先算两个数：错了要赔多少，错了能不能用便宜方式重试。
| 分流档 | 判定逻辑 | 兜底机制 | 我们工作流中的占比 |
|---|---|---|---|
| 14B 直出 | 输出是枚举类 / 单标签 / 置信度 > 阈值 | 低置信度自动升级到 70B | 33.8% |
| 70B 直出 | 需要成段生成，但有结构校验（JSON schema、字段必含） | schema 校验失败自动升级旗舰 | 29.6% |
| 旗舰直出 | 需要跨多文档综合判断，或兜底成本高于差价本身 | 无，直接跑 | 8.1% |
| 先旗舰出参考、再小模型复用 | 批量同构任务（批量改写、批量打标） | 抽样比对，偏差超限整体回退 | 28.5% |
第四档是我们省得最多、也最被低估的一招。逻辑是用旗舰模型跑 5% 的请求当”参考答案”，然后拿这些样本微调或蒸馏一个小模型去跑剩余 95%。在一个批量改写任务上，旗舰月成本从 2 万降到 4000 元，质量差距 1.1 个百分点。它的前提是你的请求是同构的；任务一杂，参考样本就不代表分布，这一招立刻失效。
三个踩过的坑：一是只看单价不看重试。14B 跑结构化抽取单次便宜 90%，但它错了就会触发人工返工，一次返工的工时成本顶上几千次调用。分流账必须把”错误会触发什么”算进去。二是把降本 KPI 定成”分流比例”。这个指标一定会被刷上去，而质量会以没人注意的方式滑坡；我们后来改成了”单任务人工返工率 + 单任务成本”双指标。三是忽视冷启动。小模型显存常驻之后，第一批请求的首字延迟会飙到 5 秒以上，一线用户直接抱怨”系统变慢了”——这个问题和成本无关，但足以让整个改造在内部被否掉。
四、92 天跑下来的账：月成本降 77.9%，其中最大头不是换模型
| 改造项 | 月度节省 | 占总节省比 | 一次投入 |
|---|---|---|---|
| 意图分类切 14B（31.4% 流量） | 4100 元 | 6.4% | 0 |
| 长文档摘要切 70B（18.9% 流量） | 1.83 万元 | 28.6% | 两周评测 |
| 代码任务 60% 切 70B | 1.12 万元 | 17.5% | 测试套件改造 |
| 批量任务蒸馏化 | 1.91 万元 | 29.8% | 一个月调优 |
| KV cache / 显存调优（vLLM 侧） | 1.14 万元 | 17.7% | 一周参数调优 |
反直觉的地方在最后一行：纯工程调优省下的钱（17.7%）超过了最受欢迎的”换便宜模型”中的两项。这一项不涉及任何模型决策，只是把显存和批处理参数调对——而大多数团队在谈分流时根本没提到它。先把部署调优做对，再去谈模型选型，顺序反了整个账都会算错。
质量侧的最终数据：全部 10 条工作流的端到端可用率从 93.6% 变成 94.1%（略微上升，因为省下的算力投在了旗舰兜底上），单任务人工返工率从 4.2% 升到 4.4%，这个 0.2 个百分点是我们为 77.9% 降幅付出的代价，目前看可以接受。月度推理账单从 6.3 万元降到 1.4 万元。
总结
92 天的分流实验可以压成三句话：分流的收益由流量形状决定，不由”开源很强”决定——意图分类是最大受益方，结构化抽取和多步推理基本不该分流；小模型的可用率是断崖式下跌的，中间只存在一个 70B 甜点档，两档分流优于三档；最大的隐藏收益不在换模型，而在 vLLM 侧的显存与批处理调优。
更普适的认知是：推理降本已经是一个纯工程问题，不是一个选型问题了。2024 年大家问”该用哪个模型”，2026 年该问的是”我的流量按错误成本和重试概率切完，每档该用什么、兜底挂在哪”。能把这两个轴上的账算清楚的团队，账单结构和拍脑袋分流的团队差着四倍。省钱的本质不是用更弱的模型，是让每一次请求都落在它该在的档位上。
互动提问：你们现在有没有按任务分过模型？分流之后人工返工率是升了还是降了——你们把返工算进成本账了吗？
互动提问：如果只允许做一件事来降推理成本，你会先做模型分流、先做 vLLM 调优，还是先把显存换成更大的一张卡？
— IMAI 编辑部 | 2026-11-05