NeMo MBridge GPU 内存调优
诊断 Megatron Bridge 训练中的 GPU OOM，并降低碎片、激活和 PEFT 内存占用。
技能仅建议环境变量和训练配置，未见恶意行为、凭据收集、隐蔽外传或破坏性默认操作；说明了NCCL、CUDA Graph、PP和LoRA适用约束，也提供了禁用配置等回退方向。因缺少明确的用户确认、变更前备份/回滚流程、依赖版本与数据流边界，扣6分。NVIDIA官方组织来源可支持归属与治理，但不额外证明安全性。
正文包含决策顺序、兼容性约束、失败症状、确认方法和诊断修复表，关键路径在静态阅读下较连贯。因依赖Megatron Bridge、PyTorch、MCore、CUDA、NCCL和特定配置，且本次未执行命令或测试，异常输入覆盖和可复现性有限；按静态上限取9分，扣11分。
触发词、目标用户和OOM/LoRA+SP场景较明确，并清楚列出TP、PP、VPP、CPU offloading及适用模块边界。技能不依赖海外在线服务，具备一般中文用户环境可达性；但没有中文说明，且对硬件、软件版本、模型配置和集群环境的适配范围仍不充分，扣4分。
文档结构清晰，包含快速决策、配置示例、约束、测量结果、故障诊断、已知限制、验证命令和Apache-2.0许可证；skill card补充了所有者、版本和维护/评估信息。因缺少明确Instructions和Examples章节、作者元数据、完整依赖安装说明、变更日志与具体维护责任，扣5分。
对已知Megatron Bridge训练OOM可直接给出首选配置、替代方案、性能代价和兼容性警告；正文及基准文件提供了Llama3、LoRA和CPU offloading案例。因静态审查未验证输出或实际修复，覆盖面依赖外部文档，且没有自动 profiling 或针对环境的策略选择，按静态上限取7分，扣8分。
包含代码锚点、测试命令、失败信息、测量表、PR编号和梯度/输出一致性声明，达到可审计的一手材料水平。因未执行测试，PR和测量结果无法在给定材料内独立复核，也缺少多来源交叉证据；按静态上限取5分，扣5分。
- 不要将expandable_segments视为所有OOM的通用容量解决方案；先确认是否为碎片化，并注意其与--use-nccl-ub及部分CUDA Graph配置冲突。
- 在生产训练前应由用户确认配置变更，并以实际GPU、CUDA、NCCL、Megatron Bridge版本和运行时指标验证；CPU offloading在PP>1时不可用，LoRA输入重聚集会增加通信和吞吐代价。
- 基准仅包含1个正向任务且本次未执行测试，不能据此推断对其他模型、硬件或集群的普遍效果。
这个 Skill 能做什么，适合哪些场景？
该技能面向 NeMo MBridge 与 Megatron Bridge 训练任务中的 GPU 内存不足问题。它优先处理 CUDA 分配器碎片，并覆盖 LoRA 配合序列并行、激活重计算、并行度调整、分布式优化器和 CPU offloading 等方案。技能还提供理论内存估算、兼容性约束、故障诊断表和验证测试。实测结果主要来自 32 张 H100 80GB 上的 Llama3 70B 训练，以及多个 LoRA 序列并行配置。
指导用户设置 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True，使用 Megatron Bridge 的 estimate_training_memory 估算训练内存，并根据参数、优化器、激活和临时工作区分析内存来源。它给出 TP、PP、DP、分布式优化器、FSDP 和激活重计算的调整建议，配置 LoRA(sequence_parallel_input_regather=True) 以减少符合条件的序列并行 LoRA-A 输入保留，并检查 CPU offloading、CUDA graphs、NCCL UB 和适配器类型等约束。它还提供环境变量检查、pytest 单元测试和双进程分布式回归测试命令。
- Megatron Bridge 训练在单个 GPU 上 OOM，但其他 GPU 仍有显存余量时，用于排查内存碎片。
- 使用 LoRA 或 PEFT 与 sequence parallelism 训练时，用于降低 gathered LoRA-A 输入带来的激活显存。
- 模型确实超出 GPU 容量时，用于比较 PP、TP、分布式优化器、FSDP 和激活重计算方案。
- 需要确认某次配置或提交导致 OOM 回归时，用于对照内存估算、运行时指标和配置测试。
- 计划启用 CPU offloading 或 CUDA graphs 时，用于检查 pipeline parallelism 与 CUDA/NCCL 兼容性。
这个 Skill 有哪些优点和局限？
- 优先推荐 expandable_segments，实测可在不改变模型或并行度的情况下解决碎片导致的 OOM。
- 覆盖 LoRA 序列并行 input re-gather，并提供多种模型配置的显存节省和吞吐变化数据。
- 明确说明 TP、PP、VPP、CPU offloading、CUDA graphs 和 NCCL UB 的限制与代价。
- 包含理论估算、故障诊断、代码锚点和可复制的验证命令。
- 实测数据集中于 H100 80GB 和特定 Llama3、Qwen3、GPT-OSS 配置，不能保证其他硬件或工作负载有相同收益。
- 理论估算不包含分配器碎片、CUDA/NCCL 工作区、CUDA graph 缓冲区、token 不均衡和 dispatcher 工作区。
- 激活重计算和并行度调整可能带来明显吞吐损失；TP=8 的示例吞吐下降 28.4%。
- CPU offloading 在 pipeline parallelism 大于 1 时不可用，input re-gather 也不适用于所有 LoRA 适配器。
如何安装这个 Skill？
使用仓库 README 支持的 Skills CLI 命令安装指定技能：npx skills add nvidia/skills --skill nemo-mbridge-perf-memory-tuning --yes。README 未说明其他专属安装步骤；安装后，技能会在智能体下次加载技能并遇到相关任务时可用。
如何使用这个 Skill？
向智能体描述具体训练问题，例如：“Megatron Bridge 训练出现 GPU OOM，请先检查内存碎片，再评估 LoRA + sequence parallelism 的 input re-gather 和激活重计算方案。”对于实际验证，可按技能提供的命令导出 expandable_segments 环境变量、运行 estimate_training_memory，以及执行相关 pytest 和双进程 torch.distributed 测试。
这个 Skill 与同类方案有什么区别？
与直接增加 TP 或 PP 相比，该技能优先建议处理内存碎片；实测 expandable_segments 几乎无吞吐成本，而 TP=8 吞吐下降 28.4%，PP=8 在牺牲 DP 后下降约 5.9%。与激活重计算相比，LoRA input re-gather 是显存换通信，不会重算 LayerNorm、attention、MLP 或 LoRA GEMM。VPP 主要用于减少 pipeline bubble，不应作为主要内存修复手段。