想象你走进一家生意红火的餐厅，领班小李站在前厅，一边观察客人点菜的节奏，一边用笔在小本子上画下“前菜→主菜→甜品”的上菜顺序。他画的可不只是菜单，而是一张完整的出餐流程单。但小李自己不下厨——他的工作是等流程单画好后，转交给后厨团队。餐厅里有多支后厨：自动化炒菜机能快速批量出餐，备菜师会提前把食材按需处理，外面还聘请了擅长特殊菜系的客座大厨。领班只需把流程单交给不同的团队，就能得到不同风格的美味佳肴。这个“把流程单交给哪支后厨团队”的机制，就是 TorchDynamo 的后端接入。 在 PyTorch 的编译器体系里，TorchDynamo 正是那位领班。它通过字节码分析捕获模型的计算过程，生成一张计算图（流程单），然后根据配置把图转交给某个“后端”编译器去优化和加速。默认的后端是 TorchInductor（自动化炒菜机），你也可以接入 AOTAutograd（备菜师）、XLA 甚至自己开发的后端（客座大厨）。理解这背后的接入机制，你就能像领班一样，为不同的业务场景灵活切换最合适的编译优化方案。

岗位关联

掌握 Dynamo 后端接入机制，是 AI 编译器工程师的核心能力之一。它让你能够为模型部署灵活定制编译优化方案，并针对不同硬件平台切换最优的加速后端，实现工业级的训练与推理性能。

目录
  1. 可视化演示
  2. 后端接入原理
  3. 内置后端体系
  4. 自定义后端开发
  5. 后端切换配置
  6. 优化加速效果
  7. 典型应用场景
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示TorchDynamo后端接入机制：Python图捕获生成计算图、Dynamo将图传递给不同编译后端、灵活后端切换实现定制化加速，通过交互理解Dynamo后端接入原理。

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

图捕获：Python代码到计算图 Dynamo追踪Python执行生成计算图 计算图捕获为后端编译做准备 Py → Graph → Backend Dynamo桥接Python与编译后端

后端接入原理

领班小李每天要接无数订单，但他从不动手炒菜——他把画好的流程单迅速地递给后厨。关键在于，后厨的接单口有一个固定的“交接窗口”：流程单放在那里，后厨拿走，然后出菜口回传成品。TorchDynamo 的后端接入机制，正是这样一套标准化的“交接窗口”。

Dynamo 先通过 Python 字节码级分析，在模型运行过程中捕获所有张量操作，把它们组合成一张计算图。这张图本身只是一个中间表示，真正让它跑起来的是后端。Dynamo 内部定义了一个统一的后端回调函数签名：后端接收 GraphModule 和示例输入 sample_inputs，经过内部处理后返回一个可调用的 Python 函数，这个函数就是最终执行优化后计算逻辑的入口。

后端接入的全流程可以概括为：Dynamo 捕获图 → 调用后端函数 → 后端编译/改写图 → 返回可执行对象 → 执行引擎调用它完成推理或训练。这个流程在设计上刻意保持简洁，目的是让第三方编译器（如 XLA、TensorRT）都能通过同一套接口“插”进 PyTorch，不需要修改 Dynamo 的核心代码。当然，编译不是免费的：首次调用时，Dynamo 需要先运行 Python 代码做图分析，后端还需要时间生成优化代码，这些开销统一记为编译时间。

理解了这套原理，你就明白了为什么领班要设计“交接窗口”——它保证了任何一种后厨团队都能顺利接入，让餐厅的运营方式足够灵活。同理，Dynamo 的后端回调机制保证任意一个编译器，只要能遵守接口约定，就能无缝地为 PyTorch 服务。

Ttotal(N)=Tcompile+N×TbaseST_{\text{total}}(N) = T_{\text{compile}} + N \times \frac{T_{\text{base}}}{S}
公式解读：总耗时 = 一次性编译开销 + 执行 N 次优化后计算的总时间。编译开销是固定成本，执行次数越多、加速比越大，后端接入的收益越明显。
  1. 总耗时函数 \(T_{\text{total}}(N)\)整体消耗时间与模型被调用的次数 \(N\) 相关。
    Ttotal(N)T_{\text{total}}(N)
  2. 编译成本 \(T_{\text{compile}}\)首次捕获计算图并交给后端编译的一次性开销，包括图分析和代码生成。
    TcompileT_{\text{compile}}
  3. 单次执行耗时 \(\frac{T_{\text{base}}}{S}\)基准模式（如 Eager）执行一次的时间，除以加速比 \(S\)，得到优化后的单次执行耗时。
    TbaseS\frac{T_{\text{base}}}{S}

