在 PyTorch 2.0 中，torch.compile 就像一位“餐厅总厨”，而你训练好的模型则是一份“祖传菜谱”。过去的 PyTorch 像一位“自由派厨师”：拿到菜谱后，每做一道菜都从洗菜、切菜开始，从不提前准备，也不做任何规划——这就是 Eager 模式（即时执行模式），灵活但缓慢。而 torch.compile 这位总厨拿到菜谱后，会先通读全文、设计中央厨房流水线、把常用食材提前备好、把锅具预热到位，然后才开火炒菜——这就是“编译优化”的哲学。 但总厨也分风格：有的追求极致品质，愿意花三小时慢炖高汤；有的追求快速上菜，五分钟内必须端出招牌菜。torch.compile 提供的 mode、fullgraph、dynamic、backend 等选项，正是让你为这位总厨选择“工作风格”的旋钮。调对了，你的模型推理从“现点现做”变成“满汉全席流水线”，从 GPU 上多榨出 30%~50% 的算力。

岗位关联

掌握 torch.compile 选项，是 PyTorch 模型从“能跑”进阶到“跑得快”的必经之路，也是 AI 推理部署工程师面试中的高频考点。

目录
  1. 可视化演示
  2. mode参数三档
  3. fullgraph参数
  4. dynamic参数
  5. backend选择
  6. 编译时机
  7. 实际部署
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

三步展示torch.compile编译选项：三阶段编译流程（Dynamo图捕获→AOT分解→Inductor代码生成）、mode模式权衡（编译时间vs运行性能）、backend后端选择(inductor/eager/triton)。

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

三阶段编译流程 Dynamo: 图捕获 AOT: 分解优化 Inductor: 代码生成 Dynamo→AOT→Inductor 一行代码包装即可编译加速。

mode参数三档

想象你是这家“AI餐厅”的老板，总厨问你：“今天想用哪种工作模式？”—— mode 参数就是你的回答。它预设了三档优化强度，分别对应三种厨房管理风格。default 档位像是“标准模式”：总厨提前做好食材预处理（算子融合），但不会追求每个细节的极致；reduce-overhead 档位专注于减少上菜过程中的“传菜时间”（即减少内核启动和 Python 开销，通过 CUDA Graph 捕获大幅压缩 CPU 与 GPU 之间的通信间隙）；max-autotune 档位则是“顶配模式”：总厨花大量时间研究每一种食材的最佳切法（自动调优每个算子的实现），换来满汉全席的极致出菜速度。

在 PyTorch 中，这三种模式通过一行代码切换：

max-autotune 之所以最强，是因为它会启用 Triton 框架的自动调优机制——针对每一个算子模板，在多个候选实现中实测选出最快的一个。这相当于总厨为每道菜都做了 A/B 盲测，选出最受欢迎的配方。

回到餐厅比喻：你不会让总厨每天都用顶配模式慢炖高汤——如果顾客只点了快餐，default 模式就够了；但如果今天接待满汉全席大宴，max-autotune 前期的精心准备就非常值得。选 mode，本质是选“准备时间预算”。

Eoverall=max⁡mode∈M(TeagerTcompile(mode))E_{overall} = \max_{mode \in \mathcal{M}} \left( \frac{T_{eager}}{T_{compile}(mode)} \right)
该公式表示：整体加速比是三种模式中实际运行时间倒数的最大值。mode 的选择本质是“编译时间预算”与“运行速度收益”之间的权衡，max-autotune 消耗数分钟编译时间换取更高的稳态吞吐。
  1. 模式集合$\mathcal{M}$ 代表可选的三种编译模式，$\{default, reduceOverhead, maxAutotune\}$
    mode∈M={default,reduceOverhead,maxAutotune}mode \in \mathcal{M} = \{default, reduceOverhead, maxAutotune\}
  2. 加速比定义$\frac{T_{eager}}{T_{compile}(mode)}$ 是相对于 Eager 模式的加速倍数，公式衡量不同模式的收益
    speedup(mode)=TeagerTcompile(mode)speedup(mode) = \frac{T_{eager}}{T_{compile}(mode)}
  3. 最优选择$E_{overall}$ 是最终有效加速比，取所有模式中的最大值
    Eoverall=max⁡mode(speedup(mode))E_{overall} = \max_{mode} \left( speedup(mode) \right)
