清单的定位
成本优化的评审，最容易开成“省了多少”的汇报会。
只看省了多少，会漏掉三个问题：省下来的钱是否以质量为代价、是否可以持续、是否在别处制造了更大的成本。
这份清单把评审拆成十三组问题，每组给通过判据与常见驳回理由。不必每次问完，按方案风险挑三到五组深问。
一、度量口径
- TTFT、TPOT 与端到端延迟的定义分别是什么？
- 每个指标的统计窗口与分母是什么？
- 失败、取消与降级请求是否计入分母？
- p95 与平均值是否同时出现在报表里？
- 不同客户端版本是否分开统计？
通过判据：一页口径表，五个问题都有明确答案。
常见驳回：“我们的监控里有。”有字段不等于有口径。
二、基线
- 优化前的基线是哪一天到哪一天？
- 基线期间是否有活动、故障或版本变更？
- 基线是按能力拆分的，还是全站一个数？
- 基线的成本是否包含重试与缓存未命中？
- 基线是否可以重跑？
通过判据：基线可复现，窗口干净，按能力拆分。
常见驳回：“大概就是上个月。”无法复现的基线，无法证明优化有效。
三、调度
- 队列是否有界？满了之后是拒绝还是无限等待？
- 优先级如何分配？是否存在优先级反转？
- 并发上限由什么推导？是否考虑停留时间？
- 背压是否向上游传播？
- 多租户下是否会出现饥饿？
通过判据：调度策略有文档，拒绝与降级的边界明确。
常见驳回：“先排队，总会处理完。”排队到超时，等于既花了钱又没服务。
四、上下文
- 输入 token 由哪几部分组成？各占多少？
- 历史保留多少轮？依据是什么？
- 检索片段的数量与长度上限是多少？
- 前缀是否稳定？提示结构是否利于缓存？
- 压缩后如何验证关键信息没有丢？
通过判据：上下文预算表存在，压缩有事实探针验收。
常见驳回：“上下文越长效果越好。”成本与延迟都不支持这个结论。
五、输出
- 每个能力的输出上限是多少？
- 截断后如何处理？是否重试？
- 停止条件是否明确？
- 长尾输出占比多少？如何治理？
- 流式取消后上游是否停止计费？
通过判据：长度目标按能力设定，截断有分类处理。
常见驳回：“让模型自己停。”模型不会替你做成本控制。
六、缓存
- 缓存的键包含哪些字段？
- 命中率的分母是什么？是否包含过期结果？
- 缓存的净收益如何计算？
- 缓存失效后如何避免雪崩？
- 误命中的代价是否评估过？
通过判据：净收益为正，失效与误命中都有处理。
常见驳回：“加了缓存，命中率 40%。”命中率不等于省钱。
七、替代
- 量化、蒸馏或小模型替代前，验收集是什么？
- 替代后的质量损失如何量化？
- 什么条件下回退？回退需要多久？
- 替代是否按能力分别评估？
- 级联的通过率阈值如何确定？
通过判据：替代方案有 ADR，写清收益、损失与回退条件。
常见驳回：“小模型便宜十倍。”便宜十倍不等于值得换。
八、离线
- 哪些任务被移出在线路径？依据是什么？
- 离线作业的分片键是什么？扩容时是否漂移？
- 重试预算与幂等键如何设计？
- 错过窗口时如何降级？
- 离线链路的固定开销是否计入盈亏平衡？
通过判据：在线/离线分类表存在，盈亏平衡点算过。
常见驳回：“离线就是低优先级。”离线链路有自己的成本结构。
九、容量
- 从日活到峰值 QPS 用了哪些参数？
- 峰值系数观察了多长时间？
- 余量比例是多少？依据是什么？
- 扩容延迟是否计入容量？
- 供应商配额是否与自建容量一起算？
通过判据：容量模型可代入，参数有来源。
常见驳回：“按平均值乘二。”峰值不是平均值的固定倍数。
十、归因
- 成本能按租户、能力、模型、提示版本拆分吗？
- 重试与缓存未命中是否单独计量？
- 共享池的成本如何分摊？
- 账单与内部计量差异多大？如何解释？
- 成本异常时，多久能定位到具体版本？
通过判据：归因报表可下钻到提示版本，差异有解释模板。
常见驳回：“月底看账单。”账单只能告诉你超了，不能告诉你为什么。
十一、实验
- 这次实验改了几个变量？
- 对照组与处理组的样本量是否足够？
- 实验窗口是否覆盖了流量周期？
- 结果是否给出置信区间？
- 结论能否外推到其他能力？
通过判据：单变量、有对照、有区间、有外推边界。
常见驳回：“改完感觉快了不少。”感觉不是实验。
十二、联合门禁
- 质量、成本、延迟三个指标是否一起验收？
- 质量回退的阈值是多少？谁来判？
- 灰度比例与观察期是多少？
- 自动回滚的触发条件是什么？
- 回滚后数据与缓存是否一致？
通过判据：联合门禁有阈值、有负责人、有回滚演练。
常见驳回：“先上线，有问题再回滚。”没有触发条件的回滚等于没有回滚。
十三、稳定性
- 供应商限流时如何分流？
- 降级链是否有预算上限？
- 降级后是否可能比正常更贵？
- 成本告警的阈值与接收人是谁？
- 上一次成本事故的防复发措施是否落地？
通过判据：限流、降级与告警都有明确路径，事故有复盘记录。
常见驳回：“多接几家供应商就行。”分流策略比供应商数量更重要。
四十五分钟评审流程
| 时间 | 动作 | 产出 |
|---|---|---|
| 0–5 分钟 | 方案方讲基线、目标与改动 | 一句话结论 |
| 5–15 分钟 | 按风险挑三组深问 | 三到五个待确认项 |
| 15–30 分钟 | 逐项给结论 | 通过 / 有条件通过 / 驳回 |
| 30–40 分钟 | 核对质量与回滚方案 | 门禁与回滚条件 |
| 40–45 分钟 | 指定负责人、复查日期与证据 | 行动项 |
评审的产出不是“同意”，而是“可验证的条件”。没有条件的通过，等于把风险留给上线之后。
结论模板
方案: chat.reply 上下文压缩 + 缓存键修复
结论: 有条件通过
基线: 2026-10-20 至 2026-10-27，按能力拆分，含重试
改动: 只改上下文裁剪与缓存键，模型不变
预期: 输入 token -35%，单次成本 -28%，抽检通过率不低于 92%
条件: 1) 事实探针覆盖退款单号、金额、时效（负责人：消息团队）
2) 灰度 10% 观察 48 小时（负责人：平台）
3) 质量低于 92% 自动回滚（负责人：平台）
复查: 2026-11-08，带抽检与成本报表
上线后复盘表
| 项目 | 预期 | 实际 | 差异原因 |
|---|---|---|---|
| 输入 token | -35% | ||
| 单次成本 | -28% | ||
| TTFT p95 | 不变 | ||
| 抽检通过率 | ≥92% | ||
| 缓存命中率 | +10pp | ||
| 重试率 | 不变 |
复盘表在灰度结束后一周填写。差异超过预期 20% 的项目，必须给出原因；给不出原因的，视为实验设计有缺陷。
评审中最常见的三个误区
误区一：只审收益，不审代价。 成本降了，质量、延迟或稳定性付出什么代价？不写代价的方案，通常把代价留给了上线后。
误区二：只审平均值。 平均值达标不代表 p95 达标，也不代表峰值不出事。评审要看分位数与峰值。
误区三：只审这一次。 优化是否可维护？下次模型升级或提示改版，结论是否还成立？没有退出条件的优化，会变成新的历史包袱。
两个快速判据
时间有限时，用两个判据先筛一遍：
判据一：这次改动能否用一句话说清“改了什么、预期影响哪个指标、影响多少”。 说不清，说明方案还停留在“试试看”，先回去补基线。
判据二：如果实际结果比预期差一半，团队是否知道下一步查什么。 不知道，说明归因维度不够，先补第 9 章的报表，再谈优化。
两个判据都过不了，方案不必进入详细评审。它们不保证方案正确，但能挡掉大部分准备不足的方案。
两个判据可以直接印在评审表最上面，作为进入详细评审的前置勾选项。
小结
成本优化的评审，本质上是问四个问题：省了多少、怎么证明、代价是什么、什么时候失效。
六十问不必一次问完。先问基线、归因与联合门禁这三组，大多数方案的问题会在这三组里暴露。
复盘的日期一到，拿当时的结论模板对照实际结果，清单才算真正闭环。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。