想象一家高档餐厅，客人还没进门，总厨就已经把今晚每一桌的菜单、每道菜的做法、每口锅的流转顺序都写进了同一张值班表。做菜叫“前向”，收盘洗锅叫“反向”，客人点一道菜就要经历一次完整的“做菜—洗盘”。如果每来一桌客人都临时翻菜谱、临时派工、用完锅再想下一道，后厨一定会乱成一团。AOTAutograd 就是那位总厨——它在真正的训练开始前，把神经网络每一次的“前向计算”和“反向求导”提前编排成一张完整的联合计划表，让后面的编译器和硬件能照着这张表高效运转。 这套思想正是 PyTorch 2.0 中 torch.compile 的引擎核心：先用 Dynamo 把失控的 Python 代码“翻译”成标准图，再由 AOTAutograd 把前向与反向焊成一张联合图，最后交给 Inductor 或 XLA 等后端编译成高效代码。理解 AOTAutograd，就等于拿到了读懂现代 AI 训练加速的第一把钥匙。

岗位关联

对 AI 从业者而言，掌握 AOTAutograd 意味着你能真正读懂 torch.compile 的性能从哪里来、图为什么会被切分、显存为什么变省，并能精准定位训练与推理中的编译相关问题，这是进入大模型与推理优化领域的必修课。

目录
  1. 可视化演示
  2. 基础概念：餐厅开门前的总策划
  3. 图捕获前端：把菜谱变成标准清单
  4. 联合正反向图：出菜与洗盘一气呵成
  5. 分区与回退：标准流程与手工活分流
  6. 后端代码生成：流水线里的高效设备
  7. 性能优化策略：复用锅具与缓存菜谱
  8. XLA工程实践：同一份清单、不同的厨房
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示AOTAutograd编译栈：前向FX图捕获→分解→反向图推导→算子融合，训练双图与推理forward-only模式对比，及最小割重计算的内存优化。

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

AOTAutograd图捕获 FWD前向FX图→DEC分解与函数化预处理 BWD由前向图推导反向图→FUS算子融合 Graph_fwd→Graph_bwd→Kernel 编译期确定前后向图，运行期避免逐算子上抛。

基础概念：餐厅开门前的总策划

总厨在餐厅开门前要做的事，和 AOTAutograd 在训练开始前要做的事几乎一模一样。普通餐厅的运作方式是：客人点菜，厨师立刻看菜谱、备料、开火，菜出锅后交给服务员，然后才想起要洗锅。PyTorch 默认的 eager 模式就像这样——每一步计算都是“说走就走”，前向算完再临时构建反向图，每一次迭代都重复这套流程，大量时间浪费在“临时找路”上。

AOTAutograd 里的 AOT 是 Ahead-Of-Time，即“提前”。它要提前做两件事：一是把前向计算完整梳理出来，二是把反向求导的路径也一并画好。在深度学习中，所谓反向求导本质上是用链式法则计算损失对每个参数的梯度。把“做菜”类比成前向传播，“收盘洗锅”就是反向传播——洗锅时要知道刚才每口锅装过什么菜，才能决定怎么洗。链式法则正是这条“洗碗路线图”。

AOTAutograd 的职责，就是在还没真正“开火”之前，把这条链全画出来。总厨不必等客人催菜才去想要先炒哪道，他早已在值班表上排好了顺序。

∂L∂x=∂L∂y×∂y∂x\displaystyle \frac{\partial L}{\partial x} = \frac{\partial L}{\partial y} \times \frac{\partial y}{\partial x}
这个公式说明：损失对输入的梯度，等于损失对输出的梯度乘以输出对输入的梯度。“做菜”越复杂，这条“洗碗链”就越长，提前规划的价值就越大。
  1. 损失对输出的导数先计算损失函数 $L$ 对网络输出 $y$ 的敏感程度，这是反向传播的起点。
    ∂L∂y\displaystyle \frac{\partial L}{\partial y}
  2. 输出对输入的导数再计算网络输出 $y$ 对某个输入 $x$ 的敏感程度，即局部变化率。
    ∂y∂x\displaystyle \frac{\partial y}{\partial x}
  3. 两者相乘把两个局部变化率乘起来，就得到损失对更早层输入的梯度。
    ∂L∂y×∂y∂x\displaystyle \frac{\partial L}{\partial y} \times \frac{\partial y}{\partial x}
  4. 逐层向前回溯从输出层开始，依次把这条乘法链传回每一层，直到输入层。

