王思腾工作室· 王思腾 · 大模型工程 · 10 分钟阅读
大模型应用成本优化：把 Token 账单砍下来的系统方法
大模型 API 按量计费，Demo 阶段无感，一上量账单比预期来得快。一个日均万次调用的客服机器人，用旗舰模型每月能烧掉上万元，而其中一大半花得冤枉。这篇从计费模型讲起，给出模型分级路由（cascade）、Prompt 瘦身、多级缓存、输出控制、批处理、小模型微调等手段，并按投入产出比排出优化顺序，全程强调“省钱不能以效果滑坡为代价”。
大模型 API 是按量计费的，开发 Demo 时一天几毛钱没感觉，等产品上量，账单会涨得比想象快。一个日均万次调用的客服机器人，如果全量用旗舰模型，月账单轻松上万；而这里面相当一部分请求，用十分之一的成本就能做到同样效果。
这篇聊应用侧的成本优化。注意它和推理引擎优化（KV Cache、连续批处理、量化，见推理加速篇）是两个层面：那篇讲“怎么把一次推理本身跑便宜”，这篇讲“作为调用方，怎么少调、调小、调得值”。
一、先看清钱花在哪
优化前先埋点，否则全靠猜。每次调用记录：模型名、输入/输出 token 数、缓存命中、场景标签、是否成功。按场景（客服、摘要、分类、翻译……）聚合后，你几乎总会发现：80% 的费用来自 20% 的场景，甚至 20% 的请求。
flowchart LR
Req["所有 LLM 请求"] --> Obs["埋点统计<br/>模型 · token · 场景 · 命中"]
Obs --> Ana["按场景聚合成本"]
Ana --> Big["定位大头<br/>通常是少数高频/长上下文场景"]
Big --> Opt["针对性优化"]很多团队吭哧吭哧优化半天，却没先定位大头，结果省的是零头。埋点统计是所有优化的前提。
顺便理解计费结构，才知道往哪砍：
- 输出 token 比输入贵得多（通常 3~5 倍），因为输出要逐 token 自回归生成；
- 输入是可控的：Prompt、检索上下文、历史对话都算输入，塞多少你说了算；
- 多数厂商对命中上下文缓存的输入 token 给折扣，重复的 system prompt、长文档前缀值得缓存。
二、模型分级路由：别用大炮打蚊子
不是所有请求都配得上旗舰模型。建一套分级策略：
| 请求类型 | 推荐策略 | 相对成本 |
|---|---|---|
| 简单分类、意图识别、格式转换 | 小模型 / 微调小模型 | 1× |
| 常规问答、RAG 摘要、标准客服 | 中等模型 | 5~10× |
| 复杂推理、难例、长链规划 | 旗舰模型 | 30~50× |
更聪明的做法是 cascade（级联）：默认让便宜模型先答，只在它“没把握”时才升级到旗舰模型：
flowchart TB
Q["请求"] --> Small["小模型先答"]
Small --> Conf{"置信度 / 自评<br/>是否拿得准？"}
Conf -- "高（大多数）" --> Out1["直接返回 · 便宜"]
Conf -- "低 / 命中难例规则" --> Mid["中等模型"]
Mid --> Conf2{"仍不确定？"}
Conf2 -- "是" --> Big["旗舰模型兜底"] --> Out2["返回"]
Conf2 -- "否" --> Out2判断“拿不准”可以用：模型自评置信度、输出是否命中拒答/空结果、规则识别的难例关键词、结构化输出是否合法。实践中通常能把 70% 以上流量挡在便宜模型，整体成本下降 5~10 倍，而用户几乎无感。
三、Prompt 与上下文瘦身
输入 token 按字收费，而很多 Prompt 堆满了“无效重量”：
- Few-shot 示例贪多：5 个示例砍到 2 个，效果差距常不到 1%，token 省一半多；
- 长指令每次重复：固定的角色和规则放 system 角色并走缓存，别在每轮里重发；
- RAG 塞太多：检索回 8 段、实际相关只有 2 段。提高检索精度比压缩 Prompt 更治本——既省钱又减少无关内容干扰；
- 对话历史不裁剪：多轮对话把几十轮历史全带上，越聊越贵。旧轮次做摘要压缩，只保留最近几轮原文。
一个朴素审计法：把线上真实 Prompt 打印出来读一遍，凡是你自己都会跳着读的内容，模型也不需要。
四、缓存：重复请求别重复付费
客服、问答类流量有大量重复或相似问题。建多级缓存：
- 精确匹配缓存：把问题归一化（去空格、标点、大小写）后做 key，命中直接返回。高频常见问题场景能省 20%~40%；
- 语义缓存：用 embedding 算相似度，命中近义问题就复用答案，命中率更高，但阈值要设严，避免把“怎么退款”和“怎么退货”错误复用；
- Embedding 缓存：同一段文档、同一个重复问题没必要反复向量化，embedding 结果也缓存；
- 上下文缓存：长且固定的前缀（系统提示、长文档）利用厂商的 prompt cache。
缓存要注意时效和一致性：政策、价格类内容更新后，相关缓存必须失效。
五、输出端控制
输出贵，就要管住输出：
- 设合理的
max_tokens，防止模型失控长篇大论、空转烧钱； - 结构化场景强制 JSON，不让模型输出大段解释性废话；
- RAG 回答限定篇幅，既省输出 token，用户读着也轻松；
- 用
stop序列及时截断。
六、批处理与离线任务
非实时任务（批量摘要、数据标注、文档处理、离线评测）用 Batch API：多数厂商给 50% 左右折扣，代价是延迟（数小时返回）。夜间跑批、不追求秒回的场景非常划算。
七、结构性手段：小模型微调
如果某类任务量大、需求稳定、格式固定（比如特定领域的意图分类、工单打标），可以用旗舰模型生成一批标注数据，微调一个小模型专门干这件事。小模型单次成本可能只有旗舰的几十分之一，量大之后省得惊人，延迟还低。这和模型路由是绝配：微调小模型兜住高频标准活，旗舰模型只处理长尾难例。
八、优化优先级（按投入产出比）
flowchart LR
A["① 埋点统计<br/>半天"] --> B["② 模型分级路由<br/>收益最大"]
B --> C["③ 多级缓存<br/>重复流量越省越多"]
C --> D["④ Prompt/上下文瘦身<br/>顺手就做"]
D --> E["⑤ 输出控制 · 批处理"] --> F["⑥ 小模型微调<br/>量大才上"]- 埋点统计：半天工作量，决定后面所有决策方向；
- 模型分级路由 / cascade：通常单点收益最大；
- 缓存：流量越重复收益越大；
- Prompt 与上下文瘦身：成本低、顺手；
- 输出控制、批处理：细节优化；
- 小模型微调：一次性投入大，任务高频稳定才值得。
九、底线：省钱不能让效果滑坡
成本优化有个不能碰的红线：每一项改动都必须配评测集回归。省了 80% 的钱但答非所问、拒答率飙升，等于把成本转嫁给了用户流失，得不偿失。
正确姿势是：先建评测集（一批典型请求 + 质量指标），每做一项优化就跑一遍，确认质量指标不掉（或在可接受范围内）再上线。成本和质量要放在同一张报表上看，这才是工程而不是碰运气。
小结
- 先埋点定位成本大头，80% 的钱往往来自 20% 的场景，别优化错地方；
- 模型分级路由 / cascade 收益最大，让 70%+ 流量走便宜模型，旗舰只兜难例；
- 输入可控：砍示例、缓存固定前缀、提高 RAG 检索精度、裁剪对话历史；
- 多级缓存（精确 + 语义 + embedding + 上下文）挡重复请求；
- 管住输出、非实时走 Batch 半价、高频稳定任务微调小模型；
- 所有优化都要用评测集回归，省钱的底线是效果不滑坡。
Token 省下来的都是利润，但比省钱更重要的是别为了省钱把产品做烂——带着质量标尺去优化，成本才能真正变成竞争力。
本文由 AI 辅助创作，所有内容仅供交流与参考。
