1. 那句“疯子或骗子”到底在骂什么第一次听到“搞深度学习框架的那帮人不是疯子就是骗子”这句话我正蹲在机房调一个卷积层的显存溢出问题屏幕上滚着几百行报错旁边同事递过来一杯咖啡说了这句话。当时我笑了后来越琢磨越觉得这话扎心因为它精准地戳中了一个事实深度学习框架这个领域外行看热闹内行看门道而门道里全是反直觉的设计决策。先把话说清楚这句话不是在骂人而是在描述一种认知落差。深度学习框架的开发者要同时满足两类完全矛盾的需求一类来自算法研究员他们要的是灵活、能快速试错、能表达任意奇怪的计算图另一类来自工程部署他们要的是稳定、高效、能在各种硬件上跑出接近峰值的性能。这两类需求本质上是对立的灵活往往意味着性能损失高效往往意味着表达受限。框架作者必须在中间找一个平衡点而这个平衡点在旁观者眼里要么显得过度设计疯子要么显得承诺了做不到的事骗子。我拿一个具体例子说明。TensorFlow 1.x 时代用的是静态图你得先定义整个计算图再喂数据执行。这个设计在部署时非常香图可以被优化、被序列化、被各种编译器处理。但对研究员来说调试一个动态控制流简直是噩梦你想打印个中间变量都得用 tf.Print 这种别扭的方式。于是 PyTorch 带着动态图来了define-by-run写起来跟普通 Python 一样自然研究员爱不释手。可动态图在早期部署性能上就是打不过静态图于是 PyTorch 又搞出了 TorchScript、又搞出了 2.0 的 compile。你看绕了一大圈两边都在向对方靠拢。所以那句话的真正含义是框架作者在做一个多目标优化问题而任何多目标优化的解在单目标视角下看都是“有病”的。理解了这一点你再看 TensorFlow、PyTorch、Caffe、MXNet 这些名字就不会只把它们当成工具而会看到它们背后各自押注的技术路线和取舍哲学。这篇文章我想聊的不是“哪个框架好”那种文章太多了。我想聊的是这些框架为什么长成现在这样它们各自解决了什么别人解决不了的问题以及作为一个实际要用它们干活的人你该怎么理解这些设计怎么在踩坑的时候不骂娘而是知道坑从哪来。关键词里那些 tensorflow安装、pytorch环境搭建、pytorch转onnx、cuda和pytorch版本对应本质上都是这些设计决策在落地时溅起的水花。2. 从Caffe到PyTorch框架演化背后的取舍逻辑2.1 Caffe的“配置即模型”为什么曾经是先进生产力现在年轻人可能没怎么用过 Caffe但在 2014 到 2016 年那会儿Caffe 是计算机视觉领域的绝对主力。它的核心设计哲学是模型用 prototxt 配置文件描述层与层之间的连接、参数、初始化方式全写在文本里然后用一个统一的 solver 去训练。你不需要写多少代码改改配置就能跑一个新网络。这个设计在当时是极其先进的。为什么因为那个年代大家还在手写反向传播每个实验室都有自己的祖传代码复现一篇论文要花几周甚至几个月。Caffe 把模型定义标准化了prototxt 一贴别人就能复现你的网络结构。它牺牲的是灵活性——你想加一个自定义层得写 C 和 CUDA编译整个框架门槛高得吓人。但对于当时主流的分类、检测任务标准层已经够用了所以这个取舍是划算的。Caffe 的衰落也恰恰源于这个取舍。当研究前沿转向动态结构、注意力机制、序列建模时prototxt 这种静态配置表达起来就非常吃力。你很难在配置文件里写一个“根据输入长度动态决定循环次数”的模块。于是大家开始往 TensorFlow 和 PyTorch 迁移。这告诉我们一个道理框架的生死不取决于它当时多流行而取决于它的抽象能不能跟上研究范式的迁移。2.2 MXNet的“多语言前端”赌错了什么MXNet 当年也是明星项目亚马逊大力推它的卖点是多语言前端Python、Scala、Julia、R、C 都能用底层是一个统一的 C 引擎。这个设计听起来很美一套计算图多种语言绑定。但实际用起来问题就来了。多语言前端意味着每个语言绑定的维护成本都很高而社区的人力是有限的。当 PyTorch 用纯 Python 的亲和力吸走大量用户时MXNet 的 Python 前端体验始终差一口气。更关键的是MXNet 早期主推的 Gluon 接口虽然借鉴了动态图的思路但推出时机比 PyTorch 晚生态已经被人占了。我印象很深的是当年想用 MXNet 跑一个自定义的 seq2seq 注意力模块文档里翻半天找不到清晰的例子而 PyTorch 的教程里已经有现成的 attention 实现可以抄。MXNet 的教训是技术上的优雅不等于生态上的胜利。一个框架能不能活取决于最活跃的那批开发者愿不愿意在上面写教程、发论文、回答问题。多语言前端分散了精力反而让核心体验没做到极致。2.3 PyTorch的“define-by-run”为什么赢了研究员的心PyTorch 刚出来的时候很多人觉得它就是个“带自动求导的 NumPy”没什么了不起。但它赢就赢在这个“没什么了不起”上。define-by-run 意味着你的计算图是在运行时动态构建的你可以用 Python 的 if、for、while可以随时打印中间结果可以用 pdb 单步调试。这对研究员来说太重要了因为研究本身就是不断试错调试体验直接决定迭代速度。我举个实际场景。你要实现一个带条件分支的注意力模块比如“如果序列长度超过阈值就用稀疏注意力否则用全注意力”。在静态图框架里你得用 tf.cond 之类的原语写起来别扭调试更难。在 PyTorch 里你直接写 if-else 就行因为图是运行时建的。这种表达上的自由让 PyTorch 迅速成为论文复现的首选。但 PyTorch 早期在部署上确实吃亏。动态图每次执行都要重新解释没法做全局优化也没法方便地序列化到 C 环境。所以后来有了 TorchScript有了 ONNX 导出有了 2.0 的 torch.compile。这些都是在补动态图的短板。你看PyTorch 的演化路径就是先用灵活性占领研究阵地再逐步补性能和部署的课。2.4 TensorFlow的“工业级”执念带来了什么TensorFlow 从诞生起就带着 Google 的工业基因它的目标不只是让研究员跑实验而是让模型能从实验室一路走到生产环境。所以它早期押注静态图、押注分布式、押注 TPU 支持、押注 Serving 系统。这些在工业场景下都是刚需但在研究场景下就显得笨重。我印象最深的是 TensorFlow 1.x 的 Session 机制。你得先建图再开 Session再 run中间还有 feed_dict 这种效率不高的数据传递方式。对习惯了 NumPy 的人来说这个心智负担很重。但一旦你接受了这个范式你会发现它的图可以被 SavedModel 序列化可以被 TensorFlow Serving 加载可以在手机上用 TFLite 跑可以在浏览器里用 TF.js 跑。这套端到端的工业链路是 PyTorch 早期完全不具备的。TensorFlow 2.x 转向 eager execution其实是在向 PyTorch 的易用性妥协。但它没有完全放弃静态图而是用 tf.function 把动态代码自动转成静态图。这个设计很聪明你写的时候是动态的跑的时候是静态优化的。但这也带来了新的坑比如 tf.function 里的 Python 副作用行为跟普通 Python 不一样很多人在里面踩过坑。3. 环境搭建那些坑从CUDA版本到WSL的完整避坑链路3.1 CUDA和PyTorch版本对应为什么你总是装错关键词里“cuda和pytorch版本对应”是个高频搜索因为这是新手最容易翻车的地方。我先说清楚原理PyTorch 的 GPU 版本是预编译好的二进制包它链接了特定版本的 CUDA 运行时。你本机装的 CUDA 驱动版本必须不低于 PyTorch 编译时用的 CUDA 版本否则跑不起来。这里有个关键区分驱动版本和运行时版本是两回事。nvidia-smi 显示的是驱动支持的最高 CUDA 版本而 PyTorch 需要的是它自己编译时链接的 CUDA 运行时。比如 PyTorch 2.0 的某个版本是用 CUDA 11.7 编译的那你本机驱动只要支持 11.7 及以上就行不一定非要装 CUDA 11.7 的完整工具包。很多人误以为要装一模一样的 CUDA Toolkit结果把系统搞乱。我的建议是先确定你要用的 PyTorch 版本去官网查它对应的 CUDA 版本然后确认你的驱动版本够不够。如果不够升级驱动如果够直接用 conda 或 pip 装 PyTorch 的 GPU 版它会自带 CUDA 运行时不需要你单独装 Toolkit。只有当你需要编译自定义 CUDA 算子时才需要完整 Toolkit。PyTorch版本推荐CUDA版本最低驱动版本Linux2.0.x11.7 / 11.8450.80.022.1.x11.8 / 12.1450.80.022.2.x11.8 / 12.1450.80.021.13.x11.6 / 11.7450.80.02注意上表是常见组合具体以官方安装命令为准。装之前一定去官网复制对应的安装命令不要凭记忆敲。3.2 conda环境隔离为什么你的pytorch装完就坏“anaconda配置pytorch环境”是另一个高频问题。我见过太多人直接在 base 环境里 pip install torch然后某天装了个别的包把依赖冲突了整个环境报废。正确做法是每个项目一个 conda 环境。conda create -n dl_env python3.10 conda activate dl_env # 然后去PyTorch官网复制对应命令例如 conda install pytorch torchvision torchaudio pytorch-cuda11.8 -c pytorch -c nvidia这里有个细节conda 装 PyTorch 和 pip 装 PyTorch 的包来源不同混用容易出问题。我的经验是如果一开始用 conda 装后续就尽量用 conda如果要用 pip就统一用 pip。混着来迟早会遇到“明明装了却 import 失败”的诡异情况。还有一个坑是 Python 版本。PyTorch 对 Python 版本有要求太新的 Python 可能还没有对应的 wheel 包。比如 Python 3.12 刚出的时候PyTorch 还没跟上你 pip install 会找不到包。所以稳妥起见用 3.10 或 3.11 这种经过验证的版本。3.3 WSL和Ubuntu安装PyTorch路径和权限的坑“pytorch环境搭建wsl”和“ubuntu 安装pytorch”这两个搜索词说明很多人在 Windows 上用 WSL 做深度学习。WSL 的好处是能用 Linux 生态但坑也不少。第一个坑是文件系统性能。如果你把代码和数据放在 /mnt/c/ 下面也就是 Windows 的 C 盘IO 性能会非常差训练时数据加载会成为瓶颈。正确做法是把项目放在 WSL 自己的文件系统里比如 ~/projects/这样 IO 性能接近原生 Linux。第二个坑是 CUDA 支持。WSL2 支持 CUDA但需要 Windows 端的驱动足够新并且要装 WSL 专用的 CUDA 驱动。很多人装了普通 Windows 驱动结果 WSL 里 nvidia-smi 能跑但 PyTorch 用不了 GPU。这个要专门去查 WSL CUDA 的安装指南。第三个坑是权限。WSL 里默认用户可能没有某些目录的写权限conda 装包时报权限错误。解决办法是别用 sudo 跑 condaconda 环境应该装在用户目录下用普通用户权限操作。3.4 那个ctypes报错mxnet导入失败的经典案例关键词里有个很具体的报错“mxnet导入时file c:\python34\lib\ctypes_init_.py line 351 ininit”。这个报错我一看就笑了因为它是典型的 Python 版本太老导致的。Python 3.4 是 2014 年的版本而 MXNet 的很多版本要求 Python 3.6 以上。ctypes 在 3.4 里的实现跟新版有差异导入时初始化失败。这个案例的教训是深度学习框架对 Python 版本有硬性要求别拿一个老旧的 Python 环境去装新框架。如果你在 Windows 上看到路径里是 python34第一件事就是升级 Python。而且 Windows 上装深度学习框架本来就坑多路径里的反斜杠、缺少编译工具链、DLL 加载失败都是常见问题。我的建议是除非有特殊需求深度学习开发尽量在 Linux 或 WSL 下做能省掉一半的麻烦。4. 部署路上的拦路虎pytorch转onnx和跨框架迁移4.1 为什么需要转ONNX中间表示的价值“pytorch转onnx”是个高频需求因为训练用 PyTorch部署可能要用 TensorRT、OpenVINO、或者别的推理引擎。ONNX 是一个中间表示格式相当于一个“通用翻译”把 PyTorch 的模型翻译成 ONNX再由目标引擎翻译成自己的格式。这个设计的好处是解耦PyTorch 不需要为每个推理引擎写适配推理引擎也不需要支持每个训练框架。但坏处是翻译过程中会丢信息。PyTorch 的动态特性、自定义算子、复杂的控制流在 ONNX 里可能没有对应表达。所以转 ONNX 经常遇到算子不支持、动态维度处理不了、精度对不上的问题。我转过一个带自定义注意力模块的模型PyTorch 里跑得好好的转 ONNX 时那个自定义算子直接报不支持。解决办法是要么用 ONNX 的标准算子重写要么写自定义 ONNX 算子后者工作量很大。所以如果你计划部署最好在模型设计阶段就考虑 ONNX 的兼容性别等训练完了才发现转不过去。4.2 动态维度转ONNX时最容易翻车的地方ONNX 默认是静态形状的但很多模型需要支持变长输入比如 NLP 里的序列长度。转的时候要显式指定 dynamic_axes告诉 ONNX 哪些维度是动态的。torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size, 1: seq_len}, output: {0: batch_size, 1: seq_len} } )这里有个坑dynamic_axes 的键必须跟 input_names 和 output_names 对应写错了不会报错但导出结果是静态的。还有就是即使你指定了动态维度某些算子内部可能还是假设静态形状运行时遇到不同长度会崩。所以转完之后一定要用不同 batch size 和序列长度测一遍。4.3 精度对齐转完之后结果不一样怎么办转 ONNX 之后最常见的抱怨是“结果跟 PyTorch 对不上”。原因可能有很多算子实现差异、浮点累加顺序不同、某些优化改变了计算。排查方法是逐层对比先对比输入再对比第一层输出一层层往下找看从哪层开始偏差变大。一般来说小的数值差异1e-5 量级是正常的浮点运算本来就不满足结合律。但如果差异大到影响结果那就是算子实现有问题。这时候可以尝试禁用 ONNX 的图优化或者换一个 opset 版本。opset 版本很关键新算子往往需要更高的 opset但高 opset 可能不被目标推理引擎支持要在兼容性和功能之间权衡。5. 框架选型的现实考量2024年我们该怎么选5.1 研究场景PyTorch的统治地位还能持续多久“tensorflow与pytorch的流行趋势 2024年”这个搜索词反映了很多人的焦虑我该学哪个。从论文复现的角度看PyTorch 目前是绝对主流顶会论文的官方实现绝大多数是 PyTorch。这不是因为 PyTorch 技术上全面碾压而是因为生态惯性——大家都用教程多遇到问题好搜。但 PyTorch 2.0 之后引入的 compile 机制其实是在向 TensorFlow 的图模式靠拢。未来的趋势可能是两者的界限越来越模糊PyTorch 越来越能编译优化TensorFlow 越来越易用。对研究员来说选 PyTorch 短期内不会错但也要关注编译相关的知识因为那代表了性能优化的方向。5.2 工业部署TensorFlow Serving和TorchServe的差异工业部署场景下TensorFlow 的 Serving 系统成熟度仍然领先。它的模型版本管理、A/B 测试、热更新、监控指标都是经过大规模生产验证的。TorchServe 虽然也在进步但在超大规模部署的案例上还不如 TensorFlow Serving 丰富。不过这个差距在缩小。PyTorch 的 TorchScript 和 2.0 的 compile 让模型可以脱离 Python 运行时执行部署灵活性大幅提升。而且很多公司选择用 ONNX 作为中间格式训练用 PyTorch部署用 ONNX Runtime 或 TensorRT这样就绕开了框架自带的 Serving 系统。5.3 边缘设备TFLite和PyTorch Mobile的取舍边缘设备上TFLite 的生态更成熟量化工具链更完善支持的硬件后端更多。PyTorch Mobile 起步晚但在追赶。如果你做的是手机端或嵌入式部署TFLite 目前还是更稳妥的选择。但如果你训练用 PyTorch转 TFLite 需要经过 ONNX 或直接转换中间可能有算子损失要提前验证。5.4 一个实用建议别把鸡蛋放一个篮子我的实际经验是别把自己绑死在一个框架上。核心能力是对深度学习原理的理解框架只是工具。我见过太多人只会用 PyTorch 的某个 API换个框架就手足无措。真正值钱的能力是看到一个模型结构能理解它的计算逻辑遇到性能问题能定位是算子、内存还是通信的瓶颈需要部署时知道怎么选中间格式和推理引擎。所以我的建议是主攻一个框架目前推荐 PyTorch但至少了解另一个框架的基本用法知道 ONNX 这种中间格式怎么用。这样在项目需要切换时你不会从零开始。6. 那些年我踩过的框架坑和总结出的经验6.1 显存溢出不一定是batch size的错很多人一遇到 OOM 就调小 batch size但有时候问题不在 batch size。PyTorch 的动态图会保留中间激活值用于反向传播如果你在 forward 里做了很多中间计算但没及时释放显存会爆。解决办法是用 torch.no_grad() 包住不需要梯度的部分或者用 checkpoint 技术用计算换显存。还有一个隐蔽的坑是碎片化。频繁申请释放不同大小的显存会导致碎片明明总显存够但就是分配不出来。这时候可以试试设置 PYTORCH_CUDA_ALLOC_CONF 环境变量来调整分配策略。6.2 多卡训练DataParallel和DistributedDataParallel的选择单机多卡训练早期大家用 DataParallel但它有个致命问题主卡负载高因为梯度都汇总到主卡。而且它用 Python 线程做并行GIL 限制了效率。正确做法是用 DistributedDataParallel每个卡一个进程通信效率高负载均衡。虽然配置麻烦一点但性能提升明显。配置 DDP 的坑在于进程组初始化、端口冲突、以及数据采样器的正确设置。我建议直接抄官方示例别自己从头写。还有就是要确保每个进程的随机种子不同否则数据增强会重复。6.3 版本升级为什么你的代码在新版跑不通深度学习框架的 API 变动很频繁PyTorch 从 1.x 到 2.x 有不少破坏性变更。比如某些函数的参数改名了某些默认行为变了。升级框架后代码跑不通是常态。我的经验是生产环境锁定版本别随便升级。研究环境可以追新但要留好回退方案。用 conda 的 environment.yml 或 pip 的 requirements.txt 记录精确版本这样换机器能复现。还有就是要看官方的 release note里面会列破坏性变更提前知道能省很多调试时间。6.4 一个反直觉的经验文档读不懂时去看源码深度学习框架的文档有时候写得很简略尤其是涉及底层行为的时候。比如某个算子的梯度怎么算的文档可能就一句话。这时候别死磕文档直接去看源码。PyTorch 的源码是 Python 和 C 混合的Python 部分很好读能帮你理解算子的前向逻辑。C 部分虽然难但至少能看到函数签名和注释。我调一个自定义损失函数的梯度问题时文档翻遍了没找到答案最后在源码里发现它对某个边界条件做了特殊处理文档根本没提。所以源码是最终的真相文档只是参考。7. 写在最后框架是工具问题才是核心聊了这么多框架的演化、环境的坑、部署的坑我想回到开头那句话。搞深度学习框架的人不是疯子也不是骗子他们是在一个极度复杂的约束空间里找解。每一个看起来奇怪的设计决策背后都有它的权衡。作为使用者理解这些权衡能让你在踩坑时少一点愤怒多一点“原来如此”的释然。我自己的体会是别把太多精力花在追框架的新特性上。框架会变API 会变但深度学习的核心问题——怎么表示数据、怎么设计模型、怎么优化参数、怎么部署落地——这些是不变的。把这些问题想清楚用什么框架都能干活。反过来如果只会调 API框架一升级你就废了。最后分享一个我常用的排查思路遇到框架相关的问题先问三个问题——是环境问题还是代码问题是版本不匹配还是用法不对是框架的 bug 还是我理解错了这三个问题能帮你快速缩小范围别一上来就怀疑框架有 bug大多数时候是我们自己没搞懂它的设计逻辑。