Tests d'intégration verl

Valider l'ajout d'un modèle Megatron-Bridge via le backend Megatron de verl. Cela détecte les problèmes d'intégration que les tests de conversion Bridge seul manquent : configuration du provider, import HF via Bridge, wrapping PEFT, wrapping DDP, setup de l'optimizer, câblage rollout/ref, et propriété des checkpoints par une boucle RL externe.

Utilisez ceci comme test de compatibilité externe après que les tests unitaires et fonctionnels du Bridge pour un nouveau provider soient passants.

Ce n'est pas un remplacement pour les tests de parité des modèles Bridge. La run PPO verl par défaut prouve que le provider peut survivre à une boucle d'entraînement RL externe ; la correction spécifique à l'architecture provient toujours des tests d'import/export Bridge, de logits/roundtrip, et d'inférence spécifique au modèle.

Portée

Pensez en niveaux de couverture. Commencez par le Niveau 0 et n'ajoutez que les niveaux justifiés par la modification.

Niveau	Requis quand	Ce qu'il prouve
0 : LoRA + DDP smoke	Tout nouveau provider ou changement de config du provider qui prétend à la compatibilité verl	verl peut importer le provider Bridge local, appliquer PEFT, wrapper avec Megatron DDP, construire l'état de l'optimizer, exécuter le câblage rollout/ref/critic, et terminer une étape PPO
1 : Save/resume	PEFT, checkpointing, export HF, export d'adaptateur, état de l'optimizer, ou comportement de resume changé	la planification de checkpoint possédée par verl peut sauvegarder et recharger l'état du modèle construit par Bridge
2 : Stress du parallélisme	Finalisation du provider, paramètres dérivés de mpu, TP/PP/CP/EP, parallélisme de séquence, ou comportement du dispatcher changé	les paramètres du provider restent corrects sous un état Megatron parallèle non-trivial
3 : Megatron-FSDP optionnel	Uniquement quand l'aval demande explicitement la couverture Megatron-FSDP de verl ou la modification touche directement ce chemin d'intégration	le même provider fonctionne quand verl sélectionne Megatron-FSDP au lieu de DDP
4 : E2E spécifique à l'architecture	VLM, MoE, MTP, QAT/ModelOpt, poids quantifiés, ou comportement de couche personnalisée impliqué	la partie de l'architecture non exercée par text-only GSM8K a aussi une vérification runtime ciblée
5 : Signal de convergence / apprentissage	Optimizer, scheduler, loss, reward, trainabilité PEFT, flux de gradients, ou stabilité d'entraînement spécifique au modèle changée	les métriques bougent dans la direction attendue sur une courte run et ne produisent pas silencieusement zero/NaN/mises à jour instables

La cible de Niveau 0 par défaut est une courte run Bridge non-vanilla dans verl avec LoRA activé et Megatron DDP sélectionné :

USE_MBRIDGE=True
VANILLA_MBRIDGE=False
VALUE_VANILLA_MBRIDGE=False
LORA_RANK=4
USE_MEGATRON_FSDP=False
TOTAL_TRAIN_STEPS=1

C'est intentionnellement petit. Cela exerce le chemin orienté vers Bridge dans verl sans faire que Megatron-Bridge possède la planification rollout, la gestion des rewards, la planification de l'optimizer, ou l'orchestration des checkpoints.

Le Niveau 0 n'est pas un test de convergence. Il prouve seulement que la boucle d'entraînement peut accomplir une mise à jour. Utilisez le Niveau 5 quand la question est de savoir si le modèle apprend réellement sous verl.

Megatron-FSDP ne fait pas partie de la validation par défaut attendue pour le travail de compatibilité du provider actuel. Exécutez-le uniquement pour la couverture Niveau 3 quand FSDP est explicitement en portée :

USE_MEGATRON_FSDP=True
ALL_OFFLOAD=False
COMMON_PP=1
COMMON_VPP=null
COMMON_CP=1
COMMON_TP=1
INFER_TP=1

Repos

Utilisez des variables de repo explicites. Ne comptez pas sur une wheel megatron-bridge installée ; le but est de tester le checkout Bridge actuel.

Utilisez le repo verl amont comme source par défaut :

