AI框架精要：设计思想
本文主要介绍飞桨paddle平台的底层设计思想，可以帮助用户理解飞桨paddle框架的运作过程，以便于在实际业务需求中，更好的完成模型代码编写与调试及飞桨paddle框架的二次开发。
从编程范式上说，飞桨paddle兼容支持声明式编程和命令式编程，通俗地讲就是，静态图和动态图。其实飞桨paddle本没有图的概念，在飞桨paddle设计上，把一个神经网络定义成一段类似程序的描述，就是在用户写程序的过程中，就定义了模型表达及计算。在静态图的控制流实现方面，飞桨paddle借助自己实现的控制流OP而不是python原生的if else和for循环，这使得在飞桨paddle中的定义的program即一个网络模型，可以有一个内部的表达，是可以全局优化编译执行的。考虑对开发者来讲，更愿意使用python原生控制流，飞桨paddle也做了支持，并通过解释方式执行，这就是动态图。但整体上，两种编程范式是相对兼容统一的。2020年，飞桨paddle将发布更加完善的动态图功能，同时会保持更强劲的性能。
飞桨paddle平台中，将神经网络抽象为计算表示Operator（算子）和数据表示Variable（变量），如 图1 所示。神经网络的每层操作均由一个或若干Operator组成，每个Operator接受一系列的Variable作为输入，经计算后输出一系列的Variable。
图1 Operator和Variable关系示意图
根据Operator解析执行方式不同，飞桨paddle支持如下两种编程范式：
- 静态图模式（声明式编程范式）：先编译后执行的方式。用户需预先定义完整的网络结构，再对网络结构进行编译优化后，才能执行获得计算结果。
- 动态图模式（命令式编程范式）：解析式的执行方式。用户无需预先定义完整的网络结构，每写一行网络代码，即可同时获得计算结果。
举例来说，假设用户写了一行代码：y=x+1。在静态图模式下，运行此代码只会往计算图中插入一个Tensor加1的Operator，此时Operator并未真正执行，无法获得y的计算结果。但在动态图模式下，所有Operator均是即时执行的，运行完此代码后Operator已经执行完毕，用户可直接获得y的计算结果。
静态图模式和动态图模式的能力对比如下表所示：
说明：
由于本章节涉及飞桨paddle深度学习平台的架构设计，需要用户具备一定深度学习背景和C/C++编程能力。
静态图设计思想
静态图执行流程
在静态图模式下，飞桨paddle将神经网络描述为Program的数据结构，使用一种编程器式的执行流程，分为编译期和运行期两个阶段。
- 编译期：直接调用飞桨paddleAPI编写Python程序，向Program中添加变量Variable和算子Operator。用户只需描述前向计算，无需关心反向计算、分布式场景及异构设备场景的计算。
- 运行期：对Program进行编译优化，然后使用执行器Executor，创建Program中定义的变量，并执行Program中定义的算子。
下面以一个简单的飞桨paddle训练代码为例，体会下在静态图模式下，编译期和运行期代码的变化。
import paddle
import numpy as np
# 飞桨paddle2.0默认模式为动态图，需要开启静态图模式
paddle.enable_static()
# 编译期：调用飞桨paddle的API编写Python程序，如下述代码中定义了一个含conv2d的网络，并使用Adam优化器优化参数。
image = paddle.static.data(name='image', shape=[None, 3, 224, 224], dtype='float32')
conv_result = paddle.static.nn.conv2d(image, num_filters=64, filter_size=3)
loss = paddle.mean(conv_result)
adam = paddle.optimizer.Adam(learning_rate=1e-3)
adam.minimize(loss)
# 运行期：先运行一次startup program初始化网络参数，然后调用飞桨paddle的Executor和CompiledProgram API运行网络。
place = paddle.CPUPlace() # 使用何种设备运行网络，CPUPlace表示使用CPU运行，CUDAPlace表示使用GPU运行
executor = paddle.static.Executor(place) # 创建执行器
executor.run(paddle.static.default_startup_program()) # 运行startup program进行参数初始化
# 再使用CompiledProgram编译网络，准备执行。
compiled_program = paddle.static.CompiledProgram(paddle.static.default_main_program())
BATCH_NUM = 2
BATCH_SIZE = 32
for batch_id in range(BATCH_NUM):
input_image = np.random.random([BATCH_SIZE, 3, 224, 224]).astype('float32')
loss_numpy, = executor.run(compiled_program, feed={'image': input_image}, fetch_list=[loss])
print("Batch {}, loss = {}".format(batch_id, loss_numpy))
# 关闭静态图模式
paddle.disable_static()
Batch 0, loss = [-0.09575158]
Batch 1, loss = [-0.11025753]
静态图核心架构
飞桨paddle静态图核心架构分为Python前端和C++后端两个部分，如 图2 所示：
图2 飞桨paddle静态图核心架构示意图
- Python前端：
- Program由一系列的Block组成，每个Block包含各自的 Variable 和Operator。
- （可选操作）Transpiler将用户定义的Program转换为Transpiled Program（如：分布式训练时，将原来的Program拆分为Parameter Server Program 和Trainer Program）。
- C++后端：
- （可选操作）C++后端将Python端的Program转换为统一的中间表达（Intermediate Representation，IR Graph），并进行相应的编译优化，最终得到优化后可执行的计算图。其中，编译优化包括但不限于：
- Operator Fusion：将网络中的两个或多个细粒度的算子融合为一个粗粒度算子。例如，表达式z = relu(x + y)对应着2个算子，即执行x + y运算的elementwise_add算子和激活函数relu算子。若将这2个算子融合为一个粗粒度的算子，一次性完成elementwise_add和relu这2个运算，可节省中间计算结果的存储、读取等过程，以及框架底层算子调度的开销，从而提升执行性能和效率。
- 存储优化：神经网络训练/预测过程会产生很多中间临时变量，占用大量的内存/显存空间。为节省网络的存储占用，飞桨paddle底层采用变量存储空间复用、内存/显存垃圾及时回收等策略，保证网络以极低的内存/显存资源运行。
- Executor创建优化后计算图或Program中的 Variable ，调度图中的Operator，从而完成模型训练/预测过程。
静态图的核心概念
飞桨paddle静态图的核心概念如下：
- Variable：表示网络中的数据。
- Operator：表示网络中的操作。
- Block：表示编程语言中的控制流结构，如条件结构（if-else）、循环结构（while）等。
- Program：基于Protobuf的序列化能力提供模型保存、加载功能。Protobuf是Google推出的一个结构化数据的序列化框架，可将结构化数据序列化为二进制流，或从二进制流中反序列化出结构化数据。飞桨paddle模型的保存、加载功能依托于Protobuf的序列化和反序列化能力。
- Transpiler：可选的编译步骤，作用是将一个Program转换为另一个Program。
- Intermediate Representation：在执行前期，用户定义的Program会转换为一个统一的中间表达。
- Executor：用于快速调度 Operator ，完成网络训练/预测。
Variable
飞桨paddle的Variable 表示网络中的数据。 Variable 的C++底层数据结构为Protobuf表示的 VarDesc，包含如下信息：
message VarDesc {
// Variable的名称
required string name = 1;
// Variable的类型，例如LOD_TENSOR、LOD_TENSOR_ARRAY等
required VarType type = 2;
// 是否为持久性变量，持久性变量在模型运行过程中不会销毁，持久性变量包括：模型参数、优化器参数等
// 非持久性变量可能在模型运行过程中销毁
optional bool persistable = 3;
}
Operator
飞桨paddle的 Operator 表示网络中的操作。 Operator 的C++底层数据结构为Protobuf表示的 OpDesc ，包含如下信息：
message OpDesc {
// Operator的类型
required string type = 3;
// Operator的输入变量列表
repeated Var inputs = 1;
// Operator的输出变量列表
repeated Var outputs = 2;
// Operator的属性列表
repeated Attr attrs = 4;
}
Operator 由如下4个域构成：
- type : std::string 类型，表示 Operator 的类型，如relu、conv2d、elementwise_add等。
- inputs : std::map<std::string, std::vector<std::string>> 类型，记录输入slot名称至实际输入变量 Variable 名称的映射。
例如，飞桨paddle sum 算子功能是将多个shape相同的输入Tensor（输入slot的名称为 X ）累加为一个输出Tensor。若实际输入 Variable 的名称分别为 tmp_in_0 ，tmp_in_1 ， tmp_in_2 ，则 sum 算子的 inputs 为 {"X": ["tmp_in_0", "tmp_in_1", "tmp_in_2"]} 。 type 相同的算子拥有相同的输入slot名称（类似于函数的形参），但实际输入变量的名称（类似于函数的实参）可以不同。
- outputs : 与 inputs 类型相同，均为 std::map<std::string, std::vector<std::string>> 类型，记录输出slot名称至实际变量 Variable 名称的映射。
例如，飞桨paddle的 split 算子功能是将输入Tensor沿某个维度拆分为若干个Tensor（输出slot的名称为 Out ）。若实际输出 Variable 的名称分别为 tmp_out_0 ， tmp_out_1 ， tmp_out_2 ，则 split 算子的 outputs为 {"Out": ["tmp_out_0", "tmp_out_1", "tmp_out_2"]} 。
- attrs : std::map<std::string, Attribute> 类型，表示属性名称至实际属性值的映射，其中 Attribute 支持的类型包括：
- bool
- int32
- int64
- float32
- std::string
- std::vector<bool>
- std::vector<int32>
- std::vector<float32>
- std::vector<std::string>
- std::vector<int64>
Block
飞桨paddle的 Block 用于表示编程语言中的控制流结构，如条件结构（if-else）、循环结构（while）等，还描述了一组以顺序、选择或是循环执行的 Operator 以及 Operator 操作的对象：Tensor。Block 的C++底层数据结构为Protobuf表示的 BlockDesc ，包含如下信息：
message BlockDesc {
// 该Block的ID
required int32 idx = 1;
// 父Block的ID，类似于编程语言的父子Block关系
required int32 parent_idx = 2;
// 该Block中包含的Variable列表
repeated VarDesc vars = 3;
// 该Block中包含的Operator列表
repeated OpDesc ops = 4;
}
Block 的概念与编程语言中的类似，例如以下这段C++代码中包含三个Block：
#include <cstdint>
int64_t func(int64_t x, int64_t y)
{
bool condition = (x < y); // block 0
int64_t output;
if (condition) // block 0
{
int64_t true_out = 1; // block 1
output = true_out; // block 1
}
else
{
int64_t false_out = 0; // block 2
output = false_out; // block 2
}
return output;
}
类似的，飞桨paddle代码的 Program 包含如下三段Block：
import paddle
paddle.enable_static()
x = paddle.static.data(name='x', dtype='int64', shape=[1]) # block 0
y = paddle.static.data(name='y', dtype='int64', shape=[1]) # block 0
condition = paddle.less_than(x, y) # block 0
def true_block():
true_out = paddle.ones(shape=[1], dtype='int64') # block 1
return true_out
def false_block():
false_out = paddle.zeros(shape=[1], dtype='int64') # block 2
return false_out
# 根据条件condition判断执行true_block还是false_block
output = paddle.static.nn.cond(condition, true_block, false_block)
paddle.disable_static()
/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/layers/utils.py:77: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
return (isinstance(seq, collections.Sequence) and
每个Block 拥有自己的 Operator 和 Variable ，不同 Block 中的同名 Variable 是不同的变量。
Program
Program 的C++底层数据结构为Protobuf表示的 ProgramDesc，基于Protobuf的序列化能力提供模型保存、加载功能。ProgramDesc由若干 BlockDesc构成，其中最外层的Block称为 global block（对应Block ID为0），其余Block称为 sub block。
Program、Block 的关系如 图3 所示。
图3``Program``与``Block``关系示意图
在模型训练/预测过程中，往往需要对参数进行一次初始化，随后多次执行训练/预测代码，以达到参数最优。因此，一段飞桨paddle程序通常包含两个 Program ：
- Startup Program：初始化 Operator 所在的 Program ，包括模型参数初始化、优化器参数初始化、reader初始化等 Operator 。框架定义了一个全局默认的Startup Program，即 paddle.static.default_startup_program() 。若用户没有显式指定Startup Program，则框架会使用默认的 paddle.static.default_startup_program() 。
- Main Program：模型主体结构所在的 Program ，包括前向计算、反向计算、模型参数更新、优化器参数更新等 Operator 。框架定义了一个全局默认的Main Program，即 paddle.static.default_main_program() 。若用户没有显式指定Main Program，则框架会使用默认的 paddle.static.default_main_program() 。
Startup Program用于模型初始化，Main Program负责描述网络主体结构。因此在模型训练过程中，往往只需要运行一次Startup Program（初始化一次），然后多次运行Main Program训练模型。
下面以五个典型语句为例，体会一下 Program 在编译期的变化及其内部执行机制。
import paddle
import numpy as np
# 飞桨paddle2.0默认模式为动态图，需要开启静态图模式
paddle.enable_static()
# 语句1 ：在 ``paddle.static.default_main_program()`` 中定义变量 ``image`` 。
image = paddle.static.data(name='image', shape=[None, 3, 224, 224], dtype='float32')
# 语句2 ：在 ``Program`` 中插入conv2d算子。由于conv2d算子包含参数
# 因此语句中还隐含包括参数创建、参数初始化、算子插入等流程。
# 本语句具体执行事物如下：
# 在 paddle.static.default_startup_program()和paddle.static.default_main_program()
# 中创建conv2d算子的权重参数weight和bias。
# 在 paddle.static.default_startup_program()中插入权重参数weight和bias的初始化算子。
# 在 paddle.static.default_main_program()中插入conv2d算子，以及conv2d的输出变量conv_result 。
conv_result = paddle.static.nn.conv2d(image, num_filters=64, filter_size=3)
# 语句3 ：在Program中插入mean算子。由于mean算子不包含参数，因此语句不涉及
# paddle.static.default_startup_program()修改，只会在paddle.static.default_main_program()
# 中插入reduce_mean算子和对应的输出变量loss。
loss = paddle.mean(conv_result)
# 语句4 ：定义Adam优化器，准备做参数优化。
adam = paddle.optimizer.Adam(learning_rate=1e-3)
# 语句5 ：调用优化器的miminize。
# 具体执行事物如下：
# 在 paddle.static.default_startup_program() 中插入学习率、优化器参数
# （即Adam的Moment1、Moment2、Beta1Pow和Beta2Pow）变量及对应的初始化算子。
# 在 paddle.static.default_main_program() 中插入反向算子，并创建对应的前向变量的梯度变量。
# 在 paddle.static.default_main_program() 中插入优化器算子，用于根据参数梯度值更新参数。
adam.minimize(loss)
# 说明：
# 由于以上代码中未指定Startup Program和Main Program，此处使用 paddle.static.default_startup_program()
# 和 paddle.static.default_main_program()
# 关闭静态图模式
paddle.disable_static()
Transpiler
Transpiler 是一个 Program 层面的编译器，其作用是将一个 Program 转换为另一个 Program ，设计的目的是实现 Program 的自动转换，使得用户只需关系核心的模型训练/预测逻辑，无需关心底层实现细节。 Transpiler 不是必需的编译步骤。
如 图4 所示，在Parameter Server + Trainer的分布式训练模式下，完成一个批次训练的流程如下：
- Trainer：负责执行网络的前向和反向算子，计算参数的梯度后发送给Parameter Server。
- Parameter Server：接收Trainer计算得到的参数梯度，执行网络优化器算子，更新网络的参数，并将更新后的参数发送给Trainer。
图4 分布式训练转换Program示意图
由此可见，Parameter Server和Trainer执行的算子是不同的，需要一个自动的转化机制将用户定义的原始 Program 转换为Parameter Server端和Trainer端的不同 Program ，并插入Parameter Server和Trainer间的通信算子，分布式训练的 DistributedTranspiler 用于完成上述转换。
Intermediate Representation
在执行前期，用户定义的 Program 会转换为一个统一的中间表达，即Intermediate Representation，简称IR。
IR Graph代码示意如下：
import paddle
paddle.enable_static()
image = paddle.static.data(shape=[None, 3, 224, 224], name='image', dtype='float32')
label = paddle.static.data(shape=[None, 1], name='label', dtype='int64')
y = paddle.static.nn.fc(image, size=1000)
loss = paddle.nn.functional.softmax_with_cross_entropy(y, label)
mean_loss = paddle.mean(loss)
paddle.disable_static()
飞桨paddle底层使用 SSA Graph有向无环图的形式表示IR，如 图5 所示。
图5 IR Graph示意图
- fc_w 和 fc_b 分别是网络中全连接层的权重参数和偏置参数，全连接层底层由 mul 和 elementwise_add 两个算子组成。
- Variable 和 Operator 是Graph的结点：
- Variable 的输入结点为产生该 Variable 的 Operator ， 输出结点为以该 Variable 为输入的 Operator 。
- Operator 的输入结点为该 Operator 的输入 Variable 结点，输出结点为该 Operator 的输出 Variable 结点。
基于统一的IR Graph表达，飞桨paddle底层会进行Graph层面的优化，包括Operator Fusion，存储占用优化等，以提升执行效率。
在接口层面，用户调用 paddle.static.CompiledProgram 后即可获得一张经过IR Graph优化后的计算图。
import paddle
train_program = paddle.static.default_main_program() # 训练网络
# CompiledProgram内部会将Program转换为IR Graph，并进行一系列的图优化操作
compiled_prog = paddle.static.CompiledProgram(train_program)
说明
IR的概念起源于编译器，是介于程序源代码与目标代码之间的中间表达形式。飞桨paddle的IR与编译器的IR类似，具有如下优势：
- 便于编译优化算法的开发：所有的编译优化算法均以优化前的IR作为输入，并输出优化后的IR，因此不同的编译优化算法可以方便地串联起来使用，相互解耦，便于编译优化算法的开发。
- 便于适配不同的后端硬件：不同后端硬件（Nvidia GPU、Intel CPU、ARM、FPGA等）的架构差异很大，若框架缺少统一的IR表达，则需要针对每一种不同的IR表达适配每一种不同的硬件平台，工作量巨大。若框架有统一的IR表达，则针对每一种不同的硬件平台做一次适配即可，且可把不同硬件平台的公共、通用的部分剥离出来抽象到IR层面，减少代码冗余度，提高可维护性。
- 便于实现不同框架模型间的相互转换：每个深度学习框架往往均有自己的统一IR表达，实现不同框架模型间的转换时，只需要实现不同框架间IR的相互转换即可，开发成本低。
Executor
Executor 用于快速调度 Operator ，完成网络训练/预测。无论是 Program 还是 IR Graph，在执行网络前均只有网络的静态描述，此时网络还未运行，未有真正创建的占有存储空间的运行期变量。飞桨paddle的 Executor 内部使用 Scope 管理运行期的 Variable 。Scope 的主要数据成员为：
class Scope {
// 变量名称到变量的映射
std::unordered_map<std::string, std::unique_ptr<Variable>> vars_;
// 父Scope
Scope *parent_;
// 子Scope列表
std::list<Scope *> kids_;
};
Scope 与编程语言中的变量作用域类似，在查找变量时，会先在当前 Scope 中查找，若有则返回； 若没有则递归地从父 Scope 中查到，直到父 Scope 为空，说明变量不存在。
Executor 的创建方式如以下代码所示，其中 place 参数指明在何种设备上运行，目前飞桨paddle支持 CUDAPlace 和 CPUPlace 两种设备运行网络。
import paddle
USE_CUDA = False
place = paddle.CUDAPlace(0) if USE_CUDA else paddle.CPUPlace()
executor = paddle.static.Executor(place)
执行器 Executor.run 方法用于运行网络，具体调用方式为：
train_program = ... # 训练网络，可以是Program或CompiledProgram
loss_numpy_value = executor.run(train_program, feed={'x': x_data, 'y': y_data}, fetch_list=[loss])
Executor 的执行对象可以为 Program 或 CompiledProgram （即IR Graph），其运行的基本步骤为：
- 在 Scope 中创建 Program 或 CompiledProgram 中的 Variable 。 持久性变量（模型参数、优化器参数等，即persistable属性为True的变量）创建于顶层的 Scope ，非持久性变量（临时变量）创建于顶层 Scope 的子 Scope 中。
- 若执行对象为 Program ，则按照 Program 中 Operator 的排列次序顺序依次执行 Operator 。 若执行对象为 CompiledProgram ，则按照IR Graph中 Operator 的图依赖关系多线程地调度 Operator 。 每个 Operator 执行过程中，会首先从 Scope 中取出输入输出变量，然后根据输入变量进行一系列的运行后，将结果写入输出变量中。
- 所有 Operator 执行完毕后，销毁顶层 Scope 的子 Scope ，即将网络中所有非持久性变量删除，保留持久性变量。
动态图设计思想
动态图模式是一种命令式的编程方式，无需构建完整的计算图，即可实时获得执行结果。
动态图的执行流程
在动态图模式下，Operator 是即时执行的，即用户每调用一个飞桨paddleAPI，API均会马上执行返回结果。在模型训练过程中，在运行前向 Operator 的同时，框架底层会自动记录对应的反向 Operator 所需的信息，即一边执行前向网络，另一边同时构建反向计算图。
举例来说，在只有relu和sum两个算子的网络中，动态图执行流程如下代码注释。
import numpy as np
import paddle
x_np = np.random.random([4, 5]).astype('float32')
x = paddle.to_tensor(x_np)
# 运行前向relu算子，记录反向relu信息
y = paddle.nn.functional.relu(x)
# 运行前向sum算子，记录反向sum信息
z = paddle.sum(y)
# 根据反向计算图执行反向
z.backward()
- 当用户调用 y = paddle.nn.functional.relu(x) 时，框架底层会执行如下两个操作：
- 调用relu算子，根据输入x计算输出y。
- 记录relu反向算子需要的信息。relu算子的反向计算公式为 x_grad = y_grad * (y > 0) ，因此反向计算需要前向输出变量y，在构建反向计算图时会将y的信息记录下来。
- 当用户调用 z = paddle.sum(y) 时，框架底层会执行如下两个操作：
- 因为这里是将y的所有元素求和，是reduce_sum，调用reduce_sum算子，根据输入y计算出z。
- 记录reduce_sum反向算子需要的信息。reduce_sum算子的反向计算公式为 y_grad = z_grad.broadcast(y.shape) ，因此反向计算需要前向输入变量y，在构建反向计算图时会将y的信息记录下来。
由于前向计算的同时，反向算子所需的信息已经记录下来，即反向计算图已构建完毕，因此后续用户调用 z.backward() 的时候即可根据反向计算图执行反向算子，完成网络反向计算，即依次执行：
z_grad = [1] # 反向执行的起点z_grad为[1]
y_grad = z_grad.broadcast(y.shape) # 执行reduce_sum的反向算子：y_grad为与y维度相同的Tensor，每个元素值均为1
x_grad = y_grad * (y > 0) # 执行relu的反向算子：x_grad为与y维度相同的Tensor，每个元素值为1（当y > 0时）或0（当y <= 0时）
说明：
- 在使用GPU计算时，为了保证更高的执行效率，框架本身不会等待前向 Operator 的CUDA Kernel 执行完毕后才返回。即在Python端用户构建网络的同时，C++后端可能仍在异步地执行CUDA Kernel。只有在用户需要获得 Tensor 的值时（例如调用 y.numpy() ），框架才会等待CUDA Kernel执行完毕。这样既保证了运算的高效性，又保证了用户能获取到正确的 Tensor 值。
- 在模型预测过程中，用户调用了 layer.eval() 切换到预测模式时，框架在运行前向 Operator 后将不再记录反向信息。此时会更加节省存储资源，这是因为反向 Operator 往往需要前向 Tensor 参与反向计算，若用户切换到预测模式，则不会记录反向 Operator ，同时反向 Operator 所需的前向Tensor 亦能得到及时释放。
动态图变量和算子的底层表示
由于动态图模式下算子是即时执行，可即时获得变量的计算结果，因此动态图的变量和算子必须存储有运行时的信息。动态图的变量和算子在C++端分别以 VarBase 和 OpBase 的数据结构表示。
动态图的变量表示
VarBase 的主要成员为：
class OpBase;
class VarBase {
Variable var_;
std::shared_ptr<VarBase> grad_var_;
std::vector<std::shared_ptr<OpBase>> grad_ops_;
};
- var_: 用于存储运行时的Tensor信息。例如，当用户在Python端调用 tensor.numpy() 接口时会返回 var_ 中存储的Tensor数值。
- grad_var_: 用于存储该变量对应的反向梯度变量。 VarBase 存储 grad_var_ 的目的是便于根据前向变量找到一次反向梯度变量，根据一次反向梯度变量找到二次反向梯度变量，依此类推。
例如，当用户在Python端调用 tensor.gradient() 接口时会返回 grad_var_ ；若变量不需要计算梯度，则 grad_var_ 为空。若某个变量存在二次反向梯度，则用户可在Python端调用 tensor.gradient().gradient() 获得之（即返回C++端的grad_var_->grad_var_）。
- grad_ops_: 用于存储以变量为输入的反向算子列表，仅对反向梯度变量有效，对于前向变量此域为空。grad_ops_ 的目的是在计算前向算子的同时，辅助构建反向计算图。
动态图的算子表示
OpBase 的主要成员为：
class OpBase {
GradVarMap grad_ins_;
GradVarMap grad_outs_;
std::vector<std::shared_ptr<OpBase>> grad_pending_ops_;
};
- grad_ins_: 反向算子所有输入构成的映射表，其key为反向算子的输入slot，value为输入的 VarBase 。
- grad_outs_: 反向算子所有输出构成的映射表，其key为反向算子的输出slot，value为输出的 VarBase 。
- grad_pending_ops_: 反向计算图中该反向算子的后继算子列表。
动态图底层执行逻辑的实现
当用户在Python端调用飞桨paddle的前向算子API时，动态图框架底层将执行以下操作：
- 根据输入inputs，运行前向算子，得到输出outputs。
- 若前向算子不需要计算梯度，则直接返回。
- 若前向算子需要计算梯度，则创建对应的反向算子列表grad_ops（ std::vector<std::shared_ptr<OpBase>> 类型）。
- 对于grad_ops中每个反向算子grad_op，执行下述操作：
- 设置grad_op的输入变量 grad_ins_ 和输出变量 grad_outs_ 。其中，grad_ins_ 可能包含：前向输入变量forward_inputs、前向输出变量forward_outputs以及前向输出变量的梯度forward_outputs_grads； grad_outs_ 包含前向输入变量的梯度forward_inputs_grads。
- 将grad_op添加到每个前向输出变量的梯度forward_outputs_grads的 grad_ops_ 域中，表示此变量为grad_op的输入。
- 设置grad_op的grad_pending_ops_ 域等于 grad_outs_ 的 grad_ops_ 域的总和，表示grad_op的后继反向算子为以 grad_outs_ 为输入的所有反向算子。
下面以一段动态图代码示意动态图前向运行和反向图的构建过程：
import paddle
class ExampleLayer(paddle.nn.Layer):
def __init__(self):
super(ExampleLayer, self).__init__()
self._embedding1 = paddle.nn.Embedding(size=[128, 10])
self._embedding2 = paddle.nn.Embedding(size=[128, 10])
def forward(self, x):
emb1 = self._embedding1(x) # 语句1
emb2 = self._embedding2(x) # 语句2
mul_out = emb1 * emb2 # 语句3
relu_out = paddle.nn.functional.relu(mul_out) # 语句4
return relu_out
代码对应的前向计算图和反向计算图如 图6 所示。
图6 动态图代码示例的前向计算图和反向计算图
图中W1和W2分别是代码中两个Embedding层的词表参数，@GRAD表示梯度变量，飞桨paddleEmbedding底层的算子为lookup_table。上述代码每个语句执行完毕后，反向计算图的变化如下所述：
- 语句1：构建第一个反向算子lookup_table_grad，其输入为emb1@GRAD，输出为W1@GRAD，后继的反向算子为空。因为Embedding层的输入x不需要梯度，因此反向计算图中不含x@GRAD。
- 语句2：构建第二个反向算子lookup_table_grad，其输入为emb2@GRAD，输出为W2@GRAD，后继的反向算子为空。因为Embedding层的输入x不需要梯度，因此反向计算图中不含x@GRAD。
- 语句3：构建第三个反向算子elementwise_mul_grad，其输入为mul_out@GRAD，输出为emb1@GRAD和emb2@GRAD，后继的反向算子为前述构建的2个lookup_table_grad算子。
- 语句4：构建第四个反向算子relu_grad，其输入为relu_out@GRAD，输出为mul_out@GRAD，后继的反向算子为elementwise_mul_grad。
梯度自动计算Autograd
由于前向组网过程中，框架已自动记录了反向计算图。当用户调用 tensor.backward() 的时候，框架会从调用该接口的 VarBase 节点开始，根据图依赖关系遍历执行反向计算图的每个 OpBase ，并进行相应的梯度累加，完成梯度自动计算Autograd的过程。
以 图7（反向计算图） 为例，假设调用 backward() 接口的变量为relu_out@GRAD，则Autograd的具体流程为：
- 计算每个反向算子的依赖数dependency_num，即其前继算子的数量。
对于 图7（反向计算图） ，所有算子均只有1个前继算子，因此每个算子的依赖数均为1。
- 声明一个空的算子队列queue，并将调用 backward() 接口的变量的 grad_ops_ 进入算子队列queue。
对于 图7（反向计算图） ，将relu_out@GRAD的 grad_ops_ 即relu_grad进入算子队列queue。
- 若算子队列queue未空，则取出队列头部的算子op，执行下述操作：
- 执行反向算子op。
- 遍历反向算子op的 grad_pending_ops_ 域，将其每个后继算子的依赖数dependency_num减1。若某个后继算子的依赖数减至0，说明此算子的所有前继算子均以执行完毕，可以开始执行此算子，将此算子加入算子队列queue。
对于 图7（反向计算图） ，具体的执行流程为：
- relu_grad算子出队列queue并执行，然后将elementwise_mul_grad算子加入队列queue，此时队列queue剩余1个算子。
- elementwise_mul_grad算子出队列queue并执行，然后将2个lookup_table_grad算子加入队列queue，此时队列queue剩余2个算子。
- 第一个lookup_table_grad算子出队列queue并执行，无算子需要加入队列queue，此时队列queue剩余1个算子。
- 第二个lookup_table_grad算子出队列queue并执行，无算子需要加入队列queue，此时队列queue剩余0个算子，为空。
- 若算子队列queue为空，则说明反向计算图中的所有算子均已执行完毕，Autograd计算完成。
变量生命周期管理
动态图的变量可能同时被飞桨paddlePython前端和C++后端持有，只有在Python前端和C++后端均不需要该变量时，变量才能被释放，否则可能出现内存泄漏或重复释放。 对此，飞桨paddle采用自动引用计数的方式，管理每个变量的生命周期，保证无论变量的最后一次引用出现在Python前端还是C++后端，均能被正确、自动地释放，实现了变量生命周期管理的自动管理。
动态图和静态图的异同
由上述动态图和静态图的底层实现可知，动态图模式和静态图模式底层算子实现的方法是相同的，最大的不同点在于：
- 在静态图模式下，完整的网络结构在执行前是已知的，因此图优化分析的灵活性比较大，往往执行性能更佳，但调试难度大。
以算子融合Operator Fusion为例，假设网络中有3个变量x，y，z和2个算子tanh和relu。在静态图模式下，可以分析出变量y在后续的网络中是否还会被使用，如果不再使用y，则可以将算子tanh和relu融合为一个粗粒度的算子，消除中间变量y，以提高执行效率。
y = tanh(x)
z = relu(y)
- 在动态图模式下，完整的网络结构在执行前是未知的，因此图优化分析的灵活性比较低，执行性能往往不如静态图，但调试方便。
仍以Operator Fusion为例，因为后续网络结构未知，无法得知变量y在后续的网络中是否还会被使用，因此难以执行算子融合操作。但因为算子即时执行，随时均可输出网络的计算结果，更易于调试。