模型服务压测不可信的8大变量与一套可落地的性能测试方法

最近排查了一个很蹊跷的压测问题：同一台机器，同一个训练好的模型权重，服务代码一行没动，只是把一个配置开关从关改成开，压测出来的 QPS 反而暴跌了 30%。一开始我以为是开关写反了，或者模型加载出问题，但日志、打印、推理结果全都正常。折腾了两天，最后发现根本不是“开关”本身的问题，而是这个开关触发了一连串我此前没有意识到的环境变量和资源竞争。这件事让我重新理解了压测这件事——你以为自己在控制变量，其实变量远比想象中多。

这篇文章把我这次排查的思路、踩过的坑、以及后来沉淀下来的一套能相对可信地做模型服务压测的方法整理出来。如果你也在做模型推理服务的性能测试，或者正在为“为什么两次压测结果对不上”而头疼，这篇文章应该能帮你少走不少弯路。

1. 一个开关为什么能牵动全局

1.1 开关从来不是一个简单分支

很多人对“配置开关”的理解是一个 if/else：关了走 A 路径，开了走 B 路径，其他不变。实际在推理服务里完全不是这样，一个开关往往意味着底层算子、显存布局、线程调度、甚至网络传输策略整体切换。

比如我那个例子里的开关是“是否启用动态形状（dynamic shape）”。关闭时，模型按固定 shape 做推理，所有 batch 都要 padding 到同一个长度，计算图可以预先编译好；打开时，每个请求用原始长度进模型，省掉了 padding 开销，理论上应该更快。但实际压测变慢了，原因在于动态形状导致显存碎片化加剧，GPU 上的内存分配从“一次到位”变成了“频繁申请释放”，而 PyTorch 的缓存分配器在碎片化严重时会触发多次 cudaMemcpy 做内存整理。这个开销完全不体现在单次请求延迟上，却会在高并发下被放大。

所以一个开关的真实影响范围是：计算路径、内存分配、缓存命中率、多线程争用、甚至 GPU 时钟频率调度。它从来不是孤立的。

1.2 开关带来的“隐藏副作用”才是压测不可信的根源

再举一个更隐蔽的例子：某个开关叫“启用请求级日志”。听起来只是多打一行日志，对推理性能的影响应该很小。但开启后，日志模块在高并发下会触发锁竞争、磁盘 write 阻塞、以及日志缓冲区的 flush，这些副作用与模型本身毫无关系，却会直接拉低 QPS 和拉高 TP99。

这就是题目里说的“只改一个开关，结果不可信”的核心原因：我们以为对比的是“模型在两种配置下的真实性能差异”，实际上对比的是“两个运行环境在资源竞争、系统调用、I/O 行为上的差异”。同一个开关一旦开启，整个进程的行为模式都变了，甚至物理机上的 CPU 调频策略都会随之改变。

提示：判断一个开关是否“纯净”，不要看它的代码注释，要看它实际触发了哪些系统调用和资源行为。用strace -c、perf stat、nvidia-smi dmon去看，比猜靠谱得多。

2. 比开关更容易忽略的八类可变因素

即便你已经严格控制了“模型、代码、开关”这三个变量，压测结果依然可能不可信。因为压测是一个系统级行为，机器上任何微小的波动都会被吞吐量和延迟放大。我整理了一下实际工作中踩过的因素，基本可以分成八类。

2.1 CPU 与 GPU 的动态调频

物理机的 CPU 频率不是恒定的。默认的powersave或ondemand调频策略会根据负载动态调整主频。第一次压测时，机器是冷的，频率慢慢爬升；第二次压测前，刚好有其他任务把 CPU 预热了，起始频率就不同。最典型的例子是：第一次跑 10000 并发，QPS 8000；休息五分钟再跑，QPS 直接变成 9500，所有参数都没变，只是因为 CPU 撞到了更高频率的睿频区间。

GPU 更敏感。显卡的功耗墙和温度墙会直接影响核心时钟。连续压测 20 分钟后，GPU 温度从 60 度升到 80 度，核心频率被限制，推理延迟开始缓慢爬升。如果你只对比“开关前 5 分钟”和“开关后 5 分钟”的数据，很容易得出一个完全错误的结论。

2.2 显存与内存的分配状态

模型服务启动后，显存占用并不是稳定的。推理过程中的激活值、KV cache、中间张量都会在显存里反复申请和释放。长时间运行后，显存碎片化程度不同，同一个 batch 的显存分配时间可能相差数倍。

内存同理。Linux 的 NUMA 架构下，线程和内存的亲和性会影响访问延迟。如果压测进程恰好被调度到另一个 NUMA 节点，跨节点内存访问的带宽和延迟都会明显变差。这个问题在“同一台机器”上也存在，因为进程的 CPU 亲和性每次启动都可能不同。

2.3 网络栈与连接数

模型服务通常通过 HTTP/gRPC 对外提供接口。压测时，客户端和服务端之间的连接复用、TIME_WAIT 状态、TCP 缓冲区设置都会影响结果。最典型的是 JMeter 默认使用短连接还是长连接，这个选项一变，结果天差地别。还有一个常见坑是压测机器本身的端口耗尽，客户端到了 65535 端口上限后开始大量报错，服务端 QPS 呈现剧烈抖动。

2.4 其他进程的“噪声”

生产机器上几乎不可能完全隔离。日志采集器、监控代理、CI 任务、数据库备份都可能在某一个瞬间抢占 CPU 或磁盘 I/O。哪怕只占 5% 的 CPU，也会在模型推理的延迟上产生毫秒级波动。想要压测可信，至少要做到：压测前检查top、pidstat，确认没有明显的陌生人进程；压测过程中也要持续监控，排除偶发干扰。

2.5 请求内容的分布

同一个模型，不同输入长度、不同 token 数、不同特征分布，计算量差异可以很大。如果你压测时只准备了固定长度、固定内容的请求，那测出来的是“理想值”；如果请求长度不均匀，batch 内部的 padding 和实际计算量会不断变化，QPS 自然跳来跳去。模型服务的压测里，“输入分布”是一个比“开关”更大的变量。

2.6 服务端动态 batching 与排队策略

很多推理服务支持动态 batching，即把多个并发请求合并成一个 batch 一起算。这个策略对吞吐量的影响极大。所谓“只改一个开关”，如果改的是 max_batch_size、max_queue_delay 这类参数，那本质上是在改变系统的排队模型，结果是数学意义上不可比的。这类场景下，QPS 和延迟之间会呈现强烈的非线性关系，稍不注意就会闹出“并发翻倍，QPS 反而下降”的笑话。

2.7 语言运行时与 GC

如果推理服务用的是 Python，GIL 和内存分配器本身就会带来波动。如果服务用 Java 或 Go，GC 或 goroutine 调度会造成周期性的“停顿”。压测时间如果太短，比如只有 30 秒，恰好碰到一次 Full GC，结果偏差 50% 以上都很正常。一般建议至少压测 5 到 10 分钟，并采用多个时间段采样，而不是看瞬时峰值。

2.8 数据读取与预处理管线

很多模型服务不止是“模型推理”，前面还有 tokenizer、特征工程、鉴权、缓存查询。这些步骤的性能受 CPU 影响很大。如果开关只是改了某个预处理逻辑，比如开启了数据校验，那么压测结果的变化可能根本不来自模型，而来自数据管线。

注意：以上八类因素不是孤立的，它们常常组合出现。比如动态 batching 开启后，显存碎片化加剧，GPU 温度升高，频率下降，最终延迟爆炸。你很难把锅甩给某一个变量。

3. 压测工具本身，就是最大的不可信源

3.1 工具差异比你想的大

JMeter、k6、wrk、hey、locust 这些工具，看起来都是“并发请求”，生成负载的方式完全不同。JMeter 的线程组模型更适合模拟真实用户行为，但它有 JVM 的开销和线程调度延迟；wrk 基于 epoll 和多线程，可以打满千兆网卡，但它构造的请求过于简单，无法模拟复杂业务；k6 用 Go 实现，并发模型很轻量，但每个虚拟用户的内存占用和请求间隔控制也会影响压测结果。

把“JMeter 压出来的 QPS”和“wrk 压出来的 QPS”直接做比较，本身就是不科学的。把同一工具在不同机器、不同求解参数下的结果做比较，也需要非常小心。

3.2 压测客户端的瓶颈会被误判为服务端瓶颈

