企业官网建设流程全解析

做本地大模型微调的同学，应该都对“训练日志”又爱又恨。你用 llama-factory 把 Qwen、Llama、Mistral 这些模型拉下来，丢进自己的数据里跑 SFT，一跑就是十几个小时，结果 SSH 一断日志全没、loss 悄悄变成 NaN、或者早上起来发现训练早早就 OOM 挂了，只能对着空白的终端发呆。这篇文章我就把自己在实际项目里折腾 llama-factory 日志监控的经验完整捋一遍：日志到底存在哪、哪些指标值得盯、实时监控怎么做、异常告警怎么搭、最后附上高频故障的日志排查思路。内容偏向实操，适合正在用 llama-factory 做微调、并且希望训练过程可控可追溯的工程师。

1. 先搞清llama-factory的日志到底在哪儿

很多人上来就急着写告警脚本、接监控大盘，其实第一步应该先把日志的家底摸清楚。llama-factory 本身不是一个独立的训练框架，它在底层用的是 HuggingFace Transformers 的 Trainer，因此日志体系也是继承过来的：一部分打到终端，一部分写到目录文件，一部分以结构化事件的形式供 TensorBoard 消费。只有把这个分布搞明白了，后面的监控才有依据。

1.1 终端的输出、目录里的 jsonl、TensorBoard 的事件文件

我用不同的方式跑过 llama-factory，结论是一条命令也好、WebUI 界面也好，最终产生的日志都逃不出下面这四类。

第一类是终端 stdout。你用llamafactory-cli train config.yaml拉起训练后，屏幕上会不断滚动 INFO 级别的日志，包括模型加载、数据集切分、每多少步打印一次 loss、以及验证集上的评估结果。训练结束时还会打印一段TrainOutput汇总，里面包含global_step、train_loss这些字段。如果你直接跑 WebUI，这部分日志同样出现在启动 WebUI 的那个终端里。

第二类是训练目录下的trainer_log.jsonl。这是我最看重的文件，它就在你配置的output_dir目录下，每一行是一个 JSON 对象，由 Trainer 在每次日志打印时写入。字段通常是current_steps、total_steps、loss、learning_rate、epoch这些。举个例子，一行日志内容大致是：

{"current_steps": 20, "total_steps": 5000, "loss": 1.823, "learning_rate": 1.5e-4, "epoch": 0.02}

这个文件之所以重要，是因为它天然是结构化的，不需要你再拿正则去抠终端输出，直接按行解析就能做趋势统计和异常告警。WebUI 上那个实时 loss 曲线，背后读的也是这份数据。

第三类是 TensorBoard 事件文件。llama-factory 在配置里写入report_to: tensorboard后，训练过程中会在output_dir/runs下面生成类似events.out.tfevents.*的文件。终端日志只能告诉你“当前这一秒发生了什么”，TensorBoard 能给你完整的时间序列，包括 loss、学习率、梯度范数这些指标的历史曲线。后面我会专门讲怎么把它用起来。

第四类是训练结束后的汇总 JSON。output_dir下还会有train_results.json、all_results.json，里面保存的是训练时长、每步耗时、每秒钟处理的样本数、最终 loss 等统计值。很多做训练复盘的人不知道看这里，其实它比你自己掐表算吞吐量准确得多。

1.2 日志不是越多越好：Info、Debug、Error 的分级理解

刚开始用 llama-factory 时，我习惯把所有日志调到 DEBUG 级别，觉得看到越多越放心。实际跑起来才发现，DEBUG 日志量非常大，模型加载阶段会把每个权重张量的形状都打出来，数据预处理阶段恨不得把每一条样本的 token 序列都铺在屏幕上。对排障偶尔有用，但对长期监控是干扰。

正确的做法是理解 Transformers 的日志分级：INFO 输出关键节点，WARNING 提示可疑情况，ERROR 记录致命错误，CRITICAL 才是真正需要立刻处理的崩溃。llama-factory 默认的级别就是 INFO，我建议日常保留这个级别，通过环境变量可以控制，比如：

export TRANSFORMERS_VERBOSITY=info

真要排查深层次问题，比如某个网络结构输入输出的 shape 对不上、或者 dataset 加载阶段数据维度异常，再临时调成 debug 也不迟。调试完立刻改回来，否则日志文件膨胀速度会吓你一跳。另外要记住一个细节：日志写盘本身是有 I/O 开销的。当logging_steps设得太小，每个 step 都写一次日志，训练吞吐会肉眼可见地下降。我实际对比过，logging_steps=1和logging_steps=20在 7B 模型上的单 step 耗时能差出几个百分点。监控要做的，是把日志频率调到一个“够用但不拖后腿”的节奏。