python6 行
# 标准模式：编译时间短，性能提升约 20%-30%model = torch.compile(model, mode="default")# 减少开销模式：额外使用 CUDA Graph 减少 CPU 启动开销model = torch.compile(model, mode="reduce-overhead")# 极致自动调优：编译时间最长，性能提升可达 40%-60%model = torch.compile(model, mode="max-autotune")

fullgraph参数

fullgraph 这个参数像是一位“讲究的总厨”，他要求整个做菜流程必须一气呵成，从头到尾由他一人掌控，不允许中途让别人代劳。当 fullgraph=True 时，torch.compile 会将整个模型的计算图作为一个完整的图来编译，不允许任何“图断裂”（graph break）发生。所谓图断裂，是指某些 Python 操作（如 print、动态 if、数据依赖的循环）无法被编译器识别为张量操作，导致计算图被切成多个小片段，每个片段单独优化。

图断裂的代价如同“上菜中途换人”：每一段都要重新启动一次内核、重新传输一次中间数据，性能大打折扣。如果设置 fullgraph=True 而模型中出现了无法编译的操作，程序会直接报错——这反而是一种“帮助”，它让你立刻定位到是哪一步代码阻碍了整图优化。

在餐厅里，fullgraph=False 时总厨允许部分菜品外包给隔壁师傅；fullgraph=True 时总厨坚持“不外包，否则就报警”。现实中，对于 Transformer 这类标准模型，fullgraph=True 通常可直接开启；但遇到动态控制流较多的模型（如检测模型的后处理），就需要谨慎。开启 fullgraph，本质是“用报错风险换取极端性能”。

cbreak=∑i=1nsegments(α+β⋅di)c_{break} = \sum_{i=1}^{n_{segments}} \left( \alpha + \beta \cdot d_i \right)
该公式表示图断裂的总代价：$n_{segments}$ 是被切割的图片段数量，每个片段产生固定耦合开销 $\alpha$（内核启动）与数据传输开销 $\beta \cdot d_i$（$d_i$ 为中间数据量）。图断裂的数量越多，总开销越大，所以 fullgraph=True 通过“禁止断裂”来强制消除这些代价。
  1. 片段数量$n_{segments}$ 是计算图被切割的段数，每次 Python 控制流导致的图断都会增加段数
    nsegments=nbreaks+1n_{segments} = n_{breaks} + 1
  2. 固定开销$\alpha$ 是每段图执行时的固定启动开销（如内核调度、Python 层调用）
    α=Tlaunch\alpha = T_{launch}
  3. 数据开销$\beta \cdot d_i$ 表示第 $i$ 段产生的中间数据传递代价，$d_i$ 越大越昂贵
    costi=β×di\text{cost}_i = \beta \times d_i

dynamic参数

餐厅高峰时段，每桌顾客人数不定：有 2 人桌、4 人桌、8 人包间。如果总厨坚持每桌配 4 人份食材，要么浪费，要么不够。dynamic 参数就是用来应对这种“输入形状变化”的场景。PyTorch 的在默认情况下（dynamic=False）假设输入形状固定，编译器按固定形状生成最优内核代码——这如同总厨知道今天只接待 4 人桌，可以精确备料。但现实中推理服务的输入长度往往忽长忽短，形状不固定，这就导致需要动态形状支持。

dynamic=True 时，编译器不再假设单一形状，而是生成能处理一定范围形状的通用内核，并通过“形状分桶”（shape bucket）策略，将相似形状归入同一桶，为每个桶生成专门优化。这相当于总厨按“2-4 人 / 6-8 人”备料，而不是每一位客人都单独设计菜单。

