企业官网建设流程全解析

框架之争已经持续了好多年，但真正要回答的问题从来不是“PyTorch 和 TensorFlow 哪个更好”，而是“你当前的任务更适合哪一套工作流”。很多人在简历里写“熟悉 PyTorch 和 TensorFlow”，但面试官追问一句“它们的自动微分机制有什么不同”就卡住了；也有人学完一个框架的教程，换到另一个环境后连张量怎么创建都要重新查。这两个框架虽然名字不同、API 不同，但核心构成其实高度一致：张量系统、自动微分、模型表示、执行模式、序列化与部署接口。真正让你竞争力变强的不是背会 20 个 API，而是理解这些构成组件之间的设计取舍，再亲手把一个模型从训练跑到部署链路的最小闭环跑通。

这篇文章会把 PyTorch 和 TensorFlow 放在一起拆开讲：先看底层架构为什么从“静态图 vs 动态图”变成“全部动态优先”，再做同一个模型的实战演示，然后讲清楚安装环境里最常见的坑和排查顺序，最后给出一条可以复用的选型判断路径。整体有一个主判断：这两大框架正在快速收敛，学习时不用二选一，但简历和项目里一定要有主次。

1. 为什么这场框架之争和很多人想象的不一样

1.1 两套框架在底层逻辑上已经收敛到一个方向

早期 TensorFlow 的经典印象是静态计算图：先定义好整个网络结构，再启动会话执行；PyTorch 的经典印象是动态计算图：每一行代码都在构建计算关系，调试体验接近普通 Python 程序。这种“静态 vs 动态”的对立，在 2017 到 2019 年之间是选型的主要矛盾。

但今天再看，这个对立已经基本消失了。TensorFlow 在 2.x 版本默认开启了 Eager 模式，写起来是命令式风格，一行一行运行张量操作；PyTorch 也通过 torch.compile、TorchScript、导出等机制，可以把自己的动态模型编译成更利于部署和性能优化的静态图。两边都在向同一个方向靠拢：开发阶段要动态、要直观、要能 print 中间结果；生产和部署阶段要静态化、要可优化、要能脱离 Python 环境运行。

所以如果你还在纠结“学动态图还是静态图”，其实是在用上一代的问题做今天的决策。真正的核心差异已经不是动态和静态，而是生态惯性和工具链偏好：PyTorch 在研究社区、Paper 代码复现、Transformer 系列模型中占据明显的默认位置；TensorFlow 则凭借 Keras 的高层 API、TensorFlow Serving、TF Lite、TF.js 等组件，在工程部署和端侧场景里有完整的链路。这里的关键不是某个功能谁有谁没有，而是你想长期混迹的圈子默认使用哪套工具。

1.2 判断框架能力的四个真实维度

很多新手对比框架时会陷入“看函数数量”或“看教程热度”的误区。实际判断一个深度学习框架，要从四个维度看：

• 张量系统：是否支持 GPU/TPU 加速、设备间数据迁移、梯度自动记录。
• 自动微分：能不能不手写反向传播，梯度是否好调试，计算图能否被修改和可视化。
• 模型表示：定义网络结构的方式是偏底层可控制，还是偏高层开箱即用。
• 序列化与部署：训练好的模型能否方便地保存、加载、转换格式、上线服务或移植到移动端。

这四个维度只要理解透了，换框架的成本会大幅度下降。因为 PyTorch 里的torch.nn.Module和 TensorFlow 里的tf.keras.Model虽然 API 不同，但它们承担的职责是等价的：都是把网络层、参数、前向计算封装到一个对象里。你理解了这个抽象，就理解了框架之间的翻译逻辑。

1.3 2024 年前后的流行趋势：研究默认 PyTorch，生产环境越来越混合

