【推理优化进阶】性能实验科学：工作负载、统计显著性与尾延迟归因

注：建议在开始学习本专栏前先完成对推理优化工程师快速入门指南专栏中所有内容的学习。

生产流量不是固定长度矩阵

先导课中，我们通过固定延迟、固定 QPS 的压测拿到了基线吞吐数字。但把这份报告带到生产环境评审时，几乎必然会被挑战：真实流量不会像基准测试那样方方正正如矩阵------每一行等长，每个请求同质。生产流量有到达的节奏、有输入输出的联合形态、有不同租户的叠加，这些维度共同决定了实验结论是否可迁移。

Open-loop 与 closed-loop：你的压测工具在哪个世界

大部分压测工具默认采用 closed-loop 模型：发完一个请求后，等待响应返回，再发下一个。这种模型保证了系统在任意时刻的在途请求数恒定，因此吞吐被系统延迟自然地钳制住------延迟升高时，发送速率自动降低。但这并不符合真实情况。

生产环境更接近 open-loop ：客户端按独立于服务端响应时间的节奏持续发请求，无论上一个请求是否完成。排队论中，closed-loop 对应 M / M / 1 M/M/1 M/M/1 排队系统，而 open-loop 对应的则是 M / G / ∞ M/G/\infty M/G/∞ 或带有重试的 M / M / 1 + K M/M/1+K M/M/1+K 模型。两者的关键差异在于：open-loop 下，当服务延迟恶化时，排队长度会持续增长，积压请求最终导致超时雪崩------这种级联效应在 closed-loop 压测中完全不会出现，因为 closed-loop 工具发现响应变慢后会自动降低发包速率，系统永远不会进入过载区。

因此，压测工具必须支持 open-loop 模式（如 ghz 的 --concurrency 配合固定间隔、wrk2 的固定 QPS 模式、k6 的恒定虚拟用户配合 arrival-rate executor），否则你测出的只是系统在"友好负载"下的表现，而非真实流量下的生存能力。

Poisson 仅是基线，不是答案

业界最常见的负载生成方式是"平均 QPS 加随机波动"，其数学基础是 Poisson 到达过程：假设每个请求的到达相互独立，且到达间隔服从指数分布。其合理性在于无记忆性（memoryless property）------系统当前的状态不携带关于下一次到达时间的任何信息。这使得 Poisson 成为分析上的便利假设，也是所有排队论教科书的基础模型。

但生产流量几乎从不服从 Poisson。原因很直接：Poisson 要求独立同分布的到达间隔，而真实请求之间天然存在相关性。用户的点击行为呈爆发式------一个热门事件触发成千上万的并发访问；下游服务的重试在超时后同步爆发；定时任务在每个整点同时触发。这些行为导致到达间隔不是独立同分布的。

实际建模中，更贴近现实的分布包括：

Weibull 分布 （形状参数 k < 1 k < 1 k<1 时呈递减危险率，模拟"空闲期后的集中爆发"）
Pareto 分布（重尾，模拟极端突发峰值）
自相似流量模型（如分数布朗运动驱动的到达过程，用于 Web 流量建模）

一个实用的做法是：用 Poisson 做下界基线 ，再用突发模型（burst model）做压力上界。两条曲线之间的区域，才是生产流量的真实分布区间。

突发与日周期：负载不是平稳过程

即使你正确使用了 open-loop 和 Poisson 到达，还有一个更深层的问题：负载不是平稳随机过程，它带有明显的日周期和突发特征。

日周期（diurnal pattern）意味着你选取的压测时段直接决定了结论适用的时间窗口。典型的在线服务呈现"双峰"形态：中午 12 点---14 点与晚间 20 点---22 点的峰值 QPS 可能是低谷期的 3---5 倍。如果压测实验只覆盖了平稳期的负载，那么针对高峰期的容量规划就是外推------而外推在负载不均时几乎总是失效。

突发（burst）则更棘手。一个可复现的突发负载模型需要两个参数：突发长度 （burst length，即连续到达的请求数）和突发间隔（inter-burst interval）。两者均服从各自的概率分布。例如，某社交平台的 feed 刷新请求，在用户打开 App 的瞬间形成 50---200 个请求的突发，随后进入静默期。这类模式可以用 Markov 调制 Poisson 过程（MMPP）建模：系统在"正常态"和"突发态"之间切换，两个状态下的到达速率不同。