为什么动态形状会变慢？ 编译器在固定形状下可以将张量维度硬编码为常量，展开循环、预分配精确大小的显存，这些优化在形状变化时都无法进行。对于 NLP 推理场景，建议对输入长度做 padding 到一个固定上限，配合 dynamic=False，往往比开启 dynamic=True 更快。开启 dynamic，本质是“为通用性牺牲部分性能”。

Sstatic=Tcompile(fixed)Trun(fixed),Sdynamic=Tcompile(bucket)Trun(bucket)S_{static} = \frac{T_{compile}(fixed)}{T_{run}(fixed)}, \qquad S_{dynamic} = \frac{T_{compile}(bucket)}{T_{run}(bucket)}
公式对比静态形状与动态形状的加速收益：静态形状以单次编译时间 $T_{compile}(fixed)$ 换取固定形状的极致运行速度；动态形状将编译预算分摊到多个形状桶上，每个桶的专用性下降，但适应性增强。
  1. 静态加速比$S_{static}$ 是固定形状下的加速比，编译一次、永久复用
    Sstatic=TcompileTrunS_{static} = \frac{T_{compile}}{T_{run}}
  2. 动态加速比$S_{dynamic}$ 是分桶后的加速比，每桶编译开销分摊到同类形状上
    Sdynamic=TbucketTrun(bucket)S_{dynamic} = \frac{T_{bucket}}{T_{run}^{(bucket)}}
  3. 权衡关系$S_{dynamic} < S_{static}$ 通常成立，因为通用内核不如专用内核极致
    Sdynamic≈γ⋅Sstatic,0.7<γ<0.95S_{dynamic} \approx \gamma \cdot S_{static}, \quad 0.7 < \gamma < 0.95

backend选择

每个餐厅背后都有供应商：肉从哪家买、蔬菜从哪家进，直接影响菜品质量。在 torch.compile 中，backend 参数就是选择“代码生成供应商”——负责把计算图翻译成 GPU 实际执行的代码。默认的 inductor 后端是 PyTorch 官方主推的“自营供应链”，它利用 OpenAI 的 Triton 语言生成高效的 GPU 内核代码。Triton 是一种面向 GPU 编程的类 Python 语言，屏蔽了 CUDA 的底层细节，让编译器能自动生成高性能内核。

选择 backend="inductor" 时，torch.compile 会将 Graph IR（内部中间表示）经多个优化 pass 处理后，生成 Triton 代码再编译为 GPU 内核。其他可选后端包括 eager（不优化，退化为普通模式）、aot_nnc 等。高级用户还可通过自定义 backend 函数接入自己的编译器实现，这相当于餐厅自己建立中央厨房标准，不依赖外部供应商。

Triton 的成功在于“适度抽象”：它不像 CUDA 那样需要开发者手动管理 shared memory 和线程同步，但保留了 tile 级操作和自动并行化的能力，让编译器程序能高效自动生成代码。这如同总厨使用标准化预制菜供应链，既保证品质统一又大幅降低人力成本。选 backend，本质是“选供应商的质量标准”。

Ktriton=TritonKernel(fused_graph),min⁡kernel∈KTexec(kernel)K_{triton} = \text{TritonKernel}(fused\_graph), \qquad \min_{kernel \in \mathcal{K}} T_{exec}(kernel)
公式表示 Inductor 后端的核心思想：将融合后的计算图交给 Triton 生成内核，并在多个候选内核中选出执行时间最短的那个。backend 的选择决定了这个“候选内核集合”的生成质量。
  1. 内核生成$\text{TritonKernel}$ 是 Triton 编译器将融合图转化为 GPU 内核代码的过程
    K=TritonKernel(fused_graph)K = \text{TritonKernel}(fused\_graph)
  2. 候选集合$\mathcal{K}$ 是编译器生成的多个候选内核（不同 tile 大小、循环展开策略）
    K={K1,K2,...,Kn}\mathcal{K} = \{K_1, K_2, ..., K_n\}
  3. 最优选择$\min T_{exec}$ 从候选集中选出执行时间最短的内核
    Kbest=arg⁡min⁡KiTexec(Ki)K_{best} = \arg\min_{K_i} T_{exec}(K_i)

