同一模型、同一机器、只改一个开关，为什么压测结果仍可能不可信？

先说一个我上周刚踩完的场景：一个AI推理服务，模型权重文件完全一致，部署机器也是同一台，我只把JVM参数里的一个NUMA开关从关改成了开，压测结果居然从稳定2万QPS变成了1.4万到2.3万之间剧烈抖动。第一反应是“开关改坏了”，回滚之后我再跑，结果这次连回滚版本的结果都和昨天不一样了。这时候我才意识到，长期以来我对压测的信任是被高估的。

这个“同一模型、同一机器、只改一个开关”的困惑，相信做后端性能优化、AI推理服务调优的朋友多多少少都遇到过。你以为自己做了严格的对照实验，控制了所有变量，结果复现不出来、结果乱跳，甚至方向反了。这篇文章我想从压测方法论、运行时机制、机器环境这几个维度，把“为什么开关结果是不可信的”这件事拆开来讲清楚，同时给出一套我自己在用的、能让压测结果真正可对比的工程方法。

1. “一个开关”其实改变的是整个运行生态

1.1 开关并不是单点变化

我们直觉上觉得“改一个开关”就是代码里一个布尔值的翻转，运行时只会沿着这一个分支走。但在真实的服务端场景里，开关几乎都是调整“资源分配策略”或者“并发行为模式”的，它影响的不是一行代码路径，而是一整类系统资源的调度方式。

拿我上面提到的NUMA开关举例，-XX:+UseNUMA改的并不是JVM“用不用某个特性”，而是改变对象分配时对内存节点的选择策略。打开这个开关之后，JVM会倾向于把对象分配到执行线程所在CPU对应的本地内存节点上，这在多路服务器上能降低远端内存访问延迟，但也可能让某些线程的内存分配集中到同一个节点，导致节点间负载不均。你关掉它，内存分配相对混沌但均匀；打开它，内存局部性好但可能引入新的平衡问题。两个模式下的GC频率、分配速率、TLAB命中率全都会变，压测结果自然跟着变。

更常见的例子是线程池参数。把核心线程数从8改成16，表面看只是并发能力提升，实际改变的是锁竞争强度、上下文切换频率、任务队列排队模型、甚至GC的并发标记线程的资源竞争模式。如果你是做模型推理服务，改一个batch_size开关，影响的可能不只是吞吐量，还包括显存分配碎片、算子融合策略、异步流水线的深度。这些层面的变动，不会写在配置文件注释里，但都会直接反映到压测数据上。

所以说，开关从来不是“单点变化”，它是一整套系统行为模式的切换。你不能假设A/B两个配置只存在一个差异变量。

1.2 按影响机制给开关分个类

根据我在压测中的经验，做实验结果对比之前，最好先判断自己动的是哪一类开关，因为不同类别的开关对结果可信度的影响机制完全不同。

第一类是运行时资源开关，典型如JVM的GC策略、堆大小、NUMA、大页内存、偏向锁、压缩指针。这类开关通过改变内存布局、CPU调度、锁行为来影响性能，特征是一旦生效，整机资源分配模型都会变化，压测结果受机器当前状态影响非常大，很难复现。

第二类是框架层行为开关，比如Netty的缓冲区分配策略、HTTP连接keep-alive开关、服务治理框架的熔断阈值、AsyncProfiler的采样开关等。这类开关改变的是请求处理链路的行为，对压测的影响是线性的，但容易受压测工具端连接池状态影响。比如你只改服务端的keep-alive开关，但压测客户端的连接复用策略没变，测量结果就是两套连接逻辑的混合体。

第三类是应用逻辑开关，比如模型推理服务里的动态batching开关、量化开关、缓存开关。这类开关直接决定计算路径，结果最容易看懂——开和不开，性能差距可以差好几倍——但它们也最容易掩盖问题，因为量化开关可能改变了计算精度，动态batching可能改变了延迟分布，这些用单一QPS指标根本看不出来。