实验设计时，建议在压测脚本中显式编码这两种模式，而非依赖工具默认的均匀速率：

python 复制代码

# 突发负载生成示例（示意逻辑）
import numpy as np

def bursty_arrivals(mean_rate, burst_factor, burst_prob):
    """在 Poisson 基线上叠加突发"""
    while True:
        if np.random.random() < burst_prob:
            # 突发态：速率提升 burst_factor 倍，持续 50-200ms
            rate = mean_rate * burst_factor
            duration = np.random.uniform(0.05, 0.2)
        else:
            rate = mean_rate
            duration = np.random.exponential(1 / mean_rate)
        # 按当前速率生成指数间隔的到达
        yield np.random.exponential(1 / rate)

延迟分布与删失数据

上一节重建了生产流量的到达过程，但请求发出之后的故事同样容易被简化。大多数基准测试报告只给出一个数字：平均延迟或 P99。这个数字背后的样本集合，往往已经悄悄过滤掉了最关键的信号。当压测工具本身成为瓶颈，或者超时请求被直接丢弃、重试请求被单独统计、未完成的请求根本不进入样本时，延迟分布不再是系统行为的真实投影，而是一张经过裁剪的照片。

Coordinated Omission：测量仪器扭曲了测量对象

先看一个最常见的陷阱。使用 closed-loop 压测时，客户端等待响应返回后才发起下一个请求。假设系统在 10 秒内发生了一次 5 秒的停顿，由于客户端在这 5 秒内没有发出任何新请求，这段时间在压力视角下是"不存在"的------压测工具记录的延迟分布完全缺失了排队时间。这就是 coordinated omission（协调性遗漏）：测量行为与系统行为耦合，导致异常事件被系统性地从样本中抹除。

修复方案并不复杂：压测工具必须记录请求的预期发起时间 与实际完成时间 之差，而非简单的"发出到返回"。如果客户端原本应在 t 0 t_0 t0 发出请求，但系统停顿导致请求实际在 t 0 + 4 s t_0 + 4s t0+4s 才发出、 t 0 + 4.2 s t_0 + 4.2s t0+4.2s 才收到响应，那么这条样本的延迟应该记为 4.2 秒，而不是 0.2 秒。Gil Tene 在 2015 年的 QCon 演讲《How NOT to Measure Latency》中演示了同一个系统在同一负载下，修正前后 P99 从 1ms 变为 2400ms 的极端案例。任何延迟报告若未说明压测工具如何处理并发排空（concurrency drain），其 P99 数字都值得怀疑。

HDR Histogram：为什么平均值和普通百分位不够

即使修正了样本采集方式，延迟数据的呈现方式也决定结论的可靠性。延迟分布几乎总是长尾的------P99.9 可能是 P50 的百倍以上。传统的时间片直方图（如每 100ms 一个桶）在尾部几乎无法分辨：大量样本堆积在 P50 附近，尾部每个桶只有零星几个样本，百分位估计的误差急剧膨胀。

HDR Histogram （High Dynamic Range Histogram）正是针对这个问题设计的。它使用浮点数的指数-尾数语义来动态选择桶边界：数值越小，桶越密；数值越大，桶越宽。这使得单个直方图能以约 1% 的精度覆盖从微秒到小时的跨度，同时内存占用固定。实际使用中，HDR Histogram 的核心价值不在于它的低内存，而在于它支持的压缩百分位查询------你能在同一份数据上同时回答 P50、P99.9 和 P99.999，而不需要重新保存原始样本。

延迟实验报告中，应明确标注百分位估计的误差上界。HDR Histogram 的 getValueAtPercentile(p, tickResolution) 允许指定 tick 分辨率来控制精度------报告时附带 p=99.99, error≤0.1% 这类标注，比裸写 "P99 = 240ms" 严谨得多。注意，HDR Histogram 存储的是观测值分布，它不会替你修正 coordinated omission------那是采样层的事。

P99 置信区间：点估计的陷阱