https://github.com/verl-project/verl

Si un checkout n'est pas déjà disponible, clonez-le à côté du checkout Bridge ou dans l'espace de travail standard du site :

git clone https://github.com/verl-project/verl.git /path/to/verl

export BRIDGE_REPO=${BRIDGE_REPO:-/path/to/Megatron-Bridge}
export VERL_REPO=${VERL_REPO:-/path/to/verl}
export PYTHONPATH="${BRIDGE_REPO}/src:${BRIDGE_REPO}/3rdparty/Megatron-LM:${VERL_REPO}:${PYTHONPATH:-}"

Avant d'exécuter, enregistrez les deux états :

git -C "$BRIDGE_REPO" status --short
git -C "$VERL_REPO" status --short
git -C "$BRIDGE_REPO" rev-parse --short HEAD
git -C "$VERL_REPO" rev-parse --short HEAD

Si vous testez sur une machine GPU distante, synchronisez d'abord les modifications locales exactes. Ne réinitialisez ou n'écrasez pas les modifications non liées dans l'un ou l'autre arbre.

Vérifiez que Python importe le checkout en test :

python - <<'PY'
import megatron.bridge
print(megatron.bridge.__file__)
PY

Le chemin affiché doit vivre sous $BRIDGE_REPO/src. S'il pointe vers site-packages, corrigez PYTHONPATH avant de faire confiance à tout résultat.

Lors de l'exécution contre un cluster Ray existant, l'import du driver ne suffit pas. Les workers Ray peuvent ne pas hériter de PYTHONPATH shell, et la run peut échouer plus tard avec ModuleNotFoundError: No module named 'megatron.bridge' même si l'import du driver a réussi. Vérifiez un import de worker :

python - <<'PY'
import os
import ray

ray.init(address="auto", runtime_env={"env_vars": {"PYTHONPATH": os.environ["PYTHONPATH"]}})

@ray.remote
def bridge_path():
    import megatron.bridge
    return megatron.bridge.__file__

print(ray.get(bridge_path.remote()))
PY

Si l'import du worker échoue, passez le chemin du checkout via l'environnement runtime de Ray lors du lancement du wrapper :

bash tests/special_e2e/run_ppo_trainer_megatron.sh \
  "++ray_kwargs.ray_init.runtime_env.env_vars.PYTHONPATH=${PYTHONPATH}"

Si cet import échoue avant la construction du modèle, corrigez d'abord l'environnement runtime. L'image verl officielle peut ne pas contenir toutes les dépendances de Bridge ; par exemple, Bridge importe modelopt via AutoBridge, donc un nvidia-modelopt manquant peut faire échouer le smoke avant que verl exerce le provider :

python -m pip show nvidia-modelopt || \
  python -m pip install --extra-index-url https://pypi.nvidia.com nvidia-modelopt

Traitez les installations ad hoc comme une preuve de configuration de conteneur, pas comme des modifications de repo. Si l'image manque uv, exécutez les tests unitaires Bridge ciblés dans un environnement de développement Bridge au lieu de les forcer via le conteneur verl.

Choix du modèle

Préférez le plus petit checkpoint HF public qui utilise la famille de provider changée. Par exemple, utilisez un checkpoint dense 0.5B ou 0.6B pour les changements de provider dense avant de tester des variantes plus grandes.

S'il n'y a pas de petit checkpoint public pour la nouvelle architecture, utilisez le chemin dummy-model de verl avec une config HF minimale de cette architecture :

USE_DUMMY_MODEL=True
DUMMY_MODEL_CONFIG_PATH=/path/to/minimal_config.json
MODEL_ID=<org>/<representative-model-name>

Rapportez soigneusement les résultats dummy-model : ils valident la construction du modèle et la mécanique d'entraînement, pas la compatibilité des poids préentraînés.

Pour les VLMs, la run PPO GSM8K générique est text-only. Elle peut valider le provider Bridge du côté langage et le wrapping de boucle externe, mais elle ne prouve pas le prétraitement d'image/vidéo ou l'exécution du vision encoder. Associez-la aux tests de conversion/inférence VLM de @skills/adding-model-support/tests-and-examples.md, ou utilisez une commande d'entraînement multimodal verl si elle existe pour la famille de modèles.

