企业官网建设流程全解析

Megatron-LM 单节点 GB200 测试移植指南：从 2 节点 MR 功能测试创建 1 节点 mr-github 变体

【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM

本篇指南讲解 Megatron-LM 中一项具体的 CI 工程实践：如何将现有2 节点（8 GPU）的 GB200 合并请求（MR）作用域功能测试，系统性地移植为1 节点（4 GPU）的mr-github作用域测试。读者将掌握 GB200 测试配方的组织方式、基于 TP/PP/EP 的并行度裁剪分类规则、_1node模型配置目录的创建方法，以及如何为gpt-1node.yaml/moe-1node.yaml配方文件追加products条目并分配mr-github作用域，从而在资源占用更小的前提下扩大 GB200 的 CI 覆盖。

GB200 单节点测试的背景与动机

在 NVIDIA GB200 硬件平台上，每个节点包含4 张 GPU。因此：

• 一个 2 节点测试合计使用8 张 GPU；
• 其 1 节点变体只使用4 张 GPU。

Megatron-LM 的 CI 中，MR 合并前需要跑一批功能测试来快速验证改动是否破坏核心训练路径。将这些测试中占用 2 个节点的用例裁剪为单节点用例，可以在不牺牲覆盖面的前提下显著降低 CI 的资源需求与排队时间——这就是“onboard GB200 1-node GitHub MR tests”这一工程任务的出发点。该技能由 NVIDIA 维护（作者 Oliver Koenig），以 Apache-2.0 协议开源，技能元数据与评估基准分别记录在 skills/mcore-onboard-gb200-1node-tests/skill-card.md 和 skills/mcore-onboard-gb200-1node-tests/SKILL.md。

GB200 测试配方与模型配置的组织结构

GB200 功能测试由两类文件共同定义，这也是本次移植工作中需要操作的两类对象。

测试配方文件（Recipe）

GB200 相关的配方文件集中在tests/test_utils/recipes/gb200/目录下：

此外该目录还包含gpt-dynamic-inference.yaml、moe-dynamic-inference.yaml、nemotron.yaml、hybrid-perf.yaml、unit-tests.yaml等面向推理、Nemotron、混合模型与单元测试的 GB200 配方（参见 tests/test_utils/recipes/gb200/），本任务聚焦于gpt与moe两类训练功能测试。

模型配置目录（Model Config）

每个测试用例的模型参数存放在功能测试用例目录下：

tests/functional_tests/test_cases/{model}/{test_case}/model_config.yaml

1 节点变体使用_1node后缀的目录：

tests/functional_tests/test_cases/{model}/{test_case}_1node/model_config.yaml

其中{model}取gpt、moe等。例如 MoE 侧已落地的用例gpt3_moe_mcore_te_ep8_resume_torch_dist_muon_1node对应目录 tests/functional_tests/test_cases/moe/gpt3_moe_mcore_te_ep8_resume_torch_dist_muon_1node/。

model_config.yaml采用三段式结构：ENV_VARS（环境变量，如CUDA_DEVICE_MAX_CONNECTIONS、NCCL_ALGO）、MODEL_ARGS（训练超参与并行度参数）、TEST_TYPE（测试类型，如ckpt-resume）以及LAUNCHER（如ft_launcher）。

测试作用域（Scope）约定

配方文件products:块中的每条记录通过scope字段决定测试在哪些 CI 阶段运行。本任务涉及的作用域有：

• mr：2 节点 MR 测试（合并请求触发，通常运行在专门的多节点机器上）；
• mr-slim：2 节点 MR 精简子集；
• mr-github：1 节点 GitHub MR 测试（本任务的落点）；
• mr-github-slim：1 节点 GitHub MR 精简子集（仅给每份配方中 1～2 个最具代表性的测试）；
• nightly/weekly：夜间 / 周度测试；
• mr-broken/nightly-broken：已知挂起或有问题的用例，会被暂时标记为禁用（例如gpt3_mcore_te_tp2_pp2_ep4_etp1_resume_torch_dist_attn_cudagraph因 hang 被标记为mr-broken，见 tests/test_utils/recipes/gb200/moe.yaml）。

关键原则：只挑选scope: [mr, ...]或scope: [mr-slim, ...]的 2 节点测试作为候选，跳过nightly、weekly、mr-broken作用域，以及那些已经存在于*-1node.yaml文件中的用例，避免重复覆盖。

六步移植工作流

第 1 步：筛选候选测试

