TensorFlow预训练模型与Eager/Graph执行模式实战指南

深度学习框架用久了，你会发现一个规律：真正拉开效率差距的，往往不是谁更会调参，而是谁更懂得站在现成的肩膀上。TensorFlow 这套生态里，预训练模型和开箱即用的 API 就是那副肩膀，而 Eager Execution 与 Graph Execution 的取舍，则决定了你写代码时是"边写边看"还是"先搭图后跑车"。这两块内容看似一个讲模型、一个讲执行机制，实际上它们共同构成了 TensorFlow 日常开发的两条主线——一条解决"用什么"，一条解决"怎么跑"。我自己从早期版本一路用到现在，踩过的坑不算少，下面就把预训练模型的调用方式、Eager 模式的实操细节，以及两种执行模式的本质差异，按我实际工作中的理解完整拆一遍，适合刚上手 TensorFlow 的朋友，也适合想把手头代码从旧范式迁移过来的老手参考。

1. 预训练模型与 API 的整体布局思路

1.1 为什么 TensorFlow 要把模型"分层"提供

刚接触 TensorFlow 的人常有个困惑：官方文档里一会儿是 Keras Applications，一会儿是 Hub，一会儿又冒出个 Model Garden，到底该用哪个？这背后其实是一套分层设计逻辑。最上层是Keras Applications，提供的是经过验证的经典骨干网络，比如 ResNet、MobileNet、EfficientNet 这些，接口统一、一行代码就能加载，适合绝大多数迁移学习场景。中间层是TensorFlow Hub，它更像一个模型仓库，除了图像分类，还覆盖文本嵌入、音频特征、目标检测等，模型来源也更杂，既有官方也有社区贡献。最底层是Model Garden，偏向研究级和前沿模型，代码量大、依赖多，适合需要深度定制的研究场景。

这种分层不是随意堆砌，而是对应了不同的使用深度。你只是想拿个 ResNet 做图像分类微调，用 Keras Applications 就够了，没必要碰 Model Garden 那套复杂的配置。反过来，你要复现某篇论文里的检测架构，Keras Applications 里根本没有，只能去 Model Garden 找。理解这个分层，能帮你少走很多弯路——我见过不少人一上来就扎进 Model Garden，结果被一堆依赖和配置文件劝退，其实他的需求用 Keras Applications 十分钟就能搞定。

从工程角度看，这种分层还有个隐性好处：依赖隔离。Keras Applications 随 TensorFlow 主包一起安装，不需要额外拉取；TensorFlow Hub 需要单独装tensorflow-hub；Model Garden 则往往要克隆整个仓库、装一堆第三方库。你在做技术选型时，先想清楚自己的定制程度，再决定往哪一层走，能省下大量环境折腾的时间。

1.2 三类 API 的适用边界对比

为了让你一眼看清差异，我把这三层的核心特征整理成表：

这张表不是让你死记，而是帮你建立判断直觉。我的经验是：能用 Keras Applications 解决的，绝不往上走。因为它的接口最稳定、文档最全、社区问题最多（意味着你遇到的坑别人基本都踩过）。只有当需求明确超出它的覆盖范围，比如要做文本语义相似度、要加载一个特定领域的嵌入模型，才考虑 Hub。Model Garden 则是最后的选择，除非你确实需要它独有的架构。

1.3 预训练权重背后的迁移学习逻辑

很多人调用预训练模型时只是机械地写weights='imagenet'，却说不清这行参数到底带来了什么。简单讲，预训练权重是模型在海量数据上训练后留下的一组参数，这些参数编码了通用的特征提取能力——浅层学到边缘、纹理，深层学到语义部件。你把它加载进来，相当于让模型带着"见过世面"的基础来学你的新任务，而不是从随机初始化开始瞎摸索。

