AI 成本优化

flowchart LR
  A["AI 成本优化"]
  A --> B["分类：工程与生产"]
  A --> C["关键词：AI"]
  A --> D["关键词：成本"]
  A --> E["关键词：缓存"]
  A --> F["关键词：模型路由"]

AI 成本优化不是“把单价压低一点”，而是把整条链路里不必要的 token、错误的模型选择、低价值的生成、无效的重试和不可控的长尾请求，一层层拿掉。很多团队不是模型效果做不出来，而是账单先把产品打回了现实。

延伸阅读：

OpenAI Pricing

Anthropic Claude Pricing / Prompt Caching / Batch Processing

Google Gemini API Pricing

vLLM Prefix Caching

这篇文章会讲什么

MVP 阶段你可能会觉得：

一次调用也就几分钱
用户量还不大，先把效果做出来
等真的有量了再优化也不迟

但 AI 成本和很多传统 SaaS 成本有一个很不一样的地方：

它往往直接跟使用量、上下文长度、输出长度、模型等级和失败重试绑定。

这意味着，成本不是“规模起来以后基础设施自然会摊薄”的那类问题。很多时候恰恰相反：

用得越多，账单越线性增长
上下文越长，单次请求越贵
输出越啰嗦，成本越高
工具循环和失败重试会把隐性成本放大
错误的模型路由，会把本来可以很便宜解决的问题，送进最贵的路径

这篇文章想建立的，不是“省钱技巧清单”，而是一套更接近真实工程的判断框架：

成本到底由什么构成
应该先优化哪里
什么优化只是局部省钱，什么优化会伤害质量
什么情况下该继续用 API，什么情况下才值得认真算自托管

如果前一篇《模型推理优化》关注的是“怎么跑得更快”，那么这一篇关注的就是：

怎么在不把质量打崩的前提下，把每个有效请求的成本降下来。

1. 先把问题说清：AI 成本不只是 token 单价

很多人第一次做成本估算，只会算：

输入 token × 输入单价 + 输出 token × 输出单价

这当然是起点，但在生产系统里，真实成本通常至少包括五层。

1.1 模型调用成本

这是最直观的一层，也通常是账单里最大头：

输入 token
输出 token
缓存输入 token
Batch 调用折扣
某些工具或附加能力的单独收费

以 2026 年 3 月公开价格为例，OpenAI 的 gpt-5.4 标准价是每百万输入 token 2.50 美元、缓存输入 0.25 美元、输出 15 美元；gpt-5.4-mini 是输入 0.75 美元、缓存输入 0.075 美元、输出 4.50 美元。OpenAI 还提供 Batch 价格，约为标准价的一半。(OpenAI开发者)

Anthropic 在 Claude Sonnet 4.6 页面上给出的起始价格是每百万输入 token 3 美元、输出 15 美元，并明确提到 prompt caching 最高可节省 90%，batch processing 可节省 50%。(Anthropic)

Google Gemini Developer API 的公开价格中，Gemini 2.5 Flash 标准价是每百万输入 token 0.30 美元、输出 2.50 美元；Batch 价是输入 0.15 美元、输出 1.25 美元。Gemini 2.5 Flash-Lite 则更低，标准价输入 0.10 美元、输出 0.40 美元，Batch 价输入 0.05 美元、输出 0.20 美元。(Google AI for Developers)

1.2 检索与上下文成本

很多团队只盯模型单价，却忽略了上下文本身就是成本变量：

RAG 召回太多，输入 token 直接上涨
对话历史无限累积，后续每轮都更贵
系统提示过长，所有请求都在重复付费
工具返回太冗长，下一轮又把这些内容重新送进模型

所以成本问题往往不只是“模型贵”，而是系统让模型读了太多低价值文本。

1.3 失败与重试成本

这是最容易被低估的一层。

一个请求失败，不一定只浪费一次调用费。真实系统里常见的放大器包括：

结构化输出失败后重试
工具调用失败后改写 prompt 再来一轮
多模型 fallback
Agent 走了很多步才发现路径不对
用户因为前端无响应而重复点击

