1. 训练监控这件事为什么值得单独拎出来说搞深度学习训练的人都有一个共识模型跑起来只是第一步真正折磨人的是“它到底学得怎么样”。尤其是用 MindSpore 配合 Transformers 做训练时很多人习惯性地把 loss 打印到终端就完事了结果跑了十几个小时回头一看loss 曲线要么震荡得像个心电图要么早就悄悄发散白白浪费了算力。MindSpore Transformers 训练在线监控这件事核心就是解决“训练过程不可见”的问题而TensorBoard作为最成熟的训练可视化工具之一在 MindSpore 生态里同样能发挥出非常直观的效果。这篇文章面向的是正在用或者准备用 MindSpore 做 Transformer 类模型训练的同学不管你是在单卡上微调一个小模型还是在多卡环境里跑一个参数量不小的网络只要你想实时看到 loss、学习率、梯度范数、权重分布这些关键指标的变化趋势那这套监控方案就能直接拿去用。我会从整体设计思路讲起把 TensorBoard 在 MindSpore 里的接入方式、回调机制、日志目录组织、常见坑点全部拆开讲清楚最后给出一套可以直接复现的实操流程。需要提前说明的是MindSpore 本身提供了SummaryCollector和SummaryLandscape这类回调来对接 TensorBoard 的日志格式而 Transformers 风格的训练脚本通常会有自己的 Trainer 或者自定义训练循环两者结合的时候有一些细节需要处理。这些细节恰恰是很多人踩坑的地方比如日志写不进去、曲线显示不全、多卡环境下文件冲突等等。下面我会逐一展开。2. 整体设计思路为什么选 TensorBoard 而不是别的2.1 监控方案选型的几个现实考量训练监控这件事市面上能选的方案其实不少。有基于终端输出的简单打印有基于 Matplotlib 自己画图的也有像 WandB、MLflow 这类功能更全的平台。但在 MindSpore 的语境下TensorBoard 有几个很难被替代的优势。第一是原生支持程度高。MindSpore 的mindspore.train.callback.SummaryCollector直接就是往 TensorBoard 兼容的事件文件里写数据不需要额外装一堆依赖也不需要把训练数据传到外部服务器。对于很多在内网或者离线环境里跑训练的场景这一点非常关键。第二是开销可控。TensorBoard 的日志写入是异步的采集频率可以自己控制。你完全可以设置成每 10 个 step 采集一次或者每 100 个 step 采集一次对训练速度的影响几乎可以忽略。相比之下有些监控方案会在每个 step 都做一次网络请求或者磁盘写入训练吞吐直接掉一截。第三是可视化维度足够丰富。Scalar、Histogram、Image、Graph、Text 这几种面板基本覆盖了训练监控的所有需求。loss 和 learning rate 用 Scalar 看趋势梯度和权重分布用 Histogram 看健康度输入样本用 Image 看数据增强效果计算图用 Graph 看结构几乎不需要再额外写可视化代码。当然TensorBoard 也不是没有缺点。它的多实验对比能力相对弱一些日志文件多了之后管理起来比较麻烦而且默认的界面在实验数量多的时候会显得有点乱。但对于“训练在线监控”这个具体需求来说它已经足够好用而且和 MindSpore 的集成成本最低。2.2 MindSpore 的 Summary 机制是怎么工作的要理解 TensorBoard 在 MindSpore 里怎么用得先搞清楚 MindSpore 的 Summary 机制。简单来说MindSpore 在训练过程中会通过回调Callback的方式在特定的时间点比如每个 epoch 结束、每个 step 结束触发数据采集然后把采集到的数据按照 TensorBoard 的事件文件格式写到指定的目录里。这个目录通常长这样summary_dir/ ├── events.out.tfevents.1690000000.hostname.12345.0 ├── events.out.tfevents.1690000100.hostname.12345.1 └── ...每个事件文件里存的是一系列 protobuf 格式的记录TensorBoard 启动后会读取这些文件解析出 scalar、histogram 等数据然后在网页上渲染成图表。你不需要手动解析这些文件但理解这个结构对排查问题很有帮助比如日志写不进去的时候你可以先看看目录里到底有没有生成事件文件。MindSpore 里最常用的采集回调是SummaryCollector它的核心参数包括summary_dir日志目录、collect_freq采集频率、collect_specified_data指定采集哪些数据等。在 Transformers 风格的训练脚本里你通常需要把这个回调加到model.train()的callbacks列表里或者加到自定义训练循环的 callback 集合中。2.3 和 Transformers 训练流程的衔接点如果你用的是 HuggingFace 风格的 Transformers 训练脚本那训练循环通常是由Trainer类控制的回调机制也是 Transformers 自己的TrainerCallback。这时候要把 MindSpore 的SummaryCollector接进去有两种常见做法。一种是把 MindSpore 的 callback 包装成 Transformers 的 callback在on_log或者on_step_end这些钩子里手动触发 Summary 采集。另一种是干脆不用 Transformers 的Trainer自己写训练循环在循环里显式调用SummaryCollector的step_end方法。两种方式各有优劣前者改动小但灵活性差后者灵活但需要自己处理学习率调度、梯度累积这些细节。我个人的建议是如果你已经在用 Transformers 的Trainer优先考虑包装成 callback 的方式因为这样对现有代码的侵入最小。如果你是从头写训练脚本那直接自己控制 Summary 采集会更顺手也更容易做细粒度的监控。3. 核心细节解析TensorBoard 接入的关键参数与配置3.1 SummaryCollector 的核心参数怎么设SummaryCollector是 MindSpore 里对接 TensorBoard 的主力回调它的参数设置直接决定了你能看到什么数据、数据有多细。下面这张表列出了最常用的几个参数和它们的实际含义。参数名类型默认值实际作用建议设置summary_dirstr./summary日志输出目录按实验名时间戳命名collect_freqint10采集频率step小模型设10大模型设50-100collect_specified_datadictNone指定采集内容按需开启histogram和imagekeep_default_actionboolTrue是否保留默认采集项一般保持Truecustom_lineage_datadictNone自定义元数据记录超参方便对比这里重点说几个容易踩坑的地方。collect_freq不是越小越好设成 1 的话每个 step 都写一次磁盘训练速度会明显下降尤其是当你的模型比较大、step 时间本来就长的时候这个开销会更明显。我一般会根据总 step 数来定如果总共就几千个 step设成 10 没问题如果总共几十万个 step设成 100 甚至 500 都合理。collect_specified_data这个参数很多人会忽略但它其实很关键。默认情况下MindSpore 只采集 scalar 数据也就是 loss、learning rate 这些标量。如果你想看权重分布或者梯度直方图需要显式开启from mindspore.train.callback import SummaryCollector summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq20, collect_specified_data{ collect_histogram: True, collect_tensor: True, }, keep_default_actionTrue )开启 histogram 之后日志文件会明显变大因为每个采集点都要记录大量张量的分布信息。所以如果你的磁盘空间有限或者训练时间特别长建议只在调试阶段开启正式跑长训练的时候关掉。3.2 日志目录的组织方式与实验管理训练监控做多了之后你会发现日志目录的组织方式直接影响你后续对比实验的效率。我见过太多人把所有实验的日志都写到同一个目录里结果 TensorBoard 一打开几十条曲线叠在一起根本分不清哪条是哪条。一个比较稳妥的做法是按“项目名/实验名_时间戳”的层级来组织summary/ ├── mnist_transformer/ │ ├── exp_lr1e-4_bs32_20240101_120000/ │ ├── exp_lr1e-4_bs64_20240101_150000/ │ └── exp_lr5e-5_bs32_20240102_090000/ └── cifar_vit/ ├── exp_patch16_20240103_100000/ └── exp_patch8_20240103_140000/这样在 TensorBoard 里你可以通过选择不同的子目录来对比特定实验也可以把整个项目目录加载进来看所有实验的整体趋势。另外建议在实验名里带上关键超参比如学习率、batch size、patch size 这些这样即使过了几个月回头看也能一眼看出每个实验的配置差异。还有一个细节是时间戳的格式。用YYYYMMDD_HHMMSS这种格式排序的时候天然就是按时间顺序找最新实验很方便。不要用Jan01这种格式跨月跨年的时候排序会乱。3.3 多卡训练下的日志写入问题多卡训练的时候TensorBoard 日志的写入会变得稍微复杂一些。如果你不做任何处理每张卡都会往同一个目录里写事件文件结果就是日志文件数量爆炸而且 TensorBoard 加载的时候可能会因为文件冲突而显示异常。MindSpore 在多卡场景下的常见做法是只在 rank 0 的卡上开启 Summary 采集其他卡不采集。这样既能保证有完整的监控数据又不会产生冗余日志。实现方式通常是在创建SummaryCollector之前判断一下当前 rankimport mindspore.communication as comm def get_rank(): try: return comm.get_rank() except: return 0 if get_rank() 0: summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq50 ) callbacks.append(summary_collector)如果你确实需要看每张卡的 loss 曲线那可以在日志目录里按 rank 分子目录比如summary/exp_001/rank_0、summary/exp_001/rank_1然后在 TensorBoard 里分别加载。但说实话大多数情况下 rank 0 的数据已经足够反映整体训练情况了没必要把每张卡的数据都单独存一份。4. 实操过程从零搭一套可用的训练监控4.1 环境准备与依赖确认在开始之前先确认你的环境里装了必要的包。MindSpore 本身是必须的TensorBoard 也需要单独安装因为 MindSpore 只负责写日志不负责渲染。pip install mindspore pip install tensorboard如果你用的是 GPU 或者 Ascend 环境MindSpore 的安装方式会有所不同具体可以参考官方文档。安装完之后可以用下面这段代码快速验证一下 Summary 功能是否正常import mindspore as ms from mindspore.train.callback import SummaryCollector import numpy as np # 创建一个简单的 summary collector collector SummaryCollector(summary_dir./test_summary, collect_freq1) # 模拟一些数据 for i in range(100): loss 1.0 / (i 1) np.random.rand() * 0.01 collector.add_value(loss, loss, i) collector.close()跑完之后检查./test_summary目录下有没有生成events.out.tfevents.*文件。如果有说明 Summary 写入正常接下来启动 TensorBoard 就能看到曲线tensorboard --logdir ./test_summary --port 6006然后在浏览器里打开http://localhost:6006如果能看到 loss 曲线那基础环境就没问题了。4.2 在自定义训练循环里接入 Summary如果你是自己写训练循环那接入 Summary 的方式会比较直接。下面是一个完整的例子展示了如何在每个 step 结束后采集 loss 和 learning rateimport mindspore as ms import mindspore.nn as nn from mindspore.train.callback import SummaryCollector from mindspore import Tensor import numpy as np # 假设你已经定义好了网络、损失函数、优化器 # net MyTransformer() # loss_fn nn.CrossEntropyLoss() # optimizer nn.Adam(net.trainable_params(), learning_rate1e-4) summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq10, collect_specified_data{collect_histogram: False} ) # 模拟训练循环 steps 1000 for step in range(steps): # 这里替换成你真实的数据加载和训练逻辑 # data, label next(dataset_iter) # output net(data) # loss loss_fn(output, label) # grads ms.grad(loss_fn)(output, label) # optimizer(grads) # 模拟 loss 和 lr loss_value 2.0 / (step 1) np.random.rand() * 0.05 lr_value 1e-4 * (0.95 ** (step // 100)) # 手动写入 summary summary_collector.add_value(loss, loss_value, step) summary_collector.add_value(learning_rate, lr_value, step) if step % 100 0: print(fStep {step}, Loss: {loss_value:.4f}, LR: {lr_value:.6f}) summary_collector.close()这里的关键点是add_value方法它接受三个参数标签名、数值、step 数。标签名就是你在 TensorBoard 里看到的曲线名称step 数决定了曲线在横轴上的位置。你可以根据需要添加任意多个指标比如梯度范数、权重均值、吞吐量等等。4.3 在 Transformers Trainer 里包装 MindSpore Callback如果你用的是 Transformers 的Trainer那接入方式会稍微绕一点。因为Trainer有自己的回调体系你需要写一个适配器把 MindSpore 的SummaryCollector包装成 Transformers 能识别的 callback。from transformers import TrainerCallback class MindSporeSummaryCallback(TrainerCallback): def __init__(self, summary_collector): self.summary_collector summary_collector self.step 0 def on_log(self, args, state, control, logsNone, **kwargs): if logs is None: return for key, value in logs.items(): if isinstance(value, (int, float)): self.summary_collector.add_value(key, value, state.global_step) def on_train_end(self, args, state, control, **kwargs): self.summary_collector.close()然后在创建Trainer的时候把这个 callback 加进去summary_collector SummaryCollector( summary_dir./summary/transformers_exp, collect_freq10 ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, callbacks[MindSporeSummaryCallback(summary_collector)] )这种方式的优点是改动小不需要动Trainer的内部逻辑。缺点是采集频率受限于Trainer的 logging 频率如果你设置logging_steps100那 Summary 也只能每 100 步采集一次。如果你需要更细粒度的监控还是得自己写训练循环。4.4 启动 TensorBoard 并解读关键曲线日志写进去之后启动 TensorBoard 就是最后一步了。命令很简单tensorboard --logdir ./summary --port 6006 --host 0.0.0.0--host 0.0.0.0是为了让同一网络下的其他机器也能访问方便在远程服务器上跑训练、在本地看曲线。启动之后浏览器打开对应地址你就能看到各种面板了。下面这张表列出了几个最关键的曲线和它们的解读方式曲线名称正常表现异常表现可能原因train_loss平稳下降后期趋于平缓震荡剧烈或上升学习率过大、数据有问题learning_rate按调度策略变化突然变成0或NaN调度器配置错误grad_norm稳定在合理范围突然爆炸或持续增大梯度裁剪没生效、模型发散weight_mean缓慢变化快速趋近0或无穷初始化有问题、正则化过强我个人的习惯是训练开始后的前几百个 step 会一直盯着 loss 和 grad_norm 看确认没有异常之后再让它自己跑。如果发现 loss 震荡得厉害第一反应是检查学习率是不是太大了如果 grad_norm 持续增大那大概率是梯度爆炸需要加梯度裁剪。5. 常见问题与排查技巧实录5.1 TensorBoard 打不开或者曲线不显示这是最常见的问题通常有几个原因。第一个是日志目录里根本没有事件文件这时候你需要检查SummaryCollector是否真的被调用了以及summary_dir路径是否正确。第二个是 TensorBoard 启动的目录和日志目录不一致比如日志写在./summary/exp_001但你启动的时候用的是--logdir ./summary这种情况下 TensorBoard 会把exp_001当成一个子实验你需要点进去才能看到曲线。第三个原因是端口被占用。TensorBoard 默认用 6006 端口如果这个端口已经被别的程序占了启动会失败。解决办法是换一个端口比如--port 6007。第四个原因是事件文件损坏这种情况通常发生在训练中途强制中断的时候解决办法是删掉损坏的文件重新跑或者用--reload_multifile true让 TensorBoard 尝试重新加载。还有一个比较隐蔽的问题是时间戳不一致。如果你在训练脚本里手动指定了 step 数但 step 数的增长和实际训练进度不匹配TensorBoard 的横轴就会显示得很奇怪。解决办法是确保add_value里的 step 参数和实际训练 step 保持一致。5.2 日志文件过大导致磁盘爆满开启 histogram 采集之后日志文件的增长速度会非常快。我遇到过跑一个 24 小时的训练日志目录占了 50 多个 G 的情况。如果你没有提前做好磁盘规划训练跑到一半因为磁盘满了而中断那就很尴尬了。控制日志大小的几个手段一是降低采集频率把collect_freq从 10 调到 100 甚至更大二是关闭 histogram 采集只保留 scalar三是定期清理旧实验的日志比如只保留最近 5 次实验的数据四是使用 TensorBoard 的--purge_orphaned_data选项在启动时清理孤立的数据。另外MindSpore 的 Summary 文件默认是不压缩的如果你对磁盘空间特别敏感可以在训练结束后手动压缩一下或者写个脚本定期把旧日志打包归档。5.3 多卡环境下曲线重复或缺失多卡训练时如果你没有做 rank 判断每张卡都往同一个目录写日志TensorBoard 里就会出现多条重复的曲线而且因为不同卡的 step 可能不完全同步曲线会显得很乱。解决办法前面已经提到了就是只在 rank 0 上开启 Summary 采集。但有时候你会遇到另一种情况明明只在 rank 0 上开了采集但曲线还是缺失。这通常是因为 rank 0 的进程在训练结束前就被杀掉了导致 Summary 文件没有正常关闭。解决办法是在训练结束的时候显式调用summary_collector.close()确保所有缓冲的数据都写入磁盘。还有一个坑是有些训练框架会在每个 epoch 结束后重启数据加载进程如果 Summary 采集是在数据加载进程里做的那日志可能会丢失。这种情况下需要把 Summary 采集放在主训练进程里而不是数据加载进程里。5.4 曲线抖动太大看不清趋势loss 曲线抖动是正常现象但如果抖动得太厉害趋势就看不出来了。这时候有几个处理办法。一是用 TensorBoard 自带的平滑功能在左侧面板里调整 smoothing 参数一般设成 0.6 到 0.9 之间比较合适。二是降低采集频率比如从每 10 步采集一次改成每 100 步采集一次这样曲线会自然平滑一些。三是在写 Summary 之前先对 loss 做移动平均比如每 10 个 step 的平均值作为一个采集点。我个人的习惯是训练初期用高频率采集方便发现异常训练稳定之后切换到低频率采集方便看长期趋势。TensorBoard 的平滑功能只是视觉上的处理不会改变原始数据所以如果你需要精确分析还是得看原始曲线。5.5 常见问题速查表问题现象可能原因排查方法解决方案TensorBoard 页面空白日志目录为空或路径错误检查目录下是否有 events 文件确认 summary_dir 和 logdir 一致曲线只有一条直线采集频率太低或 step 没变化检查 collect_freq 和 step 参数调整采集频率确保 step 递增多卡曲线重复每张卡都写了日志检查是否有 rank 判断只在 rank 0 开启采集日志文件过大histogram 采集太频繁查看日志目录大小降低频率或关闭 histogram训练中断后日志损坏文件没有正常关闭检查文件是否能被 TensorBoard 读取删除损坏文件重新训练6. 几个我踩过的坑和对应的经验6.1 不要在训练循环里频繁创建 SummaryCollector我刚开始用的时候犯过一个很蠢的错误在每个 epoch 开始时都重新创建一个SummaryCollector。结果就是日志目录里生成了一大堆事件文件TensorBoard 加载的时候特别慢而且曲线断断续续的。正确的做法是在训练开始前创建一次训练结束后关闭一次中间一直复用同一个实例。6.2 注意 Summary 写入的线程安全性MindSpore 的SummaryCollector在写入数据的时候内部是有缓冲的。如果你在多个线程里同时调用add_value可能会出现数据竞争的问题。虽然这种情况不常见但如果你用了多线程数据加载或者异步训练最好还是加个锁或者确保只在主线程里写 Summary。6.3 远程训练时用 SSH 端口转发看曲线如果你在远程服务器上跑训练本地想看 TensorBoard最方便的方式是用 SSH 端口转发。在本地终端里执行ssh -L 6006:localhost:6006 userremote_server然后在远程服务器上启动 TensorBoard本地浏览器打开http://localhost:6006就能看到了。这种方式比直接把 TensorBoard 暴露到公网安全得多也不需要额外配置。6.4 用 TensorBoard 的对比功能做实验分析TensorBoard 左侧有一个“Runs”面板你可以通过勾选不同的实验来对比它们的曲线。这个功能在做超参搜索的时候特别有用。比如你跑了 5 组不同学习率的实验把它们的日志放在同一个父目录下然后在 TensorBoard 里全部勾选就能很直观地看出哪组学习率收敛得最好。我一般会在实验名里带上关键超参比如lr1e-4_bs32、lr5e-5_bs64这样在 Runs 面板里一眼就能看出每组的配置。如果实验比较多还可以用颜色分组功能把同一类实验标成同一种颜色对比起来更清晰。6.5 训练结束后别忘了关闭 SummaryCollector这个看起来是小事但如果不做可能会导致最后一段数据丢失。因为SummaryCollector内部有缓冲区只有调用close()的时候才会把缓冲区的数据全部刷到磁盘。如果你在训练结束后直接退出进程缓冲区里的数据就丢了。所以不管训练是正常结束还是异常中断都建议在finally块里调用一下close()。try: # 训练循环 pass finally: summary_collector.close()这套监控方案我在几个不同的项目里都用过从小的图像分类模型到稍微大一点的文本生成模型整体表现都很稳定。TensorBoard 的曲线虽然简单但胜在直观和实时训练过程中扫一眼就能知道有没有跑偏。如果你还没把训练监控当回事建议从下一个实验开始就把 Summary 加上后面排查问题的时候会感谢自己的。
MindSpore Transformers 训练监控：TensorBoard 在线可视化实战
1. 训练监控这件事为什么值得单独拎出来说搞深度学习训练的人都有一个共识模型跑起来只是第一步真正折磨人的是“它到底学得怎么样”。尤其是用 MindSpore 配合 Transformers 做训练时很多人习惯性地把 loss 打印到终端就完事了结果跑了十几个小时回头一看loss 曲线要么震荡得像个心电图要么早就悄悄发散白白浪费了算力。MindSpore Transformers 训练在线监控这件事核心就是解决“训练过程不可见”的问题而TensorBoard作为最成熟的训练可视化工具之一在 MindSpore 生态里同样能发挥出非常直观的效果。这篇文章面向的是正在用或者准备用 MindSpore 做 Transformer 类模型训练的同学不管你是在单卡上微调一个小模型还是在多卡环境里跑一个参数量不小的网络只要你想实时看到 loss、学习率、梯度范数、权重分布这些关键指标的变化趋势那这套监控方案就能直接拿去用。我会从整体设计思路讲起把 TensorBoard 在 MindSpore 里的接入方式、回调机制、日志目录组织、常见坑点全部拆开讲清楚最后给出一套可以直接复现的实操流程。需要提前说明的是MindSpore 本身提供了SummaryCollector和SummaryLandscape这类回调来对接 TensorBoard 的日志格式而 Transformers 风格的训练脚本通常会有自己的 Trainer 或者自定义训练循环两者结合的时候有一些细节需要处理。这些细节恰恰是很多人踩坑的地方比如日志写不进去、曲线显示不全、多卡环境下文件冲突等等。下面我会逐一展开。2. 整体设计思路为什么选 TensorBoard 而不是别的2.1 监控方案选型的几个现实考量训练监控这件事市面上能选的方案其实不少。有基于终端输出的简单打印有基于 Matplotlib 自己画图的也有像 WandB、MLflow 这类功能更全的平台。但在 MindSpore 的语境下TensorBoard 有几个很难被替代的优势。第一是原生支持程度高。MindSpore 的mindspore.train.callback.SummaryCollector直接就是往 TensorBoard 兼容的事件文件里写数据不需要额外装一堆依赖也不需要把训练数据传到外部服务器。对于很多在内网或者离线环境里跑训练的场景这一点非常关键。第二是开销可控。TensorBoard 的日志写入是异步的采集频率可以自己控制。你完全可以设置成每 10 个 step 采集一次或者每 100 个 step 采集一次对训练速度的影响几乎可以忽略。相比之下有些监控方案会在每个 step 都做一次网络请求或者磁盘写入训练吞吐直接掉一截。第三是可视化维度足够丰富。Scalar、Histogram、Image、Graph、Text 这几种面板基本覆盖了训练监控的所有需求。loss 和 learning rate 用 Scalar 看趋势梯度和权重分布用 Histogram 看健康度输入样本用 Image 看数据增强效果计算图用 Graph 看结构几乎不需要再额外写可视化代码。当然TensorBoard 也不是没有缺点。它的多实验对比能力相对弱一些日志文件多了之后管理起来比较麻烦而且默认的界面在实验数量多的时候会显得有点乱。但对于“训练在线监控”这个具体需求来说它已经足够好用而且和 MindSpore 的集成成本最低。2.2 MindSpore 的 Summary 机制是怎么工作的要理解 TensorBoard 在 MindSpore 里怎么用得先搞清楚 MindSpore 的 Summary 机制。简单来说MindSpore 在训练过程中会通过回调Callback的方式在特定的时间点比如每个 epoch 结束、每个 step 结束触发数据采集然后把采集到的数据按照 TensorBoard 的事件文件格式写到指定的目录里。这个目录通常长这样summary_dir/ ├── events.out.tfevents.1690000000.hostname.12345.0 ├── events.out.tfevents.1690000100.hostname.12345.1 └── ...每个事件文件里存的是一系列 protobuf 格式的记录TensorBoard 启动后会读取这些文件解析出 scalar、histogram 等数据然后在网页上渲染成图表。你不需要手动解析这些文件但理解这个结构对排查问题很有帮助比如日志写不进去的时候你可以先看看目录里到底有没有生成事件文件。MindSpore 里最常用的采集回调是SummaryCollector它的核心参数包括summary_dir日志目录、collect_freq采集频率、collect_specified_data指定采集哪些数据等。在 Transformers 风格的训练脚本里你通常需要把这个回调加到model.train()的callbacks列表里或者加到自定义训练循环的 callback 集合中。2.3 和 Transformers 训练流程的衔接点如果你用的是 HuggingFace 风格的 Transformers 训练脚本那训练循环通常是由Trainer类控制的回调机制也是 Transformers 自己的TrainerCallback。这时候要把 MindSpore 的SummaryCollector接进去有两种常见做法。一种是把 MindSpore 的 callback 包装成 Transformers 的 callback在on_log或者on_step_end这些钩子里手动触发 Summary 采集。另一种是干脆不用 Transformers 的Trainer自己写训练循环在循环里显式调用SummaryCollector的step_end方法。两种方式各有优劣前者改动小但灵活性差后者灵活但需要自己处理学习率调度、梯度累积这些细节。我个人的建议是如果你已经在用 Transformers 的Trainer优先考虑包装成 callback 的方式因为这样对现有代码的侵入最小。如果你是从头写训练脚本那直接自己控制 Summary 采集会更顺手也更容易做细粒度的监控。3. 核心细节解析TensorBoard 接入的关键参数与配置3.1 SummaryCollector 的核心参数怎么设SummaryCollector是 MindSpore 里对接 TensorBoard 的主力回调它的参数设置直接决定了你能看到什么数据、数据有多细。下面这张表列出了最常用的几个参数和它们的实际含义。参数名类型默认值实际作用建议设置summary_dirstr./summary日志输出目录按实验名时间戳命名collect_freqint10采集频率step小模型设10大模型设50-100collect_specified_datadictNone指定采集内容按需开启histogram和imagekeep_default_actionboolTrue是否保留默认采集项一般保持Truecustom_lineage_datadictNone自定义元数据记录超参方便对比这里重点说几个容易踩坑的地方。collect_freq不是越小越好设成 1 的话每个 step 都写一次磁盘训练速度会明显下降尤其是当你的模型比较大、step 时间本来就长的时候这个开销会更明显。我一般会根据总 step 数来定如果总共就几千个 step设成 10 没问题如果总共几十万个 step设成 100 甚至 500 都合理。collect_specified_data这个参数很多人会忽略但它其实很关键。默认情况下MindSpore 只采集 scalar 数据也就是 loss、learning rate 这些标量。如果你想看权重分布或者梯度直方图需要显式开启from mindspore.train.callback import SummaryCollector summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq20, collect_specified_data{ collect_histogram: True, collect_tensor: True, }, keep_default_actionTrue )开启 histogram 之后日志文件会明显变大因为每个采集点都要记录大量张量的分布信息。所以如果你的磁盘空间有限或者训练时间特别长建议只在调试阶段开启正式跑长训练的时候关掉。3.2 日志目录的组织方式与实验管理训练监控做多了之后你会发现日志目录的组织方式直接影响你后续对比实验的效率。我见过太多人把所有实验的日志都写到同一个目录里结果 TensorBoard 一打开几十条曲线叠在一起根本分不清哪条是哪条。一个比较稳妥的做法是按“项目名/实验名_时间戳”的层级来组织summary/ ├── mnist_transformer/ │ ├── exp_lr1e-4_bs32_20240101_120000/ │ ├── exp_lr1e-4_bs64_20240101_150000/ │ └── exp_lr5e-5_bs32_20240102_090000/ └── cifar_vit/ ├── exp_patch16_20240103_100000/ └── exp_patch8_20240103_140000/这样在 TensorBoard 里你可以通过选择不同的子目录来对比特定实验也可以把整个项目目录加载进来看所有实验的整体趋势。另外建议在实验名里带上关键超参比如学习率、batch size、patch size 这些这样即使过了几个月回头看也能一眼看出每个实验的配置差异。还有一个细节是时间戳的格式。用YYYYMMDD_HHMMSS这种格式排序的时候天然就是按时间顺序找最新实验很方便。不要用Jan01这种格式跨月跨年的时候排序会乱。3.3 多卡训练下的日志写入问题多卡训练的时候TensorBoard 日志的写入会变得稍微复杂一些。如果你不做任何处理每张卡都会往同一个目录里写事件文件结果就是日志文件数量爆炸而且 TensorBoard 加载的时候可能会因为文件冲突而显示异常。MindSpore 在多卡场景下的常见做法是只在 rank 0 的卡上开启 Summary 采集其他卡不采集。这样既能保证有完整的监控数据又不会产生冗余日志。实现方式通常是在创建SummaryCollector之前判断一下当前 rankimport mindspore.communication as comm def get_rank(): try: return comm.get_rank() except: return 0 if get_rank() 0: summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq50 ) callbacks.append(summary_collector)如果你确实需要看每张卡的 loss 曲线那可以在日志目录里按 rank 分子目录比如summary/exp_001/rank_0、summary/exp_001/rank_1然后在 TensorBoard 里分别加载。但说实话大多数情况下 rank 0 的数据已经足够反映整体训练情况了没必要把每张卡的数据都单独存一份。4. 实操过程从零搭一套可用的训练监控4.1 环境准备与依赖确认在开始之前先确认你的环境里装了必要的包。MindSpore 本身是必须的TensorBoard 也需要单独安装因为 MindSpore 只负责写日志不负责渲染。pip install mindspore pip install tensorboard如果你用的是 GPU 或者 Ascend 环境MindSpore 的安装方式会有所不同具体可以参考官方文档。安装完之后可以用下面这段代码快速验证一下 Summary 功能是否正常import mindspore as ms from mindspore.train.callback import SummaryCollector import numpy as np # 创建一个简单的 summary collector collector SummaryCollector(summary_dir./test_summary, collect_freq1) # 模拟一些数据 for i in range(100): loss 1.0 / (i 1) np.random.rand() * 0.01 collector.add_value(loss, loss, i) collector.close()跑完之后检查./test_summary目录下有没有生成events.out.tfevents.*文件。如果有说明 Summary 写入正常接下来启动 TensorBoard 就能看到曲线tensorboard --logdir ./test_summary --port 6006然后在浏览器里打开http://localhost:6006如果能看到 loss 曲线那基础环境就没问题了。4.2 在自定义训练循环里接入 Summary如果你是自己写训练循环那接入 Summary 的方式会比较直接。下面是一个完整的例子展示了如何在每个 step 结束后采集 loss 和 learning rateimport mindspore as ms import mindspore.nn as nn from mindspore.train.callback import SummaryCollector from mindspore import Tensor import numpy as np # 假设你已经定义好了网络、损失函数、优化器 # net MyTransformer() # loss_fn nn.CrossEntropyLoss() # optimizer nn.Adam(net.trainable_params(), learning_rate1e-4) summary_collector SummaryCollector( summary_dir./summary/exp_001, collect_freq10, collect_specified_data{collect_histogram: False} ) # 模拟训练循环 steps 1000 for step in range(steps): # 这里替换成你真实的数据加载和训练逻辑 # data, label next(dataset_iter) # output net(data) # loss loss_fn(output, label) # grads ms.grad(loss_fn)(output, label) # optimizer(grads) # 模拟 loss 和 lr loss_value 2.0 / (step 1) np.random.rand() * 0.05 lr_value 1e-4 * (0.95 ** (step // 100)) # 手动写入 summary summary_collector.add_value(loss, loss_value, step) summary_collector.add_value(learning_rate, lr_value, step) if step % 100 0: print(fStep {step}, Loss: {loss_value:.4f}, LR: {lr_value:.6f}) summary_collector.close()这里的关键点是add_value方法它接受三个参数标签名、数值、step 数。标签名就是你在 TensorBoard 里看到的曲线名称step 数决定了曲线在横轴上的位置。你可以根据需要添加任意多个指标比如梯度范数、权重均值、吞吐量等等。4.3 在 Transformers Trainer 里包装 MindSpore Callback如果你用的是 Transformers 的Trainer那接入方式会稍微绕一点。因为Trainer有自己的回调体系你需要写一个适配器把 MindSpore 的SummaryCollector包装成 Transformers 能识别的 callback。from transformers import TrainerCallback class MindSporeSummaryCallback(TrainerCallback): def __init__(self, summary_collector): self.summary_collector summary_collector self.step 0 def on_log(self, args, state, control, logsNone, **kwargs): if logs is None: return for key, value in logs.items(): if isinstance(value, (int, float)): self.summary_collector.add_value(key, value, state.global_step) def on_train_end(self, args, state, control, **kwargs): self.summary_collector.close()然后在创建Trainer的时候把这个 callback 加进去summary_collector SummaryCollector( summary_dir./summary/transformers_exp, collect_freq10 ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, callbacks[MindSporeSummaryCallback(summary_collector)] )这种方式的优点是改动小不需要动Trainer的内部逻辑。缺点是采集频率受限于Trainer的 logging 频率如果你设置logging_steps100那 Summary 也只能每 100 步采集一次。如果你需要更细粒度的监控还是得自己写训练循环。4.4 启动 TensorBoard 并解读关键曲线日志写进去之后启动 TensorBoard 就是最后一步了。命令很简单tensorboard --logdir ./summary --port 6006 --host 0.0.0.0--host 0.0.0.0是为了让同一网络下的其他机器也能访问方便在远程服务器上跑训练、在本地看曲线。启动之后浏览器打开对应地址你就能看到各种面板了。下面这张表列出了几个最关键的曲线和它们的解读方式曲线名称正常表现异常表现可能原因train_loss平稳下降后期趋于平缓震荡剧烈或上升学习率过大、数据有问题learning_rate按调度策略变化突然变成0或NaN调度器配置错误grad_norm稳定在合理范围突然爆炸或持续增大梯度裁剪没生效、模型发散weight_mean缓慢变化快速趋近0或无穷初始化有问题、正则化过强我个人的习惯是训练开始后的前几百个 step 会一直盯着 loss 和 grad_norm 看确认没有异常之后再让它自己跑。如果发现 loss 震荡得厉害第一反应是检查学习率是不是太大了如果 grad_norm 持续增大那大概率是梯度爆炸需要加梯度裁剪。5. 常见问题与排查技巧实录5.1 TensorBoard 打不开或者曲线不显示这是最常见的问题通常有几个原因。第一个是日志目录里根本没有事件文件这时候你需要检查SummaryCollector是否真的被调用了以及summary_dir路径是否正确。第二个是 TensorBoard 启动的目录和日志目录不一致比如日志写在./summary/exp_001但你启动的时候用的是--logdir ./summary这种情况下 TensorBoard 会把exp_001当成一个子实验你需要点进去才能看到曲线。第三个原因是端口被占用。TensorBoard 默认用 6006 端口如果这个端口已经被别的程序占了启动会失败。解决办法是换一个端口比如--port 6007。第四个原因是事件文件损坏这种情况通常发生在训练中途强制中断的时候解决办法是删掉损坏的文件重新跑或者用--reload_multifile true让 TensorBoard 尝试重新加载。还有一个比较隐蔽的问题是时间戳不一致。如果你在训练脚本里手动指定了 step 数但 step 数的增长和实际训练进度不匹配TensorBoard 的横轴就会显示得很奇怪。解决办法是确保add_value里的 step 参数和实际训练 step 保持一致。5.2 日志文件过大导致磁盘爆满开启 histogram 采集之后日志文件的增长速度会非常快。我遇到过跑一个 24 小时的训练日志目录占了 50 多个 G 的情况。如果你没有提前做好磁盘规划训练跑到一半因为磁盘满了而中断那就很尴尬了。控制日志大小的几个手段一是降低采集频率把collect_freq从 10 调到 100 甚至更大二是关闭 histogram 采集只保留 scalar三是定期清理旧实验的日志比如只保留最近 5 次实验的数据四是使用 TensorBoard 的--purge_orphaned_data选项在启动时清理孤立的数据。另外MindSpore 的 Summary 文件默认是不压缩的如果你对磁盘空间特别敏感可以在训练结束后手动压缩一下或者写个脚本定期把旧日志打包归档。5.3 多卡环境下曲线重复或缺失多卡训练时如果你没有做 rank 判断每张卡都往同一个目录写日志TensorBoard 里就会出现多条重复的曲线而且因为不同卡的 step 可能不完全同步曲线会显得很乱。解决办法前面已经提到了就是只在 rank 0 上开启 Summary 采集。但有时候你会遇到另一种情况明明只在 rank 0 上开了采集但曲线还是缺失。这通常是因为 rank 0 的进程在训练结束前就被杀掉了导致 Summary 文件没有正常关闭。解决办法是在训练结束的时候显式调用summary_collector.close()确保所有缓冲的数据都写入磁盘。还有一个坑是有些训练框架会在每个 epoch 结束后重启数据加载进程如果 Summary 采集是在数据加载进程里做的那日志可能会丢失。这种情况下需要把 Summary 采集放在主训练进程里而不是数据加载进程里。5.4 曲线抖动太大看不清趋势loss 曲线抖动是正常现象但如果抖动得太厉害趋势就看不出来了。这时候有几个处理办法。一是用 TensorBoard 自带的平滑功能在左侧面板里调整 smoothing 参数一般设成 0.6 到 0.9 之间比较合适。二是降低采集频率比如从每 10 步采集一次改成每 100 步采集一次这样曲线会自然平滑一些。三是在写 Summary 之前先对 loss 做移动平均比如每 10 个 step 的平均值作为一个采集点。我个人的习惯是训练初期用高频率采集方便发现异常训练稳定之后切换到低频率采集方便看长期趋势。TensorBoard 的平滑功能只是视觉上的处理不会改变原始数据所以如果你需要精确分析还是得看原始曲线。5.5 常见问题速查表问题现象可能原因排查方法解决方案TensorBoard 页面空白日志目录为空或路径错误检查目录下是否有 events 文件确认 summary_dir 和 logdir 一致曲线只有一条直线采集频率太低或 step 没变化检查 collect_freq 和 step 参数调整采集频率确保 step 递增多卡曲线重复每张卡都写了日志检查是否有 rank 判断只在 rank 0 开启采集日志文件过大histogram 采集太频繁查看日志目录大小降低频率或关闭 histogram训练中断后日志损坏文件没有正常关闭检查文件是否能被 TensorBoard 读取删除损坏文件重新训练6. 几个我踩过的坑和对应的经验6.1 不要在训练循环里频繁创建 SummaryCollector我刚开始用的时候犯过一个很蠢的错误在每个 epoch 开始时都重新创建一个SummaryCollector。结果就是日志目录里生成了一大堆事件文件TensorBoard 加载的时候特别慢而且曲线断断续续的。正确的做法是在训练开始前创建一次训练结束后关闭一次中间一直复用同一个实例。6.2 注意 Summary 写入的线程安全性MindSpore 的SummaryCollector在写入数据的时候内部是有缓冲的。如果你在多个线程里同时调用add_value可能会出现数据竞争的问题。虽然这种情况不常见但如果你用了多线程数据加载或者异步训练最好还是加个锁或者确保只在主线程里写 Summary。6.3 远程训练时用 SSH 端口转发看曲线如果你在远程服务器上跑训练本地想看 TensorBoard最方便的方式是用 SSH 端口转发。在本地终端里执行ssh -L 6006:localhost:6006 userremote_server然后在远程服务器上启动 TensorBoard本地浏览器打开http://localhost:6006就能看到了。这种方式比直接把 TensorBoard 暴露到公网安全得多也不需要额外配置。6.4 用 TensorBoard 的对比功能做实验分析TensorBoard 左侧有一个“Runs”面板你可以通过勾选不同的实验来对比它们的曲线。这个功能在做超参搜索的时候特别有用。比如你跑了 5 组不同学习率的实验把它们的日志放在同一个父目录下然后在 TensorBoard 里全部勾选就能很直观地看出哪组学习率收敛得最好。我一般会在实验名里带上关键超参比如lr1e-4_bs32、lr5e-5_bs64这样在 Runs 面板里一眼就能看出每组的配置。如果实验比较多还可以用颜色分组功能把同一类实验标成同一种颜色对比起来更清晰。6.5 训练结束后别忘了关闭 SummaryCollector这个看起来是小事但如果不做可能会导致最后一段数据丢失。因为SummaryCollector内部有缓冲区只有调用close()的时候才会把缓冲区的数据全部刷到磁盘。如果你在训练结束后直接退出进程缓冲区里的数据就丢了。所以不管训练是正常结束还是异常中断都建议在finally块里调用一下close()。try: # 训练循环 pass finally: summary_collector.close()这套监控方案我在几个不同的项目里都用过从小的图像分类模型到稍微大一点的文本生成模型整体表现都很稳定。TensorBoard 的曲线虽然简单但胜在直观和实时训练过程中扫一眼就能知道有没有跑偏。如果你还没把训练监控当回事建议从下一个实验开始就把 Summary 加上后面排查问题的时候会感谢自己的。