2. 日志监控的核心指标：别看热闹，要看门道

日志文件里每行都是数字，但它不是流量报表，每一列背后都对应模型训练的某个物理过程。这里我挑几个真正值得盯的指标展开，重点解释它们为什么能被当作判断训练健康度的依据。

2.1 loss曲线：健康训练的几种形态

loss 是所有监控指标里最直观的，但恰恰因为它太直观，很多人反而把它看浅了。我在项目里总结过三种典型形态。

第一种是正常下降：训练初期 loss 下降较快，中后期进入平台期，偶尔有小幅波动。这种曲线对应的日志特征是，trainer_log.jsonl里的 loss 字段总体趋势向下，但相邻 step 之间会有正常的抖动。第二种是发散的曲线，loss 从某个 step 开始突然飙升，之后不回头地涨上去。这时候第一反应应该是去看相同时间点的learning_rate和grad_norm，多半是学习率过大或者梯度爆炸。第三种是过拟合信号：train loss 一路向下，但如果你同时开了验证集，eval loss 在某个阶段开始回升。日志里表现为训练 loss 与评估 loss 走势背离。

这里有个关键提醒：只看终端打印的 loss 是“事后诸葛”，等它在终端肉眼可见地异常时，可能已经过去了成百上千步。所以我的习惯是维护一份 loss 的滚动统计，不要只看单步值，而是看最近 50 步的滑动均值。单步 loss 为 1.82、1.95、1.76 这种波动完全正常，但滑动均值从 1.8 涨到 2.3，就值得立刻暂停训练排查原因了。

2.2 学习率、梯度范数与收敛质量

loss 是结果，学习率和梯度范数是过程信号，它们往往更能说明问题。llama-factory 默认带 warmup，训练开始后学习率会先从接近 0 的区域爬升到峰值，再按 schedule 衰减。如果trainer_log.jsonl里的learning_rate在某个阶段已经掉到 0，说明整个 schedule 走完了，后续训练基本只是在原地微调。这个状态出现在预算不够的收尾阶段是正常的，出现在训练中段就要检查配置里的num_train_epochs和max_steps是否冲突。

梯度范数在 llama-factory 中通过grad_norm字段暴露到 TensorBoard。它的量级和 loss 不完全挂钩，但仍是判断稳定性的重要参考。比如 LoRA 训练中，梯度范数量级通常在个位数到十几之间，突然变成几百甚至上千，基本就是梯度爆炸的前兆。llama-factory 默认开启梯度裁剪，max_grad_norm一般设置为 1.0，日志中表现为异常大的梯度被截断到裁剪阈值，反映到 loss 上可能会出现异常的跳变平台。

我自己习惯在每次训练启动后，先观察前 200 步的learning_rate、grad_norm、loss三条曲线是否同时处于合理区间。如果前 200 步的 grad_norm 就频繁触顶，说明初始学习率偏大，别犹豫，先停掉调参再继续，别浪费后面的几十个小时。

2.3 吞吐指标：tokens/s 和 GPU 利用率的观察方法

很多时候训练没有报错，但你就是觉得“慢”，这种主观感受需要用日志量化。llama-factory 训练结束时写入train_results.json的文件里，有train_samples_per_second、train_steps_per_second、train_runtime这几个字段。更细粒度地看，进度条上显示的X it/s也能反映实时速度。

不过真正要判断“慢在哪”，光看训练日志不够，还得结合硬件层日志。训练过程中我用watch -n 5 nvidia-smi盯 GPU 利用率、显存占用和温度。如果日志显示单 step 耗时很高，但 GPU 利用率只有 30% 甚至更低，问题基本不在计算，而在数据加载。最常见的原因是dataloader_num_workers设得太低、或者磁盘是机械盘读取速度跟不上。反之 GPU 利用率接近 100% 但 loss 没有下降，说明计算在空转，这时候该检查的是模型结构或数据预处理是否存在 bug。

