企业官网建设流程全解析

我第一次正儿八经用PyTorch跑项目，是在做一个图片分类的小任务。当时刚把环境和依赖装好，满怀信心地写了一个三层网络，结果一训练就报错——梯度全是NaN，模型权重肉眼可见地炸掉了。后来查了两天才发现，问题出在对张量梯度传播的机制理解不够，一个很小的细节没处理对，整个训练就失控了。从那以后我就意识到，PyTorch的好上手是相对的，真正想把它用到生产级别，必须把张量、计算图、数据管线、训练循环这些东西一层层吃透。

这篇文章我打算从一个实际使用者的角度，把PyTorch从底层机制到完整实战的路径完整梳理一遍。内容包括：张量与自动微分是怎么设计的、环境怎么搭才不会踩版本坑、DataLoader究竟怎么配置才能喂饱GPU、训练循环每一步调用的顺序为什么不能乱、以及最常见的显存溢出、Loss为NaN、梯度不更新这些故障怎么定位。不管你是刚接触PyTorch的初学者，还是已经能跑通简单模型、想进一步优化性能和排查问题的开发者，这篇文章应该都能给你一些参考。

1. 先拆开PyTorch的引擎：张量、计算图与自动微分

1.1 张量：一个被“设备”和“梯度标记”扩展了的数组

很多人学PyTorch，第一个接触的概念就是Tensor。你可以把Tensor理解为带扩展功能的NumPy数组：它同样支持切片、广播、矩阵乘法和各种数学运算，但比NumPy数组多出两个关键维度——设备（device）和梯度追踪（requires_grad）。

设备决定了张量数据存在哪里，CPU还是GPU。NumPy数组只能活在内存里，而Tensor可以通过tensor.to('cuda')或者tensor.cuda()搬到显卡显存上，让大规模矩阵运算享受并行加速。平时写代码很容易忽略一个问题：CPU上的张量和GPU上的张量做运算会直接报错，提示设备不一致。这个错虽然信息写得很清楚，但新手几乎都会撞上一次。

梯度标记则是深度学习训练的基础。当你创建一个张量并设置requires_grad=True时，PyTorch会记录对这个张量的所有操作，构建一张计算图。等到调用backward()的时候，它再从输出端反向遍历这张图，把每个参数的梯度算出来。这才是整个框架自动微分的核心秘密。

下面这段代码是理解张量和梯度最简单的演示：

import torch # 创建一个叶子张量，并标记需要梯度 x = torch.tensor([2.0], requires_grad=True) # 做一些运算 y = x * 3 + 1 z = y.sum() # 反向传播 z.backward() # 查看梯度 print(x.grad)

运行结果里，x的梯度是3。为什么是3？因为z对x求导，链式法则一路传下来，就是dz/dy乘以dy/dx，也就是1乘以3。

这段代码虽然简单，但里面藏着几个值得深挖的点：x被称为叶子张量（leaf tensor），它是由用户直接创建的；y和z是中间结果，它们的grad_fn属性记录了生成自己的运算（分别是MulBackward和SumBackward），这就是反向传播时可以回溯的证据。

1.2 动态计算图：调试友好，但也容易埋雷

PyTorch最让我喜欢的特性之一，是它的计算图是动态构建的。也就是说，每次前向传播都会根据当前的输入重新搭建一张图，图的形状随代码执行实时变化。这意味着你可以在训练过程中用if语句控制网络结构，也可以随时打断前向过程查看中间张量。

对比一下早期一些框架的静态图模式：静态图需要先把计算流程定义好，再编译成一张固定图，数据往里灌就行。好处是执行效率高，图结构容易做全局优化；坏处是调试和交互非常痛苦，一旦图里有bug，报错信息往往脱离实际代码。PyTorch的动态图则更像普通的Python程序，断点一打，变量一查，问题基本就浮出水面了。

不过动态图也有它的坑。最大的坑是：每次前向都会建立新的计算图，如果不注意使用torch.no_grad()或者.detach()，中间过程产生的计算图会一直挂在内存里，显存和内存占用肉眼可见地往上涨。尤其在验证模型或推理时，很多人都忘了包一层no_grad()，结果模型占用的显存比训练时还离谱。

建议把下面这个习惯刻进肌肉记忆：凡是只做推理、不需要梯度的代码段，一律用with torch.no_grad():包起来。这既是省显存，也是省时间。