扫描 tests/test_utils/recipes/gb200/gpt.yaml 与 tests/test_utils/recipes/gb200/moe.yaml 的products:块，找出所有scope含mr或mr-slim的条目。

以当前仓库为例，gpt.yaml中符合mr条件的用例包括：

• gpt3_mcore_te_tp1_pp1_resume_torch_dist_dist_optimizer
• gpt3_mcore_te_tp2_pp1_gdn
• gpt3_mcore_reruns_persistent_1
• gpt3_mcore_te_tp1_pp4_vp1_dist_optimizer_overlap_grad_reduce_param_gather_overlap_optimizer
• gpt3_mcore_te_tp4_pp1_resume_torch_dist_dist_optimizer_overlap_grad_reduce_param_gather

moe.yaml中符合mr条件的用例包括：

• gpt3_moe_mcore_te_ep8_resume_torch_dist_dist_muon
• gpt3_moe_mcore_te_ep8_resume_torch_dist_muon
• gpt3_moe_mcore_te_tp4_ep2_etp2_pp2_resume_torch_dist_dist_optimizer

这些正是需要生成_1node变体的目标。

第 2 步：读取并提取模型配置的并行度参数

对每个候选用例，读取其model_config.yaml，提取以下关键并行度参数：

--tensor-model-parallel-size (TP) --pipeline-model-parallel-size (PP) --expert-model-parallel-size (EP) --expert-tensor-parallel-size (ETP) --context-parallel-size (CP) --global-batch-size --micro-batch-size

这些参数在 megatron/core/parallel_state.py 与 megatron/training/arguments.py 中定义并初始化对应的进程组，是判断世界规模（world size）与进程组能否成立的基础。

第 3 步：分类——直接拷贝还是需要适配

世界规模的通用公式为：

world_size = TP × PP × DP，其中 DP ≥ EP

从 8 GPU 收缩到 4 GPU 时，按以下条件分类处理：

不要修改 GBS（全局批大小）——减少的 DP 由梯度累积（gradient accumulation）自动吸收，从而保持全局训练语义与 golden values 的一致性。

第 4 步：创建_1node模型配置目录

对于“直接拷贝”类用例，可以简单地复制配置目录：

# Trivial copy mkdir -p tests/functional_tests/test_cases/{model}/{test_case}_1node cp tests/functional_tests/test_cases/{model}/{test_case}/model_config.yaml \ tests/functional_tests/test_cases/{model}/{test_case}_1node/model_config.yaml # 然后使用编辑工具应用并行度修改（EP 或 PP）

对于需要适配的用例，复制后再修改MODEL_ARGS中的并行度参数。仓库中的真实差异印证了这一模式——对比gpt3_moe_mcore_te_ep8_resume_torch_dist_muon与其_1node变体，唯一的差异正是：

- --expert-model-parallel-size: 8 + --expert-model-parallel-size: 4

其余参数（--num-experts: 8、--global-batch-size: 32、--micro-batch-size: 4等）原样保留，与“EP 8→4、专家数不变、GBS 不变”的规则完全一致。

第 5 步：创建或更新配方文件

GPT 测试——若tests/test_utils/recipes/gb200/gpt-1node.yaml不存在，则克隆gpt.yaml的spec块并将nodes改为 1，按此模板编写：

type: basic format_version: 1 maintainers: [mcore] loggers: [stdout] spec: name: "{test_case}_{environment}_{platforms}" model: gpt # 或 moe build: mcore-pyt-{environment} nodes: 1 gpus: 4 n_repeat: 5 platforms: dgx_gb200 script_setup: | # 从 gpt.yaml / moe.yaml 原样复制 ... script: |- # 从 gpt.yaml / moe.yaml 原样复制 ...

其中script_setup完成环境准备（设置umask 077、写.netrc、clone 仓库、checkout MR commit 与 backwards-ref 等），script则组装环境变量并调用测试执行脚本：

bash ./tests/functional_tests/shell_test_utils/run_ci_test.sh "${ARGUMENTS[@]}"

MoE 测试——向已存在的 tests/test_utils/recipes/gb200/moe-1node.yaml 追加条目。

第 6 步：添加 products 条目

作用域分配约定：

• 每份配方中1～2 个最具代表性的测试：scope: [mr-github, mr-github-slim]
• 其余所有测试：scope: [mr-github]

products: - test_case: [<test_case>_1node] products: - environment: [dev] scope: [mr-github, mr-github-slim] # 或 [mr-github] platforms: [dgx_gb200]