吞吐指标的波动也要结合阶段看。模型刚加载完、第一次进入训练循环时，日志往往会有较大停顿，这是 CUDA 初始化、算子预热、以及第一个 batch 的数据加载合并在一起的“冷启动”，不用慌张。真正需要警惕的是训练跑了几千步之后，吞吐突然从2.0 it/s掉到0.5 it/s，这时候要结合系统日志看看是不是有别的进程抢占资源，或者显存碎片化导致算子变慢。

3. 实操：搭一套能用的实时日志监控流程

讲了半天指标，下面进入实操。我不打算带你搭一套纯属自娱自乐的复杂监控平台，就按照真实项目里最简单可靠的方式，把 llama-factory 的日志“看住”。这里的原则是：能用系统自带命令解决的，就不引入额外组件；能用 tmux 避免的进程管理问题，就不写复杂的守护脚本。

3.1 用 tmux 托底，保证训练和日志都不丢

先解决一个最基础的坑：日志没了，监控也就无从谈起。很多第一次跑 llama-factory 的人习惯用nohup python -u train.py > train.log 2>&1 &把训练丢到后台，然后 SSH 一断，自己倒是能干别的了，结果第二天回来发现进程早被系统清理掉了，或者训练还在跑但你完全不知道它跑得怎么样。

我的推荐是 tmux，它解决的核心问题是“终端会话和 SSH 连接解耦”。具体做法非常无脑：

tmux new -s finetune # 在 tmux 会话里启动训练 llamafactory-cli train config.yaml

需要离开时，按Ctrl-b然后按d就能分离会话，SSH 断开也不影响训练进程。回来后用tmux attach -t finetune重新接上，终端里所有历史日志都还在。如果你维护多个实验，开几个不同的 tmux 会话分别跑，命名规范一点，比如finetune-qwen7b、finetune-llama3，管理起来非常省心。

tmux 不只保证进程不丢，它还能让你随时回翻日志。训练跑了一天后，你想看看三个小时前的 loss 是什么状态，直接在会话里往上翻屏即可，不用去 log 文件里搜半天。当然如果你确实习惯后台运行方式，记住python -u的-u参数一定不能少，它强制 Python 不缓冲输出，否则日志会攒在内存缓冲区里，等训练结束或者写满才一次性落盘，监控脚本看到的数据会严重滞后。

3.2 tail + watch + tee：轻量可靠的流式监控组合

监控的实时性很重要，但大部分人不需要 Grafana 那种秒级刷新的大屏。我的常用组合是三个命令：tail看日志尾部、watch定时刷新硬件状态、tee在需要时把终端输出同时写到文件。

# 实时盯训练日志，重点关注 loss 和 step 进度 tail -f experiments/exp_001/trainer_log.jsonl # 每 5 秒刷新一次 GPU 状态 watch -n 5 nvidia-smi # 同时看训练日志和系统负载 tail -f experiments/exp_001/trainer_log.jsonl & top -d 5

有人可能觉得tail -f直接看 jsonl 不够友好，毕竟里面是一行行 JSON，看久了眼睛酸。这里推荐一个小技巧：如果环境里有jq命令，可以做一个“只提取关键字段”的流式视图：

tail -f experiments/exp_001/trainer_log.jsonl | jq -r '"step=\(.current_steps) loss=\(.loss) lr=\(.learning_rate)"'

输出就变成一行行干净明了的文本。讨厌 JSON 格式的同学可以把这个命令做成 shell alias，每次训练直接敲它。

tee的用法是当你从 WebUI 启动训练但又想同时保留完整日志时才需要。llama-factory 的 WebUI 训练过程会在启动服务的终端打印日志，如果想让训练日志永久落盘，可以这么做：

llamafactory-webui 2>&1 | tee -a experiments/exp_001/webui_train.log

注意-a参数是追加模式，避免每次重启 WebUI 把上一次的日志覆盖掉。

3.3 TensorBoard 的启动与远程访问

TensorBoard 我不是每天都盯，但每次开始一个稍微大点的训练任务，我一定会在后台把它拉起来。配置层面，在 llama-factory 的 YAML 里加上一行：

report_to: tensorboard

训练开始后，output_dir下会出现runs目录。启动 TensorBoard 的命令极简：

tensorboard --logdir experiments/exp_001/runs --port 6006

然后浏览器访问http://服务器IP:6006就能看到曲线。如果你是远程服务器，出于安全考虑建议不要直接绑到公网，而是在本地机器上做 SSH 隧道：

ssh -L 6006:127.0.0.1:6006 user@your_server