近年几个明显的趋势变化值得注意。一方面，学术论文、开源模型权重、顶会复现代码大多以 PyTorch 为第一发布语言；Hugging Face Transformers 对 PyTorch 的支持也一直是主力。这意味着如果你做 NLP、视觉模型微调、Transformer 相关实验，PyTorch 几乎是绕不开的默认工具。另一方面，TensorFlow 并没有消失，它在传统企业级机器学习平台、端侧推理场景、以及与 Google Cloud 的整合上仍然存在。对于做 Web 端或移动端 AI 功能的人来说，TensorFlow.js 和 TF Lite 依然是成熟选项。

更常见的实际局面是混合使用：研究团队用 PyTorch 训练，需要上线时切换为 ONNX、TensorRT 或 TF Serving 部署；也有人用 TensorFlow/Keras 快速实现行业方案，再通过模型转换把权重迁移到其他推理引擎。所以 2024 年后的框架选择已经不再是单相思，你要学会的是理解语言边界和转换格式。

2. 核心架构对比：先看懂底层设计，再谈选择

2.1 张量系统：torch.Tensor 与 tf.Tensor

两个框架的核心数据结构在概念上没有本质差异，都表示多维数组，都支持 GPU 上的异构计算。但有几个细节会影响你的日常手感。

PyTorch 的张量最直观的特点是它和 NumPy 的互操作非常自然：torch.from_numpy和.numpy()可以在 CPU 张量和 NumPy 数组之间转换，且默认共享内存，能做到零拷贝。实际使用上，这意味着你可以把 NumPy 的数据处理、OpenCV 的图像读取、pandas 的表格处理直接接到 PyTorch 张量流程里，心智负担很小。

TensorFlow 的张量则更强调跨设备执行和自动设备分配。tf.Tensor自身带device信息，你可以随时用tf.debugging.set_log_device_placement(True)查看某个操作被放到哪个设备上。TensorFlow 对数据管道的设计也更重，tf.data.Dataset提供了完整的数据加载、shuffle、map、batch、prefetch 管线，这套东西在处理大数据集时非常有用，但学习曲线明显更陡。

在热词搜索里可以看到大量安装相关的问题，比如“cuda安装”“ubuntu22安装深度学习驱动安装了没反应”。这说明张量系统能不能真正跑起来，首先卡在设备环境，而不是代码。无论哪个框架，建议先在一个干净环境里验证 PyTorch 的torch.cuda.is_available()或 TensorFlow 的tf.config.list_physical_devices('GPU')是否返回 True。设备没接通，后面写的模型再正确也只是 CPU 上的玩具。

2.2 自动微分：动态图的 tape 和静态图的 graph

自动微分是深度学习框架最核心的底层能力，它的作用是不需要你手动推导反向传播公式。理解这一点比背诵任何 API 都有用。

PyTorch 的自动微分基于 Autograd 引擎。每个张量可以设置requires_grad=True，在前向计算过程中，框架会记录每一步操作，形成一个动态计算图；当你调用loss.backward()时，梯度会按链式法则从 loss 回传到每个需要梯度的参数上。调试时你可以在任意位置打印中间张量的值、修改梯度、甚至查看.grad是否为空。这种设计非常接近“把反向传播自动化了”的自然直觉。

TensorFlow 的自动微分在 GradientTape 中实现。你在with tf.GradientTape() as tape:块内执行的张量操作都会被记录，之后调用tape.gradient(loss, model.trainable_variables)就能拿到梯度。这个设计实际上也是动态的，关键是你要形成条件反射：所有需要求梯度的计算必须放在 tape 的作用域里面。常见错误就是把一些操作写在上下文外，导致梯度为 None。

可以做个类比：动态图调试就像写普通 Python 程序，可以在每一步 print；静态优化则像编译器，为了性能把代码整体优化后再执行。理解自动微分，就是理解框架在“记录计算过程”和“按链式法则回传”这两件事上的基本逻辑。真正动手实现一个深度网络时，最值得验证的事情是：梯度是否正确传导到所有可训练参数上。排查时先看损失是否下降，再看梯度是否为 None、是否出现 NaN，最后看学习率和数据归一化。

