企业官网建设流程全解析

最近接手了一个图像分类的线上接口，模型本身不复杂，反而在框架选型上折腾了小两周。不是模型难写，而是“到底用 TensorFlow 还是 PyTorch”这个问题背后牵着一串更实际的东西：环境怎么装、GPU 怎么认、训练脚本怎么组织、模型导出后往哪儿扔、手机端和 Web 端怎么办。每一步单独看都有答案，串起来之后，不同框架的差距才真正暴露出来。

这篇文章我把 TensorFlow 这一整条链路里自己实际走通的部分完整写一遍，重点放在 2024 年这个节点上：怎么装、怎么避开安装坑、怎么用 Keras 快速跑通一个模型、怎么从训练环境平滑过渡到线上服务。最后再聊聊和 PyTorch 的对比。刚入门的朋友可以从第二部分直接照着做，已经在用其他框架、想横向迁移的，后三部分更值得看。

1. 先给结论：TensorFlow和PyTorch，2024年该怎么选

1.1 两个框架的现状差异

先说流行趋势。如果只看 2024 年的学术论文、开源项目数量，PyTorch 在科研和原型验证阶段的势头依然很猛，这几乎是共识。动态图调试体验好、社区里新模型的复现代码多，做研究和快速试验的人自然会往那边靠。

但“研究框架”和“生产系统”是两个评价维度。TensorFlow 这些年花了很多力气在“从训练到部署的完整性”上：SavedModel 格式、TensorFlow Serving、TensorFlow Lite、TensorFlow.js，再加上对云原生环境里 K8s 部署的支持，这些都不是靠论文数量堆出来的，而是靠工程场景磨出来的。也正因为这样，你走进企业内部看存量系统，TensorFlow 的比例一点都不低。

有一个变化值得注意：2024 年发布的 Keras 3 已经可以在 TensorFlow、JAX、PyTorch 之上作为后端运行。也就是说，“选 TensorFlow 还是 PyTorch”这个问题的边界开始模糊——用 Keras 写出来的模型，后面挂哪个后端是可以在配置层面切换的。真正让你离不开某个框架的，反而是部署链路、性能优化工具这些“水面以下”的部分。

1.2 按场景选型，而不是按热度选型

我自己的做法是按场景拆：

我不建议用一个“xx已死”的结论去指导选型。更合理的问法是：我手头这个项目，从训练到上线最长的瓶颈在哪一步？如果你的项目大概率要走到“训练完成后在不同平台上部署”这一步，TensorFlow 这套链路确实省心；如果目前还停留在“快速验证某个想法”的阶段，PyTorch 的调试舒适度是实打实的。

1.3 大模型时代也没让 TensorFlow 失去位置

2024 年大模型相关的话题确实占据了大量注意力，这也让很多人产生“只有 PyTorch 生态才跟得上时代”的错觉。真实情况是，大模型研究和训练这块 PyTorch 生态确实更活跃，但大量真实业务里仍然是中小模型、结构化数据和常规视觉任务占大头。这些场景看重的是稳定、可维护、可监控，而这些恰恰是 TensorFlow 长期投入的方向。加上 Keras 3 的出现，TensorFlow 在通用建模上的入口反而更简单了，尤其是对做业务算法、需要频繁和产品端对接的团队。

2. 环境搭建与安装：从干净环境到GPU可用

2.1 先建干净环境，再谈安装

很多 TensorFlow 安装问题的根源不是命令记错了，而是环境太乱。系统 Python 里装了一堆包装包，pip 和 conda 混着用，Python 版本还五花八门。我现在的固定流程是先创建一个独立环境，再安装 TensorFlow，所有后续试验都在这个环境里做。

创建环境有两种常见方式：

# conda 方式 conda create -n tf python=3.11 -y conda activate tf # venv 方式 python -m venv tf_env source tf_env/bin/activate

从 2.16 之后的版本看，Python 3.9 到 3.12 之间基本都能正常使用。我个人推荐 3.11，兼容性和常见科学计算包的匹配度比较均衡。

激活环境后安装：

pip install --upgrade pip pip install tensorflow