这里有个关键取舍：冻结多少层。全冻结（trainable=False）适合你的数据集很小、和原任务很接近的情况，训练快、不易过拟合；全解冻适合数据量大、任务差异大的场景，但需要更小的学习率，否则预训练学到的特征会被破坏。我通常的做法是先冻结骨干只训分类头，等 loss 稳定后再解冻最后几个 block 用低学习率微调，这个两阶段策略在多数图像任务上都很稳。下面这段代码就是这个思路的骨架：

import tensorflow as tf base = tf.keras.applications.MobileNetV2( input_shape=(224, 224, 3), include_top=False, weights='imagenet' ) base.trainable = False # 第一阶段：冻结骨干 model = tf.keras.Sequential([ base, tf.keras.layers.GlobalAveragePooling2D(), tf.keras.layers.Dense(128, activation='relu'), tf.keras.layers.Dropout(0.3), tf.keras.layers.Dense(10, activation='softmax') ]) model.compile( optimizer=tf.keras.optimizers.Adam(1e-3), loss='sparse_categorical_crossentropy', metrics=['accuracy'] )

注意include_top=False这个参数，它决定了是否保留原模型最后的分类层。做迁移学习时几乎总是设为 False，因为原模型的分类类别数和你自己的任务对不上，保留它反而要额外处理。这个细节新手容易忽略，加载完发现输出维度是 1000 而不是自己的类别数，才回头找原因。

2. 预训练模型实操：从加载到微调的完整链路

2.1 Keras Applications 的加载与预处理配套

用 Keras Applications 最容易被低估的一点，是预处理必须和模型配套。每个骨干网络在训练时用的归一化方式不一样，比如 MobileNetV2 期望输入缩放到 [-1, 1]，而 ResNet50 用的是另一套均值方差。如果你随便拿img / 255.0就喂进去，模型也能跑，但精度会莫名其妙地掉一截，而且很难排查。

正确的做法是用官方提供的preprocess_input函数：

from tensorflow.keras.applications.mobilenet_v2 import preprocess_input import numpy as np # 假设 img 是 0-255 范围的 uint8 数组 x = preprocess_input(img.astype(np.float32)) x = np.expand_dims(x, axis=0) # 补 batch 维度

这个函数内部做的就是对应模型训练时的归一化。我踩过的坑是：有一次自己手写归一化，结果和模型预期差了半个量级，验证集精度卡在 60% 上不去，换成preprocess_input后直接跳到 85%。所以这条经验值得记牢——预处理永远跟着模型走，不要自己发明。

另外，include_top、weights、input_shape这三个参数要一起考虑。如果你改了input_shape，就不能加载imagenet的全套权重（因为最后的全连接层尺寸对不上），这时要么设include_top=False，要么让权重只加载匹配的部分。实际项目中我基本固定用 224×224 或 299×299，和原模型保持一致，省去这些麻烦。

2.2 TensorFlow Hub 的 KerasLayer 封装技巧

Hub 的模型调用方式和 Keras Applications 不太一样，它返回的是一个可调用的层对象，最常用的封装是hub.KerasLayer。这个封装的好处是能直接塞进tf.keras.Sequential或函数式模型里，和普通层一样参与训练。

import tensorflow_hub as hub hub_layer = hub.KerasLayer( "https://tfhub.dev/google/nnlm-en-dim128/2", input_shape=[], dtype=tf.string, trainable=False ) model = tf.keras.Sequential([ hub_layer, tf.keras.layers.Dense(64, activation='relu'), tf.keras.layers.Dense(1, activation='sigmoid') ])

这里有几个实操要点。第一，trainable=False在 Hub 模型上几乎是默认选择，因为 Hub 模型往往很大，全量微调成本高且容易过拟合，冻结后只训后面的头就够了。第二，input_shape和dtype要和模型预期严格匹配，文本模型通常吃tf.string，图像模型吃浮点张量，填错了会在第一次前向时炸掉。第三，Hub 模型首次加载会下载权重到本地缓存，网络不好时会卡住，建议提前在稳定环境里跑一次把缓存建好。