内置后端体系

餐厅里通常有几支固定编制的后厨团队。第一支是自动化炒菜机 TorchInductor——它像一台精密的工业设备，拿到流程单后自动生成最优的烹饪程序（C++/Triton 代码），速度快、出品稳定，因此成为默认的“主力后厨”。第二支是备菜主管 AOTAutograd——他不等客人催菜，而是在订单进来前就准备好所有半成品（反向传播图），正餐时间一到，立刻出菜，这对训练任务尤其重要。

第三支是传统厨师团队 Eager——他们的手艺朴实无华，一道一道菜按部就班地做，永远不会出错。在 Dynamo 的后端体系里，Eager 扮演“保底回退”的角色：当计算图包含一些特殊算子，自动化后厨处理不了时，Dynamo 就退回 Eager 模式，保证程序照常运行。除了这三支主要队伍，餐厅还备有 CUDAGraphs 等辅助“厨具”，它们可以与其他团队搭档，在 GPU 上进一步减少调度开销。

TorchInductor 之所以能成为默认后端，得益于它对 GPU 和 CPU 的深度优化。它把计算图翻译成 Triton 和 C++ 代码，配合自动向量化和并行化策略，往往能达到接近手写 CUDA 的性能。而 AOTAutograd 的核心贡献在于：传统自动微分是在前向执行中“边做边记”，它却把反向图提前编译好，省去了运行时动态构建的成本。

这些内置后端各有分工，就像餐厅的固定编制团队各有所长。日常业务中，你只需要在配置里指定一个后端名字，Dynamo 就会自动把流程单交给对应的后厨。这也是为什么 TorchDynamo 的接入体验如此“轻”——你不需要写任何后端代码就能享受编译加速。

S=TeagerTinductorS = \frac{T_{\text{eager}}}{T_{\text{inductor}}}
公式解读：加速比 S 等于 Eager 模式（基准）的执行时间除以 Inductor 优化后的执行时间。S 越大，后端带来的性能提升越明显。
  1. 加速比 \(S\)衡量后端优化效果的指标，表示执行时间缩短了多少倍。
    SS
  2. 基准耗时 \(T_{\text{eager}}\)未接入后端、直接按 PyTorch 默认模式执行的总时间。
    TeagerT_{\text{eager}}
  3. 优化耗时 \(T_{\text{inductor}}\)使用 TorchInductor 后端编译后，执行同一模型所需的时间。
    TinductorT_{\text{inductor}}

自定义后端开发

如果餐厅还想请一支客座厨师团队，领班只需要跟对方约定两件事：流程单按什么格式交接？菜做好后从哪个窗口送出？Dynamo 的自定义后端开发，本质也是这两件事：定义函数签名、约定返回值。

一个自定义后端的函数签名是固定的：它接收 GraphModule（Dynamo 捕获的计算图）和 sample_inputs（一组示例输入，用于后端做形状推导和调优），然后返回一个可调用对象。这个可调用对象可以是经过改写后的 GraphModule.forward，也可以是外部编译器（如 XLA、TensorRT）生成的可执行句柄。Dynamo 不关心后端内部用什么技术，只要最终“出菜窗口”送回一个能跑的函数即可。

开发流程通常包含四个步骤：一是设计后端入口函数；二是在函数内对计算图进行分析、改写或翻译；三是通过 torch._dynamo.register_backend 把函数注册为一个具名后端；四是使用 torch.compile(model, backend="my_backend") 调用它。更便捷的是，你还可以用 @register_backend("my_backend") 装饰器直接挂载函数，省去一行显式注册代码。

自定义后端把“编译优化”这件事真正地开放给了社区。无论是把图翻译成 XLA HLO、导出成 ONNX，还是交给自研的 AI 芯片编译器，你都可以用这套接口优雅地接入。就像餐厅请客座大厨，只要遵守交接约定，领班就放心把流程单交出去，让专业的人做专业的事。

