Wiki Notes

Appearance

AI成本治理案例专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做知识库问答、客服分诊、Agent 工作流、实时语音、多模态处理和批量任务，需要把“能用”推进到“可持续付费”的产品、平台、运营与交付同学

很多团队做 AI 项目时，最开始把成本治理理解成一句话：

  • 选个便宜模型

真实流量一上来，大家很快会发现成本问题远不止模型单价：

  • 请求次数
  • 上下文长度
  • reasoning 预算
  • 工具调用
  • 失败重试
  • 检索冗余
  • 会话长度
  • 异步与同步执行方式
  • 人工返工

OpenAI 当前 Cost optimization、Prompt caching、Batch API、Background mode、Flex processing、Model optimization 等官方资料在 2026-07-08 复核时指向一个很明确的工程结论：

  • AI 成本治理首先是工作流治理，其次才是模型单价治理。

所以这篇专题不会只讲几条抽象原则，而是通过典型案例解释：

  1. 成本到底会在哪些地方失控
  2. 不同类型系统适合怎样止损
  3. 怎么把成本治理接进路由、缓存、执行模式、预算和评测体系

1. 为什么成本治理不能只看模型单价 ​

如果团队讨论成本时只问：

  • 这个模型每百万 token 多少钱

那通常说明治理还在很早期。

真实系统里，更值得问的是：

  • 每个成功任务要花多少钱
  • 哪类请求最贵
  • 贵的是模型、检索、重试，还是人工返工
  • 哪些成本和业务价值匹配，哪些只是浪费

OpenAI 当前 Cost optimization 明确强调：

  • 降成本通常要同时减少请求数和 token 数
  • 成本和时延经常联动
  • Batch 和 Flex 更适合低优先级、异步工作负载

翻译成工程话就是：

  • 最贵的常常不是“最贵模型”
  • 而是“被反复放大的低效路径”

2. 成本治理第一步不是优化，而是拆账 ​

如果团队只能看到：

  • 本月 AI 总花费

那基本上还谈不上治理。

更有效的拆法至少包括：

  • 每类 workflow 成本
  • 每类模型成本
  • 每类工具调用成本
  • 每个租户 / 业务域成本
  • 高价值与低价值请求成本
  • 成功路径与失败路径成本

一句话理解：

  • 先知道钱烧在哪，再谈怎么省。

3. 成本治理最该先区分哪几类钱 ​

一个更可落地的拆法通常至少分四桶：

3.1 模型直接成本 ​

  • input tokens
  • output tokens
  • reasoning tokens
  • audio / image / video 处理成本

3.2 工作流放大成本 ​

  • 重试
  • fallback
  • 重复检索
  • 重复工具调用
  • 多次 handoff

3.3 运行方式成本 ​

  • 同步执行带来的等待与超时
  • 批任务逐条提交
  • 本可异步却强行实时

3.4 业务返工成本 ​

  • 人工复核
  • 人工改写
  • 错误转人工
  • 用户重复提交

真正有效的成本治理，几乎都要同时盯这四类。

4. 成本和价值必须一起看，不然很容易“省小钱亏大钱” ​

很多团队一看到贵，就只盯：

  • 单次请求多少钱

但真实决策里更重要的是：

  • 每个成功任务多少钱
  • 每个有效转化多少钱
  • 每次节省了多少人工
  • 每次错误又带来了多少返工

如果只看模型账单，你很容易做出一种“假节省”：

  • 模型费省了
  • 但错误率、返工率和人工兜底成本暴涨

更实用的视角通常是同时看：

  • cost per request
  • cost per successful task
  • cost per avoided manual handling
  • cost of failure / rework

5. 一个更可执行的成本治理流程 ​

比起“大家一起想办法省钱”，更推荐走一条固定流程：

text
observe
 -> segment cost by workflow
 -> find top offenders
 -> analyze tokens / retries / tools / cache hit
 -> optimize prompt / retrieval / routing / execution mode
 -> re-measure
 -> add budgets / alerts / guardrails

这条流程里最关键的一步，不是优化，而是：

  • 先把高成本路径分桶

因为只有这样你才能知道问题到底该改：

  • prompt
  • 检索
  • 路由
  • 工具
  • 执行模式
  • 审批策略

6. 案例一：知识库问答成本失控 ​

6.1 典型表现 ​

  • top-k 过大
  • 每次都带很长上下文
  • 用户连续追问导致历史越来越长
  • 同样问题反复查相似文档
  • 成本上升但正确率没明显改善

