PyTorch 核心术语详解：基于 GLOSSARY 读懂 ATen 中的 Operation、Kernel 与 JIT 编译体系

PyTorch 仓库根目录下的 GLOSSARY.md 是理解 PyTorch 内部机制的官方术语手册，它用 15 个词条厘清了两组最容易混淆的概念：ATen 算子体系中的 Operation / Kernel / Composite / Leaf 的边界，以及 TorchScript 的 Tracing / Scripting 两条编译路径。本文逐条展开这些术语的原始定义，并结合仓库中 aten/src/ATen/native/native_functions.yaml 等真实源码印证每个术语在代码中的落点，帮助你在阅读 PyTorch 源码、撰写算子或排查 dispatch 问题时快速对齐概念。

一、术语总览：GLOSSARY 的两块知识版图

GLOSSARY.md 的目录（toc）将全部词条划分为两大类：

1. Operation and Kernel（算子与内核）：ATen、Operation、Native Operation、Custom Operation、Kernel、Compound Operation、Composite Operation、Non-Leaf Operation、Leaf Operation、Device Kernel、Compound Kernel；
2. JIT Compilation（即时编译）：JIT、TorchScript、Tracing、Scripting。

前者回答"一个 PyTorch 算子从注册到执行经历了什么"，后者回答"一段 Python 代码如何被编译成可执行、可部署的程序"。下面按原目录顺序逐条解析。

二、ATen：一切的地基

GLOSSARY 对 ATen 的定义是："A Tensor Library" 的缩写，是其他一切所依赖的底层张量与数学运算库。

这一点可以直接在仓库目录结构中印证：ATen 的 C++ 实现全部位于 aten/src/ATen/，包含 Dispatch.h、Dispatch.cpp、Device.h 等核心基础设施文件。而 aten/src/README.md 进一步交代了 ATen 的历史脉络：低层库源自最初的 Torch，曾有 TH（TorcH）、THC（TorcH CUDA）、THCS（CUDA 稀疏）、THNN（神经网络）、THS（稀疏）等多个变体，其中 THCS 与 THNN 已废弃（now defunct）。这些缩写至今仍残留在大量符号名中——阅读 ATen 源码时看到 TH 前缀的符号，即为此背景。该 README 同时给出了 ATen C 层代码的"引用计数黄金法则"（Golden Rule of Reference Counting）：凡是由名字以 new 开头的函数返回、或你手动 retain 过的指针，你必须在退出路径上 free 它——这是理解 ATen 存储与视图（view 共享 c10::StorageImpl）实现的前提。

三、Operation：工作单元

GLOSSARY 的定义：Operation 是"一份工作"（a unit of work）。例如矩阵乘法这项工作，就是一个名为 aten::matmul 的算子。

aten:: 前缀正是 ATen 命名空间的体现。在 native_functions.yaml 中可以找到它的正式声明：

- func: matmul(Tensor self, Tensor other) -> Tensor
  variants: function, method

variants: function, method 声明了该算子同时以 torch.matmul 函数形式和 Tensor.matmul 方法形式暴露——这解释了为什么你在 Python 里两种写法都能调用同一个 aten::matmul。

Native Operation（原生算子） 随之定义：随 PyTorch ATen 原生生成的算子，aten::matmul 是文档给出的标准例子。与下文 Custom Operation 对照理解：凡是没写 aten:: 前缀而来自 native_functions.yaml 等声明文件的算子，都可视为原生算子。

四、Custom Operation：用户自定义算子

GLOSSARY 指出：Custom Operation 由用户定义，且通常是 Compound Operation（复合算子）。官方文档曾以专门教程讲解其创建方式（仓库文档仅以外部教程链接指向，本文不重复外链）。

在仓库中可以找到对应的验证与工具链落点：

• test/custom_operator/ 目录下存放了自定义算子的完整测试用例，涵盖 Python 端与 C++ 端（.py、.cpp）的注册方式；
• torch/_custom_op/ 与 torch/_library/ 是框架内部支撑自定义算子注册机制的模块。