图捕获前端：把菜谱变成标准清单

总厨再厉害，也得先看懂各家的菜谱。PyTorch 的模型是用 Python 写出来的，Python 太灵活——循环、条件、动态张量形状都可能出现。直接让编译器面对 Python 源码，就像让新来的配菜工面对十本手写菜谱，字迹不同、格式各异，根本没法统一备料。于是 torch.compile 的第一个组件 Dynamo 登场了：它像一个细心的“菜单分析员”，在函数被执行时观察每一步操作，把实际发生的张量运算“捕获”下来。

捕获到的内容会被整理成一张 FX 图（FX Graph）。这是一张标准化的有向无环图：节点是算子，边是张量流动方向。相当于把十本手写菜谱统一成了一张印刷体配料表——葱姜蒜各多少克、先放油还是先放盐，全部清清楚楚。Dynamo 和 FX 的产物，正是 AOTAutograd 的输入。

有了这张标准清单，AOTAutograd 就可以像总厨拿到统一配料表一样，从容地研究“哪些菜能一起炒、哪口锅能复用”了。

G=(V,E),E={(u,v)∣u,v∈V}\displaystyle \mathcal{G} = (V, E),\quad E = \{(u, v) \mid u, v \in V\}
计算图就是一坨节点和一堆有向边：节点代表算子，边代表张量从哪个算子流向哪个算子。
  1. 节点集合$V$ 是所有算子的集合，比如一个矩阵乘法、一次 ReLU 激活。
    V={v1,v2,…,vn}\displaystyle V = \{v_1, v_2, \ldots, v_n\}
  2. 边集合$E$ 是记录张量流动方向的边的集合，每条边由起点和终点唯一确定。
    E={(u,v)∣u,v∈V}\displaystyle E = \{(u, v) \mid u, v \in V\}
  3. 有向无环约束数据只能从前往后流，不能绕圈，否则梯度便永远算不完。

联合正反向图：出菜与洗盘一气呵成

以前的编译器优化往往只盯前向：把一堆线性层、激活函数融合成更高效的内核，但反向传播仍然像另一个世界，单独重新算一遍。AOTAutograd 最重要的贡献，是生成了联合正反向图（joint graph）——把前向算子与反向算子放进同一张图里，统一优化。

这就像总厨不再把“做菜”和“洗盘”当成两套排班，而是编在同一张值班表上：师傅炒完这道菜，锅需要立刻交给洗碗工，洗碗工洗完后锅又马上回到灶台做下一道菜。前向的中间激活值（比如某个矩阵乘法的输出）对反向求导是必需食材，如果分别优化，就得把这份食材单独冷藏保存；而联合图让反向步骤直接在前向算子的“锅边”取用，省去了大量搬运和重新计算。

把前向和反向焊接在一起之后，编译器可以看清整条“做菜—洗盘—再做菜”的循环路径，从而做出更聪明的全局决策。

J(x,v)=(f(x),  ∇f(x)⋅v)\displaystyle \mathcal{J}(x, v) = \left( f(x),\; \nabla f(x) \cdot v \right)
联合图表达的是：给定输入 $x$ 和一个“伴随向量” $v$，同时产出前向结果 $f(x)$ 和反向结果 $\nabla f(x) \cdot v$。这就是总厨手里的“一张表干两件事”。
  1. 输入张量$x$ 是流入网络的输入数据，比如一张图片或一组特征。
    x∈Rd\displaystyle x \in \mathbb{R}^{d}
  2. 前向输出$f(x)$ 是网络对输入 $x$ 的预测结果，可以是一组 logits。
    y=f(x)\displaystyle y = f(x)
  3. 伴随向量$v$ 是反向传播开始时从损失方向传来的梯度向量，通常是 $\frac{\partial L}{\partial y}$。
    v=∂L∂y\displaystyle v = \frac{\partial L}{\partial y}
  4. 反向输出$\nabla f(x) \cdot v$ 表示把伴随向量沿着计算图反向传回，得到对 $x$ 的梯度。