6.2 常见根因 ​

  • 检索策略偏“宁可全塞，也别漏”
  • rerank 缺失或效果差
  • 公共前缀和 system prompt 过长
  • 会话历史没有摘要
  • 缓存命中率低

6.3 这里最该先看的不是模型单价 ​

而是：

  • 每次带了多少无效上下文
  • 同一资料被重复喂了多少次
  • 是否有大量重复前缀

OpenAI 当前 Prompt caching 文档明确说明：

  • 重复的前缀内容会带来更低输入成本和更低延迟

6.4 更有效的止损方式 ​

  • 缩小 top-k
  • 先 rerank 再拼接上下文
  • 对长文档做摘要或 chunk 压缩
  • 对公共前缀提升缓存命中
  • 会话历史做分层摘要而不是无上限堆积

6.5 最常见误区 ​

  • 明明问题在检索和上下文装配，却只想着换便宜模型

7. 案例二：客服分诊系统所有请求都走重链路 ​

7.1 典型表现 ​

  • 每个请求都走高成本模型
  • 分类、摘要、路由、工单生成全串成一条重工作流
  • 低复杂度和高复杂度请求成本差不多

7.2 常见根因 ​

  • 没有先分类再路由
  • 低风险问题和高风险问题共用同一条链
  • 草稿生成和最终动作没拆开
  • 模板化机会没被利用

7.3 更合理的治理方向 ​

  • 分类走轻模型
  • 只有高复杂度请求才升级
  • 工单草稿和最终提交拆开
  • 重复类型请求做模板化输出

7.4 这里真正需要的是什么 ​

不是“更便宜的模型”，而是：

  • 成本路由

也就是：

  • 低价值 / 低风险请求走轻路径
  • 高价值 / 高风险请求走重路径

8. 案例三：Agent 工具循环导致成本飙升 ​

8.1 典型表现 ​

  • 工具失败后反复重试
  • 同一个问题多次检索
  • reasoning 步数失控
  • handoff 循环
  • 单次任务成本远高于预期

8.2 常见根因 ​

  • 没有 step limit
  • 没有 retry budget
  • 没有幂等缓存
  • 工具 schema 不清，模型一直修参数
  • fallback 逻辑混乱

8.3 这里最容易漏掉的一项成本 ​

  • 不是主路径本身
  • 而是失败路径重复烧钱

8.4 更有效的治理方式 ​

  • 加 step limit
  • 加 retry budget
  • 对重复工具结果做缓存
  • 给高成本路径设置 fallback
  • 对异常长链路做 trace 分桶与复盘

8.5 更应该进入治理闭环的动作 ​

  • 异常链路告警
  • trace grading
  • 失败路径成本基线

9. 案例四：实时语音系统成本高于预期 ​

9.1 典型表现 ​

  • 会话太长
  • 无效 turn 太多
  • 转写、推理、语音回复全链路都在持续烧成本
  • 同一背景信息在长会话里不断重复解释

9.2 常见根因 ​

  • turn detection 不稳
  • session 生命周期控制差
  • 没有及时摘要旧上下文
  • 本不需要实时的步骤仍然放在实时链路里

9.3 更适合的治理手段 ​

  • 控制 session 生命周期
  • 提高 turn detection 准确性
  • 对长会话做摘要和裁剪
  • 区分实时与离线任务
  • 把后处理改成异步或后台执行

9.4 这类系统最容易低估什么 ​

  • “无效对话轮次”本身就是成本源

所以这类场景经常不是先换更便宜模型，而是先减少：

  • 空转
  • 抢话后的重来
  • 无意义追问

10. 案例五：批量任务同步执行导致成本和时延双高 ​

OpenAI 当前 Batch API 文档明确指出：

  • 它适合不需要即时响应的异步请求

Background mode 文档则强调：

  • 长耗时任务更适合异步可靠执行

Flex processing 文档还明确说明：

  • 它适合较低优先级或非生产紧急路径

10.1 典型场景 ​

  • 批量摘要
  • 批量分类
  • 长文档抽取
  • 运营回放
  • 大规模离线评测

10.2 错误做法 ​

  • 用同步接口逐条提交
  • 每条任务都走在线主路径
  • 用户或运营后台同步等待

10.3 更好的设计 ​

  • 批处理改 Batch
  • 超长任务改 Background mode
  • 低优先级异步任务考虑 Flex
  • 前台只展示任务状态，不要求立刻出结果

10.4 为什么这能同时改善成本和体验 ​

因为用户不再同步等待，同时系统能用更适合后台吞吐的执行模式处理任务。