"Custom Operation 通常是 Compound Operation"这句定性很重要：因为用户通常在 Python 层用已有算子组合出新的语义（例如 layer_norm 的自定义实现往往由 mean、var、sub、div 组合而成），其求导自然依赖 Autograd 对内部组合算子的自动追踪，而非手写反向公式。

五、Kernel：算子的实现

GLOSSARY 的定义：Kernel 是 PyTorch 算子的实现（Implementation），规定了算子执行时应做什么（specifying what should be done when an operation executes）。

Operation 与 Kernel 的关系是"接口与实现"：Operation 是注册进系统、可被调用与分发的逻辑单元，Kernel 则是真正落地的函数体。这一关系在 native_functions.yaml 的声明中体现得非常直接：

- func: matmul(Tensor self, Tensor other) -> Tensor
  variants: function, method
  dispatch:
    CompositeImplicitAutograd: matmul
    NestedTensorCPU, NestedTensorHPU, NestedTensorCUDA, NestedTensorXPU: matmul_nested

func: 行声明 Operation，dispatch: 块下的每一行则是"在某个 dispatch key 下执行哪个 Kernel"的映射。matmul 这个 Operation 在 CompositeImplicitAutograd 这一键下分派给名为 matmul 的复合 Kernel，而在 NestedTensorCPU/NestedTensorCUDA 等键下分派给 matmul_nested——同一个 Operation 在不同 dispatch key 下绑定不同 Kernel，这正是 ATen 分派机制（其核心数据结构位于 aten/src/ATen/Dispatch.h 与 aten/src/ATen/Dispatch_v2.h）的静态声明形式。

六、Compound / Composite / Non-Leaf Operation：一个概念的三个名字

GLOSSARY 对三个词条给出了完全一致的定性：

• Compound Operation：由其他算子组合而成的算子。它的 Kernel 通常是设备无关（device-agnostic）的；通常不单独定义求导函数，而是由 Autograd 基于它所依赖的那些算子自动计算其导数。
• Composite Operation：Same as Compound Operation（与 Compound Operation 同义）。
• Non-Leaf Operation：Same as Compound Operation（与 Compound Operation 同义）。

也就是说，社区里流传的 "composite op" 与 "non-leaf op" 都是指同一类"组合型算子"。上文 matmul 的例子就是最典型的实证：其 dispatch key 名为 CompositeImplicitAutograd——后缀 ImplicitAutograd 恰好对应文档中"自身不定义导数、由 Autograd 隐式推导"的描述；而从源码结构看，此类复合 Kernel 的 C++ 实现（如 matmul 函数）会向下调用 bmm、mm 等更基础的算子，因此天然获得跨 CPU/CUDA 的通用性，且梯度路径由底层算子的导数自动拼出。

七、Leaf Operation：与复合算子相对的基本算子

GLOSSARY 的定义：Leaf Operation 被视为"基本算子"，与 Compound Operation 相对。Leaf Operation 总是定义了 dispatch 函数（分派函数），通常也定义了导数函数。

"总是有 dispatch 函数"对应 native_functions.yaml 中每个 leaf 算子声明下必有的 dispatch: 块，按 CPU / CUDA 等设备键逐一绑定实现；"通常有导数函数"则对应叶子算子普遍伴随 *_backward 声明（例如与 matmul 配套声明的 matmul_backward）。从源码结构看，leaf 算子的 C++ 实现往往带 structured_kernel 标注并由代码生成器接管分派与反向推导逻辑，这正是"Leaf 总有 dispatch 函数"在工程上得以保证的机制。理解 Compound 与 Leaf 的分界，本质上是判断一个算子"自带底层实现"还是"委托给别的算子"。

八、Device Kernel 与 Compound Kernel：Kernel 的两个阵营

GLOSSARY 对 Kernel 做了对称划分：