我一直建议团队在做性能调优实验前，先给要动的开关打上“资源型/行为型/逻辑型”的标签，然后针对不同标签预设不同的观察指标。这能避免很多“结果相反”的误导。

1.3 小开关引发大崩塌的传导链

理解了开关的全局性，再去复盘那些“改一个开关结果崩了”的案例，很多时候不是开关本身的逻辑错了，而是一连串连锁反应放大了系统的非线性行为。

举个我自己经历过的例子：我有一个服务原本GC用的是Parallel Scavenger，非一次压测前我把一个“JSON序列化使用缓冲池”的开关打开了。这个开关本身只是让序列化时少new一些临时对象，看起来人畜无害。但正因为临时对象减少了，对象分配率下降了，GC的频率降下来了。GC降频之后，原本被GC暂停掩盖的锁竞争问题浮现出来——因为并发线程不再被频繁打断，锁争抢的持续时间变长，P99延迟反而大幅上升。

这种“修复了一个瓶颈，暴露了另一个瓶颈”的连锁效应，在复杂的服务端系统里几乎是常态。用计算机系统里的话说，这叫性能平衡木：你把一个瓶颈挪走，系统的稳态就重新分布，新的瓶颈会在别的地方冒出来。所以改一个开关之后压测结果变了，这个“变”可能是真实的性能变化，也可能是系统从一个稳态跳到了另一个稳态，而你看到的结果只是新稳态下的一个采样点。

理解了机制，接下来要面对一个更扎心的问题：就算开关真的只影响了局部，压测方法论本身也经常制造假数据。

2. 压测方法上的三个坑，比机器问题更隐蔽

2.1 压测工具先把自己压垮了

很多人在排查性能问题时，会忽略一个基本事实：压测结果 = 服务端处理能力 + 压测客户端生成能力。当压测机自己成为瓶颈时，你看到的所谓性能下降，其实是压测端的抖动。

拿JMeter举例。如果你在Windows机器上跑JMeter，几百个并发线程就能把客户端的CPU吃满，而Windows线程调度的粒度又很粗，线程之间互相抢占，发出的请求间隔就会剧烈抖动。我在压测一个CPU密集型的模型推理服务时，遇到过压测机网卡软中断抢占CPU导致请求发送延迟增加了十几毫秒，服务端其实稳如泰山，但客户端统计的响应时间曲线就是很难看。

我后来养成了一个习惯：压测前永远先看压测机自身的CPU、内存、网络软中断、线程切换指标。如果压测机CPU使用率超过70%，或者软中断占比明显升高，先升配置、减少并发线程数、或者换用异步压测工具（比如k6、vegeta）把问题隔离掉。否则后面所有的对比实验都是建立在沙地上的。

还有一个高频坑是连接数。压测工具默认会为每个线程建立独立连接，开10个线程就是10条连接，但你如果用连接池复用一个连接，压测机侧的TIME_WAIT状态会迅速积累，最终占满端口表，新连接创建失败，表现为请求错误率上升。在这个节点上你去对比开关效果，只会得到一堆噪声。

2.2 只看平均值等于自欺欺人

压测结果不可信的第二个来源，是统计口径和采样方式的偏差。

我在工作中见过太多“平均响应时间180ms，P99已经1.2秒”的报告。平均值这个指标天生对长尾不敏感，而性能优化最需要关注的恰恰是长尾。你把一个开关改了，平均QPS涨了20%，但如果P99涨了3倍，对于线上用户体验来说这就是一次性能恶化，而不是优化。

更隐蔽的是采样方式的问题。有的压测工具默认每500毫秒采样一次，有的按请求数采样，有的按完成请求采样。如果你压测时用了“按完成请求采样”，那么当服务端变慢时，单位时间内完成的请求少了，采样的点也就少了，统计结果会偏向那些快的请求——这就是一个恶性循环：越慢越失真。同样跑5分钟，两组实验的采样总量可能差两倍，直接对比它们的平均延迟毫无意义。

