Wiki Notes

Appearance

任务级成本归因专题 ​

版本：v1.5

最后更新：2026-07-09

适用对象：已经开始关注 AI 成本，但不满足于“看总账”，想知道到底是哪类任务、哪段链路、哪种策略在烧钱的产品、平台和运营同学

很多团队开始关注 AI 成本后，第一步常常是看总账单，但真正想优化时很快就会发现：

  • 知道总成本高，没有用
  • 不知道到底是哪类任务、哪段链路在烧钱

这也是为什么需要任务级成本归因。

它真正要解决的不是“算账更精细”，而是：

  • 让团队知道应该优化哪条链路、哪类请求和哪种策略。

根据 2026-07-09 可访问的 OpenAI Cost optimization / Prompt caching / Batch API / Flex processing / Costs API，一个很值得先建立的共识是：

AI 成本不是只有输入输出 token，而是模型、缓存、处理模式、工具、重试、人工接管和风险控制共同构成的任务级成本。

1. 什么是任务级成本归因 ​

更实用的理解通常是：

  • 把一次完整任务的成本拆到具体环节和具体责任对象上

这样团队看到的不再只是月度总成本，而是：

  • 哪种任务最贵
  • 哪个步骤最烧钱
  • 哪个策略在拉高成本
  • 高成本是否换来了对应价值

1.1 为什么总量视角不够 ​

只看总成本，常见问题包括：

  • 优化无从下手
  • 争议很大，没人知道该谁负责
  • 高价值高成本和低价值高成本混在一起

如果没有任务级视角，很多成本讨论最后只会停留在：

  • “是不是模型太贵了”

2. 任务级归因最值得拆哪几层 ​

更实用的拆法通常至少有三层：

2.1 任务类型层 ​

  • 哪类任务最花钱

例如：

  • 知识库问答
  • 客服分诊
  • 审批助手
  • 多模态抽取
  • 实时语音

2.2 链路层 ​

  • 哪一步最花钱

例如：

  • retrieval
  • rerank
  • model inference
  • tool execution
  • human review

2.3 策略层 ​

  • 哪种模型、Prompt、检索或审批策略导致成本变化

这样既能看业务，也能看技术原因。

3. 哪些成本最值得优先做任务级拆解 ​

更适合优先拆解的通常包括：

  • 模型调用成本
  • 检索与 rerank 成本
  • 工具调用成本
  • 人工审批与人工接管成本
  • 长任务重试与补偿成本

这些成本叠在一起，才构成真实任务成本。

3.1 这里最容易漏掉的一项 ​

很多团队只算 token，不算：

  • 工具
  • 重试
  • 审批
  • 人工返工

结果看起来“模型不贵”，但任务总体已经很贵。

4. 任务级成本到底应该算哪些字段 ​

OpenAI 当前 Cost optimization、Prompt caching、Batch API、Flex processing 与 Evaluate agent workflows 共同说明：

  • AI 成本已经不只是“输入 token + 输出 token”

更可执行的任务级成本口径通常至少包括：

  • model_input_tokens
  • model_output_tokens
  • cached_tokens
  • model_name / routing_policy
  • tool_call_count
  • retry_count
  • human_review_count
  • background_or_batch_flag
  • task_type
  • trace_id / workflow_id

如果这些字段缺失，很多账都很难对齐到真实任务。

4.1 计费口径最好先区分 4 类，不要把所有成本都当成 token ​

很多团队一说成本归因，默认脑子里只有：

  • 输入 token
  • 输出 token

但 OpenAI 当前 Costs API、Pricing 与 Usage 相关参考里已经能看到，真实账单至少会混着几种完全不同的计费单位：

  1. token-like 例如文本、推理、多模态输入输出 token。
  2. request-like 例如 web search、file search 这类按调用次数统计的能力。
  3. session-like 例如 code interpreter / hosted tools 这类更接近“会话”或“容器”级别的资源。
  4. storage-like 例如 vector store 相关的存储占用。

如果你不先把单位拆开，后面就很容易把：

  • 一个 token 很贵的任务
  • 一个工具会话很多的任务
  • 一个长期占存储的任务

都误合成一个“平均成本”。

4.2 账单归因和任务归因最好分成两张表，再做对账 ​

OpenAI 当前 Costs API 支持按 project_id、line_item、api_key_id 分组；多类 Usage 结果又支持按 model、user_id、vector_store_id、context_level 等维度分组。

