先立基线与口径
基线包含两部分：固定测试集上的 token 与花费，以及同一时期的账单口径。为什么必须先立：没有基线时，任何下降都可能是流量波动或统计周期不同造成的，无法判断优化是否真的生效。
对照要同分布
同一批请求、同一评测标准、同一时段，分别跑旧方案与新方案。怎么避免失真：请求要覆盖长短上下文与失败样例，比较时看单位任务成本与成功率两条曲线，只降成本不降质量才算通过。
异常流量压测
模拟突发、重试风暴、超长上下文与重复提交，观察成本与限流行为。为什么必要：多数成本事故发生在异常流量下，正常时段的平均值看不出来；压测要记录触发条件与恢复时间，不能只记峰值。
对账与回归门禁
把本地计量与供应商账单按月对账，差异超过约定阈值就暂停上线排查。做法是把固定测试集接进发布流水线，成本涨幅超阈值时阻断发布；边界是阈值由业务与财务共同确认，不是技术单方设定。
适用与不适用
适合谁
- 已完成一轮成本优化、准备复盘的团队
- 准备上线新提示词或新模型的团队
- 需要向管理层证明优化有效的项目
不适合谁
- 尚无稳定基线、场景仍在变化的项目组
- 只做一次性采购比价、不参与运营的场景
典型场景
一家连锁餐饮的客服系统在换模型前做了验收：用同一批历史会话跑新旧两版，比较单位任务成本与转人工率，再模拟晚高峰的突发流量。对账发现供应商账单比本地统计略高，查明是重试计入方式不同，双方先统一口径再上线。
可执行步骤
- 固定测试集与统计口径，记录优化前的花费、token 与成功率
- 用同一批请求跑新旧两版，比较单位成本、延迟与质量指标，两组要同分布
- 模拟突发流量、重试风暴与超长上下文，记录成本变化曲线与触发条件
- 按月对账本地计量与供应商账单，差异超阈值即暂停上线排查，查明差异来源
- 把成本阈值接进发布流水线，超标自动阻断并触发复盘，阈值需双方确认
常见坑
- 没有基线就直接上线，账单降了说不清原因，涨了也找不到出处，复盘全靠猜，结论无法复用。
- 两组请求分布不同，新方案看起来更省，实际是问题更简单，结论完全反了，白白浪费一轮。
- 只测正常流量，异常时重试风暴把成本推高数倍，限流与熔断也没生效，事后才发现。
- 对账差异长期挂着不查，双方各说各话，最后只能按账单付款，争议无从解决，只能吃哑巴亏。
自检与验收清单
- 是否有可复跑的基线数据与固定测试集
- 两组请求的分布是否一致并留档，样本量是否足够
- 异常流量场景是否做过压测并记录，限流是否生效
- 对账差异阈值是否与供应商书面约定，超阈值怎么办
- 成本门禁是否已接入发布流水线，谁来判定阻断
常见问题
成本降了但质量降了算通过吗
不算。验收要同时看单位任务成本与任务成功率，任一指标恶化都应判为未通过。若质量下降在可接受范围内，需要业务方书面确认并设定监控项，否则省下的钱会在返工与投诉里花回去。
对账差异多大算异常
没有通用阈值，取决于计量复杂度与流量规模。建议先连续对账三个月，看差异的稳定性，再设定一个略高于历史波动的阈值。差异突然扩大时先查重试与缓存计价，而不是急着改模型。
压测会不会很费钱
会有一笔测试开销，但通常远低于线上事故的代价。控制办法是缩小流量规模、用合成请求替代真实长文本，并在测试账户里跑。压测计划应提前报备预算，避免被当成异常支出。