我建议的标准做法是四个指标一起看：QPS、平均延迟、P99延迟、错误率。而且延迟分布要按分位数看整条曲线，不能只看一个点。如果一个开关改动之后，QPS上去了、但P99曲线尾部变厚，这个开关大概率引入了某种“大多数请求变快、少数请求被阻塞”的机制，比如锁升级、缓存失效、批量刷新。

2.3 没做预热就是在测量“系统启动过程”

第三个方法论大坑是忽略预热。服务端应用从启动到稳定运行，内部有一大堆东西在慢慢“热起来”：JIT热点编译、线程池懒加载、连接池初始化、缓存填充、GPU的CUDA context建立、模型权重加载。这些过程的时间尺度差距很大，JIT可能需要几十秒到几分钟，CUDA context可能要十秒量级，缓存填充则取决于流量模式。

如果你不预热就直接压测，得到的数据是“系统从零开始”的过程数据，而不是稳态数据。更坑的是，JIT是分层编译的，热门方法会逐步从解释执行升级为C1编译再升级为C2编译，每一级编译完成之后性能都会跳变一次。所以你会发现压测曲线呈阶梯状上升：前几分钟性能不稳定，之后慢慢爬升，然后突然跳到另一个平台期。

我见过最离谱的一次，同一个开关改了之后，一组实验做了2分钟预热，另一组没预热，结果性能差距从10%到80%不等。这不是开关的作用，这是系统的启动过程在研究里产生的结果。不把预热做足，你对开关的判断就毫无意义。

3. 机器标称“不变”，运行时却分秒在变

3.1 JIT把同一段代码编译成了不同的机器码

你可能会说：模型文件一样、机器一样、开关一样，那再跑一次总该一样了吧？其实仍然不一定。

现代服务端语言（Java、Go、甚至C++在某些编译器下）都有运行时优化机制。JVM的JIT会根据每次运行时的分支走向、调用频次、内联决策，把方法编译成不同的机器码。同一个开关在不同运行时刻，可能会触发不同的内联决策。比如方法A在第一次运行时没有被内联，第二次运行时因为调用频率超过了阈值被内联了，于是整个热路径的指令数都变了，性能就变了。

理解JIT最形象的类比是厨师备菜：同一个菜单，如果只做一次，厨师就按部就班起锅烧油；如果这道菜连续被点100次，厨师就会提前把料切好、把锅烧热、甚至把配料直接码在锅边——这就是JIT的“热点编译”。你改了一个开关，相当于给菜单换了一种食材，厨师会重新判断要不要提前备菜，于是后续所有的备菜策略都跟着变。

我实践中做过一次实验：同一个服务，同一个开关，我连续跑了三次10分钟压测，每次结果相差了15%左右。抓出JIT日志看了一下，三次热路径方法的编译级别不同，有的方法在C1编译级别就停了，有的跑到了C2，内联的深度也不一样。这完全不是开关的问题，而是JIT的随机决策差异。

要在压测中把JIT的影响抹平，唯一可靠的做法是足够长的预热时间，以及多次实验取中位数而不是单次数据。我在标准压测流程里，预热时间至少占整个实验的30%，而且会用两个不同开关的配置交叉重复验证。

3.2 GC行为和内存分配率的“隐形蝴蝶”

JIT是容易被忽视的变量，GC则是更显眼但仍然防不胜防的变量。

GC对压测的影响可以分成两类：一类是暂停型影响（STW），另一类是分配率影响。前者直观，看GC日志就好；后者则很隐蔽——对象分配率的变化不一定会立即触发GC，但它会改变GC的触发频率、垃圾回收的幅度、甚至晋升到老年代的对象数量，最终影响停顿时间和内存占用。

我之前压测过一个图像处理服务，只把一个“图片元数据缓存”开关打开了，结果老年代GC从每5分钟一次变成每30秒一次。原因很简单：缓存对象被频繁引用，无法被回收，晋升到老年代的对象变多，老年代更容易满。表面上看这个开关只是增加了一个缓存层，实际上它改变了整个堆的对象年龄分布。

