前阵子有个朋友问我：2024年了，TensorFlow是不是已经没人用了？我当时愣了一下，因为这个问题背后其实藏着一堆误解。TensorFlow在2024年仍然是生产环境里最常出现的深度学习框架之一，尤其是那些跑在云端的、做推荐系统和CV模型的业务场景，TF Serving和标准化模型格式依然是硬需求。这篇文章不打算重复官方文档，而是从我自己的安装、调试、部署经验出发，聊聊TensorFlow到底还值不值得学，怎么装，以及和PyTorch的那点恩怨。

如果你正卡在“框架选择”和“环境搭建”的十字路口，希望这篇东西能帮你省下几个晚上的折腾时间。我会尽量把话说得直白，有些地方可能口语化，但都是实际跑过之后的心得。

1. 2024年再说TensorFlow，先聊三个扎心问题

1.1 TensorFlow真的“凉”了吗

如果你只看学术论文或者GitHub上的热门项目，很容易得出“PyTorch已经全面碾压TensorFlow”的结论。尤其在CV、NLP这些研究领域，新论文的官方实现大部分都是PyTorch版本，HuggingFace的Transformers库也把PyTorch当作一等公民。但“热门”和“生产环境里的存量”是两回事。

我前几年在一家做推荐系统的公司待过，线上跑的模型绝大部分还是TensorFlow。不是团队不想换，而是沉淀下来的数据管道、特征工程、模型版本管理和上线系统全都围绕TF生态构建，说换就换的成本高到没人敢拍板。这种感觉有点像编程语言里的Java——社区讨论热度可能不如新语言，但在关键业务系统里你总能见到它的身影。

所以我的看法是：TensorFlow在2024年并不是“凉了”，而是热度从研究圈转移到了工程圈。它更像一个“稳定且无聊”的选择，不那么性感，但能扛事。

1.2 谁在2024年还在用TensorFlow

从我的观察看，还在大规模使用TensorFlow的团队大致有这么几类：

• 互联网公司的搜广推业务。推荐、广告、搜索这类的排序模型，生产链路极其复杂，很多系统就是基于TensorFlow + TF Serving搭起来的。你换框架，等于把线上基础设施重写一遍。
• 端侧和移动端应用。TensorFlow Lite在手机、嵌入式设备上的工具链成熟度，目前依然是第一梯队。
• Google生态的深度用户。如果你在Google Cloud上训练模型，或者要利用TPU这种专用硬件，TensorFlow的适配度会更好。
• 老项目维护团队。很多2019年到2021年落地的系统，代码是TF 2.x写的，模型、脚本、部署流程都在，不可能因为流行趋势变了就推翻。

另外还有一个被低估的点：Keras。TensorFlow 2.x把Keras作为官方高级API之后，很多非研究型工程师其实是用Keras在写模型。它把层、优化器、训练循环这些概念封装得很舒服，比直接写底层算子舒服太多。这部分用户数量巨大，只是不怎么在论文区发声。

1.3 一个客观的技术视角：生态与场景

要判断一个框架值不值得用，不能只看训练模型那一小步。深度学习的完整链条是：数据处理、模型开发、训练调参、模型验证、部署上线、线上监控、版本更新。每个环节对应的工具链完全不同。

TensorFlow把这整套东西打包成了一套相当完整的体系：TFX处理数据管道，SavedModel统一模型格式，TensorFlow Serving做高并发推理，TensorFlow Lite负责端侧转换，TensorFlow JS还能把模型跑在浏览器里。这种“全家桶”的好处是各个组件之间的衔接顺畅，出了问题更容易查。

反观PyTorch，优势在模型研究和灵活调试，它的TorchScript、TorchServe、ONNX导出这些年也在不断补齐，但跟TF全家桶比还是少了一些“工业级”的感觉。2024年的真相是：两者都在互相学习，PyTorch在补部署能力，TensorFlow在补调试体验，差别没有网上吵的那么大。

所以如果你要问我“TensorFlow还是不是2024年的主流”，我会回答：在工业部署和端侧场景，它依然是主流之一；在学术研究和快速原型阶段，PyTorch更主流。这不是一个二选一的问题，而是一个按场景选工具的问题。

2. TensorFlow安装：从零跑通本地环境的完整记录

2.1 版本选择：别再盲装最新版

我自己第一次装TensorFlow的时候，直接pip install tensorflow，结果被一堆版本兼容问题折磨到怀疑人生。后来学乖了：先搞清楚自己的用途，再选版本。

