1. 为什么“PyTorch”这三个字值得单独拎出来聊
如果你在深度学习圈子里待过一阵子，大概率会发现一个现象：大家聊模型结构、聊训练技巧、聊部署方案的时候，绕来绕去最后总会落回一个词——PyTorch。它不是一个新东西，也不是什么一夜爆红的框架，但它的存在感就是这么强。强到什么程度？很多开源项目放出来，README里第一行环境要求就是“PyTorch >= x.x”，论文复现的代码十有八九也是PyTorch写的。你要是不会它，很多前沿的东西连跑都跑不起来。
这篇文章不打算写成官方文档的中文翻译，也不准备把API从头到尾念一遍。我想做的是把PyTorch这个东西拆开，从“它到底解决了什么问题”开始，一路聊到“实际写代码的时候哪些地方容易翻车”。不管你是刚接触深度学习、还在纠结选哪个框架的新手，还是已经用了一段时间、但总觉得有些地方没吃透的老手，下面这些内容应该都能让你拿到一些能直接用的东西。
核心关键词我先摆出来：动态计算图、张量操作、自动求导、GPU加速、模型训练流程、数据加载、迁移学习、模型部署。这些词你会在接下来的内容里反复看到，因为它们构成了PyTorch的骨架。我不会为了凑关键词硬塞，而是每个点都落到实际写代码时会遇到的具体场景上。
先说清楚这篇文章适合谁看。如果你完全没碰过Python，那可能需要先补一下基础语法，否则后面的代码片段看起来会比较吃力。但如果你已经会写简单的Python脚本，想搞清楚深度学习框架到底怎么用、为什么这么用，那这篇文章就是为你准备的。我会尽量用生活化的类比来解释那些听起来很唬人的概念，同时保证技术细节不缩水，让你看完之后能自己动手搭一个完整的训练流程出来。
2. PyTorch到底是个什么东西：从“为什么需要它”说起
2.1 没有框架之前，人们是怎么做深度学习的
要理解PyTorch的价值，得先知道没有它的时候有多麻烦。早期做神经网络，研究者得自己手写反向传播的梯度计算。假设你设计了一个三层网络，每层的激活函数、损失函数都得自己推导导数，然后用代码实现出来。这还不算完，如果中间改了一个激活函数，整个梯度推导就得重来一遍。那种工作量和出错概率，想想都头皮发麻。
后来有了静态图框架，思路是把整个计算过程先定义好，再喂数据进去执行。这就像你先画好一张工厂流水线的图纸，机器按照图纸搭好，然后原料从一头进、成品从另一头出。好处是效率高、优化空间大，但坏处也很明显：你想改个流程，得把图纸重新画一遍。调试的时候更是痛苦，因为代码执行和图的构建是分开的，报错了你都不知道是哪一步出的问题。
PyTorch走的是另一条路。它让计算图在代码运行的过程中动态生成，你写一行代码，它就执行一行，同时把计算关系记录下来用于求导。这就像你一边走一边铺路，走到哪里路就铺到哪里。调试的时候可以直接用Python的print、pdb，跟写普通程序没什么区别。这个特性叫做动态计算图，是PyTorch最早打动人的地方。
2.2 动态图带来的实际好处
动态图不只是“调试方便”这么简单。它让一些复杂的模型结构变得容易实现。比如处理自然语言的时候，句子的长度是不固定的，循环神经网络需要根据实际输入长度来决定展开多少步。静态图框架处理这种情况就很别扭，得用各种填充和掩码技巧绕过去。而PyTorch里，你直接写个for循环遍历序列就行，每一步的计算图都是动态生成的，长度变化完全不是问题。
再比如条件分支。有些模型会根据输入的不同走不同的计算路径，比如一个门控网络决定用哪个子网络来处理当前样本。这在静态图里几乎没法优雅地实现，但在PyTorch里就是一个普通的if-else语句。这种灵活性让研究者能快速试验各种奇怪的想法，不用被框架的限制绑住手脚。
当然，动态图也不是没有代价。早期的PyTorch在性能上确实比静态图框架差一些，因为每次运行都要重新构建计算图，优化器没法提前做全局优化。但随着后续版本的迭代，这个问题已经被大幅缓解了。现在PyTorch也支持将模型编译成静态图来加速推理，算是把两边的优势都吃到了。
2.3 张量：PyTorch世界里的基本单位
PyTorch里最基础的数据结构叫张量。你可以把它理解成一个多维数组，跟NumPy的ndarray很像，但多了两个关键能力：一是可以在GPU上运行，二是可以记录计算历史用于自动求导。
为什么叫“张量”而不是“数组”？这其实是数学上的术语。标量是零维张量，向量是一维张量，矩阵是二维张量，再往上就是高维张量。深度学习里处理的数据基本都是高维的：一张彩色图片是三维的（高度、宽度、通道数），一批图片是四维的（批量大小、高度、宽度、通道数）。用张量来统一表示这些数据，操作起来就很自然。
张量的创建方式有很多种。你可以从Python列表直接转，也可以用内置的初始化函数生成特定形状的张量。比如生成全零、全一、随机数的张量，都有对应的函数。实际项目里最常用的是从数据加载器里直接拿到批量张量，或者从NumPy数组转换过来。
这里有一个新手很容易踩的坑：张量的形状。深度学习里大量的bug都跟形状对不上有关。比如你期望输入是(batch_size, channels, height, width)，结果实际拿到的是(batch_size, height, width, channels)，后面的卷积层就会报错。我的习惯是每写几步就打印一下张量的shape，确认维度符合预期。这个习惯能帮你省下大量调试时间。
3. 自动求导机制：PyTorch最核心的魔法
3.1 计算图是怎么记录下来的
PyTorch的自动求导靠的是一套叫autograd的机制。当你对一个张量进行操作时，如果这个张量的requires_grad属性是True，PyTorch就会在后台记录这个操作，构建出一张计算图。这张图里的节点是张量，边是操作。比如你做了y = x * 2 + 3，计算图里就会记录下乘法和加法这两个操作，以及它们之间的依赖关系。
当你最后调用y.backward()的时候，PyTorch会从y开始，沿着计算图反向传播，利用链式法则计算出每个需要梯度的张量的梯度值。这些梯度会累积到张量的.grad属性里。整个过程不需要你手动推导任何导数，框架全帮你做了。
这里有个细节值得注意：梯度是累积的。也就是说，如果你连续调用两次backward()而没有清零梯度，第二次的梯度会加到第一次的结果上。这个设计有它的道理，比如在处理多个损失函数或者梯度累积的时候会用到。但对新手来说，忘记清零梯度是一个极其常见的错误，会导致训练结果完全不对。所以标准的训练循环里，每次反向传播之前都要调用optimizer.zero_grad()或者手动把梯度置零。
3.2 哪些操作会被记录，哪些不会
不是所有操作都会被autograd记录。只有对requires_grad=True的张量进行的操作才会被追踪。如果你从这样的张量出发，经过一系列计算得到一个新张量，新张量的requires_grad自动就是True。但如果你用.detach()方法把张量从计算图里分离出来，或者用with torch.no_grad()上下文管理器包裹一段代码，那这段代码里的操作就不会被记录。
这个特性在实际中非常有用。比如在验证集上评估模型的时候，你不需要计算梯度，用torch.no_grad()包起来可以节省显存和计算时间。再比如你想把某个中间结果当作常量用，不希望梯度传回去，就可以用detach()。
还有一个容易混淆的点：原地操作。有些操作会直接修改张量的内容，比如x.add_(1)这种带下划线的版本。原地操作在autograd里可能会引发问题，因为反向传播需要用到前向传播时的值，如果你把值改掉了，梯度计算就可能出错。PyTorch在大多数情况下会检测到这种问题并报错，但最好的习惯是尽量避免对需要梯度的张量做原地操作。
3.3 自定义求导函数
虽然PyTorch内置了绝大多数常见操作的求导规则，但有时候你会遇到一些特殊的需求，比如实现一个新的激活函数，或者一个自定义的损失函数，框架里没有现成的反向传播实现。这时候就需要自己定义求导函数。
PyTorch提供了两种方式。一种是继承torch.autograd.Function类，手动实现forward和backward两个静态方法。forward里写前向计算逻辑，backward里写梯度回传的逻辑。这种方式比较底层，但控制力最强。另一种是用torch.autograd.functional里的工具函数，适合比较简单的场景。
对于大多数应用来说，你不需要自己写求导函数，因为组合现有操作就能实现绝大部分功能。但理解这个机制的存在，能让你在遇到奇怪报错的时候知道往哪个方向排查。
4. 从零搭建一个完整的训练流程
4.1 数据准备：Dataset和DataLoader
任何深度学习项目的第一步都是把数据整理成模型能吃的格式。PyTorch提供了两个核心类来帮忙：Dataset和DataLoader。
Dataset是一个抽象类，你需要继承它并实现两个方法：__len__返回数据集的大小，__getitem__根据索引返回一条数据。返回的数据可以是张量，也可以是张量组成的元组，比如(输入, 标签)。这种设计的好处是数据不需要一次性全部加载到内存里，对于大规模数据集来说非常关键。
DataLoader则负责从Dataset里批量取数据，并且支持多进程加速、随机打乱、自定义采样等高级功能。你只需要指定batch_size、shuffle、num_workers这几个参数，它就能帮你把数据流水线搭好。num_workers设置为大于0的值可以启用多进程加载，在数据预处理比较耗时的时候能显著提升训练速度。但也不是越大越好，设置成CPU核心数左右通常比较合适，太大了反而会因为进程间通信开销导致效率下降。
这里有一个实操心得：自定义Dataset的时候，__getitem__里尽量不要做太重的计算。如果每条数据都需要复杂的预处理，可以考虑提前处理好存成文件，或者用缓存机制。否则多进程加载的时候，每个worker都在重复做同样的计算，反而浪费资源。
4.2 模型定义：继承nn.Module
PyTorch里定义模型的标准方式是继承nn.Module类。你需要在__init__里声明所有的层，在forward方法里定义数据的前向传播路径。框架会自动帮你处理参数管理、梯度计算、GPU迁移这些事情。
为什么用类的方式而不是函数式的方式？因为模型通常包含可学习的参数，这些参数需要在训练过程中被优化器更新。nn.Module提供了一套完整的参数管理机制，你只要把层定义为类的属性，它们就会自动注册到模型的参数列表里。调用model.parameters()就能拿到所有需要优化的参数，直接传给优化器就行。
forward方法里你可以用任何Python控制流，包括if、for、while。这就是动态图带来的灵活性。比如你可以根据输入张量的某个属性来决定走哪条分支，或者根据序列长度决定循环多少次。这些在静态图框架里都需要特殊处理，在PyTorch里就是普通的Python代码。
有一个细节需要注意：不要在forward里创建新的层。层的创建应该放在__init__里，forward只负责调用已有的层。如果在forward里动态创建层，每次前向传播都会生成新的参数，优化器根本没法正确更新它们。这个错误在新手里不算罕见，因为代码看起来能跑通，但训练效果就是不对。
4.3 损失函数和优化器
损失函数衡量模型输出和真实标签之间的差距，优化器则根据这个差距来更新模型参数。PyTorch在torch.nn模块里提供了常见的损失函数，比如交叉熵、均方误差、负对数似然等。在torch.optim里提供了各种优化器，比如SGD、Adam、RMSprop等。
选择哪个损失函数取决于任务类型。分类任务通常用交叉熵损失，回归任务用均方误差，二分类可以用带Sigmoid的二元交叉熵。优化器的选择更多是经验问题。Adam因为自适应学习率的特性，在大多数任务上都能取得不错的效果，适合作为默认选择。SGD配合动量在调参得当的情况下可能达到更好的最终精度，但需要更仔细地调整学习率。
学习率是影响训练效果最大的超参数之一。设得太小，收敛慢得让人着急；设得太大，损失可能震荡甚至发散。一个实用的技巧是使用学习率调度器，在训练过程中动态调整学习率。比如余弦退火、阶梯下降、或者基于验证集表现的自适应调整。PyTorch的torch.optim.lr_scheduler模块提供了这些调度器的实现。
4.4 训练循环的骨架
一个标准的训练循环包含以下几个步骤：前向传播计算输出、计算损失、清零梯度、反向传播计算梯度、更新参数。这五步循环往复，直到模型收敛或者达到预设的训练轮数。
代码结构大概是这样的：外层循环遍历epoch，内层循环遍历DataLoader里的每个batch。每个batch里执行上述五步。在每个epoch结束后，通常在验证集上评估一下模型表现，看看有没有过拟合的迹象。
这里有几个实操中总结出来的注意事项。第一，确保模型处于训练模式。调用model.train()会启用Dropout和BatchNorm的训练行为。如果在验证时忘记调用model.eval()，Dropout仍然会随机丢弃神经元，导致验证结果不稳定。第二，损失值要取标量。如果损失是一个张量，调用backward()之前需要确保它是标量，否则会报错。通常损失函数返回的就是标量，但如果你自己写了损失计算逻辑，要注意这一点。第三，梯度裁剪。在训练循环神经网络或者Transformer的时候，梯度可能会变得非常大，导致参数更新过猛。用torch.nn.utils.clip_grad_norm_可以限制梯度的范数，让训练更稳定。
5. GPU加速：让训练快起来的关键
5.1 什么时候该用GPU
GPU在深度学习里的作用就是并行计算。神经网络的训练涉及大量的矩阵乘法和逐元素操作，这些操作天然适合并行化。一块中端GPU的浮点计算能力可能是高端CPU的几十倍，在训练大模型的时候差距非常明显。
但也不是所有情况都值得上GPU。如果你的模型很小、数据量也不大，CPU可能就够用了，而且省去了数据在CPU和GPU之间来回搬运的开销。判断标准很简单：如果训练一个epoch要等好几分钟甚至更久，那就该考虑GPU了。如果几秒钟就跑完了，CPU完全够用。
5.2 把模型和数据搬到GPU上
PyTorch里把东西搬到GPU上很简单，调用.to(device)就行。你需要定义一个device对象，根据是否有可用的GPU来决定用cuda还是cpu。然后把模型和每个batch的数据都搬到这个device上。
这里有一个常见的性能陷阱：不要在训练循环里反复创建device对象或者反复调用.to(device)。正确的做法是在循环外面把模型搬到GPU上，然后在循环里只搬数据。另外，从DataLoader取出的数据默认在CPU上，需要手动搬到GPU。这个搬运过程是有开销的，如果数据量小、模型计算量大，开销可以忽略；但如果数据量很大，可能会成为瓶颈。这时候可以考虑用pin_memory参数让DataLoader把数据放在锁页内存里，加速CPU到GPU的传输。
还有一个多GPU的情况。如果你的机器有多块GPU，可以用nn.DataParallel或者nn.parallel.DistributedDataParallel来并行训练。前者用起来简单，但效率不如后者。DistributedDataParallel需要每个GPU跑一个进程，配置稍微复杂一些，但扩展性更好。对于大多数个人项目来说，单GPU或者DataParallel就够用了。
5.3 显存管理
GPU的显存是有限的，训练大模型的时候经常会遇到显存不够的问题。PyTorch的显存管理机制是缓存式的，它不会在张量不再使用的时候立刻把显存还给系统，而是保留在缓存里以便后续快速分配。所以你看到的显存占用可能比实际需要的多。
如果遇到显存不足的报错，可以尝试以下几个方法。第一，减小batch_size。这是最直接有效的方法，但可能会影响训练稳定性。第二，使用梯度累积。用多个小batch的梯度累积起来模拟大batch的效果，代价是训练速度变慢。第三，混合精度训练。用半精度浮点数代替单精度，可以显著减少显存占用，同时还能加速计算。PyTorch提供了torch.cuda.amp模块来实现自动混合精度，用起来很方便。第四，及时释放不需要的张量。用del删除不再使用的变量，然后调用torch.cuda.empty_cache()清空缓存。不过频繁调用empty_cache()会影响性能，只在确实需要的时候用。
6. 迁移学习：站在别人的肩膀上
6.1 为什么迁移学习这么有用
从头训练一个深度神经网络需要大量的数据和计算资源。但在很多实际场景里，你手头的数据可能只有几百张图片，或者几千条文本。这种情况下从头训练几乎肯定会过拟合。迁移学习的思路是利用在大规模数据集上预训练好的模型，把它学到的通用特征迁移到你的任务上。
预训练模型在训练过程中学到了分层的特征表示。浅层网络学到的是边缘、纹理这类通用特征，深层网络学到的是更抽象、更任务相关的特征。对于新任务，你可以保留浅层网络，只重新训练深层网络，或者干脆把整个网络当作特征提取器，只训练最后几层分类器。
6.2 在PyTorch里做迁移学习的步骤
PyTorch的torchvision库提供了大量预训练模型，比如ResNet、VGG、EfficientNet等。加载一个预训练模型只需要一行代码，指定pretrained=True就行。加载之后，你可以选择冻结部分层的参数，让它们在训练过程中不更新。
冻结参数的方法是把对应参数的requires_grad设为False。通常的做法是冻结特征提取部分的所有层，只训练最后的分类头。分类头需要根据你的任务类别数重新定义，把原来的输出层替换成新的全连接层。
这里有一个经验之谈：学习率要设小一点。因为预训练模型的参数已经在一个很好的位置上了，太大的学习率会破坏这些学到的特征。通常比从头训练时的学习率小一个数量级左右。另外，可以给不同层设置不同的学习率，浅层用更小的学习率，深层用稍大的学习率，这样能在保留通用特征的同时让任务相关的层更快适应新数据。
6.3 微调的时机和策略
迁移学习有两种主要策略：特征提取和微调。特征提取是冻结所有预训练层，只训练新加的分类层。微调是解冻部分或全部预训练层，让它们在训练过程中也更新参数。
选择哪种策略取决于你的数据量和任务相似度。如果数据量小且任务和预训练任务相似，特征提取就够了。如果数据量较大，或者任务和预训练任务差异较大，微调能带来更好的效果。实际操作中，可以先尝试特征提取，如果效果不理想再逐步解冻更多层进行微调。
微调的时候要注意灾难性遗忘的问题。如果学习率太大或者微调轮数太多，模型可能会忘掉预训练时学到的有用特征，反而导致性能下降。监控验证集上的表现，在性能不再提升的时候及时停止训练，是一个实用的策略。
7. 模型保存、加载与部署
7.1 保存和加载模型参数
训练完一个模型之后，你需要把它保存下来以便后续使用。PyTorch里最推荐的方式是只保存模型的参数，也就是state_dict。这是一个字典，键是层的名字，值是对应的参数张量。保存的时候用torch.save，加载的时候先实例化模型结构，再用load_state_dict把参数填进去。
为什么不直接保存整个模型对象？因为整个模型对象包含了类的定义和结构信息，加载的时候需要能访问到定义模型的代码。如果代码结构变了，或者换了一个环境，加载就可能失败。只保存参数的话，只要模型结构定义一致，就能顺利加载。
保存的时候还可以把优化器的状态、当前的epoch数、最佳验证指标等信息一起存下来，方便以后继续训练。通常的做法是存一个字典，包含model_state_dict、optimizer_state_dict、epoch、loss等字段。
7.2 推理模式的注意事项
加载模型做推理的时候，一定要记得调用model.eval()。这会切换Dropout和BatchNorm的行为。Dropout在推理时会关闭，BatchNorm会使用训练时统计的均值和方差，而不是用当前batch的统计量。忘记调用eval()会导致推理结果不一致，同一个输入可能得到不同的输出。
另外，推理时用torch.no_grad()包裹起来，可以避免构建计算图，节省显存和时间。对于大批量推理，这个优化效果很明显。
7.3 部署到生产环境的几种路径
PyTorch模型部署到生产环境有几种常见方式。最简单的是直接用PyTorch做推理，把模型加载到内存里，每次请求来了就前向传播一次。这种方式适合请求量不大、对延迟要求不极端的场景。
如果对性能有更高要求，可以把模型导出成ONNX格式，然后用ONNX Runtime或者TensorRT来推理。ONNX是一个开放的模型交换格式，支持多种框架和硬件。导出成ONNX之后，可以用各种推理引擎来加速，通常能比原生PyTorch快不少。
还有一种方式是TorchScript。它可以把PyTorch模型编译成一种中间表示，脱离Python解释器运行。这对于嵌入式设备或者需要C++部署的场景很有用。TorchScript的转换过程需要模型的前向传播是静态可分析的，所以一些动态控制流可能需要改写。
选择哪种部署方式取决于具体需求。如果只是快速验证想法，直接用PyTorch最省事。如果追求极致性能，ONNX加推理引擎是更好的选择。如果需要在没有Python环境的设备上运行，TorchScript或者C++ API是必要的。
8. 常见问题与排查技巧实录
8.1 训练不收敛的排查思路
训练不收敛是新手最常遇到的问题。表现是损失值不下降，或者震荡得很厉害，或者直接变成NaN。排查的时候可以按照以下顺序来。
首先检查数据。把输入数据可视化一下，看看有没有异常值、标签有没有错位、归一化有没有做。我遇到过好几次因为数据归一化参数算错导致训练完全跑不动的情况。其次检查学习率。试着把学习率调小一个数量级，看看损失是否开始下降。如果调小之后能下降但很慢，说明学习率偏小；如果还是震荡，可能是模型结构或者数据有问题。然后检查损失函数。确认损失函数和任务类型匹配，比如多分类用交叉熵而不是均方误差。最后检查梯度。打印一下梯度的范数，如果梯度很小甚至为零，可能是梯度消失；如果梯度很大，可能是梯度爆炸，需要加梯度裁剪。
8.2 显存不足的应急处理
显存不足的报错信息通常很明确，会告诉你试图分配多少显存但只剩多少。遇到这种情况，先减小batch_size试试。如果减小到1还是不够，那可能是模型本身太大了。这时候可以考虑用混合精度训练、梯度检查点、或者模型并行等技术。
梯度检查点是一种用时间换空间的方法。它在前向传播时不保存中间激活值，在反向传播时重新计算这些值。这样能大幅减少显存占用，代价是训练速度变慢。PyTorch提供了torch.utils.checkpoint来实现这个功能。
还有一个容易被忽略的点：验证和推理时也会占用显存。如果在训练循环里同时做验证，而且没有用torch.no_grad()，验证过程也会构建计算图，显存占用会翻倍。确保验证和推理都在no_grad模式下进行。
8.3 多进程数据加载的坑
DataLoader的num_workers参数设置不当会导致各种奇怪的问题。在Windows上，多进程加载需要把主代码放在ifname== 'main'保护块里，否则会无限递归创建子进程。在Linux上一般没这个问题，但如果自定义Dataset里用了不可序列化的对象，也会报错。
另一个常见问题是随机种子。多进程加载时，每个worker有自己的随机状态。如果不设置种子，每次epoch的数据顺序可能不一样，影响实验的可复现性。可以在Dataset的__init__里设置种子，或者在worker_init_fn里统一设置。
还有一个性能相关的点：num_workers不是越大越好。每个worker都是一个独立的进程，进程间通信和内存复制都有开销。通常设置成CPU核心数或者稍小一点比较合适。如果数据加载本身很快，设置太大的num_workers反而会拖慢训练。
8.4 模型保存加载的版本兼容问题
PyTorch不同版本之间保存的模型可能不兼容。用新版本加载旧版本保存的模型，或者反过来，都可能报错。最稳妥的做法是在项目里固定PyTorch版本，并且在保存模型的时候记录下版本号。
如果确实需要跨版本加载，可以尝试用map_location参数指定加载到CPU上，然后再迁移到目标设备。有时候还需要手动调整state_dict里的键名，因为不同版本的层命名可能有变化。这种情况比较麻烦，最好的办法还是统一环境版本。
9. 一些让代码更顺手的实战习惯
9.1 固定随机种子保证可复现
深度学习实验里有很多随机性来源：参数初始化、数据打乱、Dropout、数据增强等。如果不固定随机种子，同样的代码跑两次可能得到不同的结果，这给调试和对比实验带来了很大困难。
固定种子的方法是在代码开头设置Python、NumPy、PyTorch的随机种子。但要注意，即使固定了种子，在GPU上的一些操作仍然可能是不确定的，因为CUDA的某些算法本身就有随机性。PyTorch提供了torch.use_deterministic_algorithms来强制确定性，但可能会牺牲一些性能。
我的习惯是在实验阶段固定种子，确保结果可复现。但在最终报告结果的时候，会用多个种子跑几遍，取平均值和标准差，这样更能反映模型的真实性能。
9.2 用TensorBoard或类似工具监控训练
光看损失值的变化很难全面了解训练状态。用TensorBoard可以记录损失曲线、准确率曲线、学习率变化、权重分布、梯度分布等信息，直观地看到训练过程中发生了什么。
PyTorch提供了torch.utils.tensorboard模块，用起来很简单。在训练循环里调用add_scalar记录标量，add_histogram记录分布，add_image记录图像。然后在命令行启动TensorBoard服务，浏览器里就能看到实时的可视化结果。
除了TensorBoard，还有一些第三方工具比如Weights & Biases、MLflow等，功能更强大，支持实验对比和超参数搜索。选择哪个看个人偏好和团队习惯。
9.3 配置文件管理超参数
把超参数硬编码在代码里不是个好习惯。当实验多了之后，你会记不清哪个结果对应哪组参数。用配置文件来管理超参数，可以让实验更有条理。
简单的做法是用Python的argparse或者JSON/YAML文件来存参数。更规范的做法是用专门的配置管理库，比如Hydra、OmegaConf等。这些库支持配置继承、命令行覆盖、多组实验并行等功能，能大幅提升实验效率。
我自己的习惯是把所有可调参数都放在一个YAML文件里，代码里只读配置不写死值。这样换一组参数只需要改配置文件，不用动代码。实验记录也方便，把配置文件和结果一起存档就行。
9.4 日志记录要详细但不啰嗦
训练过程中的日志对于排查问题和复现实验非常重要。但日志太多会淹没关键信息，太少又不够用。我的经验是记录以下几类信息：每个epoch的训练损失和验证损失、验证集上的关键指标、当前学习率、训练耗时、显存占用。如果做的是分类任务，还可以记录混淆矩阵或者每个类别的准确率。
日志的格式要统一，方便后续用脚本解析。通常用CSV或者JSON Lines格式，每行一条记录。这样可以用pandas直接读取分析，也可以导入到可视化工具里画图。
10. 关于PyTorch生态的一些个人观察
PyTorch发展到今天，已经不只是一个深度学习框架了，它周围形成了一个相当完整的生态。torchvision处理计算机视觉任务，torchaudio处理音频，torchtext处理自然语言。还有PyTorch Lightning这样的高层封装，把训练循环、分布式训练、混合精度这些样板代码都抽象掉了，让研究者能更专注于模型本身。
但工具多了也容易让人迷失。我的建议是先把原生PyTorch用熟，理解训练循环的每个细节，然后再根据需要引入高层工具。否则出了问题你都不知道是框架的锅还是封装的锅。原生PyTorch的代码虽然啰嗦一些，但每一步都清清楚楚，调试起来心里有底。
另外，PyTorch的社区非常活跃。遇到问题的时候，官方论坛、GitHub issues、Stack Overflow上通常都能找到答案。很多前沿论文的作者也会在GitHub上放出PyTorch实现，读这些代码是学习怎么写高质量深度学习代码的好途径。
最后说一个我自己的体会：PyTorch的API设计整体上很一致，学了一个模块之后，其他模块的用法往往能触类旁通。比如你学会了nn.Module的用法，再看nn.Sequential、nn.ModuleList、nn.ModuleDict就很容易理解。这种一致性降低了学习成本，也是它受欢迎的原因之一。
