企业官网建设流程全解析

在 PaddlePaddle 里写代码，绕不开的一件事就是先决定用哪种编程模式：动态图还是静态图。这两个词几乎每个刚上手的人都会碰到，但真正能把它们讲清楚、并且在项目里选对的人并不多。我见过太多情况——有人全程用动态图写训练脚本，跑得挺顺，一到部署阶段发现导出模型一堆坑；也有人听说静态图性能好，一上来就用paddle.enable_static()写，结果调个形状错误要打印半天，最后又退回动态图。这篇内容就是想把这两种模式从底层逻辑、写法差异、性能边界到实际选型，一次性摊开讲明白，顺带把环境准备阶段最容易卡住人的镜像源配置部分写细。适合刚接触 PaddlePaddle、想在两种模式之间做选择的人，也适合已经写了很久动态图、想搞清楚静态图到底强在哪里的开发者。

1. 两种编程模式的分野：先弄清它们各自解决什么问题

1.1 用做饭打比方：动态图是边炒边尝，静态图是先写菜谱再开火

理解动态图和静态图，最省事的办法是拿做饭类比。动态图就像站在灶台前炒菜，放一勺盐、尝一口、不够再加半勺，每一步的结果立刻能感知到，随时能调整。你在 PaddlePaddle 动态图模式下写y = model(x)，这一行执行完，y就是一个实实在在的张量，里面装着具体数值，你可以直接print(y.shape)、可以画图、可以中断调试。代码的执行顺序和你阅读代码的顺序完全一致，这是它最讨人喜欢的地方。

静态图则相反，它是先把整道菜的菜谱（计算图）完整写下来，交给厨房（执行器）去按流程做，你在写菜谱的时候手里是没有成品可以尝的。在静态图里写logits = paddle.static.nn.fc(x, size=10)，这个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_dim=784, hidden=256, num_classes=10): 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(name='x', shape=[-1, 784], dtype='float32') hidden = paddle.static.nn.fc(x, size=256, activation='relu') logits = paddle.static.nn.fc(hidden, size=10) loss = paddle.mean( paddle.nn.functional.cross_entropy(logits, paddle.static.data( name='label', shape=[-1], dtype='int64')) ) 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 版叫paddlepaddle，GPU 版叫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\activate

2.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.conf，Windows 在%APPDATA%\pip\pip.ini），后续所有pip install都会走这个源。第二条trusted-host只在镜像站使用自签证书或者纯 HTTP 时才需要，走正规 HTTPS 的站点通常不用配；但配上也基本无害，属于"多写一行不亏"的保险项。想确认配置是否生效，跑pip config list就能看到当前生效的所有项。

第三种：conda 环境下的.condarc配置。

如果你用 conda 管理环境，pip 的配置对 conda 装包不起作用，需要在用户目录下编辑.condarc：

channels: - 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 paddlepaddle

pip 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_gradient=False) b = paddle.to_tensor([1.0], stop_gradient=False) x = paddle.to_tensor([3.0], stop_gradient=False) 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 = (wx+b)^2，对w求导是2(wx+b)·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_dim=784, hidden=256, num_classes=10): 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_rate=1e-3, parameters=model.parameters(), weight_decay=1e-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(axis=1) == y).astype('float32').mean() print(f"epoch {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 或者 Inf：

paddle.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()表示 CPU，paddle.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(name='x', shape=[-1, 784], dtype='float32') label = paddle.static.data(name='label', shape=[-1], dtype='int64') hidden = paddle.static.nn.fc(x, size=256, activation='relu') logits = paddle.static.nn.fc(hidden, size=10) loss = paddle.mean(paddle.nn.functional.cross_entropy(logits, label)) acc = paddle.mean( paddle.cast(logits.argmax(axis=1) == label, 'float32') ) optimizer = paddle.optimizer.Adam(learning_rate=1e-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(f"step {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], dtype='float32')] static_model = paddle.jit.to_static(model, input_spec=input_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 一张对比表把差异说清楚

把前面讲的东西收敛成一张表，选型的时候直接对着看：

这张表里最容易被人低估的是"调试体验"这一行。开发期的时间成本往往被忽略，但实际项目里改代码、找 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.9，manylinux表示 Linux 平台。这些标记必须和目标环境对上。

6.2 动静转换相关的坑

to_static之后输出形状和动态图对不上。最常见的成因是 InputSpec 写错了，尤其是 batch 维写死。还有一种情况是模型里有依赖具体数值的分支，转换后走了另一条路径。排查办法是构造一个固定输入的对照测试：同一份输入分别喂给动态图模型和转换后的模型，逐元素比较输出差异。

转换成功但推理结果是 NaN。优先检查是不是忘了model.eval()，其次是检查输入数据的预处理和训练时是否一致。归一化参数不一致、数据类型不一致（float64 喂给 float32 模型），都会导致这种问题。

保存的模型加载时报 key 不匹配。通常是模型结构在保存和加载之间发生过改动。jit.save保存的是结构加参数，结构变了就对不上。所以导出推理模型要放在结构完全定稿之后，或者干脆在导出脚本里重建一次模型再加载参数。

动态控制流的模型转不了。把分支逻辑尽量移到模型外面，用 Python 层的判断来决定调用哪个子模型，而不是在forward里根据张量值分支。如果确实需要数据相关的控制流，去看框架提供的控制流算子，但要注意这类算子对导出和后续部署有额外约束。

6.3 性能和显存相关的问题

训练过程中显存持续上涨直到 OOM。这是典型的梯度或中间变量泄漏。检查是不是有地方在循环里累积了张量（比如把每步的 loss 存进列表），或者是不是用了retain_graph=True又没释放。还有一种情况是动态图下某些算子的输出被意外持有，可以用显存监控工具观察每一步的增量。

静态图训练比动态图还慢。不要默认静态图一定快。检查是不是 batch size 太小导致图优化的收益体现不出来，或者数据 feeding 成了瓶颈。静态图的feed是通过字典传 numpy 数组，如果数据预处理本身很重，那这部分开销在两种模式下是一样的。另外确认一下是不是误跑了 CPU 模式。

多卡训练时各卡负载不均。数据并行下如果最后一个 batch 大小和其他不一致，会出现某张卡先结束然后空转。把drop_last打开，或者让数据长度能被卡数整除，能缓解这个问题。

6.4 一张速查表收尾

我在实际写这两套代码时的体会是，动态图和静态图的分界线其实不在"哪个更好"，而在"你现在处在项目的哪个阶段"。开发期所有精力都该花在验证想法上，任何增加反馈延迟的东西都是负担；部署期所有精力都该花在压成本和压延迟上，任何多余的开销都是浪费。把这两件事分开看，选型就不再纠结了。另外有个小技巧分享：如果你不确定某个模型能不能顺利转成静态图，别等到训练完再试，在模型结构定下来的第一时间就写一个只有几行的小脚本，用随机输入跑一遍to_static加jit.save加jit.load。这个动作大概花五分钟，但能提前暴露掉所有形状和动态控制流的问题，比训练完三天之后发现导不出来要划算太多。