1. 从一次版本更新说起为什么1.3这个节点值得单独聊2019年10月PyTorch 1.3 正式发布。如果你只扫一眼 release notes可能会觉得这个版本没什么大动作——没有颠覆性的 API 重构没有全新的训练范式。但我在那段时间正好在做一个序列到序列的文本生成项目从 1.2 升到 1.3 之后有几个变化是实打实影响了我日常写代码方式的。先说最直观的一个命名张量Named Tensors从实验性功能开始走向可用。在此之前我调试一个 Transformer 的注意力模块时最怕看到的就是RuntimeError: The size of tensor a (64) must match the size of tensor b (32) at non-singleton dimension 2这种报错。你盯着这行字脑子里要反推dim 2 到底是 batch、head 还是 seq_len而命名张量允许你给每个维度起名字报错信息会直接告诉你哪个命名维度对不上。这个改动看起来小但它解决的是深度学习工程里最消耗时间的一类问题——维度语义的丢失。再一个是量化Quantization支持的完善。1.3 把量化从能跑推进到了能用在生产推理上的阶段支持了动态量化、静态量化和量化感知训练三条路径。这意味着什么意味着你训练完的模型不再只能躺在实验室的 GPU 上而是可以压缩到 INT8 精度部署到 CPU 甚至移动端。对于做端侧推理的团队来说这是从PyTorch 只能做研究到PyTorch 也能做落地的关键一步。还有移动端部署PyTorch Mobile的正式可用以及TensorBoard 的原生集成。后者尤其值得说——以前用 PyTorch 想看训练曲线得装 tensorboardX 这个第三方库版本兼容问题层出不穷。1.3 之后torch.utils.tensorboard成了官方模块一行from torch.utils.tensorboard import SummaryWriter就能用。所以这篇内容不是要给你念一遍官方 changelog而是想从一个实际使用者的角度聊聊 PyTorch 1.3 这几个特性背后的设计逻辑、它们各自解决了什么真实痛点、以及放到今天这个时间点回看PyTorch 和 TensorFlow 这两条技术路线的走向到底是怎么被这些看似不起眼的版本迭代所决定的。如果你正在选框架、正在搭环境、或者正在纠结学哪个更有前途接下来的内容应该能给你一些比PyTorch 更 Pythonic这种空话更具体的判断依据。2. 命名张量到底解决了什么问题从维度报错说起2.1 维度语义丢失深度学习调试的隐形杀手我先描述一个几乎每个做深度学习的人都遇到过的场景。你写了一个多头注意力模块输入张量形状是(batch, seq_len, d_model)经过线性变换后拆成(batch, seq_len, n_heads, d_head)然后转置成(batch, n_heads, seq_len, d_head)去做bmm。这一串操作里你做了至少三次view、两次transpose、一次permute。每一步都在改变维度的物理位置但张量本身不记录第0维是batch这个信息。于是当你写错了一个转置或者两个张量的 head 数不一致时PyTorch 只能告诉你dim 2 的尺寸对不上。你得手动print(x.shape)然后在脑子里维护一张维度映射表。项目小的时候还好一旦模型有几十层、每层都有类似的变换这张表就会变成你的认知负担。命名张量的思路很直接让张量自己记住每个维度叫什么。你可以这样写import torch x torch.randn(32, 128, 512, names(batch, seq, feature)) w torch.randn(512, 256, names(feature, hidden)) y torch.matmul(x, w) # 自动对齐 feature 维度 print(y.names) # (batch, seq, hidden)注意这里的关键点matmul不再依赖维度的物理位置而是根据名字自动对齐。feature和feature匹配剩下的batch、seq保留hidden作为新维度加入。如果你把w的第二个维度也命名成feature那就会直接报错说命名冲突而不是等到运行时才发现形状不对。2.2 在注意力模块里的实际收益回到那个 seq2seq 的注意力模块。用命名张量重写之后代码的可读性和可调试性提升是明显的。我举一个简化版的例子# 传统写法 q q.view(batch, seq, n_heads, d_head).transpose(1, 2) k k.view(batch, seq, n_heads, d_head).transpose(1, 2) attn torch.bmm(q, k.transpose(-2, -1)) # 命名张量写法 q q.view(batch, seq, n_heads, d_head).refine_names(batch, seq, head, d_head) k k.refine_names(batch, seq, head, d_head) attn torch.matmul(q.align_to(batch, head, seq, d_head), k.align_to(batch, head, seq, d_head).rename(None).transpose(-2, -1))看起来更啰嗦了对吧但关键在于当你写错的时候报错信息会变成类似Expected tensor to have names (batch, head, seq, d_head) but got (batch, seq, head, d_head)。你一眼就能看出是align_to的顺序写错了而不是对着dim 2发呆。提示命名张量在 1.3 时期仍然是实验性功能部分算子还不支持。我的建议是在模型的关键接口处比如注意力模块的输入输出使用命名张量做校验内部计算仍然用普通张量这样既能获得调试收益又不会因为算子覆盖不全而卡住。2.3 为什么这个特性对框架选型有参考意义命名张量这个功能TensorFlow 在同期并没有对应的等价物。TF 的tf.Tensor虽然有shape但维度同样是无名的。你可能会说这不就是个语法糖吗但我想说的是一个框架愿不愿意在开发者体验这种不直接提升模型精度的地方投入恰恰反映了它的产品哲学。PyTorch 从诞生起就走的是define-by-run的动态图路线强调写起来像 NumPy、调试起来像普通 Python 程序。命名张量是这条路线上的自然延伸——既然动态图让控制流调试变简单了那命名张量就让形状调试变简单。而 TensorFlow 1.x 时代的静态图哲学是先定义计算图再喂数据它的优化目标是部署效率和跨平台一致性开发者体验在优先级列表上排得靠后。这个差异在 1.3 这个时间点已经非常明显了。3. 量化与移动端部署PyTorch 补上生产落地的短板3.1 量化三条路径的适用场景拆解PyTorch 1.3 的量化支持是我认为被低估的一个更新。很多人对量化的理解停留在把 FP32 变成 INT8模型变小四倍但实际做工程的时候你会发现量化分好几种做法选错了路径精度掉得你怀疑人生。动态量化Dynamic Quantization是最省事的一种。你训练完模型调用torch.quantization.quantize_dynamic它会在推理时动态地把权重转成 INT8激活值仍然保持浮点。适合什么场景LSTM、GRU、以及那些权重占主导、激活值分布变化不大的模型。我实测过一个两层 LSTM 的文本分类模型动态量化后模型体积从 12MB 降到 3MBCPU 推理延迟降低约 40%精度几乎无损。静态量化Static Quantization需要你提供一批校准数据calibration data让框架提前统计激活值的分布范围从而确定量化的 scale 和 zero_point。它比动态量化快因为激活值的量化也是提前算好的。适合 CNN 为主的视觉模型。但坑在于校准集的选择很关键。如果你用训练集的一小批样本做校准而实际推理数据分布有偏移精度就会明显下降。量化感知训练Quantization Aware Training, QAT是最重但效果最好的一种。它在训练阶段就插入伪量化节点让模型感知到量化误差从而在权重里补偿。适合对精度要求极高的场景比如医疗影像、自动驾驶感知。代价是你要重新训练训练时间可能翻倍。量化方式是否需要重训练是否需要校准数据典型精度损失适用模型动态量化否否极小LSTM/GRU/Linear静态量化否是小CNN量化感知训练是是最小任意3.2 PyTorch Mobile 的部署链路1.3 版本另一个重要更新是 PyTorch Mobile 进入正式可用阶段。在这之前把 PyTorch 模型部署到移动端基本是个不可能三角要么用 ONNX 转出去再转回来要么自己写 C 推理代码要么干脆换框架。PyTorch Mobile 的链路是这样的先用torch.jit.trace或torch.jit.script把模型转成 TorchScript然后用optimize_for_mobile做算子融合和量化最后导出.ptl文件在 Android 或 iOS 端用对应的运行时加载。import torch import torch.utils.mobile_optimizer as mobile_optimizer model MyModel() model.eval() example torch.randn(1, 3, 224, 224) traced torch.jit.trace(model, example) optimized mobile_optimizer.optimize_for_mobile(traced) optimized.save(model.ptl)这里有个实操心得torch.jit.trace对控制流是不友好的。如果你的模型里有if判断或者循环次数依赖输入trace 出来的图会固化某一条路径。这时候要用torch.jit.script它通过解析 Python 源码来生成图能保留控制流。但 script 对 Python 语法的支持有限有些动态特性用不了。我的经验是优先用 trace遇到控制流再局部改成 script。3.3 和 TensorFlow Lite 的对比同期 TensorFlow 在移动端有 TF Lite而且 TF Lite 的生态成熟度在当时是领先的——支持的算子更多文档更全社区案例更丰富。但 PyTorch Mobile 有一个优势训练和部署用同一套 API。你不需要学一套新的图定义语言不需要处理转换过程中的算子不兼容问题ONNX 转换的痛做过的人都懂。这个差异在团队协作里会被放大。如果一个团队用 PyTorch 做研究用 TF Lite 做部署那中间就多了一道转换和维护成本。而 PyTorch Mobile 让研究到部署的链路缩短了。虽然 1.3 时期它的算子覆盖还不如 TF Lite但方向是对的。4. TensorBoard 原生集成一个被低估的体验升级4.1 tensorboardX 时代的兼容性噩梦在 1.3 之前PyTorch 用户想看训练曲线标准做法是装tensorboardX。这个库是社区开发者写的把 PyTorch 的标量、图像、直方图等数据写成 TensorBoard 能读的格式。问题在于它和 TensorFlow 的版本是耦合的——TensorBoard 本身是 TF 生态的一部分tensorboardX要跟着 TF 的版本走。我遇到过最离谱的一次是服务器上装的是 TF 1.12tensorboardX要求 TF 1.14 以上但升级 TF 又会影响另一个项目的代码。最后只能建两个 conda 环境来回切换。这种依赖地狱在 1.3 之后基本消失了因为torch.utils.tensorboard是官方维护的它只依赖tensorboard这个独立的包不再和 TF 主包绑定。4.2 实际使用中的几个细节官方集成之后用法和 tensorboardX 几乎一样from torch.utils.tensorboard import SummaryWriter writer SummaryWriter(runs/experiment_1) for epoch in range(epochs): writer.add_scalar(Loss/train, train_loss, epoch) writer.add_scalar(Loss/val, val_loss, epoch) writer.add_histogram(weights/fc1, model.fc1.weight, epoch) writer.close()但有几个细节值得注意。第一SummaryWriter的log_dir如果包含中文路径在某些系统上会有编码问题建议用纯英文。第二add_histogram记录权重分布时如果每步都记日志文件会膨胀得很快。我的做法是每隔 N 个 epoch 记一次或者只在验证阶段记。第三如果你用torch.jit导出的模型add_graph是可以直接可视化计算图的这对检查模型结构很有帮助。注意TensorBoard 的日志目录不要放在会被 git 追踪的路径下。我见过有人把runs/提交到仓库结果仓库体积暴涨。记得在.gitignore里加上runs/。4.3 这个改动背后的信号TensorBoard 原生集成这件事表面看是少装一个库但它传递的信号是PyTorch 开始认真对待工程化体验了。一个框架如果只关心能不能训出模型它不会在意可视化工具是不是官方维护的。但当它开始在意这些周边的时候说明它的目标用户从研究人员扩展到了工程团队。这个信号在 1.3 之后的版本里越来越明显TorchServe 做模型服务、TorchElastic 做分布式训练容错、PyTorch Profiler 做性能分析。这些工具的共同点是它们不提升模型精度但提升的是把模型用起来的效率。TensorFlow 在 1.x 时代靠 TF Serving、TF Lite、TFX 建立起来的工程化优势PyTorch 正在一步步追平。5. 从安装踩坑看两个框架的生态差异5.1 PyTorch 安装conda 与 pip 的选择聊完特性说点更接地气的——安装。我在不同机器上装过无数次 PyTorch总结下来conda 和 pip 的选择会直接影响你后续的依赖管理体验。如果你用 conda命令是这样的conda install pytorch torchvision torchaudio cudatoolkit10.1 -c pytorch注意-c pytorch这个 channel 参数。PyTorch 官方维护了自己的 conda channel里面的包是和特定 CUDA 版本编译好的。如果你不加这个参数conda 可能会从defaultschannel 里找一个版本那个版本可能不带 CUDA 支持或者 CUDA 版本和你的驱动不匹配。如果你用 pippip install torch1.3.0 torchvision0.4.1pip 装的是 PyPI 上的 wheel 包默认是 CUDA 10.1 编译的。如果你的驱动只支持 CUDA 9.2那就得去 PyTorch 官网的Previous Versions页面找对应版本的 wheel。这里有个我踩过的坑conda 装的 PyTorch 和 pip 装的 PyTorch 不要混用。我曾经在一个环境里先用 conda 装了 PyTorch后来用 pip 装了一个依赖库结果 pip 把 PyTorch 的依赖比如 numpy升级了导致 PyTorch 找不到兼容的 numpy 版本直接 import 失败。解决办法是要么全用 conda要么全用 pip别混。5.2 验证 GPU 是否可用一个必做的检查装完之后别急着跑模型先做这个检查import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果is_available()返回 False常见原因有三个一是装的 CPU 版本二是 CUDA 版本和驱动不匹配三是环境变量CUDA_VISIBLE_DEVICES被设成了空。第三个原因最隐蔽我有一次在服务器上排查了半小时最后发现是同事在.bashrc里设了这个变量。5.3 TensorFlow 安装的对比体验同期装 TensorFlow 的体验说实话更折腾。TF 1.x 的 pip 包和 CUDA、cuDNN 的版本对应关系非常严格装错一个小版本就报ImportError: libcudart.so.10.0: cannot open shared object file。而且 TF 的 GPU 版本和 CPU 版本是两个不同的包名tensorflow和tensorflow-gpu装错了不会自动切换只会默默用 CPU 跑你还不一定发现。PyTorch 在这方面做得更友好一个包同时包含 CPU 和 GPU 支持运行时自动检测。这个差异看起来小但对于刚入门的人来说少一个坑就少一次劝退。对比项PyTorch 1.3TensorFlow 1.x包管理conda/pip 均可官方 channelpip 为主GPU 需单独包CUDA 兼容一个包多 CUDA 版本版本对应严格验证方式torch.cuda.is_available()需手动指定 device环境隔离conda 环境友好依赖冲突较常见6. 两条路线的分岔动态图与静态图的哲学之争6.1 动态图为什么赢了研究者的心PyTorch 的核心竞争力说到底就一条动态计算图。你写的每一行 PyTorch 代码都是立即执行的。y x 1执行完y就有值了。你可以print(y)可以用pdb打断点可以写if判断可以写for循环一切就像普通 Python 程序。TensorFlow 1.x 的静态图是另一套逻辑。你先定义一张计算图y tf.add(x, 1)只是往图里加了一个节点y本身没有值。要拿到值得开一个Sessionsess.run(y)。调试的时候你不能直接print(y)得print(sess.run(y))。控制流要用tf.cond、tf.while_loop这些专门的算子不能直接用 Python 的if和while。这个差异在写论文、做实验的时候是致命的。研究的特点是快速试错——你有一个想法想验证它行不行需要频繁改模型结构、改损失函数、改数据流。动态图让这个过程像写普通脚本一样自然而静态图每次改动都要重新构图、重新编译迭代速度差了一个数量级。6.2 静态图在部署端的优势但静态图不是没有优点。它的优势在部署图定义好之后可以整体优化——算子融合、内存复用、跨平台编译。TensorFlow 1.x 靠这个优势在工业界建立了很深的护城河。TF Serving、TF Lite、TPU 支持都是建立在静态图基础上的。所以 2019 年前后的局面是研究用 PyTorch部署用 TensorFlow。很多团队的做法是用 PyTorch 做原型验证验证通过后用 TensorFlow 重写一遍做上线。这个重写的成本就是静态图和动态图之间的鸿沟。6.3 TensorFlow 2.0 的应对与 PyTorch 的回应TensorFlow 2.0 在 2019 年 10 月发布核心变化就是默认启用 Eager Execution动态图同时保留tf.function装饰器把 Python 函数编译成静态图。这个策略叫动态图优先静态图可选明显是在向 PyTorch 靠拢。而 PyTorch 这边1.3 之后的版本在补静态图的能力——torch.jit.script和torch.jit.trace就是它的答案。你可以用动态图开发用 TorchScript 导出静态图部署。两条路线在中间相遇了。这个相遇对使用者的意义是框架之间的迁移成本在降低。你不再需要因为部署需求而被迫换框架。但代价是两个框架的 API 都在变复杂——PyTorch 要学 TorchScriptTensorFlow 要学 Eager 和tf.function的切换。这是工程化的必然代价。7. 2024 年回看流行趋势与选型建议7.1 数据上的趋势如果看 2024 年的框架使用数据PyTorch 在研究领域的优势已经非常稳固。顶会论文的代码实现PyTorch 占比超过八成。Hugging Face 的模型库默认权重格式是 PyTorch 的state_dictTensorFlow 权重往往需要额外转换。这个生态效应是自我强化的新模型用 PyTorch 发布新研究者用 PyTorch 复现新论文用 PyTorch 写代码。TensorFlow 在工业部署端仍然有存量优势尤其是那些在 TF 1.x 时代就建立起来的推荐系统、广告系统。但增量市场PyTorch 的势头更猛。TorchServe、ONNX Runtime、TensorRT 对 PyTorch 的支持都在完善。7.2 给不同角色的选型建议如果你是学生或研究者直接学 PyTorch。它的调试体验、社区资源、论文复现代码的丰富度都是当前最优解。pytorch教程、pytorch入门这些搜索词的热度也反映了这一点。如果你是从业者团队已有 TF 1.x 存量不要急着迁移。TF 1.x 的模型如果能稳定运行迁移的收益可能抵不上成本。但新项目可以考虑 PyTorch或者 TF 2.x。如果你做端侧部署两个框架都要了解。PyTorch Mobile 和 TF Lite 各有优劣选哪个取决于你的模型类型和团队技术栈。如果模型是 Transformer 类PyTorch 的生态支持更好如果是传统 CNNTF Lite 的算子覆盖更全。如果你在搭环境anaconda配置pytorch环境是最省心的路径。conda 的环境隔离能避免大部分依赖冲突。Ubuntu 下装 PyTorch记得先确认显卡驱动版本再选对应的 CUDA 版本。Windows 下用 Anaconda PyCharm 的组合是目前比较成熟的方案。7.3 一个容易被忽略的点Transformer 生态transformer pytorch tensorflow这个搜索词反映了一个现实Transformer 架构已经成为主流而它的 PyTorch 实现比如 Hugging Face 的transformers库比 TensorFlow 实现更活跃。如果你要做 NLP、要做注意力机制相关的模型PyTorch 几乎是默认选择。我在做a generic attention module for a decoder in seq2seq这类项目时Hugging Face 的transformers库提供了现成的注意力实现直接调用就行。而 TensorFlow 这边虽然也有对应的实现但版本更新频率和社区活跃度都差一些。这个生态差距在具体项目里会变成实实在在的时间成本。8. 我个人的一些实操体会说了这么多框架层面的分析最后分享几个我在实际项目里总结的小经验都是踩过坑之后才明白的。第一不要追最新版本。PyTorch 1.3 发布的时候我第一时间升级结果有个依赖库还没适配卡了两天。后来我的策略是等小版本迭代到 x.3 或 x.4 再升这时候社区该踩的坑都踩完了issue 里能找到解决方案。第二环境一定要隔离。不管是 conda 还是 venv每个项目一个环境。我见过太多因为环境混乱导致昨天还能跑今天就不行了的案例。conda env export environment.yml这个命令要养成习惯把环境固化下来。第三TorchScript 不是万能的。导出模型之前先用torch.jit.trace跑一遍对比输出和原模型是否一致。我遇到过一次 trace 之后输出有细微差异排查发现是某个自定义算子没有被正确追踪。这种问题不对比输出是发现不了的。第四量化的精度损失要实测。不要相信文档里说的精度几乎无损那是在特定模型、特定数据集上的结论。你自己的模型一定要在验证集上跑一遍量化前后的对比确认精度下降在可接受范围内再上线。第五TensorBoard 的日志要定期清理。runs/目录会随着训练不断膨胀尤其是记录了直方图的时候。我一般会在每个实验结束后把有用的曲线截图保存然后删掉日志文件。磁盘空间在服务器上是稀缺资源。框架选型这件事没有绝对的对错只有适不适合你的场景。PyTorch 1.3 这个版本在我看来是它从研究工具向工程平台转型的一个标志性节点。命名张量、量化、移动端、TensorBoard 集成这些更新单独看都不算惊艳但合在一起它们补齐了 PyTorch 在生产落地上的短板。而 TensorFlow 也没有停下2.0 的 Eager Execution 就是对 PyTorch 最直接的回应。两条路线在竞争中互相借鉴最终受益的是我们这些写代码的人。