就这么简单。这里要重点说一句：从 TensorFlow 2.x 中期开始，GPU 支持和 CPU 版本已经合并到同一个包，不用再费劲找tensorflow-gpu，也不需要在 pip 层面区分装哪个。

2.2 GPU 能不能用，关键看驱动和 runtime

安装完 TensorFlow 后，第一步不是急着跑训练，而是确认 GPU 有没有被正确识别。

import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices('GPU'))

如果能看到对应的 GPU 设备，说明驱动这层没问题。很多人在这里会踩一个逻辑误区：以为要手动安装 CUDA Toolkit 和 cuDNN。其实 TensorFlow 的预编译 wheel 包里已经内置了运行所需的 CUDA runtime 和 cuDNN 库，你真正需要保证的只是系统里的 NVIDIA 驱动够新，能兼容内置的 CUDA 版本。

用下面命令查看本机驱动支持的 CUDA 版本：

nvidia-smi

在输出右上角能看到CUDA Version。如果这个版本明显偏低，优先更新 NVIDIA 驱动，而不是手动往系统里塞一堆 CUDA 库，后者反而容易和 wheel 包产生冲突。这是我从“手动装 CUDA 失败到怀疑人生”到“先查驱动版本”的教训，能帮你省很多时间。

2.3 更省心的安装方式：直接用官方容器

如果是在 Linux 服务器上做开发和训练，我更推荐直接用官方 Docker 镜像：

docker pull tensorflow/tensorflow:latest-gpu

镜像里已经配好了和 wheel 包匹配的 CUDA、cuDNN，你只要满足 NVIDIA 容器运行时要求就行。换句话说，最难搞的 runtime 版本匹配问题直接被镜像固化掉了。“为什么有人装 TensorFlow 半小时，有人装三天？”多半就差在这里。容器方式的好处是独立、可复制、能随时清理，特别适合需要频繁切换项目环境的情况。

如果你所在网络从 PyPI 下载速度不理想，可以按自己习惯配置 pip 镜像源，不用改任何代码逻辑。

3. 装完后的排错清单：我踩过的那些坑

3.1 import 阶段最常见的两种报错

第一种是ModuleNotFoundError。听着像是缺包，但大多数时候是环境搞混了——你明明在 conda 环境里，结果 shell 里调用的还是系统 Python 的 pip。排查第一步永远是：

which python which pip

确认这两个命令指向同一个环境目录，再谈其他。

第二种是 NumPy 版本冲突。TensorFlow 对 NumPy 版本有兼容范围，如果环境里正好有一个过新或过旧的 NumPy，import 时可能报错，常见表现是“module compiled using NumPy，This may cause runtime errors”之类。解决办法不是乱降级，而是先看看 TensorFlow 当前要求的 NumPy 范围，然后在该范围内选一个稳定版本装回去。

3.2 GPU 识别不出来时的排查顺序

如果tf.config.list_physical_devices('GPU')返回空列表，别急着重装 TensorFlow。按这个顺序排查：

1. 先确认驱动层面是否正常，nvidia-smi是否能输出 GPU 信息。如果这里都看不到卡，TensorFlow 必然用不了。
2. 确认 TensorFlow 环境没装错：在 bash 命令行执行python -c "import tensorflow as tf; print(tf.__version__)"，确保输出正常。
3. 如果是 Windows 上使用 WSL2，注意当前 TensorFlow 对 WSL2 的 GPU 支持依赖 Windows 侧的驱动。只要 Windows 里显卡驱动保持更新，WSL2 内部通常能直接透传 GPU。
4. 看启动日志，TensorFlow 每次启动时会打印当前可见的设备列表。如果日志提示没有找到支持 CUDA 的运行时，那大概率还是驱动版本偏旧。

3.3 训练时显存不足，不一定是模型太大

OOM 是训练阶段更常见的错误。我看到很多新手一遇到 OOM 就立刻把 batch_size 调小，但实际多数情况是同时开多个训练进程，把显存占满了。

nvidia-smi

执行后看进程列表，确认是不是真的只有一个进程在占显存。如果存在残留训练进程，直接清理掉再继续。通常这个方法比盲目调小 batch 更有效。

