最近在技术社区经常看到同一个问题被反复问起2024年了TensorFlow是不是已经没人用了是不是直接学PyTorch就完了恰好我自己前阵子重装了TensorFlow做部署相关的项目翻了翻安装文档、查了不少版本更新记录也顺手对比了一下两边的使用体验。结论可能和很多人的想象不太一样TensorFlow的热度确实被PyTorch压了一头但论生产部署、端侧落地、服务化方案它依然是绕不开的老牌重型武器而且TensorFlow安装的搜索量一直没降过说明每个季度都有一大批新人在尝试踏入这门框架的第一道门槛。这篇文章我不想重复官方文档里那些照抄可用的话术而是想从一个实际使用者的角度把2024年TensorFlow的真实处境、完整安装过程、新版API习惯的变化以及和PyTorch的选型对比串起来讲一遍。无论你是刚接触深度学习的新手还是想评估要不要从PyTorch迁移过来的老手应该都能在里头找到一点自己用得上的东西。1. 2024年的TensorFlow热度下降但远未过气1.1 热搜背后为什么还有这么多人搜tensorflow安装先说个我自己观察到的现象。TensorFlow这个关键词在技术类搜索榜里的热度确实不如几年前那么夸张了但注意看相关热搜词会发现一个细节tensorflow安装的搜索量一直居高不下。这其实是一个很典型的新手信号——真正长期使用某个框架的人不会天天搜安装教程反复搜安装的人意味着始终有初学者在涌入。这些新人从哪来一部分是高校课程。虽然近两年越来越多的课程换成了PyTorch但TensorFlow在早期的机器学习教材里扎根太深很多学校还在用经典教材配套的TF代码。另一部分来自工业界项目。很多企业的AI系统是在2018到2021年间搭起来的那些系统大概率跑的是TensorFlow模型新入职的工程师接手时第一件事就是把开发环境装起来。还有一部分是移动端和嵌入式方向的开发者TensorFlow Lite在端侧推理的存量部署依然可观。所以TensorFlow过气这个说法准确来说应该是TensorFlow在学术论文里的出场率过气而不是TensorFlow在真实项目里的份额过气。对于刚入门的人来说如果因为觉得它过气就完全跳过反而可能错过一批工作和项目机会。1.2 与PyTorch的流行趋势对比学术界和工业界的真实分布先看数字。从论文复现平台Papers with Code的统计来看PyTorch在CV、NLP等主流方向的论文复现代码中已经占据了压倒性优势GitHub上开源的模型代码十有七八是PyTorch版本。TensorFlow的论文代码占比确实在下降这是不争的事实。但换个场景看就不太一样了。在Stack Overflow的企业标签问题、云计算市场相关的部署排查、以及各大厂商的MLOps实践中TensorFlow的出现频率依然很高。原因在于学术界写模型和工业界跑模型是两码事学术界要快速改动模型结构验证想法PyTorch的定义即运行风格确实舒服。工业界要考虑模型的版本管理、在线服务的延迟和吞吐、AB测试链路以及模型上线后的监控和回滚。TensorFlow的SavedModel格式和TensorFlow Serving在服务化这条链路上已经沉淀了非常久周边配套比如模型仓库、批处理、GPU调度也都磨合得很成熟。所以2024年更准确的说法是如果你想快速验证想法、参与前沿论文复现、用主流开源模型二次开发PyTorch更顺手如果你想把模型稳定地跑在生产环境里或者在做移动端嵌入式设备上的推理TensorFlow生态依然是第一梯队的选择。2. 从零开始TensorFlow环境搭建的完整实操2.1 Python与虚拟环境第一步做对后面省心我建议无论是Windows、macOS还是Linux第一步都用conda建一个独立的Python环境。别嫌麻烦直接装在系统Python里——TensorFlow的依赖项protobuf、numpy、absl-py等版本要求很苛刻系统Python一旦混装过其他深度学习库分分钟给你上演依赖冲突。conda create -n tf python3.11 conda activate tfPython版本我选的是3.11。2024年TensorFlow官方对3.12的支持虽然已经有了但部分配套库可能还会有编译兼容的小毛病。对于追求稳妥的人来说3.10或者3.11是最合适的踩坑最少。环境创建好之后更新pip再安装TensorFlow。CPU版和GPU版现在不需要分开装了官方提供了一个带CUDA支持的安装方式这一点和早期版本的体验差别非常大下文拆开细说。pip install --upgrade pip pip install tensorflow安装完成后验证一下版本和可用设备import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices())能输出版本号且没有任何报错说明基础环境OK。CPU版默认情况下也能跑通几乎所有模型代码只不过训练速度会比较感人罢了。2.2 安装GPU版tensorflow[and-cuda]带来的变化TensorFlow以前最劝退的一点就是CUDA环境的配置你得先装NVIDIA驱动再装CUDA Toolkit再装cuDNN而且版本还得和TensorFlow精确匹配一旦对不上就报错报错信息还看不懂。2024年这个痛点已经有了实质性的改善。官方发布了一套整合好的安装方式在Linux系统下只要从PyPI安装对应的包它会自动把适配的CUDA和cuDNN依赖拉下来。# Linux NVIDIA GPU 新的整合安装方式 pip install tensorflow[and-cuda]装完之后不需要手动设置LD_LIBRARY_PATH也不需要去NVIDIA官网下载那一堆Toolkit文件。这种方式会把CUDA运行库装在Python环境的site-packages里面TensorFlow启动时会自动加载对普通用户来说基本是零配置。Windows用户稍微繁琐一点因为整合包方案在Windows上的支持不如Linux那么完善。Windows用户建议直接用官方提供的适用于Windows的TensorFlow 2.x版本然后手动安装对应版本的CUDA和cuDNN。这些年我踩过不少Windows环境下的坑最核心的一条经验是CUDA版本一定不要追新要按TensorFlow官方兼容表来选。比如TensorFlow 2.15到2.16之间的版本官方明确写的是CUDA 11.8或12.2你装个12.4可能就启动不了。验证GPU是否激活的标准姿势print(Num GPUs Available: , len(tf.config.list_physical_devices(GPU)))如果输出显示的GPU数量大于0说明TensorFlow已经能正确调用GPU。如果输出为空列表大概率是驱动版本不对或者整合安装的依赖没有加载成功。2.3 Docker方案适合不想折腾CUDA的人如果你连上面这些操作都嫌麻烦或者是想给团队提供一套统一的环境模板直接用Docker是最省心的思路。TensorFlow官方镜像本来就是给生产环境准备的各种依赖全部打包好了拉下来就能跑在Linux服务器上尤其合适。docker pull tensorflow/tensorflow:latest-gpu-jupyter docker run --gpus all -it --rm tensorflow/tensorflow:latest-gpu-jupyter我个人的习惯是在服务器上跑Docker镜像在本机开发机用conda环境。好处是本机改动代码迭代快服务器上只跑真正需要长时间训练的脚本两个环境互不污染。顺便说一句如果你在的公司有内部镜像源建议把常用镜像同步一份到内网里否则每次pull官方镜像都可能慢到怀疑人生。3. 装上之后先别急着炼丹新版TensorFlow的关键API变化3.1 用tf.keras而不是直接操作底层Layer很多从TensorFlow 1.x时代过来的老人一开始会习惯性地找placeholder和Session结果发现新版里这些东西统统没有了。如果你有这样的历史包袱请务必记住一句话2024年的TensorFlow核心API只有一个就是tf.keras。写模型的推荐姿势是用Sequential或者Functional API把网络结构搭出来再交给Model.fit去训练model tf.keras.Sequential([ tf.keras.layers.Input(shape(784,)), tf.keras.layers.Dense(128, activationrelu), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10, activationsoftmax) ]) model.compile( optimizeradam, losssparse_categorical_crossentropy, metrics[accuracy] ) model.fit(x_train, y_train, epochs5, batch_size32, validation_split0.2)这里要注意新版里tf.keras.layers.Input是必须要写的不要图省事直接用Dense作为第一层然后靠input_shape参数两种写法虽然都能跑但显式声明输入形状的代码后续更好维护尤其是在用Functional API拼接复杂模型的时候。还有一点fit函数里validation_split0.2虽然很方便但它会把每个epoch训练时最后20%的样本留出来做验证如果你的数据本身是按类别有序排列的这个随机划分就会失效验证指标会严重失真。遇到这种情况建议用tf.keras.utils.train_test_split先切好数据再把验证集单独传给validation_data。3.2 Eager Execution终于不用再理解计算图了TensorFlow 1.x时代最劝退的概念就是计算图。你需要先把所有操作定义成图中的节点然后创建一个Session去执行整个图。这种定义与执行分离的模式对于写惯普通Python代码的人来说极其不自然调试的时候更是想掀桌。从TensorFlow 2.0开始Eager Execution已经成为默认模式。什么意思呢你写一行tf.add(a, b)这一行执行完结果立刻就出来了跟写普通Python代码的体验没有任何区别a tf.constant([1, 2, 3]) b tf.constant([4, 5, 6]) print(a b) # tf.Tensor([5 7 9], shape(3,), dtypeint32)这对新手堪称拯救级的改动。但实际项目中完全没有计算图的纯Eager模式在性能上会吃亏尤其是大批量循环训练的时候Python和TensorFlow算子之间来回切换的开销非常明显。所以官方给的折中方案是tf.function装饰器在你写好的训练函数前面加一行tf.function让它在第一次调用时把代码编译成优化过的图之后的调用走图执行速度和手写计算图时代几乎一样甚至更快。tf.function def train_step(x_batch, y_batch): with tf.GradientTape() as tape: predictions model(x_batch, trainingTrue) loss loss_fn(y_batch, predictions) gradients tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(gradients, model.trainable_variables))这里GradientTape就是新版自动求梯度的核心机制在tape的上下文中记录所有操作然后调用tape.gradient一步求梯度。相比之下PyTorch是每个tensor自带grad属性、通过backward()计算梯度两种思路殊途同归但GradientTape的写法对循环内部的梯度累积更友好。3.3 tf.data数据处理管道的正确姿势模型代码写完之后数据加载往往才是真正的性能瓶颈。很多人第一次用TensorFlow的时候还是自己写一个for循环喂数据结果发现GPU利用率上不去训练总时间反而比数据预处理快还慢。这时候就该轮到tf.data出手了。tf.data.Dataset是吃数据管道的核心抽象最基础的用法是把numpy数组包成数据集dataset tf.data.Dataset.from_tensor_slices((x_train, y_train)) dataset dataset.shuffle(10000).batch(32).prefetch(tf.data.AUTOTUNE)这里三连方法的含义分别是shuffle(10000)设置一个容量为10000的缓冲区从里面随机取样打乱数据顺序。batch(32)把样本聚合成大小为32的批次。prefetch(tf.data.AUTOTUNE)让数据读取和模型训练流水线并行。GPU在跑当前批次的时候CPU提前把下一个批次读好这一步对训练速度的提升最明显。如果你要在数据管道里做自定义预处理比如图片数据做随机裁剪、翻转用map方法def augment(image, label): image tf.image.random_flip_left_right(image) image tf.image.random_crop(image, size[32, 32, 3]) return image, label dataset dataset.map(augment, num_parallel_callstf.data.AUTOTUNE)一个经常被忽视的坑是map里的函数会被TensorFlow尝试编译成图执行所以不要在里面写依赖外部Python变量的复杂逻辑尤其是不要去改全局变量或者执行I/O操作。一旦在tf.function环境下执行这些副作用要么被忽略要么直接报错。如果想要更灵活的自定义预处理逻辑可以考虑先把numpy数组处理成想要的形式再喂给from_tensor_slices。4. 实测对比TensorFlow与PyTorch在典型任务中的表现4.1 同样的模型两者的开发体验差异为了让对比有点说服力我拿一个经典的图像分类任务在两边各写了一遍差不多的模型。硬件环境是同一台机器、同一块GPU数据都是CIFAR-10。从开发手感上说两者的差距没有网络上说得那么悬殊但还是有一些细微差异。PyTorch的代码组织更灵活你可以用纯Python的类继承结构随意组织模型前向传播逻辑里甚至可以掺入循环、条件分支、外部调用调试的时候用普通的Python调试器就能单步跟踪变量变化。TensorFlow这边的tf.keras模型更偏向按规范写模型Sequential/Functional API提供了一套固定的组装逻辑想自定义前向传播逻辑要用Model子类写法上会多一层结构约束。好处是模型结构定义得清晰规范该有的配置都有上线部署时不容易出幺蛾子。一个不可回避的痛点是维度和shape的调试。PyTorch在forward里打印中间张量的shape很方便TensorFlow需要你把tf.print插进去或者用tf.debugging.set_log_device_placement这种相对冷门的开关整体调试手感确实逊色一点。4.2 部署与服务TensorFlow Serving确实是老本行说到部署TensorFlow的优势立刻体现出来了。PyTorch虽然也能通过TorchServe或者ONNX转到服务端推理但在工程链路的成熟度上还是差了半截。TensorFlow的标准部署路径是这样的训练完模型执行model.export或者tf.saved_model.save导出为SavedModel格式。把SavedModel放进TensorFlow Serving的模型仓库目录。TensorFlow Serving监听HTTP/gRPC接口客户端请求进来返回推理结果。docker run -t --rm -p 8501:8501 \ -v /path/to/models:/models \ -e MODEL_NAMEmy_model \ tensorflow/serving这个方案自带模型版本管理——你往模型目录里放进新版本文件夹Serving会自动识别并切换不需要重启服务灰度发布和回滚都变得非常简单。这一套东西在PyTorch生态里虽然也有对应的方案但配置复杂度和稳定性都还差一截。如果你做的是端侧推理TensorFlow Lite和TensorFlow.js的覆盖面也很广。Android、iOS、浏览器、树莓派、MCU都有对应的运行时模型转换工具TFLite Converter一步到位。在边缘设备和浏览器场景TensorFlow的可选方案可能是最多的。4.3 分布式训练内建方案与第三方方案的取舍分布式训练这一块TensorFlow既有内建方案也有和Kubernetes结合的第三方方案。TensorFlow自带的tf.distribute.MirroredStrategy可以在单机多卡上非常方便地同步训练strategy tf.distribute.MirroredStrategy() with strategy.scope(): model create_model() model.compile(optimizeradam, losssparse_categorical_crossentropy) model.fit(dataset, epochs5)MultiWorkerMirroredStrategy则负责多机多卡场景配合TF_CONFIG环境变量可以做到近乎透明的分布式训练。这种改很少的代码、框架帮你搞定通信和同步的思路在Keras和TensorFlow里设计得很熟练。PyTorch这边官方的分布式方案DistributedDataParallel也做得很好但需要你自己管理进程组初始化、分配GPU、处理多节点的网络通信协议侵入性更强。如果你团队里没有专门的分布式系统工程师第一次配置多机训练的时候大概率要磨掉几天时间。不过说实话2024年普通开发者在分布式训练上的最佳选择已经变成了直接用云厂商的托管训练服务把TensorFlow/PyTorch的脚本扔进去平台负责调度自己本地不再需要关心分布式细节。这时候框架自身的分布式能力反而不是核心考量因素了。5. 重装过程中踩过的坑与选型建议5.1 这次重装遇到的三个典型报错第一坑是版本选择的诱惑。我最初图新鲜想直接装最新版的TensorFlow结果发现最新版依赖的编译器版本、CUDA版本在现有的系统上不兼容折腾一圈又老老实实装回官方推荐的稳定版本。这一条给所有新人的建议都一样框架装稳定版不要追最新。第二坑是numpy版本冲突。TensorFlow对numpy的版本范围有限制如果你环境里之前装过最新版的numpy导入TensorFlow时可能会报类似module numpy has no attribute bool的错误。解决方法是把numpy降级到TensorFlow官方要求的版本范围内。但这种问题最好从源头避免也就是一开始就用独立的虚拟环境不要把系统Python环境弄得乱七八糟。第三坑是路径问题。Windows用户如果在项目路径里带了中文字符TensorFlow在某些操作下载模型权重时会解析路径失败。这个问题我见了不少新人踩到解决也简单项目路径全部用英文用户名如果是中文的把项目放在C盘根目录下的自定义英文文件夹里。5.2 什么场景下我仍然会选TensorFlow被问得最多的一个问题就是新项目选TensorFlow还是PyTorch。根据我的实际经验可以从这几个角度来判断如果项目要求模型以服务化方式上线比如要通过gRPC对外提供推理接口我会倾向TensorFlow。SavedModel TensorFlow Serving的组合几乎是最短路径的工业级部署方案模型热更新、多版本管理都现成的。如果团队已经有了一套TensorFlow技术栈包括数据管道、模型管理、监控告警没有必要为了赶潮流迁移到PyTorch。框架切换的成本远不止重写模型代码还包括团队学习成本、线上系统的稳定性风险。如果业务涉及大量移动端或者浏览器端的推理模型TensorFlow Lite和TensorFlow.js对端侧的支持非常完善。从训练到TFLite转换再到端侧运行全链路一条龙这是目前很多竞品难以全包的地方。5.3 什么场景我会转向PyTorch反过来说如果目标是快速复现一篇最新的论文、调整模型结构做各种实验那我肯定首选PyTorch。学术社区的主流生态就在那里模型权重、训练脚本、微调包几乎都是PyTorch版本的在TensorFlow里等代码移植是浪费时间。如果团队里大多数人都是资深PyTorch用户新项目也没有部署上的历史负担那PyTorch完全够用。部署环节通过TorchScript或者ONNX也没问题。另外生成式模型、大语言模型的微调社区PyTorch的统治力更强这些方向上硬选TensorFlow反而会给自己增加麻烦。我的个人判断是这两个框架在2024年并不是选A就全错的关系很多时候项目里两个框架共存。用PyTorch做研究和快速原型验证验证完用TensorFlow做生产化落地的团队不在少数。5.4 给新手的一个建议先挑一个深入进去别贪多最后对还没入门深度学习的朋友多说一句。框架本身只是工具真正有价值的是你对机器学习原理、模型结构、数据处理、部署运维的理解。TensorFlow和PyTorch在底层概念上完全可以互相迁移你会了TensorFlow的GradientTape再看PyTorch的backward就不会觉得陌生你会了PyTorch的Dataset和DataLoader再看tf.data的shuffle、batch、prefetch几乎是同样的思维模式。所以不要被网上的框架之争带偏挑一个你的课程资源或者工作环境更依赖的框架入手先把模型从训练到部署的完整链路跑通一次再尝试另一个框架会轻松很多。与其在两个框架之间反复横跳不如在一个框架里真正积累起走完整个项目周期的经验这个经验才是最值钱的换框架时也会跟着你一起走。我在实际使用中体会最深的一点是环境搭建和框架选型的纠结永远是暂时的真正让人成长的是你在上面跑了多少个实验、处理过多少批数据、解决过多少个玄学级别的报错。