深度学习这件事说穿了就是把数据喂进一张计算图里让它在误差反馈中一点点把参数调对。TensorFlow 是这套流程里最主流的一套工具箱之一它把张量运算、自动求导、模型封装、导出部署串成了一条完整的链路。但真正动手的人知道这条链路上布满岔路口装哪个版本、Keras 用几、数据管道怎么写才不拖后腿、loss 卡住不动时从哪查、训完怎么交付给工程侧。我这次围绕如何使用 TensorFlow 进行深度学习这条主线把环境搭建、数据管道、模型组织、训练调参、导出部署、线上排障这六个环节里我踩过和见过的坑全盘出来讲一遍。刚入门的人可以顺着步骤抄作业做过一两个项目、总觉得模型训得慢或者训不稳的人重点看数据管道和训练循环那两节大概率能找到对症的东西。1. 环境这口气先理顺能省掉一半玄学问题装环境这一步看着枯燥但后面九成的“玄学报错”都从这里埋下伏笔。我见过太多人上来就pip install tensorflow然后对着显卡不识别、算子找不到、Keras 版本冲突折腾一个下午。这一节把版本、隔离、验证三件事说清楚。1.1 Python 版本、TensorFlow 版本与显卡驱动的三角关系TensorFlow 的版本不是独立的它卡在一个三角关系里TensorFlow 版本决定它支持的 Python 版本范围也决定它编译时用的 CUDA 与 cuDNN 版本。举个实操层面的例子较新的 2.15 分支对 Python 3.9 到 3.11 支持比较稳而更新的大版本在包结构上做了调整默认捆绑了新一代 Keras很多老代码里tf.keras的写法行为会变部分只存在于旧 Keras 里的接口需要额外装兼容包才能用。我的建议很直接新项目先锁一个成熟的小版本不要追最新。锁定版本的理由不是保守而是可复现。你今天在本地跑通的脚本明天在另一台机器或另一个容器里要能跑出同样的结果版本漂移是最大的敌人。生产侧的镜像更是如此一旦定版除非有明确的安全或性能需求否则不要轻易动。还有一类高频问题出在显卡支持上。不同版本对 GPU 的支持策略改过几次某些平台的原生 GPU 支持已经停止只能走 WSL 或者容器。如果你在本地装完tf.config.list_physical_devices(GPU)返回空列表先别怀疑代码按这个顺序查驱动版本是否满足该 TensorFlow 版本要求、CUDA 运行时是否在动态库搜索路径里、有没有装对应版本的 cuDNN。提示查版本对应关系时以官方安装页的表格为准不要相信博客里的二手信息那些文章往往停留在两三年前。1.2 虚拟环境隔离别在系统解释器里折腾虚拟环境这一步没有任何妥协空间。系统 Python 里装的包被多个项目共用一旦某个项目需要降版本另一个项目就跟着崩。我用 conda 管环境原因是它对非 Python 依赖比如 CUDA 运行库的处理比纯 pip 温和。conda create -n tfdl python3.10 -y conda activate tfdl pip install tensorflow2.15.0 pip install tensorflow-datasets matplotlib pandas scikit-learn为什么选 3.10 而不是更新的版本因为生态里大量第三方库尤其是做可视化和数据处理的对最新 Python 的支持总是滞后几个月你用一个太新的解释器等于把自己放在生态的边缘位置上报错信息会变得很难搜。装完先别急着写模型跑一个自检脚本把版本、设备、显存策略一次性确认掉import tensorflow as tf print(TF:, tf.__version__) print(Built with CUDA:, tf.test.is_built_with_cuda()) print(Physical GPUs:, tf.config.list_physical_devices(GPU)) # 按需增长避免一上来就吃掉整张卡 for gpu in tf.config.list_physical_devices(GPU): tf.config.experimental.set_memory_growth(gpu, True) # 确认矩阵乘法能跑在卡上 with tf.device(/GPU:0): a tf.random.normal((1024, 1024)) b tf.random.normal((1024, 1024)) c tf.matmul(a, b) print(device of result:, c.device)set_memory_growth(True)这一行值得单独说。TensorFlow 默认会一次性申请几乎全部显存理由是减少碎片和重复分配开销但代价是你没法在同一张卡上并行跑两个实验也没法在 Jupyter 里边调边看显存曲线。开了按需增长以后显存是按实际用量线性涨的调试体验好很多。代价是极少数场景下有轻微的分配抖动但绝大多数训练任务感知不到。1.3 别忽视 CPU 侧的线程配置一个容易被忽略的点数据管道跑在 CPU 上图像解码、增强、批处理全靠它。如果你在容器里跑训练容器默认可能只看到很少的核或者tf.data的并行度被限制结果就是显卡利用率长期在 30% 上下晃训练时间白白翻倍。print(logical cpus:, len(tf.config.list_logical_devices(CPU))) print(intra-op threads:, tf.config.threading.get_intra_op_parallelism_threads()) print(inter-op threads:, tf.config.threading.get_inter_op_parallelism_threads())intra_op控制单个算子内部的并行度比如一次大矩阵乘怎么切分inter_op控制互不依赖的算子之间的并行度。默认值是 0表示由运行时自己决定。在独占机器的训练场景里我一般会让intra_op等于物理核数、inter_op给 2 到 4理由是一次大算子拆太细反而增加同步开销而算子之间的并发度受限于图结构给太多也是空转。2. 张量与数据管道真正决定训练速度的地方很多人第一次跑 TensorFlow注意力全在模型结构上觉得网络设计得好精度就高。实际做过几个项目就会发现模型结构在主流任务上已经高度同质化真正拉开差距的是数据怎么进、进来以后长什么样。2.1 用张量思维起步而不是从层开始TensorFlow 的最小单位是张量两个属性最要命shape和dtype。我见过最典型的一类 bug 是标签的 dtype 变成了float32而损失函数期望整型报错信息还很绕绕到人怀疑人生。另一类是 NumPy 默认给float64混进模型以后触发隐式类型转换速度掉一截而且警告刷屏。x tf.random.normal((32, 224, 224, 3)) y tf.constant([0, 1, 2] * 10, dtypetf.int32) print(x.shape, x.dtype) # (32, 224, 224, 3) float32 print(y.shape, y.dtype) # (30,) int32 # 形状断言把问题挡在训练之前 tf.debugging.assert_shapes([(x, (N, 224, 224, 3))])assert_shapes这个工具在排查“某个维度悄悄变了”的问题时非常好用尤其是你自己写了自定义层或者用了多输入模型某一层把通道数改了却没报错最后在Dense那里才炸。把断言提前报错位置就能精准到源头。张量和 NumPy 数组最大的区别在于不可变性和设备归属。张量一旦创建就不能原地改内容所有操作返回新张量——这个设计最初让很多人不适应但它让自动求导和设备调度变得可控。另外张量知道自己躺在那块设备上c.device能直接打出来这在手写训练循环时排查“为什么这一步慢”非常关键如果是/CPU:0说明你的设备作用域没生效。2.2 tf.data 的四个开关cache、shuffle、map、prefetchtf.data是整个 TensorFlow 里性价比最高的模块写好这四行训练吞吐能差出三倍。但它对顺序很敏感顺序错了不但不提速还会引入隐蔽的正确性问题。def build_ds(paths, labels, batch_size32, trainingTrue): ds tf.data.Dataset.from_tensor_slices((paths, labels)) if training: ds ds.shuffle(buffer_sizelen(paths), seed42) ds ds.map(load_and_augment, num_parallel_callstf.data.AUTOTUNE) if not training: ds ds.cache() # 验证集缓存每个 epoch 复用解码结果 ds ds.batch(batch_size, drop_remaindertraining) ds ds.prefetch(tf.data.AUTOTUNE) return ds几个关键决策的逻辑我拆开说。shuffle的buffer_size决定了随机性的真实程度。数据管道是流式的它没法真的把全量数据打乱再发只能在一个滑动缓冲区内做局部打乱。如果buffer_size远小于数据集大小那你每个 epoch 看到的样本顺序仍然是高度相关的模型会学到这种顺序带来的偏差表现为验证集指标抖动大、收敛不稳。实操上buffer_size至少给到几千最好等于数据集大小内存扛得住的话。cache的位置极讲究。放在map之后意味着增强后的结果被缓存了那么每个 epoch 拿到的“随机”增强其实是同一份——训练变成了对固定增强样本的记忆泛化性能会明显下降。放在map之前缓存原始解码结果才是正确用法省掉的是重复的文件读取和解码增强依然每次重算。这个坑我在早期项目里踩过当时现象是训练集精度飞涨、验证集原地踏步查了两天才定位到。prefetch(AUTOTUNE)必须放在管道的最后。它的作用是让 CPU 在 GPU 算当前批次的时候提前准备下一批。少了这一行就是标准的串行流水线GPU 每隔几十毫秒空等一次利用率曲线会呈现规律的锯齿。drop_remainder在训练集上建议开因为最后一个小批次可能只有一两个样本批归一化在这种小批次上统计量非常不稳定会污染整轮的滑动统计。2.3 数据增强放管道里还是放模型里这个问题没有标准答案但有一个明确的判断依据增强逻辑要不要跟着模型一起走。放在tf.keras.layers里作为模型的一部分好处是导出的 SavedModel 自带预处理推理侧不用重新实现一遍端到端一致性有保障。代价是增强在 GPU 上算占显存也占算力。而且要注意这些层在推理时必须处于非训练模式否则你的线上结果会带随机性。放在tf.data的map里好处是不占显存、可以用更复杂的 CPU 侧逻辑比如基于关键点的仿射变换代价是 CPU 可能成为瓶颈而且导出模型时预处理和模型是分离的推理侧必须手动对齐。我的常用折中是归一化和尺寸变换放进模型作为前处理层随机增强放在管道里。理由很实际——归一化一旦两侧不一致线上精度会掉得很离谱而且这种 bug 极其难查随机增强只在训练期存在推理时本来就不需要放管道里不会带来一致性风险。data_aug tf.keras.Sequential([ tf.keras.layers.RandomFlip(horizontal), tf.keras.layers.RandomRotation(0.05), tf.keras.layers.RandomZoom(0.1), ], nameaug) def load_and_augment(path, label): img tf.io.decode_jpeg(tf.io.read_file(path), channels3) img tf.image.resize(img, (224, 224)) img data_aug(img, trainingTrue) return img, label注意RandomFlip这类层在trainingTrue时才生效如果你的自定义训练循环忘了传这个参数增强会静默失效训练看起来“正常”但泛化差排查成本很高。3. 模型搭建的三条路线选错了后面全是返工TensorFlow 提供了三种建模范式很多人纠结用哪个其实判断标准很清晰看你的计算图有没有“分叉”和“动态结构”。3.1 Sequential够快但天花板很低Sequential是最快的上手方式一层接一层往下堆。适合的场景是标准的单向流输入一张图经过若干卷积池化最后接全连接输出。原型阶段我很喜欢用它因为代码短、可读性强、summary()一目了然。model tf.keras.Sequential([ tf.keras.layers.Input(shape(224, 224, 3)), tf.keras.layers.Rescaling(1.0 / 255), tf.keras.layers.Conv2D(32, 3, paddingsame, activationrelu), tf.keras.layers.MaxPooling2D(), tf.keras.layers.Conv2D(64, 3, paddingsame, activationrelu), tf.keras.layers.MaxPooling2D(), tf.keras.layers.GlobalAveragePooling2D(), tf.keras.layers.Dense(128, activationrelu), tf.keras.layers.Dropout(0.3), tf.keras.layers.Dense(10, activationsoftmax, dtypefloat32), ], namesmall_cnn)它的短板在哪没法表达跳连、没法共享层、没法做多输入多输出。你想加一个残差连接Sequential直接无解。所以我的实际策略是原型用 Sequential 验证数据管道通不通确认 feature 和 label 对得上、损失能降然后立刻换 Functional 重写。这个切换成本很低但如果一开始就用 Sequential 搭了个大模型再想改那就得推翻重来。3.2 Functional API八成场景的正解Functional通过“张量进、张量出”的方式把层连成有向图能表达分支、合并、共享。多输入比如图像加元数据、多输出分类加回归的多任务、残差块、特征金字塔全都能写。inputs tf.keras.Input(shape(224, 224, 3), nameimage) x tf.keras.layers.Rescaling(1.0 / 255)(inputs) # 主干 c1 tf.keras.layers.Conv2D(32, 3, paddingsame, activationrelu)(x) p1 tf.keras.layers.MaxPooling2D()(c1) c2 tf.keras.layers.Conv2D(64, 3, paddingsame, activationrelu)(p1) # 旁路把浅层特征下采样后和深层拼起来 skip tf.keras.layers.Conv2D(64, 1, strides2, paddingsame)(p1) fused tf.keras.layers.Concatenate()([c2, skip]) x tf.keras.layers.GlobalAveragePooling2D()(fused) x tf.keras.layers.Dense(128, activationrelu)(x) x tf.keras.layers.Dropout(0.3)(x) outputs tf.keras.layers.Dense(10, activationsoftmax, dtypefloat32, namelogits)(x) model tf.keras.Model(inputs, outputs, namefusion_net) model.summary()这里有个细节值得说明Concatenate要求除拼接轴以外的维度全部一致所以旁路必须做同倍下采样否则会报形状不匹配。这不是 TensorFlow 的限制而是张量拼接的数学要求理解这一点以后写多尺度融合就不会卡。另外值得一提的是参数量计算。一层Conv2D(64, 3)接在 32 通道的输入后面参数量是(3×3×32 1) × 64 18496其中1是偏置。全连接层的参数量是in × out out。这个估算能力在做显存预算时是刚需下面训练那节会用到。3.3 子类化模型留给真正需要动态结构的场景子类化是继承tf.keras.Model并在call里写前向逻辑图是“命令式”构建的灵活度最高能写条件分支、循环、递归。代价是模型结构不能先验推导summary()拿不到完整信息除非你先跑一次build或者传一个假输入调试和序列化都更麻烦。我的判断标准是能用 Functional 表达的一律用 Functional。只有当你的前向过程依赖运行时数据比如根据输入长度决定循环次数或者要在一个call里管理多个子模块的状态子类化才值得。纯粹为了“看起来高级”去用子类化后面导出和可视化时会付出代价。4. 训练循环里的参数每一个都有算法model.fit三行代码就能跑起来但里面的默认值大概率不适合你的任务。这一节把损失函数配对、batch size 与学习率的计算、回调策略讲透。4.1 损失函数和输出层激活必须成对出现这是新手最容易出错的地方而且错了不一定报错只是精度上不去。规则很简单任务类型输出层损失函数备注二分类1 个单元 sigmoidBinaryCrossentropyfrom_logits 要对应多分类one-hot 标签N 个单元 softmaxCategoricalCrossentropy标签需 to_categorical多分类整型标签N 个单元 softmaxSparseCategoricalCrossentropy省内存推荐多分类数值稳定优先N 个单元无激活SparseCategoricalCrossentropy(from_logitsTrue)推理时手动 softmax最后一行的写法值得多说两句。把 softmax 从模型里拿掉让损失函数内部用 logits 直接算数值稳定性明显更好因为log(softmax(x))在 fp16 下很容易溢出而框架内部的 log-sum-exp 实现做了平移处理。代价是推理时你得记得手动加一个 softmax忘记加的话输出就是一堆没有归一化的分数看起来“置信度很低”其实只是少了那一步。model.compile( optimizertf.keras.optimizers.Adam(learning_rate1e-3), losstf.keras.losses.SparseCategoricalCrossentropy(from_logitsTrue), metrics[accuracy], )4.2 batch size、学习率和显存的三方计算这三个量是耦合的定了一个另外两个就得跟着算。我的做法是先从显存反推 batch size 上限再按线性缩放规则定学习率。显存占用的粗算模型是这样的参数侧fp32 权重 4 字节 梯度 4 字节 Adam 的一阶二阶矩各 4 字节合计约 16 字节每参数。一千万参数的模型参数侧约 160MB。如果你用混合精度权重和激活降到 2 字节但优化器状态和主权重仍是 fp32整体能省三到四成。真正吃显存的是激活值它和 batch size、特征图尺寸成正比。一个粗略的经验224 输入、常规 CNN 主干batch32 时激活占用大概在 2 到 4GB 区间具体取决于网络深度和跳连数量。所以如果一张卡是 16GB减掉参数和框架开销batch 大概能给到 32 到 64。学习率按线性缩放基准是 batch32 时 lr1e-3那么 batch 翻四倍到 128lr 给 4e-3。但这条规则在大 batch 下会失效需要配 warmup——前几百步把学习率从接近零线性拉上来避免初期梯度方向不稳把权重带偏。steps_per_epoch len(train_paths) // batch_size warmup_steps min(500, steps_per_epoch) lr_schedule tf.keras.optimizers.schedules.PiecewiseConstantDecay( boundaries[30 * steps_per_epoch, 60 * steps_per_epoch], values[1e-3, 3e-4, 1e-4], )PiecewiseConstantDecay这种分段常数衰减在中小规模任务上很实用说人话就是“前 30 轮用大步走中间 30 轮减速之后微调”。比余弦退火直观也比指数衰减好调因为每一段的学习率你都看得见。4.3 回调函数把“人工盯训练”变成自动决策训练最浪费时间的不是算是人盯着看。三个回调基本能覆盖大部分需求。callbacks [ tf.keras.callbacks.ModelCheckpoint( ckpt/epoch_{epoch:02d}-val_{val_loss:.4f}.keras, monitorval_loss, save_best_onlyTrue, save_weights_onlyFalse, ), tf.keras.callbacks.EarlyStopping( monitorval_loss, patience8, restore_best_weightsTrue, min_delta1e-4, ), tf.keras.callbacks.ReduceLROnPlateau( monitorval_loss, factor0.5, patience3, min_lr1e-6, ), tf.keras.callbacks.TensorBoard(log_dirlogs, histogram_freq1), ]ModelCheckpoint的文件名里带上{val_loss}这个细节很实用训练结束以后光看目录就知道哪个是最好的不用翻日志。设save_best_onlyTrue也避免磁盘被几十个检查点占满。EarlyStopping的patience给多少取决于你的学习率调度。如果配了ReduceLROnPlateaupatience要比它大——因为降学习率以后指标通常还会再改善一轮太早停就浪费了这次改善机会。我给patience8、降 lr 的patience3这样大约能有两次降 lr 的缓冲。restore_best_weightsTrue是必加的。不加的话早停后模型停在“指标已经变差的那一轮”你白训了。实操心得ReduceLROnPlateau的factor别设得太狠。0.1 的降幅看起来干净但在验证集噪声大的任务上容易把学习率一步降死之后再也爬不出来。0.5 更温和多降几次的效果通常比一次降到底好。4.4 混合精度几乎无成本的一次提速混合精度是这几年最划算的优化之一前向和反向用 fp16 算权重主副本仍用 fp32 保存。显存省三成左右在支持张量核心的卡上速度提升一到三倍而且对精度的影响在绝大多数任务上可以忽略。tf.keras.mixed_precision.set_global_policy(mixed_float16)这一行要在建模型之前调用写反了不生效。另外有两个必须注意的点输出层的 dtype 要显式设成 float32。因为 softmax、sigmoid 这类函数在 fp16 下数值范围太窄容易出 nan。上面例子里的Dense(10, activationsoftmax, dtypefloat32)就是在做这件事。损失缩放交给框架。Adam 配混合精度时框架会自动加 loss scaling 处理梯度下溢你不需要手动乘。但如果用自定义优化器就得自己加LossScaleOptimizer包装。opt tf.keras.optimizers.Adam(1e-3) opt tf.keras.mixed_precision.LossScaleOptimizer(opt)4.5 分布式策略什么时候值得上MirroredStrategy单机多卡是最常用的几行代码就能把训练摊到多张卡上。strategy tf.distribute.MirroredStrategy() print(replicas:, strategy.num_replicas_in_sync) with strategy.scope(): model build_model() model.compile(optimizeradam, loss..., metrics[...]) global_batch 32 * strategy.num_replicas_in_sync注意batch_size是全局值每张卡分到的是一份。学习率要按全局 batch 重新换算这就是上面线性缩放规则的用武之地。但分布式不是无脑上。判断标准是单卡训练一次要几小时以上且数据管道跟得上。如果瓶颈在数据侧GPU 利用率已经很低的那些卡加卡只会让它们一起等数据加速比接近 1。我见过团队花两周调分布式最后发现是map没开并行、图像解码全在一个核上跑改成num_parallel_callsAUTOTUNE直接提速两倍多比加卡管用。5. 导出与部署训练完成只是走了一半模型在 Notebook 里能跑和能交给工程侧上线是两件事。这一步出问题的成本最高因为问题往往在上线后才暴露。5.1 导出格式的选型逻辑TensorFlow 生态里主流的导出格式有几种选哪个看落地环境格式适用场景优点限制Keras 格式.keras训练侧存档、迁移结构、权重、优化器状态全带不适合直接给推理服务SavedModel 目录服务端部署、TF Serving自带签名跨语言加载文件多体积大TFLite移动端、端侧设备体积小、启动快算子支持受限ONNX跨框架互通生态广转换可能丢精度训练侧我一般存 Keras 格式因为要能继续训练、要保留优化器状态。交付侧导 SavedModel因为它的签名机制明确规定了输入输出的名字、形状和 dtype工程侧不需要读你的 Python 代码就知道怎么调。model.export(exported/model/1) # 新版导出接口带签名 # 或者 model.save(exported/model_savedmodel)目录名里的1是版本号这是给服务端准备的习惯——推理服务通常按版本目录加载可以平滑切换、灰度回滚。5.2 量化体积和精度的交换端侧部署绕不开量化。三种常见选项差别很大converter tf.lite.TFLiteConverter.from_saved_model(exported/model_savedmodel) # 选项一动态范围量化只量化权重激活在推理时动态量化 converter.optimizations [tf.lite.Optimize.DEFAULT] # 选项二float16 量化权重存 fp16算的时候转回 fp32 converter.target_spec.supported_types [tf.float16] # 选项三全整数量化需要代表性数据集做校准 def rep_ds(): for i in range(100): yield [calib_images[i:i1]] converter.optimizations [tf.lite.Optimize.DEFAULT] converter.representative_dataset rep_ds converter.target_spec.supported_ops [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] converter.inference_input_type tf.uint8 converter.inference_output_type tf.uint8 tflite_model converter.convert() open(model.tflite, wb).write(tflite_model)体积和精度大致的关系动态范围量化体积压到原来的四分之一精度基本不掉float16 同样的压缩比在支持 fp16 的硬件上更快全整数量化能压到八分之一但需要校准集而且精度掉多少完全取决于你的任务对数值敏感程度——图像分类一般掉不到 1 个点检测和分割这类密集预测任务掉得会明显一些。注意用全整数量化时输入的 uint8 取值范围是 0 到 255但你的模型内部如果是Rescaling(1/255)这个缩放会跟着一起转换推理侧千万不要再手动归一化一次否则输出完全错乱。这类 bug 在联调阶段特别隐蔽因为输出看起来“还是个数”只是不准。5.3 推理侧的输入校验清单我做过一次统计线上推理结果对不上训练结果的原因按频率排序是这样的预处理不一致占一半以上、通道顺序不同RGB 和 BGR 搞反、输入图的 resize 插值方式不同、模型处于训练模式导致 BN 用了当前批次统计量、输入 dtype 不匹配导致精度截断。前三个都在预处理层解决办法是把预处理固化进模型让推理侧只负责“把原始像素塞进去”。第四个问题的解法是显式调用model(x, trainingFalse)或者在导出时确保 BN 层的状态已被冻结。第五个问题靠签名里的 dtype 约束来防导出后可以这样检查loaded tf.saved_model.load(exported/model/1) sig loaded.signatures[serving_default] print(sig.structured_input_signature) print(sig.structured_outputs)把这份签名打印出来贴到接口文档里工程侧照着接比口头沟通靠谱得多。6. 排障实录那些让人怀疑人生的时刻这一节是我这些年攒下来的排查路径按现象分类遇到问题按顺序走一遍基本能定位到八九成的原因。6.1 损失不下降按这个顺序查先说结论loss 卡住不动绝大多数情况不是模型不够好而是数据或标签出了问题。我的排查顺序是这样的。第一步关掉所有增强用 16 张训练图过一遍模型看能不能把训练损失打到接近零。如果连 16 张都记不住那模型结构或者损失函数一定有问题——比如输出层单元数和类别数对不上、损失函数和激活函数配错了。这个“过拟合小样本”的测试是最高效的一步几分钟就能排除结构性问题。第二步检查标签和数据的对齐。这是最容易错也最难发现的地方。用tf.data的时候如果你在map里返回了(img, label)但在batch之前做了别的变换顺序很容易错位。最直接的验证方法是把一批数据取出来画图肉眼看图和标签对不对。第三步检查学习率。太大表现为 loss 震荡或直接 nan太小表现为 loss 降得极慢但确实在降。快速判断方法打印前十步的 loss如果几乎一模一样大概率是学习率太小或者梯度被截断了。第四步检查归一化。输入像素是 0 到 255 而模型里没有Rescaling会导致激活值极大、梯度爆炸或者饱和反过来做了两次归一化信号被压到接近零梯度传不回去。现象最可能原因快速验证loss 完全不动学习率过小 / 模型输出被 detach打印梯度范数loss 剧烈震荡学习率过大 / batch 太小lr 降 10 倍重跑loss 变 nanfp16 溢出 / 除零 / 标签越界关混合精度重跑训练 loss 降验证不降数据泄漏反了 / 过拟合 / BN 问题检查划分与增强顺序训练精度异常高标签泄漏特征里含标签/ 重复样本去重后重切分loss 变 nan这一项要额外说一句混合精度是最常见的诱因但主因往往在别处fp16 只是把一个原本就危险的数值放大了。关掉混合精度能跑通不代表问题解决了可能是梯度里存在极大的值被 fp16 的有限范围截断了。建议在关掉混合精度的情况下打开梯度裁剪看看到底是哪一层的梯度炸了。model.compile( optimizertf.keras.optimizers.Adam(1e-3, clipnorm1.0), loss..., metrics[accuracy], )clipnorm1.0会按整个梯度向量的范数做等比缩放比clipvalue逐元素截断更能保持梯度方向。默认给 1.0 是个稳妥的选择如果发现梯度长期贴着这个上限说明学习率确实太大了。6.2 显存不够用从便宜的手段开始试OOM 是训练期最频繁的报错。处理顺序建议按成本从低到高先降 batch再开混合精度再考虑梯度累积最后才动输入分辨率。梯度累积的思路是“小批次多步凑一个大批次”用时间换显存。适合的场景是你确实需要较大的等效 batch 才能稳定训练但显卡装不下。tf.function def train_step(x, y, accum4): with tf.GradientTape() as tape: logits model(x, trainingTrue) loss loss_fn(y, logits) / accum grads tape.gradient(loss, model.trainable_variables) # 这里用简单累加代替优化器状态管理示意流程 return grads accum_grads [tf.zeros_like(v) for v in model.trainable_variables] for step, (x, y) in enumerate(ds): g train_step(x, y) accum_grads [a b for a, b in zip(accum_grads, g)] if (step 1) % 4 0: optimizer.apply_gradients(zip(accum_grads, model.trainable_variables)) accum_grads [tf.zeros_like(v) for v in model.trainable_variables]这段代码要注意一个细节损失要先除以累积步数再求导等价于对大 batch 求平均。如果忘了除等效学习率会被放大四倍训练直接崩。输入分辨率是最后的手段因为它直接影响模型能看到的细节降了可能就学不到小目标了。如果非降不可先降训练分辨率在推理时用稍高的分辨率这叫“训练测试分辨率不一致”技巧对小目标检测有一定帮助但要注意 BN 统计量的偏移。6.3 训练好好的导出后结果对不上这类问题的排查有一套固定流程。先确认两边的输入是不是同一份数据——不是“看起来一样”是数值上逐元素相等。做法是把同一张图分别喂给训练态的模型和导出的模型打印输出的前几个值。训练态输出: [0.12, 0.03, 0.71, ...] 导出后输出: [0.34, 0.29, 0.11, ...]如果差异很大按这个顺序查模型的training参数BN 在训练态用当前批统计量在推理态用滑动统计量这个差异在 batch 小的时候非常明显预处理是否重复或遗漏输入通道顺序图像 resize 的插值算法bilinear和bicubic差异不小尤其是缩小的时候。还有一个隐蔽的点如果模型里有Dropout而你在推理时没关掉训练模式输出会带随机性。验证方法是同一份输入连续跑两次看输出是否完全一致。不一致就说明有随机算子还活着。实操心得把“训练态 vs 导出态”的一致性检查写成一个单元测试每次改模型都跑一遍。这个测试只有二十行代码但拦下的问题价值远超写它的时间。测试的内容很简单——固定随机种子构造一个固定输入比对两次前向的相对误差超过 1e-4 就报错。7. 一点个人体会上面这些内容里如果只能留三条给刚开始用 TensorFlow 做深度学习的人我会留这三条。第一条数据管道的重要性被系统性地低估了。我复盘过自己经手的项目训练慢的原因里超过一半出在数据侧而不是模型侧。养成一个习惯训练的时候开着监控看 GPU 利用率如果它长期低于 80% 且呈锯齿状别急着换模型先去改tf.data的并行度和prefetch。第二条先用小样本把流程跑通再放大。16 张图能不能过拟合是我每次新任务的第一个检查点。这个测试只要几分钟但它能把“结构错误”和“数据错误”这两类问题分开后面的排查方向就明确了。第三条版本锁死环境可复现。深度学习项目里最贵的成本不是算力是时间。花半天配好的环境如果没有写进依赖清单和构建脚本三个月后你想复现结果大概率要重来一遍。我现在每个项目根目录都有一个requirements.txt里面所有包都是精确版本号不是我勤快是被坑怕了。最后补一个容易被忽略的小技巧训练前把tf.config相关的设置、数据集大小、类别分布、模型参数量、预计每轮步数打一份日志到文件里。这一步不花什么时间但当你在两周后回头看一次失败的训练时这份日志能省掉大量的猜测。