• Device Kernel（设备内核）：Leaf Operation 中针对特定设备的内核，即绑定到某一具体 dispatch key（CPU、CUDA、XPU……）的那个实现；
• Compound Kernel（复合内核）：与 Device Kernel 相对，通常设备无关（device-agnostic），归属于 Compound Operation——典型如上文 CompositeImplicitAutograd 键下分派的 matmul 函数。

把这两组划分合起来，就得到一张完整的二维坐标：Operation 层面按"基本 vs 组合"分为 Leaf / Compound；Kernel 层面按"绑定设备 vs 设备无关"分为 Device / Compound。aten::matmul 在 NestedTensorCPU 等键下的 matmul_nested 属于 Device Kernel（针对 NestedTensor 布局的设备实现），而 CompositeImplicitAutograd 下的 matmul 属于 Compound Kernel——同一个算子同时拥有两类 Kernel，这是阅读 native_functions.yaml 时最常见的形态。

九、JIT 编译体系：JIT、TorchScript、Tracing 与 Scripting

GLOSSARY 的后半部分用四个词条勾勒出 TorchScript 编译栈：

• JIT：Just-In-Time Compilation，即时编译的总称；
• TorchScript：TorchScript JIT 编译器与解释器的接口。仓库中对应 torch/jit/ 目录，它是 Python 用户与底层 TorchScript 编译/解释运行时之间的全部公共入口；
• Tracing（追踪）：用 torch.jit.trace 作用于一个函数，得到一个可被即时编译优化的可执行程序。其工作方式是通过一次真实的前向执行记录算子调用轨迹，适合控制流固定的模型；
• Scripting（脚本化）：用 torch.jit.script 作用于一个函数，检查其源代码并将其编译为 TorchScript 代码。与 trace 不同，script 走的是静态分析 + 编译路线，能够表达 if、循环等数据无关的控制流，也是 test/jit/ 目录中大量测试用例所验证的对象。

一个可操作的判据是：当你需要保留 Python 控制流语义、且要求部署端解释执行时选择 torch.jit.script；当你只需要记录一条确定的算子执行轨迹时选择 torch.jit.trace。两者产出的都是可序列化的 TorchScript 程序，区别在"运行时观察行为"与"编译时分析源码"。

十、术语速查表：定义与仓库验证点

术语	定义要点（源自 GLOSSARY.md）	仓库内验证点
ATen	"A Tensor Library"，张量与数学运算基础库	aten/src/ATen/、aten/src/README.md
Operation	工作单元，如 aten::matmul	native_functions.yaml#L3783
Native Operation	ATen 原生自带的算子	同上的 func: 声明
Custom Operation	用户定义，通常为复合算子	test/custom_operator/、torch/_library/
Kernel	算子的实现，规定执行时做什么	dispatch: 块中的函数映射
Compound / Composite / Non-Leaf Operation	同义：由其他算子组合、设备无关、导数由 Autograd 自动推导	CompositeImplicitAutograd 分派键
Leaf Operation	基本算子，必有 dispatch 函数，通常有导数函数	每个 leaf 算子的 dispatch: 块与配套 *_backward
Device Kernel	Leaf 算子的设备特定内核	如 matmul_nested（NestedTensor 各设备键）
Compound Kernel	设备无关，隶属复合算子	如 CompositeImplicitAutograd: matmul
TorchScript	JIT 编译器与解释器的接口	torch/jit/、test/jit/
Tracing	torch.jit.trace 执行轨迹编译	同上
Scripting	torch.jit.script 源码检查编译	同上

十一、结语

GLOSSARY.md 篇幅不长，却提供了阅读 PyTorch 源码时反复要用的词汇表：以 Operation / Kernel 为骨架，用 Leaf / Compound 的二维划分解释分派表中每一行的含义，再用 JIT / TorchScript / Tracing / Scripting 补齐编译侧的术语。当你在 native_functions.yaml 中看到一个新的 dispatch: 声明，或需要为一个自定义算子选择"自己写 Device Kernel"还是"组合出 Compound Kernel"时，回到这张术语表对号入座，就能快速判断该算子属于体系的哪一层、其梯度行为从何而来。