Pour les modèles MoE, le Niveau 0 avec COMMON_EP=1 détecte toujours de nombreux problèmes de provider et PEFT, mais il ne stresse pas le routage parallèle des experts. Ajoutez une run Niveau 2 avec parallélisme expert quand la modification touche la disposition des experts, la config du dispatcher, la relecture du routeur, ou le parallélisme tensoriel des experts.

Pour MTP, QAT/ModelOpt, ou le support de checkpoint quantifié, le wrapper générique peut ne pas activer la fonctionnalité. Utilisez l'exemple verl le plus proche ou le script de famille de modèles qui active la fonctionnalité, et enregistrez les overrides Hydra supplémentaires dans le rapport.

Vérifications Bridge d'abord

Exécutez les tests Bridge ciblés avant l'e2e verl externe. Incluez tous les tests spécifiques au modèle ajoutés par la modification.

cd "$BRIDGE_REPO"
uv run python -m pytest -q \
  tests/unit_tests/models/test_model_provider_mixin.py \
  tests/unit_tests/models/test_param_mapping.py \
  tests/unit_tests/training/test_integration.py \
  <model-specific-test-paths>

Pour une nouvelle famille de modèles, exécutez aussi le test de conversion ou roundtrip pertinent depuis la PR du modèle. Voir @skills/adding-model-support/tests-and-examples.md pour les motifs de test de modèle.

Preuve minimale du côté Bridge pour un nouveau modèle/provider :

tests unitaires de provider/config
tests de mapping de paramètres
import HF vers Megatron ou roundtrip sur un petit modèle
comparaison de génération ou logits spécifique au modèle quand disponible
ce smoke de boucle externe verl après que les éléments ci-dessus passent

Setup des données verl

Le wrapper smoke PPO Megatron de verl attend des fichiers parquet GSM8K par défaut. Préparez-les une fois depuis le checkout verl s'ils manquent :

cd "$VERL_REPO"
export PYTHONPATH="$VERL_REPO:${PYTHONPATH:-}"
python3 examples/data_preprocess/gsm8k.py \
  --local_save_dir "${GSM8K_DIR:-$HOME/data/gsm8k}"

Utilisez --local_dataset_path "$GSM8K_SOURCE_DIR" uniquement quand ce chemin de dataset brut local existe réellement. Sinon laissez datasets récupérer openai/gsm8k.

Définissez les chemins explicites lors de l'exécution dans un conteneur ou système de fichiers partagé :

export TRAIN_FILES=/path/to/gsm8k/train.parquet
export VAL_FILES=/path/to/gsm8k/test.parquet

Le wrapper active aussi un modèle de reward par défaut. Assurez-vous que le chemin de modèle de reward par défaut existe, ou définissez :

export RM_MODEL_PATH=/path/to/local/reward/model

Pour un smoke rule-reward Niveau 0, il est acceptable de désactiver le rollout du modèle de reward quand aucun modèle de reward local n'est disponible :

bash tests/special_e2e/run_ppo_trainer_megatron.sh \
  reward.reward_model.enable=False

Rapportez ceci comme une limitation ; cela teste toujours la construction du actor/ref/critic Bridge, LoRA, wrapping DDP, rollout, et une mise à jour PPO, mais pas le serving du modèle de reward.

Run verl minimale

Utilisez le wrapper maintenu par verl au lieu de construire manuellement une longue commande Hydra :

cd "$VERL_REPO"
ray stop --force || true

export MODEL_ID=<small-compatible-hf-model>
export TRAIN_FILES=${TRAIN_FILES:-/path/to/gsm8k/train.parquet}
export VAL_FILES=${VAL_FILES:-/path/to/gsm8k/test.parquet}
export RM_MODEL_PATH=${RM_MODEL_PATH:-/path/to/local/reward/model}
export ENGINE=vllm
export USE_MBRIDGE=True
export VANILLA_MBRIDGE=False
export VALUE_VANILLA_MBRIDGE=False
export LORA_RANK=4
export USE_MEGATRON_FSDP=False
export COMMON_PP=1
export COMMON_VPP=null
export COMMON_CP=1
export COMMON_TP=1
export INFER_TP=1
export ALL_OFFLOAD=False
export TOTAL_TRAIN_STEPS=1
export SAVE_FREQ=-1
export VAL_BEFORE_TRAIN=False
export TEST_FREQ=-1