本地浏览器访问http://127.0.0.1:6006即可。这个方式实际用下来最稳，不用在服务器上额外开防火墙端口。

TensorBoard 的价值在于它能同时展示多条曲线，尤其是把 train loss 和 eval loss 放一起看，过拟合信号一眼就能识别出来。这是终端日志做不到的。我还会把不同实验的输出目录都放到同一个--logdir下，TensorBoard 会自动按实验名分组对比，调参时非常有帮助。

3.4 容器/远程集群场景的日志监控补充

如果你在 Docker 容器里跑 llama-factory，日志监控多两个注意事项。第一，容器日志默认通过 Docker 的 json-file driver 管理，docker logs -f 容器名可以直接看，但你无法方便地按文件路径去 tail，尤其是trainer_log.jsonl这种训练过程生成的文件。所以启动容器时一定要把训练输出目录挂载到宿主机：

docker run -it --gpus all \ -v /mnt/training_logs:/workspace/experiments \ llm-finetune:latest \ llamafactory-cli train config.yaml

这样宿主机上/mnt/training_logs就能直接访问训练所有的日志文件，监控脚本照常工作。第二，容器重启后日志默认会保留，但如果容器重建，所有未挂载目录里的文件都会消失。血的教训：日志目录不挂载就等于白跑。

Kubernetes 环境下的思路类似，kubectl logs -f pod方便是方便，但 Pod 一旦被驱逐或重建，日志就没了。生产级做法是启用集群级的日志采集，或者至少把output_dir放到持久卷。Slurm 这类 HPC 集群也有自己的套路，作业脚本里记得把 stdout 重定向到实验目录：

#SBATCH --output=experiments/exp_001/slurm_%j.log

这样每个作业的日志按 ID 分开存，排查时直接对号入座。

4. 日志落盘、保留策略与异常告警

前面讲的是“怎么实时看”，这一节讲“怎么留证据、怎么主动发现问题”。训练过程是几个小时到几天的事，日志不能只存在于终端里，它必须变成可控的文件资产，并且能在异常出现时主动通知你，而不是等你某天偶然瞄一眼屏幕才发现早就完蛋了。

4.1 日志文件命名与按训练周期归档

我见过太多人把日志丢在output_dir根目录随手覆盖，训练完想复盘时，之前几次实验的日志已经被冲掉了。日志管理的第一步是约定目录命名。我的标准结构大概长这样：

experiments/ exp_001/ config.yaml trainer_log.jsonl runs/ events.out.tfevents.* train_results.json logs/ train_20250412_1023.log train_20250413_1830.log

在启动每次训练前，把当前配置文件和启动命令固化下来，训练结束后把终端完整输出重定向到logs目录，文件名带上日期。这样做的好处是，周末回看一周前调参踩坑的过程，你能准确还原当时的模型配置、数据版本和 loss 走势，而不是只记得一个模糊的“好像效果不错”。

我自己的习惯是每次训练结束，在logs目录下生成一个超短的训练摘要：

{ echo "训练时间: $(date +%Y-%m-%d_%H:%M:%S)" echo "任务: exp_001" echo "最终 train_loss: $(jq '.train_loss' experiments/exp_001/train_results.json)" echo "耗时: $(jq '.train_runtime' experiments/exp_001/train_results.json) 秒" } > experiments/exp_001/logs/summary.txt

这个摘要文件不占空间，但复盘效率提升巨大。不用打开 TensorBoard 也知道上次跑到什么程度。

4.2 简单实用的异常检测与告警脚本

告警不是 AI 平台的专利，哪怕你只是在本机做实验，用一个简单的 Python 脚本轮询日志，都能帮你省下大量守在屏幕前的时间。我写过一个很简化的版本，核心思路是不断读取trainer_log.jsonl新增的行，检测 NaN loss，连续多次触发就调用 Webhook 发送告警。

#!/usr/bin/env python3 import json import os import time import urllib.request TRAIN_LOG = "experiments/exp_001/trainer_log.jsonl" INTERVAL = 30 # 轮询间隔，单位秒 NAN_THRESHOLD = 3 # 连续多少次 NaN 才告警 WEBHOOK_URL = "https://your-webhook.example.com/send" nan_count = 0 position = os.path.getsize(TRAIN_LOG) def send_message(text): data = json.dumps({"text": text}).encode("utf-8") req = urllib.request.Request( WEBHOOK_URL, data=data, headers={"Content-Type": "application/json"}, ) urllib.request.urlopen(req, timeout=5) while True: with open(TRAIN_LOG, "r", encoding="utf-8") as f: f.seek(position) lines = f.readlines() position = f.tell() for line in lines: try: entry = json.loads(line) except json.JSONDecodeError: continue if "loss" in entry: loss = entry["loss"] if loss != loss: # NaN 判断，NaN 不等于自身 nan_count += 1 else: nan_count = 0 if nan_count >= NAN_THRESHOLD: send_message("llama-factory 训练 loss 连续出现 NaN，请立即检查！") nan_count = 0 time.sleep(INTERVAL)