run=fbackend(Gmodel,Isample)\text{run} = f_{\text{backend}}(G_{\text{model}}, I_{\text{sample}})
公式解读：后端函数 \(f_{\text{backend}}\) 接收模型计算图 \(G_{\text{model}}\) 和示例输入 \(I_{\text{sample}}\)，输出一个可执行对象 \(\text{run}\)。这个对象是图优化后的最终执行入口。
  1. 可执行对象 \(\text{run}\)后端返回的最终调用入口，之后每次前向都执行它。
    run\text{run}
  2. 后端处理函数 \(f_{\text{backend}}\)开发者定义的自定义编译逻辑，可以是图重写器、代码生成器或外部编译器封装。
    fbackendf_{\text{backend}}
  3. 模型计算图 \(G_{\text{model}}\)Dynamo 捕获到的 GraphModule，包含算子节点、参数和拓扑结构。
    GmodelG_{\text{model}}
  4. 示例输入 \(I_{\text{sample}}\)采样自真实数据的一小批输入，帮助后端完成形状推断、布局选择等优化。
    IsampleI_{\text{sample}}

后端切换配置

餐厅里每天有不同档次的客人：有赶时间的白领，有追求仪式感的家庭聚餐，也有讲求性价比的大团餐。领班小李会根据客人的需求，在点单系统上按下一个按钮，切换不同后厨团队。Dynamo 的后端切换，同样提供了多样化的“按钮”供开发者选择。

最直观的切换方式是 backend 参数。调用 torch.compile(model, backend="inductor") 时，你直接把后端名传给编译接口。这种方式适合在代码中显式声明，逻辑清晰、可读性好。如果你希望全局生效，不想改代码，可以设置环境变量 TORCHDYNAMO_BACKEND=inductor，运行环境中的所有编译调用都会自动使用该后端，方便做部署配置。对于更复杂的场景，Dynamo 还支持在运行时根据条件动态决定后端，例如当检测到输入规模较大时选择 Inductor，输入较小时退回 Eager。

切换后端时，一个实用的辅助手段是调试诊断工具。torch._dynamo.config 提供了一系列开关，可以输出编译日志、打印捕获到的图结构，帮助你确认后端是否被正确调用、计算图是否被意外切分（graph break）。当性能表现不符合预期时，这些工具能帮你快速定位是后端选型问题，还是图捕获阶段存在瓶颈。

后端切换给了开发者极大的战术自由度——同一份模型，在开发环境用 Eager 方便调试，在训练集群用 AOTAutograd 加速反向，在线上推理用 Inductor 追求极致吞吐。这一切都像领班拨动开关一样简单，而 Dynamo 在背后默默处理了后端调用的所有细节。

B∗=arg⁡max⁡B∈BSpeedup(B)B^* = \arg\max_{B \in \mathbb{B}} \text{Speedup}(B)
公式解读：后端切换的本质目标是，在所有可选后端集合 \(\mathbb{B}\) 中，挑选出加速比最高的那个后端。实际工程中还要综合考虑编译时间、显存开销等约束。
  1. 最优后端 \(B^*\)当前场景下最合适的后端选择结果。
    B∗B^*
  2. 后端候选集 \(\mathbb{B}\)所有已注册可用的后端集合，包括内置与自定义。
    B\mathbb{B}
  3. 最大化加速比 \(\arg\max \text{Speedup}(B)\)遍历候选后端，找到使加速比最大的对象。
    arg⁡max⁡B∈BSpeedup(B)\arg\max_{B \in \mathbb{B}} \text{Speedup}(B)

优化加速效果

客座大厨擅长很多不外传的烹饪技巧：把“焯水”“爆炒”“勾芡”三道工序合并成一步完成，把原本要洗三次锅的流程省成一次，这就是“算子融合”。自动化炒菜机 TorchInductor 拿到计算图后，最核心的优化手段之一正是算子融合——把多个相邻算子合并成一个内核（Kernel）执行，减少 GPU 内核启动次数和中间数据的内存读写。

代码生成是另一个重要加速来源。TorchInductor 会针对目标硬件（如 NVIDIA GPU）生成专门的 Triton/C++ 代码，在循环展开、向量化加载、缓存利用等层面精细调优。它生成的代码往往能比 PyTorch 原始的通用实现快数倍。此外，后端还会执行自动调优（Autotune）：对关键算子的各种实现（不同 tile 大小、不同线程配置）做基准测试，选出当前硬件上最快的那一版。

