MindSpore Transformers训练实时监控实战：Callback+WebSocket+ECharts

前阵子我调一个 Deformable DETR 的微调实验，模型用 MindSpore Transformers 套件加载，睡前看了一眼 loss 还在 0.8 附近，心里想着“还行，明早起来应该能收敛”。结果第二天打开终端，屏幕上一行刺眼的 loss: nan，而且这个 nan 大概从第二个 epoch 中段就开始出现了。也就是说，整整半宿的训练都在原地空转。从那以后我就明白一件事：训练大模型，光靠终端日志是赌运气。必须把训练过程在线监控起来，把 loss、lr、梯度范数、吞吐量这些指标实时画成曲线图，出了问题第一时间就能从曲线形态上看出来，而不是等天亮才发现。这篇文章就把我在 MindSpore Transformers 训练里落地的一套在线监控方案完整写出来，包括实时曲线图可视化的整体设计、基于 Callback 的指标采集、WebSocket 加 ECharts 的前后端代码，以及接进 Deformable DETR 这类 Transformer 模型的实战过程。

1. 为什么训练必须做在线监控

1.1 终端日志只能回答“发生了什么”，曲线能回答“正在发生什么”

很多人觉得训练监控不就是把 loss 打印出来吗？LossMonitor 加 TimeMonitor 已经是标配了。但终端日志有两个天然缺陷：第一，它是离散的，你看到的是一个一个数字，而不是一段趋势。loss 从 0.8 掉到 0.6 再涨回 0.7，你根本看不出这是正常波动还是模型在发散；第二，它是事后的，你今天晚上睡不着，凌晨两点爬起来看一眼日志，发现早上八点就已经 nan 了，中间六个小时全浪费了。实时曲线图解决的就是这两个问题：横轴是 step，纵轴是 loss 或其它指标，曲线的形状、斜率、突变点都是可读的信息。loss 是缓慢下降还是突然抬头，lr 是线性衰减还是出了尖刺，梯度范数是不是在某一步突然爆到几十，这些从一条连续曲线上能一眼判断，而终端日志要翻几十屏才能对出个大概。

1.2 实时曲线能提前暴露的五类训练问题

我总结了自己踩过的坑，训练过程中的大多数“事故”都会在曲线形态上留下痕迹，而且往往比 loss 变成 nan 更早出现。第一类是梯度爆炸，loss 曲线在某个 step 处出现明显的垂直上升尖峰，紧接着后面几个 step 全是 nan，这是优化器被炸穿的前兆，需要盯梯度范数曲线。第二类是学习率策略失效，lr 曲线本该线性衰减却变成了台阶状，或者 warmup 阶段过了之后 loss 反而一路横盘，说明 warmup steps 配多了。第三类是数据加载瓶颈，throughput（每秒样本数）曲线在某个 epoch 后突然从 2000 掉到 300，往往是 dataloader 的 shuffle 或者预处理队列出了问题，模型在空等数据。第四类是过拟合信号，验证集 loss 在训练集 loss 还在下降时就开始反弹，两条曲线的交叉点就是早停的位置。第五类是硬件资源异常，GPU 利用率曲线如果呈锯齿状，说明通信开销已经超过了计算收益，分布式并行配置需要调整。这些信息如果只靠终端日志，很难在第一时间捕捉到。

1.3 在线监控不是锦上添花，是止损工具

我之前也觉得监控这东西属于“锦上添花”，模型能跑就行，搞一堆可视化是浪费时间。直到有一次在云上租了八卡机器跑 BERT 微调，实验跑了两天发现 loss 根本就没动过，原因是数据集里 label 全部错位了，模型一直在学噪声。如果当时在 loss 曲线旁边放一条 accuracy 曲线，第一轮就能看出来这是死局。在线监控本质上是止损工具，它让实验失败的成本从“几天”压缩到“几十分钟”。特别是 Transformer 这类大模型，单次训练动辄几个小时起步，哪怕提前半小时发现问题，省下的都是真金白银的算力。这也是我为什么坚持要把监控指标做得尽量全：loss 只是结果，梯度范数和 lr 才是过程，只看结果等于等诊断报告出来了才去医院。

2. 方案选型：MindInsight 还是自研可视化

2.1 原生方案：SummaryCollector 与 MindInsight

