事故先说：月底账单比上月多三倍。没人知道是哪个功能——十二个服务共用一个 key（第一篇的事故）；追了两天发现一个新上线的 agent 功能在 5% 的任务里跑到 40 步、每步带着 100K 的上下文，那 5% 的任务花了账单的 60%。这就是 AI 应用成本的结构：长尾任务占大头、成本随改动跳变、没有归因就没有优化。

《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》给了成本公式与价目；这一篇讲它在生产里的运营：归因、预算与降级、九种省钱手段与各自的量级、按任务看分布、单位经济学、FinOps 的节奏。

本篇要回答的核心问题是：

成本怎么归因到租户 / 功能 / 版本，预算与降级怎么设？¹ 九种省钱手段各省多少、有什么代价？² 每任务成本怎么看分布，单位经济学怎么算，FinOps 的节奏是什么？³

一、总览

1. 成本的结构

%%{init: {"flowchart": {"wrappingWidth": 260}}}%%
%% 图：从月底账单到每任务成本：打标签 → 账本 → 按任务看 → 长尾
flowchart TB
    B["月底账单：一个总数"] -- "没有归因就没有优化" --> T["每次调用打标签：<br/>租户 · 功能 · prompt 版本 · 模型快照 · 任务 id"]
    T --> L["按天的账本：标签 × 五项 usage × 美元<br/>（未缓存输入 / 缓存读 / 缓存写 / 输出含思考 / 工具费）"]
    L --> V["按<b>任务</b>看，不按调用看：<br/>p50 与 p95 的每任务成本"]
    V --> F["发现：5% 的任务跑到 40 步 × 100K 上下文，<br/>花了 60% 的钱（长尾占大头）"]
    F --> A["药：每任务预算与降级（第三章）、缓存与排列、<br/>小模型分流、批处理……九种手段各有量级（第四章）"]

\[\text{成本} = \sum_{\text{调用}} \big( \text{未缓存输入} \times p_{in} + \text{缓存读} \times 0.1\, p_{in} + \text{缓存写} \times 1.25\, p_{in} + (\text{输出} + \text{推理}) \times p_{out} \big) + \text{工具费} + \text{judge 与检索}\]

《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》的公式加上生产里的三项：工具费（服务端工具按次计——web search、code interpreter、file search）、judge（《评测、可观测与可追溯（02）：评分——规则、LLM-as-judge 与人》：在线抽样与门禁）、检索（embedding、向量库、rerank——《检索与知识接入（07）：检索评测与运营》的五项）。三个事实决定运营方式：

• 长尾占大头：agent 的 p95 任务是 p50 的 5–10 倍成本；5% 的任务花一半的钱。
• 随改动跳变：换 effort、改 prompt、加工具、换模型，成本变化以倍计——每次改动是一次成本发布（第六篇）。
• 输入侧为主：agent 的输入输出比约 100 : 1（《Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切》），缓存与瘦身作用在输入侧。

%% 图：长尾占大头——把一天的 agent 任务按成本从低到高排，前 95% 的任务每个花几美分到几十美分，最后 5% 的任务每个花几美元（40 步 × 100K 上下文），这 5% 花掉了一半的钱；优化要先看 p95 任务的画像，不是平均值
%%{init: {"xyChart": {"width": 760, "height": 340, "plotReservedSpacePercent": 60}, "themeVariables": {"xyChart": {"plotColorPalette": "#c0392b, #5b8fd6, #4d9a5c"}}}}%%
xychart-beta
    title "一天 1,000 个任务按成本排序：每 5% 一组的总花费（美元）"
    x-axis "任务分位" ["0–5%", "…", "45–50%", "…", "80–85%", "85–90%", "90–95%", "95–100%"]
    y-axis "该组总花费（美元）" 0 --> 130
    bar [1, 2, 4, 6, 10, 14, 22, 125]

最右一根柱子——5% 的任务——比左边所有柱子加起来还高。它们长什么样（多少步、多大上下文、在重复什么），第五章讲。

2. 本文的章节安排

第二章归因；第三章预算与降级；第四章九种手段与量级；第五章按任务看；第六章单位经济学；第七章 FinOps 节奏；第八章实践建议。

二、归因

1. 标签

每次调用（经网关——第一篇）带：租户、功能（哪个产品能力）、prompt 版本、模型与快照、会话 / 任务 id、环境（生产 / 灰度 / 评测）、路径（主路径 / fallback / 级联的第几级）。usage 五项 × 价目表 → 美元，按标签维度聚合。