这些优化手段最终汇聚成部署层面的显著收益。算子融合后，原来几十个小内核变成几个大内核，调度开销大幅下降；代码生成保证了生成的指令紧贴硬件特性；自动调优则在每次编译时为模型“量身定制”最优参数。综合下来，常见的视觉和语言模型在 Inductor 后端下，端到端性能通常可以提升 1.5 到 3 倍。

这些优化手段好比后厨团队的精湛工艺，每道工序的合并与精简都直接改变了出菜速度。对接了后端的模型，在实际部署中的性能提升是实实在在的——不是靠“感觉变快”，而是靠吞吐量和延迟等硬指标来衡量。

Tfused≈max⁡(Ti)≪∑i=1nTiT_{\text{fused}} \approx \max(T_i) \ll \sum_{i=1}^{n} T_i
公式解读：融合后的执行时间大约等于最慢的那个算子耗时，而不是所有算子耗时之和。这就是算子融合“化零为整”的威力。
  1. 融合后耗时 \(T_{\text{fused}}\)多个算子合并成一个内核后的总执行时间。
    TfusedT_{\text{fused}}
  2. 单个算子耗时 \(T_i\)第 \(i\) 个算子独立执行需要的时间。
    TiT_i
  3. 最慢算子 \(\max(T_i)\)融合后各算子的计算在统一内核中完成，整体耗时被最慢的算子主导。
    max⁡(Ti)\max(T_i)
  4. 串行总和 \(\sum T_i\)未融合时所有算子依次执行的总时间，融合后的耗时远小于它。
    ∑i=1nTi\sum_{i=1}^{n} T_i

典型应用场景

不同的餐厅场景需要不同的后厨策略，Dynamo 后端接入在真实业务中同样百花齐放。最经典的场景是 XLA 后端接入：XLA（Accelerated Linear Algebra）是 TensorFlow/TPU 生态的编译器，通过 Dynamo 的开放后端接口，PyTorch 模型可以把计算图交给 XLA，在 Google Cloud TPU 上高效运行，实现跨生态的硬件复用。

第二个典型场景是训练加速。在大规模训练任务中，每个 step 都要做前向和反向计算。AOTAutograd 后端在第一步就预编译好反向图，之后每个 step 直接执行编译后的精确计划，省去了逐步构建动态图的运行时开销。配合 Inductor 对前向图的优化，训练吞吐可以提升 20% 到 40%，这对动辄几万 step 的预训练任务意味着巨大的时间节省。

第三个场景是推理服务优化。在线搜索、推荐和对话系统对延迟极其敏感。通过在部署阶段接入 TorchInductor 或 CUDAGraphs 后端，服务端把请求处理时间从原来的几十毫秒压缩到个位数毫秒，p99 延迟持续稳定。更有工程团队根据自身业务算子的特殊性开发定制后端，例如把图翻译成自家 NPU 的指令集，这类定制化方案在自动驾驶和安防领域尤为常见。

后端接入让 AI 工程师的“兵器库”变得极其丰富：你可以为训练选备菜师（AOTAutograd），为在线推理选自动化炒菜机（Inductor），为特殊硬件请客座大厨（自定义后端）。这套机制把编译优化的选择权真正交到了开发者手中，让“为场景定制加速”从一个美好的愿望变成随手可用的工程能力。

Ltotal=Lpre+Lcompile+LinferL_{\text{total}} = L_{\text{pre}} + L_{\text{compile}} + L_{\text{infer}}
公式解读：一个模型请求的端到端延迟由预处理、编译（若首次调用）、推理执行三部分构成。后端接入主要压缩 \(L_{\text{infer}}\)，并可能引入一次性的 \(L_{\text{compile}}\)。
  1. 端到端延迟 \(L_{\text{total}}\)从请求进入系统到返回结果的完整时间。
    LtotalL_{\text{total}}
  2. 预处理耗时 \(L_{\text{pre}}\)数据清洗、打包、搬运到设备等前置操作。
    LpreL_{\text{pre}}
  3. 编译耗时 \(L_{\text{compile}}\)首次调用时 Dynamo 和后端的编译开销，可通过缓存消除。
    LcompileL_{\text{compile}}
  4. 推理耗时 \(L_{\text{infer}}\)模型计算本身的时间，是后端优化的主战场。
    LinferL_{\text{infer}}

