22 服务指标

22.1 指标定义

四个指标构成推理服务的全部语言，商务和技术必须用同一套定义。

容易混淆的一点：吞吐是系统视角，TPOT 是单用户视角，两者经常反向。把批量开到极大，系统吞吐上升，但每个用户的出字变慢。运营方追求吞吐，客户追求 TPOT，SLA 就是在这两者之间划线。指标还必须绑定测量边界：TTFT 的起点可能是网关到达、分词开始或调度开始，同一个引擎的服务级指标和单请求指标可能用不同起点，两个 TTFT 不能直接比较。核吞吐、并发和请求率也不是同一个量：并发是某一时刻的在途请求数，批次大小是某次迭代实际共同执行的序列数，请求率是外部到达过程，连续批处理下三者不断变化。压测的到达模型也分两种：开放式到达按外部速率发请求，系统变慢也继续施压，容易暴露队列和过载；固定并发等旧请求结束才补新的，系统一变慢实际到达率也跟着降。两者都可用，回答的问题不同。

22.2 三角取舍

延迟、吞吐、成本三者不可同时最优，任何报价都隐含了在这个三角上的一个取舍位置。扩大批次通常提高填充率和原始吞吐，却让请求等待更久；有效吞吐（goodput）解决的正是这个歧义：只计算在延迟目标内完成的请求。不同报告若用不同的首字与出字门槛，goodput 之间仍不可直接比较。核

22.3 利用误读

GPU 利用率常被误解为芯片发挥了百分之多少性能。工具统计的通常是 GPU 有内核活动的时间比例：同样 90%，可能是张量核心饱和，也可能是大量时间在等显存或互联数据。专业工具能分别观察计算单元、张量管线、显存、PCIe 和 NVLink 的活动，核这些计数器不是越高越好：decode 阶段本来就是高显存活动、低张量活动，为了把计算单元推高而扩大批次，反而损害 P99。利用率的正确用途是诊断资源瓶颈，不是单独做商业结论；单位成本最终要结合有效吞吐、功耗、错误率和留出的恢复余量算，第 26 章接这条线。

22.4 排队曲线

排队曲线比最大值更有解释力。到达率低于处理能力时，队列大多为空，加一点流量对延迟影响有限；接近饱和后，微小波动就让等待迅速增长。最大吞吐往往出现在系统已进入高尾延迟的位置，不能直接当可售容量；生产容量应落在满足服务目标、能承受突发和单节点故障的区域。报告应画到达率、有效吞吐、P99 三者的联合曲线，标记拒绝开始、目标失守和爆显存的位置。只给一个最大 QPS，会隐藏它是在多高延迟、多少拒绝、多长预热后得到的。这条曲线也帮 BD 看懂留余量买的是什么：可预测性。尾延迟是容量边界的早期信号：平均延迟可能长期平稳，P99 已经因少数长提示词、缓存未命中或抢占上升，仪表盘至少按模型、租户、长度桶和错误类型切片看 P50、P95、P99。

22.5 测量误差

测量系统自己也会产生误差。客户端、服务端和 GPU 的时钟不一定同步，端到端应在同一客户端用单调时钟测量；流式协议可能被代理缓冲，服务端记录 token 已发送不等于客户端立即看到；只对成功请求算延迟，过载时大量快速失败被排除，图表反而更好看。预热必须写明：首次请求包含权重触页、内核编译和缓存建立，完全丢弃预热数据适合测稳态，却不能代表扩容与故障恢复。还有一个高频陷阱是平均 token 速度：总输出除以总墙钟时间是集群吞吐，先算每请求速度再平均是给每个请求相同权重，1 除以 TPOT 是单序列生成速率，三者分母和权重不同，数值不会相等，表头应直接写公式。分位数还需要样本量：P99 由最慢的约 1% 样本决定，只跑几十个请求时 P99 很不稳定，两个版本差异很小时应报告波动范围，不能把一次偶然领先写成确定提升。

22.6 压测方法

压测结论的可信度，取决于测试流量与真实流量的相似程度。常见错误是用固定长度的合成请求压测：输入 1024、输出 128，跑满并发看吞吐。这类数据在真实流量下几乎不可复现，因为真实流量的长度分布是长尾的，少数超长请求会吃掉大部分 KV 显存。一张合格的性能表，表头至少包含模型与权重版本、硬件、精度、引擎、并行、长度分布、到达模型、并发、流式设置、预热与持续时间；结果列同时给 P50、P95、P99 的首字与出字、端到端、请求与 token 吞吐、有效吞吐、拒绝与错误、峰值显存和功耗；同一系统至少测低负载基线、目标平均负载、压力突发和长时间稳定四类场景。性能不是一个点，是一条随负载变化的响应曲线。

先停在四个变量上：显存管并发，带宽管出字速度，缓存命中影响成本，调度决定三者能否同时落在服务目标内。第 23 章把它们接到服务承诺上，第五部分再放进账本。