bash tests/special_e2e/run_ppo_trainer_megatron.sh

Utilisez MODEL_ID quand le checkpoint est disponible via le layout de cache par défaut du wrapper. Ajoutez MODEL_PATH=/path/to/local/hf/model seulement quand vous testez un checkpoint local ou converti.

Quand $HOME est petit ou accédé lentement, mettez les caches HF et les checkpoints téléchargés sur un chemin scratch partagé ou node-local plus grand et passez MODEL_PATH explicitement. Pré-téléchargez les gros modèles une fois dans le même environnement conteneur pour éviter que les workers Ray fassent la course au cache :

export HF_HOME=${HF_HOME:-/scratch/$USER/verl_hf}
export HF_HUB_CACHE=$HF_HOME/hub
MODEL_PATH=${MODEL_PATH:-/scratch/$USER/models/<org>/<model>}
hf download <org>/<model> --local-dir "$MODEL_PATH"

Capturez les logs dans un fichier pour examen :

mkdir -p "${LOG_DIR:-$PWD/verl_e2e_logs}"
LOG_FILE="${LOG_DIR:-$PWD/verl_e2e_logs}/verl_lora_ddp_$(date +%Y%m%d_%H%M%S).log"
bash tests/special_e2e/run_ppo_trainer_megatron.sh \
  "++ray_kwargs.ray_init.runtime_env.env_vars.PYTHONPATH=${PYTHONPATH}" \
  2>&1 | tee "$LOG_FILE"
grep -E "Training Progress|VANILLA_MBRIDGE|Traceback|RuntimeError|KeyError|ValueError" "$LOG_FILE"

Préférez un log sauvegardé à un extrait de terminal collé dans les descriptions de PR.

Pour les runs smoke limitées en temps où la capture de graphe CUDA vLLM domine le setup et le but est la validation du provider Bridge, il est acceptable d'ajouter :

bash tests/special_e2e/run_ppo_trainer_megatron.sh \
  actor_rollout_ref.rollout.enforce_eager=True

Rapportez cet override comme une limitation. Cela valide toujours l'import Bridge, l'import HF, LoRA, Megatron DDP, le câblage rollout, et une mise à jour PPO, mais pas la capture de graphe CUDA vLLM.

Couverture Save/Resume

Après que la run minimale passe, ajoutez la couverture checkpoint si la modification touche PEFT, checkpointing, export, ou état de l'optimizer :

# Save une fois.
SAVE_FREQ=1 TOTAL_TRAIN_STEPS=1 \
bash tests/special_e2e/run_ppo_trainer_megatron.sh

# Resume et entraîne une étape de plus.
RESUME_MODE=auto SAVE_FREQ=1 TOTAL_TRAIN_STEPS=2 \
bash tests/special_e2e/run_ppo_trainer_megatron.sh

Supprimez les répertoires verl checkpoints/ obsolètes entre expériences non liées. Gardez-le pour la validation resume.

Stress du parallélisme

Utilisez le Niveau 2 quand le provider lit ou mute des champs liés au parallélisme, ou quand la modification touche provider.configure(...), Megatron mpu, parallélisme de séquence, parallélisme de contexte, comportement du dispatcher MoE, ou paramètres de parallélisme tensoriel/parallélisme tensoriel expert.

Les variantes ci-dessous supposent que les exports du Niveau 0 ci-dessus sont toujours dans le shell ; chaque commande override seulement les valeurs testées.

Exemple de variante de stress dense :

COMMON_TP=2 \
COMMON_PP=2 \
COMMON_VPP=null \
COMMON_CP=1 \
INFER_TP=2 \
USE_MEGATRON_FSDP=False \
bash tests/special_e2e/run_ppo_trainer_megatron.sh

Exemple de variante de stress MoE, uniquement pour les checkpoints MoE compatibles :

COMMON_EP=2 \
COMMON_ETP=1 \
ROUTING_REPLAY_MODE=disabled \
bash tests/special_e2e/run_ppo_trainer_megatron.sh