这说明官方账单视角和你自己的任务视角，本来就不是同一张表。

更稳的做法通常是：

  1. provider billing view 以项目、API key、line item、模型或工具类别聚合。
  2. internal task view 以 task_id、trace_id、tenant_id、workflow_version、task_type 聚合。
  3. reconciliation layer 用请求时间窗、项目、API key、trace 映射关系把两边对起来。

这样你才能回答两类不同的问题：

  • 财务上，这个月到底花在哪些 line item
  • 业务上，哪类任务和哪条链路真正把钱烧掉了

5. 为什么 cached_tokens 要单独看 ​

OpenAI 当前 Prompt caching 文档明确指出：

  • Prompt Caching 可降低输入 token 成本与延迟
  • 缓存命中依赖前缀稳定、静态内容前置、动态内容后置

5.1 不单独看缓存会带来什么问题 ​

你会很难回答：

  • 这次成本下降，是模型更便宜了，还是缓存命中了
  • 这次成本上升，是用户问题更复杂了，还是固定前缀被改坏了

所以任务级成本视图里，缓存不是附加项，而是一级字段。

5.2 prompt_cache_key 和稳定前缀最好一起进版本治理 ​

OpenAI 当前 Prompt caching 文档除了要求把静态内容放前面、动态内容放后面，也明确建议对共享前缀稳定使用 prompt_cache_key，并提醒单个前缀与 key 组合的速率过高会削弱缓存效果。

这意味着缓存命中率不是“基础设施自动优化一下”就行，而是配置治理问题。

更稳的做法通常是把下面这些字段也纳入成本归因：

  • prompt_cache_key
  • prompt 前缀版本
  • system / developer 指令版本
  • 知识前缀拼装方式

否则你很难区分：

  • 是用户问题变复杂了
  • 还是某次 prompt 改版把可缓存前缀打散了

6. 为什么 Batch / Flex 也要进入归因 ​

OpenAI 当前官方文档说明：

  • Batch API 适合异步任务，并提供 50% 的成本折扣
  • Flex processing 适合低优先级或异步任务，成本更低但响应更慢

这意味着处理模式本身就会改变成本和体验。

6.1 任务归因最好能区分 ​

  • 实时任务成本
  • 后台长任务成本
  • 批处理任务成本
  • 低优先级 flex 成本

否则“平均成本”很容易掩盖系统设计差异。

6.2 Batch 和 Flex 最好作为单独成本泳道比较，不要并回实时均值 ​

OpenAI 当前 Batch API 明确强调异步批处理有 50% 折扣、独立的更高限额和最长 24 小时完成窗口；Flex processing 则强调更低成本，但会带来更慢响应和偶发资源不可用。

这意味着它们不是简单的“便宜版调用”，而是：

  • 用不同 SLA 换成本结构

更可执行的归因方式通常会把以下字段拆开看：

  • delivery_mode = realtime | batch | flex | background
  • expected_sla
  • actual_completion_time
  • timeout_or_resource_unavailable_count

否则你会把：

  • 本来就允许慢的离线任务
  • 必须快的在线任务

放到同一条均线上比较，最后得出错误结论。

7. 成本归因为什么要和价值一起看 ​

不是所有高成本都需要压。

更关键的是判断：

  • 这个成本有没有换来对应价值

例如：

  • 高风险审批更贵，但可能值得
  • 高频低价值问答太贵，就应该优先优化
  • 高价值任务走更强模型，可能是合理的

7.1 更实用的视角 ​

同时看：

  • 每次请求成本
  • 每次成功任务成本
  • 人工替代成本
  • 错误和返工成本

否则容易出现一种“假节省”：

  • 模型费省了
  • 人工返工成本却暴涨

8. 一个更现实的任务级归因模型 ​

很多系统最终会落成一张任务视图：

text
任务
 -> 任务类型
 -> trace / workflow
 -> 模型调用成本
 -> 工具调用成本
 -> 重试与补偿成本
 -> 人工审批 / 接管成本
 -> 最终结果与业务价值

这样看到的就不再是：

  • “某模型本月花了多少钱”

而是：

  • 哪类任务最贵
  • 哪一步最贵
  • 这笔钱有没有换来更高成功率或更低风险

9. 成本归因如何进入治理闭环 ​

更稳妥的做法通常是：

text
Observe
 -> Slice by task type / workflow / tenant
 -> Find top-cost buckets
 -> Replay traces and inspect retries / tools / cache hit
 -> Optimize routing / prompt / retrieval / execution mode
 -> Re-measure
 -> Add budgets / alerts / policy guards