从 HDR Histogram 中读出的 P99 是一个点估计，而任何基于采样的点估计都有不确定性。假设实验跑了 10 分钟共 120 万个请求，P99 附近的样本约 1.2 万个，这看起来足够多。但真实场景中，尾尖峰（tail spike）是不频繁事件，且分布高度偏斜，直接报告单个 P99 值很容易把噪声当作信号。

更稳健的做法是计算百分位的置信区间 。对于第 p p p 百分位的估计 x ^ p \hat{x}_p x^p，一个实用的方法是 bootstrap 重采样 ：从原始样本中有放回地抽样 B B B 次（通常 B = 1000 B=1000 B=1000），每次重算 P99，取这 B B B 个 P99 的 2.5% 和 97.5% 分位数作为置信边界。由于 HDR Histogram 压缩了原始样本，bootstrap 需要作用于未压缩的桶计数组件------这也是为什么实验原始数据要保留，而不是只留报告摘要。

若时间预算不允许完整 bootstrap，至少应报告两个对照组各自 P99 的差值及其波动范围。一个"P99 降低 15%"的结论，如果置信区间横跨 0，它就不能被当作优化证据。

生存分析视角：删失数据不是可丢弃数据

延迟实验中最隐蔽的错误发生在样本筛选阶段。一个请求可能因为以下原因没有进入"成功样本"集合：

客户端超时：请求发出后超过阈值未收到响应，客户端主动断开
服务端取消：处理过程中客户端连接断开，服务端终止计算
重试污染：客户端超时后重试，第一次的延迟被完全丢弃
流式断连：流式响应中途连接中断，已接收部分数据但请求未完成

把这些样本从统计中删除，等于假设"失败的请求延迟无信息量"。但这恰恰是倒退------失败也是性能数据。生存分析（survival analysis）视角提供了一个干净的框架：每个请求从发出到完成（或删失）是一个时间事件，删失（censoring）本身就是观测的一部分。请求在 5 秒时被超时判断为失败，这条样本的信息是"系统未能在 5 秒内完成该请求"，而不是"该请求的延迟不存在"。

实践中，正确处理删失数据的方案是分级报告：第一级只统计成功完成的请求延迟；第二级统计所有请求的成功-失败时间（失败请求记为"完成时间 = 超时阈值"或"删失标记"）；第三级报告失败率随时间的曲线。三组数字合并呈现，读者才能判断延迟改进是否以牺牲成功率为代价。

队列视角的重新定义

把上述概念统一起来，延迟实验的本质其实是一个队列事件记录系统 。请求到达、排队、被处理、完成或被丢弃，每个事件都有时间戳。实验设计者真正要测量的不是"成功请求的延迟"，而是从请求进入系统到最终判定的完整生存时间，无论判定是成功还是失败。只有当报告明确说明三个问题------（1）样本是否修正了 coordinated omission；（2）百分位是否有置信区间；（3）删失样本如何纳入统计------延迟结论才具备跨环境迁移的基础。

这一节的框架将在下一节落地为具体的实验设计：如何通过 A/B 配对、消融和随机化顺序，来判定你观察到的延迟差异是真实信号还是环境噪声。

因果可归因的对照与消融

到达过程重建了，延迟分布也纠正了删失偏差，但还差最后一步：实验结论能不能站得住脚。前两节解决的是"流量像不像生产环境"，本节解决的是"改动之后的变化到底是不是改动造成的"。性能实验的因果推断比想象中脆弱------GPU 温升、时钟频率漂移、邻居实例的资源争抢、缓存命中率的逐次变化，这些干扰项与代码改动叠加在一起，足以让 A/B 对比得出完全相反的结论。

别让温度、时钟和邻居替你跑实验

先处理最容易被忽略的三个混淆变量。GPU 锁频 是第一个：现代 GPU 的 boost 机制会根据温度与功耗动态调节核心频率，同一段代码在冷启动时可能跑到 1.8 GHz，运行十分钟后因温度墙降频到 1.4 GHz。这不是理论上的担忧------两者之间的吞吐差异可达 20%-30%，远超大多数优化的预期收益。实验开始前用 nvidia-smi -lgc 1500,1500（以实际型号支持的频率范围为准）将频率锁定在固定值，或者至少在实验记录中标注实际运行频率。CPU 侧同理，检查是否启用了 intel_pstate 或 amd_pstate 的睿频策略，必要时通过 cpupower frequency-set --governor performance 固定。