Gardez ceux-ci comme des runs de suivi. Ne les rendez pas la première surface de débogage pour un nouveau provider.

Variante Megatron-FSDP optionnelle

Utilisez le Niveau 3 après que le Niveau 0 passe uniquement quand l'aval demande explicitement la couverture Megatron-FSDP ou la modification Bridge touche directement le wrapping FSDP, le sharding, le format de checkpoint, ou le comportement de l'optimizer distribué :

USE_MEGATRON_FSDP=True \
ALL_OFFLOAD=False \
COMMON_PP=1 \
COMMON_VPP=null \
COMMON_CP=1 \
COMMON_TP=1 \
INFER_TP=1 \
bash tests/special_e2e/run_ppo_trainer_megatron.sh \
  ++actor_rollout_ref.actor.megatron.override_transformer_config.gradient_accumulation_fusion=False \
  ++actor_rollout_ref.ref.megatron.override_transformer_config.gradient_accumulation_fusion=False \
  ++critic.megatron.override_transformer_config.gradient_accumulation_fusion=False

Pour le comportement FSDP natif de Bridge et les contraintes, lisez aussi @skills/perf-megatron-fsdp/SKILL.md.

Signal de convergence / apprentissage

Utilisez le Niveau 5 seulement quand la modification affecte la trainabilité ou quand la validation aval demande explicitement la convergence. Ne l'exigez pas pour chaque PR provider seul ; la convergence RL est plus lente, plus bruyante, et plus dépendante de l'environnement que le smoke de compatibilité.

L'objectif est une courte run de signal d'apprentissage, pas un benchmark complet. Préférez un petit modèle, données fixes, seed fixes quand disponible, et suffisamment d'étapes pour observer un mouvement de métrique non-aléatoire :

TOTAL_TRAIN_STEPS=20 \
SAVE_FREQ=-1 \
VAL_BEFORE_TRAIN=True \
TEST_FREQ=10 \
LORA_RANK=4 \
USE_MBRIDGE=True \
VANILLA_MBRIDGE=False \
VALUE_VANILLA_MBRIDGE=False \
USE_MEGATRON_FSDP=False \
ENGINE=vllm \
bash tests/special_e2e/run_ppo_trainer_megatron.sh

Pour un signal plus fort, exécutez 50-100 étapes si le temps GPU le permet. Gardez rollout, modèle de reward, dataset, tailles de batch, et checkpoint de modèle fixes entre les runs baseline et candidate.

Les preuves de convergence acceptable dépendent de la tâche, mais le rapport doit inclure au moins :

pas de NaNs ou infs dans loss, reward, KL, entropy, grad norm, ou métriques de logprob
nombre non-nul de paramètres trainables quand PEFT est activé
losses actor/critic et métriques liées aux rewards loggées pour plusieurs étapes
tendance de validation ou reward comparée au point de départ ou à une baseline connue comme bonne
pas de gradients zéro répétés, adaptateurs LoRA gelés, ou logprobs constants sauf si attendu

N'appelez pas une run de 20 étapes « convergée » au sens benchmark. Appelez-la « learning-signal passé » sauf si elle atteint un seuil de métrique pré-accordé.

Image du conteneur

Utilisez les images Docker officielles de verl comme source par défaut :

https://hub.docker.com/r/verlai/verl

Pour le chemin smoke PPO par défaut de cette compétence, choisissez un tag d'image verlai/verl saveur vLLM sauf si le test modifie intentionnellement le moteur rollout. Le wrapper maintenu défaut à vLLM, et la commande doit le rendre explicite avec :

ENGINE=vllm

Évitez d'utiliser sglang, TRT-LLM, ou des images génériques pour la run Niveau 0 par défaut sauf si le point du test est de valider ce backend rollout. Un backend-spécifique image peut échouer avant la construction du modèle, ce qui rend le résultat un mauvais signal pour un changement de provider Megatron-Bridge.

Épinglez le tag exact de l'image dans le log du test ou la description de PR :

export VERL_IMAGE=${VERL_IMAGE:-verlai/verl:<vllm-compatible-tag>}

Si le cluster nécessite des images Enroot/SquashFS, convertissez ou miroir le tag verlai/verl sélectionné via le processus normal du site, mais gardez le tag source visible dans le rapport.