2.3 模型构建与训练循环：Eager 模式下的体验趋同

在 Eager 模式下，两个框架的高层 API 写起来已经非常接近了。PyTorch 使用torch.nn.Module，TensorFlow 使用tf.keras.Model。都是先定义一个类，在__init__里声明层，然后在forward或call方法里定义前向传播。

不过机制上有差异。PyTorch 的Module被调用时执行的是forward方法，子类化很自然，你可以用任意 Python 控制流。TensorFlow 的Model被调用时执行call方法，如果内部包含 Python 控制流，在序列化或导出为 SavedModel 时可能需要额外处理，否则可能会出问题。

训练循环的差异则是两个框架风格的分水岭。PyTorch 默认不提供完整的 fit 函数，你通常自己写一个 for 循环：遍历数据集、把数据放到设备、清零梯度、前向计算、算 loss、反向传播、优化器 step、打印指标。这个循环看起来很繁琐，但它把每一步都暴露给了你，让你真正理解训练过程。 TensorFlow 的 Keras 提供model.compile()加model.fit()的高层接口，几行代码就能跑一个完整训练流程。这在快速原型阶段效率很高，但如果你需要自定义循环，就要使用tf.GradientTape自己写。我自己见过不少用 Keras 上手很快的人，推导到自定义训练循环时反而容易卡住，因为之前太顺了。

从学习价值看，我更建议你至少手写一遍 PyTorch 风格的原生训练循环，因为它会把“前向计算—损失—梯度—更新”这个步骤钉进脑子里。之后再用 Keras 的 fit，你会清楚那些“魔术”后面到底发生了什么。

2.4 序列化与部署：weights_only、SavedModel 与转换链路

模型训练完，紧接着就是保存、加载、部署。两个框架在这一层的差异比训练层更明显。

PyTorch 的常规做法是torch.save(model.state_dict(), "model.pth")，加载时先实例化模型再load_state_dict。因为torch.load默认使用了 pickle，近期的版本里 PyTorch 对weights_only默认值做了调整，更倾向于安全加载权重而不是任意 Python 对象。我在实际使用里会建议你显式写出torch.load(..., weights_only=True)或使用官方推荐的安全加载方式，既能避免跨版本兼容问题，也能减少执行任意代码的风险。这算是近期热词里出现频率较高的一个隐蔽坑点。

TensorFlow 序列化的核心是 SavedModel 格式。model.save("my_model_dir")会生成一个包含权重、模型结构、签名函数的目录，生产环境可以通过 TensorFlow Serving 直接加载。它的优势是结构完整，和部署工具链衔接顺畅；缺点是目录结构看起来比单个权重文件复杂，第一次接触时容易感觉不直观。

如果你需要在两个框架之间互通模型，ONNX 是常见的中间转换格式。PyTorch 可以通过torch.onnx.export，TensorFlow 可以通过tf2onnx转换。转换时要注意模型的动态轴、算子兼容性问题，不是所有层都能百分百跨框架迁移。部署层面要结合你的线上服务是 Python 服务还是 C++ 服务、是否走 GPU 推理、是否需要批处理等条件综合判断。

3. 同一个模型，两种框架的实战演示

3.1 环境准备：先从最小可运行环境开始

不管学哪个框架，我都不建议把时间浪费在“完美配置全套环境”上。最佳路径是这样的：用 Conda 或虚拟环境创建独立 Python 环境，安装对应框架，然后先跑一个最小张量程序验证环境。

例子（这是常见写法，具体 Python 版本要根据你的依赖选择）：

# PyTorch 环境 conda create -n torch_env python=3.11 conda activate torch_env pip install torch torchvision

# TensorFlow 环境 conda create -n tf_env python=3.11 conda activate tf_env pip install tensorflow