这些成本在账单里未必单独列出来，但会真实吞掉毛利。

1.4 平台与运维成本

当你开始做缓存、路由、批处理、自托管，成本已经不止是模型账单，还包括：

GPU / CPU / 内存 / 存储
推理服务运行时
向量库和对象存储
队列与异步执行器
监控、告警、日志
工程和运维人力

所以“自托管更便宜”只有在把这些都算进去以后才有意义。

1.5 质量回退成本

很多“节省成本”的方案，最后会以另一种方式把钱吐回去：

小模型答不准，转人工率上升
过度缓存，错误答案被大面积复用
prompt 压缩过头，结构化稳定性下降
路由太激进，用户满意度下降导致业务损失

因此 AI 成本优化最难的地方，不是怎么便宜，而是：

怎么让“省下来的钱”不是靠透支质量换来的。

2. 成本拆解的基本公式

如果只保留最核心的表达，一个请求的直接成本大致可以拆成：

单次请求成本
= 输入 token 成本
+ 输出 token 成本
+ 工具 / 检索附加成本
+ 重试 / fallback 的额外成本
- 缓存命中节省
- batch 折扣节省

把它展开一点，更接近工程视角：

月成本
≈ Σ(各类请求量 × 平均单次有效成本)
+ 固定平台成本
+ 自托管硬件 / 运维成本（如有）

这里最重要的不是公式本身，而是两个判断：

2.1 成本不是平均值问题，而是分布问题

你真正该关心的通常不是“平均每次请求多少钱”，而是：

最贵的 10% 请求为什么这么贵
哪些租户 / 功能 / 工作流在吞账单
输出 token 为什么会出现长尾
哪些失败重试是可避免的
哪些请求明明可以走便宜模型，却总被路由到贵模型

很多系统的优化空间，不在平均请求，而在少数高成本路径。

2.2 先拆成本归因，再谈优化

所以你至少应该按这些维度做归因：

按模型
按功能
按租户 / 用户
按请求类型
按链路阶段：检索、生成、工具、重试、fallback
按 prompt 版本和路由策略

没有归因，就没有真正的成本优化，只有模糊焦虑。

3. 第一优先级通常不是“换更便宜模型”，而是少用 token

这是 AI 成本优化里最朴素、也最常被忽略的一点。

一次调用里，最容易直接下降的不是单价，而是 token 数。而 token 数里，最容易被浪费的是：

重复指令
冗余 few-shot
不必要的长上下文
低质量召回片段
不受控的长输出
被原样塞回上下文的工具结果

3.1 Prompt 优化首先是在删冗余，不是在堆技巧

先看定义：更短的 prompt，不只是更便宜，也往往更稳定。

常见可直接优化的地方：

去掉重复约束
把长段自然语言改成更紧凑的结构化指令
few-shot 不要“因为不放心就多放几个”
相同规则不要在 system、developer、user 三层反复出现
工具说明只给当前场景需要的部分
不要把本可由代码保证的规则留给 prompt 解释

很多 prompt 越写越长，并不是因为问题真的更复杂，而是因为团队在不断叠补丁。久而久之，prompt 变成一段没人敢删、但每次都在付费的历史包袱。

3.2 动态上下文比“大而全上下文”更省钱，也往往更准

RAG 场景里，最浪费钱的做法之一是：

用户一问问题
系统召回 10 段甚至 20 段
不重排、不裁剪，统统塞进去

这不仅贵，很多时候还更差。因为模型注意力也会被稀释。

更合理的做法通常是：

先粗召回
再重排
只注入当前问题真正需要的上下文
对长文档做摘要化或片段级提取
把“引用素材”和“背景材料”区分开，不要全部平铺

成本优化和质量优化在这里往往并不矛盾： 上下文越相关，通常越便宜，也越有效。

3.3 控制输出长度，常常是最直接的成本杠杆

输出 token 在很多主流模型上明显贵于输入 token。OpenAI 当前公开价格里，gpt-5.4 标准输出价是输入价的 6 倍，gpt-5.4-mini 也是同样比例；Anthropic Claude Sonnet 4.6 的起始价格同样是输出高于输入。(OpenAI开发者)