Hub 真正体现价值的地方是多模态和文本场景。比如做句子相似度，你可以直接加载一个句向量模型，把文本映射成定长向量，后面接个余弦相似度就完事，完全不用自己训 embedding。这种"拿来即用"的能力，是 Keras Applications 覆盖不到的。

2.3 微调阶段的层解冻与学习率策略

微调是整个流程里最考验经验的部分。前面提到两阶段策略，具体到操作上，解冻时要特别注意BatchNormalization 层。BN 层在推理时用的是移动统计量，微调时如果把它也设为可训练，统计量会被小批量数据带偏，反而伤害性能。所以业界常见做法是：解冻卷积层但保持 BN 层冻结。

# 解冻最后两个 block，但 BN 层保持冻结 base.trainable = True for layer in base.layers[:-20]: layer.trainable = False for layer in base.layers: if isinstance(layer, tf.keras.layers.BatchNormalization): layer.trainable = False model.compile( optimizer=tf.keras.optimizers.Adam(1e-5), # 微调学习率要小 loss='sparse_categorical_crossentropy', metrics=['accuracy'] )

学习率这里我从 1e-3 降到 1e-5，降了两个数量级。原因是微调阶段模型已经接近一个好的解，大步长会把预训练特征破坏掉。这个数值不是死的，数据量越大可以适当放大，但一般不超过 1e-4。实测下来，1e-5 配合早停（EarlyStopping）在多数中小数据集上表现稳定。

还有一个容易忽略的点：重新 compile。在 Keras 里，改变trainable属性后必须重新调用compile，否则优化器不会感知到参数变化。这个坑我早期踩过，解冻了半天发现模型根本没在学，排查很久才想起来是没重新编译。

3. Eager Execution 模式的核心机制与实操

3.1 Eager 模式到底改变了什么

TensorFlow 1.x 时代，写代码的体验是先定义一张计算图，再开一个 Session 去执行，中间看不到任何中间结果。Eager Execution 把这个顺序彻底翻转了：代码写一行执行一行，结果立刻返回。这听起来只是使用体验的改善，但它带来的连锁反应很深远。

最直接的变化是调试。以前图模式下，你想看某个张量的值，得用tf.Print或者开 Session 跑sess.run，非常别扭。Eager 模式下，张量就是实实在在的数值，print一下就能看到，配合 Python 原生调试器可以逐行断点。这对新手极其友好——你可以像写 NumPy 一样写 TensorFlow，边写边验证。

第二个变化是控制流的自然表达。图模式下写 if/while 要用tf.cond、tf.while_loop这些特殊算子，因为图是静态的，得提前把分支结构编码进去。Eager 模式下直接用 Python 的 if/for 就行，因为每步都在真实执行。这让代码可读性大幅提升，尤其是涉及复杂逻辑的模型。

第三个变化是与 Python 生态的无缝衔接。Eager 模式下张量和 NumPy 数组可以自由转换，tf.numpy_function、tf.py_function这类桥接也更自然。你在 Eager 里调一个 Python 函数处理张量，不需要像图模式那样小心翼翼地考虑图构建时机。

3.2 用 tf.function 兼顾灵活与性能

Eager 模式虽好，但有个硬伤：逐行执行意味着没有全局优化。每次运算都是一次独立的 kernel 调用，Python 解释器的开销也摊在里面，性能上比图模式差。TensorFlow 2.x 的解法是tf.function——你写的是 Eager 风格的代码，但它会在第一次调用时把函数追踪（trace）成一张图，后续调用走图执行，兼顾了开发体验和运行效率。

@tf.function def train_step(x, y): with tf.GradientTape() as tape: logits = model(x, training=True) loss = loss_fn(y, logits) grads = tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(grads, model.trainable_variables)) return loss