另外，TensorFlow 默认会申请尽可能多的显存。如果机器上还要跑其他任务，可以在代码里设置显存按需增长：

gpus = tf.config.list_physical_devices('GPU') if gpus: tf.config.set_logical_device_configuration( gpus[0], [tf.config.LogicalDeviceConfiguration(memory_limit=4096)] )

这样限制到 4GB 以内，多个任务共卡时不至于互相影响。

4. 快速上手一个图像分类模型

4.1 从数据到训练，15分钟跑通

安装和排错之后，接下来真正进入写代码阶段。下面是 MNIST 手写数字识别的完整代码，从数据加载到训练结束都能跑通：

import tensorflow as tf from tensorflow import keras from tensorflow.keras import layers print("TensorFlow:", tf.__version__) # 1. 加载数据 (x_train, y_train), (x_test, y_test) = keras.datasets.mnist.load_data() # 2. 归一化并展平 x_train = x_train.astype("float32") / 255.0 x_test = x_test.astype("float32") / 255.0 x_train = x_train.reshape((x_train.shape[0], 784)) x_test = x_test.reshape((x_test.shape[0], 784)) # 3. 搭建模型 model = keras.Sequential([ layers.Input(shape=(784,)), layers.Dense(128, activation="relu"), layers.Dropout(0.2), layers.Dense(10, activation="softmax") ]) # 4. 编译 model.compile( optimizer="adam", loss="sparse_categorical_crossentropy", metrics=["accuracy"], ) # 5. 训练 history = model.fit( x_train, y_train, batch_size=32, epochs=5, validation_split=0.2, ) # 6. 测试 test_loss, test_acc = model.evaluate(x_test, y_test) print(f"测试准确率: {test_acc:.4f}")

这个脚本我在不少环境里跑过，第一次运行会自动下载 MNIST 数据集，后面就正常了。如果训练时发现 CPU 占用上升但 GPU 没动静，先检查第 2 步，大概率是数据成了瓶颈。

4.2 Keras 模型为什么要这么写

这里三个地方值得展开说。

一是Sequential适合线性堆叠的网络结构。遇到多输入、多输出、共享层的模型，就要换成 Functional API，但新手阶段从 Sequential 起步完全够用。

二是sparse_categorical_crossentropy是针对整数标签的损失函数。如果你的标签做了 one-hot 编码，需要换成categorical_crossentropy——这两者混用是常见的运行时报错来源。

三是Dropout层放在最后。它的作用是训练时随机丢弃部分神经元连接，降低过拟合风险。很多人忽略这个层，结果在测试集上准确率比训练集低一大截。

4.3 数据管道的正确姿势：用 tf.data

上面的例子把数据直接喂给model.fit，数据量小没问题，但生产环境数据集一大，直接丢内存会很难受。TensorFlow 更推荐用tf.data构造管道：

train_dataset = tf.data.Dataset.from_tensor_slices((x_train, y_train)) train_dataset = train_dataset.shuffle(10000).batch(32).prefetch(tf.data.AUTOTUNE) model.fit(train_dataset, epochs=5, validation_split=0.2)

这里最需要注意的是prefetch(tf.data.AUTOTUNE)，它让数据加载和模型训练在时间上重叠。通俗说，GPU 在算这一批数据时，CPU 已经在准备下一批了。少了这行，训练速度可能会明显下降，尤其是数据读取耗时较长时。

如果你打算在真实项目里用 TensorFlow，建议从一开始就养成写tf.data管道的习惯，而不是直接喂 NumPy 数组。两者在代码量上差别不大，但性能差距明显。

5. 从模型到线上服务：TensorFlow部署链路实战

5.1 导出模型：不要只保存权重

训练完成后，常见动作是用model.save()保存模型，但部署到线上时更规范的做法是导出 SavedModel 格式：

model.export("saved_model/my_model")

SavedModel 不只是权重文件，它内部还包含模型结构、优化器状态、以及用于推理的签名函数。TensorFlow Serving 可以直接加载这个目录，不需要额外的序列化脚本。用saved_model_cli可以查看模型暴露的签名：