这里有个容易踩坑的点：国内网络环境下直接 pip 下载大型安装包经常会超时或下载缓慢，可以考虑配置国内镜像源，或者使用框架官网给出的 GPU 版本安装命令。GPU 环境下，PyTorch 和 TensorFlow 都会要求你的 CUDA 驱动版本不低于某个阈值，但具体阈值随版本变化比较快，所以没有固定答案。更稳妥的办法是安装完成后，直接运行下面这行代码看设备是否可用：

# PyTorch 验证 import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU only")

# TensorFlow 验证 import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices('GPU'))

如果设备返回正常，说明环境通了，再往下学模型就是纯语言层面的问题。如果设备返回 False，先不要怀疑操作系统，按顺序检查驱动、CUDA 版本、Python 位数和框架安装命令是否匹配。很多人在这一步放弃或重装系统，其实大部分问题只是版本错配。

3.2 PyTorch 实战：定义 CNN 并完成完整训练循环

下面以 CIFAR-10 图像分类为例，写一个常见的最小 CNN 示例。如果你刚入门，可以把这个代码当成骨架，数据、网络层数、超参数都可以替换成你自己的任务。

import torch import torch.nn as nn import torch.optim as optim import torchvision import torchvision.transforms as transforms # 1. 数据加载 transform = transforms.Compose([ transforms.ToTensor(), transforms.Normalize((0.5, 0.5, 0.5), (0.5, 0.5, 0.5)) ]) trainset = torchvision.datasets.CIFAR10( root="./data", train=True, download=True, transform=transform ) trainloader = torch.utils.data.DataLoader( trainset, batch_size=64, shuffle=True, num_workers=2 ) # 2. 定义网络 class SimpleCNN(nn.Module): def __init__(self): super().__init__() self.conv1 = nn.Conv2d(3, 32, kernel_size=3, padding=1) self.conv2 = nn.Conv2d(32, 64, kernel_size=3, padding=1) self.pool = nn.MaxPool2d(2, 2) self.fc1 = nn.Linear(64 * 8 * 8, 128) self.fc2 = nn.Linear(128, 10) def forward(self, x): x = self.pool(torch.relu(self.conv1(x))) x = self.pool(torch.relu(self.conv2(x))) x = torch.flatten(x, 1) x = torch.relu(self.fc1(x)) x = self.fc2(x) return x model = SimpleCNN() device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) # 3. 损失函数和优化器 criterion = nn.CrossEntropyLoss() optimizer = optim.Adam(model.parameters(), lr=0.001) # 4. 训练循环 for epoch in range(3): running_loss = 0.0 for images, labels in trainloader: images, labels = images.to(device), labels.to(device) optimizer.zero_grad() outputs = model(images) loss = criterion(outputs, labels) loss.backward() optimizer.step() running_loss += loss.item() print(f"Epoch {epoch+1}, Loss: {running_loss/len(trainloader):.4f}") # 5. 保存权重 torch.save(model.state_dict(), "simple_cnn.pth")

这段代码的关键点是：定义训练循环时，五步操作顺序不要乱——取数据、清零梯度、前向计算、算损失并反向传播、优化器更新。如果遗漏optimizer.zero_grad()，梯度会在多个 batch 间累积，损失曲线会非常不稳定。

3.3 TensorFlow 实战：用 Keras 实现同一个模型

同样一个模型，TensorFlow/Keras 的高层接口写法会短很多：

