狐狸晨曦不少朋友第一次拿到 EchoFree 项目时，第一反应都是先找 README，然后照着命令敲一遍，发现能跑通单机，很开心。等想上多卡、搞多机训练，或者往端边云协同的场景迁移时，就开始各种报错。说实话，这不算笨，因为从命令行训练到分布式训练，中间隔着的不是几条命令，而是对一套并行体系的理解。EchoFree 这个项目名字听着像语音方向，实际上它是一套可以灵活跑在单机、多机甚至端侧云侧协同环境下的训练框架，很多人卡在“能从命令行启动”到“能正确做分布式训练”这个进阶过程里。
这篇就围绕 EchoFree 的训练启动展开，从命令行入口讲到分布式训练的完整链路。无论你是刚把环境装好、准备敲第一条训练命令的小白，还是已经单卡跑通想往多机扩展的老手，都能在里面找到对应的章节。我会把每一步为什么这样做、参数背后的用意、以及实际踩过的坑都讲透，包含可复现的命令和配置，尽量让你看完就能直接动手。
1. 先弄清楚 EchoFree 的训练链路：单卡到多卡的演进逻辑
1.1 打开项目目录后，训练入口在哪里
第一次解压或者 git clone 完 EchoFree，最好先花十分钟把项目结构过一遍。不要急着跑命令，因为训练框架类项目的目录组织方式，基本决定了你后面排查问题的路径。
常规的 EchoFree 项目主目录下会有这几个核心部分：
main.py或train.py，这是训练的统一入口；configs/目录，存放各种训练配置，通常是 yaml 或 json；models/、datasets/、utils/这些模块文件夹；- 偶尔会有
scripts/目录，里面放着封装好的启动脚本。
你可能会问，既然有了训练入口，为什么不直接双击运行，还要搞一套命令行参数？这个问题的答案，恰好就是 EchoFree 被设计成适合多场景的原因。训练一个模型往往不是“点一下按钮”就能完成的，你需要动态指定用哪块 GPU、加载哪份配置、跑多少个 epoch、从哪里续训，这些如果写死在代码里，每次调整都要改源码，既不安全也不可维护。命令行参数，就是给训练过程留出来的“旋钮”。
在 EchoFree 里，命令行参数的解析一般集中在入口文件里，用 argparse 或者 click 这类库实现。常见参数包括 --config 指定配置文件路径、--local_rank 指定分布式训练时的局部进程编号、--resume 指定断点续训路径。你先记住这几个关键词，后面会反复用到。
1.2 单卡训练背后发生了什么
当你在终端里敲下这行命令：
bash复制python train.py --config configs/echo_free_base.yaml
看起来只是启动了一个 Python 进程，但 EchoFree 内部做的事情是层层递进的。第一步，解析命令行参数，把 echo_free_base.yaml 里的训练超参数、模型结构、数据路径读进来，合并成一个全局配置对象。第二步，初始化日志系统和随机种子，保证实验可复现。第三步，加载数据集和数据加载器，开启子进程预取数据。第四步，实例化模型，把参数放到指定设备上。第五步，进入训练循环，每个 step 里做前向传播、计算损失、反向传播、参数更新。
值得留意的是，即使在单卡模式下，EchoFree 也会初始化分布式训练所需的一些环境变量。这不是多余动作，而是为了让代码在单卡和多卡之间切换时保持一致。它通常会判断环境中是否设置了 RANK、WORLD_SIZE 这类变量，如果没设置，就默认当成单卡世界来处理。这个设计思路很值得学习：分布式训练不是另一套代码，而是同一套代码在不同启动方式下的表现。
所以我的建议是，一开始不要直接上多卡。先把单卡跑通，用一个小数据集或者小模型配置走通全流程，确认环境、依赖、代码版本都没问题，再去看分布式的部分。顺序反了，你很难判断报错到底是环境问题还是并行代码问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 命令行跑通第一版：单机单卡实战
2.1 环境准备里最容易翻车的三个点
EchoFree 依赖的 Python 包通常会写进 requirements.txt 或者 environment.yml。但环境装上不等于能用，这里有几个高频翻车点需要你特别留意。
第一个是 CUDA 版本与 PyTorch 版本的匹配问题。很多人直接 pip install torch 装了默认版本，结果跑起来发现 CUDA 不可用，或者报了 “No kernel image is available” 这种错误。EchoFree 对算子的编译是有版本要求的，装 PyTorch 前，先去官网选好与你的 NVIDIA 驱动匹配的 CUDA 版本，再安装对应轮子。
bash复制# 检查本机 CUDA 是否可用
python -c "import torch; print(torch.cuda.is_available()); print(torch.version.cuda)"
如果输出 False，先不要怀疑代码，九成是 PyTorch 的 CUDA 版本和驱动对不上。
第二个是显存不足的问题。EchoFree 的默认配置通常按 24GB 显存设计，如果你只有 8GB 或者 12GB 显存，加载就会 OOM。解决方案是先用小 batch size 跑通，再逐步调大。命令行里一般会支持覆盖配置文件中的参数，比如：
bash复制python train.py --config configs/echo_free_base.yaml --train.batch_size 4
第三个是数据集路径问题。EchoFree 的配置里一般会有 data.root 或者 train_data.path 这样的字段，如果不改成你本机的数据路径，启动后会在数据加载阶段报 FileNotFoundError，而且有时候报错信息会被日志系统吞掉，看起来像是模型问题，实际上是数据没找到。先确认数据路径，再谈训练。
2.2 从配置文件到训练命令的映射关系
拿到 EchoFree 的配置文件后，不要急着改，先读懂字段含义。一套典型的配置长这样：
yaml复制model:
name: echo_free_base
hidden_size: 768
num_layers: 12
train:
batch_size: 16
epochs: 50
learning_rate: 1e-4
save_interval: 5
data:
root: /data/echo_free
num_workers: 4
dist:
backend: nccl
init_method: env://
命令行启动时，EchoFree 支持两种方式覆盖配置。一种是用一个大的 --config 指定整个配置，另一种是在命令行后面追加参数来覆盖 yaml 中的特定字段，类似 --train.learning_rate 5e-5 这种带点号的写法。这个约定的好处是，你不必为每次实验都新建一个配置文件，只需要在启动命令里做微调。
注意：如果你修改了配置但训练结果没变化，优先检查命令行参数的解析逻辑。很多时候是 EchoFree 将配置文件作为优先级最高的来源，命令行参数根本没被合并进去。确认方法是在训练启动的日志中打印完整配置对象，看实际生效的值。
2.3 最小训练命令与输出判读
跑通的最小命令实际上很简单：
bash复制cd EchoFree
python train.py --config configs/echo_free_small.yaml
如果配置合理，你会依次看到几类输出信息。第一类是环境信息，包括 PyTorch 版本、检测到的 GPU 数量、当前进程的 rank 和 world size，这在你后面跑分布式时很重要，确认是否进入了预期的并行模式。第二类是配置摘要，把当前所有参数打印出来。第三类是数据集加载信息，比如样本总数、类别数。第四类就是训练迭代日志，一般格式是 epoch, step, loss, lr, throughput 之类的组合。
我见过不少人卡在“日志一直不出现”这个阶段。第一轮迭代前可能要经历数据集的加载和预处理，如果数据集很大，等待几分钟是正常的。但如果超过十分钟还没有任何训练日志输出，就要怀疑是数据加载阶段出了问题。这时候可以先按暂停键，看看 CPU 和磁盘 IO 是否异常，如果磁盘 IO 很低而 CPU 很高，通常是数据预处理逻辑存在瓶颈。
2.4 验证训练真的没有空转
训练启动后，光看日志不够，还得确认模型权重确实在更新。一个非常有效的验证方法，是看 loss 值是否在正常范围内波动。如果 loss 从第一步开始就一直是同一个数字，甚至在第一次迭代后出现 nan，往往不是训练未启动，而是配置或者数据出了问题。
更直观的方式，是用 GPU 监控命令：
bash复制nvidia-smi -l 1
观察显存占用和 GPU 利用率，如果 GPU-Util 持续在 90% 以上，说明计算确实在进行。如果 GPU-Util 在 0% 和 100% 之间反复横跳，大概率是数据加载速度跟不上计算速度，后面我们会专门讲这个问题。
单卡跑通之后，顺手做一个 checkpoint 保存和断点续训测试。找到配置里的 save_interval，等第一个 checkpoint 落盘后，用 --resume 参数从它恢复训练，确认 loss 延续而非从头开始。这个能力是分布式训练的基础保障，不要等到上了多卡才发现断点续训根本不能用，那时候排查成本会高很多。
3. 从单卡到多卡：分布式训练必须理解的四件事
3.1 rank、local_rank、world_size 到底在表达什么
单卡时代的编程模型是整个程序只有一个进程，但分布式训练是多个进程同时在跑同一个脚本。这时候你就需要一套“寻址系统”来区分每个进程的身份，这就是 rank、local_rank 和 world_size。
- world_size 表示当前参与训练的总进程数，也就是你把模型切成了多少份并行工作；
- rank 是全局唯一编号，范围从 0 到 world_size-1，它决定了进程在整个集群中的身份，rank 0 通常扮演全局协调者的角色；
- local_rank 是节点内部的编号，如果一台机器有 8 张卡，那么在这台机器上启动的 8 个进程的 local_rank 就是 0 到 7。
可以做个类比：world_size 是整个公司的员工总数，rank 是工号，local_rank 则是你在分公司内部的编号。不同分公司可以有相同的内部分号，但工号在全公司唯一。
在 EchoFree 的训练脚本里，你会经常看到类似 torch.distributed.get_rank() 的调用。它的作用就是让每个进程知道自己是几号，从而决定处理哪一部分数据或者负责哪一部分模型参数。常见的用法包括：只有 rank 0 进程打印日志和保存 checkpoint，避免多个进程同时写文件导致冲突；只在 rank 0 上执行验证集评估，防止重复计算。
3.2 三种并行策略怎么选：数据并行、模型并行、流水并行
很多教程直接把分布式训练等同于“把 batch 分给多张卡”，其实这只是数据并行。EchoFree 涉及的并行策略，至少要分清三种。
数据并行是最容易理解的：每张卡复制一份完整的模型，但每次读取不同的数据子集，然后通过梯度同步机制保持所有副本参数一致。实现上，前向传播和反向传播都是独立的，唯独在反向传播结束后，需要对梯度做一次全局同步，EchoFree 默认用的是 AllReduce。
模型并行则是把一个大模型切分成多段，每张卡负责存储和计算其中一部分。由于层与层之间存在依赖关系，前向传播时数据需要按顺序经过所有卡，通信量和等待时间都更大。这种方案只在模型大到单卡显存放不下时才需要。
流水并行可以看成模型并行的进阶版：把不同的层分配给不同的设备，同时让多个微批次交错进入流水线，让每张卡在等待前序结果时也能继续算自己的活。在 EchoFree 里，如果模型超过单卡承载能力，一般建议先试流水并行而不是纯模型并行，因为通信模式来得更规整、更稳定。
不过对于绝大多数 EchoFree 的训练任务来说，数据并行已经足够。只有当单卡显存真的放不下模型时，才需要考虑另外两种。
3.3 通信后端选型：NCCL 与 Gloo 的适配场景
进程之间需要同步梯度，就必须有一个通信后端来传输数据。EchoFree 常用的后端主要有两个：NCCL 和 Gloo。
NCCL 是 NVIDIA 提供的集合通信库，它专门针对 GPU 之间的高速通信做了深度优化，支持机房内部的高带宽传输，是 GPU 训练场景下的默认选择。它的底层会直接使用 NVIDIA 的私有连接技术，比如 NVLink、InfiniBand，所以在同机多卡或者同集群多机场景下性能非常出色。
Gloo 则是一个更通用的通信库，支持 CPU 和 GPU，但性能上不如 NCCL 针对 NVIDIA 硬件的调优。它通常在无法使用 NCCL 的环境下作为后备方案，比如没有 NVIDIA GPU、需要纯 CPU 调试、或者 NCCL 在当前网络架构下无法正常通信的情况。
在 EchoFree 启动时，环境变量 GLOO_SOCKET_IFNAME 或者 NCCL_SOCKET_IFNAME 的配置很重要。如果机器有多个网络接口，比如一块管理网卡和一块计算网卡，通信库如果选错了接口，就会导致跨机通信失败或者性能极差。判断方法是在启动前用 ip addr 查看网卡名称，然后在启动命令里显式指定：
bash复制export NCCL_SOCKET_IFNAME=eth0
export GLOO_SOCKET_IFNAME=eth0
3.4 环境变量是如何被多机自动注入的
EchoFree 在多机训练时并不需要手动在每台机器上逐个设置 rank，而是通过启动器向每个进程注入一组标准环境变量。这也是 init_method=env:// 这种初始化方式的基础。
当使用 torchrun 或者 torch.distributed.launch 启动时，启动器会自动设置 MASTER_ADDR、MASTER_PORT、WORLD_SIZE、RANK、LOCAL_RANK 等环境变量，然后每个进程调用 init_process_group 时从这些环境变量读取信息。你不需要在自己的 shell 里手动设置它们，这与早期手动设置的方式是不同的。
这个行为意味着：你在写代码时，不要自己硬编码 os.environ["RANK"] 这类取值，也不要手动构造环境变量，而是统一从 torch.distributed 提供的接口获取。EchoFree 内部封装了这些逻辑，但如果你在自己写的脚本里做了多余的事情，很容易破坏启动器的注入行为。
4. EchoFree 分布式训练启动实操：从 torchrun 到多机部署
4.1 单机多卡启动：torchrun 的正确打开方式
现代 PyTorch 已经不太推荐直接用 python train.py 配合 --local_rank 的方式来启动分布式任务，而是推荐使用 torchrun 这个命令作为启动器。它最大的好处是会帮你管理进程的生命周期，包括错误传播和自动重启。
bash复制torchrun --nproc_per_node=4 train.py --config configs/echo_free_base.yaml
这行命令的含义是：在本地启动 4 个训练进程，每个进程对应一张 GPU。你可以用 CUDA_VISIBLE_DEVICES 来控制使用哪些卡：
bash复制CUDA_VISIBLE_DEVICES=0,1,2,3 torchrun --nproc_per_node=4 train.py --config configs/echo_free_base.yaml
要注意的是，有了 torchrun 后，--local_rank 不再需要手动传入。因为启动器会自动设置 LOCAL_RANK 环境变量，EchoFree 内部会正确解析。如果你是在旧版本代码里手动传 --local_rank，那就得改成从 os.environ["LOCAL_RANK"] 读取，否则会报参数冲突的错误。
启动后，你会在终端里看到 4 组日志，它们分别来自 4 个进程。这时候判断是否正常的标准，和单卡时不同。你不仅要看 loss 是否下降，还要确认 4 个进程是否都在工作、它们的梯度同步是否正常。最简单的方式是看训练日志里 rank 编号是否正确，如果所有日志都显示 rank 0，那说明进程通信初始化失败。
4.2 多机多卡：master_addr 与 master_port 的设置细节
多机训练比单机多卡又多了一层复杂度。节点之间需要通过网络通信，所以必须指定一个“主节点”作为协调者。
假设你有两台机器，机器 A 的 IP 是 192.168.1.10，机器 B 的 IP 是 192.168.1.11，每台机器 4 张卡。那么机器 A 上运行：
bash复制torchrun --nnodes=2 --nproc_per_node=4 --master_addr=192.168.1.10 --master_port=29500 train.py --config configs/echo_free_base.yaml
机器 B 上运行：
bash复制torchrun --nnodes=2 --nproc_per_node=4 --master_addr=192.168.1.10 --master_port=29500 train.py --config configs/echo_free_base.yaml
注意两条命令的区别，只有 master_addr 指向主节点这个行为是一致的。启动顺序上，一定要先启动主节点所在机器，再启动其他机器。如果从节点先启动，它会因为找不到协调者而一直等待，最终报连接超时。
一个常见的误区是，master_addr 填的是主节点的外网 IP 或者主机名。内网训练集群中，正确填法应该是机器间的内网通信地址。如果不确定，先在两台机器上互相执行 ping 192.168.1.10 测试连通性，再检查防火墙是否放行了 master_port 对应的端口。
注意：master_port 千万别用默认的
None，也就是不指定端口。多机环境下，如果多组任务同时运行，会因端口冲突导致初始化失败。建议每次任务都设置一个不常用且独立的端口号，比如 29501、29502，并确保所有节点的端口一致。
4.3 端边云协同：EchoFree 在真实场景中的部署训练分工
EchoFree 这个名字里的 Echo，其实已经暗示了它在语音交互或者回声消除这类场景中的定位。结合“端边云协同的大小模型分布式训练和部署”这个方向，它的训练并不是只存在于数据中心里的。
端边云协同的含义是：端侧设备（手机、音箱、嵌入式设备）部署轻量小模型，负责实时响应和初步处理；边缘节点负责中等规模模型的推理和增量更新；云侧拥有大规模算力，负责训练大模型，并把蒸馏或者量化后的小模型下发到端侧。
这给训练链路提出了额外的要求。EchoFree 在云侧训练大模型，可以用分布式训练把 batch 切得非常开；但它同时要支持把训练产物导出为端侧能跑的格式，比如 TensorRT、ONNX 或者量化后的 TFLite。在训练脚本里，这通常表现为一个导出阶段，会在 checkpoint 保存后附带执行一次模型转换和校验。
如果你需要在这种链路中做增量训练或者联邦微调，需要注意数据分布问题。端侧上传到云侧的数据通常是小批量的、非独立同分布的，EchoFree 里一般会配套数据重采样或者领域自适应模块。这里不展开太多算法细节，但要提醒的是：部署前一定要做端侧推理和云侧训练之间的精度对齐测试，这是整个协同链路里最容易出偏差的地方。
4.4 训练脚本里必须做的三个代码改动
从单卡脚本改成分布式训练，不只是改启动命令。EchoFree 训练脚本内部如果没做对应改造，即使在多卡环境下启动也会报错或者训练结果错误。
第一个改动是初始化进程组。在模型加载和数据加载之前，调用 init_process_group，并传入合适的后端和初始化方式。EchoFree 通常在入口函数里封装了这个逻辑，但你需要确认它是在创建 DataLoader 之前完成的。
第二个改动是改造 DataLoader 的数据采样器。普通 DataLoader 会把整个数据集按顺序分给当前进程，但在分布式训练中，每个进程只应该看到数据的一部分，而且所有进程加起来刚好覆盖完整数据集。这需要用到 DistributedSampler，EchoFree 的数据加载模块一般会检查 world size 并自动切换到它。
第三个改动是模型参数的同步和 checkpoint 的保存逻辑。EchoFree 中，保存 checkpoint 时不能每个进程都写文件，一般用 rank 0 进程来写。另外，为了避免训练过程中的微小数值差异在不同进程中扩散，有的配置还会在反向传播后做梯度裁剪和梯度归一化。你的训练脚本里，这三个位置都必须显式处理，否则分布式训练即使不报错，也挺容易产生精度问题。
5. 训练中我踩过的坑与排查手段
5.1 卡死在 all_reduce 环节的排查思路
多卡训练里最让人崩溃的问题之一，是程序在前几个 step 还正常，然后突然停住不动，GPU 利用率下降，任务像死了一样。这类问题里，常见原因是某个进程提前退出，导致其它进程在集合通信过程中一直等待。
EchoFree 用了 AllReduce 做梯度同步，它的特点是：所有进程必须同时参与，只要有一个进程掉队或者退出，全体进程就会一直阻塞等待。所以排查的第一步，是确认每个进程是否都存活、都在正常推进日志。常用的命令是 ps aux | grep python 看进程数量，再用 nvidia-smi 看每张卡上是否有进程占用。
第二步是确认各进程的日志步调是否一致。如果 rank 2 的日志走到 step 100 之后不再更新，而其他进程还在往前走，那就去 rank 2 对应的日志里找异常。常见的坑包括：某个进程的数据集加载失败，某个进程的显存不足被系统杀掉，或者网络通信有断连。定位到了差异进程后，再针对性看它那一侧的日志，而不是在主节点上反复重启。
5.2 日志乱序与重复输出
分布式训练时，多个进程同时往终端打印日志，顺序会非常混乱，甚至同一个 loss 被打印了多遍。这不是功能错误，但会严重影响你的排查效率。EchoFree 里做得比较好的做法，是每个进程在日志前缀加上 rank 信息，比如 [EchoFree: rank=2, epoch=1, step=12]。如果你启动后没有这类前缀，说明可能没有按进程区分日志文件。
更实用的方案是把每个进程的日志重定向到独立文件：
bash复制torchrun --nproc_per_node=4 --redirects=3 --tee=3 train.py --config configs/echo_free_base.yaml
这样 stdout 和 stderr 会按进程拆开，rank 0 的日志仍然在终端显示，其余进程的日志写入单独文件。排查问题时，直接按 rank 查文件效率高得多。
5.3 显存 OOM 的定位方法
分布式训练的 OOM 表现和单卡不同。单卡 OOM 会直接抛异常，多卡时可能只有某个进程 OOM，然后整个集群卡死。定位时，先用 nvidia-smi 看每张卡的显存占用，如果某一张卡的显存超出而其他卡正常，就要检查是不是数据不均或者模型切分不均。
排除显存容量不足后，再看是不是 batch size 太大或序列长度过长。EchoFree 的训练日志里一般会打印峰值显存占用，如果接近上限，优先调小 batch size 或者开启混合精度。如果显存占用特别不均衡，那就去检查优化器状态变量在 DDP 下是否同步，有的模型结构里不同层的中间激活差异过大，也会导致显存分布失衡。
5.4 验证分布式训练结果没跑偏
多卡训练跑通之后，还有一个容易被遗漏的问题：训练结果是否正确。判断方法很简单：单卡用 4 个 epoch 跑出的 loss 曲线，和多卡用同样配置跑出的 loss 曲线，在给定相同随机种子时应基本一致（允许少量数值误差）。如果多卡训练 loss 下降非常陡，或者和单卡明显不同，那就说明并行逻辑引入了一些偏差。
具体检查点包括：BatchNorm 在 DDP 下的统计量同步方式是否正确，EchoFree 里建议把 BatchNorm 换成 SyncBatchNorm，否则各进程的均值方差计算会不一致；学习率调度器的行为在每个进程里是否保持一致；权重初始化的随机种子是否在进程组建立后重新设置。这些问题排查起来比较隐蔽，但对照单卡基准是验证分布式实现的通用办法。
6. 从能跑到跑好：性能调优与后续扩展
6.1 数据加载瓶颈比算力更容易被忽视
多卡训练起来后，很多人第一个想调的是模型结构或者学习率，但实际上最难解决的往往在数据加载这一层。当 GPU 利用率达不到预期，而 CPU 和磁盘 IO 都处于高位时，瓶颈大概率在 DataLoader 上。
EchoFree 的配置里，num_workers 这个参数很关键。多卡环境下，每个进程都拥有自己的 DataLoader，而 DataLoader 里每个 worker 都是一个独立子进程。假如你有 4 个进程、每个进程配置 4 个 worker，总共有 16 个数据加载子进程，如果主机内存不够，swap 就会被频繁触发，性能反而下降。
调试数据加载瓶颈时，可以在命令行里临时把模型的训练循环简化成只做前向不做反向，观察每秒能处理多少 batch。如果这个数字远超正常训练时的吞吐，说明计算和通信没问题，接着查数据增强和预处理逻辑，看看是否有重复解码或者 CPU 上的耗时操作。
6.2 混合精度与梯度累积的平衡
EchoFree 支持自动混合精度训练，原理是让一部分计算使用 FP16、一部分保持 FP32，在不明显损失精度的前提下提高训练吞吐。开启混合精度后，单卡显存占用通常能下降 20% 到 40%，如果你已经因为显存吃紧而把 batch size 调小，这一步能帮你把有效 batch size 拉回来。
梯度累积则是另一个“加大 batch size”的手段。它把多个 mini-batch 的梯度累加起来，再统一做一次参数更新。EchoFree 里一般通过配置 gradient_accumulation_steps 来实现：
bash复制torchrun --nproc_per_node=4 train.py --config configs/echo_free_base.yaml --train.batch_size 4 --train.gradient_accumulation_steps 4
这里的效果等价于用单卡 16 的 batch size 训练（4 × 4），但实际显存占用只有单卡 4 的水平。需要留意的坑是：梯度累积会放大学习率调参的敏感度，修改累积步数后要重新确认收敛效果，同时注意在每个累积周期的末尾正确进行梯度裁剪。
6.3 训练监控、checkpoint 与断点续训策略
训练进入长时间运行后，最需要关注的是监控的维度。除了 loss，我建议至少关注这几类指标：梯度范数、学习率变化、每 step 的耗时、单位时间吞吐量、显存占用峰值。EchoFree 的日志系统往往会定期输出这些指标，但如果没有，你可能需要自己加几行代码，或者把数据导到可视化工具中。
checkpoint 保存时，EchoFree 的滑动窗口默认会保留最近几个模型，但你应该同时设置一个注册保存目录，把 best 模型和 last 模型分开存储。断点续训的关键是不只保存模型权重，还要保存优化器状态、学习率调度器状态、epoch 计数器和随机数生成器状态，否则恢复训练时可能会出现意外的指标跳动。
提示：在大规模多机训练里，不要把所有历史 checkpoint 都留在共享存储上，一定时间后磁盘会积满。我的习惯是只保留最近 2 到 3 个 best 模型和最近 1 个 last 模型，历史模型归档到冷存储的目录，等实验结束再手动清理，避免训练中因为磁盘已满导致异常退出。
说到最后，还是那个观点：EchoFree 这类项目的核心门槛，不在代码本身，而在对整个训练生命周期的理解。命令行只是入口，分布式训练只是手段，真正让你的模型能落地、能在端边云各种环境下衔接上，靠的是前面这些环节里每一个参数的合理取舍。我刚刚接触分布式训练那阵子走了不少弯路，现在回头总结经验，踩坑最快的方式就是先把每个报错背后的机制弄懂，再动手跑下一次实验。你能看到这里，说明已经比大多数人走得稳当。