saved_model_cli show --dir saved_model/my_model --all

这一步的价值在于：训练代码、推理代码和线上服务解耦，模型已经变成一个可以被标准工具加载的产物。这才是“模型即制品”的工程理念。

5.2 用 TensorFlow Serving 起一个 HTTP 接口

导出完成后，上线前的最后一步是把模型托管起来。TensorFlow Serving 是官方推理服务组件，支持 REST 和 gRPC。以 Docker 方式启动最简单：

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

启动后用 curl 发一个推理请求：

curl -X POST http://localhost:8501/v1/models/my_model:predict \ -H "Content-Type: application/json" \ -d '{"instances": [[0.0, 0.1, 0.2, 0.0, ...]]}'

返回结果里会包含predictions字段，这就是模型的预测输出。到这里，一个最基本的模型服务链路已经通了：训练环境导出 SavedModel，容器加载模型，HTTP 接口对外提供服务。

我实际调过的经验是：TensorFlow Serving 在生产环境里稳定性很好，模型更新时还能做版本管理，不用重启整个服务。这个能力对线上模型迭代很重要，比如你同时上线 v1 和 v2，它可以通过配置流量比例做灰度，而不是让运维去手动切换服务。

5.3 移动端和 Web 端：TFLite 和 TensorFlow.js

如果部署目标是手机 App 或浏览器，TensorFlow 生态的优势就更明显了。

移动端路径是把 SavedModel 转换成轻量级的.tflite文件：

converter = tf.lite.TFLiteConverter.from_saved_model("saved_model/my_model") tflite_model = converter.convert() with open("model.tflite", "wb") as f: f.write(tflite_model)

转换后的文件体积更小，推理代码可以用 TFLite Interpreter 直接加载，对 Android/iOS 都很友好。Web 端则可以用 TensorFlow.js 加载模型在浏览器里推理，适合需要客户本地处理数据的场景。

这里我提醒一下，如果你未来既要做服务端、又要做移动端、还可能要 Web 端，TensorFlow 的统一模型格式会减少大量重复适配工作。PyTorch 也能通过 ONNX 转换达到类似效果，但链路更长，排查问题也更绕。

5.4 部署时的版本问题

还是那个老问题：显卡驱动和 CUDA 版本。即使模型训练好了，线上服务环境也可能出现“本地好好的，容器里跑不起来”的尴尬。解决办法是服务环境尽量复用训练环境的镜像基础，至少保证 TensorFlow、CUDA、cuDNN 三者版本一致。容器化之所以重要，不只是因为它方便，而是它把环境差异这个最大的不稳定因素锁死了。

6. 我的选型复盘：什么任务我会优先用TensorFlow

聊了这么多，最后回到主题。如果手头项目符合下面几个特征，我个人会非常明确地倾向 TensorFlow：

第一，这个项目从第一天起就知道要上线，而且上线形态可能不止一种。比如既要跑在服务端、又要在 App 里做离线推理，TensorFlow 的 SavedModel+TFLite 链路最直接，中间不需要转换成其他中间格式再适配一遍。

第二，团队里有大量做业务算法的同学，模型迭代速度快。Keras 的高层 API 对这些人非常友好，几行代码就能复现基线模型，配合 TensorBoard 看训练过程也更直观。

第三，模型服务需要稳定的监控、版本管理、灰度能力。TensorFlow Serving 在这方面的成熟程度我试过很多次，稳定性和文档都已经经过了大量生产环境验证。

但反过来，如果你的场景是研究、快速写论文、搭建一个实验原型，我也不会强行推 TensorFlow。这个领域没有“最好”，只有“适合”，选型的核心永远是看你要走完的链路里，哪个框架能让你在最短时间内到达终点而不用处理额外的不确定性。

我个人在实际操作中的体会是：2024 年还在纠结“学哪个框架”是浪费时间，更合理的做法是把 Keras 3 作为通用接口来学，底层选择交给部署需求。这样你既不浪费 TensorFlow 在部署侧的成熟能力，也保留未来切换到其他后端的空间。真正的产出永远是解决问题的模型和服务，而不是某个框架的名字。