分区与回退：标准流程与手工活分流

任何后厨都会遇到没法标准化的菜：有的客人要求“少油”、有的食材必须现杀现片。神经网络里也有类似情况——有些算子是动态的、依赖数据内容甚至 Python 控制流，无法被静态编译。总厨此时不会让整个厨房停工，而是做个分区决策：能批量生产的菜进入中央厨房流水线，必须手工处理的菜留在小灶上现做。

AOTAutograd 的分区器就扮演这个决策者。它使用最小割（MinCut）算法，把联合图切成几块子图：能编译的整段交给后端编译器，不能编译的片段保留为 Eager 模式执行。分区器的目标不是让出“手工区”，而是让“流水线区”尽可能大——把绝大多数前向、反向算子都包进可编译子图，只在必要处切开。

切完之后，AOTAutograd 会把“可编译子图”交给后端编译器，把“手工子图”留回 Eager。对使用者来说，整个模型依然照常运行，只是内部已经被悄悄地分成了流水线区和小灶区。

min⁡S⊆V∑e∈δ(S)w(e)\displaystyle \min_{S \subseteq V} \sum_{e \in \delta(S)} w(e)
最小割的目标是：找一个节点子集 $S$，让“被切断的边”的总权重最小。对应到图分区，就是尽量少切关键的张量流动边，让每一块子图都尽量“有肉”。
  1. 候选分区$S$ 是图中的一个节点子集，可以理解为被划进“可编译区”的那批算子。
    S⊆V\displaystyle S \subseteq V
  2. 被切断的边$\delta(S)$ 表示横跨 $S$ 内外两个集合之间、被一刀切开的边的集合。
    δ(S)={(u,v)∈E∣u∈S,v∉S}\displaystyle \delta(S) = \{ (u, v) \in E \mid u \in S, v \notin S \}
  3. 权重求和$w(e)$ 是每条边的权重，通常和张量大小或通信代价有关，目标是最小化总切断代价。
    ∑e∈δ(S)w(e)\displaystyle \sum_{e \in \delta(S)} w(e)
  4. 取最小值在所有可能的分区方式中选代价最小的那一种。

后端代码生成：流水线里的高效设备

分区确定后，真正“干活”的设备上场了。PyTorch 默认的后端叫 Inductor，它接收 AOTAutograd 产出的可编译子图，生成面向 GPU 或 CPU 的高效代码。在 GPU 上，它通常产出 Triton 内核；在 CPU 上，则产出向量化的 C++ 代码。

后厨流水线里最怕什么？怕每做一道菜都要重新生火、重新架锅。GPU 编程也有类似的成本：每个内核（kernel）被启动一次都有固定开销，数据还要反复在显存与寄存器之间搬运。Inductor 的一大绝活是内核融合（kernel fusion）：把连续多个算子合并成一个内核一次跑完。比如“矩阵乘法 + 偏置相加 + ReLU 激活”通常可以融合成一个算子，就像“切好的肉丝直接下锅炒熟盛出”，中间不把半成品端出厨房。

Inductor 之所以能放心大胆地融合，正是因为 AOTAutograd 已经把前向和反向都摆在了同一张图里。总厨提前排好了值班表，设备工程师才能设计出真正高效的流水线。

Teager=∑i=1mti,Tfused≤Teager\displaystyle T_{\text{eager}} = \sum_{i=1}^{m} t_i, \qquad T_{\text{fused}} \le T_{\text{eager}}
如果把多个算子分开跑，总耗时是各个内核耗时之和；融合成一个大内核后，总耗时往往小于这个和，因为省去了重复启动和数据搬运。
  1. 逐个执行总耗时$t_i$ 是第 $i$ 个算子单独运行的内核耗时，把所有 $m$ 个算子加起来，就是 Eager 模式的总耗时。
    Teager=∑i=1mti\displaystyle T_{\text{eager}} = \sum_{i=1}^{m} t_i
  2. 融合后的耗时$T_{\text{fused}}$ 表示把这些算子合并成一个大内核后的总耗时。
    Tfused≤Teager\displaystyle T_{\text{fused}} \le T_{\text{eager}}
  3. 加速比两者相除得到融合加速倍数，数值越大说明“合并炒菜”越划算。
    Speedup=TeagerTfused\displaystyle \text{Speedup} = \frac{T_{\text{eager}}}{T_{\text{fused}}}