这意味着成本归因不应只是财务视图，而应该是：

  • 工程优化入口

9.1 先回放高成本桶，再决定要不要改模型 ​

OpenAI 当前 Evaluate agent workflows 把 traces、tool calls、guardrails、handoffs 视为评测证据，并建议先从 traces 开始定位 workflow 级问题。

对成本治理来说，这个思路同样成立。

更稳的顺序通常不是：

  • 先换更便宜的模型

而是：

  1. 找出 top-cost buckets
  2. 回放这些桶的 traces
  3. 看贵在 token、工具、重试、人工还是状态恢复
  4. 再决定该改模型、改 prompt、改检索、改工具、还是改执行模式

这样更不容易做出“账面降成本、整体更浪费”的假优化。

10. 为什么任务级成本要和事件模型绑定 ​

如果没有统一 trace 和事件记录，就很难知道：

  • 这次任务里到底调用了多少次模型
  • 哪一步重试了几次
  • 哪个工具最耗时又最耗钱
  • 哪个审批节点拖慢了交付

所以成本归因不仅是计费问题，也是 observability 设计问题。

10.1 conversation state 和续写链路要单独看，不然输入成本会被低估 ​

OpenAI 当前 Conversation state 文档明确说明：即使使用 previous_response_id 做续写，链路上前面的输入 token 仍会计入后续请求的输入 token。

这对任务级归因是一个很容易被忽略的点：

  • “这次只是接着聊一句”

并不等于：

  • “这次只花了一句的 token”

如果你的系统依赖长会话、状态恢复或多轮续写，归因视图里最好单独保留：

  • conversation_id
  • previous_response_id
  • 历史链长度
  • 每轮输入 token
  • 状态恢复次数

否则长会话产品很容易在表面上“单轮不贵”，实际上累计成本持续失真。

11. 为什么高成本任务不一定该优先砍 ​

有些任务：

  • 单次成本高
  • 但业务价值也高

例如：

  • 高风险审批
  • 高价值客户辅助
  • 复杂多模态审阅

这类任务更适合做的是：

  • 看单位成功成本
  • 看人工替代成本
  • 看风险降低收益

而不是机械压缩模型成本。

12. 为什么低价值高成本桶更值得优先优化 ​

真正应该优先治理的，通常是：

  • 高频低价值
  • 可替代
  • 可降级
  • 可异步

例如：

  • 内部低优先级总结
  • 批量清洗任务
  • 非实时内容标注

这些任务常常更适合：

  • smaller model
  • prompt caching
  • batch
  • flex

13. 哪些策略最常拉高任务成本 ​

常见原因包括：

  • 模型选型过重
  • top-k 过大
  • Prompt 前缀不稳定导致缓存差
  • 工具重试风暴
  • guardrail 误触发导致多次重跑
  • 人工审批或人工接管触发过多

如果没有任务级归因，这些问题都很容易被误判成：

  • “整体模型太贵”

14. 为什么任务级成本要和版本比较绑定 ​

一次成本变化，往往不止来自流量变化，也可能来自：

  • 模型切换
  • Prompt 改版
  • rerank 增加
  • 缓存命中下降
  • 处理模式变化

所以更成熟的成本视图通常要能回答：

  • 这次成本变化对应的是哪次版本变化

14.1 版本成本对比至少要绑定 5 类配置版本 ​

很多团队只会记：

  • 模型从 A 切到 B

但实际引起成本变化的常常还有：

  • prompt 模板
  • tool schema
  • workflow DAG
  • retrieval / rerank 配置
  • approval / guardrail 配置

更稳的版本对比最少建议保留：

  • model_snapshot
  • prompt_version
  • workflow_version
  • tool_schema_version
  • retrieval_or_knowledge_version

这样成本上涨时，你才能更快判断：

  • 是模型贵了
  • 还是流程长了
  • 还是工具更重了
  • 还是知识拼接和缓存命中变差了

15. 哪些指标适合一起看 ​

成本归因如果孤立看，容易误判。

更稳的组合通常是：

  • 单任务成本
  • 单任务成功率
  • 单任务延迟
  • 人工接管率
  • 高风险漏放率

这样才看得出：

  • 成本高，是换来质量，还是换来浪费

16. 一个可执行的成本分桶方法 ​