仓库中gpt-1node.yaml的落地示例（tests/test_utils/recipes/gb200/gpt-1node.yaml）：

- test_case: [gpt3_mcore_te_tp1_pp1_resume_torch_dist_dist_optimizer_1node] products: - environment: [dev] scope: [mr-github, mr-github-slim] platforms: [dgx_gb200] - test_case: [gpt3_mcore_te_tp4_pp1_resume_torch_dist_dist_optimizer_overlap_grad_reduce_param_gather_1node] products: - environment: [dev] scope: [mr-github, mr-github-slim] platforms: [dgx_gb200]

而大部分用例（如gpt3_mcore_te_tp1_pp4_vp1_uneven_pipeline_1node）只挂mr-github。另有少量用例以mr-github-temp-disabled临时禁用，待问题修复后再启用。

并行度裁剪速查表

这个速查表覆盖了本次移植中绝大多数的并行度组合：前五行是TP × PP ≤ 4的直接拷贝场景（DP 减半）；第六行对应ep8的 EP 缩减场景（仓库中gpt3_moe_mcore_te_ep8_resume_torch_dist_muon_1node即此模式）；最后一行对应tp4 pp2的 PP 缩减场景（仓库中gpt3_mcore_te_tp4_pp2_resume_torch_dist_reshard_8x1xNone_1node即此模式）。

落地验证：仓库中的真实实现

本次移植工作流已在当前仓库中大规模落地，可以直接对照验证：

• GPT 侧：gpt-1node.yaml已包含 30+ 个_1node用例，按tp1_pp1、tp1_pp2、tp1_pp4、tp2_pp1、tp2_pp2、tp2_pp2_cp2（PP 2→1）、tp4_pp1、tp4_pp2（PP 2→1）分块组织，见 tests/test_utils/recipes/gb200/gpt-1node.yaml。其中gpt3_mcore_te_tp2_pp2_cp2_*_1node与gpt3_mcore_te_tp4_pp2_resume_torch_dist_reshard_8x1xNone_1node正是“PP 2→1”适配的实例。
• MoE 侧：moe-1node.yaml已包含ep8变体（EP 8→4）与tp4_ep2_etp2_pp2变体（PP 2→1），见 tests/test_utils/recipes/gb200/moe-1node.yaml。
• 模型配置侧：tests/functional_tests/test_cases/gpt/与tests/functional_tests/test_cases/moe/下均已存在对应的_1node/model_config.yaml目录。

测试执行机制：配方script中组装的环境变量（TRAINING_SCRIPT_PATH、TRAINING_PARAMS_PATH、GOLDEN_VALUES_PATH、DATA_PATH等）由 tests/functional_tests/shell_test_utils/run_ci_test.sh 消费。该脚本会校验全部必填变量、提升文件描述符与进程数的软限制、按N_REPEAT重复执行训练脚本，并将结果与golden_values_{environment}_{platforms}.json中的基准值比对，这正是 1 节点变体必须保持 GBS 等全局语义不变的原因——只有保证训练语义一致，golden values 才能继续复用。

移植完成检查清单

完成一个用例的移植后，逐项核对：

• 已识别gpt.yaml和moe.yaml中所有mr作用域测试，且未被*-1node.yaml覆盖
• 已逐个读取候选用例的模型配置
• 已分类为“直接拷贝”或“需要适配”
• 已为每个测试创建_1node/model_config.yaml
• 已在需要处应用 EP 或 PP 缩减
• 已创建/更新配方 YAML，nodes: 1, gpus: 4
• 已分配mr-github作用域（每份配方 1～2 个代表性测试另加mr-github-slim）
• 已验证mr-github-slim不会过载（精简套件应保持小规模）

总结

将 2 节点 GB200 MR 功能测试移植为 1 节点mr-github测试，本质上是围绕world_size = TP × PP × DP（DP ≥ EP）这条主线做并行度降维：TP × PP ≤ 4时直接拷贝、DP 自动减半；TP × PP = 8时 PP 减半；EP > 4时 EP 降至 4 而专家总数不变；全程保持 GBS 不变以复用 golden values。本文给出的六步工作流、分类规则、速查表与检查清单，配合仓库中已落地的gpt-1node.yaml/moe-1node.yaml及大量_1node模型配置目录，构成了一套可复制、可验证的 GB200 CI 覆盖扩展方法，可帮助 CI 工程师与开发者快速为 Megatron-LM 的 GB200 平台补齐单节点 MR 级别的功能测试矩阵。

【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM