2024年新来的实习生看到我电脑上的IDE里装了一整套TensorFlow环境脱口而出“现在还有人用这个吗”我当时没急着反驳因为这半年里我已经听过太多次类似的质疑。但实际情况是我手头的三个生产项目两个的推理后端都在用TensorFlow Serving一个移动端识别功能用的是TFLite。TensorFlow在我的工作流里一直没有退场反倒是在部署环节越来越顺手。如果你也正在纠结“2024年还能不能学TensorFlow”“怎么装才不踩坑”“和PyTorch到底怎么选”这篇内容可以给你一份比较实在的参考。我没有打算把两个框架比出个你死我活。现实中做工程的人都知道武器库多一件趁手的家伙远比站队重要。下面这些话都是我实际装环境、训练模型、部署服务时攒下来的经验不是从官方文档里抄出来的漂亮话。1. 2024年的TensorFlow被唱衰但从未退场的框架1.1 为什么唱衰的声音那么多原因很简单PyTorch在学术界和AI创业圈里的声音太大了。从论文复现、开源项目到Kaggle比赛PyTorch的代码几乎成了默认语言。新手一查资料十个教程里有八个是PyTorch写的自然就会觉得TensorFlow已经不行了。加上TensorFlow 1.x时代那个“图优先”的糟糕体验留下了一大批怨念很深的开发者舆论上相当吃亏。但舆论和现实经常不是一回事。TensorFlow在工业界的真实渗透率远远被大众低估了。很多金融机构、制造业工厂、自动驾驶公司和安卓生态的团队线上跑的模型推理服务就是TensorFlow SavedModel或者TFLite。决策者不太关心你用哪个框架写模型他们只关心能不能稳定上线、能不能方便扩容、能不能塞进手机。这几个问题上TensorFlow的老本行恰恰就是工程化和部署。1.2 两个框架的定位差异我给一个非常直接的比喻PyTorch像一台适合改装的手动挡性能车灵活、直接、想改哪里改哪里适合你跑通思路和做前沿研究TensorFlow像一台出厂配置完整的自动挡工程车规矩多、手感重一些但开到工地上拉货的时候你基本不用操心它会不会中途撂挑子。学术圈更重视灵活调试PyTorch的动态图机制用起来确实舒服print任意张量、到处打断点理解起来毫无障碍。工业界更重视稳定复现和部署链路TensorFlow的SavedModel标准格式、TF Serving、TFLite和TF.js把从训练到上线的路径搭得非常完整。TensorFlow 2.x之后已经彻底拥抱了动态图Keras成了标准前端学习门槛比1.x时代低了不止一个量级。很多人对TensorFlow的印象还停留在tf.Session和placeholder那个年代这是最典型的认知滞后。2. TensorFlow安装的版本矩阵与踩坑实录安装TensorFlow是无数新手的第一道坎而且这道坎很奇怪——明明照着教程敲命令却总有人会死在 import tensorflow 这一步。这一节我把决策路径和坑位都摆出来。2.1 装机前的决策CPU版本还是GPU版本不要一上来就装GPU版。如果你的机器没有NVIDIA显卡或者你不确定CUDA环境能不能配好先装CPU版跑通流程一点不丢人。CPU版做MNIST、做文本分类、做小规模图像实验完全够了。我见过太多人为了配GPU环境折腾两天结果显卡驱动和CUDA版本对不上最后连入门代码都没跑起来直接劝退。安装命令其实非常简单核心就一行pip install tensorflow-cpu有NVIDIA显卡、显存不低于4GB、想认真训练模型的再考虑装GPU版pip install tensorflow注意pip install tensorflow在2.11之后的默认发行版对应的就是GPU支持的版本Linux下。Windows那边情况特殊我在2.3节仔细说。2.2 虚拟环境与pip镜像源无论你是新手还是老鸟我都不建议把TensorFlow直接装进系统全局的Python环境里。TensorFlow对依赖版本极其敏感protobuf、numpy、absl-py这些库稍微动一个版本就可能冒出一堆莫名其妙的报错。用虚拟环境隔离是最稳妥的。我常用的组合是Anaconda或者Minicondaconda create -n tf python3.11 conda activate tf pip install tensorflow-cpu如果你在国内大概率会遇到pip下载慢到怀疑人生的状况。解决方式很简单指定镜像源不需要搞任何复杂的网络配置pip install tensorflow-cpu -i https://pypi.tuna.tsinghua.edu.cn/simple提示pip默认源慢的时候换成清华源或者阿里源都能明显提速。千万别去折腾系统代理那个方向不仅麻烦而且容易在团队协作时留下一堆别人看不懂的配置文件。2.3 Windows用户最容易被坑的点原生GPU支持止步于2.10这里有一个特别重要、但官方文档里不显眼的历史事实TensorFlow 2.10是最后一个支持Windows原生GPU的版本。从2.11开始Windows用户想在GPU上跑TensorFlow必须通过WSL2或者Linux容器。也就是说如果你用Windows NVIDIA显卡直接执行pip install tensorflow最新版然后运行GPU检查代码大概率会提示“找不到GPU”。这不是你装错了是官方策略变了。NVIDIA和微软在合作推动WSL2的GPU直通方案Windows原生CUDA支持被TensorFlow放下了。折中方案有三个在Windows里用WSL2在Ubuntu环境下安装TensorFlow GPU版利用WSL的GPU直通跑训练把原生版本固定在2.10pip install tensorflow2.10.0同时安装对应的CUDA 11.2和cuDNN 8.1改用Docker镜像官方镜像tensorflow/tensorflow:latest-gpu-jupyter把CUDA和cuDNN都准备好了省心程度最高。我自己现在更多是第三种方案。Docker的好处不只是省心换项目时环境隔离更彻底部署到服务器上也一样。2.4 安装后的验证与常见崩溃处理装完别急着写训练代码先跑一个最简验证import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices())第二行会列出当前可用的计算设备。如果你装的是CPU版应该能看到CPU设备如果你装的是GPU版并且环境没问题这里会多出GPU设备列表。如果GPU列表是空的先检查驱动和CUDA版本再用tf.config.list_physical_devices(GPU)单独看GPU有没有被识别。新手最常见的几个崩溃我直接列出对应的处理方式Could not load dynamic library cudart64_XX.dllCUDA动态库缺失。确认已装CUDA和cuDNN并且把路径加进系统的环境变量。ImportError: DLL load failed while importing _pywrap_tensorflow_internal通常发生在Windows的CUDA/cuDNN版本不匹配时。优先检查TensorFlow版本对应的CUDA版本表。protobuf运行时警告把protobuf降级到3.20.x左右很多历史版本的TensorFlow只和旧protobuf兼容。内存不足导致OOM不要无限加大batch size。如果显卡显存是6GBbatch size从16开始试不要一上来就64。这些小问题看起来多实际处理过一次之后就会形成肌肉记忆。环境这关过了TensorFlow的学习才算真正开始。3. 从数据管道到模型训练一个能跑起来的Keras流程很多教程喜欢直接给一个model.fit然后把训练结果贴出来看起来很简单。但你一旦换成自己的数据立刻会发现卡在数据读取和预处理上。这一节我以图像分类为例说说一条完整、可复用的训练链路。3.1 tf.data让数据读取不再是瓶颈自己写循环读图片、做归一化、分批喂给模型在小数据集上没问题但数据量一上去就会变成灾难。几十万张图片一张一张读进内存训练过程绝大多数时间都耗在磁盘IO上。TensorFlow提供了一套完整的数据管道方案核心就是tf.data.Dataset。它把数据读取、变换、混洗、预取和批次组织都串成管线简洁到几乎可以“照着抄”train_ds tf.keras.preprocessing.image_dataset_from_directory( data/train, image_size(224, 224), batch_size32, label_modecategorical ) train_ds train_ds.prefetch(tf.data.AUTOTUNE)prefetch(tf.data.AUTOTUNE)这行非常关键。它让数据预处理和模型训练在时间上重叠GPU/CPU在计算的同时后台已经在准备下一批数据避免训练过程频繁停下来等数据。如果你需要更细粒度的控制可以用函数式写法def process_image(path, label): img tf.io.read_file(path) img tf.image.decode_jpeg(img, channels3) img tf.image.resize(img, [224, 224]) img tf.cast(img, tf.float32) / 255.0 return img, label dataset tf.data.Dataset.from_tensor_slices((image_paths, labels)) dataset dataset.map(process_image, num_parallel_callstf.data.AUTOTUNE) dataset dataset.shuffle(1000).batch(32).prefetch(tf.data.AUTOTUNE)map阶段支持并行处理多个文件AUTOTUNE让TensorFlow自己决定并行线程数。数据吞吐量提升是肉眼可见的。3.2 用Keras函数式API搭一个图像分类模型Keras提供三种建模方式Sequential、函数式API、继承Model类自定义。我喜欢用函数式API因为它在灵活性和简洁性之间平衡得最好。同样是搭一个简单的卷积分类模型inputs tf.keras.Input(shape(224, 224, 3)) x tf.keras.layers.Rescaling(1./255)(inputs) x tf.keras.layers.Conv2D(32, 3, activationrelu)(x) x tf.keras.layers.MaxPooling2D()(x) x tf.keras.layers.Conv2D(64, 3, activationrelu)(x) x tf.keras.layers.MaxPooling2D()(x) x tf.keras.layers.Flatten()(x) x tf.keras.layers.Dense(128, activationrelu)(x) outputs tf.keras.layers.Dense(10, activationsoftmax)(x) model tf.keras.Model(inputsinputs, outputsoutputs) model.compile( optimizeradam, losscategorical_crossentropy, metrics[accuracy] )Rescaling这层直接放在模型里而不是在数据管道里单独做归一化这样导出模型之后线上推理时外部输入只需要原图预处理逻辑被模型自己包住了。这个习惯在做部署时会让你少踩很多坑。编译模型时loss、optimizer这些参数不要盲目复制。分类问题用分类交叉熵、回归问题用MSE、二分类用binary crossentropy这些基础概念值得花半小时弄明白能省下面调试时好几天的迷茫。3.3 训练与调参中的几个实用细节训练代码本身不长model.fit( train_ds, validation_dataval_ds, epochs30, callbacks[ tf.keras.callbacks.EarlyStopping(patience5, restore_best_weightsTrue), tf.keras.callbacks.ModelCheckpoint(model/best_model.h5, save_best_onlyTrue) ] )但有几个细节新手很容易忽略EarlyStopping要配restore_best_weights。不配这个参数训练结束后模型权重是最后一步的不是验证集最优的等于白早停。ModelCheckpoint存成SavedModel格式更好。默认存.h5也能用但我建议显式指定保存为TF原生格式后面部署能省心tf.keras.callbacks.ModelCheckpoint( model/best_model, save_best_onlyTrue, save_formattf )Learning Rate不要总用默认值。Adam默认学习率0.001在大多数场景起步没问题但如果你看到loss在某个数值附近震荡不收敛试试把学习率降到0.0001再继续训练。神经网络训练的很多“玄学”最后都发现是学习率的问题。GPU显存不足时先降batch size不是降图片尺寸。之前我为了凑batch size硬把224的图缩到128准确率掉了将近6个百分点后来才反应过来是显存不够不是模型“不爱学习”。训练完成后记得保存模型。除权重外自定义层和预处理逻辑也要一起保存否则换环境加载时处处报错。4. 部署是TensorFlow的强项TF Serving与TFLite的落地路径训练只是TensorFlow故事的一半。真正让它在工业界立住脚的是把模型变成线上服务、变成手机App里的推理能力。这一节我重点讲两条常见的部署路径。4.1 SavedModel训练与部署的统一格式TensorFlow模型的标准交付格式叫SavedModel。它把网络结构、权重、预处理、签名函数都打包在一个目录里结构大致长这样models/ └── 1/ ├── saved_model.pb └── variables/ ├── variables.data-00000-of-00001 └── variables.index保存方式超级简单model.export(models/1) # 新版Keras推荐models/1这个目录命名方式对应的是版本号。TensorFlow Serving会读取这个版本信息做版本管理和平滑切换。这就是为什么目录里有个1而不是随便一个文件名。加载验证也简单import tensorflow as tf loaded tf.saved_model.load(models/1)4.2 TF Serving做推理服务TF Serving是TensorFlow官方的高性能推理服务组件。它直接吃SavedModel目录对外提供gRPC和HTTP接口生产环境里常见的需求——多模型管理、模型热更新、请求批处理——它都内置了。用Docker启动一个TF Serving是最省心的方式docker pull tensorflow/serving docker run -p 8501:8501 \ --mount typebind,source$(pwd)/models,target/models \ -e MODEL_NAMEyour_model_name \ -t tensorflow/serving启动之后用HTTP请求就可以了curl -X POST http://localhost:8501/v1/models/your_model_name:predict \ -H Content-Type: application/json \ -d {instances: [{input_tensor: [1.0, 2.0, ...]}]}注意body里的字段名要和模型导出时的输入签名一致。如果报“无法匹配签名”先加载SavedModel查看签名loaded tf.saved_model.load(models/1) print(loaded.signatures)TF Serving对并发和吞吐的处理能力相当成熟我自己在云服务器上只分配2核CPU压测下来每秒处理几百个请求一点问题没有。注意如果只是做一个内部的简易推理接口不一定非要上TF Serving。直接用Keras加载模型配一个Flask接口也能跑。但一旦你有灰度发布、多版本切换、高并发这类需求TF Serving会省掉你手写一堆服务治理逻辑的时间。4.3 TFLite把模型塞进移动端移动端和嵌入式设备是TensorFlow的另一大阵地。TFLite模型在安卓、iOS、树莓派、微控制器上都能跑。转换过程通常分两步。先确保你手上的模型能导出为TFLite格式import tensorflow as tf converter tf.lite.TFLiteConverter.from_saved_model(models/1) converter.optimizations [tf.lite.Optimize.DEFAULT] tflite_model converter.convert() with open(model.tflite, wb) as f: f.write(tflite_model)optimizations里的DEFAULT选项会做权重压缩模型体积通常可以缩小到原来的四分之一左右。代价是精度会有一点点下降但这个代价在移动端场景下非常划算。转换之后在安卓端可以通过TensorFlow Lite Task Library直接调用。常见的图像分类任务甚至不需要你写复杂的Java/Kotlin解析代码官方库已经封装好了Input/Output的处理逻辑。如果你做的是目标检测TFLite同样有现成的API几个类就能跑完。坦白说PyTorch也有对应的移动端方案但生态的成熟度、文档数量和踩坑资料的丰富程度跟TFLite不在一个量级上。这也是很多移动端团队最后仍然选择TensorFlow的原因。5. TensorFlow与PyTorch的2024年流行趋势数据说了什么5.1 学术研究与工业部署的“跷跷板”先看事实。PyTorch在论文发表、预训练模型权重、开源算法库上占据明显优势。HuggingFace生态和PyTorch深度绑定导致你随便看一个最新的NLP或视觉模型开源代码大概率是PyTorch写的。这个趋势2024年没有任何反转而且看起来会继续加强。但这不等于TensorFlow就输了。工业部署侧的很多调研仍然显示TensorFlow在生产环境中占据大量份额。原因我刚才也说了TF Serving、TFLite、TF.js以及Keras这层高级API让整个工程链路太成熟了。银行、自动驾驶、制造业、智能终端这类对稳定性和长时间运行要求极高的场景选择的逻辑很朴素不追求最新最潮只要求稳妥可控。所以这个趋势本质上是一个“跷跷板”学术研究和快速迭代的天平往PyTorch倾斜工业落地和长期维护的天平往TensorFlow倾斜。两边其实不在同一个赛道上硬碰硬。5.2 2024年开源社区的几个明显信号这一年有几个值得注意的信号Keras 3.0发布把后端做到了多框架支持。同一个Keras代码可以跑在TensorFlow、PyTorch和JAX上。这意味着Keras这个前端正在成为跨框架的标准层TensorFlow和PyTorch的边界反而在淡化。TensorFlow的2.x系列迭代节奏明显放缓官方把更多精力放在稳定性和性能上而不是疯狂加新功能。这对生产环境是好事对追求新鲜感的社区则缺乏吸引力。AI应用爆发之后大量新入场的传统软件团队更关心“模型怎么上线”而不是“模型怎么写”。这类需求大量涌向TensorFlow的部署方案。PyTorch的torch.compile和性能优化不断推进但部署侧的TorchServe生态依然比TF Serving弱一些尤其在高性能推理、批处理和版本热切换这些细节上工程化差距是短期填不平的。整体给我的感觉是2024年你要是问“哪个框架人气高”答案是PyTorch你要是问“哪个框架能让我最快把模型送到生产环境”TensorFlow依然是那个非常扎实的答案。5.3 我的选型建议别被舆论带着跑我在实际工作中是两套都用的实验和写原型用PyTorch方便复现论文、快速迭代做产品化交付时条件允许我会把模型迁到TensorFlow或者至少导出为SavedModel格式然后用TF Serving或TFLite上线。这个迁移并没有大家想象中那么痛苦。现在Keras可以加载PyTorch参数严格说不是直接加载但借助ONNX或者对模型结构等价地重建一遍再导入权重操作起来很成熟。加上Keras 3.0的多后端支持以后这种跨框架迁移的摩擦会更小。对于刚入门的朋友我的建议更简单想做科研、发论文、追最新模型学PyTorch因为开源社区资源最丰富复现代码容易。想找工作、做业务系统、搞模型上线至少把TensorFlow的Keras训练、SavedModel导出、TF Serving或TFLite部署链路摸熟这是很实际的竞争力。两个都想学好先用少的精力把TensorFlow的流程打通尤其部署部分再用PyTorch去复现开源模型。两个框架的底层概念高度相通真正学会第二个要花的时间远比你想象得少。6. 最后聊几句真心话如果你读完上面这些还是没决定先学哪个那我给你一个特别务实的答案找一台电脑装CPU版TensorFlow跑通一个手写数字识别再把模型导成SavedModel启动一个TF Serving容器用curl请求一次推理。这套流程全部走完你对深度学习从训练到部署的全貌就有了真实的体感然后你再回去看PyTorch教程理解速度会快非常多。我个人在实际项目里最舒服的一个组合是PyTorch承担研究和快速验证TensorFlow承担生产部署实验阶段灵活一点上线阶段求稳。按这个思路你不需要在框架之间做“二选一”的宗教式站队。框架终究不是目标解决实际问题才是。TensorFlow从1.x时代的繁琐一路走到今天确实有它的历史包袱但它在工程化这条路上积累下来的东西至今仍然是它最硬的底气。如果你愿意给它一次机会从Keras入手而不是被老旧的教程劝退你会发现它比舆论描述的强太多了。