这段代码是 TensorFlow 2.x 训练循环的标准写法。@tf.function装饰后，train_step第一次被调用时会追踪成图，之后每次调用都复用这张图。注意training=True这个参数，它控制 Dropout 和 BN 层的行为，训练和推理时必须区分，否则结果会不对。

tf.function有个需要警惕的行为：它会对不同的输入签名（shape、dtype）分别追踪。如果你的输入 shape 每次都变，就会反复追踪，反而更慢。解决办法是用input_signature固定签名，或者确保输入 shape 稳定。我在处理变长序列时踩过这个坑，后来统一 padding 到固定长度才解决。

3.3 Eager 下的调试与性能观测手段

Eager 模式最大的红利是调试，但要用好还得掌握几个工具。最基础的是直接print张量，Eager 下张量有具体的值，print(x)就能看到内容和 shape。进阶一点用tf.debugging系列，比如tf.debugging.assert_all_finite检查 NaN/Inf，tf.debugging.check_numerics定位数值异常。

性能观测方面，Eager 模式下可以用tf.profiler或者简单的计时。我常用的土办法是在关键段落前后打时间戳：

import time start = time.time() for _ in range(100): train_step(x_batch, y_batch) print(f"平均每步耗时: {(time.time() - start) / 100:.4f}s")

这个办法粗糙但有效，能快速判断瓶颈在数据加载还是模型计算。如果要精细分析，就上 TensorBoard 的 profiler，能看到每个算子的耗时分布。Eager 模式下 profiler 的接入比图模式简单，直接tf.profiler.experimental.start就行。

需要提醒的是，Eager 下的性能数字不能直接和图模式比。因为 Eager 有 Python 开销，同样的模型在 Eager 下跑出来的吞吐会偏低，这是正常的。要评估真实性能，应该用tf.function包装后再测，那才是生产环境的数字。

4. Graph Execution 与 Eager 的本质差异及迁移实践

4.1 两种模式的执行模型对比

要理解两者的差异，得从"计算什么时候发生"这个角度切入。Graph Execution 是先建图、后执行：你写的所有算子只是在描述计算关系，真正的数值计算要等 Session 启动后才发生。Eager Execution 是边定义边执行：每个算子调用立即产生结果。

这个根本差异衍生出一系列连锁区别，我整理成表方便对照：

从这张表能看出，Graph 的优势在性能与部署，Eager 的优势在开发与调试。TensorFlow 2.x 的策略是用 Eager 做默认、用tf.function按需转图，本质上是把两者的优点拼起来。这个设计思路值得理解，因为它解释了为什么现在写 TensorFlow 代码，大部分时候你感受不到"图"的存在，但性能又不至于太差。

4.2 从图模式迁移到 Eager 的常见改写

如果你手上有 TensorFlow 1.x 的老代码要迁移，几个高频改写点值得提前知道。首先是Session 和 placeholder 的消失。老代码里tf.placeholder定义输入、sess.run喂数据，新写法直接用函数参数传张量：

# 旧写法（图模式） x = tf.placeholder(tf.float32, [None, 784]) y = tf.matmul(x, W) + b with tf.Session() as sess: result = sess.run(y, feed_dict={x: data}) # 新写法（Eager） def forward(x): return tf.matmul(x, W) + b result = forward(data)

其次是变量初始化。图模式要显式sess.run(tf.global_variables_initializer())，Eager 下变量创建即初始化，不需要这一步。第三是控制流，前面提过，tf.cond换成 Python if，tf.while_loop换成 Python while（或者保留tf.while_loop以便tf.function追踪）。

迁移时最容易出错的是依赖图构建时机的逻辑。老代码里有些操作是在建图阶段执行的（比如某些 shape 推断），迁移到 Eager 后执行时机变了，可能导致行为不一致。我的建议是迁移后跑一遍完整的单元测试，重点验证 shape 和 dtype，这两块最容易出问题。

4.3 什么场景该主动切回图模式