AI 应用场景

大模型在线推理服务加速

阶段：模型部署与推理优化

解决的问题：传统 PyTorch Eager 模式在 GPU 上执行 Transformer 模型时，每个算子独立启动内核，调度开销大、GPU 利用率低，且反复读写中间张量拖慢整体延迟。Dynamo 接入 TorchInductor 后端后，计算图先被捕获为静态图，再融合算子、生成 Triton 内核，推理时只需一次图执行即可完成全部计算。

具体案例：某电商平台的推荐排序模型，每天服务超 1 亿次请求。原先进程使用默认 PyTorch 推理，P99 延迟约 45ms；接入 torch.compile(model, backend="inductor") 后，算子融合减少了 60% 的内核启动，加上 Triton 代码生成适配 A100 架构，P99 延迟降到 22ms，吞吐提升 2.1 倍，GPU 峰值显存占用下降 30%。

自定义算子接入专用编译器

阶段：模型定制化编译与算子开发

解决的问题：工业界模型常包含自研算子（如高效稀疏注意力、动态路由等），PyTorch 官方后端无法对这些算子做深度优化。Dynamo 的后端接入接口允许团队封装自研编译器，将包含特殊算子的计算图完整接管，实现在特定硬件上的极致性能。

具体案例：一家自动驾驶公司开发了基于 Radar 点云的自研稀疏卷积算子。团队实现了一个自定义后端，接收 Dynamo 捕获的 GraphModule 后，将稀疏卷积子图翻译为 TensorRT 插件，其余子图交给 Inductor。接入后，整个感知模型在车规级 Orin 平台上的推理耗时从 72ms 降至 38ms，满足了实时性要求。

大规模训练吞吐提升

阶段：训练流程优化

解决的问题：大规模预训练模型中，每次迭代都动态构建反向图，带来显著的 Python 开销。Dynamo 接入 AOTAutograd 后端后，反向传播图在编译阶段一次性生成并优化，训练循环中直接执行编译后的函数。

具体案例：某实验室训练 13B 参数的语言模型，原生 PyTorch 每 step 耗时 1.8 秒。使用 torch.compile(model, backend="aot_autograd") 配置后，前向算子被 Inductor 融合，反向图被 AOT 预编译，每 step 耗时降为 1.2 秒，整体训练时间缩短 33%，千卡集群每周节省电费开支数万元。

Python 演示

python46 行
# 演示如何为 TorchDynamo 实现一个自定义后端import torchfrom torch._dynamo import register_backend  def my_custom_backend(gm, sample_inputs):    """自定义后端: 分析计算图, 打印算子统计, 返回原始 forward"""    print("=== 自定义后端开始处理计算图 ===")    op_count = {}    for node in gm.graph.nodes:        if node.op == "call_function":            op_name = node.target.__name__            op_count[op_name] = op_count.get(op_name, 0) + 1    print("算子统计:", op_count)    print("图中节点总数:", len(gm.graph.nodes))    print("=== 后端处理完成, 返回可执行函数 ===")    return gm.forward  register_backend("my_custom_backend", my_custom_backend)  class SimpleNet(torch.nn.Module):    def __init__(self):        super().__init__()        self.fc1 = torch.nn.Linear(4, 8)        self.relu = torch.nn.ReLU()        self.fc2 = torch.nn.Linear(8, 2)     def forward(self, x):        x = self.fc1(x)        x = self.relu(x)        return self.fc2(x)  def demo():    model = SimpleNet().eval()    x = torch.randn(4, 4)    compiled = torch.compile(model, backend="my_custom_backend")    with torch.no_grad():        out = compiled(x)    print("输出形状:", out.shape)  if __name__ == "__main__":    demo()
目的：实现一个完整的 Dynamo 自定义后端，注册后在 torch.compile 中指定使用，观察后端如何接收计算图、分析算子并返回可执行函数。
  1. def my_custom_backend(gm, sample_inputs):后端函数固定签名，接收 GraphModule 和示例输入
  2. for node in gm.graph.nodes:遍历计算图中的所有节点，识别算子类型
  3. op_count[op_name] = op_count.get(op_name, 0) + 1统计每类算子的调用次数
  4. register_backend("my_custom_backend", my_custom_backend)把函数注册为具名后端，供 torch.compile 直接引用
  5. torch.compile(model, backend="my_custom_backend")编译模型时显式指定自定义后端
  6. compiled(x)真正执行时调用的是后端返回的 gm.forward，而不是原始模型

常见误区

误区我听说 PyTorch 2.0 的 torch.compile 默认用 TorchInductor，就以为Dynamo只有一个后端，想换别的编译器也没办法。

正解Dynamo 的后端接入是高度开放的。官方内置了 TorchInductor、AOTAutograd、Eager、CUDAGraphs 等多种选择，同时提供了 register_backend 接口，允许 XLA、TensorRT、ONNX Runtime 乃至自研编译器快速接入。默认用 Inductor 只是因为它在大多数场景下表现最好，绝不意味着“没有别的选择”。

为何常见：PyTorch 官方文档和演讲都以 Inductor 作为案例展示，用户接触到的第一个后端就是它，容易形成“唯一的”错觉。

误区我觉得后端就是被动地“看一下”Dynamo 传来的图，处理完就结束了，不用返回任何值，Dynamo 会自己继续执行。

正解后端函数必须返回一个可调用对象（Callable）。Dynamo 捕获图、调用后端，只是“接力”的第一步；真正执行计算的是后端返回的那个函数。如果后端没有返回值，Dynamo 会在后续执行时报 TypeError。可以这样理解：领班把流程单交给后厨，后厨必须回传一份做好的菜，而不是只接单不干活。

为何常见：初学者容易把“后端注册”理解成发布订阅模式，以为回调完就完事了，忽略了编译器中“后端必须接管执行”这一关键语义。

误区用了 torch.compile 后，不管什么模型都应该变快，怎么我跑一个小模型反而变慢了呢？是不是我写错了？

正解编译有一次性开销：Dynamo 需要做字节码分析和图捕获，后端需要生成优化代码。如果模型的单次执行本来就很快（如几十微秒），而编译耗时高达几秒，那么总耗时反而增加。判断收益时要看公式 \(T_{\text{total}} = T_{\text{compile}} + N \times T_{\text{base}} / S\)：N（执行次数）越大、S（加速比）越高，编译开销才越能被摊薄。小模型或一次性推理任务，编译可能得不偿失。

为何常见：官方性能评测报告通常展示运行成百上千次后的平均收益，掩盖了首次编译的巨大开销，用户容易被“加速 2 倍”的结论误导。

误区我注册了自己的后端，每次运行推理时都要执行整个编译流程，那用它还不如自己手写一个优化器方便。

正解Dynamo 内置了编译缓存机制。相同的图结构、相同的输入形状和配置，在第一次编译后会被缓存，后续调用直接命中缓存，不会重复进入后端函数。只有当图结构或配置发生变化时，才会触发新的编译。这与餐厅后厨备菜的道理一样——同样的菜式做过一次，下一次直接按已确定的流程出菜，不需要重新研究菜谱。

为何常见：调试时，开发者看到后端函数中的 print 日志只打印了一次，却看到程序又执行了多次，于是误以为编译没有重复；但看到日志消失又以为没调用后端，概念混淆导致“重复编译”的错觉。

面试题

Q1. TorchDynamo 的核心功能是什么？

单选题 · easy

  • A.自动计算梯度
  • B.捕获编译计算图← 正确答案
  • C.管理 GPU 显存
  • D.序列化模型权重

答案：B。TorchDynamo 是一个编译器前端，核心职责是在 Python 运行时捕获模型的计算图并交给后端编译。自动求导由 Autograd 引擎负责，显存管理是 CUDA Runtime 的职责，权重序列化是 torch.save 的功能，均与 Dynamo 无直接关系。

Q2. Dynamo 后端接口的输入参数是什么？

单选题 · mid

  • A.张量与标量数组
  • B.计算图与示例输入← 正确答案
  • C.模型文件路径数组
  • D.字节码指令序列