import tensorflow as tf # 1. 数据加载 (x_train, y_train), (x_test, y_test) = tf.keras.datasets.cifar10.load_data() # 归一化到 [0,1] x_train = x_train.astype("float32") / 255.0 x_test = x_test.astype("float32") / 255.0 # 2. 定义模型 model = tf.keras.Sequential([ tf.keras.layers.Conv2D(32, kernel_size=3, padding="same", activation="relu", input_shape=(32, 32, 3)), tf.keras.layers.MaxPooling2D(pool_size=(2, 2)), tf.keras.layers.Conv2D(64, kernel_size=3, padding="same", activation="relu"), tf.keras.layers.MaxPooling2D(pool_size=(2, 2)), tf.keras.layers.Flatten(), tf.keras.layers.Dense(128, activation="relu"), tf.keras.layers.Dense(10) ]) # 3. 编译 model.compile( optimizer=tf.keras.optimizers.Adam(learning_rate=0.001), loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True), metrics=["accuracy"] ) # 4. 训练 history = model.fit(x_train, y_train, batch_size=64, epochs=3) # 5. 保存模型 model.save("simple_cnn_model")

这里有一个细节值得留意：因为 CIFAR-10 的标签是整数编号，所以损失函数用SparseCategoricalCrossentropy，再配合from_logits=True，也就是说网络的最后一层没有接 Softmax。如果你自己写数据集时标签是 One-Hot 编码，就要换成CategoricalCrossentropy。这个匹配关系不弄清楚，模型可以“跑起来”，但训练结果会混乱。

3.4 两种写法的本质差异和通用能力

对比两个示例，你会发现数据准备、模型定义、损失计算、训练循环这些概念在两边都有对应物。真正差异不在“谁更简单”，而在于：

• PyTorch 风格把训练循环暴露给用户，当你需要写复杂逻辑时更灵活；TensorFlow/Keras 则把训练循环封装在 fit 内，快速验证更快。
• PyTorch 的Module子类化让你对网络结构有完全控制；TensorFlow 的 Sequential 适合固定结构，换成多输入或多输出模型时再考虑 Functional API 或子类化。
• TensorFlow 如果需要复用 PyTorch 里那种自定义训练循环，可以在tf.GradientTape里实现，模式上会多一层上下文管理器。

真正重要的通用能力是：不要只背 API，而是能在拿到一个任务后手动完成数据读入、模型搭建、训练验证、保存模型这四个必要环节。任何框架教程做到这一步，都算真正入门。

4. 安装环境与排查链路：跑通比理解更重要

4.1 PyTorch 安装的常见思路

热词里大量出现“pytorch安装教程gpu”“pytorch环境搭建”“安装pytorch gpu版本”。可见安装问题挡住了很多人。PyTorch 安装虽然不像某些大型软件那样复杂，但 GPU 版本需要关注几个点：

第一，先确认你的显卡驱动能正常识别 GPU，在终端输入nvidia-smi能看到显卡信息。第二，去 PyTorch 官网按你的 CUDA 版本选择安装命令，而不是盲目用 pip 默认源安装 CPU 版本。第三，安装完后至少运行一次torch.cuda.is_available()验证设备可用，然后跑一个小张量乘法确认 GPU 计算正常。

如果你用的是 Jetson 这类嵌入式设备，比如搜索引擎里出现的 JetPack 6.2.2，那要格外小心：这类平台上的 PyTorch 一般不能直接用普通 pip 安装，通常需要安装官方预编译的 wheel 或用源码编译，并且必须匹配 JetPack 版本。这时候先看官方论坛或发布说明，比自己试错更快。

4.2 TensorFlow 安装的常见问题

TensorFlow 在 CPU 机器上安装相对简单，pip install tensorflow就能跑 CPU 版本。GPU 版本时需要确保 CUDA 环境和 cuDNN 版本与当前 TensorFlow 要求匹配。不同 TensorFlow 版本对 CUDA 的支持差异可能会让你“装上了却用不了”。

很多人在 Ubuntu 上遇到“驱动安装了没反应”的情况。我的排查建议是：先看nvidia-smi是否能执行，再看内核模块是否加载，最后才怀疑框架安装问题。不要一装不上就重装系统，大部分情况只是驱动加载、CUDA 路 径或 pip 版本问题。把排查链路固定成“驱动层面 → CUDA 层面 → 框架层面”三层递进，会省很多时间。