环境快照是第二个：实验开始前，记录操作系统版本、内核参数、驱动版本、依赖库的 commit hash、环境变量、当前实例上与负载共置的其他进程清单。快照的价值不在于实验当时，而在于三周后有人拿着你的数据问"这个结果是在什么环境下得到的"时，你能给出精确的复现条件------而不是"大概是这样"。

邻居效应是第三个：共享物理机的容器实例之间，CPU 缓存、内存带宽和网络队列会相互干扰。同一个实验在隔壁实例繁忙和空闲时运行，P99 可以相差数倍。缓解手段是在实验期间声明资源争抢窗口（例如在结果表中注明"运行期间宿主机的 steal 时间占比 < 2%"），或者干脆在独享节点上做关键对比实验。

预热判据：不等时钟，等稳态

缓存冷启动和 JIT 编译预热会让前几百个请求的延迟显著偏高，直接纳入统计会污染分布。但固定预热 1000 请求并不可靠------不同系统达到稳态的时间相差两个数量级。更严谨的做法是定义预热判据：持续发送请求，每隔 5 秒计算一次滑动窗口内的平均延迟，当连续 3 个窗口的均值变化不超过 2% 时，判定进入稳态，然后清空统计样本、开始正式记录。这段预热数据不算数，但它的存在保证了正式数据确实来自稳态系统。

python 复制代码

def is_steady(window_means: list[float], tolerance: float = 0.02) -> bool:
    """连续 3 个窗口的均值变化不超过 tolerance 即视为稳态。"""
    if len(window_means) < 3:
        return False
    recent = window_means[-3:]
    # 计算相邻窗口的相对变化率，取最大值
    deltas = [abs(recent[i+1] - recent[i]) / recent[i] for i in range(2)]
    return max(deltas) <= tolerance

A/A、A/B 与配对运行

先跑一轮 A/A 实验------同一个版本跑两次，用同样的负载和协议。这看起来像是浪费时间，但 A/A 能告诉你系统本身的噪声底有多高。如果 A/A 的 P99 差异就有 5%，那么 A/B 中 8% 的差异可能只是噪声，而 A/A 差异只有 1% 的话，8% 就有更强说服力。

A/B 的配对运行 是关键。不要先跑完 A 再跑 B------这会让时间成为混淆变量（温度、邻居负载、缓存状态都随时间漂移）。正确做法是随机化交替 ：将实验时间段切成小片（如每 5 分钟一片），用随机序列决定每片跑 A 还是跑 B。随机化的意义在于，任何未观测到的时间相关干扰会均匀散落在两侧，而不是集中在一侧。类似地，随机化顺序保证了首次运行的缓存劣势或预热不足不会偏向某个版本。

多重比较修正与效应量

性能实验往往不只比较一个指标：P50、P99、P999、吞吐、错误率......每个指标做一次假设检验，5 个指标就是 5 次。每次检验有 5% 的假阳性概率，则 5 次中至少一次假阳性的概率为 1 − ( 0.95 ) 5 ≈ 22.6 % 1-(0.95)^5 \approx 22.6\% 1−(0.95)5≈22.6%。用 Bonferroni 修正 来应对------显著水平 α \alpha α 除以比较次数 m m m，即要求 p < α / m p < \alpha/m p<α/m------虽然保守，但在性能实验中是合理的：宁可漏报一个真实差异，也不能被噪声牵着走。另一种思路是先定主指标（比如 P99），只有主指标显著才算有效结论，其余指标作为辅助参考，这属于确认性分析与探索性分析的区分，也能有效控制假阳性。

最后，也是最重要的：效应量优先于 p 值 。p 值只告诉你"这个差异是否可能是噪声"，不告诉你差异有多大。样本量足够大时，1% 的延迟差异也能达到 p < 0.01 p < 0.01 p<0.01 的显著性------但 1% 在工程上可能根本不值得改。报告实验时同时给出两个量：差异幅度（如 "P99 从 210ms 降到 185ms，降幅 11.9%" 或 Cohen's d 效应量）和置信区间。置信区间比 p 值更丰富------它给出了差异的合理范围，让读者自己判断这个范围是否值得投入。