MindSpore 生态里自带了一套可视化方案，训练时挂一个 SummaryCollector，训练结束后启动 MindInsight 服务，就能在浏览器里看标量曲线、计算图、数据图之类的面板。接入成本很低，代码基本就是三五行：

from mindspore.train.callback import SummaryCollector summary_collector = SummaryCollector(summary_dir='./summary_dir', collect_freq=10) model.train(epoch_size, train_dataset, callbacks=[summary_collector])

训练跑完以后，在命令行启动 MindInsight：

mindinsight start --port 8080 --summary-base-dir ./summary_dir

浏览器打开http://localhost:8080就能看到训练过程中记录的标量曲线。这套方案的好处是白嫖，不写一行前端代码，对标量、图片、计算图都有支持，而且和 MindSpore 的算子层做了打通，某些指标在 NPU 上采集更准确。但它在我实际的“在线监控”需求下有几个痛点：一是延迟，MindInsight 的数据是从 Summary 文件里异步刷新的，训练过程中打开页面，曲线要隔一段时间才会跳一下，更像是事后复盘，不是真正意义的实时；二是自定义指标不灵活，我想看梯度范数、吞吐量这些指标，SummaryCollector 默认是不采集的，得自己去处理 trainable_params 的梯度，绕一圈很麻烦；三是服务比较重，如果只是想在本地快速看一眼训练状态，启动一个 MindInsight 服务有点杀鸡用牛刀。

2.2 为什么我还要自研一套轻量可视化

MindInsight 适合离线分析，但我要的是“训练还在跑，我喝着咖啡就能看到曲线在动”。这个诉求在技术形态上其实很简单：训练进程把指标写出来，浏览器定时拉或者通过 WebSocket 被推送过去。自研方案可以完全按自己的需求裁剪，想监控什么指标就加什么指标，想用什么前端图表库就用什么，甚至可以把告警逻辑接进去，比如 gradient norm 超过阈值就在页面上弹红。另外一个很实际的原因是，MindSpore Transformers 套件里的训练脚本封装层次比较深，我想往里面加一个旁路监控，从 callback 或者 train loop 里把指标透传出来，直接改套件源码不现实，自研方案反而能作为一个独立模块解耦在外面，训练主流程不需要大动。综合下来，我选择了一个轻量级方案：Callback 采集指标写入 JSONL 文件，一个独立进程监控文件变化并通过 WebSocket 推送，浏览器端 ECharts 渲染实时曲线。

2.3 整体架构与数据流

整套监控系统的数据流分四个环节：训练进程、日志文件、WebSocket 服务、浏览器前端。

为什么要把指标先写文件，而不是在 Callback 里直接发 WebSocket？这是我在最开始就踩过的坑。训练进程是算力密集型任务，如果在 step_end 里同步发网络请求，哪怕只是毫秒级的阻塞，遇到网络抖动就可能拖慢训练速度。文件写入是本地磁盘操作，开销极低，而且天然具备持久化能力，训练崩了之后还能从文件里回放整个训练曲线。独立的 WebSocket 服务进程即使挂了，也不影响训练主流程，重启服务之后它可以继续从文件尾部读数据，相当于断点续传。这套解耦设计带来的稳定性，远大于多写几行代码的成本。

3. 核心代码实践：Callback 采集与实时推送

3.1 训练进程：自定义 Callback 采集指标

MindSpore 的 Callback 机制和很多框架一样，提供step_begin、step_end、epoch_begin、epoch_end这些钩子。我要采集的核心指标有四类：loss、learning rate、吞吐量、梯度范数。其中梯度范数稍微特殊一点，因为它并不在默认的cb_params里，需要在自定义训练循环或者 hook 里额外拿。为了优先保证链路能跑通，我先把 loss、lr、throughput 这三种最容易拿到的指标做进第一版，梯度范数作为一种增强指标放在后面单独说明。

