1. 为什么训练监控这件事值得单独拎出来聊搞深度学习训练的人都有一个共同的痛模型跑起来了loss 曲线到底长什么样是正常收敛还是在震荡学习率是不是设大了梯度有没有爆炸这些问题如果只靠终端里刷屏的print日志来判断效率低不说还特别容易漏掉关键信息。尤其是用 MindSpore Transformers 跑大模型微调的时候一次训练动辄几个小时甚至几天你不可能一直盯着终端看。TensorBoard 就是解决这个问题的。它把训练过程中的标量、图像、计算图、参数分布等信息可视化出来你打开浏览器就能实时看到 loss 曲线、学习率变化、吞吐量等关键指标。MindSpore 从早期版本就内置了对 TensorBoard 的支持通过SummaryCollector和SummaryRecord这两个回调机制可以把训练数据写到事件文件中然后用 TensorBoard 直接读取展示。这篇文章面向的是正在用或者准备用 MindSpore Transformers 做模型训练的同学不管你是刚跑通第一个 demo 的新手还是已经在做多卡分布式训练的老手训练监控这块内容都能帮你少踩一些坑。我会从整体设计思路讲起把回调机制、参数配置、实操步骤、常见问题排查都过一遍尽量做到你看完就能直接在自己项目里用起来。2. 整体设计思路与方案选型2.1 为什么选 TensorBoard 而不是其他方案训练监控的工具其实不少TensorBoard、WandB、MLflow、SwanLab 各有各的用法。MindSpore Transformers 默认集成的就是 TensorBoard原因很直接它是本地化的、不需要联网、不需要额外注册账号、不依赖第三方服务。你装好 TensorBoard 的 Python 包训练脚本里加几行配置就能在本地浏览器里看结果。另一个实际考量是 MindSpore 的SummaryCollector本身就是基于 TensorBoard 的事件文件格式设计的。它生成的 summary 文件可以直接被 TensorBoard 解析不需要做任何格式转换。如果你用其他可视化平台反而需要额外写适配层增加了维护成本。当然TensorBoard 也有它的局限比如多实验对比不如 WandB 方便团队协作共享不如云端方案。但对于个人开发者和中小团队来说TensorBoard 的性价比是最高的。你可以在本地同时开多个 TensorBoard 实例分别指向不同的日志目录对比不同实验的效果。2.2 MindSpore 的 Summary 机制是怎么工作的MindSpore 的训练监控核心是两个类SummaryCollector和SummaryRecord。它们的关系可以这样理解——SummaryRecord是底层的数据记录器负责把数据写到磁盘SummaryCollector是上层封装它继承自Callback在训练的不同阶段自动调用SummaryRecord来记录数据。SummaryCollector的工作流程大致是这样的在train或fit开始之前它会在指定的collect_save_dir目录下创建一个子目录默认以时间戳命名然后在训练过程中按照collect_freq设定的频率把模型参数、loss、学习率等信息写入事件文件。训练结束后你把这个目录路径告诉 TensorBoard它就能解析出所有记录的数据。这里有一个关键点SummaryCollector默认只记录一部分信息比如 loss 和部分参数。如果你想记录更多内容比如自定义的评估指标、梯度直方图、计算图等就需要通过custom_callback或者直接用SummaryRecord来扩展。MindSpore Transformers 在training_callback.py里已经做了一些封装但了解底层机制能帮你在需要的时候灵活定制。2.3 在 MindSpore Transformers 中的集成方式MindSpore Transformers 的训练入口通常在run_mindformer.py或者train.py里。它通过配置文件YAML来管理训练参数其中就包括 callbacks 的配置。默认情况下框架会注册一个SummaryCollector回调但具体的记录频率、保存路径、记录内容等参数需要你在 YAML 文件或者命令行里指定。一个典型的配置长这样callbacks: - type: SummaryCollector summary_dir: ./summary_dir collect_freq: 10 collect_specified_data: collect_metric: True collect_train_lineage: True collect_graph: True这段配置的意思是每 10 个 step 记录一次数据记录评估指标、训练血缘信息和计算图。summary_dir是事件文件的保存路径训练结束后你需要把这个路径传给 TensorBoard。需要注意的是MindSpore Transformers 的版本迭代比较快不同版本之间 callbacks 的配置方式可能有差异。比如在 1.0 版本之前很多配置是写在run_mindformer.py的参数里的1.0 之后逐渐迁移到了 YAML 配置文件中。所以你在参考网上的教程时一定要先确认自己的版本号。3. 核心细节解析与实操要点3.1 SummaryCollector 的关键参数逐个拆解SummaryCollector的参数不少但真正影响你日常使用的就那么几个。我把它们分成三类来说基础配置、记录内容配置、性能相关配置。基础配置里最重要的是summary_dir和collect_freq。summary_dir指定事件文件的保存目录建议用一个有意义的名字比如./summary/bert_base_lr2e5这样你后面开多个实验对比的时候不会搞混。collect_freq控制记录频率默认是 10意思是每 10 个 step 记录一次。这个值设太小会导致事件文件膨胀得很快设太大又可能漏掉关键的变化趋势。我的经验是如果训练总步数在 10000 步以内设 10 到 50 都行如果总步数超过 10 万步建议设 100 到 500否则事件文件可能几个 G。记录内容配置主要通过collect_specified_data来控制。它是一个字典常用的键包括参数名作用建议值collect_metric是否记录评估指标Truecollect_train_lineage是否记录训练血缘信息Truecollect_graph是否记录计算图首次调试时 True正式训练 Falsecollect_input_data是否记录输入数据一般 Falsecollect_dataset_graph是否记录数据集图一般 Falsehistogram_regular参数直方图的正则表达式按需设置collect_graph这个参数要特别说一下。开启之后TensorBoard 的 GRAPHS 面板里能看到完整的计算图对调试模型结构很有帮助。但记录计算图会显著增加事件文件的大小和训练启动时间所以正式训练的时候建议关掉。性能相关配置主要是collect_freq和max_num的配合。max_num限制每个指标最多记录多少个数据点默认是 100000。如果你训练步数特别多可以适当调小这个值避免事件文件过大。3.2 自定义监控指标的添加方法框架默认记录的指标有限通常只有 loss 和学习率。如果你想监控更多东西比如梯度范数、参数更新量、自定义的评估指标就需要自己动手扩展。最直接的方式是用SummaryRecord。你可以在训练脚本里创建一个SummaryRecord实例然后在训练循环里手动调用它的add_value方法from mindspore.train.summary import SummaryRecord summary_record SummaryRecord(log_dir./custom_summary) for step, data in enumerate(dataset): loss train_step(data) summary_record.add_value(scalar, custom_loss, loss) if step % 10 0: summary_record.record(step)这里add_value的第一个参数是数据类型scalar、histogram、image等第二个参数是标签名第三个参数是具体的值。record方法负责把缓存的数据刷到磁盘。另一种方式是通过自定义 Callback。MindSpore Transformers 支持在 YAML 里配置自定义回调你只需要继承Callback类在step_end或epoch_end方法里写记录逻辑就行。这种方式的好处是和框架的集成度更高不需要修改训练主循环。注意SummaryRecord实例在使用完毕后必须调用close()方法否则部分数据可能还在缓冲区里没有写入磁盘。我踩过这个坑训练跑完了发现最后几百步的数据丢了就是因为忘了关。3.3 分布式训练下的监控配置多卡训练的时候监控配置有几个额外的坑要注意。首先SummaryCollector默认只在 rank 0 的进程上记录数据其他 rank 不会写事件文件。这是合理的因为所有 rank 的 loss 最终会做 all-reduce记录一份就够了。但如果你需要监控每个 rank 的独立指标比如每张卡的梯度范数就需要手动在每个 rank 上创建SummaryRecord并且把日志目录区分开。其次分布式训练的事件文件路径最好用绝对路径不要用相对路径。因为不同 rank 的工作目录可能不一样相对路径会导致文件写到意想不到的地方。我一般会在配置里写死绝对路径比如/home/user/experiments/exp001/summary。还有一个细节是collect_freq在分布式场景下的行为。由于每个 rank 的 step 计数是同步的所以collect_freq的效果和单卡一致。但如果你用的是流水线并行不同 stage 的 step 计数可能有偏移这时候建议把collect_freq设大一点避免数据点过于密集导致曲线抖动。4. 完整实操流程与关键环节4.1 环境准备与依赖安装在开始之前确认你的环境里已经装好了 MindSpore、MindSpore Transformers 和 TensorBoard。版本兼容性很重要我列一下我测试通过的组合pip install mindspore2.2.0 pip install mindformers1.0.0 pip install tensorboard2.14.0MindSpore 的安装方式取决于你的硬件平台。Ascend 用户建议按照官方文档的指引安装对应的版本GPU 用户可以直接 pip 安装。TensorBoard 的版本不要太新也不要太旧2.14 左右是比较稳的。安装完成后用下面的命令验证一下python -c import mindspore; print(mindspore.__version__) python -c import tensorboard; print(tensorboard.__version__)如果都能正常输出版本号说明环境没问题。4.2 配置文件的修改与参数设置以 MindSpore Transformers 的 BERT 微调为例找到对应的 YAML 配置文件通常在configs/bert目录下在callbacks部分添加或修改SummaryCollector的配置callbacks: - type: SummaryCollector summary_dir: /home/user/experiments/bert_finetune/summary collect_freq: 20 keep_default_action: False collect_specified_data: collect_metric: True collect_train_lineage: True collect_graph: False collect_input_data: False histogram_regular: .*weight.*这里keep_default_action设为 False 表示不保留默认的记录行为完全按照collect_specified_data来。histogram_regular设成.*weight.*表示记录所有名字里带 weight 的参数的直方图这对观察参数分布变化很有用。如果你用的是命令行启动也可以通过参数覆盖 YAML 里的配置python run_mindformer.py \ --config configs/bert/run_bert_base_uncased.yaml \ --summary_dir ./summary/bert_run1 \ --collect_freq 50命令行参数的优先级高于 YAML 文件所以你可以用这种方式快速调整不用每次都改配置文件。4.3 启动训练并观察日志输出配置好之后启动训练。训练开始后你会在终端看到类似这样的输出INFO: SummaryCollector: Summary dir is /home/user/experiments/bert_finetune/summary/20240101_120000 INFO: SummaryCollector: Collect freq is 20 INFO: SummaryCollector: Start to collect summary data...注意那个带时间戳的子目录SummaryCollector会在你指定的summary_dir下自动创建一个以时间戳命名的子目录真正的事件文件写在这个子目录里。所以你在启动 TensorBoard 的时候路径要指向这个子目录而不是父目录。训练过程中你可以随时查看事件文件的大小ls -lh /home/user/experiments/bert_finetune/summary/20240101_120000/正常情况下你会看到events.out.tfevents.xxx这样的文件大小随着训练进行逐渐增长。如果文件大小一直不变说明记录可能出了问题需要检查配置。4.4 启动 TensorBoard 并解读可视化结果训练进行中或者训练结束后启动 TensorBoardtensorboard --logdir /home/user/experiments/bert_finetune/summary/20240101_120000 --port 6006 --host 0.0.0.0--host 0.0.0.0允许局域网内其他机器访问方便你在远程服务器上训练、在本地浏览器里看结果。启动成功后浏览器打开http://localhost:6006就能看到面板了。TensorBoard 的面板很多训练监控最常用的是这几个SCALARS 面板展示标量数据loss 曲线、学习率曲线都在这里。你可以同时勾选多个指标对比它们的走势。比如把 train_loss 和 eval_loss 放在一起看如果 eval_loss 开始上升而 train_loss 还在下降说明过拟合了。HISTOGRAMS 面板展示参数的分布直方图。如果你配置了histogram_regular这里能看到权重和梯度的分布变化。正常的训练过程中权重分布应该缓慢变化如果某个层的权重突然变得很宽或者很窄可能有问题。GRAPHS 面板展示计算图。首次调试模型结构的时候很有用可以直观地看到数据流向和算子连接关系。DISTRIBUTIONS 面板和 HISTOGRAMS 类似但展示的是分位数随时间的变化适合观察长尾分布。4.5 多实验对比的目录组织技巧当你跑了很多组实验之后怎么管理这些 summary 目录就成了一个问题。我的做法是按下面的结构组织experiments/ ├── bert_base_lr2e5/ │ └── summary/ │ └── 20240101_120000/ ├── bert_base_lr5e5/ │ └── summary/ │ └── 20240102_090000/ └── bert_large_lr2e5/ └── summary/ └── 20240103_140000/然后启动 TensorBoard 的时候指向experiments目录tensorboard --logdir experiments --port 6006TensorBoard 会自动递归扫描所有子目录把不同实验的曲线用不同颜色画在同一张图上。你可以在左侧的 Runs 列表里勾选或取消勾选特定的实验非常方便对比。提示如果不同实验的 summary 目录层级深度不一致TensorBoard 的自动分组可能会乱。建议保持统一的目录结构每个实验一个顶层目录下面再放 summary 子目录。5. 常见问题与排查技巧实录5.1 TensorBoard 打不开或者没有数据这是最常见的问题原因通常有三个。第一个是路径指错了TensorBoard 的--logdir必须指向包含events.out.tfevents文件的目录而不是它的父目录。你可以用find命令确认一下find /path/to/summary -name events.out.tfevents*如果这个命令找不到任何文件说明训练时根本没有写事件文件需要回头检查SummaryCollector的配置。第二个原因是端口被占用。TensorBoard 默认用 6006 端口如果这个端口已经被其他程序占了启动会失败。换一个端口就行tensorboard --logdir ./summary --port 6007第三个原因是事件文件损坏。这种情况通常发生在训练异常中断的时候文件没有正常关闭。你可以尝试用--reload_multifile true参数让 TensorBoard 重新加载tensorboard --logdir ./summary --reload_multifile true如果还是不行那这个事件文件可能真的坏了只能重新跑训练。5.2 事件文件过大导致磁盘爆满训练步数多、collect_freq设得小、又开了collect_graph和histogram_regular这几个因素叠加起来事件文件可以轻松超过 10 个 G。我遇到过最夸张的一次一个 3 天的训练任务写了 40 多个 G 的 summary 文件直接把磁盘撑爆了。解决办法有几个。首先collect_freq不要设太小100 到 500 是比较合理的范围。其次histogram_regular不要用.*匹配所有参数只匹配你真正关心的层。第三collect_graph只在调试时开正式训练关掉。第四可以设置max_num限制每个指标的最大数据点数collect_specified_data: max_num: 10000这样即使训练步数很多每个指标也最多只保留 10000 个数据点文件大小可控。5.3 分布式训练中只有部分 rank 有数据前面说过SummaryCollector默认只在 rank 0 记录数据。如果你发现只有 rank 0 的 summary 目录有文件其他 rank 的目录是空的这是正常行为不是 bug。但如果你确实需要每个 rank 都记录就得手动在每个 rank 上创建SummaryRecord并且确保日志目录包含 rank idimport mindspore.communication as comm from mindspore.train.summary import SummaryRecord rank_id comm.get_rank() summary_record SummaryRecord(log_dirf./summary/rank_{rank_id})这样每个 rank 会写到独立的目录互不干扰。5.4 曲线抖动严重看不出趋势有时候 loss 曲线抖得像心电图根本看不出下降趋势。这通常是因为collect_freq太小把每个 step 的噪声都记录下来了。解决办法很简单把collect_freq调大或者用 TensorBoard 自带的平滑功能。TensorBoard 的 SCALARS 面板左侧有一个 Smoothing 滑块默认是 0.6。把它调到 0.9 甚至 0.99曲线会平滑很多趋势一目了然。注意平滑只是视觉效果原始数据并没有被修改你随时可以把滑块调回去看原始曲线。如果平滑之后还是看不出趋势那可能是学习率设得有问题或者 batch size 太小导致梯度噪声过大。这时候就需要回头调整超参数了不是监控工具能解决的。5.5 常见问题速查表问题现象可能原因解决方法TensorBoard 无数据路径指错用 find 确认事件文件位置端口冲突6006 被占用换端口 --port 6007文件损坏训练异常中断加 --reload_multifile true磁盘爆满记录频率过高调大 collect_freq限制 max_num只有 rank 0 有数据默认行为手动为每个 rank 创建 SummaryRecord曲线抖动记录频率过小调大 collect_freq 或开平滑训练变慢记录开销过大关掉 collect_graph 和 histogram6. 几个我踩过的坑和实操心得第一个坑是关于summary_dir的。早期我用相对路径./summary结果在不同机器上跑的时候工作目录不一样事件文件写到了各种奇怪的地方。后来统一改成绝对路径再也没出过问题。如果你在多台机器上跑实验这一点尤其重要。第二个坑是关于SummaryRecord的关闭。前面提过忘了调close()会导致数据丢失。我现在的习惯是在训练脚本的finally块里加一行summary_record.close()确保无论训练是否正常结束数据都能刷到磁盘。第三个心得是关于监控指标的选取。不要什么都记只记你真正会看的指标。我见过有人把每个层的权重、梯度、激活值全记下来结果事件文件巨大不说TensorBoard 加载都卡。我的建议是loss 和学习率必记梯度范数选记参数直方图只记关键层计算图只在调试时记。第四个心得是关于 TensorBoard 的启动时机。不需要等训练结束再启动训练开始后就可以启动TensorBoard 会自动检测事件文件的更新并刷新页面。这样你可以在训练过程中实时观察曲线及时发现问题并中断训练节省时间和算力。第五个心得是关于多实验对比的。如果你在调超参数建议每跑一组实验就改一次summary_dir的名字把关键超参数写进目录名里比如lr2e5_bs32_dropout01。这样在 TensorBoard 里对比的时候一眼就能看出哪条曲线对应哪组参数不用去翻训练日志。最后说一个关于性能的观察。开启SummaryCollector之后训练速度会有一定程度的下降具体幅度取决于collect_freq和记录内容的多少。我实测下来collect_freq100、只记 loss 和学习率的情况下性能损失在 2% 以内基本可以忽略。但如果开了collect_graph和全量histogram性能损失可能达到 10% 到 15%。所以正式训练的时候监控配置要精简把开销控制在可接受范围内。