2. 账本

一张按天的表：标签维度 × usage 五项 × 美元；加工具费、judge、检索的成本按同一维度记（检索的成本按会话分摊）。价目表在网关维护，带日期（价格会变——《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》的 2026-09 价目是某个时刻的）。

3. 三个视图

• 按功能：哪个能力烧钱——决定优化优先级。
• 按租户：多租户 SaaS 的成本分摊与定价依据；异常租户（一个租户占一半）要限流。
• 按版本：prompt / 模型版本变更前后的每任务成本——第六篇发布的成本门禁。

4. 评测与灰度的成本

评测（L5：评测集 × k × judge）与灰度 / 影子（双倍推理）的成本单列——它们是”质量的成本”，与生产成本分开看，否则优化会砍掉评测。

三、预算与降级

1. 预算

按租户 / 功能设日与月的美元上限，从账本实时算消耗；阈值：80% 告警、95% 通知负责人、100% 触发降级。预算按历史用量与增长设，季度调。评测的预算也要有——否则它是第一个被砍的。

2. 降级梯子

超预算不是硬停（用户体验），是按梯子降：

超预算的降级梯子

级	动作	代价
1	切到便宜模型 / 降 effort	质量降（评测集上量过）
2	关闭非核心的增强（多查询检索、judge 抽样、二次校验）	质量小降
3	限流（每租户 / 每用户的 RPM 降）	排队
4	agent 的步数与 token 预算收紧	更多部分结果
5	关闭非核心功能（kill switch，第六篇）	功能不可用，有提示
6	全部走非模型路径 / 排队稍后	最后一级

每一级的触发条件、恢复条件（消耗回落到 90% 以下）、用户提示写进 runbook（第六篇）。这是 《模型作为组件（06）：客户端工程——重试、超时、幂等、限流与流式解析》熔断的成本版。

%% 图：预算的三档与六级降级梯子——账本实时算消耗：80% 告警、95% 通知负责人、100% 开始按梯子降：先切便宜模型 / 降 effort（质量在评测集上量过），再关非核心增强，再限流，再收紧 agent 预算，再 kill switch 关非核心功能，最后全部走非模型路径；消耗回落到 90% 以下逐级恢复
flowchart TB
    L["账本：实时消耗 / 月预算"] --> T80["80%：告警"] --> T95["95%：通知负责人"] --> T100["100%：触发降级梯子"]
    T100 --> D1["① 切便宜模型 · 降 effort<br/>质量降（量过）"]
    D1 -->|"仍超"| D2["② 关非核心增强<br/>多查询检索 · judge 抽样 · 二次校验"]
    D2 -->|"仍超"| D3["③ 限流：每租户 / 用户 RPM 降<br/>排队"]
    D3 -->|"仍超"| D4["④ agent 步数与 token 预算收紧<br/>更多部分结果"]
    D4 -->|"仍超"| D5["⑤ kill switch：关非核心功能<br/>有提示"]
    D5 -->|"仍超"| D6["⑥ 全部走非模型路径 / 排队稍后"]
    D6 -.->|"消耗回落到 90% 以下：逐级恢复"| D1
    classDef n fill:#fff7e0,stroke:#c98a00,color:#222
    classDef warn fill:#fff3e0,stroke:#c98a00,color:#222
    classDef bad fill:#fdecea,stroke:#c0392b,color:#222
    class L,T80 n
    class T95,D1,D2,D3 warn
    class T100,D4,D5,D6 bad

3. 异常检测

不等到月底：每小时的消耗与同时段基线比，突增（3 倍以上）告警并自动归因到功能 / 租户 / 版本——”哪个东西刚变了”（第六篇的版本 diff）。

四、九种手段与量级

九种降成本手段与量级