所以做开关对比实验时，GC日志不是可选项，而是必选项。我习惯每次都采集四项数据：Full GC次数、GC总暂停时间、平均分配率、晋升速率。如果两次实验在GIGC指标上的差异大于30%，我会判定这个对比实验无效，需要重新调整堆参数或者增加堆内存再做，直到GC行为在可接受范围内接近，才认为开关的差异是可信的。

3.3 CPU频率、超线程与NUMA的“同机不同性”

机器还是那台机器，但现代CPU不可能给你一个恒定不变的运行环境。

第一层干扰是CPU频率调节。服务器CPU的睿频机制会动态调整频率，如果开了节能模式（powersave governor），频率会随负载变化而波动，负载高时频率上去、负载低时频率下来。这就导致一个问题：你在压测时看到的结果，有一部分可能是CPU频率变化带来的，而不是开关的功劳。我见过有人在同一台机器上压测，关掉睿频和开启睿频，性能差距能到30%，而且这个差距在不同测试时段还会反转。

第二层干扰是超线程。一台24核的机器，如果你是靠超线程才看到48个逻辑核，那么“同一核”上另—个兄弟线程的负载会直接影响你的执行速度。你压测的同时，如果机器上某个监控Agent在跑定时任务，它可能恰好就被调度到了你正在用的物理核的另一半上，你就被迫和它争抢执行单元。这种干扰在压测数据里表现为周期性的尖刺，非常难排查。

第三层是NUMA拓扑。多路服务器上，内存访问延迟取决于内存在哪个节点。如果你的服务端进程只在一个节点上分配内存，而压测流量线程绑定在另一个节点，那么每次跨节点访问都会增加延迟。这能解释为什么“同一台机器”上午和下午压测结果完全不同——问题可能出在进程被调度到了不同的CPU节点上。

我在排查这类问题时，会先给机器做一次“硬件基线测试”，跑一个纯CPU计算负载反复测几次，看结果方差。如果纯计算负载的结果都飘，那就是基础环境不稳定，环境不修好做任何开关实验都是白费。

3.4 TCP层和连接状态的残留效应

最后一个容易被忽略的“变”是连接状态。你压测一个网络服务，每跑一轮实验，TCP连接状态都会产生残留：TIME_WAIT状态的连接要等2MSL才能释放、客户端端口可能被占满、服务端文件描述符可能短暂不够用。

如果你在两轮压测之间没有充分冷却，第二轮实验一开始服务端可能会有大量处于TIME_WAIT的连接没有被回收，新建连接要走完整的握手流程，延迟自然升高。我之前踩过一个典型的坑：压测HTTP服务，第一轮开了keep-alive，第二轮关掉了，但压测客户端还复用着第一轮建立的连接，服务端却已经准备关闭了。结果第二轮的错误率和连接重置率特别高，数据完全没法看。

结论是：保证两次实验之间的冷却时间足够长，或者在完成一轮压测后强制关闭所有连接、清理TIME_WAIT状态、等待文件描述符回落到基线，再开始下一轮。

4. 工程化压测方法论：把“不可信”变成“可对比”

4.1 对照组不是跑两次，而是多次独立采样

既然知道了这么多干扰因素，那怎么才能获得可信的对比结果？

我的经验是把压测当作统计学实验来做，而不是“跑个脚本看个数字”。核心动作就三个：

第一，固定流量模型。不要用“压测工具随机生成流量”，而要用录制好的真实请求序列，或者用固定比例组合的合成流量。这样才能保证两轮实验的输入尽可能一致。我在压测模型推理服务时，会把线上录制的请求trace保存下来，压测时原样回放，连请求里的token长度分布都保持一致。

第二，多次运行取统计量。每个配置至少跑3轮独立实验，每轮之间留足冷却时间，然后记录每轮的QPS均值、P99值、错误率。最后比较两个配置时，对比的是三轮实验的均值差异，并算出标准差。如果标准差大于均值差的50%，我会认为这个对比结果没有意义，需要补充更多实验。

