企业官网建设流程全解析

搞了几年深度学习，PyTorch 几乎成了我日常项目里的默认选项。它不像某些框架那样把计算图和训练流程包装得密不透风，而是把张量运算、自动求导、神经网络模块一层层摊开，让研究者能直接看见模型在跑什么、在哪里出错。这篇内容不聊入门教程里那种简单的分类Demo，而是从设计思路、实操细节到工程落地，把 PyTorch 从训练到上线的关键环节都捋一遍。适合刚上手想系统理解框架机制的人，也适合已经在用但总被环境、显存、部署问题卡住的同行。

我最早接触 PyTorch 是在某个图像处理项目里，当时被动态计算图吸引过来，后来在实际项目里踩过不少坑，也慢慢摸清了框架的脾气。下面这些内容算是我自己的经验沉淀，希望对你有帮助。

1. 为什么是PyTorch：一个框架背后的设计思路

1.1 PyTorch解决的核心问题

深度学习框架要回答的问题其实只有一个：怎么让用户在写模型时尽量少操心“底层到底怎么算”。PyTorch 给出的答案很直接，把 Python 的编程习惯完整保留下来，你写模型就像写普通 Python 类一样，前向传播就是重写一个函数，反向传播由框架自动搞定。

这个设计解决了两个长期痛点。第一个是调试难，很多框架把计算图整体编译后再执行，报错信息经常指向一串底层算子，用户根本不知道是哪层网络出了问题。PyTorch 按调用顺序逐行执行，报错能直接定位到 Python 代码的具体行，调试体验和普通程序没有区别。第二个是研究迭代慢，模型结构经常要改，PyTorch 不需要预先定义静态图，改完代码立刻跑，实验节奏快得多。

在工程性能上，PyTorch 并没有因为灵活而牺牲太多。它底层用 C++ 实现核心算子，Python 只是调用层，只要批量维度设计合理，计算效率和其他框架差距不大。而且这两年它对分布式训练、模型导出、移动端部署的支持都补上了，从研究到生产不再需要换框架。

1.2 动态计算图与静态图之争

很多人第一次听说 PyTorch 都会碰到“动态图”这个词。要理解它，可以做一个类比：静态图像提前画好一张完整的施工图纸，所有工序确定后一次性开工；动态图则像现场指挥，走一步算一步，每一步的依据是前面已经得到的真实结果。

动态计算图意味着前向传播时，框架会记录每一步操作，形成一个临时计算图，反向传播时再沿这个图回传梯度。这个机制的灵活之处在于，图的结构可以根据数据动态改变。比如处理变长序列时，不同样本的序列长度不同，模型结构也随之变化，动态图处理这种场景天然顺畅。

静态图也有它的优势，比如部署前可以先做整图优化，把多个算子融合，性能上限更高。但代价是写代码的灵活性受限，调试也更绕。PyTorch 后来推出的 TorchScript 和torch.compile就是为了弥补动态图在部署和性能上的短板，想兼顾的时候可以用这些工具把动态图转为静态优化版本，这个后面再说。

1.3 当前的生态位置

经过几年的发展，PyTorch 已经不只是研究者的玩具，而是几乎所有主流开源模型的第一发布平台。尤其是这两年大规模预训练模型爆发，相当比例的模型权重都直接用 PyTorch 权重格式分发，很多新模型的官方实现也是 PyTorch 版本。

生态一旦形成，跟着用的人越多，相关的教程、第三方库、工具链就越成熟，后来者几乎没有理由绕开它。整个社区形成了一个正反馈循环：模型开发者发布 PyTorch 实现，应用开发者基于 PyTorch 做推理和二次开发，框架本身也随着需求持续演进。对于个人开发者来说，学 PyTorch 不只是学一个工具，更是在融入这套技术生态，很多问题都能在社区里找到现成答案。

2. 环境搭建与基础实操

2.1 安装环节的关键判断

安装 PyTorch 最需要花心思的不是 pip install 本身，而是怎么确定自己的硬件和 CUDA 环境。我见过太多人装完以后发现 GPU 用不了，问题大多出在 PyTorch 版本和本机 CUDA 版本不匹配上。