手段	做法	典型量级	代价	出处
级联	便宜模型先试，按置信度 / 校验决定是否升级到贵模型	50–80%（多数请求走便宜路径）	两次调用的延迟；分流器要评测	《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》
路由	按任务类型固定选模型（分类用小模型、写作用大模型）	30–60%	路由规则维护	《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》
prompt caching	静态前缀、断点、只追加（缓存读 0.1×）	输入侧 50–90%	排列纪律；第一轮写入 1.25×	《Prompt 与上下文工程（05）：prompt caching 与上下文的排列》
Batch	非实时任务走 Batch 层级（半价，24 小时内）	50%	延迟从秒到小时	《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》
Flex / 峰谷	可等待的请求走低优先级层级	20–50%	延迟不定	《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》
prompt 瘦身	删无效技巧、冗余示例、重复规则	输入 10–40%	要评测遵循率不掉	《Prompt 与上下文工程（02）：prompt 设计——稳定的模式与不稳定的措辞》
输出瘦身	结构化输出、限长、不要”解释一下你的想法”	输出 20–60%	用户可能要解释（L7 呈现）	《Prompt 与上下文工程（03）：结构化输出——约束解码、schema 设计与失败修复》
上下文预算	卸载、清理、压缩、复述	agent 输入 30–70%	压缩有损；实现	《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》、《工具、Agent 与 harness（04）：长任务的上下文管理与子 agent》
effort 按步选	简单步 low、关键步 high	推理 token 30–70%	每步分类	《模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态》
步数与预算卫士	agent 的上限与部分结果	砍掉长尾	更多部分结果	《工具、Agent 与 harness（01）：最小 agent 循环的解剖——从 40 行到生产级》
PTC	多步数据处理变一轮	该类任务 50–90%	沙箱、编码能力	《工具、Agent 与 harness（02）：工具调用与 MCP——协议、tool search 与程序化工具调用》

量级是经验范围，取决于你的分布——每一项都要在评测集上量质量不掉、在账本上量省了多少，两个数字一起报。手段可叠加：级联 + 缓存 + 瘦身 + effort 选档常让每任务成本降到原来的 1/5 到 1/10。

1. 顺序

先归因（知道钱在哪）→ 先做不影响质量的（缓存排列、瘦身、Batch 迁移、卫士）→ 再做要评测的（级联、路由、effort、压缩）→ 最后考虑微调小模型（第七篇飞轮：几千条数据后把行为编译进小模型——《检索与知识接入（01）：进上下文还是进权重——知识类型决定接入方式》的顺序）。

%% 图：九种手段各能省多少（典型量级的中值，作用在各自那部分成本上）——缓存作用在输入侧能省 70%，级联 65%，PTC 对多步数据处理 70%，上下文预算 50%，effort 选档对推理 token 50%，Batch 50%，输出瘦身 40%，路由 45%，prompt 瘦身 25%；每项都要在评测集上量质量、在账本上量省了多少，两个数字一起报
%%{init: {"xyChart": {"width": 760, "height": 340, "plotReservedSpacePercent": 60}, "themeVariables": {"xyChart": {"plotColorPalette": "#c0392b, #5b8fd6, #4d9a5c"}}}}%%
xychart-beta
    title "九种手段的典型节省（%，区间中值，各作用于自己那部分成本）"
    x-axis ["缓存（输入）", "PTC（多步处理）", "级联", "上下文预算（agent 输入）", "effort 选档（推理）", "Batch", "路由", "输出瘦身", "prompt 瘦身"]
    y-axis "节省（%）" 0 --> 80
    bar [70, 70, 65, 50, 50, 50, 45, 40, 25]

%% 图：手段的顺序——先归因知道钱在哪；先做不影响质量的四件（缓存排列、prompt 瘦身、Batch 迁移、卫士）；再做要在评测集上量质量的四件（级联、路由、effort 选档、压缩）；最后几千条数据积累后才考虑微调小模型把行为编译进权重；叠加后每任务成本常降到 1/5–1/10
flowchart TB
    A["① 归因<br/>标签 · 账本 · 三视图<br/>知道钱在哪"] --> B["② 免费的：不影响质量<br/>缓存排列 · prompt 瘦身 · Batch 迁移 · 卫士"]
    B --> C["③ 要评测的：质量与成本一起报<br/>级联 · 路由 · effort 选档 · 上下文压缩"]
    C --> D["④ 最后：微调小模型<br/>几千条数据后把行为编译进权重（第七篇飞轮）"]
    C -.- N["叠加：级联 + 缓存 + 瘦身 + effort<br/>每任务成本 → 1/5 到 1/10"]
    classDef a fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef b fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef c fill:#fff7e0,stroke:#c98a00,color:#222
    classDef d fill:#fdecea,stroke:#c0392b,color:#222
    class A a
    class B b
    class C,N c
    class D d

五、按任务看

1. 分布