这意味着，控制输出长度不仅能改善延迟，也会直接降成本。

可直接使用的做法包括：

明确要求“只输出结论 / JSON / checklist”
分离“内部长推理”和“对用户短展示”
给不同任务设置不同 max output tokens
把解释性大段文本改成可展开的二级内容
不要默认让模型写“完整文章式回答”

很多系统的账单，不是被输入拖爆的，而是被“不必要的长输出”拖爆的。

4. 缓存：最容易带来立竿见影收益，但也最容易被用坏

先看定义：缓存的本质不是偷懒，而是承认很多请求并不值得重复花钱再算一遍。

4.1 精确缓存：最稳、最好用、最该先做

适合这些场景：

重复问题
模板化请求
同一文档反复摘要
固定输入的结构化抽取
参数完全一致的后端工作流

优势很明确：

实现简单
风险可控
命中即直接省钱
对质量几乎没有负面影响

很多团队一听缓存就想到“语义缓存”，其实第一步通常应该是先把精确缓存做好。

4.2 语义缓存：更激进，也更需要护栏

语义缓存的思路是：

问法不完全一致
但意思足够接近
可以复用已有回答或中间结果

它很有吸引力，尤其在 FAQ、客服、内部知识问答里。但它也更容易出问题：

表面相似，实际上权限不同
表面相似，实际上时间要求不同
表面相似，实际上用户上下文不同
老答案命中到新问题，导致过时信息被复用

所以语义缓存最好不要裸用。更稳妥的设计通常是：

只在低风险场景启用
加上租户 / 权限 / 时间窗口 / 产品版本等过滤条件
对命中结果做置信判断
必要时只缓存中间结果，不直接缓存最终答复

4.3 Prefix / Prompt Caching：它优化的是“重复前缀”

有些请求不是整个输入完全一致，但它们共享很长的固定前缀，比如：

很长的 system prompt
长文档分析里的固定背景材料
多轮对话里重复保留的前文
多个用户请求共享的大段公共上下文

这时前缀缓存就很有价值。

OpenAI 当前公开价格里单独列出了 cached input 价格，明显低于普通 input 价格。比如 gpt-5.4 标准 input 为 2.50 美元 / 百万 token，cached input 为 0.25 美元；gpt-5.4-mini 则是 0.75 对 0.075。(OpenAI开发者)

vLLM 官方文档则给出了 Automatic Prefix Caching 的设计说明，并且明确讨论了共享环境中的 cache isolation 和 cache_salt，用于限制不同请求之间的缓存复用边界。(vLLM)

这提醒我们两件事：

前缀缓存确实能省钱、省算力
缓存复用不是只有性能问题，还有隔离和安全边界问题

4.4 缓存最容易出问题的地方不是命中率，而是“命中了不该命中的内容”

尤其要小心：

不同租户之间的缓存穿透
带时间敏感性的答案被长期复用
带个性化上下文的结果被共享
缓存键没有包含模型版本、prompt 版本、权限上下文

所以缓存不是 Redis 一加就结束，而是一个需要明确边界的系统能力。

5. 模型路由：不是“能省点单价”，而是把高价模型留给真正需要它的请求

先看定义：成本优化里最有杠杆的动作之一，不是把所有请求都压到最便宜模型，而是把“本来不该用贵模型的请求”从贵路径里拿出来。

5.1 最常见的错误是“默认全走最强模型”

这是很多产品早期最容易发生的事：

为了效果保险
所有请求都上最强模型
客服 FAQ、分类、抽取、改写、审核，全都走同一路径

短期看起来简单，长期代价很重：

小任务也按大任务付费
吞吐压力更大
延迟更高
后面想拆路由会很痛

5.2 更合理的路由方式

常见可以落地的维度包括：

按任务类型路由

分类、抽取、重写、改写 → 小模型
高自由度长生成 → 大模型
代码、复杂推理、长文档综合 → 更强模型