我的建议是先确认三件事：显卡型号、驱动支持的 CUDA 版本、以及是否需要用 GPU 训练。如果只是 CPU 跑小模型，直接装 CPU 版就可以，体积小也没兼容问题。如果要用 GPU，重点看驱动版本，因为 PyTorch 安装包里的 CUDA 运行时和驱动不是一回事，但驱动版本不能低于 PyTorch 需要的版本。

这里有个容易混淆的点：用nvidia-smi看到的 CUDA 版本是驱动支持的版本，不代表本机“装着”那个版本的 CUDA 工具包。PyTorch 的 pip 包通常自带打包好的 CUDA 运行时，所以你不需要单独装 CUDA 工具包也能跑。只要驱动够新，PyTorch 的 CUDA 版本选择范围就比较宽。实测下来，我一般直接选 pip 源里最新稳定的 CUDA 版本，比如 cu124，兼容性和性能都比较好。

装完以后建议立刻验证 GPU 是否可用：

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))

如果cuda.is_available()返回 False，先不要急着重装，检查驱动版本和 PyTorch 的 CUDA 要求是否匹配，八成是版本错位。

2.2 Tensor：数据流转的基础单元

Tensor 是 PyTorch 的基本数据类型，你可以把它理解成带计算功能的数组。它有 dtype、shape、device 三个核心属性。shape 表示各维度大小，dtype 表示数据类型，device 表示数据存放在 CPU 还是 GPU 上，这三个属性直接决定后续运算是否正确高效。

创建张量的方式很多，常用的有torch.tensor()、torch.zeros()、torch.ones()、torch.randn()。你需要特别留意的是torch.tensor()会复制数据，而torch.as_tensor()在合适条件下会共享内存，后者性能更好。如果从 NumPy 数组转换，用torch.from_numpy()也常被用来避免多余拷贝。

张量操作的细节容易踩坑的是维度。比如你对三维张量做squeeze()，默认会去掉所有长度为 1 的维度，有时候会把不该去掉的维度去掉，尤其是样本数量为 1 的批次。所以更推荐写清楚参数，比如squeeze(dim=1)。又比如transpose()和permute()的区别，前者只能交换两个维度，后者可以按任意顺序重新排列，功能上更通用。

2.3 autograd：自动求导背后的思路

自动求导是 PyTorch 最核心的机制，理解它才能真正理解框架的运行逻辑。简单说，你在做前向传播时，框架会对每个涉及计算的张量记录操作历史，形成一个计算图。反向传播时，从最后的损失张量出发，沿着计算图逐层回传梯度。

看一个最简单的例子：

import torch x = torch.tensor(2.0, requires_grad=True) y = x ** 2 + 3 * x + 1 y.backward() print(x.grad) # 2*x + 3 = 7

这里x设置requires_grad=True，框架就知道要追踪它的运算。反向传播后x.grad保存梯度。这个机制背后是链式法则的自动实现，你不需要手动推导梯度公式，也不需要手写反向传播。

实际操作中有一个常见的错误：在循环里迭代更新参数时，梯度会在多次反向传播中累积，如果你没有在每步清零，梯度会越叠越大，导致训练不收敛。用优化器的话，optimizer.zero_grad()通常放在每个 batch 的反向传播之前，这是最容易漏掉的一行代码。

另一个和自动求导相关的知识点是torch.no_grad()。在模型推理阶段，不需要计算梯度，用这个上下文管理器可以关闭梯度追踪，省内存也省时间。很多人会在评估模型时忘记用，导致显存莫名其妙被打满。养成习惯：训练以外的前向传播都包在with torch.no_grad():里。

2.4 用nn.Module搭一个完整网络

PyTorch 里搭建网络的核心继承nn.Module，把网络的层定义在__init__，把前向计算逻辑写在forward。下面是一个两层的全连接网络：

import torch import torch.nn as nn import torch.nn.functional as F class SimpleNet(nn.Module): def __init__(self, in_features=784, hidden_features=128, num_classes=10): super().__init__() self.fc1 = nn.Linear(in_features, hidden_features) self.fc2 = nn.Linear(hidden_features, num_classes) def forward(self, x): x = self.fc1(x) x = F.relu(x) x = self.fc2(x) return x model = SimpleNet() print(model)

这是一个非常标准的写法。注意forward方法名的固定性，PyTorch 在调用model(x)时会自动执行forward里的内容，同时会处理 hooks、参数注册等后台工作，所以不要直接调用model.forward(x)。

