1. 为什么 PyTorch 能在深度学习圈子里反客为主我第一次把 PyTorch 装上服务器的时候PyTorch 还只是某个实验室里的内部工具那时候圈子里大多数人还在用静态图框架写模型。当时的直觉是这个框架怎么这么像 NumPy写出来的代码几乎就是 Python 本身定义模型、改前向逻辑、打断点调试全都跟在写普通脚本一样。这个像 NumPy的直觉恰恰是 PyTorch 后来席卷开发者社区的核心原因。深度学习框架的演进本质上是在表达自由度和执行效率之间反复摇摆。早期静态图框架的思路是你先定义一张完整的计算图再把整张图交给编译器去优化执行。好处是部署快、优化空间大坏处是你不能一边写一边改。你在调试的时候遇到形状不对、维度对不上、梯度为 NaN 这类问题得先把图跑起来才能看到错而图一旦构建好想打印中间结果几乎是不可能的事情。PyTorch 走的是另一条路前向传播的每一行代码都立刻执行框架在背后偷偷地把每一步操作记录成一张动态计算图等到调用 backward 的时候再按这张图反推梯度。这意味着什么意味着你可以用最原始的 print、断点、交互式调试器去检查任何一个中间张量想在哪一步停就在哪一步停。这种设计选择带来的一个直接后果是PyTorch 的调试体验几乎等同于普通 Python 编程。做研究的人最烦的就是写模型的 30% 时间花在排查框架本身的报错上。PyTorch 把框架的抽象层做得很薄除非你主动使用 TorchScript 或大规模分布式能力否则它给你的就是一个支持 GPU 的 NumPy 外加一个自动求导引擎。薄抽象让用户能随时掀开引擎盖看内部发生了什么也就让圈子里形成了一种PyTorch 写起来最顺手的口碑。我后来接手的几个项目团队从静态图框架迁到 PyTorch 之后大家反馈最一致的并不是性能提升了多少而是报错我看得懂了。这篇内容不是 PyTorch 的入门教程而是从一个实际使用者的角度把 PyTorch 里最容易让人困惑的机制和最容易踩坑的工程环节拆开讲一遍。适合三类人看刚入门深度学习、用 PyTorch 写了几个 Demo 但觉得知其然不知其所以然的同学从其他框架切换过来、被动态图和静态图差异搞到头晕的工程师以及已经在用 PyTorch 做实际项目但是对显存治理、复现性、多卡训练这一串问题还没有整理出系统经验的开发者。你会看到很多具体的代码片段和踩坑记录这些都是常规文档里不会写的东西。2. 张量Tensor的底层认知GPU 上不是只有一个数组PyTorch 里最基础的概念是张量很多人把张量简单理解成多维数组这个理解没错但会导致对一系列后续行为的误判。张量真正比 NumPy 多出来的东西不是维度这个概念而是它背后挂着的三种属性数据类型dtype、设备device和布局layout。这三个属性共同决定了张量在内存里怎么放、计算时怎么跑、以及能不能跟其他张量直接做运算。2.1 device 与 data 的绑定关系你在 CPU 上建一个张量和你在 GPU 上建一个张量它们背后是完全不同的内存区域。PyTorch 的设计哲学是显式设备管理——它不会自动帮你把 CPU 上的数据搬到 GPU 上也不会自动搬回来。很多人第一次跑模型报错 Expected all tensors to be on the same device 就是因为模型参数和数据各在一端。这个报错信息写得很清楚它把每个张量所在的设备都列出来了你只需要照着提示把 device 统一即可。我实际写项目时的习惯是在脚本开头就定义好device torch.device(cuda if torch.cuda.is_available() else cpu)然后所有张量创建的地方都显式传入这个 device。但要注意torch.randn(3, 4)这样不带 device 参数的调用仍然会默认放在 CPU 上所以更稳妥的做法是给常用张量统一走.to(device)这一步。.to()这个方法的语义是返回一个位于指定设备上的副本原张量不变它和.cuda()这种硬编码方法完全不同——你在代码里写.cuda()将来换到 CPU 环境就直接报错而.to(device)让同一套代码可以自适应两种环境。2.2 内存布局连续张量与转置的代价张量的 layout 属性是另一个被忽略的底层细节。默认情况下 PyTorch 张量是连续存储的stride 布局中相邻元素按行优先排列但执行transpose、permute这类操作后张量在内存里其实还是原样只是通过新的 stride 步长实现了看起来像转置的效果。这在数学上是一样的但是在计算效率上差异很大。一个非常经典的坑是对转置后的张量做view()操作会直接报错。view()要求张量底层内存连续因为它是靠连续内存块重排形状来实现的而transpose之后张量已经变成了非连续布局必须先用.contiguous()方法让它在内存里重新摆成连续的样子然后再view()。这个报错我第一次遇到时一脸茫然后来才意识到问题本质是内存布局。如果你只是做矩阵乘法转置张量完全没问题PyTorch 的矩阵乘法内核能够直接处理 stride 步长但如果你转置后还要 reshape 或者用某些底层算子就一定要过一遍contiguous()。顺便提醒一句contiguous()也不是无代价的它会触发一次内存拷贝。如果在一个循环里反复对同一个张量做 transpose 再 contiguous性能损耗会被放大。遇到这种场景可以考虑在数据预处理阶段就把布局确定好不要在训练循环里频繁切换。2.3 GPU 张量和 NumPy 的边界PyTorch 和 NumPy 的互操作很方便torch.from_numpy()可以从 NumPy 数组创建张量.numpy()可以把 CPU 上的张量变回 NumPy 数组。但这两个接口有一个共同前提——它们共享内存所以任何一方修改都会影响另一方。这意味着torch.from_numpy()得到的张量和原 NumPy 数组共享底层数据修改张量会改掉 NumPy 数组。GPU 上的张量不能直接.numpy()必须先用.cpu()把数据搬回主存。我在做推理服务的时候经常在这里踩坑模型输出在 GPU 上用.item()取标量还好但取整个数组必须.cpu().numpy()。关于 dtype 还有一条实用规律PyTorch 的默认浮点类型是 float32而 NumPy 在现代环境下常用 float64。当你用torch.from_numpy()传入一个 float64 数组时得到的张量是 float64 的但 CNN 模型的权重通常是 float32两者做运算会直接报错。所以预处理的时候最好先np_array.astype(np.float32)或者干脆用torch.tensor(np_array, dtypetorch.float32)一次性搞定。3. autograd 反向传播一张动态图的完整生命周期autograd 是 PyTorch 最核心的引擎也是新手最容易会用但不懂的部分。我见过很多同学写模型时完全依赖框架自动求导代码能跑通但问起中间发生的细节就说不清楚。这其实不是坏事——框架本来就该帮你处理这些但一旦遇到梯度异常比如某个参数梯度为 0或者 loss 不下降不知道 autograd 的行为逻辑排查起来就非常被动。3.1 叶子张量、非叶子张量和计算图的构建autograd 的精髓可以用一句话概括前向传播的每一次张量运算都会在后台记录一个运算节点节点之间通过引用的方式连成一张有向无环图。如果你对某个张量调用了backward()引擎会从该张量出发沿着图的反方向逐节点计算梯度。每个由用户直接创建、不依赖其他张量计算得来的张量叫做叶子张量leaf tensor。由叶子张量通过运算得到的中间张量叫做非叶子张量。默认情况下autograd 只为叶子张量保存梯度放在.grad属性里非叶子张量的梯度会在反向传播结束后被自动释放以节省内存。这条规则导致了很多隐蔽问题。最常见的你在前向传播时把中间结果存下来打算在 backward 之后读一下的它的梯度结果等反向传播结束那个中间张量的.grad是None。这不是框架坏了而是它故意不给你存。如果你确实需要非叶子张量的梯度可以用.retain_grad()显式要求框架保留。不过这个操作会增加显存开销能不用就不用。3.2 backward 到底做了什么调用loss.backward()时PyTorch 从 loss 张量开始沿计算图反向遍历每个节点计算关于输入的局部梯度并通过链式法则累积到叶子张量的.grad上。注意这里的关键词是累积。如果你在一个循环里多次调用backward()而没有清空梯度梯度会在.grad上不断累加。这就是为什么每个训练步骤开头都要写optimizer.zero_grad()的原因——它把所有参数的梯度清零避免上一次迭代的梯度污染这一次。实际写代码时很多人会把zero_grad()放在backward()前面顺序上是zero_grad - forward - backward - step这没问题。但有一种做法要格外小心如果你在一个 batch 里需要执行两次 backward比如某些对抗训练算法那么两次 backward 之间的梯度会被加在一起然后你只调用一次step()两个任务的梯度就会混合更新。这有时候是有意为之梯度累加模拟大的 batch size有时候是 bug取决于你的意图。如果是刻意做梯度累加来模拟大 batch我记得后续操作是把总梯度除以累加次数否则学习率等于被放大。3.3 图中断detach 和 requires_gradtensor.detach()是我不太建议新手随便用、但用起来又特别顺手的一个方法。它返回一个与当前计算图断开连接的新张量这个新张量的requires_grad是 False也就意味着反向传播根本不会流经它。典型使用场景你想用某个模型的输出作为另一个模型的特征输入但希望特征提取部分的参数不被更新这时就可以用detach()把特征张量隔开。requires_grad是另一个常用的开关。默认情况下从叶子张量出发的运算会自动开启梯度追踪但如果你确定某个中间量不需要梯度把它显式设置成requires_gradFalse可以让 autograd 跳过相关的计算省下不少显存和时间。我在推理阶段做验证时会在外面套一个with torch.no_grad():这比逐张量设置 requires_grad 更干净。3.4 实际调试中常见的梯度异常遇到 loss 不收敛或者直接变成 NaN我的排查顺序是这样的先看输入数据里有没有 NaN 或 Inf——数据问题占一半再看 loss 计算过程里有没有用到会放大数值的操作比如取指数然后做 log数值不稳定很容易爆再看学习率是不是太大试着降低一到两个数量级最后才怀疑模型结构。如果以上都没问题但某些参数的梯度一直为 0就检查该参数的输入路径上有没有被detach()切断或者是不是有某个中间张量的requires_grad被误设成了 False。还有一种隐蔽情况如果用了torch.no_grad()包裹了一段本来需要梯度的前向计算梯度会直接消失。我在有一次复现论文代码时模型结构完全没问题但官方仓库在某个 transform 外面错误地包了no_grad导致整个分支的梯度断裂这个问题花了很长时间才从代码审查里找出来。4. 训练脚本工程化从 Demo 到可复现实验的距离把 PyTorch Demo 跑通很容易但把一个深度学习实验做到别人能复现、自己能继续迭代的工程化状态中间还隔着不少东西。这一节讲的不是算法而是我在实际项目里总结出的训练脚本工程习惯。4.1 nn.Module 的真正价值不是封装很多人理解nn.Module就是一个放层的容器然后在里面塞一堆nn.Linear、nn.Conv2d。这其实只看到了表面。nn.Module的核心价值在于它通过钩子机制自动收集子模块的参数让你可以统一调用.parameters()、.to(device)、.train()、.eval()这些方法而不需要手动管理每个层。这条机制意味着——如果你的自定义层没有继承nn.Module或者你在__init__里把某个子层直接赋给了self之外的地方比如存到一个普通的 list 里那么这些参数就会从你的模型管理体系中漏掉。最典型的坑是self.layers [nn.Linear(10, 20) for _ in range(5)]这样写PyTorch 不会把这些 Linear 的权重注册到模型里因为 Python list 不是 Module 容器结果 optimizer 拿到的参数列表里根本没有它们训练时这些层完全不动。正确做法是self.layers nn.ModuleList([...])。类似的如果你用字典保存子模块应该用nn.ModuleDict。这个细节我在 code review 里提醒过不止一位同事属于没遇到过就不会注意的坑。4.2 训练循环的结构化模板我写训练脚本不会每次都从零开始而是固定一套结构模板在模板上做改动。核心步骤是定义 device、模型、损失函数、优化器、学习率调度器。定义 DataLoader设置 batch size、shuffle、num_workers、pin_memory。进入 epoch 循环每个 epoch 内先写训练阶段model.train()再写验证阶段model.eval()。训练阶段里执行optimizer.zero_grad() - output model(batch) - loss criterion(output, target) - loss.backward() - optimizer.step()。定期记录 loss 和指标往 TensorBoard 或日志文件里写而不是等训练完一次性统计。其中model.train()和model.eval()这两个方法特别容易被忽略。train()模式会启用 Dropout 和 BatchNorm 的统计更新行为eval()模式会关闭 Dropout、让 BatchNorm 使用全局统计量。如果你在验证阶段忘了切回eval()模型的验证结果会不稳定——我见过有人写的验证函数里用的是train()状态结果指标忽高忽低折腾了好几天才意识到是模式切换的问题。4.3 DataLoader 的隐藏性能瓶颈如果一个模型训练过程中 GPU 利用率只有百分之二三十CPU 那侧的数据供给大概率是瓶颈。DataLoader 的关键参数是num_workers它决定了数据加载使用几个子进程。默认值是 0意思是数据在主进程里加载这意味着每取一个 batchGPU 都必须等着 CPU 把图片读出来、做变换、堆成张量。设成大于 0 之后数据加载会并行进行训练吞吐量经常提升好几倍。但num_workers不是越大越好。每个 worker 都会占用一部分 CPU 内存如果设置的 worker 数量太多会让机器 CPU 过载反而拖慢主进程。我的习惯是从min(4, cpu核心数-1)开始测逐个往上加观察 GPU 利用率和 CPU 占用率之间的平衡。对于小数据集worker 数量有个合适区间就够了盲目堆数量没有意义。pin_memoryTrue这个参数也值得说一下。它让 DataLoader 在 CPU 端分配锁页内存pinned memory这样从 CPU 往 GPU 拷贝数据时会走更快的 DMA 路径。我实测下来开启 pin_memory 对训练速度的提升在纯数据密集型任务上可以达到 5% 到 15%而且成本几乎为零所以默认设成 True 是合理的。4.4 随机种子与复现实验的完整方案深度学习实验里有个很烦人的问题同一次运行两次训练结果不完全一样。这不一定是代码有 bug而是随机性在起作用。要尽量做到可复现需要同时固定好几层随机源Python 内置的random、NumPy 的随机数、PyTorch 的随机数以及 CUDA 侧的随机数。我通常会在主脚本开头写这样一段import random import numpy as np import torch def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed)这里torch.manual_seed()能同时覆盖 CPU 和 GPU 的随机数生成器torch.cuda.manual_seed_all()负责所有 GPU。但即便全部设置了还有一个变量在捣乱——cuDNN。cuDNN 的卷积算法在同一个模型里每次选择的可能是不同实现PyTorch 提供了两个额外的开关来约束它torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark FalsedeterministicTrue让 cuDNN 选择确定性的算法benchmarkFalse禁止它根据输入尺寸自动选最快的算法。这两个开关会带来小幅的性能损失但对复现实验是必要的。如果只是做常规训练、不需要精确复现我建议把 benchmark 保持 True因为自动选算法带来的提速在某些模型上很明显。所以复现性和性能往往是一对需要取舍的矛盾。5. 显存治理与多卡训练实操中真正拦住你的那堵墙模型代码写好后下一步通常会撞上一个问题这个模型我放不上显卡或者说批量一大就爆显存。这一节是我觉得最有干货的部分因为很多框架的文档不会把显存管理方式写透但实际做项目时这是最常管道的一道坎。5.1 显存去哪儿了很多人以为显存只装模型参数其实一个训练 batch 的显存开销由几部分组成模型参数、优化器状态比如 Adam 的动量项和二阶矩、每一层的中间激活值、梯度本身。尤其要留意的是中间激活值——它们在前向传播过程中全都被保留下来直到反向传播结束才释放。所以 batch size 翻倍时显存消耗不是简单翻倍而是近似按激活值的量级增加而激活值和 batch size 是线性关系。我见过有人用torch.cuda.max_memory_allocated()观察峰值显存发现比模型参数总量大了十几倍就以为是泄漏。这其实不是泄漏是激活值在正常占用。想要降低这一块的显存占用常见手段有缩小 batch size然后做梯度累加。用混合精度训练AMP把一部分计算放到 float16 下显存占用直接砍掉将近一半。用激活检查点activation checkpointing这是以额外的重计算时间为代价换取中间激活值不全部驻留显存。AMP 是性价比最高的方案。PyTorch 的torch.cuda.amp模块把自动混合精度封装得很简单在 forward 前用autocast()上下文在backward()前用GradScaler()缩放梯度。这套方案在不改动模型结构的情况下通常能获得 20% 到 30% 的显存节省同时训练速度也会提升。难点在于一些自定义的损失函数在 float16 下数值不稳定如果 loss 变成 NaN可能需要把某个敏感操作排除在 autocast 之外。5.2 显存碎片化一个不太被讨论的问题跑长训练任务时你可能遇到一个诡异的现象程序在一开始完全没问题跑了几百个 epoch 之后突然报CUDA out of memory但看nvidia-smi发现显存并没有被其它进程占满。这大概率是显存碎片化导致的。PyTorch 的显存分配器会缓存一小块一小块的显存空间当反复创建和释放不同大小的中间张量时地址空间里就留下很多无法拼接的小空洞累积到一定程度后即使空闲显存总量足够也找不到一块连续的大内存给新张量。缓解办法是检查一下训练循环里是不是有循环内部创建大张量的行为尽量把固定大小的中间张量复用起来。另一个实用技巧是定期调用torch.cuda.empty_cache()释放缓存块让分配器整理一下。不过这个方法不能彻底根治碎片化它只是把可释放的缓存还给缓存池。真正治本的方法应该是如果显存碎片问题很严重先排查 DataLoader 返回的 batch 大小是否稳定有些自定义 collate 函数会产出不同尺寸的张量以及是否有在循环内部反复调用torch.Tensor创建不同形状的中间结果。这两点改进后碎片化问题会明显减少。5.3 从单卡到多卡为什么不要用 DataParallel新手上多卡训练时最容易搜到的是torch.nn.DataParallel因为它写起来最省事套一个壳模型就在多卡上跑了。但我现在不推荐任何人再用 DataParallel除了快速验证时不方便改代码外它的性能天生有瓶颈——它采用的是单进程多线程的方式把每个 batch 分成多份分发到不同 GPU然后在主卡上汇总梯度。这导致主卡的显存和通信带宽成为瓶颈多卡扩展效率比较差尤其在模型很大、梯度通信频繁的时候加速比远不是线性的。正确做法是torch.nn.parallel.DistributedDataParallelDDP。DDP 采用多进程方式每个 GPU 跑一个独立进程每个进程有自己的模型副本数据是各自独立采样的只是在反向传播时通过后端通信同步梯度。这样一来通信只发生在梯度同步那一下主卡瓶颈就被绕开了。虽然 DDP 的启动方式比 DataParallel 稍微复杂一点需要初始化进程组、设置 rank但现代的 PyTorch 已经有torchrun这样的工具能把分布式训练的启动命令简化到一行学习成本比之前低很多。如果你只是想在本机用多卡DDP 也适用不需要真的搭分布式集群。用torchrun --nproc_per_nodeN启动脚本再配合环境变量读取 rank 和 local_rank就能在本机多卡跑起来。我建议第一次尝试 DDP 的人先在一个小模型上把流程跑通再迁移到正式模型上否则同时调试模型本身和分布式机制问题会非常难定位。5.4 梯度累加与有效 batch size梯度累加这个技巧我在前面提过它本质上是用时间换显存。如果你的目标有效 batch size 是 64但显存只够放 batch size 16那你就可以每次喂 16 的 batch连续跑 4 次 backward让梯度累积起来最后做一次 optimizer.step()。注意批次之间的梯度是自动累积的所以千万不能在循环里多次调用optimizer.zero_grad()否则前面几次的梯度就被清掉了。还有一个我一直觉得需要提醒的点梯度累加虽然模拟了大 batch但 BatchNorm 的行为不会自动跟着变。BatchNorm 用的是每个 mini-batch 内的统计量如果实际跑的还是 16 的 batchBN 依然按照 16 的统计量来归一化这种名义上 64、实际上 16的差异会让模型表现和真正的大 batch 不完全一样。如果你在做需要固定 batch 大小的对比实验这一点必须提前想清楚。6. 从研究原型到部署落地PyTorch 生态的边界在哪里PyTorch 常常被划分为研究框架但这几年它的部署能力也在一步步补齐。这一节聊聊我对 PyTorch 生态边界的一些判断和实战经验。6.1 生态组件怎么选用 PyTorch 相关生态时我有一条原则先确认项目是否真的需要这些组件再决定引入。图像相关的任务torchvision是最常见的工具库它不只是提供预训练模型还包含标准的数据集加载器、数据变换和视觉模型的后处理工具。语音相关的任务torchaudio提供了音频文件的解码读入、波形变换、频谱特征计算等能力比从零开始手动处理 PCM 数据要省事得多。自然语言处理任务transformers是目前几乎所有预训练语言模型的事实标准接口不管你是做文本分类、问答还是生成它都能直接加载模型权重和分词器。不过生态组件并不是越多越好。我曾见过有些项目把torchvision当成万能工具箱连简单的图像 resize 都要走它的 transform 接口反而提高了代码耦合度。最佳实践是基础数据变换用自己写的小工具涉及标准视觉任务再引入生态库。生态库的版本升级也是个大坑torchvision和torch的版本必须匹配主要体现在编译时的 CUDA 版本上升级其中一个却不升另一个大概率会碰到二进制不兼容的问题。6.2 部署路径TorchScript、ONNX 与量化部署方面PyTorch 提供了几条路径各有各的适用场景。TorchScript 是把 PyTorch 模型编译成一种可序列化、可独立运行的中间表示。它的好处是可以在没有 Python 的环境里用libtorch跑起来适合 C 服务端部署。但 TorchScript 对模型的兼容性不是 100%代码里有太多动态控制流或者 Python 特有对象时脚本化编译会失败或者产出与预期不符的结果。我的经验是在设计模型时就考虑部署需求尽量把动态分支写好bool 条件里不要用原生 Python 对象做复杂判断如果确实有很动态的逻辑把动态部分放到模型外面处理让 TorchScript 只管纯张量运算。ONNX 是另一种跨框架的导出方案。通过torch.onnx.export()可以导出 ONNX 格式然后用 ONNX Runtime 在多种硬件上运行。好处是生态广坏处是同样的兼容性问题依然存在特别是自定义算子。我吃过亏的是在模型里用了一个torch.where算子某个 ONNX Runtime 版本不支持该算子导致导出成功但推理报错。这类问题排查起来比较费时我的建议是提前在导出后做一次推理验证别等到上线前才发现。量化的部分我在实际项目中接触不多但可以给一个大致的方向PyTorch 提供torch.quantization模块可以做训练后量化和量化感知训练。如果你部署的硬件对 INT8 计算支持良好量化后的模型尺寸和推理速度都能显著改善。但量化不是按下开关就完事层类型、数值分布都会影响量化误差必须在目标硬件上做精度验证。6.3 什么时候该离开 PyTorch聊边界是为了不盲从。PyTorch 再方便也有不适合的场景。比如你要在手机端跑极轻量级的模型用 TFLite 可能更高效如果你的整个服务已经用一种特定的推理后端强行加装 PyTorch Runtime 反而浪费资源如果你做的是超大规模推理集群PyTorch 的一个 Python 进程模型可能不如专门优化过的静态图后端来得稳。这些问题不是非此即彼而是要在项目初期就做好规划。7. 写在最后对于一个框架最好的评价是用完能睡个好觉回到开头说的那个直觉。PyTorch 最让我欣赏的一点是它把复杂的东西藏在了简单接口的后面但当你需要理解它时所有机制又都是透明的。它会报错、会提醒你 device 不统一、会告诉你哪个张量的梯度没有被计算而不是让你在黑盒里瞎猜。用时间久了你会发现这个框架的思维方式深刻地影响了你怎么设计模型、怎么写训练循环、怎么排查问题。说了这么多其实我真正想强调的只有一句话框架只是工具理解工具的运行机制、边界和取舍才是让项目顺利推进的真正能力。PyTorch 的价值并不在于它有多少层封装、多少个模块而在于它帮助你建立了一套动态、透明、可调试的深度学习工作流。这套工作流从一开始的快速原型验证到中期的迭代调优再到后期的部署落地都能保持在一个统一的编程模型下这本身就是很难得的设计。如果你现在正处在按教程能跑通、但换一个任务就不知道该从哪里改的阶段我建议不要急着背 API而是亲手写一个最简单的线性回归、一个小型 CNN然后用print去观察每一层的输入输出形状、观察梯度变化、观察 loss 曲线的走势。把这些基础的感觉建立起来之后再回头看生态库、分布式训练、部署工具这些上层建筑你会发现它们的逻辑都是连贯的而不是一堆孤立的功能堆叠。最后再分享一个我自己的小习惯每次新开一个 PyTorch 项目我都会先写一个最小复现脚本只包含数据加载、模型定义、训练循环三件事确保这三件事在单卡、纯 CPU 环境下能跑通再逐步加功能。这看起来多花了一点时间但在遇到问题的时候一个小而完整的复现脚本往往比一个大而全的项目更好定位问题也更好向别人求助。希望这篇内容能在你后续的 PyTorch 项目里少走几步弯路。