import json import time from mindspore.train.callback import Callback class LiveMonitor(Callback): def __init__(self, log_file='metrics.jsonl', log_interval=10): super().__init__() self.log_file = log_file self.log_interval = log_interval self._step_time = None def epoch_begin(self, run_context): self._step_time = time.time() def step_end(self, run_context): cb_params = run_context.original_args() step = cb_params.cur_step_num loss = self._parse_loss(cb_params.net_outputs) lr = self._parse_lr(cb_params) if step % self.log_interval != 0: return now = time.time() throughput = self.log_interval / (now - self._step_time) if self._step_time else 0.0 self._step_time = now record = { 'step': step, 'loss': loss, 'lr': lr, 'throughput': round(throughput, 2), 'ts': now, } with open(self.log_file, 'a', encoding='utf-8') as f: f.write(json.dumps(record) + '\n') def _parse_loss(self, outputs): if hasattr(outputs, 'asnumpy'): return round(float(outputs.asnumpy()), 6) if isinstance(outputs, (tuple, list)): # 自定义 TrainOneStepCell 时，输出可能是 (loss, ...) return round(float(outputs[0].asnumpy()), 6) return round(float(outputs), 6) def _parse_lr(self, cb_params): opt = cb_params.optimizer if opt is None: return 0.0 lr = opt.learning_rate if hasattr(lr, 'value'): lr = lr.value() try: return round(float(lr.asnumpy()), 8) except Exception: return round(float(lr), 8)

这里有几个细节需要注意。cb_params.net_outputs在不同场景下类型不一样：用Model.train且传了loss_fn时，它通常是 loss 的 Tensor；如果你自定义了TrainOneStepCell，它可能是 tuple，所以_parse_loss里做了兼容。_parse_lr里的opt.learning_rate可能是动态学习率对象，这种对象有value()方法，调用后拿到当前 step 的实际学习率值；也可能直接就是固定数值或者 Tensor，所以包了一层异常处理。通过log_interval控制写入频率很重要，如果每个 step 都写一次，一条 2000 step 的训练就会生成 2000 行 JSON，页面渲染也会越来越卡，一般设成 10 或 20 比较合适。

3.2 中转层：JSONL 文件加 WebSocket 广播

有了 metrics.jsonl 这个文件，接下来需要一个独立的进程把新写入的行推给前端。这里我直接用websockets库实现，逻辑很薄：维护一个连接集合，定时轮询文件尾部的新增内容，广播给所有客户端。

import asyncio import json import os import websockets CONNECTIONS = set() LOG_FILE = 'metrics.jsonl' POLL_INTERVAL = 0.5 async def register(ws): CONNECTIONS.add(ws) try: async for _ in ws: pass finally: CONNECTIONS.remove(ws) async def watch_log(): last_pos = 0 while True: if os.path.exists(LOG_FILE): with open(LOG_FILE, 'r', encoding='utf-8') as f: f.seek(last_pos) lines = f.readlines() last_pos = f.tell() for line in lines: line = line.strip() if line and CONNECTIONS: # 每个连接的 send 都放到任务里并发执行 await asyncio.gather(*[ws.send(line) for ws in CONNECTIONS]) await asyncio.sleep(POLL_INTERVAL) async def main(): async with websockets.serve(register, '0.0.0.0', 8765): await watch_log() if __name__ == '__main__': asyncio.run(main())

这段代码要注意两点。一是websockets.serve的 handler 签名在不同版本里不一样，老版本是async def register(ws, path)，新版本只接收ws一个参数，如果启动时提示参数不匹配，把register改成async def register(ws, path=None)或者只保留一个参数即可。二是asyncio.gather并发发送，因为一个客户端连接卡住不应该影响其他客户端。实际生产环境可以把它做得更健壮，比如加一个发送超时保护，连接断开时从集合里移除，否则异常连接会一直堆积。

3.3 浏览器端：用 ECharts 画实时曲线

