团队 LLM 成本优化实战:三层模型路由,同样的活账单砍一半(2026)
大模型账单失控的根源是「全用旗舰」。三层路由方法论:批量杂活走最低档、日常主力走中档、攻坚才上旗舰,附每层的选型标准、两个最容易漏算的隐形成本,以及怎么查实时单价。
1. 为什么「全用旗舰」是最贵的错误
旗舰型号和最低价档之间的单价差,通常是一个数量级以上——但在「从一段 JSON 里把三个字段抽出来」这类任务上,两者的产出没有任何区别。你可以现在就去审计一下自己的调用日志,按任务类型分个类,绝大多数团队会发现:很大一部分调用其实是 L1 难度的杂活,却和真正的难题一样跑在旗舰上。把这部分降档是所有成本优化里 ROI 最高的一步,因为它不牺牲任何效果——不是让你少调用、不是让你降低质量,只是把杀鸡的牛刀换成鸡刀。这一步通常不需要改架构,只需要在几个调用点上换个模型名。
2. 三层怎么分:给一个可操作的判断标准
分层的难点不在于「分成三层」,而在于判断某个任务该归哪一层,靠感觉分最后都会漂移到全用旗舰。给一个能直接用的标准:① L1 ——「答案对错一眼可判、不需要推理过程」的任务,比如分类、打标签、抽取结构化字段、格式转换、意图识别、简单摘要;② L2 ——「需要理解上下文,但不需要烧脑」的任务,日常写码、重构单个文件、写内容、常规问答,这一层应该承担你绝大部分调用;③ L3 ——「L2 实际跑过并且失败了」的任务,跨文件的大改造、长链条 agent、真正的难题。注意 L3 的判据是事后的(跑过才知道),不是事前凭感觉认定的。
3. 关键纪律:默认 L2,升级要有理由
这条纪律是整套方法能不能落地的分水岭。人的默认倾向是「反正贵一点,用最好的保险」,于是分层规则写在文档里,代码里全是旗舰。把默认值设成 L2,然后规定升级到 L3 必须给出理由,而唯一算数的理由是「L2 跑过,结果不行」——「这个任务感觉比较重要」「这是给客户的,不能出错」都不算,因为按这个标准所有任务都重要。反过来也有个反向的坑要提醒:别为了省钱把 L2 的活压到 L1。用低档模型跑写码任务,返工、调试、来回重试的成本,远比省下的那点 token 费高。分层是让每个任务落到合适的档位,不是让所有任务都往下压。
4. 落地方式:不需要复杂网关
很多团队一听「路由」就想搭一套模型网关,其实第一步根本不需要。因为这些模型走的是同一个接口、同一个 key,切换模型只是改 `model` 一个字段,所以在业务代码里按任务类型选不同的模型配置就够了。建议的做法是:把三层的模型名做成配置项或环境变量(比如 `MODEL_L1` / `MODEL_L2` / `MODEL_L3`),业务代码里按任务类型引用对应的那个,而不是把模型名硬编码进逻辑。这样换模型、调整分层、临时降级都只是改配置,不用改代码重新发版。进阶做法是给 agent 框架配 fallback:L2 连续失败自动升 L3,成功之后回落到 L2,这样既有兜底又不会长期挂在高价档上。
5. 第一笔漏算的钱:推理模型的思考 token
这是账单里最常见的「怎么比我算的多」。部分模型在给出答案之前会先生成一段推理过程,这部分 token 通常计入输出计费,而你在返回结果里往往看不到它,于是按「我要的答案很短」去估成本,实际扣费高出一截。有两个直接的应对:① 批量任务优先选非推理型号——L1 那类任务根本不需要推理过程,用会思考的模型纯属为看不见的东西付钱;② 注意 max_tokens 的设置,如果上限给得太小,可能出现「思考 token 把额度耗光、答案还没开始输出」的情况,钱花了却拿到空结果,这是双重浪费。选型时把「这个型号会不会先思考」当成一个明确的筛选条件。
6. 第二笔漏算的钱:长上下文的阶梯价
这一条最容易在批量任务上突然咬人。不少型号的单价不是一口价,而是按输入长度分档的——输入 token 在阈值以内是一个价,超过阈值之后单价会跳到更高的一档,跳幅可能接近翻倍。危险之处在于它的触发方式:你的批量任务平时都在阈值以内跑得好好的,某天喂进去一批更长的文档,单价整体跳档,账单就毫无征兆地涨了一截。应对方法:① 接入前先确认你要用的型号有没有阶梯,阈值是多少(模型接口的返回里能看到分档信息);② 在代码里对单次输入长度做个上限保护,超长就先切分再处理;③ 固定不变的长前缀(系统提示词、模板)能压短就压短 —— 缓存要省钱的前提是前缀一个字节都不变,而且各家对命中部分怎么计价差别很大,压短是任何情况下都成立的那笔省钱。
7. 每月十五分钟的成本复盘
优化不是一次性的,模型和价格都在变,建议每月做一次十五分钟的复盘。前提是你的账单要能拆得开——合格的供应商应该提供逐笔流水,每笔带模型名和 token 数,可以导出。拿到数据之后按模型聚合,问四个问题:① L3 的调用里,有多少其实 L2 能干?(通常是最大的一块水分)② L1 的任务里,是不是混进了本该 L2 的活?(反向的坑,会体现为返工率高)③ 哪个项目或 key 的用量在异常增长?(接前一节,可能是踩了阶梯价)④ 上个月新上的模型,有没有更划算的替代? 每次复盘通常还能再找回一成左右。
8. 单价怎么查:别照抄任何文章里的数字
最后一条很重要,包括对这篇文章本身:模型单价会调整,任何文章里写死的数字都会过期,照抄去做预算迟早出错。可靠的做法是查实时标价——价格页会列出当前每个型号的单价,也可以直接拉模型接口,这个接口公开、不需要 Key: ```bash curl https://cocodot.co/api/ai/models ``` 返回里每个型号都带当前售价、对应的官网价、以及分档信息,做预算就用这份数据,不要用任何二手转述。另外提醒一句:折扣幅度是逐型号不同的,有的型号有明显折扣,也有型号就是官网同价(尤其部分国产型号本身定价已经很低),别默认「全线都有折扣」去估算,按你实际要用的那几个型号逐个查。
三层路由速查(选型标准,不是价目表)
| 层 | 任务类型 | 怎么判断属于这一层 | 选型要点 |
|---|---|---|---|
| L1 批量 | 分类/打标/抽字段/格式化 | 答案对错一眼可判,不需要推理过程 | 优先非推理模型,避免思考 token |
| L2 主力 | 写码/重构/内容/常规推理 | 需要理解上下文,但不烧脑 | 你的绝大部分调用应该落在这层 |
| L3 攻坚 | 跨文件改造/长链 agent/难题 | L2 实际跑过并且失败了 | 按次使用,别设成默认 |
| 避坑 | 长上下文批量任务 | 单次输入是否可能超过阶梯阈值 | 超阈值后单价跳档,先算再跑 |
| 查价 | 任何时候 | —— | 以价格页/模型接口实时价为准 |