如果你只是想在笔记本上跑跑MNIST，或者做课程作业，直接装CPU版就够了。不要一上来就追求GPU，因为GPU环境涉及的驱动、CUDA、cuDNN版本互相匹配问题，能把人逼疯。TensorFlow官方对CUDA版本有要求，装错了就报Could not load dynamic library之类的错。

目前2.x系列的稳定版，Python支持范围通常在3.9到3.11之间。我自己的习惯是选择次新版本，比如2.15或2.16，而不是无脑追最新。为什么？因为新版本发布初期往往会有一些兼容性问题，影响你快速上手。等社区把坑填得差不多了再升级，体验会平滑很多。

2.2 虚拟环境与Python版本搭配

不管你是用Miniconda还是venv，我都强烈建议给TensorFlow单独开一个虚拟环境。这不是洁癖，而是防止不同项目的依赖互相打架。比如你另一个项目需要numpy 1.x，而TF 2.16要求numpy 2.x，同时装就会导致一堆莫名其妙的错误。

我习惯用conda，因为它在管理Python版本上特别方便。创建环境的命令如下：

conda create -n tf python=3.10 conda activate tf

如果你不想装Anaconda，也可以用Python自带的venv：

python3 -m venv tf-env source tf-env/bin/activate

进了环境之后，先检查一下python版本，确保是3.9到3.11之间。这一步看似简单，却能帮你避开后面80%的依赖坑。

2.3 安装命令与国内镜像加速

TensorFlow的安装命令其实很简单，麻烦的是一些细节。最基础的安装：

pip install tensorflow

如果网络环境不是很好，比如访问官方PyPI特别慢，可以用清华镜像：

pip install tensorflow -i https://pypi.tuna.tsinghua.edu.cn/simple

如果你确定只需要CPU，可以装这个：

pip install tensorflow-cpu

它的体积更小，也不会去检测GPU库，省心。如果要用GPU训练，我建议先确认自己的NVIDIA驱动版本，然后参考官方文档安装对应的CUDA工具包。部分TensorFlow版本可以直接安装带CUDA依赖的包：

pip install tensorflow[and-cuda]

不过这个选项对网络要求比较高，按需选择。安装过程中如果遇到pip提示要升级依赖，先别急着同意，因为你正在用的依赖版本可能已经是TF要求的版本，盲目升级反而容易把环境弄坏。

2.4 验证安装的两种方式

安装完成后，别急着写模型，先跑一个最简单的验证命令：

python -c "import tensorflow as tf; print(tf.__version__)"

如果正常输出版本号，比如2.16.1，说明基本环境没问题。接着再验证一下GPU能不能被识别：

import tensorflow as tf print("GPU available:", tf.config.list_physical_devices('GPU'))

如果没有GPU，你会看到空的列表，这不算错误。如果你有GPU但列表是空的，常见原因是驱动、CUDA版本和TF版本不匹配。这时候我建议按这个顺序排查：先看NVIDIA驱动是否正常，然后看CUDA版本是否符合TF要求，最后看cuDNN是否安装。排查过程确实烦，但一旦跑通了一次，后面就会发现套路。

3. 上手TensorFlow的第一套工作流：从数据到部署

3.1 高维张量，先扔掉恐惧

很多新手听到“张量”两个字就觉得高深，其实它就是“多维数组”的官方说法。比如一个32x32像素的彩色图片，在TensorFlow里就是一个形状为(32, 32, 3)的张量，最后那个3是RGB通道。完全可以用生活化的方式理解：张量就是装了数字的盒子，几层嵌套就是几维张量。

在TensorFlow 2.x里，你不需要像老版本那样通过会话去执行计算图，默认就是动态模式，跟写NumPy差不多。看个例子：

import tensorflow as tf a = tf.constant([[1.0, 2.0], [3.0, 4.0]]) b = tf.constant([[2.0, 0.0], [1.0, 3.0]]) c = tf.matmul(a, b) print(c.numpy())

你创建两个张量，做矩阵乘法，直接得到结果。这种直观感非常友好，不要让背上的旧记忆吓到你。

3.2 用Keras快速搭一个分类模型

TensorFlow最舒服的部分，就是Keras这个高级API。我第一次用Keras搭手写数字识别模型时，大概只花了几分钟就跑到了98%以上的准确率。代码很简单：

