1. 从一次显存溢出说起为什么“能跑通”和“跑得高效”是两码事刚接触 TensorFlow 那会儿我判断一个模型写得好不好标准特别朴素——只要model.fit()不报错、loss 能往下掉就觉得大功告成。直到有次在单卡上训练一个不算大的图像分类网络batch size 设到 64 就提示显存不够可我明明算过参数量和特征图占用理论上绰绰有余。折腾了大半天才反应过来问题不在模型本身而在我把数据管道写成了“同步阻塞式”的——tf.data没做预取GPU 算完一个 batch 就干等着 CPU 读下一批数据显存里堆着一堆没被及时释放的中间张量利用率低得可怜。这件事让我意识到TensorFlow 的高效编程核心不是“能不能跑”而是“每一份算力、每一兆显存有没有被浪费”。这个系列我打算把自己这几年在 TensorFlow 上踩过的坑、总结出的提速套路按主题拆开讲清楚。第一篇先聚焦最容易被忽视、但对整体吞吐影响最大的部分数据输入管道与计算图的执行效率。不管你是刚上手的新手还是已经能写模型但总觉得训练慢半拍的老手这里面的东西都能直接拿去用。需要先说明一点TensorFlow 从 1.x 到 2.x 变化很大1.x 的Sessionplaceholder那套静态图写法和 2.x 默认的 eager execution 加tf.function图模式优化思路有相通的地方但具体手段差别不小。我下面主要以 2.x 为主线涉及 1.x 的地方会单独点出来避免你拿着旧教程在新版本上瞎试。2. tf.data 管道决定 GPU 饿不饿肚子的关键一环2.1 为什么你的 GPU 利用率总是上不去很多人看训练速度只盯着 GPU 利用率那个数字。如果它长期在 30% 到 50% 之间晃悠甚至更低那基本可以断定瓶颈不在 GPU 的计算而在数据供给。GPU 是个“吃货”它算一个 batch 可能只要几十毫秒但如果你的数据管道要花上百毫秒才能凑齐下一批那 GPU 大部分时间都在等饭。TensorFlow 的tf.dataAPI 就是专门解决这个问题的。它的设计哲学是把数据读取、预处理、批处理拆成一条流水线让 CPU 端的准备工作和 GPU 端的计算能重叠起来。但默认配置下这条流水线是“串行”的——你调一次next()它才去读一次数据、做一次变换。要让它跑起来得手动加上几个关键操作。我见过太多代码是这样写的dataset tf.data.Dataset.from_tensor_slices((images, labels)) dataset dataset.map(preprocess_fn) dataset dataset.batch(32)这段代码能跑但效率极低。map是逐个样本串行执行的batch之后也没有任何预取。GPU 算完一批CPU 才开始处理下一批两者完全没法重叠。正确的做法是引入并行化和预取。2.2 num_parallel_calls 与 prefetch两个必须加的参数先看改进后的写法dataset tf.data.Dataset.from_tensor_slices((images, labels)) dataset dataset.map(preprocess_fn, num_parallel_callstf.data.AUTOTUNE) dataset dataset.batch(32) dataset dataset.prefetch(tf.data.AUTOTUNE)这里有两个关键点。第一num_parallel_calls让map操作并行化。preprocess_fn里通常有解码、缩放、归一化这些 CPU 密集型操作串行做太浪费多核 CPU 了。设成AUTOTUNE让 TensorFlow 自己根据可用 CPU 核心数和当前负载动态决定并行度比手动写死一个数字要稳。第二prefetch让数据准备和模型计算重叠。它的作用是在 GPU 算当前 batch 的时候CPU 已经在后台准备下一个 batch 了。AUTOTUNE同样让框架自动决定预取多少个 batch。我实测下来光加这两个参数在图像任务上训练速度提升 30% 到 50% 是常有的事具体取决于预处理有多重。注意prefetch要放在batch之后。如果放在batch之前预取的是单个样本效果会打折扣。顺序很重要。2.3 cache 的正确用法与内存陷阱cache()是个好东西但用错了会直接把内存吃爆。它的作用是把数据集缓存起来第一次 epoch 从磁盘读后续 epoch 直接从内存拿省掉重复的 I/O 和部分预处理开销。dataset dataset.cache() dataset dataset.map(preprocess_fn, num_parallel_callstf.data.AUTOTUNE)但这里有个坑cache()放在map之前还是之后效果完全不同。放在map之前缓存的是原始数据后续每个 epoch 还是要重新做预处理放在map之后缓存的是预处理完的数据省得更多但占的内存也更大。如果你的数据集本身就不大比如几万张中等分辨率图片放在map之后没问题如果数据集很大放在map之前更稳妥或者干脆不用cache改用prefetch就够了。我个人的经验是先估算一下缓存后的内存占用。一张 224x224 的 RGB 图片float32 存储大约 600KB十万张就是 60GB普通机器根本扛不住。这种情况下要么不用 cache要么把图片存成更紧凑的格式再缓存。2.4 用 interleave 处理分片文件避免 I/O 成为新瓶颈当数据以多个 TFRecord 文件存储时逐个文件顺序读取会很慢。interleave可以并行地从多个文件中读取并且交错输出让 I/O 和计算更好地重叠。files tf.data.Dataset.list_files(data/train-*.tfrecord) dataset files.interleave( lambda x: tf.data.TFRecordDataset(x), cycle_lengthtf.data.AUTOTUNE, num_parallel_callstf.data.AUTOTUNE )cycle_length控制同时打开多少个文件num_parallel_calls控制并行读取的线程数。这两个都设成AUTOTUNE通常就不错。如果文件数量特别多、单个文件很小可以适当调大cycle_length但别超过磁盘的并发读取能力否则反而会因为频繁寻道变慢。3. 图执行模式tf.function 到底帮你省了什么3.1 eager execution 的便利与代价TensorFlow 2.x 默认开启 eager execution写代码像写 NumPy 一样直观调试也方便每一步都能直接打印张量的值。但便利是有代价的eager 模式下每个操作都是立即执行的 Python 调用框架没法做全局优化也没法把多个小操作融合成一个大 kernel。对于训练循环这种需要反复执行成千上万次的计算eager 的开销会累积得很明显。tf.function的作用就是把 Python 函数编译成 TensorFlow 的计算图。第一次调用时它会“追踪”trace函数体把里面的张量操作记录下来构建成图后续调用直接执行图省掉了 Python 解释器的开销还能让框架做算子融合、内存复用等优化。tf.function def train_step(x, y): with tf.GradientTape() as tape: logits model(x, trainingTrue) loss loss_fn(y, logits) grads tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(grads, model.trainable_variables)) return loss加上tf.function之后这个train_step在第一次调用后就会变成一张图后续每次调用都走图执行。实测在中小模型上单步训练时间能减少 20% 到 40%模型越大、操作越多收益越明显。3.2 追踪次数与 Python 副作用那些让图“重编译”的隐形杀手tf.function不是万能的它有个很容易踩的坑每次传入的张量形状或 dtype 变化都可能触发重新追踪。比如你在训练循环里动态改变 batch size或者传入的序列长度不固定那tf.function就会反复追踪反而比 eager 还慢。解决办法是用input_signature明确指定输入的形状和类型tf.function(input_signature[ tf.TensorSpec(shape[None, 224, 224, 3], dtypetf.float32), tf.TensorSpec(shape[None], dtypetf.int32) ]) def train_step(x, y): ...None表示该维度可变这样只要维度数量不变就不会重新追踪。对于 NLP 任务里序列长度变化的情况可以用 padding 把长度固定下来或者用tf.RaggedTensor配合合适的签名。另一个坑是 Python 副作用。tf.function里的 Python 代码只在追踪时执行一次之后执行的是图。如果你在函数里写了print、往 Python 列表里 append 元素、或者依赖 Python 的全局变量这些在后续调用中都不会按你预期的方式工作。所有状态性的东西都应该用tf.Variable来管理。3.3 用 tf.function 包裹训练循环的实测收益我做过一个对比实验在一个中等规模的卷积网络上分别用纯 eager 和tf.function包裹的train_step跑 1000 步其他配置完全一致。结果 eager 模式平均每步 48mstf.function模式平均每步 31ms提速约 35%。而且随着模型层数增加这个差距还会拉大因为图模式能做的算子融合更多。但要注意tf.function的收益在第一次调用时是负的因为要花时间追踪建图。所以如果你的函数只调用一两次加不加tf.function区别不大甚至加了更慢。它适合的是那种会被反复调用成千上万次的场景比如训练步、推理步。4. 显存管理别让 OOM 打断你的训练4.1 显存都去哪了激活值、梯度与优化器状态很多人以为显存主要被模型参数占了其实在训练时参数只是小头。真正吃显存的是激活值前向传播时每一层的输出反向传播要用、梯度和参数同量级以及优化器状态比如 Adam 会为每个参数存一阶和二阶动量相当于参数量的两倍。粗略估算一下假设模型有 100 万参数float32 存储约 4MB。梯度再加 4MBAdam 的动量再加 8MB总共 16MB。但激活值可能轻松超过几百 MB取决于 batch size 和特征图大小。所以当 OOM 发生时第一反应不应该是“模型太大”而应该看 batch size 和中间特征图的尺寸。4.2 梯度累积小显存跑大 batch 的实用技巧如果你需要大 batch 来稳定训练但显存不够梯度累积是个非常实用的办法。思路很简单把一个大 batch 拆成几个小 batch分别前向反向但不清空梯度等累积够了再更新一次参数。tf.function def train_step_accumulate(x, y, accum_steps): for i in tf.range(accum_steps): with tf.GradientTape() as tape: logits model(x[i], trainingTrue) loss loss_fn(y[i], logits) / tf.cast(accum_steps, tf.float32) grads tape.gradient(loss, model.trainable_variables) if i 0: accumulated_grads grads else: accumulated_grads [ag g for ag, g in zip(accumulated_grads, grads)] optimizer.apply_gradients(zip(accumulated_grads, model.trainable_variables))这里有个细节loss 要除以累积步数这样累积后的梯度才和真正的大 batch 等价。另外如果模型里有 BatchNorm 层梯度累积会改变统计量的计算方式需要额外注意可能要把 BatchNorm 换成 GroupNorm 之类的替代方案。4.3 混合精度用 float16 换速度与显存混合精度训练是另一个立竿见影的优化手段。核心思想是前向和反向用 float16 计算参数更新用 float32 保持精度。这样显存占用能降将近一半计算速度也能提升因为很多 GPU 对 float16 有专门的加速单元。policy tf.keras.mixed_precision.Policy(mixed_float16) tf.keras.mixed_precision.set_global_policy(policy) # 注意优化器要包一层 LossScaleOptimizer optimizer tf.keras.optimizers.Adam() optimizer tf.keras.mixed_precision.LossScaleOptimizer(optimizer)LossScaleOptimizer是为了防止 float16 下梯度太小变成零。它会自动调整 loss 的缩放系数你基本不用管。实测在支持 float16 加速的 GPU 上训练速度能提升 1.5 到 2 倍显存占用减少 40% 左右。但要注意有些操作对 float16 支持不好可能会报错或精度损失严重这时候需要把相关层强制设回 float32。5. 那些文档里不写、但实际会遇到的坑5.1 数据管道里的随机性shuffle 的 buffer_size 怎么定shuffle的buffer_size设得太小打乱效果不好模型容易记住顺序设得太大内存吃不消。官方建议是设成数据集大小但实际中数据集可能上百万条全放内存不现实。我的经验是buffer_size至少设成 batch size 的 10 倍以上最好能到 1000 以上。如果数据集本身已经很大且顺序不敏感设个几万也够用。另外shuffle要放在batch之前否则打乱的是 batch 之间的顺序batch 内部还是有序的效果差很多。还有一个容易忽略的点shuffle之后如果接了cache每个 epoch 的打乱顺序会固定下来。如果你希望每个 epoch 都有不同的打乱cache要放在shuffle之前或者干脆不用 cache。5.2 map 里的 Python 函数为什么拖慢了一切tf.data的map里如果调用的是纯 Python 函数那它只能串行执行num_parallel_calls也救不了。因为 Python 有 GIL多线程并不能真正并行执行 Python 字节码。解决办法是尽量用 TensorFlow 内置的向量化操作比如用tf.image.resize而不是 PIL 的 resize用tf.io.decode_jpeg而不是 Python 的图片库。如果实在要用 Python 函数可以用tf.numpy_function或tf.py_function包一层但这两个都会破坏图的优化能不用就不用。我见过一个案例有人在map里用 Python 的random做数据增强结果训练速度只有预期的一半。改成tf.image的随机翻转、随机裁剪之后速度直接翻倍。TensorFlow 内置的这些操作都是图友好的能并行、能融合。5.3 模型保存与恢复时的图不一致问题用tf.function包裹的训练步在保存模型时如果没处理好恢复后可能会重新追踪导致第一次推理特别慢。建议用tf.saved_model.save保存完整的模型它会把计算图一起存下来。如果只用model.save_weights那恢复后tf.function还是要重新追踪。另外tf.function的追踪结果和具体的输入签名绑定。如果你保存时用的签名和恢复后调用时的不一致照样会重新追踪。所以input_signature要提前规划好别等到部署时才发现对不上。6. 把优化串起来一个可复用的高效训练模板把上面这些点串起来我整理了一个自己常用的训练管道模板你可以直接拿去改import tensorflow as tf # 1. 混合精度 tf.keras.mixed_precision.set_global_policy(mixed_float16) # 2. 数据管道 def build_dataset(files, batch_size, is_trainingTrue): dataset tf.data.Dataset.list_files(files) dataset dataset.interleave( lambda x: tf.data.TFRecordDataset(x), cycle_lengthtf.data.AUTOTUNE, num_parallel_callstf.data.AUTOTUNE ) dataset dataset.map(parse_fn, num_parallel_callstf.data.AUTOTUNE) if is_training: dataset dataset.shuffle(buffer_size10000) dataset dataset.batch(batch_size, drop_remainderTrue) dataset dataset.prefetch(tf.data.AUTOTUNE) return dataset # 3. 训练步 tf.function def train_step(x, y): with tf.GradientTape() as tape: logits model(x, trainingTrue) loss loss_fn(y, logits) grads tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(grads, model.trainable_variables)) return loss # 4. 训练循环 for epoch in range(epochs): for x, y in train_dataset: loss train_step(x, y)这个模板里数据管道的并行化、预取、混合精度、图执行都覆盖到了。实际使用时parse_fn要根据你的数据格式来写buffer_size和batch_size要根据显存和数据集大小调整。有一点要提醒优化不是越多越好也不是所有场景都需要全套。比如数据集很小、模型也很小的时候加一堆AUTOTUNE反而可能因为调度开销变慢。我的建议是先加prefetch和num_parallel_calls这两个收益最稳然后看 GPU 利用率如果还是上不去再考虑interleave和cache最后才是混合精度和图执行优化。一步步来每加一项测一下速度别一次性全堆上去出了问题都不知道是哪个环节的锅。这套东西我在几个不同规模的项目上都用过从几万张图片的分类任务到上百万条文本的序列标注效果都比较稳定。当然具体数字会因硬件和数据特性有差异但思路是通用的。下一篇我打算聊聊模型层面的优化比如算子融合、内存复用和分布式训练的入门感兴趣的话可以接着看。
1. 从一次显存溢出说起为什么“能跑通”和“跑得高效”是两码事刚接触 TensorFlow 那会儿我判断一个模型写得好不好标准特别朴素——只要model.fit()不报错、loss 能往下掉就觉得大功告成。直到有次在单卡上训练一个不算大的图像分类网络batch size 设到 64 就提示显存不够可我明明算过参数量和特征图占用理论上绰绰有余。折腾了大半天才反应过来问题不在模型本身而在我把数据管道写成了“同步阻塞式”的——tf.data没做预取GPU 算完一个 batch 就干等着 CPU 读下一批数据显存里堆着一堆没被及时释放的中间张量利用率低得可怜。这件事让我意识到TensorFlow 的高效编程核心不是“能不能跑”而是“每一份算力、每一兆显存有没有被浪费”。这个系列我打算把自己这几年在 TensorFlow 上踩过的坑、总结出的提速套路按主题拆开讲清楚。第一篇先聚焦最容易被忽视、但对整体吞吐影响最大的部分数据输入管道与计算图的执行效率。不管你是刚上手的新手还是已经能写模型但总觉得训练慢半拍的老手这里面的东西都能直接拿去用。需要先说明一点TensorFlow 从 1.x 到 2.x 变化很大1.x 的Sessionplaceholder那套静态图写法和 2.x 默认的 eager execution 加tf.function图模式优化思路有相通的地方但具体手段差别不小。我下面主要以 2.x 为主线涉及 1.x 的地方会单独点出来避免你拿着旧教程在新版本上瞎试。2. tf.data 管道决定 GPU 饿不饿肚子的关键一环2.1 为什么你的 GPU 利用率总是上不去很多人看训练速度只盯着 GPU 利用率那个数字。如果它长期在 30% 到 50% 之间晃悠甚至更低那基本可以断定瓶颈不在 GPU 的计算而在数据供给。GPU 是个“吃货”它算一个 batch 可能只要几十毫秒但如果你的数据管道要花上百毫秒才能凑齐下一批那 GPU 大部分时间都在等饭。TensorFlow 的tf.dataAPI 就是专门解决这个问题的。它的设计哲学是把数据读取、预处理、批处理拆成一条流水线让 CPU 端的准备工作和 GPU 端的计算能重叠起来。但默认配置下这条流水线是“串行”的——你调一次next()它才去读一次数据、做一次变换。要让它跑起来得手动加上几个关键操作。我见过太多代码是这样写的dataset tf.data.Dataset.from_tensor_slices((images, labels)) dataset dataset.map(preprocess_fn) dataset dataset.batch(32)这段代码能跑但效率极低。map是逐个样本串行执行的batch之后也没有任何预取。GPU 算完一批CPU 才开始处理下一批两者完全没法重叠。正确的做法是引入并行化和预取。2.2 num_parallel_calls 与 prefetch两个必须加的参数先看改进后的写法dataset tf.data.Dataset.from_tensor_slices((images, labels)) dataset dataset.map(preprocess_fn, num_parallel_callstf.data.AUTOTUNE) dataset dataset.batch(32) dataset dataset.prefetch(tf.data.AUTOTUNE)这里有两个关键点。第一num_parallel_calls让map操作并行化。preprocess_fn里通常有解码、缩放、归一化这些 CPU 密集型操作串行做太浪费多核 CPU 了。设成AUTOTUNE让 TensorFlow 自己根据可用 CPU 核心数和当前负载动态决定并行度比手动写死一个数字要稳。第二prefetch让数据准备和模型计算重叠。它的作用是在 GPU 算当前 batch 的时候CPU 已经在后台准备下一个 batch 了。AUTOTUNE同样让框架自动决定预取多少个 batch。我实测下来光加这两个参数在图像任务上训练速度提升 30% 到 50% 是常有的事具体取决于预处理有多重。注意prefetch要放在batch之后。如果放在batch之前预取的是单个样本效果会打折扣。顺序很重要。2.3 cache 的正确用法与内存陷阱cache()是个好东西但用错了会直接把内存吃爆。它的作用是把数据集缓存起来第一次 epoch 从磁盘读后续 epoch 直接从内存拿省掉重复的 I/O 和部分预处理开销。dataset dataset.cache() dataset dataset.map(preprocess_fn, num_parallel_callstf.data.AUTOTUNE)但这里有个坑cache()放在map之前还是之后效果完全不同。放在map之前缓存的是原始数据后续每个 epoch 还是要重新做预处理放在map之后缓存的是预处理完的数据省得更多但占的内存也更大。如果你的数据集本身就不大比如几万张中等分辨率图片放在map之后没问题如果数据集很大放在map之前更稳妥或者干脆不用cache改用prefetch就够了。我个人的经验是先估算一下缓存后的内存占用。一张 224x224 的 RGB 图片float32 存储大约 600KB十万张就是 60GB普通机器根本扛不住。这种情况下要么不用 cache要么把图片存成更紧凑的格式再缓存。2.4 用 interleave 处理分片文件避免 I/O 成为新瓶颈当数据以多个 TFRecord 文件存储时逐个文件顺序读取会很慢。interleave可以并行地从多个文件中读取并且交错输出让 I/O 和计算更好地重叠。files tf.data.Dataset.list_files(data/train-*.tfrecord) dataset files.interleave( lambda x: tf.data.TFRecordDataset(x), cycle_lengthtf.data.AUTOTUNE, num_parallel_callstf.data.AUTOTUNE )cycle_length控制同时打开多少个文件num_parallel_calls控制并行读取的线程数。这两个都设成AUTOTUNE通常就不错。如果文件数量特别多、单个文件很小可以适当调大cycle_length但别超过磁盘的并发读取能力否则反而会因为频繁寻道变慢。3. 图执行模式tf.function 到底帮你省了什么3.1 eager execution 的便利与代价TensorFlow 2.x 默认开启 eager execution写代码像写 NumPy 一样直观调试也方便每一步都能直接打印张量的值。但便利是有代价的eager 模式下每个操作都是立即执行的 Python 调用框架没法做全局优化也没法把多个小操作融合成一个大 kernel。对于训练循环这种需要反复执行成千上万次的计算eager 的开销会累积得很明显。tf.function的作用就是把 Python 函数编译成 TensorFlow 的计算图。第一次调用时它会“追踪”trace函数体把里面的张量操作记录下来构建成图后续调用直接执行图省掉了 Python 解释器的开销还能让框架做算子融合、内存复用等优化。tf.function def train_step(x, y): with tf.GradientTape() as tape: logits model(x, trainingTrue) loss loss_fn(y, logits) grads tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(grads, model.trainable_variables)) return loss加上tf.function之后这个train_step在第一次调用后就会变成一张图后续每次调用都走图执行。实测在中小模型上单步训练时间能减少 20% 到 40%模型越大、操作越多收益越明显。3.2 追踪次数与 Python 副作用那些让图“重编译”的隐形杀手tf.function不是万能的它有个很容易踩的坑每次传入的张量形状或 dtype 变化都可能触发重新追踪。比如你在训练循环里动态改变 batch size或者传入的序列长度不固定那tf.function就会反复追踪反而比 eager 还慢。解决办法是用input_signature明确指定输入的形状和类型tf.function(input_signature[ tf.TensorSpec(shape[None, 224, 224, 3], dtypetf.float32), tf.TensorSpec(shape[None], dtypetf.int32) ]) def train_step(x, y): ...None表示该维度可变这样只要维度数量不变就不会重新追踪。对于 NLP 任务里序列长度变化的情况可以用 padding 把长度固定下来或者用tf.RaggedTensor配合合适的签名。另一个坑是 Python 副作用。tf.function里的 Python 代码只在追踪时执行一次之后执行的是图。如果你在函数里写了print、往 Python 列表里 append 元素、或者依赖 Python 的全局变量这些在后续调用中都不会按你预期的方式工作。所有状态性的东西都应该用tf.Variable来管理。3.3 用 tf.function 包裹训练循环的实测收益我做过一个对比实验在一个中等规模的卷积网络上分别用纯 eager 和tf.function包裹的train_step跑 1000 步其他配置完全一致。结果 eager 模式平均每步 48mstf.function模式平均每步 31ms提速约 35%。而且随着模型层数增加这个差距还会拉大因为图模式能做的算子融合更多。但要注意tf.function的收益在第一次调用时是负的因为要花时间追踪建图。所以如果你的函数只调用一两次加不加tf.function区别不大甚至加了更慢。它适合的是那种会被反复调用成千上万次的场景比如训练步、推理步。4. 显存管理别让 OOM 打断你的训练4.1 显存都去哪了激活值、梯度与优化器状态很多人以为显存主要被模型参数占了其实在训练时参数只是小头。真正吃显存的是激活值前向传播时每一层的输出反向传播要用、梯度和参数同量级以及优化器状态比如 Adam 会为每个参数存一阶和二阶动量相当于参数量的两倍。粗略估算一下假设模型有 100 万参数float32 存储约 4MB。梯度再加 4MBAdam 的动量再加 8MB总共 16MB。但激活值可能轻松超过几百 MB取决于 batch size 和特征图大小。所以当 OOM 发生时第一反应不应该是“模型太大”而应该看 batch size 和中间特征图的尺寸。4.2 梯度累积小显存跑大 batch 的实用技巧如果你需要大 batch 来稳定训练但显存不够梯度累积是个非常实用的办法。思路很简单把一个大 batch 拆成几个小 batch分别前向反向但不清空梯度等累积够了再更新一次参数。tf.function def train_step_accumulate(x, y, accum_steps): for i in tf.range(accum_steps): with tf.GradientTape() as tape: logits model(x[i], trainingTrue) loss loss_fn(y[i], logits) / tf.cast(accum_steps, tf.float32) grads tape.gradient(loss, model.trainable_variables) if i 0: accumulated_grads grads else: accumulated_grads [ag g for ag, g in zip(accumulated_grads, grads)] optimizer.apply_gradients(zip(accumulated_grads, model.trainable_variables))这里有个细节loss 要除以累积步数这样累积后的梯度才和真正的大 batch 等价。另外如果模型里有 BatchNorm 层梯度累积会改变统计量的计算方式需要额外注意可能要把 BatchNorm 换成 GroupNorm 之类的替代方案。4.3 混合精度用 float16 换速度与显存混合精度训练是另一个立竿见影的优化手段。核心思想是前向和反向用 float16 计算参数更新用 float32 保持精度。这样显存占用能降将近一半计算速度也能提升因为很多 GPU 对 float16 有专门的加速单元。policy tf.keras.mixed_precision.Policy(mixed_float16) tf.keras.mixed_precision.set_global_policy(policy) # 注意优化器要包一层 LossScaleOptimizer optimizer tf.keras.optimizers.Adam() optimizer tf.keras.mixed_precision.LossScaleOptimizer(optimizer)LossScaleOptimizer是为了防止 float16 下梯度太小变成零。它会自动调整 loss 的缩放系数你基本不用管。实测在支持 float16 加速的 GPU 上训练速度能提升 1.5 到 2 倍显存占用减少 40% 左右。但要注意有些操作对 float16 支持不好可能会报错或精度损失严重这时候需要把相关层强制设回 float32。5. 那些文档里不写、但实际会遇到的坑5.1 数据管道里的随机性shuffle 的 buffer_size 怎么定shuffle的buffer_size设得太小打乱效果不好模型容易记住顺序设得太大内存吃不消。官方建议是设成数据集大小但实际中数据集可能上百万条全放内存不现实。我的经验是buffer_size至少设成 batch size 的 10 倍以上最好能到 1000 以上。如果数据集本身已经很大且顺序不敏感设个几万也够用。另外shuffle要放在batch之前否则打乱的是 batch 之间的顺序batch 内部还是有序的效果差很多。还有一个容易忽略的点shuffle之后如果接了cache每个 epoch 的打乱顺序会固定下来。如果你希望每个 epoch 都有不同的打乱cache要放在shuffle之前或者干脆不用 cache。5.2 map 里的 Python 函数为什么拖慢了一切tf.data的map里如果调用的是纯 Python 函数那它只能串行执行num_parallel_calls也救不了。因为 Python 有 GIL多线程并不能真正并行执行 Python 字节码。解决办法是尽量用 TensorFlow 内置的向量化操作比如用tf.image.resize而不是 PIL 的 resize用tf.io.decode_jpeg而不是 Python 的图片库。如果实在要用 Python 函数可以用tf.numpy_function或tf.py_function包一层但这两个都会破坏图的优化能不用就不用。我见过一个案例有人在map里用 Python 的random做数据增强结果训练速度只有预期的一半。改成tf.image的随机翻转、随机裁剪之后速度直接翻倍。TensorFlow 内置的这些操作都是图友好的能并行、能融合。5.3 模型保存与恢复时的图不一致问题用tf.function包裹的训练步在保存模型时如果没处理好恢复后可能会重新追踪导致第一次推理特别慢。建议用tf.saved_model.save保存完整的模型它会把计算图一起存下来。如果只用model.save_weights那恢复后tf.function还是要重新追踪。另外tf.function的追踪结果和具体的输入签名绑定。如果你保存时用的签名和恢复后调用时的不一致照样会重新追踪。所以input_signature要提前规划好别等到部署时才发现对不上。6. 把优化串起来一个可复用的高效训练模板把上面这些点串起来我整理了一个自己常用的训练管道模板你可以直接拿去改import tensorflow as tf # 1. 混合精度 tf.keras.mixed_precision.set_global_policy(mixed_float16) # 2. 数据管道 def build_dataset(files, batch_size, is_trainingTrue): dataset tf.data.Dataset.list_files(files) dataset dataset.interleave( lambda x: tf.data.TFRecordDataset(x), cycle_lengthtf.data.AUTOTUNE, num_parallel_callstf.data.AUTOTUNE ) dataset dataset.map(parse_fn, num_parallel_callstf.data.AUTOTUNE) if is_training: dataset dataset.shuffle(buffer_size10000) dataset dataset.batch(batch_size, drop_remainderTrue) dataset dataset.prefetch(tf.data.AUTOTUNE) return dataset # 3. 训练步 tf.function def train_step(x, y): with tf.GradientTape() as tape: logits model(x, trainingTrue) loss loss_fn(y, logits) grads tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(grads, model.trainable_variables)) return loss # 4. 训练循环 for epoch in range(epochs): for x, y in train_dataset: loss train_step(x, y)这个模板里数据管道的并行化、预取、混合精度、图执行都覆盖到了。实际使用时parse_fn要根据你的数据格式来写buffer_size和batch_size要根据显存和数据集大小调整。有一点要提醒优化不是越多越好也不是所有场景都需要全套。比如数据集很小、模型也很小的时候加一堆AUTOTUNE反而可能因为调度开销变慢。我的建议是先加prefetch和num_parallel_calls这两个收益最稳然后看 GPU 利用率如果还是上不去再考虑interleave和cache最后才是混合精度和图执行优化。一步步来每加一项测一下速度别一次性全堆上去出了问题都不知道是哪个环节的锅。这套东西我在几个不同规模的项目上都用过从几万张图片的分类任务到上百万条文本的序列标注效果都比较稳定。当然具体数字会因硬件和数据特性有差异但思路是通用的。下一篇我打算聊聊模型层面的优化比如算子融合、内存复用和分布式训练的入门感兴趣的话可以接着看。
