在给餐厅招新主厨前，老板一定会干一件事：让新主厨和老主厨分别做几道招牌菜，掐表看谁上菜快、谁用料省、谁忙起来不翻车。这个“做菜考核”就是性能基准测试。PyTorch 要推自己新来的“主厨”——torch.compile，也面临同样的任务：它凭什么说自己比老主厨（Eager 模式）更快？快多少？在什么条件下更快？为了回答这些问题，我们需要一套公平、科学、可重复的“考核方案”，也就是基准测试（Benchmark）。本篇文章就带你从零搭建这套方案，看看 compile 模式这口“新锅”什么时候香，什么时候翻车，以及如何用数据替你做技术选型。

岗位关联

对 AI 从业者而言，掌握基准测试就是掌握“拿数据说话”的能力——无论是验证优化效果、说服团队切换方案，还是定位推理瓶颈，一份严谨的评测报告都是最有力的发言依据。

目录
  1. 可视化演示
  2. 基准测试概览
  3. 核心指标体系
  4. 评测方法流程
  5. 前后对比分析
  6. 硬件环境差异
  7. 工具实践技巧
  8. 部署决策指导
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示torch.compile编译前后推理延迟对比、多模型吞吐量提升及基准测量统计分布IQR离群值过滤三种核心模式，直观呈现AI编译器性能评测机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

推理延迟对比 warmup阶段预热编译填充缓存排除冷启动噪声 编译后P99延迟从42ms降至19ms加速2.2倍 Speedup = Eager_latency / Compiled_latency torch.utils.benchmark自动处理同步和warmup

基准测试概览

老板要考核厨师，第一步不是发秒表，而是先想明白“考核到底要回答什么问题”——是看谁出菜快，还是看谁能在高峰期同时照料更多桌客人？跑 Benchmark 也一样，动笔写脚本前，先弄清目标：你想验证 torch.compile 比 Eager 快多少？它在你的服务器上能不能稳定提速？不同的提问方式，决定了你该测什么指标、设计什么样的实验。

基准测试（Benchmark）就是一套标准化的“考核流程”：固定环境、固定输入、反复运行、统计分析。就像考试要统一试卷、统一时间、统一阅卷标准一样，只有控制变量，两个选手的表现才具有可比性。torch.compile 的新世界里有 Eager 模式作为参照系，我们需要用同一份“试卷”来考它们。

一个完整的评测流程通常分四步：搭建固定环境、预热跳过冷启动、多次采样记录、统计汇总出报告。这四步缺一不可——少了预热，cold start 的慢会被误当成平均成绩；少了多次采样，一次抖动就会污染整个结论。基准测试是一门“排除偶然”的学问，它的精确程度，直接决定了你对编译优化收益的判断是否可信。

回到餐厅的例子：老板不会因为新厨师炒第一道菜洒了勺油就开除他——他会等新厨师把灶台摸熟了，再连续记录二十道菜的出菜时间，和老主厨的数据一比，才作出论定。基准测试的意义，正是把这种“等人熟了再测”的耐心，变成一套可执行的科学流程。

Speedup=TˉeagerTˉcompile\text{Speedup} = \frac{\bar{T}_{\text{eager}}}{\bar{T}_{\text{compile}}}
这个公式是“考核总成绩单”：Eager 模式的平均耗时除以 torch.compile 的平均耗时，结果大于 1 表示编译更快，等于 1 表示打平，小于 1 则表示开了倒车。
  1. 定义分子（老主厨的成绩）$\bar{T}_{\text{eager}}$ 表示 Eager 模式下多次推理的平均耗时，这是参照系的基准线，类似老主厨的平均出菜时间。
    Tˉeager=1n∑i=1nTeager,i\bar{T}_{\text{eager}} = \frac{1}{n}\sum_{i=1}^{n} T_{\text{eager}, i}
  2. 定义分母（新主厨的成绩）$\bar{T}_{\text{compile}}$ 表示 torch.compile 在稳定运行阶段的平均耗时，类似新主厨忙完一天的稳定出菜时间。
    Tˉcompile=1n∑i=1nTcompile,i\bar{T}_{\text{compile}} = \frac{1}{n}\sum_{i=1}^{n} T_{\text{compile}, i}
  3. 求比值（得出考核结论）两个均值相除得到加速比，比值越大说明编译优化的收益越可观，反之则说明这个场景不适合上 compile。
    Speedup=TˉeagerTˉcompile\text{Speedup} = \frac{\bar{T}_{\text{eager}}}{\bar{T}_{\text{compile}}}