import tensorflow as tf (x_train, y_train), (x_test, y_test) = tf.keras.datasets.mnist.load_data() x_train, x_test = x_train / 255.0, x_test / 255.0 model = tf.keras.models.Sequential([ tf.keras.layers.Flatten(input_shape=(28, 28)), tf.keras.layers.Dense(128, activation='relu'), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10, activation='softmax') ]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy', metrics=['accuracy']) model.fit(x_train, y_train, epochs=5, validation_split=0.1)

每个部分干什么，稍微解释一下：Flatten把28x28的图片拉平成784维向量，Dense是全连接层，Dropout是随机丢弃部分神经元防止过拟合，最后的softmax输出10个类别的概率。compile配置优化器、损失函数和评估指标，fit开始训练。

从这里你应该能感受到，Keras的设计哲学就是“把常见场景压缩到最简单”。如果你想做更复杂的自定义模型，也可以继承tf.keras.Model写子类，但前期真没必要。

3.3 数据管道与训练中的几个细节

跑通一个例子很简单，但要让训练过程高效，就得学会tf.data。我见过不少朋友直接用NumPy数组喂给model.fit，数据量小的时候没问题，数据一大就会卡到怀疑人生。

正确的做法是用tf.data.Dataset构建数据管道：

train_ds = tf.data.Dataset.from_tensor_slices((x_train, y_train)) train_ds = train_ds.shuffle(10000).batch(64).prefetch(1)

这里的shuffle打乱数据顺序，batch把数据打包成64个一批，prefetch会提前准备下一批数据，让GPU不至于等CPU读取。这个prefetch特别关键，它能让训练过程中的数据加载和计算重叠起来。

训练时还可以配合回调函数，比如早停和模型保存：

callbacks = [ tf.keras.callbacks.EarlyStopping(patience=2, restore_best_weights=True), tf.keras.callbacks.ModelCheckpoint('best_model.keras', save_best_only=True) ] model.fit(train_ds, epochs=20, callbacks=callbacks)

实际项目里，数据清洗和特征工程占的时间远超过模型搭建。框架只是你手里的工具，数据才是真正要好好打磨的东西。

3.4 导出与推理：模型不只是训练完就结束

训练完模型，如果只是放在.h5文件或者.keras文件里，那它还只是个半成品。我自己的理解是：模型只有部署到推理环境里，才算真正走完了工作流。

TensorFlow里最标准的部署单元是SavedModel格式。你可以在训练结束后这样导出：

model.export('saved_model/my_model')

导出的目录里会有saved_model.pb和variables文件夹，这就是一个完整的、可以交给服务端的模型包。如果你用TensorFlow Serving，还需要在目录外面套一层版本号，比如：

models/ my_model/ 1/ <-- SavedModel里的文件都放在这里

然后启动Serving容器：

docker pull tensorflow/serving docker run -p 8501:8501 \ --mount type=bind,source=$(pwd)/models/my_model,target=/models/my_model \ -e MODEL_NAME=my_model -t tensorflow/serving

用curl就可以请求接口了：

curl -d '{"instances": [[[...]]]}' -H "Content-Type: application/json" http://localhost:8501/v1/models/my_model:predict

第一次跑通这套流程，你会觉得“哦，原来上线一个模型没有想象中那么玄乎”。但这套标准流程才是TF在工业界的立身之本。

4. TensorFlow与PyTorch的2024年之争：别再纠结“谁更好”

4.1 从论文占比看趋势，但别只看占比

2024年如果你去查Paper with Code这类统计平台，会看到PyTorch在论文复现和代码实现的占比明显高于TensorFlow。这个数据当然有参考价值，它说明新研究更倾向于用PyTorch。

但论文占比不等于生产占比。举一个类比：很多人用Photoshop做创意设计，但企业里批量处理图片、做自动化流水线的，还是少不了一些脚本工具。研究要的是灵活和快速验证，生产要的是稳定和可运维。TensorFlow的流水线能力恰恰是经过大量业务验证的。

所以看到“PyTorch是趋势”这类文章时，我建议你追问一句：这个趋势是哪个领域、哪个层面的趋势？如果是学术圈，我认；如果是工业界，我会说没那么简单。

4.2 底层设计差异导致的体验差异

TensorFlow 2.x和PyTorch都已经支持动态图，编码风格也逐渐接近，但底层理念还是有差异。TensorFlow里有一个tf.function装饰器，可以把Python函数转换成计算图，从而在部署时获得更好的性能。PyTorch后来也有了torch.compile，但两者在XLA编译、图优化上的成熟度不同。