这个脚本属于最小可用版本，生产环境还得考虑日志轮转导致的文件偏移失效、多个训练任务并发等问题。但思路是对的：监控脚本不用复杂，把最致命的几种异常盯住，就足以避免大部分训练事故。扩展方向也很明确：检测CUDA out of memory关键字、检测 loss 连续多步上涨、检测日志文件停止更新。

Webhook 的接收端可以用钉钉机器人、飞书机器人，甚至是一个简单的 Slack Incoming Webhook。公司内部如果消息渠道敏感，用邮件也好过没有。关键点在于告警要“可操作”：消息里必须写明实验目录、疑似原因、以及建议检查的命令，不然半夜收到一条“loss 异常”根本不知道该干嘛。

4.3 磁盘空间与日志轮转

日志监控还有一个容易被忽略的维度：日志本身的存储。TensorBoard 事件文件体积不大，但累积多了也占空间；终端重定向日志如果 DEBUG 级别，一天能写几个 GB。更麻烦的是，如果日志落盘的位置和训练输出目录在同一个磁盘，日志写满磁盘，训练进程会直接崩溃。

我的经验是给日志文件设置保留周期。可以用 logrotate，也可以用一个简单的 cron 清理：

# 每周日凌晨清理 7 天前的旧日志 0 3 * * 0 find /data/experiments -name "*.log" -mtime +7 -delete

TensorBoard 的 events 文件不需要手动删，它很小，一个训练任务通常只有几 MB 到几十 MB，但如果启动很多次实验且都输出到同一目录，残留文件会让 TensorBoard 的对比视图变得混乱。建议每次实验用独立目录，或者干脆定期把不再需要的 events 目录删掉。留存策略没有标准答案，核心原则只有一个：日志要留得住、查得到，但不能让它反过来成为磁盘故障的诱因。

5. 高频故障的日志排查实录

最后这节是重头戏，把我在实际项目中遇到过、也帮别人排查过的高频训练故障，按“日志现象 -> 排查思路 -> 解决方案”的方式列出来。每一条都是真金白银踩过坑换来的，建议收藏。

5.1 loss 为 NaN 或梯度爆炸

这是 llama-factory 训练里最经典的翻车现场。日志层面的典型表现是：trainer_log.jsonl里的 loss 突然变成了null或NaN，终端里显示的训练步数还在走但 loss 永远是 NaN，TensorBoard 的 loss 曲线在某一步直接断掉。

排查顺序我一般这么走。第一步看数据，先确认 dataset 里有没有空样本、超长样本、或者某个字段缺失导致 tokenizer 处理异常。有些异常的 loss 根因是labels设置不对，模型预测的 token 数和标签数对不上。第二步看学习率，如果 warmup 峰值太高，Transformer 结构很容易在深层出现激活值爆炸。第三步看精度，fp16 训练时梯度容易下溢，llama-factory 配置里把bf16改成true能解决相当一部分 NaN 问题。第四步才考虑模型结构本身，比如某些自定义 loss 在零除或对数变换时产生 IEEE 非规范数。

排查时有个技巧：善用日志时间线。trainer_log.jsonl里既有 loss 字段也有learning_rate字段，把 NaN 出现的那一步和当时的 lr、grad_norm 对齐，基本就能定位是“学习率过大”还是“数据存在问题”。如果 NaN 出现在前几步，大概率是数据或初始化问题；如果跑了几百步才出现，更可能是中途某个 batch 触发的异常。

5.2 CUDA OOM 的日志定位

OOM 的日志特征非常明显，终端会打印大段红色 Traceback，最后一句通常包含CUDA out of memory。更细节的信息在显存分配器日志里，比如RuntimeError: CUDA out of memory. Tried to allocate 512.00 MiB (GPU 0; 7.80 GiB total capacity; 6.90 GiB already allocated; ...)，这行能告诉我们：申请了多少显存、还剩多少显存、当时 GPU 已经被谁占满。