编译时机

第一次调用 torch.compile 后的 model(...) 时，PyTorch 会有一个明显的“卡顿”——这是总厨在建立中央厨房：读取菜谱（追踪计算图）、设计流水线（图优化）、安装设备（生成 Triton 内核）。这个过程可能耗费数秒到数分钟。一旦编译完成，结果会被缓存到磁盘，之后每次加载同样的模型和配置都会直接复用缓存，无需重新编译。

缓存机制的关键是 缓存键：PyTorch 会根据模型源代码、编译选项、PyTorch 版本、GPU 型号等信息生成一个哈希值作为缓存标识。任何一项变化都会导致缓存失效，重新编译。这意味着，在生产环境部署时，你应当提前在相同环境下“预热”编译，把编译时间消耗在部署流程中而非用户请求的路径上。

餐厅的场景是：总厨第一天开业前已经花了一整晚建好中央厨房（预编译），之后每天的出菜时间才是真正的顾客体验。正确管理编译时机，本质是“把准备时间放在营业时间之外”。

Tfirst=Tcompile+Trun,Tsubsequent=TrunT_{first} = T_{compile} + T_{run}, \qquad T_{subsequent} = T_{run}
公式展示了编译时机对延迟的影响：首次调用开销为编译时间 + 运行时间，后续调用仅剩运行时间。工程上通过预编译和缓存复用，将 $T_{compile}$ 从用户请求的关键路径中移除。
  1. 首次开销$T_{first}$ 是第一次调用的总耗时，包含编译 $T_{compile}$ 和运行 $T_{run}$
    Tfirst=Tcompile+TrunT_{first} = T_{compile} + T_{run}
  2. 后续开销$T_{subsequent}$ 是缓存命中后的耗时，仅剩运行时间
    Tsubsequent=TrunT_{subsequent} = T_{run}
  3. 缓存命中率$r_{hit}$ 越高，平均调用耗时越接近 $T_{run}$
    E[T]=rhit⋅Trun+(1−rhit)⋅Tfirst\mathbb{E}[T] = r_{hit} \cdot T_{run} + (1 - r_{hit}) \cdot T_{first}

实际部署

把 torch.compile 用到生产环境，需要一套完整的“厨房验收标准”。首先明确应用场景：训练任务中，mode="default" 通常是性价比选择，因为训练本身耗时长，编译时间占比低；推理服务中，mode="max-autotune" 更合适，因为推理请求要求低延迟，一次编译永久复用。其次，fullgraph=True 配合结构规整的模型（如 BERT、GPT），可以保证整图优化收益；而 dynamic=True 只在输入长度变化频繁且 padding 成本高时才值得。

推理部署的另一个常见组合是 torch.compile 配合 TorchInductor 的 mode="reduce-overhead"——它通过 CUDA Graph 捕获减少内核启动的 CPU 开销。实测在某些 Transformer 推理场景下，吞吐可提升 1.5~2 倍。但注意，CUDA Graph 会占用额外显存做捕获，显存紧张时需要取舍。

餐厅的终极追求是：在顾客可接受等待时间内（延迟预算），尽可能多的桌台翻台（吞吐）。torch.compile 的选项配置，就是你对中央厨房的最终调校：选 max-autotune 提高翻台率，但前提是等待时间不能超出顾客红线。实际部署，本质是“在约束下做最优化”。

max⁡config∈C(Throughput(config))s.t.Latencyp99<Lbudget\max_{config \in \mathcal{C}} \left( Throughput(config) \right) \quad s.t. \quad Latency_{p99} < L_{budget}
公式描述生产环境配置的选择标准：满足 P99 延迟预算 $L_{budget}$ 的前提下，选择吞吐最高的编译配置。部署调优的终极目标是“在延迟红线内尽可能多接请求”。
  1. 配置集合$\mathcal{C}$ 是所有编译选项组合的配置空间
    config=(mode,fullgraph,dynamic,backend)config = (mode, fullgraph, dynamic, backend)
  2. 吞吐目标$Throughput(config)$ 是每秒处理的请求数，部署调优的目标函数
    Throughput=requestssecondThroughput = \frac{requests}{second}
  3. 延迟约束$Latency_{p99} < L_{budget}$ 表示 99% 的请求延迟必须低于业务预算
    P(L<Lbudget)>0.99P(L < L_{budget}) > 0.99