4.3 一次标准的环境排查顺序

如果你已经装了某个深度学习框架但跑模型报错，可以参考这个顺序排查，不要上来就跑去群里提问。我自己一般按五步排查：

1. 看现象：报错、卡住、无输出、速度很慢、结果 NaN。不同现象对应不同层次的问题。
2. 看输入：数据路径、文件格式、输入尺寸、归一化方式、标签编码是否正确。
3. 看环境：Python 版本、CUDA 版本、cuDNN 版本、已有依赖是否冲突、是否有多个环境下错。
4. 看参数：batch size、学习率、优化器配置、epochs、并发数是否合理。
5. 看工具边界：当前框架版本是否有已知问题、某个 API 是否被弃用、当前平台是否支持。

以 PyTorch 里常见的weights_only相关问题为例，如果你看到加载权重时报新增的警告或报错，可以先看是不是本机版本比保存权重时的版本更新，然后按新版本的推荐方式显式指定加载参数。以 TensorFlow 为例，如果看到Could not load dynamic library 'cudart64_*.dll'这类错误，通常不是代码问题，而是 CUDA 相关动态库不在系统搜索路径里。

4.4 快速检查 GPU 是否真被用起来的技巧

有时候你跑一个很小的模型，感觉速度很快，但其实在用 CPU，因为框架的 GPU 支持根本没启用。判断办法很简单：

# PyTorch：输出模型所在设备 print(next(model.parameters()).device)

# TensorFlow：查看操作被分配到哪个设备 tf.debugging.set_log_device_placement(True)

如果在日志或输出里看到device:GPU:0，说明 GPU 生效；如果是device:CPU:0，就说明框架认为当前没有可用的 GPU 或没有安装 GPU 版本。这时候再回到驱动和框架版本匹配问题上去查，基本就能定位。

5. 从“跑通 demo”到“简历里可描述的项目”

5.1 把简单模型变成项目的五个步骤

很多初学者刷完教程，感觉自己会了，但简历上只有一个“用 PyTorch 实现了 CNN 分类 CIFAR-10”。这种描述在面试官眼里几乎没有区分度，因为这是每个教程都有的东西。真正值得写的是，你不只跑通了 demo，还完成了一条项目级链路。可以参考下面的步骤来把 demo 升级成项目：

1. 规范数据管道：把自己的数据集按 train/val/test 划分，数据加载时加入 shuffle、batch、归一化，处理缺失值和类别不平衡。
2. 完善训练流程：支持恢复训练、保存最优权重、记录训练曲线、设置早停条件。
3. 增加指标记录：不只记录 loss，还记录准确率、召回率、F1 或你任务里的核心指标，并输出到本地文件或可视化工具。
4. 做好模型保存与加载：确保训练结束后能用一段独立脚本加载权重并做推理，而不是只在训练脚本里顺手验证。
5. 部署或接口化：把模型封装成函数或服务接口，输入一张图片返回预测结果，这样才算完成了“能给别人用”的闭环。

这一步才是真正和“只填到教程”拉开差距的地方。

5.2 PyTorch 生态中最值得了解的扩展库

如果你用 PyTorch 做项目，除了torch本身，有几个扩展库值得提前熟悉：

• torchvision：提供常用数据集、图像变换和预训练视觉模型，做 CV 任务必备。
• Hugging Face Transformers：做 NLP 和大模型微调几乎绕不开，内部以 PyTorch 为核心生态之一。
• PyTorch Lightning：把训练循环、分布式、日志、checkpoint 封装成更工程化的写法，适合团队协作和复杂实验管理。
• torch.compile：新版本里用于加速模型训练推理的编译能力，性能敏感时可以研究。

学习建议是：先不用全部掌握，把 torchvision 用熟，再从 Transformers 里跑通一个 BERT 或类似模型的微调，简历上就能写“熟悉预训练模型的加载与微调流程”。