第三，用统计检验判断“差异是否显著”。最简单的方法是t检验：如果两个配置三轮结果的均值差大于标准误的1.96倍，可以认为差异在95%置信水平上显著；否则，哪怕均值差看起来有10%，也可能是随机波动。我碰到过太多次均值差有8%但方差巨大、统计检验不显著的案例了，这种结果拿去汇报，就是给自己埋雷。

4.2 单开关实验的执行规范

基于上面的方法论，我整理了一份我自己每次做开关对比实验时强制遵守的“实验纪律”，这里分享出来直接可用：

第一，每次实验持续时间不少于5分钟，我认为10分钟更稳。时间太短，一个GC暂停就能把你采样的数据带歪；时间越长，JIT、GC的随机性越能被平均掉。

第二，实验顺序随机化交替进行。不要一口气把配置A跑三轮再去跑配置B，而是A、B、A、B、A、B这样交叉。原因是机器环境会随时间漂移（温度、频率、后台任务），交叉跑能把这些时间效应平均分配到两个配置上。

第三，每次压测前做一个“环境基线快照”。记录CPU频率当前状态、内存使用率、负载均值、在线用户数（如果是共用机器）、是否有定时任务、GC日志状态。跑完之后再记录一次，如果两次快照差异明显，这轮实验就直接废弃，排障完了重新跑。

第四，压测机和目标机隔离。不要在同一台机器上既跑服务端又跑压测工具，你抢到的CPU周期不同，结果就不公平。就算物理机不够，至少用taskset或cpuset把压测进程和服务端进程隔离到不同的物理核上，避免互相干扰。

下表是我在实验中用来判断“本轮数据是否有效”的硬性指标，可以对照参考：

这张表不是拍脑袋定的，都是我在实际工作中用血泪换来的经验值。你可以在自己项目中先按这个阈值跑，再根据机器性能做微调。

4.3 波动源快速定位：一套顺手排查工具组合

当你不确定“开关是不是罪魁祸首”的时候，怎么快速定位波动源？我给你一整套我现在在用的排查路径。

第一步，看GC。用jstat -gcutil 1000，每秒输出一次GC状态，对比两轮实验的GC参数变化。如果差异大，就不用继续看了，先把GC问题解决掉再谈开关。

第二步，看JIT编译情况。可以用JFR（Java Flight Recorder）或-XX:+PrintCompilation记录编译事件。重点看热路径方法有没有在不同轮次中编译级别不一致。你要是发现同一个方法上一轮是C2编译、这一轮停在C1，那性能波动原因基本就锁定了。

第三步，看CPU频率和调度。用cpupower frequency-info查看当前频率，用taskset查看进程绑定，用perf stat -e context-switches查看上下文切换。如果发现频率档位在实验期间变化超过两档，建议锁定最高性能模式再来一遍。

第四步，看压测客户端状态。如果用JMeter，先看JMeter所在机器的CPU、线程状态、连接数；如果压测机有GC（Java客户端一样有），也把它记录下来。压测器的抖动比服务端的抖动更容易被忽略，但它同样会污染数据。

第五步，看网络。用ss -s查看TCP socket状态统计，关注TIME_WAIT的数量变化。如果第二轮实验的连接数和第一轮差异大，就要考虑是连接复用策略不一致导致的。

这一套下来，90%的波动源都能定位到。剩下10%可能就是玄学，可以靠多跑几轮平均掉。

4.4 结果报告里必须记录的“环境指纹”

最后，我建议所有压测实验结果都按一个固定模板记录，把“环境指纹”留全。没有完整环境记录的结果报告，过了两周看，基本等于废纸。

比较重要的几项是：

• 提交版本和开关diff：两个配置各自的完整参数列表，不是只记录你改的那个开关，而是记录所有跟性能相关的参数，防止漏掉隐藏变动。
• 硬件和拓扑信息：CPU型号、核心数（物理/逻辑）、NUMA节点分布、内存大小、是否为虚拟机/容器。
• 运行时参数：JVM或框架的完整启动命令、GC配置、线程池大小。
• 机器状态快照：实验开始前的load average、CPU频率、内存余量、磁盘空间、网络连接数。
• 实验流量描述：请求量级、请求体大小、token分布、并发数、压测时长、预热时长。
• 结果指标：QPS均值、标准差、P50/P95/P99延迟、错误率、GC暂停总时长、CPU使用率等。