定义好网络后，如果要用 GPU 加速，需要把模型和数据都放到 GPU 上。实际操作中，可以通过一个辅助函数来统一设备选择：

device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model = SimpleNet().to(device)

把模型放到 GPU 以后，分批传入的数据也要调用.to(device)，否则会报设备不匹配的错误。这类错误在刚开始写训练代码时特别常见，报错信息会提示张量在不同设备上，不用慌，检查一下模型和数据是不是在同一个设备上就行。

训练时建议把训练逻辑封装到一个函数里，方便重复调用。每一步包含四个标准动作：取 batch 数据、forward 计算输出和损失、backward 求梯度、优化器更新参数。保持这个顺序不乱，是训练代码稳定运行的关键。

3. 训练阶段的工程细节

3.1 DataLoader的数据流水线

数据的读取效率直接影响训练速度。PyTorch 提供了torch.utils.data.Dataset和DataLoader，前者负责定义数据集的索引和读取逻辑，后者负责批量加载、打乱和多进程并行。

一个常见问题是，很多人把所有数据加载逻辑塞进__getitem__，但每读一条数据都做大量 I/O 操作，导致训练时数据加载成为瓶颈。比较稳妥的做法是，如果数据集能一次性放进内存，就预先加载并转换成 Tensor，__getitem__只做索引和必要的预处理。如果数据量很大，考虑用 LMDB、HDF5 这类格式做磁盘读取优化，或者用缓存机制，把常用的数据缓存到内存里。

DataLoader的多进程参数num_workers设置也很有讲究。设得太小，数据供应不上；设得太大，进程切换开销反而拖慢速度。经验法则是从 4 开始试，观察 GPU 利用率。如果 GPU 利用率一直不高，而 CPU 也没有打满，可以逐步增加。另外在 Windows 系统上num_workers设为 0 可以避免一些多进程坑，Linux 服务器上则通常可以设到 CPU 核数的一半甚至更多。

shuffle参数的设置也要区分场景。训练集要设True，避免模型记住样本顺序；验证集和测试集设False。如果有类别不均衡问题，还可以配合WeightedRandomSampler来自定义采样权重，让模型在训练时看到更多少数类样本。

3.2 损失函数与优化器选择

损失函数要根据任务类型选择。分类任务常用交叉熵，PyTorch 的nn.CrossEntropyLoss其实已经内置了 softmax 操作，所以网络的最后一层不需要再接nn.Softmax，直接在forward里输出原始 logits 就行。我之前见过有人最后加了一层 softmax，训练时又用交叉熵，结果数值一直不稳定，因为交叉熵内部缩放了一次。

回归任务常用nn.MSELoss或nn.L1Loss。如果你对异常值敏感度要求不同，L1 比 MSE 更鲁棒。多标签分类任务用nn.BCEWithLogitsLoss，同样内部包含 sigmoid，不需要在模型输出层手动加 sigmoid。

优化器方面，SGD 加动量在很多任务上表现稳定，Adam 类优化器收敛快但泛化表现有时候不是最佳。实际项目中我习惯先用 Adam 快速跑通流程，观察损失能否下降，然后再换 SGD 调学习率和收敛曲线。学习率是一个需要手动感受的参数，太大容易震荡甚至发散，太小收敛缓慢，建议先用 1e-3 起步，配合torch.optim.lr_scheduler做余弦退火或 Step 衰减。

3.3 训练循环与GPU加速

训练循环本身不复杂，但有很多细节决定效率和稳定性。基础版本是这样：

model.train() optimizer = torch.optim.Adam(model.parameters(), lr=1e-3) criterion = nn.CrossEntropyLoss() for epoch in range(num_epochs): total_loss = 0.0 for x_batch, y_batch in train_loader: x_batch = x_batch.to(device) y_batch = y_batch.to(device) optimizer.zero_grad() outputs = model(x_batch) loss = criterion(outputs, y_batch) loss.backward() optimizer.step() total_loss += loss.item() print(f"epoch {epoch+1}, loss: {total_loss / len(train_loader):.4f}")

注意loss.item()的作用，它把只有一维的损失张量转成 Python 数字，这样可以脱离计算图，不会继续累积内存。如果你直接累加 loss 张量，运行几个 epoch 后可能内存暴涨，这是一个很隐蔽的问题。

