算力与实验管理

如何在有限 GPU 上安排实验队列、并行多个种子、用实验管理工具（W&B、MLflow）记录指标与产物、以及定期清理与归档。本章还讨论算力不足时的策略：小模型代理、缩短训练、复用公开检查点。

实验队列：无人值守

在有限的 GPU/机器上，实验应当组织成能无人值守运行的队列：

• 队列管理用最简单的形式：一个按序执行的脚本列表，或 Slurm/调度系统的作业数组（集群用法见算力与远程工作）；
• 每个实验在 tmux/screen 会话或独立作业里跑，断连不影响（长任务一定在 tmux 里跑）；
• 失败要能恢复：实验按配置文件定义，失败后重跑同一配置即可；日志里记录失败原因；
• 并行多个种子：同一配置的多种子运行同时排队，一次性完成（见统计显著性与效应量）。

每个实验有唯一 ID 并与论文表格对应：结果目录、配置快照、日志都挂在这个 ID 下；论文的每个表格行都能用 ID 找回原始记录（见可复现性）。

实验追踪工具

W&B、MLflow、TensorBoard 等工具的价值在于把"记录"从自觉变成自动：

• 每次运行自动记录配置、指标曲线、系统指标与产物（检查点、图）；
• 跨实验对比界面：按配置字段分组对比，找规律比翻日志快得多；
• 最低限度：如果没有条件用外部服务，本地日志 + 一个汇总脚本也能达到"可追溯"的下限。

记录什么：配置全量、关键指标、资源占用、git commit、失败信息。不要记录无差别的巨型日志——日志的价值在可检索，不在全。

定期清理与归档

• 检查点与中间产物按"是否还能被某个实验 ID 需要"清理，磁盘满会杀死无人值守的队列；
• 已完成项目的实验记录归档（打包 results/ 与 configs/），释放计算资源；
• 归档时确认：这个项目的任何结论还能追溯吗？——归档是可复现性的最后一道关。

算力不足时的策略

算力受限时先证明趋势再放大：

• 小模型代理：在小模型/子集上验证方法的相对排序，有信号再放大（注意规模陷阱，见实验设计）；
• 缩短训练：用短训练的代理指标（早期 loss 曲线、少量 epoch 的验证分）预判方向；
• 复用公开检查点：能微调的不要从头训练，能冻结的不要全量微调；
• 优先级：把算力留给"最可能改变后续计划"的实验（见实验设计的顺序原则）。

本章要点

• 实验队列应能无人值守运行
• 每个实验有唯一 ID 并与论文表格对应
• 算力受限时先证明趋势再放大