NeMo MBridge 多节点 Slurm 助手
将单节点 MBridge 脚本转换为多节点 Slurm 作业，并诊断启动、NCCL 与 MoE 显存问题。
文档明确要求避免硬编码令牌、使用受限 secrets 文件并共享挂载路径，具备一定数据流透明度；但明确建议训练前执行“rm -rf nemo_experiments”，未要求确认、备份或回滚，且作业提交、远程模型/日志服务和共享存储的外部影响边界不完整，因此大幅扣分并触发阻断风险。
提供了两种启动模式、环境变量映射、常见错误模式和诊断命令，快乐路径较清晰；但模板主体默认仍是 ntasks-per-node=1 的 legacy 方案，与首选 srun-native 路径不完全对齐，部分修复依赖修改外部源码，且没有针对关键路径的提交测试或可复现执行证据，静态评分限制在10分以内。
触发词、目标用户、Slurm/Bridge/MoE/NCCL 场景和 srun 与 torch.distributed 的适用边界较明确；但对非 Slurm 环境、权限差异、集群配置差异和中国大陆网络条件没有充分说明，HF、W&B、GitHub 等外部服务可能影响可用性，故未给满分。
SKILL.md 结构可读，包含引用模板、限制提示、许可证和 skill card；但缺少推荐的 Instructions、Examples、metadata.author 和 metadata.tags，版本与维护信息主要在附属卡片和 benchmark 中，未形成清晰的变更日志及单技能更新责任说明，且 benchmark 结论覆盖仅一个任务。
能直接提供 sbatch 框架、共享缓存要求、并行度提示和 NCCL/OOM 排查步骤，核心任务价值明确；但模板仍需填充账户、路径、容器和训练命令，部分建议需要修改源码，且只有单个正向评测任务，输出仍需人工审核和环境适配，因此静态评分不超过7分。
存在固定 revision、引用模板、评测任务、ground truth 和 benchmark 指标，关键主张具有一定可追溯性；但评测样本仅一个、没有覆盖关键路径的提交测试或第三方执行记录，benchmark 属于仓库内报告，故仅给有限验证分。
- 不要未经用户明确确认、备份或回滚方案直接执行训练前的“rm -rf nemo_experiments”；该命令可能删除检查点或实验状态。
- 模板依赖本地 Slurm、Enroot、共享文件系统、容器内 uv、HF/W&B/GitHub 凭据及网络可达性；执行前需核对集群参数、挂载、权限和服务可用性。
- 首选 srun-native 说明与引用的完整 legacy 模板存在启动配置不一致，必须按实际脚本和 Bridge 调用路径复核 ntasks-per-node。
- OOM 估算、超时修复和源码修改建议未通过本次静态审查中的独立执行验证。
这个 Skill 能做什么，适合哪些场景？
该技能面向使用 NeMo MBridge 在 Slurm 集群上运行多节点任务的开发者。它指导用户将单节点 PyTorch 分布式命令转换为 sbatch 脚本，优先采用 srun-native 启动方式，也涵盖旧式 uv run torch.distributed 方式。内容涉及共享存储、容器挂载、凭据管理、交互式 GPU 分配、NCCL 超时和 MoE 模型 OOM。它适合已有 Slurm、容器和 NVIDIA GPU 环境的团队，不是通用的集群部署教程。
指导编写包含节点数、每节点任务数、GPU、日志和独占资源配置的 sbatch 文件；使用两阶段 srun 预热共享 uv 缓存并启动多节点任务；说明 Bridge 如何从 Slurm 环境变量推导 RANK、WORLD_SIZE、LOCAL_RANK、MASTER_ADDR 和 MASTER_PORT；要求为代码、数据、日志、HF_HOME、UV_CACHE_DIR 与 NEMO_HOME 使用共享路径和匹配容器挂载；提供 salloc 与 srun 交互式调试命令；通过 grep 检查真实错误、首个失败 rank、NCCL 超时和 rank 0 崩溃；帮助分析 MoE 专家并行显存规模、模块冲突、FP8 到 BF16 权重差异及环境变量问题。
- NeMo MBridge 开发者需要把单节点转换或推理脚本改造成多节点 sbatch 作业。
- 集群工程师遇到 NCCL barrier 超时，需要定位首个失败的 rank 和节点。
- 模型工程师运行 MoE 模型时发生加载或推理 OOM，需要依据专家并行度估算显存。
- 开发者需要通过 salloc 和交互式容器快速调试多节点转换任务。
- 维护者调查某次提交是否导致多节点训练启动或导出失败。
这个 Skill 有哪些优点和局限？
- 提供可直接改写的 sbatch、srun、salloc 命令形状。
- 明确区分 srun-native 与 torch.distributed 两种进程启动模型，降低任务数配置错误风险。
- 覆盖共享缓存、NEMO_HOME、容器挂载、凭据和日志等多节点实际问题。
- 给出按顺序执行的 NCCL 和 rank 失败日志检查方法。
- 对 MoE 的 TP、EP、节点数和显存余量提供具体 sizing 公式与示例。
- 内容专注于 NeMo MBridge、Slurm 和 NVIDIA GPU 环境，不能替代其他调度器或硬件平台的指南。
- 完整的可复制模板位于 references/templates.md，但该文件内容未随本资料提供。
- 未提供测试套件、平台兼容性矩阵或实际集群验证结果。
- 部分修复建议需要修改 Bridge 或 Megatron 代码，仍需用户结合具体日志确认。
如何安装这个 Skill？
按仓库 README 使用 skills CLI 安装指定技能：npx skills add nvidia/skills --skill nemo-mbridge-multi-node-slurm --yes。README 未说明该单项安装的具体目标目录；CLI 会提示选择安装位置。无需克隆仓库或手动复制技能目录。
如何使用这个 Skill？
安装后，在相关任务中向代理提出明确请求，例如："把这个 NeMo MBridge 单节点命令转换成多节点 Slurm sbatch 脚本"、"诊断这个作业的 NCCL timeout" 或 "为这个 MoE 模型检查多节点 OOM 的 EP 配置"。代理应先判断使用 srun-native 还是 uv run torch.distributed，并依据日志中的实际错误继续排查。
这个 Skill 与同类方案有什么区别？
技能明确比较两种启动方式：推荐 srun-native，由 Slurm 每节点启动 8 个任务；legacy 的 uv run torch.distributed 方式则每节点只配置 1 个 Slurm 任务，再由 torch.distributed.run 启动 8 个进程。前者适合 Bridge 脚本、转换和推理，后者用于必须调用 torch.distributed.run 的脚本，例如 MLM pretrain_gpt.py。