按复杂度路由

FAQ / 已知流程 / 模板化问题 → 轻量模型
跨文档综合 / 歧义较高 / 高风险任务 → 更强模型

按业务价值路由

免费用户 → 成本更保守的策略
付费用户 / 高价值场景 → 更高质量路径
内部自动处理 → 尽量先走低成本路线，失败再升级

这本质上是在回答一个商业问题：

哪些请求值得花更多钱？

5.3 路由系统真正难的地方，不是“写 if/else”，而是可解释与可回滚

成熟的路由系统通常至少要记录：

为什么走这个模型
用了哪个策略版本
升级条件是什么
如果成本突然升高，是哪条规则导致的

没有这些记录，模型路由很快就会变成一堆看不懂的策略补丁。

6. Cascade：AI 成本优化里最典型的“先便宜试，再贵兜底”

先看定义：Cascade 不是简单降级，而是让大模型只处理“轻量模型拿不下的部分”。

典型流程是：

先让小模型尝试回答
如果命中高置信条件，则直接返回
如果低置信、格式失败、证据不足或问题复杂，再升级到大模型

6.1 Cascade 适合什么场景

特别适合这些场景：

FAQ / 客服 / 企业知识问答
结构化抽取
文本改写与清洗
有明确成功判定条件的任务
大部分请求其实都不难，但少数特别难的系统

6.2 Cascade 能不能成立，关键看“升级条件”是否靠谱

很多人会写成：

小模型先答
觉得“不确定”就升级

问题是，“不确定”如果主要靠模型自己说，往往不够稳。

更可操作的升级条件包括：

schema 校验失败
引用不存在或证据不足
置信评分低于阈值
命中高风险意图
检索结果冲突
输出长度异常
历史上该类问题在小模型上失败率高

这意味着，Cascade 真正成熟的做法不是“问模型行不行”，而是用系统规则定义什么时候必须升级。

6.3 Cascade 最大的误区：只算便宜模型的节省，不算升级链路的额外成本

一个看起来很省钱的 Cascade，可能因为这些问题反而不划算：

小模型命中率太低，几乎都升级
小模型先跑一遍反而增加总延迟
升级后还要重新组织上下文，重复付输入成本
两段链路都要维护，系统复杂度上升

所以 Cascade 不是天然省钱，而是当以下条件同时成立时才真正划算：

大部分请求确实可以被小模型解决
升级判定相对准确
升级链路不会把 token 和延迟浪费过多
业务能接受少量边缘质量波动

7. Batch：对离线任务极其有效，但不要拿它解决实时问题

先看定义：Batch 的价值在于把“延迟不敏感”的请求，用更低单价或更高资源效率处理掉。

OpenAI 当前价格页明确给出了 Batch 价格，gpt-5.4 和 gpt-5.4-mini 的 Batch 价格大约是标准价的一半。(OpenAI开发者) Anthropic 的 Claude Sonnet 4.6 页面也明确写到 batch processing 可节省 50%。(Anthropic) Google Gemini API 价格页同样列出了 Batch 价格，Gemini 2.5 Flash 和 Flash-Lite 的 Batch 单价也明显低于标准调用。(Google AI for Developers)

7.1 Batch 适合的典型场景

夜间报表
文档批量摘要
数据清洗与标注
离线分类
历史工单分析
批量抽取结构化字段

这些场景的共同点是：

请求量大
时效要求没那么高
结果可延迟交付
更在乎单位成本，而不是单次响应时间

7.2 Batch 的真正意义

不是“便宜一点”而已，而是把实时链路和离线链路拆开：

实时链路追求体验和首字延迟
离线链路追求单位成本和总体吞吐

这两类目标往往不一样，不应该强行用同一套成本结构去解决。

8. 自托管 vs API：不要问“哪个更便宜”，要问“在什么利用率下谁更便宜”

这是成本讨论里最容易被简化过头的话题。

一句更准确的话是：

API 成本大多是按使用量线性付费；自托管成本大多是固定成本 + 利用率问题。

8.1 API 的优势