虽然 Eager 是默认，但有些场景主动用tf.function转图是明智的。训练循环是典型，前面train_step的例子就是，转图后性能提升明显。模型推理服务也是，部署时用 SavedModel 保存的本来就是图，天然高效。大规模分布式训练更不用说，图模式对算子切分和通信优化支持更成熟。

反过来，数据预处理、复杂的 Python 逻辑、需要频繁打印调试的阶段，留在 Eager 下更合适。我一般的划分是：数据管道用tf.data（它内部有自己的优化），模型前向和训练步用tf.function，外围的调度、日志、评估逻辑留在 Eager。这个混合策略在实际项目里很实用，既保证了性能，又保留了灵活性。

有个细节要注意：tf.function里的代码不能有副作用依赖，比如修改 Python 全局变量、依赖外部可变状态，这些在追踪时只会执行一次，后续调用不会重复。如果确实需要状态，用tf.Variable而不是 Python 变量。这个坑我在写带计数器的自定义训练循环时踩过，计数器不涨，排查半天才发现是追踪机制导致的。

5. 实操中的高频问题与排查心得

5.1 预训练模型加载与微调的典型故障

实际用预训练模型时，问题往往集中在几个固定位置。我把常见故障和排查思路整理如下：

这张表里，预处理不对和学习率过大是两个最高频的坑。前者隐蔽，因为模型能跑、不报错，只是精度差；后者表现为训练初期 loss 震荡甚至上升。我的排查习惯是先确认预处理，再确认学习率，这两个排除了，大部分问题就定位了。

还有一个容易被忽略的点：类别不平衡。迁移学习时如果新数据集类别严重不平衡，即使预训练模型很强，分类头也会偏向多数类。这时要在 loss 里加 class weight，或者用重采样。这个不属于模型本身的问题，但会让人误以为是预训练权重不好用。

5.2 Eager 与 tf.function 混用的陷阱

tf.function用起来简单，但混用时的坑不少。最典型的是在 tf.function 里创建 tf.Variable。第一次追踪时变量被创建，后续调用不会重复创建，但如果你的逻辑依赖每次调用都新建变量，就会出错。正确做法是把变量创建移到函数外，函数内只做读写。

第二个坑是Python 侧的效果只执行一次。比如你在tf.function里print一个张量，它只会在追踪时打印一次，后续调用不再打印。想看每次调用的值，得用tf.print（注意是 tf 命名空间下的），它会被编进图里，每次执行都输出。

第三个坑是动态 shape 导致的重复追踪。前面提过，不同 shape 会触发重新追踪，如果 shape 变化频繁，追踪开销会累积。解决办法是用input_signature声明期望的签名，或者用tf.TensorSpec固定维度。我在处理变长文本时，最后统一 padding 到固定长度，追踪次数从几百次降到一次，训练速度提升明显。

5.3 性能调优的实测经验

性能这块，我总结了几条实测有效的做法。第一，数据管道优先用 tf.data，并且开启prefetch和cache，让数据加载和模型计算重叠。prefetch(tf.data.AUTOTUNE)这一行往往能带来可观的吞吐提升，因为默认情况下数据准备和计算是串行的。

第二，训练步用 tf.function 包装，前面反复提过，这是性价比最高的优化。第三，合理设置 batch size，太小则 GPU 利用率低，太大则显存不够，一般从 32 或 64 起步，根据显存调整。第四，考虑混合精度，在支持的硬件上用tf.keras.mixed_precision，能在几乎不损失精度的情况下提速并省显存。

tf.keras.mixed_precision.set_global_policy('mixed_float16')

这一行开启混合精度后，大部分计算走 float16，关键累加仍用 float32。实测在图像任务上提速 30% 到 50% 不等，显存占用也降了不少。不过要注意，混合精度下 loss scaling 要处理好，Keras 的优化器一般会自动处理，自定义训练循环时得手动加LossScaleOptimizer。