1.3 自动求导的完整链路：从前向到backward

再看一层。假设你定义了一个多层网络，数据从输入层流到输出层，PyTorch在内部做了三件事：

• 记录每个运算节点，把张量之间的依赖关系写进计算图；
• 在张量上挂上grad_fn，标记这个张量是怎么算出来的；
• 调用backward()时，从输出端出发，沿着grad_fn构成的链反向传播，逐层累积梯度。

这套机制带来的直接好处是：你在写模型的时候根本不需要手推梯度公式，也不需要自己实现反向传播逻辑。loss.backward()一调用，模型里所有requires_grad=True的参数都会自动获得.grad值。

但理解这层机制仍然非常必要，因为排查梯度问题时都得回到这里。比如你发现某个参数训练完梯度是None，可能原因无非就三种：该参数没参与前向计算、前向结果没走到loss上、或者中途被.detach()切断了梯度流。遇到梯度相关的问题，先顺着计算图检查这几处，比盲目调学习率有效得多。

2. 搭建环境与跑通第一个模型：版本、设备与最小训练循环

2.1 版本匹配是第一个隐形门槛

PyTorch安装看起来就一条命令，但版本对应关系很容易让人栽跟头。PyTorch版本、Python版本、CUDA版本、显卡驱动四者之间有兼容性约束，装错了要么装不上，要么装上之后torch.cuda.is_available()永远返回False。

我一般按这个顺序做选型：

• 先看自己的显卡驱动支持的CUDA版本，在终端里执行nvidia-smi，右上角的CUDA Version就是驱动能支持的最高CUDA版本；
• 再根据PyTorch官方发布的安装矩阵选择对应的PyTorch版本和CUDA版本组合；
• 最后看这个PyTorch版本对Python版本的要求，通常Python 3.8到3.11都在主流支持范围内。

为了省事，可以直接用pip安装默认版本，很多时候默认版本就是带CUDA支持的。装完后立刻跑一段验证代码：

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

如果is_available()返回False，先别急着怀疑显卡，优先检查两件事：一是PyTorch是不是装了CPU版本；二是CUDA相关动态库能不能正常加载。很多时候都是环境变量没配好，跟显卡本身没关系。

2.2 一个最简分类模型：从数据到训练循环

为了验证环境，我建议跑一个最小的分类任务，不追求精度，只求全链路通。这里用公开的手写数字图片数据集做演示，输入是784维向量，输出是10类概率。

import torch import torch.nn as nn import torch.optim as optim from torch.utils.data import DataLoader, TensorDataset # 构造一个简单的三层MLP class MLP(nn.Module): def __init__(self): super().__init__() self.fc1 = nn.Linear(784, 256) self.fc2 = nn.Linear(256, 128) self.fc3 = nn.Linear(128, 10) def forward(self, x): x = torch.relu(self.fc1(x)) x = torch.relu(self.fc2(x)) x = self.fc3(x) return x # 假数据：64张图，每张784维 x_data = torch.randn(64, 784) y_data = torch.randint(0, 10, (64,)) dataset = TensorDataset(x_data, y_data) loader = DataLoader(dataset, batch_size=16, shuffle=True) model = MLP() optimizer = optim.Adam(model.parameters(), lr=1e-3) loss_fn = nn.CrossEntropyLoss() # 训练循环 for epoch in range(3): for x_batch, y_batch in loader: optimizer.zero_grad() output = model(x_batch) loss = loss_fn(output, y_batch) loss.backward() optimizer.step() print(f"epoch {epoch}, loss: {loss.item():.4f}")

这段代码虽然简单，但它包含了训练循环的五个关键位置：清空梯度、前向计算、计算损失、反向传播、参数更新。每一个位置都有它存在的理由，后面我会专门展开讲。

2.3 我把环境反复装了三遍之后才明白的事

第一件是随机种子的问题。深度学习训练本身有随机性：数据打乱顺序、模型参数初始化都是随机的。如果不在最开始设置随机种子，同一个脚本两次跑出来的结果可能差很多，这会严重干扰你判断“改动到底是有效还是无效”。我现在的习惯是固定三个种子：

import random import numpy as np import torch def set_seed(seed=42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed)

第二件事是设备混用。模型在GPU上、数据在CPU上，一训练就报错。我的做法是定义一个全局device变量，模型和数据显式地搬到同一个设备：

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

