指标速查的使用方式
指标定义不统一，后面的实验与容量规划都会失真。附录 A 把卷二用到的指标集中列出，每组给五样东西：定义、算式、分母、常见误读、对应章节。
建议团队在第一次优化之前，用最后一节的模板把口径写下来。写不下来的指标，不要放进报表。
一、延迟指标
TTFT（Time To First Token，首字延迟）
定义：从请求进入到第一个输出 token 可用的时间。
算式：TTFT = 排队 + 预处理 + 首 token 生成 + 网络。
分母：全部请求，包括失败请求；失败请求的 TTFT 记为未达标，不剔除。
常见误读：
- 只统计成功请求，峰值时报表反而变好。
- 把网关处理时间排除在外，用户感知不到这个“优化”。
- 用平均值代替 p95，长尾被抹平。
对应章节：1.1、1.3、12.3。
TPOT / ITL（每 token 时间 / 增量延迟）
定义：首字之后，相邻 token 之间的平均或分位间隔。
算式：TPOT = (结束时间 - 首字时间) / (输出 token 数 - 1)。
分母：成功完成且输出 token 数大于 1 的请求。
常见误读：
- 输出被截断时仍按完整长度计算。
- 把流式分片的网络抖动算进模型生成时间。
- 忽略不同能力的输出长度差异，直接横向比较。
对应章节：1.1、4.3。
端到端延迟（E2E）
定义：从用户触发到完整结果可用的时间。
算式：E2E = TTFT + 生成时间 + 后处理 + 渲染。
分母：全部请求。取消请求单独统计，不混入成功样本。
常见误读：
- 只测模型调用，不测后处理与渲染。
- 把“流式首字出现”当成端到端完成。
- 不同客户端版本混在一起统计。
对应章节：1.1、4.2。
二、吞吐指标
吞吐（throughput）
定义：单位时间内完成的请求数或 token 数。
算式：吞吐 = 完成请求数 / 统计窗口。
分母：统计窗口，必须写明是一秒、一分钟还是一小时。
常见误读：
- 窗口太长，把突发峰值平均掉。
- 只算成功请求，失败与超时被排除。
- 把“已发送”当成“已完成”。
对应章节：1.2、8.2。
并发（concurrency）
定义：同一时刻正在处理的请求数。
算式（Little 定律）：并发 = 到达率 × 平均停留时间。
分母：同一时刻的在途请求，包含排队与生成。
常见误读：
- 把连接数当成并发数。
- 忽略排队时间，低估所需并发。
- 按平均值配置，峰值时排队雪崩。
对应章节：2.2、8.2。
goodput（有效吞吐）
定义：满足延迟目标的请求比例或速率。
算式：goodput = 满足 SLO 的请求数 / 统计窗口。
分母：全部请求，包括超时与失败。
常见误读：
- 用吞吐代替 goodput，忽略延迟超标。
- 目标定得太宽，goodput 恒为 100%。
- 只统计在线请求，漏掉异步任务。
对应章节：1.2、8.1。
三、质量与复用指标
缓存命中率
定义：命中缓存的请求占可缓存请求的比例。
算式：命中率 = 命中次数 / (命中次数 + 未命中次数)。
分母：可缓存请求，不含明确不缓存的请求。
常见误读：
- 键设计错误导致“假命中”，命中率虚高、质量下降。
- 把过期结果算作命中。
- 命中率上升但平均成本没降，因为未命中的请求更贵。
对应章节：5.1、5.3。
重试率
定义：发生至少一次重试的请求比例。
算式：重试率 = 含重试请求数 / 全部请求数。
分母：全部请求；重试次数单独统计。
常见误读：
- 只统计最终失败的请求，忽略“重试后成功”。
- 重试不消耗预算，实际成本翻倍。
- 把客户端重试与服务端重试混在一起。
对应章节：9.1、12.1。
降级率
定义：发生降级的请求比例。
算式：降级率 = 降级请求数 / 全部请求数。
分母：全部请求；按降级等级分别统计。
常见误读：
- 只记录布尔值，无法区分换模型、缓存与兜底。
- 降级后仍算成功，质量回退被掩盖。
- 降级开关长期不关，基线被污染。
对应章节：12.2、11.3。
四、成本指标
单次成本
定义：完成一次请求的平均成本。
算式：单次成本 = (输入 token × 输入单价 + 输出 token × 输出单价) / 请求数。
分母：全部请求，包含失败与重试。
常见误读：
- 只算成功请求，低估真实成本。
- 忽略重试与缓存未命中的重复计费。
- 用浮点金额累加，产生舍入误差。
对应章节：9.1、9.3。
单位 token 成本
定义：每百万 token 的综合成本，用于跨模型比较。
算式：单位成本 = 总成本 / 总 token 数 × 1,000,000。
分母：输入与输出分别计算，再给加权值。
常见误读：
- 输入输出混算，掩盖结构差异。
- 忽略缓存折扣与批处理折扣。
- 用不同币种直接比较。
对应章节：9.2、6.3。
成本归因维度
| 维度 | 回答的问题 | 常见缺口 |
|---|---|---|
| 租户 | 谁在花钱 | 共享池未拆分 |
| 能力 | 哪个功能最贵 | 能力标识缺失 |
| 模型 | 哪个档位最贵 | 路由后未记录 |
| 提示版本 | 哪次改版推高了成本 | 版本未绑定 |
| 请求类型 | 在线还是离线 | 任务未分类 |
对应章节：9.2、9.3。
五、容量指标
峰值系数
定义：峰值请求率与平均请求率的比值。
算式：峰值系数 = 峰值 QPS / 平均 QPS。
分母：至少观察两周，覆盖工作日与周末。
常见误读：
- 用单日数据外推全年。
- 忽略活动与大促的独立峰值。
- 把峰值系数当成固定值，不做季节性修正。
对应章节：8.2。
容量余量
定义：可用容量超过峰值需求的比例。
算式：余量 = (可用容量 - 峰值需求) / 峰值需求。
分母：峰值需求，按最坏组合估算。
常见误读：
- 余量只算机器，不算供应商配额。
- 忽略冷启动与扩容延迟。
- 余量过大，成本长期闲置。
对应章节：8.2、8.3。
六、口径对齐模板
把下面这张表填完，再开始优化：
能力: chat.reply
延迟定义: 首字出现 / 最后一段渲染完成
统计窗口: 1 分钟聚合，按小时报表
延迟目标: TTFT p95 <= 800ms；E2E p95 <= 4s
分母: 全部请求（含失败与取消）
成本口径: 整数微元，含重试与缓存未命中
归因维度: 租户 / 能力 / 模型 / 提示版本
质量指标: 人工抽检通过率，样本量 >= 200/周
缓存口径: 可缓存请求为分母，过期结果不计命中
降级口径: 按等级分别统计，降级仍计入成功但单独标记
模板的价值在于暴露分歧。两个人对“延迟”的定义不同，填表时就会吵起来；早吵比上线后吵便宜。
七、指标之间的三个陷阱
陷阱一：平均值陷阱。 平均值达标、p95 超标，是 AI 请求的常态。长尾来自长输入、长输出与重试放大，必须单独观察。
陷阱二：分母陷阱。 用成功请求做分母，失败会被从报表里抹掉。所有核心指标的分母都应该是全部请求。
陷阱三：窗口陷阱。 一分钟窗口能看见突发，一小时窗口能看见趋势。两个窗口都要有，不能只留一个。
小结
指标不是越多越好。卷二真正依赖的只有十几项：三个延迟、两个吞吐、三个质量、三个成本、两个容量。
把这十几项的定义、分母与窗口写下来，团队就有了共同语言。剩下的工作，是在这个共同语言上做对照实验。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。