Runs Slurm ou conteneur

Utilisez le conteneur standard du cluster et montez les deux checkouts dans le conteneur. Gardez le setup et la run PPO réelle dans la même étape de conteneur quand vous utilisez des chemins node-local tels que /tmp ; les caches de modèle node-local et les installations pip ad hoc disparaissent quand une étape de conteneur nouvelle commence. Gardez les chemins génériques dans les scripts committed à Megatron-Bridge :

export VERL_IMAGE=${VERL_IMAGE:-verlai/verl:<vllm-compatible-tag>}

srun <site-specific-slurm-options> \
  --container-image="${VERL_IMAGE}" \
  --container-mounts="${BRIDGE_REPO}:/workspace/Megatron-Bridge,${VERL_REPO}:/workspace/verl,<data-root>:<data-root>" \
  --container-workdir=/workspace/verl \
  bash -lc '
    export BRIDGE_REPO=/workspace/Megatron-Bridge
    export VERL_REPO=/workspace/verl
    export PYTHONPATH=$BRIDGE_REPO/src:$BRIDGE_REPO/3rdparty/Megatron-LM:$VERL_REPO
    ray stop --force || true
    MODEL_ID=<small-compatible-hf-model> \
    ENGINE=vllm \
    USE_MBRIDGE=True VANILLA_MBRIDGE=False VALUE_VANILLA_MBRIDGE=False \
    LORA_RANK=4 USE_MEGATRON_FSDP=False TOTAL_TRAIN_STEPS=1 SAVE_FREQ=-1 \
    bash tests/special_e2e/run_ppo_trainer_megatron.sh
  '

Utilisez un répertoire de log persistant sur un système de fichiers partagé ou $HOME pour les longs jobs Slurm. Les logs écrits uniquement dans le /tmp node-local peuvent disparaître quand l'allocation expire ou est annulée. Si un helper d'attachement de cluster exécute la commande via srun --pty, ne backgroundez pas la workload dans ce shell attaché ; le nettoyage d'étape peut la terminer immédiatement. Pour détacher en sécurité, backgroundez le helper d'attachement lui-même depuis le nœud de login :

mkdir -p "$HOME/verl_e2e_logs"
nohup env COMMAND='bash /path/to/run_verl_e2e.sh' \
  bash /path/to/<jobid>-attach.sh \
  > "$HOME/verl_e2e_logs/attach_driver_$(date +%Y%m%d_%H%M%S).out" 2>&1 &

Si un helper d'attachement entre dans un conteneur qui ne voit plus les checkouts ou répertoire de log attendus, traitez ce helper comme obsolète. Démarrez une nouvelle étape srun contre l'allocation existante avec --container-image, --container-mounts, et --container-workdir explicites.

Sur les clusters CUDA/H100, certains lanceurs définissent à la fois CUDA_VISIBLE_DEVICES et les variables ROCm telles que ROCR_VISIBLE_DEVICES. Si les workers verl échouent avant la construction du modèle avec Please don't set ROCR_VISIBLE_DEVICES when HIP/CUDA_VISIBLE_DEVICES is set, corrigez l'environnement du launcher/conteneur ou appliquez une contournement verl locale temporaire qui supprime ROCR_VISIBLE_DEVICES quand CUDA est déjà défini. Ne rapportez pas ceci comme une failure de provider Bridge.

Pour le débogage Slurm général et les motifs multi-nœud, lisez @skills/multi-node-slurm/SKILL.md.

Critères de passage

Un passage utile a tous les éléments suivants :

Les tests Bridge ciblés passent pour le comportement de provider/config/mapping.
verl utilise le checkout Bridge local via PYTHONPATH.
Le log verl montre VANILLA_MBRIDGE=False.
Une étape d'entraînement atteint l'achèvement, par exemple Training Progress: 100%|1/1|.
Aucune exception ne se produit pendant la setup du provider Bridge, l'import HF, le wrapping LoRA, le wrapping DDP, le wrapping optionnel FSDP quand activé, la setup de l'optimizer, la setup du checkpoint manager, ou l'étape d'entraînement.