前端我选 ECharts，因为它的折线图交互完整，支持缩放、tooltip、多 Y 轴，而且社区庞大，遇到问题好查。页面逻辑很简单：WebSocket 连接服务，收到一条记录就解析成 JSON，然后 push 到对应的数据数组里，再setOption更新图表。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>MindSpore 训练实时监控</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script> </head> <body> <div id="chart" style="width: 100%; height: 600px;"></div> <script> const chart = echarts.init(document.getElementById('chart')); const steps = []; const losses = []; const lrs = []; const throughputs = []; chart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['loss', 'lr', 'throughput'] }, grid: { left: 80, right: 80, top: 50, bottom: 50 }, xAxis: { type: 'category', name: 'step', data: steps }, yAxis: [ { type: 'value', name: 'loss' }, { type: 'value', name: 'lr' }, { type: 'value', name: 'throughput' } ], series: [ { name: 'loss', type: 'line', data: losses, smooth: true, yAxisIndex: 0 }, { name: 'lr', type: 'line', data: lrs, smooth: true, yAxisIndex: 1 }, { name: 'throughput', type: 'line', data: throughputs, smooth: true, yAxisIndex: 2 } ] }); const ws = new WebSocket('ws://localhost:8765'); ws.onmessage = (event) => { const data = JSON.parse(event.data); steps.push(data.step); losses.push(data.loss); lrs.push(data.lr); throughputs.push(data.throughput); // 只保留最近 1000 个点，防止长时间训练把浏览器撑爆 if (steps.length > 1000) { steps.shift(); losses.shift(); lrs.shift(); throughputs.shift(); } chart.setOption({ xAxis: { data: steps }, series: [ { data: losses }, { data: lrs }, { data: throughputs } ] }); }; ws.onerror = (err) => { console.error('WebSocket error:', err); }; </script> </body> </html>

多 Y 轴这里我特意做了分层：loss 放左边第一根轴，lr 和 throughput 放右边第二、第三根轴。原因是 loss 量纲通常是 0 到几，lr 是 1e-4 这种小数，throughput 可能是几百上千，如果全放在一根轴上，小数量级的曲线会被压成一条直线，什么都看不出来。ECharts 的多 Y 轴模式可以很好地解决这个问题，代价是图例和 tooltip 需要花点时间调得顺手。steps.length > 1000这个滑动窗口很重要，Transformer 训练动辄几万 step，数组无限增长会让浏览器渲染帧率掉到个位数，到时候曲线图卡得连鼠标都拖不动。

3.4 在 Transformers 训练脚本中挂载监控

监控模块写好后，接入训练脚本很容易。以 MindSpore Transformers 套件里的模型为例，如果你是用Model.train这种偏底层的 API 训练的，直接在 callbacks 列表里加一个实例就行：

from mindspore import Model from mindspore.train.callback import LossMonitor, TimeMonitor model = Model(network=net, loss_fn=loss_fn, optimizer=optimizer, metrics={'acc': acc_metric}) callbacks = [ LiveMonitor(log_file='./logs/metrics.jsonl', log_interval=20), LossMonitor(per_print_times=20), TimeMonitor() ] model.train(epoch_size, train_dataset, callbacks=callbacks)

如果你用的是套件自带的高层 Trainer 封装，一般也会在初始化参数里暴露callbacks或者trainer.callbacks这类的透传字段，把LiveMonitor实例传进去即可。我有一个习惯：不管用哪种方式，都在训练脚本里单独把log_file参数提出来，方便每次实验写到不同的目录，比如logs/exp001/metrics.jsonl，这样后面回放和对比实验都很方便。VS Code 里跑这整套东西也很顺手，工作区选好装了 MindSpore 的 Python 解释器，左边终端跑训练，右边起 WebSocket 服务，浏览器开监控页，所有操作在一个 IDE 里就能完成。

4. 实战：从迷你 Transformer 到 Deformable DETR

4.1 用迷你 Transformer 快速验证监控链路

监控代码写出来之后，直接拿真实大模型调试链路是不明智的，数据加载和模型初始化太慢，一个问题要等很久才能复现。我先写了一个极简的 Transformer 分类模型，配合随机生成的数据，先把整条链路跑通。这段代码的意义不在模型精度，而是验证 Callback 采集到的数据能稳定出现在浏览器页面上。

import numpy as np import mindspore as ms from mindspore import nn, dataset as ds class MiniTransformer(nn.Cell): def __init__(self, vocab_size=1000, d_model=64, nhead=4, num_layers=2, num_classes=10): super().__init__() self.embedding = nn.Embedding(vocab_size, d_model) self.encoder_layer = nn.TransformerEncoderLayer(d_model, nhead) self.encoder = nn.TransformerEncoder(self.encoder_layer, num_layers) self.classifier = nn.Dense(d_model, num_classes) def construct(self, input_ids): x = self.embedding(input_ids) x = self.encoder(x) x = x.mean(axis=1) return self.classifier(x) def fake_data(num_samples=2000): for _ in range(num_samples): seq = np.random.randint(0, 1000, (32,)).astype(np.int32) label = np.random.randint(0, 10, ()).astype(np.int32) yield seq, label train_dataset = ds.GeneratorDataset(fake_data(), column_names=['input_ids', 'label']).batch(8) net = MiniTransformer() loss_fn = nn.SoftmaxCrossEntropyWithLogits(sparse=True, reduction='mean') optimizer = nn.Adam(net.trainable_params(), learning_rate=1e-3) model = Model(net, loss_fn=loss_fn, optimizer=optimizer) model.train(3, train_dataset, callbacks=[LiveMonitor(log_file='./logs/demo_metrics.jsonl', log_interval=10)])

跑起来之后你会在demo_metrics.jsonl里看到每 10 步一条记录，比如：

{"step": 10, "loss": 2.302, "lr": 0.001, "throughput": 108.5, "ts": 1735387200.12}

如果这一步浏览器页面没有数据，问题基本出在 WebSocket 服务没启动、端口不对或者 JSONL 文件路径不一致。先用命令行curl ws://localhost:8765或者浏览器控制台看 WebSocket 连接状态，可以快速定位是哪一环断了。

4.2 上真实模型：接入 Deformable DETR 微调

迷你模型验证通过后，就可以把同一套监控挂到真实模型上。我这次实验用的是 MindSpore Transformers 套件里的 Deformable DETR 模型做目标检测微调。Deformable DETR 是 DETR 的改进版，把可变形注意力机制引入 Transformer，收敛速度比原始 DETR 快不少，是视觉 Transformer 里很有代表性的检测模型。

接入的核心思路和迷你 Transformer 完全一样，只有两点不同。第一，Deformable DETR 的输出和 loss 结构比分类模型复杂得多，net_outputs可能是一个包含了分类 loss、回归 loss、IoU loss 的 tuple，甚至总 loss 是多个 loss 的加权和。我的LiveMonitor._parse_loss在处理只要第一个元素是总 loss 的 tuple 时是可行的，但如果套件返回的是字典结构，就需要在_parse_loss里做额外适配。第二，检测模型训练时显存占用高，batch size 往往很小，throughput 的绝对数值没有参考价值，它的价值在同一次训练中的相对变化，throughput 曲线突然往下掉，通常说明数据处理有瓶颈。

Deformable DETR 的配置里有一组关键参数直接决定训练曲线长什么样：backbone用 ResNet 还是 Swin，num_queries默认 300，transformer层的d_model默认 256，num_encoder_layers和num_decoder_layers默认各 6，这些配置会直接影响 loss 收敛速度。我习惯在启动训练前把模型的配置文件也留档一份，并把它和 metrics.jsonl 放同一个实验目录，这样回放曲线的时候能迅速对上号。

4.3 从曲线形态反推训练状态

曲线图跑起来之后，重点不是“看着它动”，而是能从形态里读出模型状态。我总结了几个高频场景。

第一个场景最常见：loss 曲线在 warmup 阶段先涨后跌，新手容易误判为模型坏了。很多 Transformer 模型的学习率策略是 warmup 加 cosine decay，warmup 阶段 lr 从很小往上涨，loss 出现一定幅度的抬升是正常的，关键看 warmup 结束之后 loss 是否开始稳定下滑。如果 warmup 都过了 loss 还在持续上升，那才是真有问题。

第二个场景是梯度范数尖峰。我在监控里额外加了一条 grad_norm 曲线，方法是在自定义 TrainOneStepCell 里把梯度的全局范数拼接进输出，或者直接用一个 hook 在反向传播后取梯度。梯度范数的意义在于，它比 loss 更早暴露训练不稳。如果 grad_norm 曲线在几百个 step 的平稳后突然出现一个几十倍于基线的尖峰，那通常意味着某一个 batch 的数据异常或者参数更新步长过大，这时候应该立刻降低 lr，或者在优化器里加梯度裁剪。

第三个场景是 throughput 阶梯式下降。这个我在分布式训练里遇到过，多个 epoch 之后 throughput 从 1200 掉到 600，查了一圈发现是 MindSpore 的数据集对象没有正确执行repeat，导致每个 epoch 结束后重建数据集，重建过程卡住了训练循环。通过实时曲线把 throughput 和 loss 放在一起看，问题定位会快得多。

5. 常见问题与排查技巧实录

5.1 高发问题速查表

这套监控系统我在本地和云服务器上都跑过，也踩过不少坑。下面这张表是我最常遇到的问题和对应解法，可以直接当排查手册用。

5.2 几个容易忽略的细节

第一个细节是日志文件的覆盖策略。我一开始用open(log_file, 'w')，每次启动训练都会清空旧文件。后来发现对比实验回放时需要保留每次实验的完整记录，于是改成'a'追加模式，并且文件名带时间戳或者实验编号。这样同一份代码跑多个实验时，每个实验都有一份独立的 JSONL 记录，复盘时直接按实验 ID 搜索。

第二个细节是 WebSocket 服务的重启问题。如果训练已经跑了一半，WebSocket 服务挂了，重启服务后它从 JSONL 尾部继续读，前面的历史数据不会补发给前端。也就是说，页面上只会有重启之后的新数据。如果需要完整的训练回放，最方便的办法是打开页面后调用一个历史数据接口，先加载已有的 JSONL 内容，再续接实时推送。我实现时是把这两步拆开的：前端先 fetch 一下 JSONL 的静态内容，再建立 WebSocket 连接。这样即使中途打开监控页面，也能看到从开头到现在的完整曲线。

第三个细节是梯度范数的采集。我前面说可以在 TrainOneStepCell 里做，但这个做法在不同 MindSpore 版本里 API 差异不小。我踩过一次坑是升级 MindSpore 之后，自定义 TrainOneStepCell 的梯度计算函数改名了，整个训练脚本直接跑不起来。后来我换了一种更省心的方式：不对训练主流程下手，单独在模型网络的 construct 里返回一个辅助输出。具体做法是给网络的 forward 返回值后面拼一个 loss，然后在 Callback 里同时解析总 loss 和辅助 loss，用两条曲线的差值近似判断梯度状态。这个方案不优雅，但极其稳定，几乎不随框架版本变化而失效。

5.3 关于数据落盘与回放的一点建议

整套监控跑通之后，最让我受益的反而不是“实时”这两个字，而是数据的落盘回放能力。训练中断了，第二天想复盘，直接把对应的 JSONL 文件拖进一个离线页面，整条训练曲线瞬间重现。我甚至可以为了某个异常 step 把曲线局部放大，看它前 50 步到底发生了什么。这个回放能力依赖一个最简单的设计：所有指标都带 step 和时间戳，按行存在纯文本文件里，没有任何二进制格式。如果你要长期积累实验记录，这个设计值得参考。

另外再提一句 MindInsight 的用法。我虽然在“在线监控”场景里自研了一版，但事后分析时还是会用 MindInsight，因为它的细节面板更完善，能看到算子级的数据。我的建议是两者配合：训练中用自研轻量方案做实时看板，训练结束后用 MindInsight 做深度分析。SummaryCollector 的collect_freq参数记得设得大一点，比如 50 或者 100，否则 Summary 文件会膨胀得很快，磁盘爆满的坑我踩过一次。

6. 最后再说几句掏心窝的话

这套监控系统我最常用的一句话是：先看趋势，再定位问题。很多人喜欢把页面做得很炫，堆一堆指标，结果训练的时候盯着曲线图反而更焦虑。我的经验是先保证三条核心曲线：loss、lr、grad_norm，这三条能覆盖训练过程中大多数异常。等你真的遇到瓶颈了，再去加 throughput、显存利用率、数据加载耗时这些辅助指标。

另一个实际体会是，监控代码不要过度设计，能够以最小代价挂进不同训练脚本比功能全面更重要。我现在的做法是把 LiveMonitor、WebSocket 服务、前端页面打包成一个独立的monitor目录，每个实验只需要在训练脚本里加一行from monitor import LiveMonitor，然后传一个日志路径，完事。这样无论是跑 BERT 分类、Deformable DETR 检测还是别的 Transformer 模型，接入成本几乎为零。

最后分享一个小技巧：每次启动长时间训练前，盯着监控页面看前 100 个 step。如果前 100 步的曲线形态就不对，千万不要抱着“再跑跑看”的侥幸心理。训练不会自己变好，只会越跑越歪。前面已经看了曲线图，就不要再赌运气了。