先这样答
只看平均吞吐会平均掉长尾请求，从而掩盖极差的用户体验。平均数会掩盖真实的延迟分布。假设有99个请求耗时100毫秒，加上1个耗时10秒的请求。计算程序得出的平均耗时只有不到200毫秒。整体指标在这个计算下看起来依然正常。真实情况是每百次请求中就有一次长达10秒的糟糕体验。平均吞吐指标根本看不出这种偶发的严重卡顿。
工程师必须按真实流量形态来设计推理服务压测。线上流量不是单一的。测试必须混合长短请求。并发量不能一上来就打满。测试人员需要采用并发梯度爬升的方式注入流量。压测过程要观察持续时间段的表现。系统在长时间高负载下的表现才是真实的。压测不能只看瞬时峰值。
采集指标时必须看分位延迟。测试人员要重点关注P50、P95和P99的具体数值。系统同时要记录失败率与请求队列深度。长上下文请求需要单独拿出来测——它才是消耗显存和拖慢延迟的真正杀手。测试人员把它和普通请求混在一起测，容易掩盖严重的性能问题。
面试官会怎么追问
-
「为什么压测时要观察持续时间段，而不是瞬时峰值？」 瞬时峰值只能反映系统在短时间内的极限。推理服务在持续运行中会面临显存压力和队列积压。观察持续时间段能暴露出瞬时测试无法触发的问题。持续观察可以准确记录失败率的变化趋势。
-
「发现P99延迟很高，通常是什么原因导致的？」 通常是长上下文请求拖慢了整体处理速度。长上下文是显存与延迟的杀手。它在长短请求混合的真实流量形态中，会严重阻塞后续请求的处理。阻塞会导致队列深度增加。
-
「如何具体模拟真实流量形态？」 测试数据要包含长短请求混合的场景。并发量需要采用梯度爬升的方式逐渐增加。测试人员不能直接用单一长度的请求去测试。测试人员也不能用固定的并发数去打满系统。
回答的坑
只提平均吞吐量，完全忽略P50、P95和P99等分位延迟指标。 忽略长上下文请求对显存的消耗，没有把它单独拿出来压测。
同系列的题