GPU 利用率方面，除了数据加载，另一个常见的效率杀手是频繁在 CPU 和 GPU 之间同步。比如在训练循环里打印每个 step 的 loss，会强制 CPU 等待 GPU 计算完成，拖慢整体速度。一般建议每隔一定步数或 epoch 结束才打印一次。

放大 batch size 也是提升 GPU 利用率的方法之一，但要注意显存上限和收敛稳定性。梯度累积是一种绕过显存限制的手段，把一个大 batch 拆成几个小 batch 累加梯度，等价于大 batch 的效果：

accumulation_steps = 4 for i, (x_batch, y_batch) in enumerate(train_loader): outputs = model(x_batch) loss = criterion(outputs, y_batch) / accumulation_steps loss.backward() if (i + 1) % accumulation_steps == 0: optimizer.step() optimizer.zero_grad()

这样写以后，等效 batch size 变成了原来的 4 倍。注意要先把 loss 除以累积步数，否则梯度总和偏大，学习率需要相应调整。

3.4 过程调试、日志与可视化

训练过程不能只靠终端打印 loss，还要结合可视化工具观察变化趋势。简单场景用tensorboard比较方便，PyTorch 提供了torch.utils.tensorboard.SummaryWriter，可以记录 loss、准确率、权重分布等标量曲线。

from torch.utils.tensorboard import SummaryWriter writer = SummaryWriter(log_dir="runs/experiment_1") for epoch in range(num_epochs): train_loss = train_one_epoch(...) val_loss = evaluate(...) writer.add_scalar("loss/train", train_loss, epoch) writer.add_scalar("loss/val", val_loss, epoch)

记录的时候最容易犯的错误是只记录训练集 loss，不记录验证集 loss。训练集 loss 下降不代表模型泛化好，很有可能过拟合。我一般会每个 epoch 结束在验证集上算一次 loss 和准确率，然后对比两者趋势。验证集 loss 先降后升、训练集 loss 继续下降，说明开始过拟合，可以考虑早停或加正则化。

日志的格式也建议统一，方便事后分析。可以用 Python 自带的logging，也可以用现成的实验管理平台记录参数组合。无论用什么，关键是记录好每次实验的超参数、数据版本、代码 commit 号，否则跑了很多实验以后根本分不清哪个结果对应哪次改动。

4. 从实验到部署的工程化

4.1 模型导出：TorchScript与ONNX

模型训练完成以后，最终目标通常是部署到服务端或移动端。PyTorch 的灵活动态图在部署时反而是把双刃剑，因为生产环境需要确定性的计算流程，所以需要把模型转换成静态优化版本。

TorchScript 是这个场景的官方方案，它可以把模型序列化成一种中间表示，不依赖 Python 解释器就能运行。最常见的方式是jit.trace，给模型一个示例输入，追踪实际执行路径并生成脚本化模型。

import torch model = SimpleNet().to(device) model.eval() example_input = torch.randn(1, 784).to(device) traced_model = torch.jit.trace(model, example_input) traced_model.save("simple_net.pt")

用 trace 的时候有一个大坑：如果你的模型包含依赖输入数据特征的分支，比如根据序列长度选择不同计算路径，trace 只会记录示例输入的路径，其他分支会被丢掉。这种情况下需要改用torch.jit.script的方式来转换，或者尽量保证示例输入覆盖所有分支。

ONNX 是另一种跨框架的交换格式，导出以后可以用 ONNX Runtime 加速推理，也可以部署到其他推理框架。导出方式和 trace 类似，关键是设置好动态轴，比如 batch 维度，让导出的模型能接受不同大小的输入。这里有个经验之谈，导出后建议用带有 ONNX 后端的工具跑一遍验证，对比原始模型和导出模型的输出差异，防止算子映射不一致导致数值偏移。

4.2 推理服务与模型量化

部署到生产环境时，推理接口往往用 HTTP 服务暴露。PyTorch 官方有 TorchServe，它封装了模型加载、请求处理、批处理这些逻辑，开箱即用。如果你想自己写一个简单的推理服务，可以基于 FastAPI 或 Flask 封装，核心步骤是启动时加载模型，请求进来时准备输入、前向推理、返回结果。