性能优化策略：复用锅具与缓存菜谱

AOTAutograd 带来的性能提升，还有两个隐藏武器：内存规划与编译缓存。先看内存规划。训练神经网络时，前向计算产生的中间张量是一片庞大的短期记忆。Eager 模式下，每个张量用完就释放，但释放得早或晚，会直接影响显存峰值。AOTAutograd 因为提前看到了整张联合图，能够精确计算每个中间张量的“生死时刻”——什么时候被创建、最后一次被使用是什么时候——从而让多个张量共享同一块显存。

这在后厨里就是“锅具复用”：同一口锅，炒完第一道菜洗一洗，立刻用来炒第二道，而不是每道菜都新买一口锅。激活值尤其适合复用：前向算子 F3 产生的激活值被反向算子 B3 消费后，这块缓存立刻可以被别的中间量占据。于是显存峰值被压得很低，同样的显卡就可以装下更大的模型或更长的序列。

另一个武器是编译缓存。同一道菜客人点十次，总厨不可能重新研究十遍菜谱。AOTAutograd 也一样：首次遇到某段计算图时完成全部捕获与编译，之后同样的图结构直接命中缓存，跳过大部分开销。这也是为什么 torch.compile 通常“第一遍慢、后面快”——第一遍是总厨在写值班表，后面只是照着执行。

Mpeak=max⁡t∑a∈live(t)size(a)\displaystyle M_{\text{peak}} = \max_{t} \sum_{a \in \text{live}(t)} \text{size}(a)
峰值内存等于所有“还活着”的张量大小之和的最大值。AOTAutograd 的规划目标，就是让这个最大值尽可能小。
  1. 存活集合$\text{live}(t)$ 表示在时刻 $t$ 仍然被后续计算需要的张量集合。
    live(t)={a∣a 已被分配且尚未释放}\displaystyle \text{live}(t) = \{ a \mid a \text{ 已被分配且尚未释放} \}
  2. 单张大小$\text{size}(a)$ 是张量 $a$ 占用的显存字节数。
    size(a)\displaystyle \text{size}(a)
  3. 瞬时总量再取最大值把每个时刻所有存活张量的大小相加，再对所有时刻取最大，就是峰值内存。
    max⁡t∑a∈live(t)size(a)\displaystyle \max_{t} \sum_{a \in \text{live}(t)} \text{size}(a)

XLA工程实践：同一份清单、不同的厨房

AOTAutograd 产出的联合图并不绑定某一家后厨。它可以交给 Inductor 生成 CUDA 代码，也可以交给 XLA 这样的第三方后端编译成适合 TPU 或其他硬件的程序。这种“前端与后端解耦”正是 XLA 与 PyTorch 编译能够互通的关键：无论底层的厨房设备多不同，只要都接得住 AOTAutograd 这份标准清单，就能把训练和推理搬上去跑。

在工程实践中，这份解耦带来了非常实际的工作方式。比如在 GPU 上调试好的模型，要部署到 TPU 上，不需要重写整个模型，只要更换编译后端并检查算子兼容性即可。遇到性能问题时，工程师通常会先检查两张表：一是 FX 图上发生了多少次 graph break（图断裂，即被迫切出的回退子图），二是编译缓存是否命中。graph break 越多，说明“手工小灶”越多，AOT 的优势被削弱；缓存没命中，则说明每次都在重新编菜谱，需要检查代码是否存在大量动态结构。

实际项目中，工程师常借助 TORCH_COMPILE_DEBUG 环境变量和 torch._dynamo.explain 等工具，观察图被切了几段、每段有多大。就像总厨每天复盘：哪道菜反复出问题、哪口锅流转不畅。通过减少 graph break、让算子更规整地落在可编译区域内，AOTAutograd 的整套厨房流水线才能发挥真正的威力。

