服务变慢时压测工具会不会继续按计划发请求这个细节足以改变结论。一个客户端等上一条回答结束才发下一条服务越慢它发得越少另一个工具按时钟发压队列会持续增长。两者都能测试系统但回答的问题不同。10 月 16 日 vLLM 的性能工程文章强调按支持范围检查正确性和性能。官方文章 负载生成方式也属于这个范围。把两次不同发压方式的数字并列为“新版本更稳”没有可比基础。时钟是否独立于响应开环按预定到达计划发请求适合观察系统在给定外部负载下的排队、拒绝与超时。闭环由固定数量客户端循环“发送、等待、再发送”适合观察固定活跃用户的体验。一个闭环用户不是一个固定 QPS响应时间变化后其请求速率也会变化。下面用单服务台、固定服务时间的教学模型比较等待。它不打开网络也没有用 sleep 假装真实推理。def serve(arrivals, service_time): if service_time 0 or arrivals ! sorted(arrivals): raise ValueError(invalid fixture) free_at, waits, finishes 0, [], [] for arrived in arrivals: start max(arrived, free_at) waits.append(start-arrived) free_at start service_time finishes.append(free_at) return waits, finishes open_arrivals [0, 1, 2] open_waits, _ serve(open_arrivals, 3) closed_arrivals [0, 3, 6] # 单客户端等待前一条完成 closed_waits, _ serve(closed_arrivals, 3) assert open_waits [0, 2, 4] assert closed_waits [0, 0, 0] print({open_wait: open_waits, closed_wait: closed_waits})闭环等待为零不代表服务台突然更快它只是把到达时间推迟了。实际压测还可能遇到客户端 CPU、连接池、Token化或网络瓶颈应当同时记录计划发送与实际发送时间确认压测端没有先饱和。回放不只保存一份提示词请求记录至少包括相对到达时间、输入 Token 长度、输出限制、采样参数、会话关联和结束状态。多轮对话若失去顺序缓存命中就变了把长输出统一截成短输出Decode 负载也变了。数据脱敏还必须避免改变影响性能的长度与结构分布。条件应如何报告冷热缓存分开运行并记录预热过程客户端积压计划与实际发送差值系统拒绝计入到达请求总数长短输入分桶展示不只给总平均持续开环过载时拒绝一部分工作可能比无界排队更合理。但报表应同时显示完成率和延迟目标不能通过丢弃大量请求给尾延迟“美容”。本文只运行离散事件的算术例子。真实引擎回放、HTTP流式响应、GPU与大促负载均未执行。选发压模型之前先说清楚想回答“固定外部负载能否承受”还是“固定活跃用户体验怎样”测试结果才不会被工具行为替换。