一个特别常见的场景：你在本地用笔记本跑 JMeter，对线上模型服务压测。笔记本的 CPU 只有 4 核，连接数达到几千后，客户端自己先撑不住了，产生的请求速率达不到设定值，反而把服务端延迟拉高。从服务端看，请求排队时间变长，误以为模型出现性能问题。实际上瓶颈在客户端。

我的建议是：压测客户端的资源至少要和服务端相当，最好更充足。如果是高并发压测，尽量用独立机器，或者至少让客户端的多线程数少于 CPU 核心数，避免线程切换成为噪音。压测过程中要盯客户端的 CPU、内存、网络连接数，确保它没有成为瓶颈。

3.3 压测参数的“隐性影响”

很多压测工具的参数看起来无关紧要，实际影响巨大：

• 超时时间：设得太短，请求被客户端标记为失败，不会计入成功 QPS；设得太长，失败的请求挂在连接上，拖慢后续请求。
• 连接池大小：连接池太小时，客户端在等待空闲连接，延迟虚高；太大时，服务端文件描述符吃紧。
• 采样周期：每个请求都记录完整响应时间，会占用客户端 CPU；不做记录，又没法分析延迟分布。最好用异步采样，而不是同步写日志。
• 并发模型：每个线程独占一个连接，和线程池共享连接的差异极大。

我用过一个很典型的错误：在 JMeter 里把“循环次数”设成固定值，没有设置“持续时间”。结果压测过程中，不同线程组的结束时间不一致，后半段实际并发数在慢慢减少，QPS 曲线呈下滑。整个压测数据根本不能用。

3.4 响应日志与断言对压测的干扰

工具里开启“响应断言”会显著影响客户端性能，因为每个响应都要做字符串匹配。开启“保存响应到文件”更是灾难，会把压测客户端变成磁盘写入瓶颈。这些功能在调试时可以开，正式压测时务必关掉。

4. 一套相对可信的模型压测实操流程

4.1 环境准备：让“同一台机器”真正可复现

首先，给压测环境做基线检查。用lscpu、free -h、nvidia-smi记录下来 CPU 型号、核数、内存、GPU 型号和驱动版本。然后固定 CPU 调频策略，例如使用cpupower frequency-set -g performance，让 CPU 尽量跑在稳定频率。

其次，隔离干扰进程。压测前用top查看负载，用pidstat 1观察是否有异常进程。如果有，要么等它结束，要么把它迁移到其他 CPU。最稳妥的做法是使用taskset将服务进程绑定到固定 CPU 核心，压测客户端绑定到另一些核心，隔离彼此。GPU 上同样要确认没有其他进程占用显存，用nvidia-smi -l 1实时观察。

还需要在压测前做一次“预热”。让模型服务先跑 2 到 3 分钟请求，把缓存、显存分配、动态编译的算子都热起来。否则第一次压测要承担初始化的开销，结果会偏低。

4.2 压测脚本设计：固定四个维度

一个可信的对比实验必须固定以下四个维度：

1. 请求内容分布：准备一组代表真实业务的请求集合，可能是固定比例的不同长度输入。不要只造一个固定字符串。
2. 并发模型：确定虚拟用户数、Ramp-Up 时间、持续时间。建议持续至少 5 分钟，并让 Ramp-Up 不超过 20 秒。
3. 采样口径：明确统计的是 P50、P95、P99 还是平均值，明确成功响应的判定条件（如 HTTP 状态码、响应时间阈值）。
4. 环境基线：CPU 频率、GPU 温度、显存占用、进程亲和性，每次压测前都要记录。

我在实际项目中会先跑一次“对照压测”，确认两次相同配置下的误差在 5% 以内，然后才开始改开关。如果对照组都跑不稳，后面所有对比都没有意义。

4.3 数据采集：不能只看 QPS

只看 QPS 和平均延迟是远远不够的。至少要同时收集以下数据：

• 服务端指标：QPS、P50/P95/P99、错误率、排队长度、活跃连接数、动态 batch 的组成大小。
• 资源指标：CPU 使用率、GPU 利用率、显存占用、GPU 温度、CPU 频率、网络收发字节数、磁盘 I/O。
• 运行时指标：Python GC 次数、JVM GC 耗时、线程数变化、对象分配速率。

推荐同时使用nvidia-smi dmon、pidstat、vmstat、perf等工具后台采集，压测结束后统一整理。