y=Backend⁡(AOT⁡(G))(x)\displaystyle y = \operatorname{Backend}\bigl(\operatorname{AOT}(\mathcal{G})\bigr)(x)
这句公式是整套流程的缩影：先捕获图 $\mathcal{G}$，再让 AOTAutograd 生成联合计划，最后交给任意后端编译执行。
  1. 捕获计算图$\mathcal{G}$ 是 Dynamo 捕获后得到的 FX 计算图。
    G=(V,E)\displaystyle \mathcal{G} = (V, E)
  2. AOT 生成联合计划$\operatorname{AOT}(\mathcal{G})$ 表示把图变成前向反向联合图，并完成内存规划与分区。
    AOT⁡(G)\displaystyle \operatorname{AOT}(\mathcal{G})
  3. 后端编译并执行$\operatorname{Backend}(\cdot)(x)$ 表示把图编译成目标代码后，对输入 $x$ 实际执行。

AI 应用场景

大模型训练加速

阶段：模型训练

解决的问题：大模型参数量大、训练迭代多，Eager 模式下每次迭代都重新构建反向图，内核启动频繁、显存峰值高，训练速度上不去。

具体案例：某团队训练 70 亿参数的语言模型，开启 torch.compile 后，AOTAutograd 提前把前向与反向焊成联合图，配合 Inductor 的内核融合与激活值复用，训练吞吐提升约 30%，显存峰值下降 15%，原先需要 8 卡才能塞下的 batch 现在 6 卡即可运行。

推理部署多后端迁移

阶段：模型部署

解决的问题：模型在 GPU 上训练完后要部署到不同硬件，传统做法需要手写各平台的优化算子，工作量大且容易引入数值不一致。

具体案例：一个视觉检测模型需要同时部署到 NVIDIA GPU 与 Google TPU。团队利用 AOTAutograd 与后端解耦的特性，GPU 上由 Inductor 编译，TPU 上由 XLA 后端消费同一张联合图，前端逻辑无需改动，仅靠切换后端就完成了迁移，部署周期从三周缩短到两天。

编译器性能瓶颈定位

阶段：模型调试与优化

解决的问题：工程师开启 torch.compile 后加速效果不明显，难以判断瓶颈到底在图捕获阶段、图分区阶段还是代码生成阶段。

具体案例：某推荐系统模型包含大量动态形状的 Python 循环，工程师用 Dynamo 调试工具发现 graph break 高达十余处，大部分子图回退到了 Eager。通过改写动态逻辑、把可变维度补齐为静态形状，graph break 降为两处，torch.compile 的加速效果从 5% 提升到 35%。

Python 演示

python35 行
import torchimport torch.nn as nnfrom torch.fx import symbolic_trace class LinearNet(nn.Module):    def __init__(self):        super().__init__()        self.fc = nn.Linear(4, 2)     def forward(self, x):        return torch.sigmoid(self.fc(x))  if __name__ == "__main__":    model = LinearNet()    x = torch.randn(8, 4, requires_grad=True)     # 1. Dynamo/FX 把"菜谱"变成标准化清单    fx_gm = symbolic_trace(model)    plan = [node.name for node in fx_gm.graph.nodes]    print("AOT 前端的 FX 图节点:", " -> ".join(plan))    fx_gm.graph.print_tabular()     # 2. torch.compile 内部调用 AOTAutograd + Inductor    compiled = torch.compile(model)    out = compiled(x)     # 3. 验证编译结果与 eager 一致    with torch.no_grad():        eager_out = model(x)    print("eager 与 compiled 结果一致:", torch.allclose(eager_out, out))     # 4. 反向传播也沿同一份联合图执行    grad = torch.autograd.grad(out.sum(), x)    print("输入梯度形状:", grad[0].shape)
目的：演示从 FX 图捕获到 torch.compile 编译再到反向传播的完整流程，展示 AOTAutograd 在其中的位置。
  1. fx_gm = symbolic_trace(model)用 FX 的符号追踪捕获模型前向计算图，相当于把菜谱写成标准清单。
  2. plan = [node.name for node in fx_gm.graph.nodes]提取图里每个节点的名字，得到一张可读执行计划。
  3. compiled = torch.compile(model)一行代码让 PyTorch 自动执行 Dynamo 捕获、AOTAutograd 联合图和 Inductor 代码生成。
  4. with torch.no_grad():推理时暂时关闭梯度追踪，避免额外内存开销。
  5. torch.autograd.grad(out.sum(), x)在编译后的模型上执行反向传播，验证联合图覆盖了梯度计算。