核心指标体系

餐厅考核要看三个维度：上菜快不快（延迟）、翻台率高不高（吞吐量）、备料占不占地方（内存）。torch.compile 的基准测试也对应有三大核心指标——推理延迟、吞吐量和内存占用，再加上一个由延迟推导出来的“综合分”：加速比。

推理延迟是最直观的指标，指模型完成一次推理所需的时间，单位通常是毫秒（ms）。它衡量的是“单次服务质量”：对用户而言，一次请求等 50 毫秒和等 500 毫秒的感受完全不同。但延迟并不能反映系统的整体处理能力——如果单次延迟很低，但每秒只能处理 10 个请求，对高并发场景依然不够用，这就需要看吞吐量。

吞吐量（Throughput）衡量系统在一秒内能处理多少个请求，单位是“次/秒”或者“样本/秒”。它是“系统总产能”的度量，与单次延迟和硬件并行能力都相关。在批量推理场景中，吞吐量往往比延迟更重要。而内存占用则记录模型推理过程中 GPU 显存和 CPU 内存的峰值，torch.compile 引入的编译缓存、图优化可能带来额外内存开销，需要一并监测。

三个指标各有侧重：延迟照顾单客体验，吞吐量照顾整体产能，内存照顾成本预算。回到餐厅：你可能遇到一位“出菜快但占用灶台多”的厨师，也可能遇到“出菜慢但手脚利落不占地方”的厨师——到底用谁，取决于你是开快餐店还是做私房菜。Benchmark 的价值就是把这些权衡数据化，让你在多种部署方案中作出理性取舍。

Throughput=NTtotal\text{Throughput} = \frac{N}{T_{\text{total}}}
吞吐量公式的含义是：在总时长 $T_{\text{total}}$ 内完成了 $N$ 次推理，相除就是每秒处理能力。它跟延迟有点像但不是一个概念——类比餐厅，延迟是“一桌客人从点菜到上菜的时间”，吞吐量是“一天总共接待了几桌”。
  1. 统计总完成的推理数$N$ 表示在测试窗口内累计完成的推理次数，比如压测了 1000 次请求，$N=1000$。
    N=累计推理次数N = \text{累计推理次数}
  2. 统计总耗时$T_{\text{total}}$ 表示完成所有推理的总计时长，单位用秒，这样得出的吞吐量就是“每秒次数”。
    Ttotal=tend−tstartT_{\text{total}} = t_{\text{end}} - t_{\text{start}}
  3. 求比值即得吞吐量用 $N$ 除以 $T_{\text{total}}$，结果越大代表系统单位时间的处理能力越强。
    Throughput=NTtotal\text{Throughput} = \frac{N}{T_{\text{total}}}

评测方法流程

主厨考核最忌讳“趁乱掐表”——后厨刚开门一片兵荒马乱时测出来的数据，既不能代表老手常态，也不能代表新手真实水平。同样，跑 torch.compile 基准时，冷启动阶段的“编译期开销”和热机后的“稳定运行期”成绩必须严格区分。

标准的评测方法分三步走。第一步是固定环境配置：锁定 GPU 型号、CUDA 版本、PyTorch 版本、输入尺寸和 batch 大小。任何一项环境不同，结果都不可横向比较。第二步是预热：在正式采样前，先用同样的输入跑若干轮，让 CUDA 各种上下文初始化完成、让 torch.compile 完成首次图编译，也就是“跳过冷启动”。