建议至少按下面几个维度切：

  • 任务类型
  • 租户 / 业务线
  • 模型路由
  • 是否多工具
  • 是否高风险审批
  • 是否异步 / batch / flex

这样更容易定位真正该优化的桶。

16.1 多租户和责任中心最好提前编码，不要后补 ​

OpenAI 当前 Usage / Costs 相关参考已经支持从项目、API key、用户等维度聚合；但很多企业内部分摊失败，不是因为平台没账，而是因为业务侧没有提前定义责任中心。

更适合企业落地的做法通常是在任务创建时就写入：

  • tenant_id
  • business_unit
  • product_surface
  • owner_team
  • chargeback_tag

这样后面才能做：

  • 租户分摊
  • 团队预算
  • 项目 ROI 对比
  • 高成本异常归属

如果这些字段靠事故后补写，最后通常只能看到平台总账，看不到责任边界。

17. 常见反模式 ​

  • 只看总账单
  • 只算模型 token，不算工具和人工
  • 不记录缓存命中与处理模式
  • 不做任务分桶
  • 降成本时只盯模型，不看链路设计
  • 成本变化和版本变化脱节

18. 一个最小但能落地的归因方案 ​

如果团队现在还没有正式任务级成本体系，建议至少先做到下面这些事：

  1. 给任务打 task_type 和 trace_id。
  2. 分别记录模型、工具、人工和重试成本。
  3. 单独记录 cached_tokens。
  4. 区分实时、batch、flex 三种处理模式。
  5. 把高成本桶和高价值桶分开看。

19. 预算不该只按月度总账看 ​

很多团队已经能做任务级归因，但最终决策还是只看：

  • 本月总共花了多少

这通常不够，因为真正要控的是：

  • 哪类任务预算超了
  • 哪类桶的成本虽然不高，但增长异常
  • 哪类高风险动作是否在“可接受成本”内

更可执行的预算体系通常至少分三层：

19.1 单任务预算 ​

例如：

  • 单次客服问答最多花多少
  • 单次审批辅助最多花多少
  • 单次长报告生成最多花多少

19.2 场景桶预算 ​

例如：

  • 高频低价值桶
  • 高风险审批桶
  • 高价值客户桶

19.3 版本观察预算 ​

例如：

  • 新版本灰度期间，某几个核心任务的单位成本最多允许上涨多少

如果没有这三层，很多“成本优化”最后还是会停留在总账讨论。

19.4 预算门禁最好同时有“软阈值”和“硬阈值” ​

很多团队虽然有预算，但只有一个动作：

  • 超了以后再开会

这通常太慢。

更稳的做法通常至少区分两层：

  1. soft budget 到阈值先告警、切流量、收紧采样、提高 review 频率。
  2. hard budget 超过后直接禁止某类高成本低价值任务继续放量，或强制切到 batch / flex / smaller model。

如果没有硬门禁，预算就很容易沦为月末复盘材料，而不是运行时控制点。

20. 后台、priority 和会话状态也会改变成本结构 ​

任务级成本最容易被低估的一点是：

  • 同样的模型，不同处理模式，真实成本结构也会不一样

例如：

  • background 任务会引入状态轮询和长任务管理成本
  • priority 可能提高关键链路稳定性，但也意味着更明确的高价值成本桶
  • conversation state 会影响历史状态的持久化和恢复策略

20.1 为什么这些字段值得单独进归因视图 ​

因为它们会直接影响：

  • 单任务时延
  • 任务重试方式
  • 状态恢复难度
  • 是否值得走更强配置

20.2 更稳妥的做法 ​

至少给任务记录：

  • 是否 background
  • 是否 priority
  • 是否依赖 conversation state
  • 是否发生人工恢复或人工接管

这样才更容易判断：

  • 高成本到底来自模型
  • 还是来自运行模式和恢复策略

21. 推荐搭配阅读 ​

22. 重点官方资源 ​

以下资源已按 2026-07-09 做过可访问性检查：

23. 落地检查清单 ​

  • 是否能把一次完整任务拆成模型、工具、重试、人工等多个成本来源
  • 是否单独记录了 cached_tokens 和处理模式
  • 是否区分了 token、调用、会话、存储这几类不同计费单位
  • 是否按任务类型、模型路由、风险等级做了成本分桶
  • 是否能把 provider 账单视图和内部任务视图做对账
  • 是否把成本和成功率、延迟、人工接管一起看
  • 是否能回答“到底是哪类任务、哪段链路在烧钱”