逐项消融是最后一个层次。如果一个优化涉及三个改动（如缓存+并发调优+协议精简），跑一次 A/B 只告诉你"这三个加在一起有效"，不告诉你谁的贡献大、谁在拖后腿。逐项消融的做法是：基线（什么都不改）→ 只加缓存 → 只加并发调优 → 只做协议精简 → 三个全上。每次对比都采用同样的配对随机化流程。这一步得到的结论才能指导后续的迭代方向，而不是只能给出一个模糊的"优化有效"。

到这里，从流量重建、延迟纠偏到因果归因，一整条性能实验链路已经齐了。但实验中还有一个绕不开的暗礁：当系统的行为被观测时，观测动作本身会不会改变结果？下一节我们讨论可观测性开销的校准------观测者效应的最后一种形态。

尾延迟放大链

前文分别解决了流量重建、样本纠偏与因果归因，现在需要把视角切换到单个请求的完整旅程。上一节的 A/B 实验可以告诉我们"改动是否有效"，却无法回答一个更具体的问题：当 P99 从 120ms 恶化到 210ms 时，这 90ms 的增量到底发生在哪一段路径上？ 性能优化的第一步永远是定位，而定位需要一张完整的 critical path 地图------从客户端发起请求，到网关路由，到队列排队，到调度器分配资源，到 Kernel 执行，到跨卡通信（NCCL），再到流式返回的第一个 token 落地。这张地图上的每一个环节都可能成为尾延迟的放大器，而且它们之间的相互作用远非线性叠加。

5.1 尾部不等于最慢 Kernel

一个反直觉的事实是：系统尾延迟的根因往往不在最耗时的 Kernel 上。假设一次推理请求的 critical path 包含 4 个串行阶段：网关路由（P99 5ms）、排队等待（P99 80ms）、执行（P99 50ms）、返回传输（P99 10ms）。直觉会指向执行阶段------它单个阶段最慢，但真正驱动整体尾延迟的可能是排队等待。

原因在于不同阶段的延迟分布形态差异巨大。执行阶段的延迟分布通常相对集中（受 Kernel 计算时间约束），而队列等待的延迟分布带有明显的重尾特征------它取决于队列长度、到达突发性和服务时间的相互作用。当分布形态不同时，各阶段 P99 的简单相加会显著高估整体延迟 （因为各阶段同时到达尾部的概率很低），而各阶段平均值的相加又严重低估尾部。正确的分析方法是看整条 critical path 上的 延迟联合分布：

P ( T t o t a l > t ) = P ( ∑ i = 1 n T i > t ) P(T_{total} > t) = P(\sum_{i=1}^{n} T_i > t) P(Ttotal>t)=P(i=1∑nTi>t)

如果各阶段 T i T_i Ti 近似独立，整体尾延迟主要由方差最大的那个阶段主导，而不是均值最大的阶段。这就解释了为什么优化执行阶段 Kernel 5ms，整体 P99 可能只改善 2ms；而把队列长度从 32 降到 16，整体 P99 可能改善 40ms。

5.2 同步放大

同步放大（synchronous amplification）是系统中存在的第一类放大器，它把一个环节的抖动传导到所有依赖它的下游环节。在 LLM serving 场景中最典型的模式是：请求在网关层同步等待后端的完整响应。

设想网关进程使用线程池处理请求，每个线程阻塞等待上游推理服务的响应。当某个上游实例出现 2 秒的停顿（例如 GPU 时钟降频或网络抖动），网关中所有等待该实例响应的线程都被卡住。线程池耗尽后，新到达的请求开始在网关队列中堆积，而网关的队列延迟又进一步恶化了所有请求的尾延迟------即使它们本来要被路由到健康的实例。

