算
给推理服务做压测，盯着 QPS 一个数容易跑偏。我现在的固定组合是三个指标一起看。
TTFT（首 token 延迟）：主要是 prefill 阶段的耗时，跟输入长度强相关。TTFT 高先查两点：prefill 有没有被长输入堵住（chunked prefill 开了没），以及 KV cache 命中率。开了 prefix caching 后，重复 system prompt 的场景 TTFT 能降一个数量级。
TPOT（每 token 输出时间）：decode 阶段的指标，对 batch size 极敏感。batch 不满时 TPOT 虚高是正常的，不要拿低并发的 TPOT 去对标厂商宣传值。看 TPOT 一定要注明当时的并发和 batch 大小，否则没有可比性。
QPS（吞吐）：QPS = 并发 / 平均延迟，压测时用固定并发 ramp up，记录 P50/P99 而不是平均值。我习惯的流程：并发从 1 翻倍加到出现排队拐点，拐点前的 QPS 就是这套配置的真实服务能力。
三个常见坑：一是用短输入测出漂亮数字，上线长上下文直接崩；二是忽略了 P99，只看平均延迟；三是压测机和推理机抢网卡/带宽，测出来的是压测机的瓶颈。
你们线上 TPOT 的 P99 SLA 一般定多少？prefix caching 在生产环境的效果和预期一致吗？
TTFT（首 token 延迟）：主要是 prefill 阶段的耗时，跟输入长度强相关。TTFT 高先查两点：prefill 有没有被长输入堵住（chunked prefill 开了没），以及 KV cache 命中率。开了 prefix caching 后，重复 system prompt 的场景 TTFT 能降一个数量级。
TPOT（每 token 输出时间）：decode 阶段的指标，对 batch size 极敏感。batch 不满时 TPOT 虚高是正常的，不要拿低并发的 TPOT 去对标厂商宣传值。看 TPOT 一定要注明当时的并发和 batch 大小，否则没有可比性。
QPS（吞吐）：QPS = 并发 / 平均延迟，压测时用固定并发 ramp up，记录 P50/P99 而不是平均值。我习惯的流程：并发从 1 翻倍加到出现排队拐点，拐点前的 QPS 就是这套配置的真实服务能力。
三个常见坑：一是用短输入测出漂亮数字，上线长上下文直接崩；二是忽略了 P99，只看平均延迟；三是压测机和推理机抢网卡/带宽，测出来的是压测机的瓶颈。
你们线上 TPOT 的 P99 SLA 一般定多少？prefix caching 在生产环境的效果和预期一致吗？