每任务成本的 p50 / p95 / p99 与最大值，按功能。agent 的 p95 常是 p50 的 5–10 倍；看长尾任务的画像（多少步、多大上下文、哪些工具、是否重复调用）——多数长尾是可修的（卫士没触发、卸载没做、模型在换词重试——《工具、Agent 与 harness（01）：最小 agent 循环的解剖——从 40 行到生产级》、《检索与知识接入（05）：从流水线到 agentic retrieval》）。

2. 成本门禁

每次发布（第六篇）比较新旧版本的每任务成本分布：p50 与 p95 都不超阈值（或有意为之并记录）。《评测、可观测与可追溯（04）：回归与门禁——CI、供应商静默升级、A/B 与在线评测》的门禁判据里”成本不退化”的具体形态。

3. 成本进面板

与质量、延迟、安全并列（总纲的四指标）：每任务成本 p50 / p95、每功能日消耗、预算消耗比、缓存命中率（《Prompt 与上下文工程（05）：prompt caching 与上下文的排列》）、级联的分流比例、降级触发次数。

六、单位经济学

1. 每任务价值

一个功能的每任务成本要与每任务价值比：节省的人工时间 × 时薪、带来的转化 / 留存的增量、用户愿付的价格。例：一个客服助手每任务 $0.08，替代人工平均 4 分钟（$2）→ 25 倍；一个代码 agent 每任务 $3，替代 40 分钟（$50）→ 17 倍；一个”AI 摘要”每次 $0.02，用户很少看 → 价值不明——第一个该扩、第三个该问要不要存在（L7 的场景选择）。

%% 图：三个功能的每任务成本与每任务价值（美元，对数量级）——客服助手 0.08 vs 替代 4 分钟人工 2.00（25 倍）；代码 agent 3.00 vs 替代 40 分钟 50.00（17 倍）；AI 摘要 0.02 vs 用户很少看、价值不明（约 0.03，1.5 倍）；价值 / 成本 < 3 的功能该重新设计或砍
%%{init: {"xyChart": {"width": 760, "height": 340, "plotReservedSpacePercent": 60}, "themeVariables": {"xyChart": {"plotColorPalette": "#c0392b, #5b8fd6, #4d9a5c"}}}}%%
xychart-beta
    title "每任务成本（红）vs 每任务价值（蓝），美元"
    x-axis ["客服助手", "代码 agent", "AI 摘要"]
    y-axis "美元" 0 --> 55
    bar [0.08, 3, 0.02]
    bar [2, 50, 0.03]

前两个蓝柱远高于红柱（25 倍、17 倍）；第三个两根几乎看不见且一样高——它的问题不是成本，是要不要存在。

2. 毛利与趋势

SaaS 里 AI 功能的成本是 COGS：毛利 = 收入 − 模型成本 − 检索 / 工具 / judge 成本；定价（按席位、按用量、按任务）要覆盖 p95 而不是 p50 的用户；模型每年降价（《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》的趋势）让同一功能的毛利随时间改善，但使用量增长与更贵的能力（agent、推理）会吃掉它——两条线都画。

3. 决策

按单位经济学做三类决策：该不该做（价值 / 成本 < 3 的功能重新设计或砍）、用什么模型（价值高的用贵模型、价值低的用便宜的或级联）、怎么定价（覆盖 p95 用户的成本；按用量的功能要有配额）。

七、FinOps 节奏

FinOps 的节奏

周期	做什么
每小时	消耗异常检测与自动归因
每天	账本更新 预算消耗比 长尾任务画像
每周	按功能 / 租户 / 版本的成本报表 缓存命中率与级联分流比 本周发布的成本影响
每月	预算对账 单位经济学更新（每任务成本 vs 价值） 手段的收益复盘
每季	模型与供应商重议（价格、弃用、新模型进评测——《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》） 预算重设 定价复核

八、实践建议

1. 归因先行：网关标签齐全、账本按天、三个视图；评测与灰度成本单列。
2. 预算与降级梯子：按租户 / 功能设日月预算，80 / 95 / 100% 三档动作，梯子写进 runbook。
3. 先做免费的：缓存排列、prompt 瘦身、Batch 迁移、卫士——量省了多少。
4. 再做要评测的：级联、路由、effort 选档、压缩——质量与成本两个数字一起报。
5. 长尾画像：每周看 p95 任务的步数与上下文，修可修的。
6. 算单位经济学：每功能的每任务成本 vs 价值，做三类决策。
7. 按节奏运营：小时 / 天 / 周 / 月 / 季各有动作。

