Onboarder les tests GitHub MR à 1 nœud GB200

Créer des variantes 1-nœud (mr-github) des tests fonctionnels GB200 existants 2-nœuds (scopes mr). Chaque nœud GB200 dispose de 4 GPUs. Un test 2-nœuds utilise 8 GPUs au total ; la variante 1-nœud en utilise 4.

Contexte

Les tests fonctionnels GB200 se trouvent dans tests/test_utils/recipes/gb200/ :

Les configurations de modèle se trouvent à : tests/functional_tests/test_cases/{model}/{test_case}/model_config.yaml

Les cas de test 1-nœud utilisent le suffixe _1node : tests/functional_tests/test_cases/{model}/{test_case}_1node/model_config.yaml

Flux de travail

Étape 1 — Trouver les tests candidats

Parcourir le bloc products: dans gpt.yaml et moe.yaml pour les entrées avec scope: [mr, ...] ou scope: [mr-slim, ...]. Ce sont les tests 2-nœuds qui ont besoin de contreparties mr-github 1-nœud.

Ignorer les tests déjà couverts dans les fichiers *-1node.yaml, et ignorer les scopes nightly, weekly, mr-broken.

Étape 2 — Lire chaque configuration de modèle

Pour chaque candidat, lire son model_config.yaml et extraire les arguments de parallélisation clés :

--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

Étape 3 — Classifier : copie triviale vs. adaptation nécessaire

La formule de la taille du monde est : world_size = TP × PP × DP où DP ≥ EP.

Passer de 8 GPUs → 4 GPUs :

Ne pas modifier GBS — laisser l'accumulation de gradient absorber le DP réduit.

Étape 4 — Créer les répertoires de configuration de modèle _1node

# Copie triviale
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

# Puis appliquer les changements de parallélisation (EP ou PP) avec l'outil Edit

Étape 5 — Créer ou mettre à jour les fichiers recette

Pour les tests GPT — créer tests/test_utils/recipes/gb200/gpt-1node.yaml (s'il est absent) en clonant le bloc spec de gpt.yaml avec nodes: 1. Utiliser ce modèle pour la spec :

type: basic
format_version: 1
maintainers: [mcore]
loggers: [stdout]
spec:
  name: "{test_case}_{environment}_{platforms}"
  model: gpt          # ou moe
  build: mcore-pyt-{environment}
  nodes: 1
  gpus: 4
  n_repeat: 5
  platforms: dgx_gb200
  script_setup: |    # copier verbatim depuis gpt.yaml / moe.yaml
    ...
  script: |-         # copier verbatim depuis gpt.yaml / moe.yaml
    ...

Pour les tests MoE — ajouter des entrées au moe-1node.yaml existant.

Étape 6 — Ajouter les entrées de produits

Convention de scope :

• 1–2 tests les plus représentatifs par recette : scope: [mr-github, mr-github-slim]
• Tous les autres tests : scope: [mr-github]

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

Référence rapide de parallélisation

Liste de contrôle

• [ ] Identifiés tous les tests scopes mr dans gpt.yaml et moe.yaml non encore dans *-1node.yaml
• [ ] Lire la configuration de modèle pour chaque candidat
• [ ] Classifiés trivial vs. adaptation nécessaire
• [ ] Créé _1node/model_config.yaml pour chaque test
• [ ] Appliqué les réductions EP ou PP où nécessaire
• [ ] Créé/mis à jour la YAML recette avec nodes: 1, gpus: 4
• [ ] Assigné le scope mr-github (+ mr-github-slim pour 1–2 tests représentatifs par recette)
• [ ] Vérifié pas de surcharge mr-github-slim (la suite slim doit rester petite)