常见误区

误区我以为 AOTAutograd 是一个全新的自动微分引擎，会完全替代 PyTorch 原来的 autograd 系统，所以一直担心旧代码是否会崩溃。

正解AOTAutograd 并不是替代品，而是建立在 autograd 之上的“提前编排者”。它仍然使用 autograd 的梯度语义，只是把反向传播的路径提前捕获、规划并编译。就像总厨不是取代洗碗工，而是在开餐前把洗碗路线也排进值班表。

为何常见：AOT 的全称里有 Autograd，加上 torch.compile 又号称“编译整个模型”，容易让人误以为底层微分机制被推倒重来。

误区我觉得开启 torch.compile 之后，模型每跑一个 batch 都会重新做一遍图捕获和代码生成，所以训练会一直很慢。

正解AOTAutograd 有编译缓存机制。同一段代码、同一组张量结构，只在第一次遇到时编译，后面直接命中缓存执行。这也是“第一次慢、后面快”的原因。如果每次都重新编译，说明代码出现了大量动态结构，缓存不断失效。

为何常见：很多人第一次跑 torch.compile 发现耗时很长，就以为每次都有这个成本，没意识到这是“写菜谱”和“照着做菜”的区别。

误区我以为只要模型里有一个算子不能被编译，torch.compile 整个就会失败，所以根本不敢用。

正解AOTAutograd 的分区器会把图切成可编译子图和不可编译子图，后者自动回退到 Eager 模式，模型仍然正常运行。当然，回退子图越多，加速效果越差。它不是崩溃，而是“手工小灶”与“流水线”的合理分流。

为何常见：把编译想象成“全有或全无”的黑盒，忽略了图分区与回退机制的存在。

误区我认为 torch.compile 主要把卷积、矩阵乘法这些前向算子融合了，反向传播该怎么样还是怎么样，加速全靠前向。

正解AOTAutograd 最核心的产出恰恰是联合正反向图：它把前向算子和反向算子放在同一张图里统一优化。反向需要的激活值可以直接复用前向缓存，反向算子之间也能融合。加速收益很大一部分来自反向路径的优化。

为何常见：大家习惯把前向和反向当成两段独立代码，忽略了 AOTAutograd 的设计初衷就是把它们焊接在一起。

误区既然 torch.compile 默认后端是 Inductor，那 AOTAutograd 产出的图就只能在 Inductor 上跑，换硬件就彻底没戏了。

正解AOTAutograd 刻意保持了与后端解耦：它生成的是标准 FX 图，可以交给 Inductor，也可以交给 XLA 等第三方后端。只要后端能消费这份图，就能在 TPU、GPU 等不同设备上获得编译优化。

为何常见：因为接触最多的是默认组合，容易把“默认”误解成“唯一”。

面试题

Q1. AOTAutograd 名称中的“AOT”指的是什么？

单选题 · easy

  • A.自动完成正向传播
  • B.提前捕获并编译图← 正确答案
  • C.自动选择后端框架
  • D.按需追踪动态计算图

答案：B。AOT 是 Ahead-Of-Time 的缩写，意为“提前”。AOTAutograd 在训练真正开始前就把前向与反向计算图捕获并编译好，而不是运行时边算边构建。A 说的是“自动”，C 说的是“自动选后端”，D 说的是“运行时追踪”，都对应不到 AOT 的“提前”内核。

Q2. AOTAutograd 的输入计算图通常来自哪个组件？

单选题 · easy

  • A.Dynamo 和 FX 捕获← 正确答案
  • B.CUDA 内核源码
  • C.ONNX 模型文件
  • D.Python AST 语法树

答案：A。torch.compile 先用 Dynamo 捕获 Python 层执行过程，再由 FX 整理成标准图，AOTAutograd 消费的正是这张 FX 图。CUDA 内核是后端产物，ONNX 文件是模型交换格式，Python AST 则是源码语法层面，均不是 AOTAutograd 的直接输入。

Q3. 联合图 joint graph 的核心特点是什么？

单选题 · hard

  • A.只包含前向算子
  • B.正反向合为一体← 正确答案
  • C.只保存参数梯度
  • D.压缩后减小模型体积