AI 应用场景

大模型推理服务加速

阶段：模型优化与部署

解决的问题：大语言模型（LLM）在线推理时，Eager 模式每次前向传播都要经过 Python 解释器逐算子分发，中间结果反复写回显存，导致 GPU 利用率低、延迟高。尤其在并发请求波动、输入长度不定的生产环境中，性能瓶颈尤为突出。

具体案例：某企业部署 BERT 语义理解服务，原始 Eager 模式 P99 延迟 45ms，最高并发仅 120 QPS。使用 torch.compile(mode="max-autotune", fullgraph=True) 配合固定序列长度 padding 后，P99 延迟降至 22ms，吞吐提升至 280 QPS，GPU 显存占用仅增加 15%。

训练加速与显存优化

阶段：模型训练

解决的问题：大模型训练中，反向传播包含大量逐元素算子（elementwise ops），每次都要启动独立的内核，GPU 算力大量浪费在内核调度上。

具体案例：某团队训练 GPT-2 规模模型时，使用 torch.compile(mode="default") 后训练吞吐提升 18%，且通过算子融合减少了中间张量的显存占用，使 batch size 得以上调 12%，进一步缩短了训练总时长。

动态形状场景的智能决策

阶段：模型服务

解决的问题：推荐系统等场景中，用户请求的 embedding 数量动态变化，输入形状不可预知。直接开启 dynamic=True 会损失静态形状的优化空间，但关闭后每次形状变化又会触发重新编译。

具体案例：某推荐排序服务对请求做长度分桶（如 32/64/128），为每个桶单独创建 torch.compile(dynamic=False) 的编译实例，兼顾了形状适应性与内核专用性，整体吞吐比单一 dynamic=True 高 23%。

Python 演示

python56 行
import torchimport torch.nn as nnimport time class SimpleMLP(nn.Module):    def __init__(self):        super().__init__()        self.fc1 = nn.Linear(512, 1024)        self.fc2 = nn.Linear(1024, 512)        self.act = nn.ReLU()     def forward(self, x):        return self.fc2(self.act(self.fc1(x)))  def benchmark(model, x, iterations=200):    # 预热：充分运行触发编译缓存    for _ in range(10):        model(x)    torch.cuda.synchronize()     start = time.perf_counter()    for _ in range(iterations):        # 保证每一步都被执行        model(x)    torch.cuda.synchronize()    end = time.perf_counter()     return (end - start) / iterations * 1000  def main():    device = torch.device("cuda" if torch.cuda.is_available() else "cpu")    x = torch.randn(64, 512, device=device)     eager_model = SimpleMLP().to(device)    comp_model = SimpleMLP().to(device)    max_model = SimpleMLP().to(device)     # 三种配置    compiled_default = torch.compile(comp_model, mode="default")    compiled_max = torch.compile(max_model, mode="max-autotune")     models = {        "eager": eager_model,        "compile_default": compiled_default,        "compile_max": compiled_max,    }     for name, model in models.items():        latency = benchmark(model, x)        print(f"{name:20s} 平均延迟: {latency:.3f} ms")  if __name__ == "__main__":    main()
目的：在相同硬件和数据下，对比 eager 模式与 torch.compile 两种 mode 配置的推理延迟，直观感受编译优化带来的加速效果。
  1. torch.compile(comp_model, mode="default")使用标准编译模式，权衡编译时间与运行性能
  2. torch.compile(max_model, mode="max-autotune")最激进优化，自动调优每个算子实现
  3. for _ in range(10): model(x)预热循环，让编译缓存生效，避免将编译时间混入基准测试
  4. torch.cuda.synchronize()同步 GPU，确保所有内核已执行完毕再计时
  5. (end - start) / iterations * 1000计算单次迭代的平均毫秒延迟