自己写服务需要注意的是并发和批处理。默认的同步推理方式在并发量高时延迟会升高，因为每个请求独立过一遍模型。更高效的做法是实现动态批处理，把一段时间内到达的多个请求拼成一个 batch，一次性推理，再拆分结果返回。这种方法可以显著提升吞吐量，代价是实现复杂度提高。

模型量化是提升推理速度的常用手段。把模型参数从 float32 换成 float16 或 int8，推理速度会大幅提升，显存占用也降一半以上。PyTorch 提供torch.quantization，可以做训练后量化或量化感知训练。实际使用中，不是所有层都适合量化，有些层量化后精度损失明显，需要针对性做敏感度分析。

对于大模型部署场景，显存优化也是一个关键问题。除了量化，还可以用内存映射加载权重，或者分片加载模型，避免一次性把整个模型载入显存导致 OOM。这个方向现在工具链已经比较成熟，核心思路是按需加载，用多少载多少。

4.3 多卡训练与分布式

模型大了以后，单卡显存不够是迟早会遇到的问题。PyTorch 提供多种多卡训练方案，最常用的是DataParallel和DistributedDataParallel。前者实现简单，但存在负载不均的问题，而且性能扩展性有限，我一般不建议在新项目里使用。

DistributedDataParallel是更底层的方案，它在多进程下运行，每张卡一个进程，通过后端通信同步梯度，扩展性和性能都更好。使用它需要引入一些额外的初始化代码，但结构和单卡训练基本一致，迁移成本不高。

import torch.distributed as dist import torch.multiprocessing as mp from torch.nn.parallel import DistributedDataParallel as DDP def train_worker(rank, world_size): dist.init_process_group("nccl", rank=rank, world_size=world_size) model = SimpleNet().to(rank) ddp_model = DDP(model, device_ids=[rank]) # 后续训练循环和单卡类似 # 注意 dataloader 需要配合 DistributedSampler 分配数据 if __name__ == "__main__": world_size = torch.cuda.device_count() mp.spawn(train_worker, args=(world_size,), nprocs=world_size)

多卡训练的一个隐藏坑是每个进程会各自加载一份完整数据集，如果没有用DistributedSampler切分数据，每张卡都会看到全部数据，相当于每个 epoch 多训练了好几倍。所以 DataLoader 必须配合DistributedSampler，并在每个 epoch 调用它的set_epoch来打乱数据顺序。

分布式训练还有一个常见问题是通信瓶颈。如果每步同步梯度的开销大于多卡并行节省的时间，训练反而变慢。这时需要检查数据加载速度、GPU 利用率和通信模式，必要时提高batch_size或者在梯度累积和多卡之间做权衡。

5. 常见问题与避坑指南

5.1 环境与版本兼容问题

环境问题占了日常踩坑的一半以上，最常见的是 CUDA 版本和 PyTorch 版本不匹配。比如驱动太老导致 PyTorch 无法调用 GPU，或者安装的是 CPU 版 PyTorch，不管怎么配置都是用不了 GPU。碰到这类问题，先执行之前那个验证脚本，确定问题出在哪个环节。

另一个高频问题是 Python 版本太旧。新版 PyTorch 逐渐放弃对老版 Python 的支持，如果你的 Python 是 3.7 或更早，很多依赖都装不上。建议使用虚拟环境管理依赖，我习惯用 conda 或 venv 创建干净的环境，专项目专用，不同项目之间互不干扰。

第三方库的版本兼容也要留意。比如 transformers、torchvision、torchaudio 这些库通常和 PyTorch 版本有对应关系，如果你随意升级其中一个，另一个可能报找不到某算子的错误。一般建议所有深度学习相关库一起升级，不要单独动其中一个。

5.2 显存管理与OOM问题

显存爆掉是最让人头疼的问题之一。模型参数、梯度、优化器状态、中间激活值都会占用显存，前向传播过程中保存的中间特征图在训练时是显存大户。减小 batch size 是最直接的解决方案，但如果不想降低吞吐，可以考虑梯度累积、混合精度训练、激活重计算等手段。

混合精度训练非常值得学会，PyTorch 提供了torch.cuda.amp，核心是GradScaler和autocast。开启混合精度以后，部分计算用 float16 完成，显存占用降低，速度还能提升不少。实践中需要注意梯度的数值稳定性，GradScaler会自动处理梯度缩放，避免下溢出。