我习惯把这些信息存成一个配置文件，和压测产生的数据放同一个目录，这样每次回看历史数据时，都能完整还原当时的实验条件。

5. 避坑清单与我踩过的几个真实案例

5.1 三个“开关黑锅”的复盘

说实话，我上面讲的理论方法，都是被现实毒打出来的。在这里复盘三个我印象最深的案例，希望能帮大家少走弯路。

第一个案例：改一个“UseTLAB”开关，性能反而差了。当时我分析了一整天，怀疑是JVM的TLAB分配逻辑出了问题。后来发现，真正原因是我的压测客户端和服务端跑在同一台机器上，压测工具线程在疯狂创建数组，把内存带宽吃掉了，服务端反而分配不到足够的内存带宽。改开关只是背了锅。从那以后，我再也没有把压测放在目标机上跑过。

第二个案例：改模型推理服务的batch_size开关，P99飙升了3倍。我刚开始以为是动态batching的调度开销变大了，后来用NVIDIA SMI一看，是显存分配碎片导致的内存拷贝变多了。batch_size变大之后，显存分配器在反复分配回收同一批显存块，碎片率上升，部分batch不得不等显存整理完成才能计算。这说明一个逻辑开关的修改，可能通过硬件资源使用模式间接影响性能，不看硬件指标根本发现不了。

第三个案例：量化开关压测结果不稳定，早上好晚上差。我一度怀疑是量化算法有随机性，后来才发现是机器CPU频率被系统调度切到了powersave模式，白天温度高、频率降档，晚上凉快了频率又回来。同开关、同模型、同机器，结果能差出20%，这完全不是我代码能控制的事情。

这三个案例的教训可以浓缩成一句话：先确认测量系统本身是可靠的，再去怀疑开关改变了系统。

5.2 压测前检查清单

最后送上一份我在每次做“单开关对比实验”前都会过的检查清单，大家可以直接抄作业：

• 压测机和目标机是否分离？是否已用taskset分成不同核组？
• 压测机CPU使用率是否低于70%？
• 目标机是否已预热足够长时间（至少占实验总时长的30%）？
• 当前CPU governor是performance还是powersave？频率是否锁定？
• 是否有定时任务或监控Agent可能在实验期间运行？
• GC日志是否开启？JIT编译日志是否开启？
• 连接的keep-alive策略在压测端和服务端是否一致？
• 两轮实验之间是否留有冷却时间？
• 本轮实验的完整环境指纹是否已记录到配置文件？

这些事，每一项看着都不复杂，但漏掉任何一项，都足以让“只改一个开关”的实验彻底失效。

6. 我最后的操作习惯：先怀疑测量系统，再怀疑开关

做了这么多年压测，我给自己的核心操作原则变成了这样：一旦发现“同模型、同机器、只改一个开关”但结果不稳定的现象，我的第一反应永远是“测量系统哪里出了问题”，而不是“这个开关真的影响了性能”。这个思路帮我省下了大量排查时间，也让我的性能调优决策变得可靠得多。

具体到我现在的习惯，每次压测开关对比实验时，我会强制要求每个配置至少跑三轮，每轮10分钟、预热5分钟，每轮结束之后立刻把环境指纹存一份文件，然后等到全部实验做完再统一对比统计量。如果三轮的结果标准差超过均值的10%，我会直接判定这个对比实验无效，先回去查环境，而不是在这堆不稳定的数据里硬找结论。

最后分享一个小技巧给同样被这个问题折磨的人：把实验结论从“这个开关有效”改成“在这个环境指纹下，这个开关有X%的概率能带来Y%的提升”。虽然这句话说起来绕，但它才是压测结果背后真实的置信度。追问“为什么结果不可信”的过程，本质上就是在追问我们到底相信什么。