PaddlePaddle动态图与静态图：原理、性能对比与工程选型

在 PaddlePaddle 里写代码绕不开的一件事就是先决定用哪种编程模式动态图还是静态图。这两个词几乎每个刚上手的人都会碰到但真正能把它们讲清楚、并且在项目里选对的人并不多。我见过太多情况——有人全程用动态图写训练脚本跑得挺顺一到部署阶段发现导出模型一堆坑也有人听说静态图性能好一上来就用paddle.enable_static()写结果调个形状错误要打印半天最后又退回动态图。这篇内容就是想把这两种模式从底层逻辑、写法差异、性能边界到实际选型一次性摊开讲明白顺带把环境准备阶段最容易卡住人的镜像源配置部分写细。适合刚接触 PaddlePaddle、想在两种模式之间做选择的人也适合已经写了很久动态图、想搞清楚静态图到底强在哪里的开发者。1. 两种编程模式的分野先弄清它们各自解决什么问题1.1 用做饭打比方动态图是边炒边尝静态图是先写菜谱再开火理解动态图和静态图最省事的办法是拿做饭类比。动态图就像站在灶台前炒菜放一勺盐、尝一口、不够再加半勺每一步的结果立刻能感知到随时能调整。你在 PaddlePaddle 动态图模式下写y model(x)这一行执行完y就是一个实实在在的张量里面装着具体数值你可以直接print(y.shape)、可以画图、可以中断调试。代码的执行顺序和你阅读代码的顺序完全一致这是它最讨人喜欢的地方。静态图则相反它是先把整道菜的菜谱计算图完整写下来交给厨房执行器去按流程做你在写菜谱的时候手里是没有成品可以尝的。在静态图里写logits paddle.static.nn.fc(x, size10)这个logits并不是一个装了数字的张量而是一个占位描述——它只知道自己是干什么的、形状是什么但不知道具体值。真正算出数值要等到Executor.run()那一刻。这就是所谓的先定义、后执行define-and-run而动态图是边定义、边执行define-by-run。这个差异听起来只是个时序问题实际上牵扯出一连串连锁反应。因为静态图在真正跑之前就拿到了完整的计算图框架有机会对整张图做全局优化把能合并的算子合并、把不会再被用到的中间变量提前释放、把内存分配规划好。动态图做不到这一点它每执行一行只知道这一行的事像个只看得见眼前一步的司机。所以静态图在推理部署、大吞吐训练场景里通常更快而动态图在开发调试阶段更省心。1.2 同一份全连接网络两种写法摆在一起看光讲概念不直观直接上代码对照。假设要搭一个三层全连接网络做十分类动态图的写法是这样的import paddle import paddle.nn as nn class MLP(nn.Layer): def __init__(self, in_dim784, hidden256, num_classes10): super().__init__() self.fc1 nn.Linear(in_dim, hidden) self.act nn.ReLU() self.fc2 nn.Linear(hidden, num_classes) def forward(self, x): return self.fc2(self.act(self.fc1(x))) model MLP() print(model) # 立刻能看到层结构 x paddle.randn([4, 784]) out model(x) print(out.shape, out.dtype) # 立刻能看到输出形状这段代码里model(x)执行完out里就是真实数值你可以对它做任何 NumPy 式的操作。paddle.nn.Layer在动态图下是活的它的forward每调用一次就真的走一遍。同样的网络静态图版本要换个写法import paddle paddle.enable_static() main_prog paddle.static.Program() startup_prog paddle.static.Program() with paddle.static.program_guard(main_prog, startup_prog): x paddle.static.data(namex, shape[-1, 784], dtypefloat32) hidden paddle.static.nn.fc(x, size256, activationrelu) logits paddle.static.nn.fc(hidden, size10) loss paddle.mean( paddle.nn.functional.cross_entropy(logits, paddle.static.data( namelabel, shape[-1], dtypeint64)) ) print(type(logits)) # 输出的是 Variable不是一个装着数字的张量 print(logits.shape) # 只有形状信息没有值注意几个关键区别。第一输入必须用paddle.static.data声明成占位符placeholder要指定name、shape、dtype其中-1表示这个维度在运行时才确定通常就是 batch 维。第二logits是Variable类型打印它得不到数值。第三整个组网过程被包在program_guard里这是因为静态图允许同时存在多个 Program主程序和启动程序program_guard负责告诉框架接下来定义的东西挂到哪个 Program 上。这两段代码的差距本质上就是立刻算和先记账后算的差距。很多从 PyTorch 转过来的开发者第一次看到静态图代码会觉得别扭原因就在这里——所有的直觉都建立在能看到值这个前提上而这个前提在静态图里被拿掉了。1.3 为什么框架要两套都留着而不是二选一有人会问既然静态图更快为什么不一上来就用静态图或者既然动态图好用为什么还要留着静态图这套东西答案在于它们服务的目标完全不同。动态图服务的是开发期。开发期的核心诉求是反馈快、调试容易、实验迭代成本低。你在研究一个新结构可能要改十几次网络每次都希望能立刻打印中间张量的统计量、能打断点、能在任意一行插一句print。这些在动态图里都是天然支持的在静态图里就非常麻烦——你没法在图还没执行的时候看到一个中间变量的值。静态图服务的是运行期。运行期的核心诉求是吞吐高、延迟低、内存占用可控、能脱离 Python 环境独立部署。模型训练好了要上生产这时候改代码的频率降到很低优化空间就变得值钱算子融合能减少 kernel 启动开销内存复用能降低峰值占用图级别的剪枝能去掉无用的分支。这些都需要一张完整的图才能做。PaddlePaddle 在新版本里默认使用动态图但保留了完整的静态图能力并且提供了paddle.jit.to_static这条动静转换通道。这个设计的意图很明确用动态图开发用静态图部署。你可以在动态图里舒舒服服地把模型写完、调好、训完最后用一行装饰器或者一个函数调用把它转成静态图去跑推理。这是目前最主流的工程实践后面第 4 章会详细展开转换的具体做法和踩坑点。提示不要在项目一开始就纠结到底选哪个正确答案通常是开发用动态图部署用静态图两者不是互斥关系而是同一项目的两个阶段。2. 环境准备镜像源配置与环境验证的完整流程2.1 装之前先把版本对齐能省掉一半的麻烦PaddlePaddle 的安装包按硬件后端和版本分成好几类装错一个就得重来。装之前至少要确认三件事是 CPU 还是 GPU、Python 版本、如果装 GPU 版本地运行环境的版本是否匹配。这里的运行环境指的是显卡驱动和 CUDA 相关组件PaddlePaddle 的 GPU 包对它们有版本要求具体对应关系以官方安装说明的版本矩阵为准不要凭记忆拍脑袋。包名上有个容易踩的点CPU 版叫paddlepaddleGPU 版叫paddlepaddle-gpu。这两个包如果装在同一个环境里会互相覆盖出问题时现象很迷惑——比如你以为装的是 GPU 版结果paddle.device.get_device()返回cpu。排查的第一步永远是python -c import paddle; print(paddle.__version__) python -c import paddle; print(paddle.device.get_device()) python -c import paddle; paddle.utils.run_check()run_check()会跑一个小规模的矩阵运算并给你一份体检报告把编译选项、设备、算子可用性都列出来。这个命令在装完环境后必跑比任何猜测都可靠。Python 版本这块尽量选 3.8 到 3.11 之间的主流版本。太新的 Python 经常出现某个依赖还没有对应 wheel 包的情况而这类问题的报错信息往往指向一个和 PaddlePaddle 毫无关系的包名非常浪费排查时间。我的习惯是新建一个干净的虚拟环境再装不要在系统环境或者已经装了几十个包的老环境里动手出了问题隔离起来方便。python -m venv paddle_env source paddle_env/bin/activate # Windows 下是 paddle_env\Scripts\activate2.2 pip 与 conda 的镜像源配置三种写法各管一段安装包体积不小GPU 版动辄几百 MB直连官方源在国内环境下经常慢到让人放弃。这时候就要配软件源镜像——注意这里说的镜像指的是包仓库的副本站点不是系统镜像也不是容器镜像三者概念不同配置位置也不一样。下面把三种常见写法都列清楚。第一种临时指定只对当前这条命令生效。pip install paddlepaddle -i https://镜像站地址/simple好处是不污染全局配置适合只是试一下的情况。缺点每次都要敲一长串容易漏。第二种写进 pip 全局配置一次配好长期有效。pip config set global.index-url https://镜像站地址/simple pip config set global.trusted-host 镜像站域名第一条命令会在用户目录下生成配置文件Linux/macOS 一般在~/.config/pip/pip.confWindows 在%APPDATA%\pip\pip.ini后续所有pip install都会走这个源。第二条trusted-host只在镜像站使用自签证书或者纯 HTTP 时才需要走正规 HTTPS 的站点通常不用配但配上也基本无害属于多写一行不亏的保险项。想确认配置是否生效跑pip config list就能看到当前生效的所有项。第三种conda 环境下的.condarc配置。如果你用 conda 管理环境pip 的配置对 conda 装包不起作用需要在用户目录下编辑.condarcchannels: - defaults show_channel_urls: true default_channels: - https://镜像站地址/anaconda/pkgs/main - https://镜像站地址/anaconda/pkgs/r custom_channels: conda-forge: https://镜像站地址/anaconda/cloud改完之后用conda config --show channels确认一下顺序。这里有个细节值得说channels里默认带的那条defaults如果不清掉conda 还是会先去官方地址找导致你以为配了镜像但速度没变。把defaults换成nodefaults或者直接删掉效果才彻底。注意镜像站地址会变配置的时候尽量用当前可用的地址并且把地址写在一个自己的小抄文件里。我曾经因为长期没更新配置里的地址导致一次环境重建时卡了近半小时最后才发现是源不可达报错信息还相当含蓄。2.3 容器镜像与离线安装包的准备思路团队协作或者需要在多台机器上跑同一个环境的场景靠 pip 一个个装太脆弱通常走两条路。走容器路线把环境固化成一个镜像所有依赖在构建时一次性装好。好处是环境完全可复现换台机器docker run就起来了。构建时同样需要配置包源写在 Dockerfile 的RUN指令里即可FROM 基础镜像地址:标签 RUN pip config set global.index-url https://镜像站地址/simple \ pip install --no-cache-dir paddlepaddle-gpu版本号--no-cache-dir这个参数值得加它让 pip 不把 wheel 缓存留在镜像层里镜像体积能小一大截。我在早期不做这件事的时候一个本来 3GB 左右的镜像被缓存撑到 6GB 多拉取时间翻倍。走离线包路线目标机器不能联网时先在能联网的机器上把包和依赖全下载下来pip download -d ./offline_wheels paddlepaddle版本号 # 目标机器上 pip install --no-index --find-links./offline_wheels paddlepaddlepip download会把当前平台匹配的所有依赖一起拉下来所以下载机器的操作系统和 Python 版本要和目标机器一致否则装的时候会缺包。这一点非常容易忽略——在 Mac 上下载的 wheel 拿到 Linux 上装大概率会报找不到匹配的发行版。2.4 装完必做的五项验证环境装好不等于能用按顺序过一遍这几项能提前发现九成的隐患。第一项导入和版本。import paddle不报错只是及格线还要看版本号是否是你想要的那个。第二项设备确认。paddle.device.get_device()返回gpu:0说明 GPU 侧通了返回cpu就得去查驱动和包版本是否匹配。第三项run_check()全绿。第四项跑一个最小的动态图算子比如paddle.matmul两个小矩阵确认前向和反向都能走通。第五项如果要用静态图paddle.enable_static()之后再跑一遍组网确认 Executor 能正常初始化。import paddle paddle.utils.run_check() a paddle.randn([32, 32]) b paddle.randn([32, 32]) c paddle.matmul(a, b) c.sum().backward() print(dynamic ok:, c.shape, a.grad is not None) paddle.enable_static() prog paddle.static.Program() startup paddle.static.Program() with paddle.static.program_guard(prog, startup): x paddle.static.data(x, [-1, 32], float32) y paddle.mean(x * 2 1) exe paddle.static.Executor(paddle.CPUPlace()) exe.run(startup) out, exe.run(prog, feed{x: [[1.0] * 32]}, fetch_list[y]) print(static ok:, out) paddle.disable_static()这段脚本跑通说明两种模式的执行链路都是通的可以放心往下写业务代码了。3. 动态图实操从张量手感到完整训练循环3.1 自动微分的直觉建立动态图最值钱的能力是自动微分而理解它的最好方式是先手动观察一次梯度流动。PaddlePaddle 里每个paddle.Tensor都有stop_gradient属性默认是False意思是这个张量需要被追踪梯度。当你把一串运算串起来框架在前向执行的同时默默记下了一条反向链路backward()就是让这条链路倒着走一遍。import paddle w paddle.to_tensor([2.0], stop_gradientFalse) b paddle.to_tensor([1.0], stop_gradientFalse) x paddle.to_tensor([3.0], stop_gradientFalse) y w * x b # y 2*3 1 7 z y * y # z 49 z.backward() print(w.grad) # dz/dw 2*y*x 2*7*3 42 print(x.grad) # dz/dx 2*y*w 2*7*2 28 print(b.grad) # dz/db 2*y 14这里提前手算一遍很有必要z (wxb)^2对w求导是2(wxb)·x代入数值2×7×3 42。跑出来的结果对得上说明你理解了链式法则在框架里是怎么落地的而不是把它当成黑盒。我见过不少人用了一年框架还说不清backward()到底做了什么遇到梯度消失、梯度爆炸这类问题时完全无从下手根源就在这里。一个必须记住的规则梯度是累加的不是覆盖的。同一个张量反复backward().grad会一直往上叠加。所以一个训练循环里每步优化器更新完必须调clear_grad()否则第二轮的梯度就是错的。这个坑我踩过现象是 loss 前几步看着正常然后突然开始发散排查了很久才定位到漏了清梯度。3.2 一个能直接跑的完整训练骨架把上面的东西串起来就是一个标准的动态图训练循环。下面这段代码结构清晰可以直接改成自己的任务import paddle import paddle.nn as nn class MLP(nn.Layer): def __init__(self, in_dim784, hidden256, num_classes10): super().__init__() self.net nn.Sequential( nn.Linear(in_dim, hidden), nn.ReLU(), nn.Dropout(0.2), nn.Linear(hidden, num_classes), ) def forward(self, x): return self.net(x) model MLP() loss_fn nn.CrossEntropyLoss() optimizer paddle.optimizer.Adam( learning_rate1e-3, parametersmodel.parameters(), weight_decay1e-4, ) model.train() for epoch in range(5): for step, (x, y) in enumerate(loader): logits model(x) loss loss_fn(logits, y) loss.backward() optimizer.step() optimizer.clear_grad() if step % 50 0: acc (logits.argmax(axis1) y).astype(float32).mean() print(fepoch {epoch} step {step} loss {loss.item():.4f} acc {acc.item():.4f})这段代码里有几个细节值得单独说。model.train()和后面的model.eval()必须成对出现因为 Dropout 和 BatchNorm 在两种模式下行为完全不同漏掉eval()会导致验证集指标明显偏低这种看起来像模型不收敛的问题最浪费排查时间。loss.item()用来把单元素张量转成 Python 浮点数打印时不会带上一堆张量元信息。optimizer.clear_grad()放在step()之后位置不能反。学习率和 batch size 的关系也有讲究。batch size翻倍时梯度的方差会变小理论上可以把学习率也放大一些经验做法是线性缩放或者平方根缩放。但这不是铁律尤其是用了 Adam 这类自适应优化器之后缩放规则会变得不那么线性。我一般的做法是先用一个保守的学习率1e-3跑通看 loss 曲线的形状再决定要不要调。3.3 动态图下的调试手法比 print 更有效的几招动态图的调试优势不是能 print而是能在任意位置停下来看现场。除了最朴素的print(x.shape, x.mean().item(), x.std().item())还有几种手法值得掌握。第一招检查异常值。训练不稳定时先怀疑有没有 NaN 或者 Infpaddle.isnan(logits).any() # 有没有 NaN paddle.isinf(logits).any() # 有没有 Inf logits.abs().max() # 量级是不是异常大如果某一层的输出量级突然跳到几千上万基本可以确定是初始化或者学习率的问题。第二招逐层打印统计量。写个简单的钩子函数挂到每一层上看激活值的分布怎么随层数变化。这比盯着最终 loss 曲线有用得多能直接定位到是哪一层开始崩的。第三招用小 batch 过拟合一个批次。这是个经典手段拿 8 条数据训练 200 步看 loss 能不能降到接近 0。如果降不下去说明模型或者数据管道有 bug而不是泛化问题。这个办法帮我排掉过好几次数据标签错位的低级错误——模型结构完全没问题就是标签对错了位loss 卡在一个不上不下的值非常迷惑。第四招paddle.seed()固定随机性。调试阶段固定种子能让问题可复现否则同一份代码跑两次结果不同根本没法判断改动是否有效。注意种子要在模型初始化之前设而且如果用了多卡或者多进程还要注意每个进程的种子设置。4. 静态图实操组网、编译、执行三段式拆解4.1 Program、Block、Place、Executor 四个概念静态图的代码读起来别扭多半是因为没搞清这四个东西各自是干嘛的。搞清了之后那些program_guard、Executor.run的写法就变得顺理成章。Program是计算图的容器可以理解成一份完整的施工图纸。一个 Program 里装着整张图的节点和边。静态图里通常有两个 Program主程序main program负责真正的计算启动程序startup program负责参数初始化。为什么要分开因为参数初始化只需要在训练开始时做一次而主程序每步都要跑拆开之后逻辑更清晰也方便框架在加载预训练参数时跳过初始化。Block是 Program 内部的代码块最外层是全局 block控制流比如while_loop、cond会创建子 block。变量有作用域的概念子 block 里定义的变量默认不会泄露到外层。这个机制在写复杂控制流的时候很重要但日常简单模型基本感知不到。Place描述计算发生在哪里——paddle.CPUPlace()表示 CPUpaddle.CUDAPlace(0)表示 0 号 GPU。它是个抽象的地点描述不直接持有资源。Executor是真正干活的执行器拿着 Program 和 Place 去跑。它负责把图翻译成底层算子调用、分配内存、调度执行。所有这些在动态图里都是隐式发生的静态图里需要你显式地把它交出去。把这四个串起来记一句话在某个 Place 上用一个 Executor 执行一个 Program。这句话就是静态图运行模型的全貌。4.2 手写一个静态图训练脚本下面这个脚本是完整可跑的包含组网、损失、优化器、执行四个环节import paddle import numpy as np paddle.enable_static() main_prog paddle.static.Program() startup_prog paddle.static.Program() with paddle.static.program_guard(main_prog, startup_prog): x paddle.static.data(namex, shape[-1, 784], dtypefloat32) label paddle.static.data(namelabel, shape[-1], dtypeint64) hidden paddle.static.nn.fc(x, size256, activationrelu) logits paddle.static.nn.fc(hidden, size10) loss paddle.mean(paddle.nn.functional.cross_entropy(logits, label)) acc paddle.mean( paddle.cast(logits.argmax(axis1) label, float32) ) optimizer paddle.optimizer.Adam(learning_rate1e-3) optimizer.minimize(loss) place paddle.CUDAPlace(0) if paddle.is_compiled_with_cuda() else paddle.CPUPlace() exe paddle.static.Executor(place) exe.run(startup_prog) for step in range(200): batch_x np.random.randn(64, 784).astype(float32) batch_y np.random.randint(0, 10, size(64,)).astype(int64) loss_val, acc_val exe.run( main_prog, feed{x: batch_x, label: batch_y}, fetch_list[loss, acc], ) if step % 20 0: print(fstep {step} loss {loss_val:.4f} acc {acc_val:.4f})几个必须注意的点。paddle.static.data的name参数是后续feed的键名写错了会报找不到输入变量而且报错信息里不会明确告诉你是哪个键名拼错了只能对着代码核对。optimizer.minimize(loss)这一步会自动把反向算子和参数更新算子都追加到当前 Program 里所以它必须在program_guard内部调用否则算子会挂到默认 Program 上去跑起来就找不到它们。fetch_list里放的必须是图里的节点取出来的结果是 numpy 数组不是张量。还有一个容易困惑的地方为什么静态图里没有backward()因为minimize()已经把反向传播和参数更新都编进图里了执行的时候是一整套一起跑的。这也解释了为什么静态图的调试难——你没法在中间插一句看梯度梯度计算本身是图的一部分。4.3 动静转换把动态图代码变成静态图手写静态图适合学习和特殊场景实际工程里更常用的是动静转换动态图里写好模型用paddle.jit.to_static转成静态图再做导出和部署。这条路的好处是同一份模型代码两用不用维护两套。转换的第一步是准备 InputSpec告诉框架输入的形状和类型。这一步是必须的因为静态图需要在组网前就知道输入的结构import paddle model MLP() model.eval() input_spec [paddle.static.InputSpec(shape[None, 784], dtypefloat32)] static_model paddle.jit.to_static(model, input_specinput_spec) # 保存成推理模型 paddle.jit.save(static_model, inference/mlp) # 加载使用 loaded paddle.jit.load(inference/mlp) out loaded(paddle.randn([1, 784])) print(out.shape)InputSpec里的None表示这个维度可变通常用在 batch 维上。如果你把 batch 维写死成[1, 784]导出的模型就只接受 batch size 为 1 的输入部署时喂一个 batch 是 8 的数据会直接报错。这个错误在本地测试时完全发现不了因为测试通常就是单条数据上线之后才炸。我的习惯是 batch 维一律写None除非有明确的固定 batch 需求。转换过程中最常见的坑是动态控制流。动态图里你可以写if x.sum() 0:这种依赖张量值的分支静态图转换时会尝试把它变成图上的条件算子但如果逻辑太复杂比如在分支里改变了张量形状、或者嵌套了好几层 Python 层的循环转换就会失败或者语义发生变化。规避办法是把这类逻辑抽到模型外面或者用paddle.jit.to_static的full_graph参数控制转换粒度。另一个坑是训练态和推理态的差异。to_static之前一定要调model.eval()让 Dropout 和 BatchNorm 切到推理行为。如果你忘了这一步导出的模型里 Dropout 还在随机丢弃推理结果会不稳定——同一个输入跑两次结果不一样这种问题排查起来相当费劲。4.4 静态图真正提速的地方在哪静态图快但不是所有场景都快。搞清楚它在哪里省时间才能判断你的项目值不值得转。第一个省的是算子启动开销。动态图每执行一个算子都要走一遍 Python 到 C 的调用、参数检查、内存分配。小算子多的时候这部分开销很可观。静态图把这些调用一次性编好执行时循环跑省掉了大量重复的调度成本。网络越深、算子越碎这个收益越明显。第二个省的是内存。静态图在执行前能算出每个中间变量的生命周期把不再需要的显存及时回收让不同的变量复用同一块显存。动态图只能靠引用计数遇到复杂的前向结构时峰值占用会偏高。粗略估算一下一个 784→512→256→10 的四层网络参数量约 53.6 万float32 下权重本身约 2.1MB如果用 Adam 优化器还要额外存一阶动量和二阶动量各一份加上梯度总占用大约是权重本身的 4 倍也就是 8.6MB 左右。这个规模下差别不明显但到了亿级参数的模型内存规划的差异就是能跑和跑不动的区别。第三个省的是算子融合。静态图能识别出卷积 BN 激活这种固定搭配把它们合成一个融合算子一次 kernel 调用干完三件事。这在推理场景收益很大尤其是小分辨率输入、追求极致延迟的场景。反过来说如果你的模型每步都要根据数据动态改变计算路径或者算子数量本来就不多静态图带来的提升可能微乎其微还要付出调试困难、代码可读性下降的代价。这种时候老老实实用动态图更划算。5. 量化对比参数、性能、调试成本逐项拆5.1 一张对比表把差异说清楚把前面讲的东西收敛成一张表选型的时候直接对着看维度动态图静态图执行方式边定义边执行逐行生效先组图后执行两阶段分离中间结果张量持有真实数值可随时打印Variable 只有形状无具体值调试体验支持断点、逐行检查、任意插桩依赖 fetch_list 取指定输出中间量不可见图优化几乎不做全局优化算子融合、内存复用、无用节点消除内存峰值偏高依赖引用计数回收可规划通常更低部署形态需转静态图后才能脱离 Python可直接导出为推理模型代码可读性贴近普通 Python直观需理解 Program/Place/Executor 概念适合阶段开发、实验、研究训练加速、推理部署、批处理学习曲线平缓前期陡理解四个核心概念后平缓这张表里最容易被人低估的是调试体验这一行。开发期的时间成本往往被忽略但实际项目里改代码、找 bug 占的时间远多于跑训练。静态图每次定位问题都要多绕一圈这个成本在小项目里可能还扛得住在复杂模型上会成倍放大。5.2 显存和吞吐的估算方法做技术选型不能凭感觉简单估个数能让决策有据可依。显存这块一个通用的粗估公式是显存 ≈ 参数量 × 每参数字节数 × 优化器倍数 × 梯度检查点系数说明一下各项。每参数字节数在 float32 下是 4混合精度训练下主体权重可能是 2。优化器倍数取决于算法SGD 无动量约 2 倍权重 梯度Adam 约 4 倍权重 梯度 一阶动量 二阶动量。梯度检查点会降低激活值占用但增加计算量。举个具体例子一个 1.1 亿参数的模型用 Adam 训练float32那么参数相关占用约1.1e8 × 4 × 4 ≈ 1.76GB。但这只是参数部分激活值往往才是大头——它跟 batch size、序列长度、层数都相关粗略估计可以按batch_size × 每样本激活字节。所以真实显存需求通常是参数部分的 2 到 5 倍具体取决于模型结构。这个结论很实用看到参数量之后先乘个 4 到 8 倍再和显卡容量对一下能快速判断跑不跑得动。吞吐这块比较公平的方式是在同样的硬件、同样的 batch size 下分别测两种模式的每秒样本数。测试时要注意几点前几步要预热因为第一次执行有编译或缓存构建开销至少要跑 100 步取平均单步测量噪音太大要区分训练和推理两者结论可能完全相反。5.3 选型什么场景该用哪种我给一个自己常用的判断流程按顺序问三个问题。第一个问题这个模型还在频繁改动吗如果答案是是用动态图别犹豫。静态图每次改结构都要重新组网、重新检查形状迭代速度会被拖慢一大截。第二个问题部署环境有没有 Python如果没有必须走静态图导出。这一点是硬约束动态图代码依赖 Python 解释器脱离不了。第三个问题性能瓶颈在哪如果 profile 下来发现瓶颈在数据加载或者 IO那换静态图基本没用如果瓶颈在算子调度开销或者内存带宽上静态图有明确收益。三个问题问完选型基本有答案了。绝大多数项目的实际情况是开发阶段全程动态图训练完成后用to_static转一次做部署只有极少数对训练吞吐有极致要求的场景才会在训练阶段就用静态图。6. 常见问题与排查实录6.1 环境与镜像源相关的问题装完之后get_device()返回cpu。先确认装的是不是paddlepaddle-gpu包再确认运行环境是否匹配。有个隐蔽情况是同一环境里先后装过 CPU 版和 GPU 版后装的覆盖了先装的但残留文件还在导致行为不确定。解决办法是把两个包都卸干净再重新装。pip 装了但 import 报ModuleNotFoundError。八成是装到了另一个 Python 环境里。用which python和pip -V对照一下看两者指向的是不是同一个环境。虚拟环境激活状态在多个终端之间不一致这个坑非常常见。配了镜像源但下载还是慢。检查三件事配置写到了哪个文件用户级还是全局级、当前 shell 有没有重启、pip config list里显示的地址是不是你以为的那个。还有一个情况是镜像站本身响应慢或者临时不可用可以临时换回默认源对比一下排除配置问题。离线安装时报找不到匹配的发行版。下载 wheel 的机器和目标机器的平台或 Python 版本不一致。wheel 文件名里带着平台和版本标记比如cp39表示 CPython 3.9manylinux表示 Linux 平台。这些标记必须和目标环境对上。6.2 动静转换相关的坑to_static之后输出形状和动态图对不上。最常见的成因是 InputSpec 写错了尤其是 batch 维写死。还有一种情况是模型里有依赖具体数值的分支转换后走了另一条路径。排查办法是构造一个固定输入的对照测试同一份输入分别喂给动态图模型和转换后的模型逐元素比较输出差异。转换成功但推理结果是 NaN。优先检查是不是忘了model.eval()其次是检查输入数据的预处理和训练时是否一致。归一化参数不一致、数据类型不一致float64 喂给 float32 模型都会导致这种问题。保存的模型加载时报 key 不匹配。通常是模型结构在保存和加载之间发生过改动。jit.save保存的是结构加参数结构变了就对不上。所以导出推理模型要放在结构完全定稿之后或者干脆在导出脚本里重建一次模型再加载参数。动态控制流的模型转不了。把分支逻辑尽量移到模型外面用 Python 层的判断来决定调用哪个子模型而不是在forward里根据张量值分支。如果确实需要数据相关的控制流去看框架提供的控制流算子但要注意这类算子对导出和后续部署有额外约束。6.3 性能和显存相关的问题训练过程中显存持续上涨直到 OOM。这是典型的梯度或中间变量泄漏。检查是不是有地方在循环里累积了张量比如把每步的 loss 存进列表或者是不是用了retain_graphTrue又没释放。还有一种情况是动态图下某些算子的输出被意外持有可以用显存监控工具观察每一步的增量。静态图训练比动态图还慢。不要默认静态图一定快。检查是不是 batch size 太小导致图优化的收益体现不出来或者数据 feeding 成了瓶颈。静态图的feed是通过字典传 numpy 数组如果数据预处理本身很重那这部分开销在两种模式下是一样的。另外确认一下是不是误跑了 CPU 模式。多卡训练时各卡负载不均。数据并行下如果最后一个 batch 大小和其他不一致会出现某张卡先结束然后空转。把drop_last打开或者让数据长度能被卡数整除能缓解这个问题。6.4 一张速查表收尾现象优先怀疑快速验证设备显示为 cpu装错包或环境不匹配打印paddle.__version__并核对包名import 找不到模块多环境混淆对比which python与pip -V镜像源下载慢配置未生效或源不可达pip config list查看当前配置静态图参数没更新minimize在 guard 外调用检查缩进层级静态图 feed 报错data 的 name 与 feed 键不一致逐个核对字符串转换后输出异常缺eval()或 InputSpec 写死用固定输入做对照测试显存持续增长中间张量被持有监控每步显存增量导出模型只支持单条输入batch 维写成固定值改成None重新导出loss 发散且随机漏了clear_grad()检查优化器调用顺序验证集指标异常偏低忘了切eval()模式检查 train/eval 切换我在实际写这两套代码时的体会是动态图和静态图的分界线其实不在哪个更好而在你现在处在项目的哪个阶段。开发期所有精力都该花在验证想法上任何增加反馈延迟的东西都是负担部署期所有精力都该花在压成本和压延迟上任何多余的开销都是浪费。把这两件事分开看选型就不再纠结了。另外有个小技巧分享如果你不确定某个模型能不能顺利转成静态图别等到训练完再试在模型结构定下来的第一时间就写一个只有几行的小脚本用随机输入跑一遍to_static加jit.save加jit.load。这个动作大概花五分钟但能提前暴露掉所有形状和动态控制流的问题比训练完三天之后发现导不出来要划算太多。