常见误区

误区“编译选项嘛，选最强的那个 `max-autotune` 准没错，反正都是加速。”

正解max-autotune 的编译时间可能是 default 的 10 倍以上（例如 BERT 模型从 10 秒增至 3 分钟），且部分算子自动调优后性能提升有限。在训练场景中，每次模型代码迭代都可能触发重编译，过长的编译时间反而降低总效率。如同总厨每次都花 3 小时熬高汤，但顾客只点了 5 分钟的蛋炒饭——投入产出严重失衡。

为何常见：人们习惯于“选最贵的一定最好”的直觉，忽略了编译时间在开发迭代成本中的占比。

误区“开启 `fullgraph=True` 更严格，应该能发现更多优化机会，模型也能正常跑。”

正解fullgraph=True 严格要求整个模型可用一份计算图表示。如果你的模型中含有依赖 Python 控制流（如 if 判断、数据相关的 for 循环）或调用了外部非张量库，编译器会直接报错。这如同要求总厨全程不许换人，但中间有个菜需要专业甜品师——他只能罢工。此时需用 fullgraph=False 允许图断裂，或重构模型为纯张量操作。

为何常见：初学者常把“更严格的编译选项”等同于“更强的优化”，忽略了图断裂在 Python 动态特性中的普遍存在。

误区“我的输入长度变化很大，开启 `dynamic=True` 后编译器应该自动优化每种形状。”

正解dynamic=True 生成的通用内核通常比静态形状的专用内核慢 5%~30%，且形状分桶策略可能不是最优的。工程上更常见的做法是主动 padding：将输入统一 pad 到固定长度的整数倍（如 128 的倍数），配合 dynamic=False，通常比 dynamic=True 更快。动态形状是“方便方案”而非“性能方案”。

为何常见：人们高估了自动化的能力，低估了领域知识（已知长度分布）在手动手工优化中的价值。

误区“调用一行 `torch.compile(model)` 就能让所有模型加速 50%，不用付出任何代价。”

正解torch.compile 的收益来源于“准备时间换运行时间”。它会增加首次调用延迟（编译）、增加显存占用（缓存与 CUDA Graph 捕获）、可能因图断裂导致优化不完整。且部分算子（如涉及动态控制流的自定义 op）编译后反而更慢。如同中央厨房需前期场地建设投入，建成前反而比路边摊更慢。

为何常见：宣传材料突出了加速效果，但对编译时间、显存开销等副作用略过不谈。

面试题

Q1. torch.compile 中 mode="max-autotune" 与 mode="default" 的核心区别是？

单选题 · easy

  • A.前者必须配合 CUDA 使用
  • B.前者会做自动算子调优← 正确答案
  • C.前者的编译时间更短
  • D.前者不支持 CPU 部署

答案：B。max-autotune 会对每个算子模板做自动调优（A/B 实测），选择最快的内核实现，因此编译时间更长、优化更强。B 正确；A、C、D 均是对两种模式的错误描述，两者都支持 CPU/GPU，且 max-autotune 编译时间更长而非更短。

Q2. 以下哪个参数用于控制 TorchDynamo 是否允许图断裂？

单选题 · easy

  • A.mode
  • B.backend
  • C.fullgraph← 正确答案
  • D.dynamic

答案：C。fullgraph=True 时 TorchDynamo 要求捕获完整计算图，一旦遇到无法编译的 Python 控制流立即报错，不允许图断裂。mode 控制优化强度，backend 控制代码生成器，dynamic 控制形状处理策略，均与图断裂无关。

Q3. 动态形状（dynamic=True）相比静态形状（dynamic=False）的性能特点是？

单选题 · mid

  • A.动态形状总是更快
  • B.静态形状内核更专用← 正确答案
  • C.动态形状编译时间更短
  • D.两者性能完全相同