放大倍数可以量化：假设网关线程池有 64 个线程，某个上游实例的 2 秒停顿导致 32 个线程被卡住，其余 32 个线程仍然可以处理新请求，但每个请求的有效并发度从 64 降到 32，等效于系统的吞吐能力减半。对于到达率为 λ \lambda λ 的 Poisson 流，队列的期望等待时间随利用率 ρ = λ / μ \rho = \lambda / \mu ρ=λ/μ 以 1 1 − ρ \frac{1}{1-\rho} 1−ρ1 的倍数增长。吞吐能力减半意味着利用率从 0.5 跳到 0.8 甚至更高，排队延迟放大 3-5 倍是保守估计。同步放大本质上把一次性的局部故障，转化为全局性的延迟恶化。

5.3 队首阻塞

队首阻塞（head-of-line blocking, HOL）是队列场景中最常见也最隐蔽的放大器。在推理服务中表现为：排在前面的慢请求阻塞了后面所有快请求的处理。

在单队列多 worker 的架构中，一个运行时间 30 秒的长请求（例如超长输入序列）占据了 worker 之后，排在它后面的短请求即使只需求 50ms 的计算，也必须等待 worker 释放。对于这些短请求，它们的延迟 = 排队等待 + 实际执行，而排队等待直接由队首的长请求决定。如果服务端不做优先级调度，短请求的尾延迟可以被长请求放大 100 倍以上。

从概率角度看，设长请求占比为 p p p，其服务时间为 S l S_l Sl（均值 μ l \mu_l μl，方差 σ l 2 \sigma_l^2 σl2），短请求服务时间为 S s S_s Ss。短请求的期望等待时间近似为：

E $W s$ ≈ p ⋅ E $S l 2$ 2 ( 1 − ρ ) \mathbb{E} $W_s$ \approx \frac{p \cdot \mathbb{E} $S_l\^2$ }{2(1-\rho)} E $Ws$ ≈2(1−ρ)p⋅E $Sl2$

因为 E $S l 2$ = μ l 2 + σ l 2 \mathbb{E} $S_l\^2$ = \mu_l^2 + \sigma_l^2 E $Sl2$ =μl2+σl2，长请求的方差项直接进入短请求的等待时间公式。一个变异性巨大的长请求（例如某次生成触发了极端长的解码长度），即使其占比只有 1%，也会显著抬高短请求的 P99。

业界常用的应对方案是多级队列 + 优先级调度：短请求进入高优先级队列，长请求进入低优先级队列，worker 优先消费高优先级。代价是长请求的延迟会进一步恶化，但整体尾延迟（尤其短请求的 P99）显著改善。

5.4 跨卡 straggler

在多卡并行（如 Tensor Parallel 或 Pipeline Parallel）的推理中，整体延迟由最慢的那张卡决定。假设模型分布在 8 张 GPU 上，每张卡的同步点（如 all-reduce）需要所有卡同时到达才能继续。如果 7 张卡在 10ms 内完成计算，而第 8 张卡因为散热噪声或邻居实例争抢花了 40ms，那么每个同步点的有效延迟是 40ms 而非 10ms。

跨卡 straggler 的核心问题是它随同步次数累积。一个推理请求可能有数十次同步点（每个 transformer layer 至少一次 all-reduce），假设每次同步点有 5% 的概率出现一张卡慢 3 倍，那么经过 30 次同步后，至少经历过一次 straggler 的概率为：

1 − ( 0.95 ) 30 ≈ 78.5 % 1 - (0.95)^{30} \approx 78.5\% 1−(0.95)30≈78.5%

这意味着大多数请求都会至少经历一次 straggler 延迟。跨卡 straggler 的检测需要按 GPU 维度拆分时间线：如果每次 all-reduce 的时间戳显示某张卡的到达时间始终晚于其他卡，且该偏差与卡上运行的 Kernel 无关，则大概率是物理层面的干扰（如温度导致的降频）。

5.5 按 request cohort 归因

有了 critical path 的各个节点和时间戳，最后一步是把延迟归因到具体的群体而非单个请求。按 request cohort 归因 的含义是：不以单个请求为分析单位，而是以具有相同特征的请求组为单位，对比它们在不同路径环节的延迟分布差异。

合理的 cohort 切分维度包括：输入长度区间（短输入 vs. 超长输入）、请求来源租户、路由到的 GPU 实例组、到达时段（繁忙时段 vs. 空闲时段）、请求所属的优先级类别。归因流程分三步：