第三件事是不要为了追求最新版本而选太新的CUDA。稳定优先，PyTorch版本和CUDA版本尽量选“已经发布了半年以上”的组合，社区踩坑帖多，遇到问题好搜。追新版本往往意味着很多第三方库还没来得及适配，报错了连个能参考的人都没有。

3. DataLoader效率实战：数据管线的分层设计与参数调优

3.1 Dataset、Sampler、DataLoader三层分工

DataLoader是PyTorch数据管线的核心，但它不是单独工作的。整个体系分三层：

• Dataset负责“给我第i条样本”；
• Sampler负责“按什么顺序取哪些索引”；
• DataLoader负责“把Sampler给出的索引拿去Dataset取数据，再攒成一个batch”。

理解这个分层很关键。很多人以为DataLoader就是简单地对数据进行分批，但其实它内部有完整的多进程调度机制。Dataset只关心单条样本的读取，Sampler决定访问顺序，DataLoader负责并行调度、内存预取、批量拼接。

自定义Dataset时只需要实现__len__和__getitem__两个方法。下面是图像分类任务中常见的写法：

import torch from torch.utils.data import Dataset from torchvision import transforms from PIL import Image class DemoImageDataset(Dataset): def __init__(self, image_paths, labels, transform=None): self.image_paths = image_paths self.labels = labels self.transform = transform def __len__(self): return len(self.image_paths) def __getitem__(self, idx): image = Image.open(self.image_paths[idx]).convert("RGB") label = self.labels[idx] if self.transform: image = self.transform(image) return image, label

3.2 num_workers、pin_memory、prefetch_factor到底怎么调

训练速度上不去，GPU利用率一直上不去，十有八九问题出在DataLoader配置上。GPU计算速度太快，CPU来不及喂数据，GPU就只能在那边干等。这时候就该调节DataLoader的参数了。

核心参数有这么几个：

• num_workers：子进程数量，决定同时有几个进程在做数据加载和预处理；
• pin_memory：把数据页锁定在内存中，让GPU可以直接从锁页内存拷贝数据，省掉一次中转；
• prefetch_factor：每个worker提前预取多少个batch；
• batch_size：单个batch的样本数量；
• drop_last：如果最后一批数据不够一个batch，是否丢弃。

有一份参数配置可以当作起步参考：

实际测试的时候，我见过有人把num_workers开到32，结果CPU直接被打满，训练反而变慢。原因是worker进程数量超过物理核心数后，系统频繁切换进程，内存带宽也成为瓶颈。比较合理的调法是从4开始往上试，观察GPU利用率和torch.utils.data.DataLoader的耗时，找到一个拐点。

3.3 图像增强和预处理放哪里做

很多人会把数据增强写在测试代码里，这是一个比较低效的做法。数据增强的目标是增加训练数据的多样性，但它本身是计算密集型的操作，如果在主进程里对整批数据逐张处理，那一轮迭代的大部分时间都花在预处理上。

正确做法是把transform放进Dataset的__getitem__里。这样每个worker子进程会在加载单张图片时顺手完成裁剪、翻转、归一化这些操作，多进程并行处理会让整体效率成倍提升。图像数据的标准流程大概是：先读取图片，再Resize，再做随机增强（训练阶段），最后转Tensor并归一化。

举个例子：

train_transform = transforms.Compose([ transforms.RandomResizedCrop(224), transforms.RandomHorizontalFlip(), transforms.ColorJitter(brightness=0.2, contrast=0.2), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), ])

3.4 自定义Dataset的三个实操建议

第一个建议是：__getitem__里要尽量避免持有全局文件句柄。比如用open()打开文件后不及时关闭，多进程环境下文件描述符很快就会被耗尽，报错还很隐蔽。用PIL的Image.open()加上下文管理器可以避免类似问题。

第二个建议是：如果数据集不大，可以在一开始就把全部数据读进内存做成TensorDataset。像医学影像或者小规模分类任务，数据总共才几个GB，完全没必要反复读磁盘，直接放内存里跑反而最简单省心。

第三个建议是：验证集和测试集记得设置shuffle=False。原因很简单——评估指标需要在确定的顺序下计算，而且某些指标比如AUC对样本顺序有要求，打乱顺序会带来不必要的麻烦。

4. nn.Module与训练循环：理清每一步的调用顺序和状态管理

4.1 nn.Module的机制：init、forward与状态字典

几乎所有PyTorch模型都继承自nn.Module，该类的核心机制集中在两点：一是__init__里定义网络组件，二是forward里定义前向计算逻辑。

初学阶段很容易把这两部分写混。比如把计算逻辑直接写在__init__里，或者在forward里重新定义网络层。正确的做法是：__init__只负责声明层结构，forward负责定义数据流向。

另一个重要概念是state_dict()，它把模型所有参数（可能还会包含缓冲区buffer）以一个字典的形式返回。保存和加载模型时，本质上就是在存取这个字典。

这里要区分三个容易混淆的成员：

• parameters()：返回所有需要梯度更新的参数，是优化器需要掌握的变量；
• buffers()：返回模型中的非可训练缓存，比如BatchNorm层里的running_mean和running_var；
• state_dict()：把parameters和buffers打包成有序字典，是模型持久化的标准格式。

很多人自定义模型时，会在__init__里用普通Python变量存一些统计值，结果模型保存后再加载，这些变量值丢了。究其原因，就是它们没有作为buffer注册。

4.2 训练循环的四步顺序：为什么不能乱

最小训练循环里有四行代码，顺序永远是这样：

1. optimizer.zero_grad()：清空上一次迭代保留的梯度；
2. loss = loss_fn(output, target)：根据当前模型输出计算损失；
3. loss.backward()：反向传播，计算出每个参数的梯度；
4. optimizer.step()：按照梯度和优化器策略更新参数。

很多新手会问：为什么每次都要调用zero_grad()？原因很简单——PyTorch的反向传播是累加梯度，而不是覆盖梯度。如果不手动清零，上一轮的梯度会和本轮梯度累加在一起，参数更新的方向就乱了。

反过来，这个特性也可以被利用，就是“梯度累积”。在显存不足的情况下，可以把一个大批次拆成多个小批次，分别前向和反向但不更新参数，每累积够一定步数再执行一次optimizer.step()。实现方式就是把zero_grad()和step()之间的代码循环多跑几次，但只在最后一次才更新参数。

还要注意model.eval()和torch.no_grad()的关系。model.eval()影响的是BatchNorm和Dropout这类在训练和推理时行为不同的层；torch.no_grad()关闭的是梯度计算和计算图构建。两者侧重点不同，建议在验证阶段同时使用：

model.eval() with torch.no_grad(): output = model(x_batch)

4.3 检查点保存与断点续训：不只是存模型权重

训练一个稍大的模型，动不动几个甚至几十个小时，中途断电、显存溢出、或者loss波动太大等情况都有可能发生。所以可靠的检查点（checkpoint）保存机制是必备的。

我的做法是每个epoch结束后按验证指标判断是否保存。保存的内容不只是model.state_dict()，还包括优化器状态、当前epoch、最佳验证指标等信息：

checkpoint = { "epoch": epoch, "model_state_dict": model.state_dict(), "optimizer_state_dict": optimizer.state_dict(), "best_acc": best_acc, } torch.save(checkpoint, "checkpoint.pt")

断点续训时，加载检查点后要手动把状态的各个部分恢复回去：

ckpt = torch.load("checkpoint.pt", map_location=device) model.load_state_dict(ckpt["model_state_dict"]) optimizer.load_state_dict(ckpt["optimizer_state_dict"]) start_epoch = ckpt["epoch"]

之所以要把optimizer状态也存下来，是因为Adam这类优化器内部维护了每个参数的历史动量信息。只加载模型权重而丢掉optimizer状态，训练虽然能继续，但学习进度会明显倒退回刚初始化的水平。

4.4 训练过程怎么观察

跑训练循环的时候，光看终端打印的loss值其实不够。Loss贴出来只能告诉你“数值在下降”，无法直接看出模型是否过拟合、学习率是否合适。

至少要养成两个习惯：一是每个epoch在验证集上算一次准确率或loss，把训练集指标和验证集指标放一起对比；二是把每个epoch的train loss和val loss记录下来，画成曲线。曲线能直观地告诉你模型处于欠拟合还是过拟合状态。如果train loss一直降但val loss开始回升，那就是过拟合了，该上正则化或者数据增强。

另外一个容易被忽略的点是：loss曲线剧烈震荡往往是因为batch_size太小或者学习率太大。我之前遇到过一次loss曲线像锯齿一样上下乱跳，把学习率往下调了一个数量级之后立刻平稳了很多。

5. 训练过程的常见故障排查：显存、梯度、NaN与混合精度

5.1 CUDA Out of Memory：先定位显存占用再谈优化

显存溢出是训练过程中最常见的故障之一。报错信息里会直接给出OutOfMemoryError，但要解决它，不能一上来就盲目调小batch_size，得先搞清楚显存被谁吃掉了。

常见原因有三个：批量数据一次性照单全收导致激活值过大、计算图缓存未释放、以及反向传播时梯度存储爆炸。

排查思路按下面这个顺序来：

1. 逐步缩小batch_size，跑几个step看显存占用是否线性下降。如果是，说明激活值占大头；
2. 检查是否忘记在验证/推理段包no_grad()，导致额外的计算图残留；
3. 使用torch.cuda.memory_summary()查看显存分配详情；
4. 关闭其他占用显存的进程，用nvidia-smi确认是否被其他任务挤占。

如果上面都排查完还不够，再考虑工程上的优化手段：梯度累积、混合精度训练、或者使用torch.utils.checkpoint对激活值做重计算。这些方法各有利弊，但都能在一定程度上缓解显存压力。

5.2 Loss为NaN：八成是数据或学习率出问题

训练过程中loss变成NaN，基本可以断定训练已经崩了。原因通常集中在四个方面：

• 学习率过大，导致梯度更新越过最优区域，参数直接发散到无穷大；
• 数据里有NaN或无穷值，反向传播时把梯度污染了；
• 损失函数里出现了除零或者log(0)之类的运算；
• 网络里存在数值不稳定的操作，比如某些激活函数在极端输入下溢出。

排查顺序很简单：先用小的学习率跑一次，如果问题消失，那就是学习率问题；再检查输入数据中是否有NaN，用torch.isnan(tensor).any()扫一遍；如果数据也没问题，就到loss计算部分逐行打印中间结果，找到第一个出现NaN的位置。

这里分享一个实用技巧：在损失函数里加一个小量epsilon，比如loss = torch.log(pred + 1e-8)，很多数值不稳定问题会立刻被挡在门外。

5.3 梯度不更新：三条链路逐段排查

参数梯度为None或者一直不更新，这类问题通常更隐蔽。排查链路我总结成三条主线：

第一条：参数到底有没有requires_grad=True。虽然nn.Parameter默认会开启梯度追踪，但如果你用普通张量存了网络参数，或者从某个地方加载了旧模型但没正确注册，梯度就是空的。

第二条：参数是否参与了前向计算。如果一个参数定义后没有被用到forward里，计算图里压根没有它的位置，梯度自然就是None。

第三条：梯度流是否被切断。排查代码里有没有误用.detach()，或者某个中间张量的requires_grad被错误地置为False。

还有个低级错误是优化器初始化时传错了参数集合。有人会把整个model直接传给optimizer，再把参数list也传一遍，导致优化器管理的参数对象和模型实际参数不是同一份，更新自然无效。建议始终用model.parameters()作为优化器的入参。

5.4 混合精度训练AMP：提速又省显存，但要注意细节

混合精度训练（AMP）几乎是训练大模型的标配。核心思路是：用FP16做前向和反向，用FP32做参数更新和损失计算，这样既享受FP16矩阵运算的速度和更小的显存占用，又不会因为精度太低导致训练不稳定。

PyTorch从版本1.6开始就把混合精度集成为标准API，用法很简洁：

from torch.cuda.amp import autocast, GradScaler scaler = GradScaler() for x_batch, y_batch in loader: optimizer.zero_grad() with autocast(): output = model(x_batch) loss = loss_fn(output, y_batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

这里有三点需要注意。第一，前向过程必须放在autocast()上下文里，这样计算会自动选择精度；第二，loss.backward()要用scaler.scale(loss)替代，避免梯度下溢；第三，参数更新要用scaler.step(optimizer)而不是直接optimizer.step()，并且每个batch最后都要调用scaler.update()。

实测下来，AMP在大部分图像模型上能带来20%到50%的训练速度提升，显存占用也能下降三到四成。需要注意的是，有些自定义算子或者自定义前向逻辑在低精度下数值不稳定，遇到诡异问题可以先关闭AMP再对比排查。

6. 从训练走向部署：模型保存、导出与推理优化

6.1 模型保存的几种方式，别再只存整个对象

模型保存看起来简单，实际操作中容易出问题的地方不少。

第一种方式是存整个模型对象：

torch.save(model, "model_full.pt")

这种方式加载方便，但缺点也很明显：跨越环境加载时风险大，比如类定义改了或者代码路径变了，加载就会失败；文件体积也会更大。我的建议是除非临时调试，否则不要用。

第二种方式只存权重字典：

torch.save(model.state_dict(), "model_weights.pt")

这种方式只保存参数和buffer，不保存类结构，加载时需要先用同样的网络结构实例化一个模型，再load_state_dict。这是推荐的常规做法。

第三种是导出为ONNX或TorchScript，用于跨框架推理。这个下面展开说。

6.2 导出ONNX：动态轴和opset版本是重点

如果模型要放到服务端推理，或者要在不同的推理框架里运行，ONNX是最常见的中间格式。PyTorch导出的代码很简单：

model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "model.onnx", opset_version=17, input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}} )