4.4 统计判断：用多次运行取代单次结论

单次压测的结果不能作为调整开关的依据。我现在的习惯是：每种配置至少跑 3 次，每次跑 5 分钟，取中位数或均值，并计算变异系数。如果两次配置之间的差异小于变异系数的两倍，那基本可以判定为“噪声差异”，不应当据此调整线上配置。

一个快速判断方法：把同配置下的多轮 QPS 画成箱线图，如果两个配置的箱子重叠度很高，就说不上谁更好。只有两个箱线图完全分开，才有统计意义上的差异。

下面是我常用的一张问题排查表，方便对照：

4.5 真实案例复盘：开关动的是“缓存”

再回到我最开始说的那个 QPS 暴跌案例。后来我用strace -c对比了开关开和关两种情况下的系统调用，发现开关开启后，每次请求都会执行一次openat和mmap——原来那个开关叫“动态加载词汇表”，每次推理都要重新读取词典文件到内存。这个操作在单机单请求时几乎无感，但在并发压测时，文件读取的锁和磁盘 I/O 成了共享瓶颈。

解决办法也很简单：把词汇表加载移到服务启动阶段，开关只控制是否执行“加载动作”，所有请求复用同一份内存中的词典，问题立刻消失。这个案例再次说明了，压测中的性能差异往往藏在系统层，而不是模型计算层。

5. 排查难度与常见的几个误判

5.1 误判一：把“开关开启后的抖动”当成“开关本身有问题”

开关开启后，如果系统出现周期性抖动，先别急着回滚。用top -H查看线程状态，用vmstat 1观察 CPU 的 us/sy 比例。如果系统态 CPU 明显升高，说明开关代码里有大量系统调用；如果用户态 CPU 升高，说明计算逻辑变重。抖动来源判断清楚，再决定是优化开关还是关掉开关。

5.2 误判二：把“测试顺序效应”当成“配置差异”

先测开关关闭，再测开关开启，然后再测一次开关关闭，三次结果往往不相等。这是因为机器的热状态发生了改变。正确做法是交替测试：A/B/A/B 或者随机顺序执行，而不是固定先 A 后 B。每轮之间要留出足够的冷却时间，让 GPU 温度回到同一水平。

5.3 误判三：只看总 QPS，不看延迟分布

有些配置明显牺牲了高延迟长尾，换取了整体吞吐的提升。QPS 一样，但 P99 从 50ms 变成 200ms，这绝对不是一个可接受的“等价”结果。必须把延迟分布一并对比。对模型服务来说，P99 往往比平均值更接近真实用户体验。

5.4 误判四：在容器里压测，忽略了宿主机噪声

如果你在 Docker 容器里跑推理服务，宿主机上的其他容器也会抢占 CPU、内存带宽和网络。即使容器设置了 CPU limit，也有 L3 缓存争用和 NUMA 干扰的问题。压测前确认宿主机负载，或使用--cpuset-mems等方式绑定 NUMA 节点，才能让结果更稳定。

6. 最后给你一个可落地的检查清单

根据我的实际经验，做一次“可信度达标”的模型压测，至少要走完下面这些步骤：

1. 记录环境信息：CPU、GPU、驱动版本、CUDA 版本、框架版本。
2. 固定 CPU 频率：切换到 performance 模式。
3. 检查机器负载：确保没有其他任务干扰。
4. 预热服务：至少 3 分钟。
5. 设计真实请求分布：覆盖不同输入长度和内容特征。
6. 选定压测工具并调优客户端：确保客户端不是瓶颈。
7. 跑 2 次基线压测：确认重复性误差小于 5%。
8. 跑目标配置压测：至少 3 轮，合理冷却。
9. 采集系统指标与延迟分布，不只记录一个 QPS 数字。
10. 用箱线图或置信区间对比，而不是直接比较单次均值。

我个人在这些年踩过无数坑之后，最大的体会是：压测的可信度不是靠“严格控制一个变量”实现的，而是靠“承认所有变量都存在，并把变量控制在可观测、可解释的范围内”。同一个模型、同一台机器、只改一个开关，听起来是一个理想实验，但现实世界里从来没有孤立变量的实验，你测的永远是一个系统。带着这个心态去分析压测数据，就不会被那些莫名其妙的数字带偏了。