无需自己维护推理栈
模型升级快
多模型可选
初期固定成本低
低流量时非常划算
更适合快速试错

8.2 自托管的优势

高利用率下边际成本可能更低
可做更深的推理优化
对上下文缓存、批处理、调度可控性更高
某些合规场景更容易满足
不容易被供应商单价波动直接影响

8.3 自托管真正难的地方

很多团队只算机器，不算这些：

GPU 空闲时间
流量波峰波谷
多模型并存
模型切换与版本管理
推理服务运行时
监控、告警、灰度、回滚
工程人力
故障和 on-call 成本

所以“自托管更便宜”只有在以下条件比较成立时才靠谱：

流量足够大且相对稳定
利用率能做上去
模型需求相对集中
团队能把推理平台运维好
质量上真的能用开源 / 自托管模型替代 API 模型

8.4 一个更有用的分界公式

不要背“多少请求量就是分界点”。更好的做法是自己算。

假设：

C_api = 每百万 token 的 API 综合成本
T_month = 每月实际处理 token 总量
C_fixed = 自托管每月固定成本（机器 + 存储 + 运维 + 人力分摊）
C_var = 自托管每百万 token 的可变成本（电费、附加基础设施等）
u = 实际利用率修正系数

那么可以粗略比较：

API 月成本 ≈ C_api × T_month / 1,000,000

自托管月成本 ≈ C_fixed / u + C_var × T_month / 1,000,000

这里最关键的是 u。因为很多自托管系统不是算力不够，而是：

白天忙、晚上闲
峰值高、均值低
模型碎片多
为了 SLA 留了大量冗余

利用率一旦上不去，自托管看起来“单 token 很便宜”的优势就会迅速缩水。

8.5 更现实的结论

对大多数团队来说：

早期和中期：API 往往更划算，也更灵活
高稳定流量、高利用率、模型需求相对固定时：自托管才开始出现明显成本优势
混合模式 往往最现实：高价值或复杂请求走 API，稳定大流量离线任务或特定内部场景走自托管

真正成熟的决策，不是站队，而是按场景拆。

9. 一个更靠谱的成本测算示例

为了避免“感觉上很便宜”，最好用真实公式算一遍。

假设某产品每月有 100 万次请求，平均每次：

输入 1500 token
输出 500 token

9.1 如果全部走 OpenAI `gpt-5.4`

按当前公开标准价：

输入成本：1500 / 1,000,000 × 2.50 = 0.00375 美元 / 次
输出成本：500 / 1,000,000 × 15.00 = 0.00750 美元 / 次
单次合计：0.01125 美元
月成本约：11,250 美元 (OpenAI开发者)

9.2 如果全部走 `gpt-5.4-mini`

输入成本：1500 / 1,000,000 × 0.75 = 0.001125 美元 / 次
输出成本：500 / 1,000,000 × 4.50 = 0.00225 美元 / 次
单次合计：0.003375 美元
月成本约：3,375 美元 (OpenAI开发者)

9.3 如果先做 40% 有效缓存命中

假设命中后大部分请求无需再进模型，那么仅从模型账单看：

gpt-5.4 月成本可从 11,250 美元降到约 6,750 美元
gpt-5.4-mini 月成本可从 3,375 美元降到约 2,025 美元

这里还没算缓存基础设施成本，但在大多数文本场景下，这个成本远小于模型账单本身。

9.4 如果做 Cascade：80% 请求由 mini 解决，20% 升级到大模型

粗略估算：

月成本 ≈ 80% × 3375 + 20% × 11250
      ≈ 4950 美元

这个数字比全走大模型便宜很多，但比全走 mini 贵。它是否值得，关键取决于：

那 20% 升级请求是否真的带来明显质量收益
小模型是否在 80% 请求里稳定可用
升级链路有没有额外重复 token 成本

9.5 这个例子真正想说明的不是“哪个模型更便宜”

而是：

模型选型会带来数量级差异
缓存对重复场景非常有杠杆
Cascade 的收益取决于升级比例和升级成本
输出 token 在高价模型上非常贵，值得重点管控