L'arrêt Ray, les avertissements Python resource-tracker, ou la terminaison du worker DataLoader après completion peuvent être acceptables si l'étape d'entraînement a completé, les métriques pour training/global_step:1 ont été loggées, et le processus s'arrête avec succès. Mentionnez-les comme bruit résiduel de log.

Ne revendiquez pas l'e2e du modèle complet si la run a utilisé une config dummy, des données text-only pour un VLM, COMMON_EP=1 pour un changement expert-parallel, ou désactivé save/resume pour un changement checkpointing. Appelez-le le niveau exact qui a passé.

Ne revendiquez pas la convergence du Niveau 0. Revendiquez la convergence seulement du Niveau 5, et distinguez « signal d'apprentissage » de « convergence benchmark » dans le rapport.

Triage de failure

Si la construction du modèle échoue, vérifiez si le provider Bridge est finalisé avec les mêmes tailles parallèles que verl a initialisées via Megatron mpu.

Si LoRA échoue, vérifiez les noms des modules cibles et si le chemin du provider utilise les helpers PEFT Bridge non-vanilla attendus par verl.

Si la sauvegarde/chargement de checkpoint échoue, d'abord réexécutez sans save/resume (SAVE_FREQ=-1) pour séparer la construction du modèle du comportement de checkpoint.

Si rollout échoue avant la construction du actor, cela peut être un problème de moteur rollout verl plutôt qu'un problème de provider Bridge. Rapportez clairement la limite.

Si le log montre le mauvais chemin Bridge, arrêtez. Toute failure ou pass ultérieure n'est pas une preuve pour le changement de Bridge local.

Si la baseline échoue avant la construction du modèle à cause des données, du modèle de reward, de Ray, de vLLM, ou de la setup de package, corrigez d'abord l'environnement et ne le rapportez pas comme une failure de provider.

Si le téléchargement du modèle échoue avec No space left on device, déplacez HF_HOME, HF_HUB_CACHE, et MODEL_PATH vers un chemin scratch partagé ou node-local plus grand, puis réexécutez avec MODEL_PATH local explicite.

Format de résumé

Terminez chaque run avec un court résumé orienté utilisateur qui répond « Les livrables demandés ont-ils passé ? » avant d'ajouter des détails. Utilisez Pass, Fail, Skipped, ou Blocked pour chaque livrable, et ne rapportez pas un Pass global sauf si les critères de passage pour le niveau de couverture demandé ont été respectés.

Result: <Pass/Fail/Blocked> - <une phrase indiquant ce qui a été validé>
Requested coverage: <Niveau 0/1/2/3/4/5 et variantes demandées>
Model: <MODEL_ID ou MODEL_PATH>

Deliverables:
- Bridge-side checks: <Pass/Fail/Skipped> - <commande de test ou raison skipped>
- Local Bridge import in verl: <Pass/Fail> - <PYTHONPATH ou chemin du Bridge importé>
- verl Megatron backend run: <Pass/Fail/Skipped> - <LoRA + DDP ou variante demandée>
- Requested variants: <Pass/Fail/Skipped/Not requested> - <save/resume, parallélisme stress, Megatron-FSDP, run architecture-specific, ou learning-signal/convergence>
- Log capture: <Pass/Fail> - <chemin du log>

Evidence:
- Bridge repo: <commit> plus fichiers dirty
- verl repo: <commit> plus fichiers dirty
- Command: <commande exacte ou chemin du script>
- Key lines: <VANILLA_MBRIDGE=False, Training Progress completion, training/global_step:1, ou la première erreur pertinente>

Limitations:
- <dummy model, skipped save/resume, COMMON_EP=1, text-only data pour VLM, no convergence claim, shutdown warnings connus, etc.>

Follow-ups:
- <needed rerun, environment fix, provider fix, ou "none">

Si le job est bloqué avant la construction du modèle/provider Bridge par les données, le modèle de reward, Ray, vLLM, la dépendance, le disque, ou la setup du cluster, marquez le résultat global comme Blocked, pas Fail, et déclarez que ce n'est pas une preuve contre le provider Bridge.

Si tout livrable demandé n'a pas été exécuté, marquez-le Skipped ou Not requested avec la raison. Ne le rendez pas implicite dans les limitations.

verl-e2e-testing