九、本文小结

• 成本结构：五项 + 工具费 + judge + 检索；长尾占大头（p95 是 p50 的 5–10 倍）、随改动跳变、输入侧为主。
• 归因：租户 / 功能 / prompt 版本 / 模型 / 会话 / 环境 / 路径标签，usage × 带日期的价目表进账本，按功能 / 租户 / 版本三视图，评测与灰度成本单列。
• 预算：日月美元上限，80 / 95 / 100% 三档；降级梯子六级（降模型 → 关增强 → 限流 → 收紧 agent 预算 → kill switch → 非模型路径）；每小时异常检测自动归因。
• 九种手段与量级：级联 50–80%、路由 30–60%、缓存输入 50–90%、Batch 50%、Flex 20–50%、prompt 瘦身 10–40%、输出瘦身 20–60%、上下文预算 30–70%、effort 选档 30–70%、卫士砍长尾、PTC 50–90%；每项量质量与成本；先免费的再要评测的最后微调。
• 按任务看 p50 / p95 / p99，长尾画像多可修；成本门禁；成本进四指标面板。
• 单位经济学：每任务成本 vs 价值，毛利与趋势两条线，三类决策（做不做、用什么模型、怎么定价覆盖 p95 用户）。
• FinOps 节奏：小时异常、天账本、周报表、月对账与单位经济、季重议。

十、自测

1. 账单涨三倍，账本显示 agent 功能 5% 的任务花了 60% 的钱。按本文，接下来三步是什么？

   答案

   （1）长尾画像：这 5% 的任务多少步、上下文多大、哪些工具、有没有重复调用——多数是卫士没触发、没卸载、换词重试；（2）修可修的：步数与 token 卫士、卸载阈值、重复调用提醒（《工具、Agent 与 harness（01）：最小 agent 循环的解剖——从 40 行到生产级》、《工具、Agent 与 harness（04）：长任务的上下文管理与子 agent》），并在评测集上确认质量；（3）预算与降级梯子：给该功能设日预算，超过时收紧 agent 预算或限流；成本门禁防再犯。详见第三章、第五章。

2. 一个团队为省钱把评测集的 k 从 5 降到 1、砍掉在线 judge 抽样。评价。

   答案

   砍的是”质量的成本”——评测与监控是防事故的，一次质量事故的代价远超 judge 费用；k = 1 让门禁失去区分力（《评测、可观测与可追溯（01）：评测集——AI 应用的单元测试》）。评测与灰度成本应单列并有自己的预算，不与生产成本混在一起优化。先做不影响质量的手段（缓存排列、瘦身、Batch）。详见第二章、第四章。

3. 级联把 70% 的请求分到便宜模型，每任务成本降了 60%，但评测集分数掉了 4 分。怎么判断值不值、怎么修？

   答案

   看分层：掉分集中在哪类用例——是便宜模型处理不了的类被错误分流（分流器的判据太宽）。修分流器（置信度阈值、按类型强制走贵模型、加校验后升级），目标是便宜路径的质量与贵模型持平、只在真正需要时升级；再用单位经济学判断：4 分对应多少价值损失 vs 60% 成本节省。两个数字一起报是原则。详见第四章、第六章。

4. 一个”AI 会议摘要”功能每次 $0.05，月消耗 $8,000，用户打开率 3%。用单位经济学分析。

   答案

   每月 16 万次生成、只有约 4,800 次被看——97% 的成本花在没人看的输出上。选项：按需生成（用户点开再生成，成本降 97%）、Batch 层级（半价）、更小的模型、或重新设计场景（L7）；先问”用户为什么不看”再决定要不要存在。价值 / 成本明显低于 3 的功能要重新设计。详见第六章。

5. 按用量定价的 AI 功能，定价按 p50 用户的成本加 40% 毛利。会出什么问题？

   答案

   重度用户（p95）的成本是 p50 的 5–10 倍，按 p50 定价在他们身上亏钱，且重度用户往往是留下来的用户；定价要覆盖 p95 的成本，或按用量分档 / 设配额并对超额计费。同时用长尾画像修可修的成本、设预算与降级梯子。详见第五章、第六章。

---

• 上一篇
  生产化与运营（01）：模型网关——所有调用经过的一层

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。