答案：B。静态形状下编译器可将维度硬编码为常量、预分配精确显存、展开循环，生成的内核更专用、速度更快。动态形状是为变长输入提供方便，往往需牺牲 5%~30% 性能。B 正确。

Q4. torch.compile 的默认 backend 参数是？

单选题 · mid

  • A.eager
  • B.tvm
  • C.inductor← 正确答案
  • D.onnxrt

答案：C。PyTorch 2.0 默认使用 inductor 后端，它基于 Triton 语言生成高效的 GPU 内核。eager 是未编译的退化模式，tvm 和 onnxrt 是第三方可选后端，都不是默认值。

Q5. 使用 torch.compile 时，以下哪个现象是正常的？

单选题 · easy

  • A.每次调用模型都会触发重新编译
  • B.第一次调用时出现明显延迟← 正确答案
  • C.编译后模型精度必然下降
  • D.编译后显存占用必然减少

答案：B。首次调用时 TorchDynamo 需要捕获计算图并触发编译器生成内核，产生数秒的延迟属于正常现象。之后调用会使用缓存，不再编译。编译不改变数值计算逻辑（精度不变），显存占用通常增加而非减少。

Q6. 关于图断裂（graph break），以下说法正确的有？

多选题 · mid

  • A.图断裂会降低优化收益← 正确答案
  • B.图断裂可以在控制流处发生← 正确答案
  • C.fullgraph=True 可消除图断裂← 正确答案
  • D.图断裂不会产生性能开销

答案：ABC。图断裂将计算图切成多段，每段需独立启动内核、传输中间数据，必然产生性能开销（D 错误）。当模型含数据相关的 if/for 时会发生图断裂（B 正确）。fullgraph=True 通过“不允许编译通过”来从源头避免图断裂（C 正确），但代价是模型必须完全可编译（A 正确）。

Q7. 以下哪段代码能使 torch.compile 发挥最优推理性能？

单选题 · hard

  • A.torch.compile(model, mode="default")
  • B.torch.compile(model, mode="max-autotune", fullgraph=True)← 正确答案
  • C.torch.compile(model, mode="reduce-overhead")
  • D.torch.compile(model, dynamic=True)

答案：B。max-autotune 自动调优每个算子，fullgraph=True 强制整图编译消除断裂开销，两者组合通常在推理端达到最优性能（在模型可全图编译的前提下）。reduce-overhead 只针对 CPU/GPU 通信开销进行优化，dynamic=True 为形状变化而设计，均非性能最大化配置。

Q8. torch.compile 的缓存复用以什么为标识？

单选题 · easy

  • A.模型文件名
  • B.代码、配置与环境的哈希← 正确答案
  • C.输入数据内容
  • D.用户 ID

答案：B。缓存键由模型源码、编译选项、PyTorch 版本、GPU 类型等信息共同生成的哈希值决定。任何相关项变化都会导致缓存失效，重新编译。这与输入数据内容、文件名、用户无关。

Q9. 关于 torch.compile 在生产环境的部署，正确的实践有？

多选题 · hard

  • A.部署时进行预热编译← 正确答案
  • B.对变长输入做长度分桶← 正确答案
  • C.训练与推理使用相同 mode
  • D.关注 P99 延迟指标← 正确答案

答案：ABD。预热编译将编译时间从用户请求路径中移除（A 正确）；长度分桶在保持形状专用性的同时适配动态输入（B 正确）；生产部署的延迟指标以 P99 为代表（D 正确）。训练通常选 default 即可，推理选 max-autotune，两者策略不同（C 错误）。

Q10. inductor 后端生成 GPU 内核所使用的语言是？

单选题 · mid

  • A.CUDA C++
  • B.Triton← 正确答案
  • C.OpenCL
  • D.Python C API

答案：B。PyTorch 的 inductor 后端将优化后的计算图转换为 OpenAI 的 Triton 语言代码，再经 Triton 编译器编译为 GPU 内核。Triton 提供了比 CUDA 更高级的抽象（如 tile 级操作），使自动代码生成更加高效。