11. 案例六：缓存和复用没设计，重复工作太多 ​

11.1 典型表现 ​

  • 同一公共上下文每天重复发送
  • 相同知识块被多次拼进输入
  • 工具结果完全相同却每次重查
  • 长系统 prompt 被每次重新计算

11.2 更适合治理的方向 ​

  • prompt caching
  • 工具结果缓存
  • 中间摘要缓存
  • 公共前缀模板化

11.3 这里的核心价值是什么 ​

它经常不是“让单次更聪明”，而是：

  • 在不改变能力的情况下，直接砍掉重复成本

11.4 更应该监控哪些字段 ​

  • cached token ratio
  • cache hit rate by workflow
  • repeated prefix ratio
  • duplicated tool query ratio

12. 案例七：为了省钱强压模型，结果人工返工更贵 ​

12.1 典型表现 ​

  • 模型单次成本下降了
  • 但工单修正、人工审核、用户追问、重新提交都上升了

12.2 常见根因 ​

  • 只看 request cost
  • 没看 task success cost
  • 没把人工替代成本算进去

12.3 更应该怎样看 ​

同时衡量：

  • 每次请求成本
  • 每次成功任务成本
  • 人工接管率
  • 返工关闭时长

12.4 这类案例最值得提醒团队什么 ​

  • 成本优化不能脱离业务价值

13. 哪些成本指标最值得长期盯 ​

只看总账是远远不够的。

更实用的指标通常包括：

  • avg cost per request
  • avg cost per successful task
  • input / output / reasoning token ratio
  • cached token ratio
  • retry rate
  • fallback rate
  • cost by workflow
  • cost by tenant
  • cost by model route
  • human handoff rate

这些指标一起看，才更容易形成精细治理。

14. 成本治理最好和版本治理绑定 ​

如果成本看板里没有版本信息，你通常只能看到：

  • 今天变贵了

但看不到：

  • 是哪次 prompt、workflow、tool、route 变更开始变贵

所以建议至少绑定：

  • model version
  • prompt version
  • workflow version
  • route version
  • cache policy version

这样后续才能真正做：

  • 灰度比较
  • 版本回滚
  • 成本回归分析

15. 成本治理要进入发布门禁，而不是只在财务报表里出现 ​

一个成熟的 AI 平台，成本不应该只在月底结算时被看到。

更实用的做法是把成本约束前置到发布流程：

  • 新 workflow 是否显著增加平均 token
  • 新 route 是否显著提高高价模型占比
  • 新工具是否带来更多重试
  • 新 prompt 是否显著拉低缓存命中率

如果这些不进发布门禁，团队很容易在功能正确的前提下：

  • 悄悄把系统做得越来越贵

16. 一个更可执行的成本治理模板 ​

如果现在要给一个项目做成本治理方案，建议至少按下面模板来：

16.1 基本盘点 ​

  • 系统有哪些 workflow
  • 哪些是在线，哪些是离线
  • 哪些是高价值，哪些是低价值

16.2 成本分桶 ​

  • 模型成本
  • 工具成本
  • 重试成本
  • 人工返工成本

16.3 高成本路径识别 ​

  • top 10 最贵 workflow
  • top 10 最贵租户
  • top 10 最贵失败路径

16.4 优化动作 ​

  • 缩 token
  • 减请求
  • 提升缓存
  • 路由分层
  • 异步化
  • 批处理化

16.5 预算和门禁 ​

  • per request budget
  • per task budget
  • per workflow alert
  • version regression gate

17. 常见反模式 ​

  • 只换便宜模型，不改 workflow
  • 不做成本分层统计
  • 不区分实时与离线任务
  • Batch 能做的事仍然同步做
  • 缓存命中率下降却没人看
  • 只看单次成本，不看业务价值与返工成本
  • 没有 step / retry budget
  • 成本分析不带版本信息

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

以下入口在 2026-07-08 复查时可访问：

20. 落地检查清单 ​

  • 是否已经按 workflow、模型、工具、租户和失败路径做成本拆账
  • 是否能同时看到 request cost 和 successful task cost
  • 是否识别了最贵的 top workflow、top tenant 和 top failure path
  • 是否对重复前缀、重复检索、重复工具调用做了缓存或复用设计
  • 是否把可离线、可批处理、可后台执行的任务从在线主路径里拆出来
  • 是否给 Agent 路径设置了 step / retry / fallback budget
  • 是否把成本与版本信息绑定，支持灰度比较和回滚
  • 是否把成本异常纳入发布门禁和告警，而不是月底才看总账