拆解：对每个请求记录各环节耗时（网关耗时、排队耗时、调度耗时、执行耗时、NCCL 等待耗时、首 token 返回耗时）
汇总：按 cohort 计算各环节的 P50/P90/P99，并对比 cohort 间的差异
定位：找出差异最大的环节，确认该环节是 cohort 特征（如输入长度导致执行变长）还是系统异常（如特定实例组的邻居效应）

一个典型的归因结果可能是：input_len > 4096 的 cohort 其整体 P99 为 320ms，比短输入 cohort 高出 180ms；拆分后发现其中 120ms 来自执行阶段（Kernel 计算本身变慢），另外 60ms 来自 NCCL 等待（长序列导致激活更大、通信量更高）。进一步分析 NCCL 等待的时间戳，发现阻塞点固定在第 4 张卡------这指向通信拓扑中的热点，而非计算负载分布不均。

归因的最终产物是一张延迟瀑布图：对每个 cohort，展示各环节的延迟贡献占比，以及环节间同步放大效应的估计。有了这张图，下一步的工作才有的放矢------是优化执行 Kernel，还是调整队列调度策略，还是重新设计通信拓扑，答案都藏在按 cohort 拆解的延迟分布里。这也解释了为什么实验设计必须在前一节的基础上，在报告中附带关键路径的各环节延迟数据，而不是只给出一个总延迟数字。

critical path 的每一段都有特定的放大机制，它们在不同负载形态下被激活的概率各不相同。实验报告如果只呈现端到端延迟分布，相当于把一张曝光过度的照片交给读者------所有细节都糊在一起。将延迟按环节拆解、按 cohort 归因，才能让每一次 A/B 实验的结论落到具体可执行的优化动作上。至此，从流量重建到因果归因再到路径定位，性能实验的完整方法论已经闭合：实验结论不再是"改了什么、快了多少"，而是"改了哪个环节、通过什么机制、影响了哪类请求、贡献了多少延迟增量"。下一节将讨论如何把这套方法论固化为可持续运行的基准测试和回归防护体系。

实验：生成可复用的基准证据包

前三节的每一项修正------到达过程重建、删失数据纠偏、因果归因设计------都会让实验结论更接近生产真相。但若这些修正只存在于某次手动执行的压测脚本里，下一次实验时遗忘一个参数、改错一个路径，整套方法论的效力就归零。性能实验的终点不是一份报告，而是一个证据包：任何人拿到它，不需要与你沟通任何口头信息，就能复现全部数字、理解全部决策、验证全部结论。

三次独立运行不等于三个样本

先破除一个最顽固的习惯：在同一个压测会话里重复三次取平均值，然后宣称"实验重复了三遍"。这不是三次独立运行------它们共享同一段流量 trace、同一轮 GPU 温升曲线、同一批缓存状态，本质上只是同一个样本的三次读数。

独立运行意味着每一次都从冷启动开始：重新拉起容器、重新加载数据、重新预热到预设判据、重新执行流量回放。两次独立运行之间，机器的温度应当回落到环境温度，缓存应当被清空，邻居实例的负载状态应当被记录而非假定为零。隔夜运行三次比连续运行六次更有价值，因为隔夜引入了时钟、温度和邻居效应的自然变化，这些变化会如实反映在结果分布中。

一个务实的做法：对每个实验配置，至少获取 5 次独立运行的延迟分布，并用 bootstrap 重采样计算 P50 与 P99 的置信区间。如果 5 次的置信区间宽度超过均值的 20%，说明环境噪声仍占主导，此时应当检查环境快照的变量是否记录完整、GPU 锁频是否生效、邻居效应是否被隔离------而不是继续加跑次数。

记录功耗与成本

延迟数字只是性能画像的一半。同一个 P99 优化，一种实现让 GPU 功耗从 320W 升到 380W，另一种从 320W 降到 280W------两者在延迟曲线上可能完全相同，但前者意味着每千次推理多付 18.75% 的电费。在真实的生产决策中，功耗和成本往往是比延迟更硬的约束。