from torch.cuda.amp import autocast, GradScaler scaler = GradScaler() for x_batch, y_batch in train_loader: x_batch = x_batch.to(device) y_batch = y_batch.to(device) optimizer.zero_grad() with autocast(): outputs = model(x_batch) loss = criterion(outputs, y_batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

如果你用的是成熟模型和标准逻辑，这个模板基本可以直接套用。OOM 之后，进程不会自动清理显存，即使代码里释放了张量，显存也可能显示仍然被占用。此时可以用torch.cuda.empty_cache()释放缓存，但它只是把缓存归还给分配器，不一定是真的释放给系统。最可靠的恢复手段是重启训练进程。

5.3 结果复现与随机种子

深度学习训练涉及大量随机性，如果不固定随机种子，同一次实验可能跑出不同的结果。这种不确定性来自多个层面：Python 的随机数、NumPy 的随机数、PyTorch 的随机数，以及 CUDA 的随机数。

固定种子的标准代码：

import random import numpy as np import torch def seed_everything(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False seed_everything(42)

需要提醒的是，即使固定了所有种子，GPU 上的某些算子仍然存在不完全确定的行为，尤其是涉及原子加法操作的算子。所以不应该追求百分百复现，而是把不确定性控制在可接受范围，比如多次实验的标准差保持在较小水平。想要结果稳定，最好在实验前固定好所有环境依赖版本，因为不同版本的算子实现也可能导致结果不同。

cudnn.benchmark的设置也需要理解一下。它在输入尺寸固定时开启可以寻找最优卷积算法，提升训练速度。但开启后会引入一些不确定性，所以实验对比阶段建议关掉，确定最终方案后再打开提速。

5.4 训练不收敛的排查思路

训练 loss 不下降或者直接变成 NaN，是每个从业者都会遇到的噩梦。我的排查顺序通常是这样：先看数据预处理是否正常，再看模型输出范围是否合理，然后检查损失函数和标签是否匹配，最后用一个小数据集做拟合测试。

小数据集拟合测试是一个很有效的诊断手段。取几十个样本，让模型在这个小集合上反复训练，如果 loss 能降到很低甚至接近 0，说明模型和数据通道是通的，问题可能出在数据量、学习率或正则化上。如果小集合也学不动，那就要从头检查模型结构了。

NaN 问题大多数出在数值不稳定上，比如学习率过大、输入特征尺度差异悬殊、损失计算时出现极端值。先用torch.clamp限制输入范围或者使用学习率预热，往往能解决大部分数值不稳定的问题。再不行就用日志记录每一层的输出均值、方差、梯度均值，定位是哪一步出现了异常值。

我自己排查 NaN 时用过一个笨但有效的方法：在训练循环里逐步打印每层的权重梯度，观察哪一层率先出现异常值，然后针对那一层做调整。保存中间变量检查会拖慢速度，但定位效率非常高，值得一试。

这里把高频问题和排查思路整理成了一份简表，方便你对照检查：

这些坑我几乎都在真实项目里踩过，印象最深的是有一次训练图像模型，loss 一直不降，查了两天才发现是数据读取时标签错位，训练集和验证集读到了同一份文件的不同偏移量。数据问题往往比模型问题更隐蔽，排查时别总盯着网络结构，先确认数据流水线是对的。

写在最后的一点体会

如果让我给刚开始学 PyTorch 的人一个建议，那就是不要只看理论，赶紧跑通一个完整的小项目，从数据加载到训练再到模型导出，把整个流程走一遍。这个过程中踩过的坑，比读十篇教程印象都深。我自己也是在一个又一个报错中慢慢建立起对框架的直觉。

另外我习惯在项目里维护一个简单的训练脚本模板，包含设备选择、随机种子、日志记录、梯度累积这些通用逻辑，每开一个新项目就在这个模板上改。看起来只是省了一点重复工作，但长期下来对代码质量和工作效率的提升非常明显。

PyTorch 本身还在快速迭代，新课的 API 层出不穷，但它底层的核心设计思路是相当稳定的。把张量、自动求导、模块化网络这几个基础概念吃透，后面学什么新功能都会很顺畅。希望这篇内容能帮你在使用 PyTorch 的路上少走几条弯路。