5.3 TensorFlow 生态中最值得了解的组件

TensorFlow 生态更适合从工程化角度切入：

• tf.keras：高层模型 API，适合快速建模并与其他工程组件衔接。
• tf.data：深度优化的数据管道，如果你的数据量大，这一步非常关键。
• TensorFlow Serving：把 SavedModel 发布成 gRPC/REST 服务的主流方案。
• TF Lite与TF.js：分别覆盖移动端嵌入式端和浏览器端推理。

如果你已经会用 PyTorch 做研究型实验，再用 TensorFlow 完成一次导出 SavedModel 并通过 Serving 或 TF Lite 部署，就能在简历上形成“训练 + 部署”的完整证据链。

5.4 简历中描述“框架能力”的写法建议

关于简历，我不建议写“精通 PyTorch 和 TensorFlow”，因为这类说法很快会在细节提问下露馅。更稳妥的写法是：

• 写清楚你用哪个框架完成过什么任务，而不是简单罗列框架名。
• 写清楚你处理过哪些数据、踩过哪些环境或性能问题、最后怎么解决。
• 如果项目里两个框架都用过，写清楚分工：比如 PyTorch 负责训练，TensorFlow 或 ONNX 负责部署。
• 在项目描述中突出“为什么这样做”，而不只是“做了什么”。

能同时理解两个框架自然是加分项，但加分的来源是你能讲清楚它们各自适合做什么，而不是你能在不同的代码库里编译通过。

6. 最终选型框架：一条可复用的判断路径

6.1 按任务类型分象限判断

如果你现在要开始一个新项目，不知道该选哪个框架，我建议不要听别人绝对化的结论，而是按任务类型判断：

这张表不是权威标准，只是一条降低决策成本的经验路径。你完全可以根据团队已有代码、公司部署设施和个人偏好调整。

6.2 我的建议：主选一个，了解另一个

如果你还在学习阶段，我的建议非常明确：先以 PyTorch 为主，把模型训练、数据处理、自定义网络、迁移学习、模型保存加载这些基础能力练扎实，然后把 TensorFlow/Keras 作为第二个框架，跑通一个 Keras 训练流程并知道 SavedModel 是什么，就足够了。

原因很简单：长期看，深度学习框架是会演进和替换的，但底层的概念不会变。你在任何一个框架里理解了自动微分、优化器、损失、梯度、设备管理，换到另一个框架只需要重新学 API 表达。不要把大量时间花在同时学两个框架的细枝末节上，那是低效的。

6.3 框架之外真正重要的通用能力

最后想提醒一句：框架只是工具层，你的竞争力更多来自于框架之外的通用能力。

• 数据处理能力：能否把一份杂乱的数据整理成模型可以训练的形式。
• 调试与实验记录能力：出问题后能不能按逻辑定位，而不是盲目调参。
• 模型评估能力：能不能用准确率之外的指标判断模型是否真的可用。
• 工程化意识：是否考虑过训练耗时、显存占用、模型体积、推理延迟、可维护性。
• 持续学习能力：框架在变，但模型结构、损失函数、优化算法、评估方式这些知识相对稳定。

如果你真想“能力拉满”，不是靠死记两个框架的 API，而是要靠在一两个真实项目里把从数据到部署的整条链路跑通。到那时候，简历上写什么框架其实只是顺手的事。

回到最开始的问题：PyTorch 和 TensorFlow 到底怎么选？答案不是选一个站队，而是先跑通一个框架的完整项目，再用另一个框架做对照实验，搞清楚它们的核心架构和设计取舍。这样你得到的不是“会两个工具”的标签，而是一套能迁移到未来任何框架上的判断力。下一步最该做的，就是先建一个新环境，把本文里的最小示例跑起来，然后亲手记录一次从数据到权重保存的完整输出。