从写代码的体验说，PyTorch更“Pythonic”，调试时可以直接在Python堆栈里打断点，心理负担小。TensorFlow因为Keras封装的存在，写起来也很顺手，但一旦你用到tf.function或自定义训练循环，就会感觉到框架的“约束感”。

我整理了一个表格，方便你对比：

这表格不是要争高下，而是告诉你不同选型会有不同体验，取什么舍什么，得结合自己的场景。

4.3 什么时候选TensorFlow？什么时候选PyTorch？

我自己的判断标准比较简单，分享出来供你参考。

选TensorFlow的理由：项目里已经有TF老代码；团队需要交付一个完整的线上推理服务；要用TensorFlow Serving或TFLite做端侧和server端的统一部署；要被部署到Google Cloud或TPU环境。另外，如果你们主要做推荐、广告、搜索这类业务，TF的生态特别合适。

选PyTorch的理由：项目是研究原型或新实验室复现论文；团队里的人都习惯Python的调试方式；需要大量复用HuggingFace上的预训练模型；项目快速迭代，且部署环境是onnx等中间格式就能搞定的。

2024年还有一个现象：很多团队开始“双修”。用PyTorch做模型研究和训练，然后导出ONNX或TorchScript，再用TensorFlow Serving或ONNX Runtime做服务。这说明框架之间并不是只能非此即彼，它们已经越来越像彼此的可替换组件了。

4.4 框架迁移的成本与平滑过渡

如果你真的面临从PyTorch迁移到TensorFlow，或者反过来，我的建议是先别动框架，先动数据。模型结构可以重新搭一遍，但数据预处理、特征工程、评估指标这些才是真正的成本大头。很多时候你觉得是在“换框架”，其实是在“重做数据管道”。

一个相对平滑的过渡方案是：先用ONNX把模型导出，再用TensorFlow的ONNX转换工具导入。这个方法不是万能，但至少能让你先跑通。更保险的做法是，保留原有框架的模型文件作为备份，在新框架里逐步复现模型结构，每次只改一个小模块，对比输出差异。

我在实际项目中见过太多因为“别人说PyTorch好”就决定全面重写的团队，最后消耗巨大。技术选型最忌讳跟风，你要知道自己的系统里，到底是模型结构占大头，还是工程基建占大头。

5. 我踩过的TensorFlow坑与排查思路

5.1 import tensorflow就报错？先查这三件事

“好不容易装好了，结果import就失败了”是最高频的问题。我自己的排查顺序是三件事：

第一，Python版本和TensorFlow版本是否匹配。比如TF 2.16比较挑版本，太老的Python 3.7通常直接不支持。用python --version先确认。

第二，是不是装了不同来源的TensorFlow。比如你之前用过conda的某个渠道，然后又用pip装了另一个，二者混装会导致包损坏。建议在干净的虚拟环境里重新装。

第三，GPU相关动态库是否齐全。如果你有GPU，import时看到类似Could not load dynamic library 'libcudnn.so.8'的报错，就是CUDA或cuDNN没配对。解决办法是安装对应版本的CUDA toolkit，或者干脆卸载GPU依赖，先用CPU版把流程跑通。

我自己遇到过最气人的一次：因为装了非官方wheel包，导致import tensorflow直接Segmentation fault。后来我把所有相关包全部卸掉，只用官方PyPI源装，问题马上消失。所以遇到诡异问题，不妨“归零重来”，往往是最高效的解法。

5.2 GPU显存OOM的排查过程

训练某个模型时，刚跑了几个step就报ResourceExhaustedError: OOM when allocating tensor。我一开始以为是模型太大，后来发现是TensorFlow默认会在进程启动时就占用全部显存。

解决办法是启用显存动态增长：

import tensorflow as tf gpus = tf.config.list_physical_devices('GPU') if gpus: try: tf.config.experimental.set_memory_growth(gpus[0], True) except RuntimeError as e: print(e)

设置之后，TensorFlow只会分配需要的显存，不会一下子把显存吃满。这个设置最好在创建任何模型之前就生效，否则会报RuntimeError。

还有一个容易忽略的点：如果你用了tf.data和prefetch，在内存充足的机器上还好，但如果map函数里做了复杂的CPU计算，可能造成CPU瓶颈，导致GPU空闲等待、显存永不释放。这种时候用nvidia-smi看一眼显存占用和GPU利用率，如果利用率很低，大概率是CPU数据加载卡住了。