10. 预算监控与告警：没有可观测的成本，就没有真正的成本优化

很多团队会在账单出来后才讨论成本，这其实已经太晚了。

AI 成本要像延迟和错误率一样，被纳入日常观测。

10.1 至少要监控这些指标

总量指标

日 / 周 / 月 token 消耗
日 / 周 / 月成本
成本趋势变化

结构指标

按模型的成本分布
按租户 / 用户的成本分布
按功能 / 路由 / prompt 版本的成本分布
输入 / 输出 token 比例

效率指标

缓存命中率
Cascade 升级率
重试率
fallback 率
平均输出长度
长尾请求占比

风险指标

单租户异常突增
新版本上线后单位请求成本突增
某模型突然占比异常升高
某链路重试次数异常

10.2 告警不应该只看“总成本超预算”

更有价值的是做分层告警：

日成本达到预算 80%
某租户成本较 7 日均值暴涨
某功能输出 token 突然上升
某个 prompt 版本上线后单次成本飙升
某模型 fallback 激增
缓存命中率显著下降

因为很多事故在“总账单爆炸”之前，早就会先在局部指标里露头。

10.3 成本控制的理想状态不是“越省越好”，而是“可预测、可归因、可干预”

这意味着，当成本升高时，你应该能很快回答：

是谁花的
花在哪个功能
为什么变贵
是正常增长还是异常
可以通过什么策略立刻止损

这才是工程上的成本治理。

11. 成本优化的常见误区

11.1 误区一：只盯模型单价，不看输出长度

很多人会花很多时间比较不同模型每百万 token 的价格，却不管系统默认输出一大段废话。但在很多主流模型上，输出 token 单价明显更高，控制输出往往比微调输入更有杠杆。(OpenAI开发者)

11.2 误区二：为了省钱，把所有请求都压到小模型

便宜模型当然重要，但如果带来：

更多升级
更多转人工
更高失败率
更差用户体验

那么“账单省了”不代表系统真的更便宜。

11.3 误区三：缓存命中率越高越好

命中率本身不是目标。如果命中了不该复用的答案，成本是省了，但质量和风险成本会上升。

11.4 误区四：把自托管想成“调用越多越赚”

自托管真正决定胜负的是利用率，不是想象中的单卡理论成本。空闲 GPU 和高峰冗余，都会把“看起来很低的单 token 成本”打回现实。

11.5 误区五：只在账单暴涨后才开始治理

成本优化最难的从来不是“想出几个技巧”，而是把成本变成和延迟、稳定性一样的日常治理对象。

12. 一个更实用的优化顺序

如果你要从今天开始系统地做 AI 成本优化，比起一上来讨论“要不要自托管”，更建议按这个顺序来。

第一步：先建立归因

先知道：

哪些模型最花钱
哪些功能最花钱
哪些租户最花钱
输入和输出谁更失控
重试和 fallback 占了多少

第二步：先压 token

优先做：

prompt 去冗余
动态上下文
输出长度控制
历史对话裁剪
工具返回摘要化

第三步：再做缓存

先精确缓存，再谨慎尝试语义缓存和前缀缓存。

第四步：再做模型路由和 Cascade

让简单请求先走便宜路径，把高价模型留给真正需要的难题。

第五步：最后再认真算 API vs 自托管

只有当流量、利用率、团队能力和合规要求都到位时，这个问题才真正值得重投入。

小结

AI 成本优化的核心，不是“找一个最便宜的模型”，而是围绕整条链路做系统性减法：

少读一点：减少无意义输入 token
少说一点：控制输出长度
少算几次：做好缓存，减少重复推理
便宜地算：合理做模型路由和 Cascade
把贵算力留给真正值得的请求
把离线任务从实时链路里拆出来
用归因、预算和告警把成本变成可运营对象

如果要把这篇文章压缩成一句话，大概就是：

AI 成本优化不是单点降价，而是把“低价值 token”和“错误的高成本路径”系统性清除掉。

这件事越早做，后面系统就越容易长大；越晚做，账单就越像一场被动补课。