最后分享一个排查性能问题的小技巧：先用tf.function包装测一遍，如果还是慢，再用 profiler 看算子耗时。很多时候瓶颈不在模型，而在数据加载或者 Python 侧的调度逻辑。我遇到过一次训练很慢，profiler 一看 70% 时间花在数据管道上，优化tf.data后整体速度翻倍。所以别一上来就怀疑模型，先看数据。

6. 模型选型与执行模式的组合决策

6.1 按任务类型选择预训练入口

把预训练模型和执行模式放在一起看，会发现它们的选择其实是联动的。图像分类任务，Keras Applications 加 Eager 开发、tf.function 训练，是最顺手的组合。文本任务，Hub 的句向量模型加 Eager 调试，能快速验证想法。目标检测这类复杂任务，Model Garden 的模型往往自带训练脚本，你更多是在它的框架里改，而不是从零搭。

我的决策顺序是：先定任务，再定模型层级，最后定执行模式。任务简单、模型现成，就全程 Eager 加 tf.function 训练步；任务复杂、需要定制，就在 Model Garden 的图模式代码基础上改，调试时局部切 Eager。这个顺序能避免"为了用某个模型而硬套任务"的本末倒置。

6.2 小数据集与大数据集的不同策略

数据规模直接影响策略。小数据集（几千张以内），预训练模型几乎必须冻结大部分层，只训分类头，学习率可以稍大（1e-3），因为要训的参数少。大数据集（十万级以上），可以解冻更多层甚至全量微调，但学习率要小（1e-5 量级），并且要有足够长的训练周期。

Eager 和 tf.function 的取舍也和数据规模有关。小数据集训练快，Eager 的调试便利性更值钱，可以多留在 Eager 下观察。大数据集训练慢，每一轮都宝贵，必须用 tf.function 榨性能，调试则靠日志和 TensorBoard，而不是逐行 print。这个权衡我在不同项目里反复验证过，基本成立。

6.3 部署阶段的模式切换考量

训练完要部署时，执行模式的选择又变了。部署环境追求的是稳定和吞吐，这时图模式是首选。Keras 的model.save保存成 SavedModel 格式，内部就是图，加载后推理高效。如果你之前用 Eager 写的自定义逻辑，部署前要确保关键路径都被tf.function覆盖，否则推理时会带着 Python 开销。

还有一个部署细节：输入签名的固定。SavedModel 会记录输入的 shape 和 dtype，部署时如果实际输入和签名不符，会报错或触发重新追踪。所以保存前用tf.function的input_signature明确声明，能避免很多线上问题。我在一次服务部署时就因为没固定签名，遇到变长输入反复追踪，延迟飙升，后来固定 padding 长度才稳定下来。

7. 我个人在实际操作中的几点体会

用到现在，我对这两块内容最大的感受是：预训练模型的价值在于"省"，执行模式的价值在于"顺"。省的是从零训练的时间和算力，顺的是开发和调试的心流。很多人把注意力全放在模型结构上，却忽略了执行模式对开发效率的影响，其实后者在日常工作里占比更大——你花在调试上的时间，往往比设计模型多得多。

预训练模型这块，我建议新手从 Keras Applications 的 MobileNetV2 入手，它轻量、加载快、预处理简单，适合反复练手。等熟悉了迁移学习的流程，再去碰 Hub 的文本模型和 Model Garden 的复杂架构。执行模式这块，别一上来就纠结图模式和 Eager 的理论差异，先把 Eager 用熟，等遇到性能瓶颈了，自然会理解tf.function为什么存在。这种"先会用、再懂原理"的路径，比反过来更扎实。

最后分享一个小习惯：每次加载预训练模型后，先跑一个前向看输出 shape 和数值范围，确认没问题再往下写。这个动作只要几秒钟，却能提前发现预处理、维度、权重加载的大部分问题。踩过几次"训练半天发现输入维度错了"的坑之后，我现在把这个检查当成固定流程，省下的返工时间远超这几秒的投入。