5.3 数据读入慢与tf.data的正确用法

有段时间我训练时发现每个epoch都要很长时间，起初怀疑是模型复杂，后来打印每一步的时间才发现，数据从磁盘读入的耗时占了大半。问题在于我用了笨办法，把整个数据集读进内存再切片，每次迭代还重新读取。

后来改成tf.data.Dataset，再加了一个cache()就能让预处理只跑一次：

ds = tf.data.Dataset.from_tensor_slices((x, y)) ds = ds.map(load_and_preprocess, num_parallel_calls=tf.data.AUTOTUNE) ds = ds.cache().shuffle(1024).batch(64).prefetch(tf.data.AUTOTUNE)

这里的num_parallel_calls让数据预处理并行执行，cache把结果缓存下来，prefetch预取。用上之后，训练速度肉眼可见地提升。记住，数据管道是训练系统里的第一道关卡，这个优化一定要做。

5.4 部署时tf.saved_model的坑

还有一次，我在部署模型时怎么都调不通，报错信息永远是在gRPC层，后来发现是模型目录结构不规范。TensorFlow Serving要求模型目录下必须有一个数字版本号子目录，比如/models/my_model/1/，Serving默认读取数字最大的版本目录作为当前版本。如果你把saved_model.pb直接放在my_model文件夹下，Serving就找不到模型。

另外，自定义模型的signature也很关键。默认model.export()会生成一个标准的serving_default签名，但如果你用的是自定义model.predict或转输出，可能需要手动指定签名：

tf.saved_model.save(model, 'saved_model/1', signatures={ 'serving_default': model.call })

这个细节不踩一次坑很难记住。部署不像训练，它要求你从“模型开发工程师”切换到“系统维护者”的视角，多考虑协议、目录、版本这类东西。

6. 2024年后的落地建议：TensorFlow该怎么学、怎么用

6.1 新人的学习路线

如果你是个深度学习新手，我建议别被框架争论带偏。先把少数核心概念搞明白：张量、模型、梯度、损失函数、训练循环。这些概念跟具体框架无关。

在TensorFlow这个体系里，学习路径可以这么走：

• 第一步，用Keras搭全连接网络跑通MNIST或Fashion MNIST。目的不是拿高分，而是熟悉model.compile和model.fit。
• 第二步，学习tf.data和数据预处理。换一个非MNIST的数据集，自己做归一化、分batch、cache和prefetch，感受数据管道对训练速度的影响。
• 第三步，学tf.function和SavedModel。把训练好的模型导出，再尝试用TensorFlow Serving加载。
• 第四步，如果有GPU，再折腾GPU环境。不要一开始就让CUDA劝退自己。

这个顺序的重要特点是：先把模型跑起来，再慢慢深入工程细节。很多人上来就研究底层分布式训练，结果连一个简单分类器的部署都做不好，反而失去了信心。

6.2 职场与项目中的真实建议

如果你希望把深度学习技能应用到工作中，我的建议是：把眼光从“哪个框架更酷”转移到“哪个框架能帮我解决问题”。招聘市场上，我看到的实际情况是：搜广推和后端机器学习平台相关的岗位，TensorFlow经验依然是加分项；而CV、NLP研究型岗位或需要快速复现论文的岗位，PyTorch经验更吃香。

如果你时间有限，我建议先扎实掌握TensorFlow的Keras和部署流程，再抽空学PyTorch的基础。因为TensorFlow让你学会“怎么把一个模型最终交付”，PyTorch让你学会“怎么快速验证一个想法”。前者是下限，后者是上限，两者互补。

当然，这只是基于我个人的经验，不是万能公式。具体怎么选，还要看你所在团队的技术栈和业务方向。

6.3 我的个人体会

接触TensorFlow这些年，我最大的感受是：框架本身不是最难的部分，难的是耐住性子把环境、数据、部署这些“脏活累活”都跑一遍。网上那些“XX已死，XX要赢”的声音，听听就好，别让它影响你的决策。

如果你现在还在为装不装TensorFlow而纠结，我的建议特别简单：先创建一个虚拟环境，pip install tensorflow，然后跑一个MNIST分类器。当你亲眼看到那块“loss: 0.02, accuracy: 0.99”的输出时，你自然就知道下一步该怎么走了。行动永远比争论更清楚。