解决 OOM 不能只看表面。常见的处理办法是调小per_device_train_batch_size，把gradient_accumulation_steps相应调大，这样全局 batch size 不变，但单步显存占用大幅下降。Llama-7B 这类模型如果还想在消费级显卡上跑通，QLoRA 的use_4bit配置基本是标配。我遇到过一个隐蔽问题：同一个机器上别人跑着别的任务，我的训练启动时还能过，跑到中途对方任务开始吃显存，我的训练就直接 OOM。这种情况日志里不会显示任何你的模型的问题，纯粹是资源竞争，所以 OOM 排查一定要先nvidia-smi看当前显存占用，再谈调参。

5.3 训练卡死、日志长时间不刷新

比 NaN 更让人崩溃的是“看起来什么都没发生”。终端日志停在某一行不再更新，GPU 利用率掉到 0%，CPU 占用却很高。这种卡死通常不是训练计算卡住，而是数据加载或日志系统卡住。

我遇到过的原因有三个比较典型。第一是num_workers设太高，DataLoader 的子进程在共享内存上内卷，直接的表现就是 CPU 跑满但训练进度纹丝不动。把这个值降到 2 或 4 能解决大多数情况。第二是数据加载阶段某个样本预处理巨慢，比如一个超长文本字段在 tokenize 时没有限制 max_length，处理一个样本要几十秒。第三是磁盘 I/O 瓶颈，机械盘上的海量小文件让 DataLoader 每次读取都在等磁盘。看到日志停在Map: ... it/s或Loading ...这类阶段，优先检查数据侧而不是模型侧。

排查卡死还有一个利器：py-spy dump --pid <训练进程PID>。它能打印出 Python 进程当前正在执行的函数调用栈，帮你看到底是卡在 DataLoader 的__getitem__里，还是卡在模型的forward中。这东西在常规文档里很少被提到，但实际排障效率极高。我这里附带提一句：如果是 CUDA 图捕获或算子编译导致的“秒级假死”，比如第一次执行某个 kernel 时触发编译优化，等几十秒又恢复正常，那不算故障，观察后续日志是否继续推进即可。

5.4 断点续训日志的核对方法与实操经验

llama-factory 支持断点续训，这是个好用但容易出错的功能。日志层面，启用续训后启动日志会多出一行类似Continuing training from checkpoint, will skip to saved global_step的信息。看到这行日志，说明 Trainer 已经检测到 checkpoint 并会接着上次的全局步数继续跑。

这里我踩过一个大坑：续训后 loss 莫名其妙跳高。正常情况下，从 checkpoint 恢复训练后，loss 相比暂停时的水平会有小幅回弹，因为重启时 DataLoader 顺序、随机状态无法完全复现，但回弹幅度应该在 5% 以内。如果恢复后 loss 直接涨了 0.5 以上，那大概率是 checkpoint 里的 optimizer 状态没有正确加载，或者resume_from_checkpoint参数写成了手动指定目录，但那个目录里根本没有完整的trainer_state.json。核对方法很直接：打开 checkpoint 目录下的trainer_state.json，看里面的global_step和日志里显示的是否一致，并且确认 checkpoint 里有optimizer.pt、scheduler.pt文件，缺一个都不能算完整续训。

顺带分享一个我个人的实用技巧：每次训练开始前，我会在output_dir下放一个README.md，记录启动命令、数据路径、关键超参和本次想验证的问题。训练过程中如果日志出现异常，我会把当时的现象和自己的想法追加进去。这样一个实验做下来，日志、配置、复盘笔记全在一个目录里，后续写技术报告或者给同事交接时，材料是自洽的，不需要再靠记忆拼凑。

说实话，折腾了这么久日志监控，我现在最依赖的反而不是那些花哨的可视化面板，而是trainer_log.jsonl这个结构化文件和一套能自动盯关键异常的脚本。日志监控这件事，本质不是让你变成一个整天盯着终端的人，而是让你在灾难发生前十分钟就能收到通知，把几十个小时的训练从“听天由命”变成“心中有数”。后面的改进方向还很多，比如把多卡训练的日志按 rank 聚合、把多次实验的指标汇总成横向对比表，但这些都是在前面这套基础能力之上锦上添花的事。先把基础打牢，训练日志这座矿，越挖越有料。