答案：B。后端接口统一接收两个参数：GraphModule（Dynamo 捕获到的计算图）和 sample_inputs（示例输入）。张量数据是用户层面的概念，模型文件路径不是回调参数，字节码是 Dynamo 内部输入而非给后端的输入。

Q3. 以下哪些属于 Dynamo 的内置后端？

多选题 · mid

  • A.TorchInductor 后端← 正确答案
  • B.AOTAutograd 后端← 正确答案
  • C.Eager 回退后端← 正确答案
  • D.XLA 编译加速器

答案：ABC。TorchInductor、AOTAutograd、Eager 都是 PyTorch 官方内置的后端选项。XLA 虽然可以通过后端接口接入，但它属于谷歌生态的编译器，不是 Dynamo 的默认内置后端，需要额外安装插件后才能使用。

Q4. 自定义后端函数必须返回什么？

单选题 · mid

  • A.新的计算图对象
  • B.可调用函数对象← 正确答案
  • C.损失值标量对象
  • D.优化器配置字典

答案：B。后端函数必须返回一个可调用对象（Callable），这是 Dynamo 约定好的“出菜口”。返回的计算图对象不能直接执行，损失值是训练循环才有的概念，优化器配置则与编译加速完全无关。

Q5. Dynamo 默认使用的后端是？

单选题 · easy

  • A.TorchInductor 后端← 正确答案
  • B.AOTAutograd 后端
  • C.Eager 执行后端
  • D.NvFuser 编译器

答案：A。PyTorch 2.0 起，torch.compile 的默认后端就是 TorchInductor，它能为 GPU/CPU 生成高度优化的 Triton/C++ 代码。AOTAutograd 常用于训练加速，Eager 是保底回退，NvFuser 曾是早期实验性方案。

Q6. 后端切换的正确调用方式是？

单选题 · mid

  • A.调用 compile 方法配置← 正确答案
  • B.切换训练模式配置
  • C.关闭梯度追踪功能
  • D.执行优化器更新

答案：A。torch.compile(model, backend="xxx") 是切换后端的标准方式。切换训练/评估模式（model.eval()）只影响 dropout 等层的状态，关闭梯度追踪（torch.no_grad()）只是省去自动求导开销，优化器更新（optimizer.step()）是训练参数更新步骤，都不涉及后端选择。

Q7. 后端接入可以带来哪些优化收益？

多选题 · hard

  • A.计算图算子融合← 正确答案
  • B.自动生成 GPU 内核代码← 正确答案
  • C.自动搜索最优编译参数← 正确答案
  • D.自动调整模型学习率

答案：ABC。算子融合减少内核调度和内存读写，代码生成让计算指令贴合硬件特性，自动调优为关键算子挑选最优实现。学习率调整属于训练超参数策略，与编译器后端无关。

Q8. 关于 Dynamo 的 graph break，以下说法正确的是？

单选题 · hard

  • A.导致后端完全失效
  • B.计算图被切分为多个子图← 正确答案
  • C.后端只需处理第一个子图
  • D.图执行时自动跳过断点

答案：B。当 Dynamo 遇到无法追踪的 Python 控制流或第三方算子时，会将计算图在断点处切分成多个子图，每个子图独立交给后端编译。后端会对每个子图都做处理，而不是只处理第一个；graph break 也不是让执行跳过某些节点。

Q9. 自定义后端返回的函数被调用时，不应做哪件事？

单选题 · extreme

  • A.复用 CUDA 图捕获结果
  • B.每次调用重新编译计算图← 正确答案
  • C.调用预编译的运行时库
  • D.使用预编译产物执行推理

答案：B。后端返回的函数是高频调用路径，每次调用都重新编译会让性能退化到不可接受的程度。正确的做法是复用编译产物——CUDA 图结果、预编译运行时库或 AOT 产物都行。就像后厨不会每炒一道菜都重新发明一次做法。

Q10. Dynamo 后端接入的本质是什么？

单选题 · easy

  • A.将模型权重替换成随机数
  • B.图交给后端编译器优化执行← 正确答案
  • C.用 C++ 重写整个模型文件
  • D.压缩模型磁盘上的文件体积

答案：B。后端接入的本质是：Dynamo 把捕获到的计算图“外包”给专用编译器后，模型以优化后的形态执行。它不改变模型权重，不需要用 C++ 重写模型，也不做磁盘体积压缩。