功耗数据应当与延迟数据同步采样，时间戳对齐到同一坐标系。NVIDIA 系 GPU 可以通过 nvidia-smi dmon 或 NVML 库直接读取实时功耗，采样频率建议不低于 10Hz，以保证与请求级别的延迟数据能够配对。记录时至少包含四列：时间戳、瞬时功耗、累计能耗（焦耳）、GPU 利用率。

配套记录的是成本元数据：跑了多少个 token、处理了多少请求、每个请求的平均能耗。这些数字将在实验对比时转化为单位经济指标------"每百万 token 的 P99 延迟"与"每百万 token 的能耗成本"------它们比裸延迟更能说服决策者。

bash 复制代码

# 示例：同步采集功耗与延迟数据（时间戳对齐）
nvidia-smi dmon -s p -d 0.1 > power_trace.csv &   # 100ms 间隔采样功耗
./benchmark_runner --config ./exp_0421.yaml          # 主压测进程

机器可读结果 schema

当实验规模超过三个配置、五个指标之后，手写 Markdown 表格来汇总结果就变成了错误的主要来源。所有原始结果必须以机器可读的 schema 落盘------推荐使用 Parquet 或 JSON Lines 格式，每条记录包含三层信息：

第一层：实验身份 。experiment_id（全局唯一）、commit_hash（代码版本）、config_hash（配置参数的哈希）、runner_version（压测工具的版本）。这一层的意义在于：任何一个数字都可以追溯到产生它的确切代码与配置状态。

第二层：环境快照。GPU 型号与驱动版本、CUDA 版本、容器镜像 digest、温度曲线摘要（起始/峰值/结束）、邻居实例的负载记录。这些数据回答了"这个数字是在什么环境下产生的"，是为下一节的可比性判断提供原始依据。

第三层：指标数据。延迟分布的分位数数组（P50/P90/P99/P999）、吞吐量、功耗曲线摘要、错误率、以及一个指向原始 trace 文件路径的引用。指标数据必须同时包含运行次数的维度，即同一个配置的 5 次运行各自独立存储，而不是预先聚合。

JSON 格式的 schema 示例如下：

json 复制代码

{
  "experiment_id": "exp_0421_batch256_lru",
  "commit_hash": "3a7f9c2",
  "config_hash": "sha256:1b4f...",
  "environment": {
    "gpu": "A100-80G",
    "driver": "535.183.06",
    "image_digest": "sha256:9e2c...",
    "temp_range_c": [31.2, 68.5]
  },
  "run_count": 5,
  "results": [
    {
      "run_id": "run_001",
      "p50_ms": 82.3,
      "p99_ms": 154.1,
      "throughput_rps": 312.7,
      "avg_power_w": 286.4,
      "energy_per_req_j": 0.91
    }
  ]
}

自动判定回归与不可比

证据包的最后一道工序，是把"判断"从人脑转移到代码。每次实验完成后，一条自动化的判定流程应当立即回答两个问题：这次改动是回归还是优化？这次实验与前次是否可比？

回归判定利用前文建立的 bootstrap 置信区间：当新配置的 P99 置信区间与基线置信区间完全不重叠时，可以确认差异具有统计显著性；部分重叠时通过置信区间的重叠比例来判断"可能显著"与"证据不足"。自动化脚本将判定结果写入结果文件的 verdict 字段，并附带判定的置信水平。

不可比判定则基于环境快照的偏差检查：如果本次实验的 GPU 温度峰值比基线实验高出 15°C 以上、或容器镜像 digest 与基线不一致、或邻居实例数量发生了变化，系统应当输出 INCOMPARABLE 标记而非任何数值结论。这条规则的意义在于：它强制团队在环境漂移超出阈值时停下并修复，而不是拿着不可比的数字硬做分析。

至此，这四节内容已形成完整闭环：重建到达过程、纠正延迟分布、确保因果可归因、定位尾延迟链条，最终沉淀为一份可复现、可追溯、可自动判定的证据包。这份证据包不仅是论文复现的模板，更是生产环境每次变更上线前必须通过的质量关卡------当回归判定脚本在 CI 中运行，当不可比标记阻止一次仓促的发布，这套方法论才真正成为团队的基础设施。