第三步才是正式采样，而且要多轮运行、记录每一次的耗时，最后取中位数而不是平均值。为什么要中位数？因为均值会被个别极端慢值“平均地绑架”，而中位数能真实反映“典型表现”。打个比方：你问 10 位顾客上菜要多长时间，其中 9 位说 10 分钟，1 位说 3 小时，平均数是 27 分钟，中位数是 10 分钟——显然中位数更贴近大多数人的真实体验。

评测流程总结成一句话：环境固定、预热充分、多次采样、中位数收尾。这套方法保证了不同模型、不同后端之间的比较公平可信。就像同一张考卷、一样的考试时长、去掉一个最高分一个最低分再算成绩——基准测试的科学性，来自对每一处细节的极端较真。

Tmedian={T(k+1),if n=2k+1T(k)+T(k+1)2,if n=2kT_{\text{median}} =\begin{cases}T_{(k+1)}, & \text{if } n=2k+1 \\\dfrac{T_{(k)} + T_{(k+1)}}{2}, & \text{if } n=2k\end{cases}
这是中位数的定义式：把所有耗时排序后取正中间位置的值（偶数个则取中间两个的平均）。它比均值抗干扰，是 Benchmark 报告的“定盘星”。
  1. 将所有耗时排序把采样的 $n$ 次推理耗时按从小到大排列，记为 $T_{(1)} \le T_{(2)} \le \dots \le T_{(n)}$。
    T(1)≤T(2)≤⋯≤T(n)T_{(1)} \le T_{(2)} \le \cdots \le T_{(n)}
  2. 奇数样本取正中当 $n=2k+1$ 是奇数时，正中间的那个数就是中位数，下标为 $k+1$。
    Tmedian=T(k+1)T_{\text{median}} = T_{(k+1)}
  3. 偶数样本取中间两均值当 $n=2k$ 是偶数时，取第 $k$ 和第 $k+1$ 位的平均值作为中位数。
    Tmedian=T(k)+T(k+1)2T_{\text{median}} = \frac{T_{(k)} + T_{(k+1)}}{2}

前后对比分析

厨师考核需要一张“对照组成绩单”：老主厨做 20 道菜各用了多久、新主厨又各用了多久，然后逐项对比。Benchmark 里的对照组就是 Eager 模式——PyTorch 传统逐算子执行的方式——它是“没被编译优化过的原味表现”。

对比分析的第一步，是在完全相同的环境和输入下，先跑一遍 Eager 模式，记录它的延迟分布作为基准线。第二步，开启 torch.compile 后跑同样的输入，记录 compile 模式的数据。第三步，将两组数据逐项对比：不只比平均延迟，还比 p50、p95、p99 等分位数，以及内存峰值。

对比的最终产物是两个数字：加速比和内存增量。加速比已经在前面定义过，是 Eager 均值除以 Compile 均值。内存增量则是 compile 模式的内存峰值减去 eager 模式的内存峰值——如果模型加速明显但内存爆炸，部署时就要谨慎。但需要注意，加速比是“收益”，编译时间与额外内存是“成本”，两者必须放在一起看。

前后对比分析让“快不快”从感觉变成了数字。任何声称“compile 提速两倍”的说法，都应该附上一份包含 Eager 基准线、样本量、统计口径的报告。真正靠谱的优化结论，不是靠“好像快了”的直觉，而是靠并排摆放的两组数据自己说话。

Memory Overhead=Mcompile−Meager\text{Memory Overhead} = M_{\text{compile}} - M_{\text{eager}}
这个公式衡量“新主厨额外占了多少冰箱”：compile 模式的峰值显存减去 eager 模式的峰值显存，正值代表编译引入了额外内存开销，负值代表反而更省内存。
  1. 记录 compile 峰值内存$M_{\text{compile}}$ 是 torch.compile 模式在推理过程中的峰值显存，反映新方案的最高占用。
    Mcompile=max⁡tmcompile(t)M_{\text{compile}} = \max_{t} m_{\text{compile}}(t)
  2. 记录 eager 峰值内存$M_{\text{eager}}$ 是 Eager 模式的峰值显存，作为对照组的内存基准线。
    Meager=max⁡tmeager(t)M_{\text{eager}} = \max_{t} m_{\text{eager}}(t)
  3. 作差比较两者内存差异两者相减，若结果为正说明 compile 有额外内存成本，需要在部署时评估是否可接受。
    Memory Overhead=Mcompile−Meager\text{Memory Overhead} = M_{\text{compile}} - M_{\text{eager}}

硬件环境差异

同一个厨师换了一口灶，出菜速度可能完全不一样——有的灶火猛，有的灶保温差。torch.compile 的加速效果同样“认硬件”：在 A100 上加速两倍的搭配，换到消费级显卡上可能只剩 1.2 倍，甚至原地踏步。

GPU 型号是最大变量。高端数据中心的 GPU 有更大的显存带宽和更强的并行能力，torch.compile 的算子融合优化在带宽受限场景下能充分施展；而低端 GPU 上，融合带来的访存节省可能并不显著。其次是精度设置：FP32 与 FP16（半精度）下，显存占用、计算速度、融合策略都不同，compile 在低精度下的收益往往更明显。

第三个变量是 batch 大小。小 batch 时，模型推理以算子启动开销为主，torch.compile 通过内核融合减少内核启动次数，可能带来显著加速；大 batch 时，计算密集度上升，编译优化的边际收益逐渐收窄。这就是为什么 Benchmark 报告必须声明“测试条件”——脱离硬件与输入配置谈加速比，就像不说明厨具就讨论菜谱，毫无意义。

硬件差异不是“缺陷”，而是基准测试必须覆盖的变量维度。一份合格的评测报告应当列出多组硬件配置下的加速比矩阵，帮助团队找到自己服务器上的最佳甜点区。就像餐厅老板会为自己的灶台、锅具、菜单组合专门定制考核表——没有放之四海皆准的“最优”，只有“属于你的环境的最优”。

Bopt=arg⁡max⁡b∈B  Speedup(b)B_{\text{opt}} = \arg\max_{b \in \mathcal{B}} \; \text{Speedup}(b)
这个式子表示“最优 batch 大小”定义：在候选集合 $\mathcal{B}$ 中，寻找使加速比最大的那个 batch 值。它提醒我们：加速比不是常数，而是随输入配置变化的函数。
  1. 定义候选 batch 集合$\mathcal{B}$ 是所有待测试的 batch 大小集合，比如 {1, 4, 16, 64}。
    B={1,4,16,64}\mathcal{B} = \{1, 4, 16, 64\}
  2. 计算各 batch 的加速比对集合中每个 $b$，都按前述加速比公式计算当前 batch 下的 Speedup(b)。
    Speedup(b)=Tˉeager(b)Tˉcompile(b)\text{Speedup}(b) = \frac{\bar{T}_{\text{eager}}(b)}{\bar{T}_{\text{compile}}(b)}
  3. 取最大值对应的 batch用 $\arg\max$ 找出使加速比最大的那一个 $b$，即最优 batch 配置。
    Bopt=arg⁡max⁡b∈B  Speedup(b)B_{\text{opt}} = \arg\max_{b \in \mathcal{B}} \; \text{Speedup}(b)

工具实践技巧

给厨师计时，不能靠老板站在身后瞪着眼用手机掐表——得有一套统一规范的工具，比如后厨的出单系统。做 torch.compile 基准测试也有现成的专业工具：torch.profiler 就是那套“出单系统”，它能逐算子记录耗时、显存分配、内核启动时间，是定位性能瓶颈的第一现场。

torch.profiler 的基本用法是：用 torch.profiler.profile() 包裹推理代码，设置 activities 为 CPU 和 CUDA 的活动，再配合 schedule 跳过预热轮次，最后用 export_chrome_trace 导出火焰图。配合 torch.utils.benchmark 工具，可以快速生成 Timer 对象做微基准测量，还能自动处理 warmup 和重复次数。

实践中建议把评测脚本模板化：一个函数接收模型、输入、设备、精度、前后端模式，返回延迟列表和显存峰值；另一个函数负责循环采样、统计中位数和分位数；第三个函数把结果格式化成 JSON 或 CSV 落盘。模板化保证了评测可复现：任何时刻重跑脚本，都能得到相同口径的数据。

工具的价值在于把“随手测测”升级为“规范评测”。torch.profiler 负责精确定位开销藏在哪一层，benchmark 模板负责保证评测可复现，日志落盘负责让每一次实验都有据可查。这就像后厨有了统一出单系统和录像复盘——每次考核都能追溯、能对比、能持续改进评测流程本身。

p=min⁡(1,nwarmupntotal)p = \min\left( 1, \frac{n_{\text{warmup}}}{n_{\text{total}}} \right)
这个公式描述预热比例 $p$ 的设定：预热轮数占总采样轮数的比例，实际经验中通常取 10%~20%，既保证跳过冷启动，又不浪费太多算力。
  1. 确定预热轮数$n_{\text{warmup}}$ 是正式采样前用于“热机”的推理次数，它让 CUDA 上下文与编译缓存就绪。
    nwarmup=max⁡(5,0.1×ntotal)n_{\text{warmup}} = \max(5, 0.1 \times n_{\text{total}})
  2. 确定总轮数$n_{\text{total}}$ 是包括预热和正式采样在内的总推理次数，通常取 20~100 之间。
    ntotal=nwarmup+nmeasuredn_{\text{total}} = n_{\text{warmup}} + n_{\text{measured}}
  3. 计算预热占比两者相除得到预热比例，合理范围在 0.1 到 0.2 之间，确保统计稳定性。
    p=nwarmupntotalp = \frac{n_{\text{warmup}}}{n_{\text{total}}}

部署决策指导

老板手握新老两位厨师的考核数据，下一步不是直接拍板，而是算一笔账：新厨师带来的效率和额外成本相比，值不值得聘？部署决策是基准测试的最终落点——它把数据转化成行动。

第一步是后端选择。torch.compile 支持多种后端（如 Inductor、CUDAGraphs），不同后端在不同硬件和模型上表现各异，需要逐一在你的目标硬件上实测。第二步是参数调优：调整编译模式（default/reduce-overhead/max-autotune）、精度设置和 batch 大小，找到该模型在这个硬件上的组合最优解。

第三步是成本收益权衡。编译本身需要时间（一次性成本），编译后的运行可能有额外的内存占用（持续性成本），而收益是延迟下降和吞吐量提升。如果模型每次推理耗时极短、且服务是冷启动频繁的短生命周期任务，那编译开销可能完全吞掉加速收益；反之，如果是长驻服务，一次编译、长期受益，就很划算。

部署决策的本质是“用数据解决权衡问题”。基准测试不是终点，它是决策的输入——通过完整记录收益和成本，你可以理直气壮地回答“要不要上 compile、怎么上”这个问题。就像老板最终拍板时靠的是考核表和成本核算单，而不是“新厨师看起来更麻利”的印象。

Net Gain=ΔT×Requests−Tcompile−ΔM×Costmem\text{Net Gain} = \Delta T \times \text{Requests} - T_{\text{compile}} - \Delta M \times \text{Cost}_{\text{mem}}
这个公式是“聘用新主厨的净收益账本”：右侧第一项是总省下的推理时间，减去一次性编译时间和额外内存的钱，结果为正就值得部署。
  1. 计算总节省时间$\Delta T$ 是每次推理节省的时间（Eager 减 Compile），乘以总请求数得到全生命周期的总省时。
    ΔT×Requests\Delta T \times \text{Requests}
  2. 减去一次性的编译成本$T_{\text{compile}}$ 是首次编译消耗的时间，它是固定成本，与请求量无关。
    Tcompile=Tcompile end−Tcompile startT_{\text{compile}} = T_{\text{compile end}} - T_{\text{compile start}}
  3. 减去持续的内存成本$\Delta M$ 是内存增量，乘以单位内存成本换算成金钱，体现“省了时间但贵了内存”的代价。
    ΔM×Costmem\Delta M \times \text{Cost}_{\text{mem}}
  4. 汇总为净收益总收入减去总成本，若为正则部署 compile 是划算的，若为负则需要保持 Eager 或换后端。
    Net Gain=ΔT×Requests−Tcompile−ΔM×Costmem\text{Net Gain} = \Delta T \times \text{Requests} - T_{\text{compile}} - \Delta M \times \text{Cost}_{\text{mem}}

AI 应用场景

场景一：大模型服务上线前的选型评估

阶段：模型部署与优化

解决的问题：传统做法是在 Eager 模式下直接部署推理服务，缺少量化手段判断 torch.compile 是否值得启用，往往是“拍脑袋”决定，导致服务上线后延迟不达标或显存溢出。通过基准测试，可以在上线前就对推理延迟、吞吐量和内存压力作出数据化预测，规避生产事故。

具体案例：某智能客服团队的 NER 模型即将上线，工程师在 A10 GPU 上用 1000 条真实请求分别跑 Eager 和 torch.compile（Inductor 后端），对比 p50/p99 延迟与显存峰值。结果显示 compile 模式 p99 从 80ms 降到 45ms，但显存峰值增加 300MB——最终团队根据这份数据调整了 batch 大小并加开了两个实例，成功上线。

场景二：推理优化方案的持续迭代与回归检测

阶段：性能优化与迭代

解决的问题：优化团队在调整编译参数（如 max-autotune、显存布局）时，容易陷入“这次改好了还是改坏了”的混乱。基准测试模板化之后，每次改动自动跑一份评测报告，用加速比和延迟分位数做回归检测，避免优化一个指标却劣化另一个指标。

具体案例：某视频理解平台每两周更新一次模型，配套的 benchmark 脚本会在 CI 中自动跑 120 轮采样（预热 20 轮），输出 JSON 报告归档。某次升级后脚本自动发现 FP16 模式下 compile 的吞吐量下降了 18%，定位到是新增算子的融合规则不匹配，及时回滚并反推解决了问题。

Python 演示

python46 行
import torchimport timeimport statistics def run_benchmark(model, sample, mode, warmup=10, repeat=30):    if mode == "compile":        model = torch.compile(model)    # 预热轮次，跳过冷启动    for _ in range(warmup):        model(sample)    torch.cuda.synchronize()    latencies = []    # 正式采样轮次    for _ in range(repeat):        torch.cuda.synchronize()        start = time.perf_counter()        model(sample)        torch.cuda.synchronize()        latencies.append((time.perf_counter() - start) * 1000)    latencies.sort()    median = statistics.median(latencies)    p95 = latencies[int(len(latencies) * 0.95)]    return median, p95 def main():    if not torch.cuda.is_available():        print("CUDA not available, benchmark requires GPU.")        return    torch.manual_seed(0)    model = torch.nn.Sequential(        torch.nn.Linear(512, 1024),        torch.nn.ReLU(),        torch.nn.Linear(1024, 512)    ).cuda().eval()    sample = torch.randn(32, 512).cuda()    eager_med, eager_p95 = run_benchmark(model, sample, "eager")    compile_med, compile_p95 = run_benchmark(model, sample, "compile")    speedup = eager_med / compile_med    print("Eager   median: %.2f ms, p95: %.2f ms" % (eager_med, eager_p95))    print("Compile median: %.2f ms, p95: %.2f ms" % (compile_med, compile_p95))    print("Speedup (median): %.2fx" % speedup)    if speedup < 1.0:        print("No speedup, consider eager mode for this workload.") if __name__ == "__main__":    main()
目的：用统一流程测量同一模型在 Eager 与 torch.compile 两种模式下的中位数延迟与 p95 延迟，并自动计算加速比，输出部署决策依据。
  1. model = torch.compile(model)把模型切换为编译模式，等价于给厨师换上新灶台，但注意首次调用会触发编译。
  2. for _ in range(warmup): model(sample)预热循环，让 CUDA 和编译缓存就绪，跳过冷启动的异常数据。
  3. torch.cuda.synchronize()阻塞等待 GPU 完成所有内核执行，保证计时不遗漏异步操作。
  4. latencies.append((time.perf_counter() - start) * 1000)用高精度计时器记录每轮推理耗时并换算成毫秒。
  5. statistics.median(latencies)取中位数而非均值，抗偶发抖动，反映典型性能表现。
  6. speedup = eager_med / compile_med计算加速比，大于 1 说明编译模式在该环境下有收益。
  7. if speedup < 1.0:数据驱动地判断“该不该上 compile”，避免凭感觉做技术选型。

常见误区

误区听说 torch.compile 是 PyTorch 2.0 的“性能神器”，于是把所有模型都无脑 switch 到 compile 模式，坚信任何模型都能白拿加速。

正解torch.compile 的收益取决于模型结构、算子类型、batch 大小和硬件。小模型、小 batch 场景下，编译开销和优化效果可能倒挂，加速比实测可能低于 1。就像给小摊贩配全套中央厨房设备，设备启动时间比炒菜时间还长，反而拖慢效率。必须实测数据，用加速比说话。

为何常见：营销材料和社区消息往往只展示加速成功的案例，失败的案例很少被传播，容易形成“compile=免费提速”的错觉。

误区跑基准时，把模型编译后的第一次推理耗时记录为“compile 模式延迟”，然后直接拿去和 Eager 对比。

正解首次推理包含编译开销，可能比 Eager 慢数倍，但它是一次性成本。正确做法是预热多轮，待模型稳定后再采样。这就像考核新厨师不能在他还没找到调料位置时掐表，应该先让他熟悉厨房再计时。

为何常见：初学者往往对“冷启动”概念不敏感，加上示例代码常常省略预热逻辑，照着抄就出错了。

误区评测报告只写“平均延迟 30ms”，用均值作为唯一性能指标，忘记统计 p95、p99 等尾部延迟。

正解均值会被极端值拉偏，而在线服务的用户体验往往被“最慢的 5%”决定。一个平均 30ms 但 p99 达到 300ms 的服务，在真实流量下依然会让用户卡顿。延迟分布要结合中位数、p95、p99 一起看，才能全面判断“典型”和“最差”两个层面的表现。

为何常见：均值最容易计算、最容易理解，而分位数需要排序和额外统计，很多人图省事就不做了。

误区在某一张 GPU 上测出 compile 加速比很高，就断言“这个模型用 compile 一定快”，直接推广到所有部署机器。

正解编译优化效果和硬件强相关：访存带宽、内核启动开销、支持的指令集都影响融合效果。A100 上的结论可能在 T4 上完全反转。报告必须声明测试硬件和软件版本，换环境就要重新 benchmark。

为何常见：人在认知上偏好“简单化结论”，希望一条经验覆盖所有场景，但性能工程恰恰是“环境敏感”的领域。

面试题

Q1. 下列哪项是 torch.compile 性能基准测试的核心目的？

单选题 · easy

  • A.证明 compile 永远比 Eager 快
  • B.量化编译优化的实际收益← 正确答案
  • C.替代单元测试验证功能正确
  • D.自动生成模型的训练数据集

答案：B。基准测试的目标是用数据量化优化收益，为后端选择和参数调优提供依据。A 错在“永远”二字，compile 并非在所有场景都更快；C 和 D 分别属于功能测试与数据工程范畴，与性能评测无关，就像考核厨师是为了评估水平而非验菜是否新鲜。

Q2. 推理延迟的标准单位通常是什么？

单选题 · easy

  • A.分钟（min）
  • B.毫秒（ms）← 正确答案
  • C.吉字节（GB）
  • D.帧率（fps）

答案：B。推理延迟指单次推理耗时，毫秒是业界通用单位。选项 C 是内存单位，D 是刷新率单位，A 的量级太大不适合描述单次推理；如同上菜计时常用“分钟”而非“小时”，推理计时常用“毫秒”而非“秒”。

Q3. 吞吐量的标准定义是？

单选题 · easy

  • A.单次推理的最快耗时
  • B.单位时间内完成的推理次数← 正确答案
  • C.模型占用的显存大小
  • D.编译一次所需的墙钟时间

答案：B。吞吐量衡量系统的整体产能，即每秒处理多少请求。A 是延迟的极致表现，C 是内存指标，D 是编译开销；类比餐厅，吞吐量是“一天接待的客人数”，而不是“最快一桌的上菜速度”。

Q4. 预热（Warmup）在基准测试中的作用是？

单选题 · mid

  • A.提升模型最终精度
  • B.跳过冷启动异常数据← 正确答案
  • C.减少 GPU 显存占用
  • D.缩小模型参数量

答案：B。预热让 CUDA 上下文、内核缓存在正式采样前就绪，尤其是 torch.compile 的首次编译也被预热轮消耗掉，保证后续采样反映稳定运行表现。B 正确；A、C、D 分别是训练、内存优化和模型压缩领域的概念，与预热无关。

Q5. 为什么基准测试通常取中位数而非平均值？

单选题 · mid

  • A.中位数总是比平均值更小
  • B.中位数更抗极端值干扰← 正确答案
  • C.平均值无法通过代码计算
  • D.中位数代表最差情况性能

答案：B。中位数关注排序后的中间位置，个别极端慢值不会“绑架”结果，更贴近典型体验。平均值可能被少数卡顿拉高。D 说反了，p99 才代表最差情况；正如顾客体验更常被“多数人等了多久”描述，而非被一个等了 3 小时的人拉高的平均数。

Q6. 加速比的计算公式是？

单选题 · mid

  • A.Eager 耗时乘以 Compile 耗时
  • B.Eager 平均耗时除以 Compile 平均耗时← 正确答案
  • C.Compile 平均耗时除以 Eager 平均耗时
  • D.Eager 耗时减去 Compile 耗时

答案：B。加速比 = Eager 平均耗时 / Compile 平均耗时，大于 1 表示编译更快，等于 1 打平。C 分子分母反了，D 得到的是差值而非倍数，A 更是无意义的乘积；简化记“老成绩除以新成绩”即可。

Q7. 一个模型在 A100 上加速比 2.5x，换到 T4 上最可能的现象是？

单选题 · hard

  • A.加速比一定超过 2.5x
  • B.加速比可能显著下降← 正确答案
  • C.完全无法运行
  • D.加速比不变

答案：B。编译优化收益依赖硬件特性，T4 的访存带宽、内核开销与 A100 不同，算子融合效果会打折扣，加速比可能大幅缩水甚至低于 1。B 正确；A 和 D 假设加速比跨硬件不变，不符合性能工程规律；C 过于极端，模型通常仍能运行。

Q8. 设计 torch.compile 基准测试时，需要固定哪些环境变量？（多选）

多选题 · mid

  • A.GPU 型号与驱动版本← 正确答案
  • B.PyTorch 版本与 CUDA 版本← 正确答案
  • C.输入尺寸与 batch 大小← 正确答案
  • D.当天天气与测试人员心情

答案：ABC。GPU 型号、驱动、PyTorch/CUDA 版本是软件栈基线，输入尺寸和 batch 直接影响计算形状与融合策略，都必须锁定。D 是无厘头干扰项；只有控制全部变量，两组数据的对比才有科学意义，如同考试必须统一试卷与考场。

Q9. 部署决策阶段“成本收益权衡”应考虑哪些因素？（多选）

多选题 · hard

  • A.编译时间开销← 正确答案
  • B.额外内存占用← 正确答案
  • C.请求量生命周期← 正确答案
  • D.模型代码的注释行数

答案：ABC。编译时间是一次性成本，内存增量是持续成本，请求量决定总省时能否覆盖编译开销。三者构成净收益公式的关键项。D 与运行性能无关；评价新主厨值不值得雇，看的是聘金与效率差，而不是菜谱上的笔记多少。

Q10. 衡量推理性能的常用统计量包括？（多选）

多选题 · easy

  • A.中位数（median）← 正确答案
  • B.p95 分位数← 正确答案
  • C.p99 分位数← 正确答案
  • D.模型参数量大小

答案：ABC。中位数代表典型表现，p95/p99 代表尾部延迟，共同构成完整的延迟画像。参数量是模型规模指标，与运行性能无直接线性关系，故不选 D；一项考核至少要能回答“大多数客人等多久”和“最慢的客人等多久”。