22｜成本与性能决策：每个成功任务，而不是每个Token
目标：把模型、上下文、缓存、并行与Review的开销放进同一个决策模型。所有价格例子为假设，不提供当前厂商报价。
本章目录
沿着对象与状态理解本章
成功任务成本的分母比单次调用价格更接近用户实际收益。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
Trace要告诉你因果，不只是时间戳
为何优化一个最显眼的步骤，整体却没变快？
执行轨迹像工程里的时间账，但更重要的是依赖关系。串行阶段会相加，并行阶段往往取关键路径；只有知道下一步在等谁，才能知道哪里值得优化。还要把排队、推理、工具、验证和重试分开，不能全算成模型慢。
输入与适用条件：固定教学秒数，无真实产品耗时数据。第4帧只改变工具A时长，其他条件保持不变。
1 / 5 · 先看一条完整任务
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
构造的任务从0到16秒：排队2秒、第一次模型3秒、并行工具A3秒/B8秒、第二次模型2秒、核验1秒。
基准墙钟16秒；工具工作量11秒默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
把优化投入到确实支配成本或完成时间的环节。
怎样实现
按依赖关系画时间线，再用同负载实测对照。
可能的代价与误解
只看平均值会隐藏长尾；把并行跨度相加会错误夸大总耗时。
如何判断是否做对
按时间戳与依赖重算16秒，检查是否把等待和重试遗漏。
1. 正确的成本分母
一次便宜调用如果失败，需要更多搜索、重试和人工返工，总体可能更贵。应计算总花费/成功完成任务数，同时单独报告失败任务消耗。若只挑成功案例计算，会给不稳定系统过度乐观的评价。
成本至少包含输入、输出、缓存读写或服务定义的计费项、工具、基础设施和人工时间。推理型模型可有额外内部推理计算，最终显示文字长度不能代表全部成本。当前产品用量以实际账单与接口为准，不凭旧文章估算。[N85]
还要分清现金成本、墙钟时间、开发维护成本和风险损失。一个复杂缓存服务节省少量Token，却增加故障点和维护成本，未必值得。
2. 模型级联的简化期望值
假设小模型一次成本Cs，以概率ps成功；失败能被可靠检测，之后调用大模型成本Cl。简化期望成本是Cs+(1−ps)Cl，若大模型直接调用成本Cl，级联有利需要Cs<psCl。但这个模型刻意忽略了误判、额外交接和失败副作用，只能作为起点。
若验证器漏掉小模型错误，系统不会升级，质量下降；若验证器本身昂贵，应加入Cv；若小模型生成错误补丁破坏环境，后续恢复成本也应计入。实际公式应按检测正确/错误的分支展开，而不是只看一次调用价格。
因此先为低风险、易验收任务测试级联。对模糊设计、长链权限和复杂并发，便宜模型的失败可能更难发现。是否路由由实测决定，不要求默认增加一个“任务复杂度判断模型”。
3. 缓存应在哪一层
可以缓存检索结果、工具结果、模型前缀计算或最终答案，失效条件不同。检索缓存依赖查询、权限、索引版本；工具缓存依赖资源与时间；答案缓存还依赖上下文、模型和输出约束。缓存键漏掉租户或权限，会从性能问题变成数据泄漏。
语义缓存把相似请求视为可复用，但“帮我查看Alice订单”和“帮我查看Bob订单”语义接近，权限与对象不同。不要只凭向量相似度返回敏感答案。对精确业务状态，保守键和短有效期通常更易验证。
Prompt缓存依赖服务支持的可复用前缀。稳定系统说明和工具定义可能有帮助，但动态任务事实不能为追求命中而固定不更新。第06章区分了KV状态与服务计费缓存。
4. 减少轮次通常比微调字数更值得先检查
十次串行模型调用，每次都需要固定网络和推理等待，即使输入各减少10%，端到端改善也可能有限。消除一次无价值分析或重复Review，可能同时减少延迟、Token和状态复杂度。但删除必要验证会降低成功率，所以必须区分无价值步骤与关键步骤。
工具可以提供更直接的结果：一次返回定位和范围，而不是先列目录再逐个猜文件；一次聚合独立只读查询，而不是无意义串行。批量执行应保留每项状态，不能让一个失败掩盖其他结果。
并行适合无依赖任务；提前执行高风险动作不属于性能优化。首字输出更快可以改善体验，但若最终结果更慢或不可靠，也要报告完整时间。
5. 以瓶颈为单位优化
若耗时主要在工具，换更快模型效果有限；若主要在长输出，减少不必要叙述可能有效；若在反复重做，先修状态和证据；若在检索噪声，先修召回与选择。Trace提供定位，实验提供证据。
不要因为某项技术流行就提前加上。向量库、图记忆、子Agent、reranker和压缩模型都有固定成本。一个小代码库直接ripgrep与精确读取可能更快更准。规模和任务分布变化后再重新评估。
6. 简洁的收益—风险评估模板
写清：当前具体失败、最小改动、预期因果机制、成功指标、可能退化场景、验证方法、回滚条件。对明确Bug修复，几句话加反例即可；对架构调整，才需要完整实验。
例如新增语义检索：预期改善不知道符号名的定位，风险是旧版本与同名误召回，验证用自然语言描述任务与精确符号任务双组对照，保留精确检索优先路径。这样的评估比“全面提升智能检索能力”更能指导实施。
成功率差1个百分点时，关键故障比均价重要
输入与条件。方案A在1000任务中成功990，平均成本1；B成功980，平均成本0.8，其中多出的10次失败都涉及发布版本错误。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1总成本 | A1000，B800 | B省200。 |
| 2每成功任务 | A≈1.0101，B≈0.8163 | 这一平均值仍让B看起来便宜。 |
| 3风险分层 | 10次新增错误集中在发布任务 | 可能违反该层风险底线。 |
| 4路由方案 | 保留发布层A，普通任务评估B | 不必全局二选一。 |
| 5上线条件 | 按层验证成功率、损失和回滚 | 不能只用总体平均省钱接受高损失失败。 |
把过程连起来。成本指标重要但不是唯一目标；不同任务的失败损失可能相差几个数量级。
边界与反例。数字为假设，不作经济收益估值；需组织自己定义可接受风险。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
7. 验收题
方案A每次花1单位，成功率50%；方案B每次花1.5单位，成功率90%。若独立重试且失败没有额外影响，成功成本近似A为2，B为1.667。实际若重试相关或有返工，需重新计算。这个例子说明最低单次成本不等于最低成功成本。
最后，不要把省Token作为唯一目标。对于高价值工程问题，多读必要源码、多运行一个关键测试可能非常值得。优化的目标是让每份成本产生可验证的业务能力，而不是让系统看上去节省。