在 NVIDIA DGX Spark 上跑长时间 ML…

适用于在 GB10 统一内存（UMA）平台上规划训练内存、处理 OOM、以及监控多小时训练中的温度与功耗。

适用场景

解决思路

1. 用 `free -g` 而不是 `nvidia-smi` 来规划和诊断内存：`free -g | awk 'NR==2 {print "free:", $4, "GB"}'`，因为 `nvidia-smi` 和 `cudaMemGetInfo` 只反映 CUDA 分配器可见内存，看不到 page-cache 和 mmap 页，可能显示有余量却仍 OOM，某些驱动下甚至直接返回 `[N/A], [N/A]`。
2. 把 `free -g` 得到的空闲值减去几 GB 作为 OS/驱动开销，再以此为预算，而不是按 128GB 规格数字来算。
3. 启动前按顺序做规划：先读 `free -g` 并扣除开销得到预算；再用 `references/uma-accounting.md` 估算权重+优化器+梯度+激活；再与最接近的锚点（70B QLoRA、27B LoRA、9B full FT）对比，而不是只看估算值；若估算接近预算，先用更短 packing 或更小 batch 启动。
4. 注意模型加载是瞬时峰值而非稳态：safetensors 权重先被 mmap 再拷贝进 CUDA tensor，加载窗口内 mmap 页和 CUDA 副本会同时占用同一内存池，按加载后占用规划余量仍可能在加载时 OOM。
5. OOM 时按 OOM Ladder 顺序处理，不要跳步，尤其不要把减小 batch size 当作第一步。
6. 第 1 步：刷新 buffer cache，`sync; echo 3 > /proc/sys/vm/drop_caches`（需要 root，是两次运行之间的重置操作，不是训练中途步骤），这通常能释放上轮运行或大数据集读取留下的数 GB page cache。
7. 第 2 步：仅在刷新未能释放足够余量后，才减小 batch size 或 packing length；优先减小 packing length，因为长上下文下它更直接决定激活占用。
8. 第 3 步：降级方法，先降到 bf16 LoRA 再考虑 QLoRA；QLoRA 的 bitsandbytes 反量化缓冲是瞬时 CUDA 分配，可能比等效 bf16 LoRA 更早 OOM，所以 QLoRA OOM 不代表模型放不下。
9. 只有在以上三步都失败后才考虑更小模型或多台 Spark。
10. 用 `bash assets/thermal-sample.sh 30 thermal.log` 每 30-60 秒采样温度和功耗并与训练日志对齐，保留该脚本写出的 CSV 格式以便时间戳对应。
11. 把持续约 100W 的功耗视为平台上限而非配置错误，不要为此重调 batch size 或精度；若温度上升而功耗在额定 240W 以下保持平稳，就是该识别的特征。
12. 显式记录 throttle 事件，不要让运行悄悄变慢；若某次运行两小时后每步耗时翻倍，日志中应能对照该时间戳的热采样看到原因。
13. 并发负载方面：对未设上限或接近满容量的负载适用“一次只跑一个重任务”规则，未设上限的 trainer 与推理服务器（vLLM、Ollama）会争抢同一内存池。
14. 小而有上限的负载可以共存：例如 <4GB 的 LoRA 微调可与 `gpu-memory-utilization<=0.5` 的 vLLM 同时运行；停止其他进程前先检查其上限，而不只是看它是否存在。
15. 未设上限/接近满容量争抢时，推理服务器会静默驱逐 trainer 页，反之亦然，双方都不报错；运行变慢或 KV cache 丢失就是争抢症状，长时间或满池运行前应停掉无关的未设上限服务器。
16. 先用 `ps aux | grep -E 'vllm|ollama|trl|axolotl' | grep -v grep` 检查 GPU 常驻进程。

适用边界 · 注意事项

• 不适用于启动阶段的失败模式（ABI 不匹配、flash-attn、playbook 损坏），那些应参考 `spark-training-gotchas`；本技能假设任务能启动。
• 不要在未确认其他进程内存上限的情况下就贸然停止它——小而有上限的负载可以安全共存。
• 不要把持续约 100W 的功耗平台上限误判为配置 bug 而去重调 batch size 或精度。