答案：B。AOTAutograd 的看家本领就是把前向计算与反向求导放进同一张图里，让编译器能同时看到整条“做菜与洗盘”的动线。A 只含前向，C 只含梯度，D 与图结构无关，三者都没抓住“联合”二字的含义。

Q4. MinCut 分区器在 AOTAutograd 中的作用是？

单选题 · mid

  • A.把数据切分到多卡
  • B.分离可编译与回退部分← 正确答案
  • C.将大 batch 拆分处理
  • D.减少参数量提高精度

答案：B。MinCut 分区把联合图切成“可编译子图”与“不可编译子图”，让前者进入后端编译、后者回退 Eager 执行。A 是数据并行切分，C 是 batch 拆分，D 是模型压缩，都与图分区器的职责无关。

Q5. 以下哪些是 AOTAutograd 编译缓存的特点？

多选题 · easy

  • A.同一图只编译一次← 正确答案
  • B.支持动态 shape 复用← 正确答案
  • C.每次运行都重新编译
  • D.缓存可显著减少开销← 正确答案

答案：ABD。编译缓存让相同结构的图只编译一次，之后直接命中缓存；只要张量形状等信息不变，动态 shape 也能复用缓存；这自然显著减少了重复编译开销。C 恰好说反，是“每次重新编译”才需要缓存去避免。总厨当然不会每桌客人都重新研究一遍菜谱。

Q6. AOTAutograd 生成的图可以交给哪些后端编译？

多选题 · mid

  • A.Inductor 代码生成← 正确答案
  • B.XLA 编译后端← 正确答案
  • C.自定义 FX 后端← 正确答案
  • D.只能使用固定后端

答案：ABC。AOTAutograd 刻意保持与后端解耦，产出的图既能交给默认的 Inductor，也能交给 XLA 或任何能消费 FX 图的自定义后端。D 把“默认”误解成“唯一”，这正是后端解耦要避免的事。同一份标准流程单，可以递给不同厨房。

Q7. 联合图中激活值复用的好处是什么？

单选题 · mid

  • A.反向复用前向缓存省内存← 正确答案
  • B.重新计算全部中间张量
  • C.丢弃所有前向计算结果
  • D.把张量移到 CPU 计算

答案：A。联合图把前向的激活值直接留给反向算子消费，相当于“锅洗完马上给下一道菜用”，避免重复计算或额外保存一份。B 是“重算”策略，C 会毁掉反向必需的数据，D 与激活复用无关。

Q8. 训练图遇到无法编译的算子时，torch.compile 会怎样？

单选题 · hard

  • A.直接抛出中断训练
  • B.在断点回退 Eager 子图← 正确答案
  • C.自动切换至 CPU 执行
  • D.无限循环等待编译成功

答案：B。图分区器会把不可编译的算子单独切出，让那些子图回到 Eager 模式执行，其余可编译部分照常由后端优化。这就是 graph break 的本来含义。A 的“中断”、C 的“换设备”、D 的“死等”都不符合分区回退的设计。

Q9. 内核融合（kernel fusion）主要解决什么问题？

单选题 · mid

  • A.减少内核启动与访存开销← 正确答案
  • B.让更多算子在 CPU 执行
  • C.扩大模型的参数量规模
  • D.增加编译缓存命中次数

答案：A。GPU 上每个内核启动都有固定开销，且算子在显存与寄存器之间来回搬运数据也很贵。融合把多个算子合并成一个内核一次跑完，既减少启动次数又降低访存。B、C、D 都与融合的核心动机无关。就像炒菜时把肉丝和青菜一锅出，而不是每样单独生火。

Q10. 关于 AOTAutograd 与 autograd 的关系，正确的说法是？

多选题 · hard

  • A.AOTAutograd 构建在 autograd 之上← 正确答案
  • B.AOTAutograd 完全替代自动微分
  • C.AOTAutograd 可同时做图优化← 正确答案
  • D.AOTAutograd 忽略反向传播过程

答案：AC。AOTAutograd 在保留 autograd 梯度语义的基础上，把反向传播提前捕获并纳入同一张图做全局优化，因此 A 和 C 正确。它并没有推翻 autograd，也不是“完全替代”，更不会忽略反向传播——反向正是它联合图里最重的一部分。总厨不会取代洗碗工，而是把洗碗排进同一张流程表。