两个容易踩的坑：第一，opset_version不是越高越好，要看你选用的推理引擎支持到什么版本，版本太高导出的模型在其他环境里可能无法加载；第二，如果期望支持动态batch输入，必须在dynamic_axes里指定，否则导出的模型固定为1个batch，上线后收到的请求多一点就直接报错。

另外，导出前记得把模型切到eval()模式。因为BatchNorm和Dropout在训练模式下导出的计算图行为会不一样，这一点如果不注意，导出的模型推理结果可能和训练时的验证结果对不上。

6.3 推理阶段的优化：batch size、缓存与量化

模型部署时，我一般按照性能收益从高到低做这几件事：

• 合并batch：单条请求推理一次，效率很低；把多条请求凑成一个batch统一推理，在很多服务场景下吞吐量能提升好几倍。这个优化几乎零成本，前提是你的服务框架支持动态batch。
• 增加缓存：对图像分类这类模糊匹配任务，可以把输入特征做哈希缓存；对NLP任务，可以缓存高频查询的推理结果。这里的效果取决于业务场景，但性价比很高。
• 量化：把模型权重从FP32压到INT8或FP16，能显著降低显存占用和提升推理速度。PyTorch的后训练量化接口可以快速尝试，但量化后模型精度可能会有轻微下降，需要一个完整的评估流程来确认。

下面给出一个标准的量化导出示例：

import torch model.eval() model_q = torch.quantization.quantize_dynamic( model, {torch.nn.Linear, torch.nn.Conv2d}, dtype=torch.qint8 ) torch.save(model_q.state_dict(), "model_qint8.pt")

6.4 部署时的几条实战经验

部署阶段和训练阶段关注点完全不同。训练阶段追求的是模型精度和训练速度，部署阶段追求的是稳定、低延迟和高吞吐。

第一条经验是：服务端推理一定要用确定性逻辑。数据预处理、后处理尽量全部在代码里写死，不要在推理路径里引用任何需要额外状态的东西，否则模型上线后输出的结果可能时对时错，排查起来非常痛苦。

第二条经验是：容器镜像里不要装一堆训练用的依赖。部署镜像只需要推理相关的内容，ETL、可视化、测试代码统统去掉。镜像越小，启动越快，受攻击面也越小。

第三条经验是：推理服务的失败率要提前设计好监控。模型推理会出现延迟波动、超时、内存增长等问题，上线前最好先压测一轮，把批次大小、并发数这些参数摸清楚。不要等线上的故障报告出来再去讨论扩容方案。

我在实际项目里还总结了一个规律：很多部署时的报错来源不是模型本身，而是输入数据的预处理方式跟训练时不一致。比如训练时用的是BGR顺序，部署时却用RGB顺序喂进去，模型精度会直接崩盘。所以部署前的关键一步，是把训练代码里的数据预处理管线完整复制到推理服务里，并且用同一张测试图做端到端比对。

跑完这些项目以后，我的体会是：PyTorch的上手曲线确实不算陡，但要用得顺，核心还是要把它的设计思想吃透。张量和计算图是地基，数据管道和训练循环是框架，排查和调优是日常，部署是把成果真正落地的那一步。别急着追求新特性，先把每一步的“为什么”弄明白，后面遇到什么奇怪的问题就都有着手点。最后再分享一个小习惯：无论模型多小，我都坚持写一个完整的配置文件，把模型结构、数据路径、学习率、batch_size、随机种子全部记录在案。项目隔三个月再回头跑时，你会感谢当初那个记录了所有细节的自己。