最近看到不少团队用Locust对AI服务做压力测试，但多数还停留在测QPS和平均延迟层面。从个人经验看，AI API（尤其是LLM推理服务）的负载模型与传统Web服务有本质区别：请求大小不均、Token生成速率非恒定、GPU显存抖动导致尾延迟剧增。单纯用Locust的HttpUser模拟恒定请求，很容易忽略“并发数上升时，P99延迟从200ms飙升到5s”这种典型问题。
技术上，建议关注两点：一是自定义client捕获流式响应的首Token延迟（TTFT）和每Token间隔（ITL），这两项直接反映GPU调度效率；二是用locust的请求钩子记录显存和GPU利用率（如通过nvml），观察是否因显存溢出触发SWAP。个人实测发现，即使QPS达标，一旦并发超过模型显存容量的2倍，服务端会因为频繁的显存交换导致TTFT暴涨，这在传统压测里容易被忽略。
当前行业趋势是使用更细粒度的指标（如Token/s/GPU）来评估性价比，而非单纯看总吞吐。有经验的朋友不妨分享：你们在压测时，有没有遇到过因服务端batching策略不同（如dynamic batching vs. static batching）导致压测结果差异巨大的情况？另外，对于流式场景，Locust的异步模式（FastHttpUser）是否真的能模拟真实用户请求行为？期待讨论。