Skill NeMo Evaluator

Référence rapide

CLI nemo-evaluator-launcher

# Exécuter l'évaluation
uv run nemo-evaluator-launcher run --config <path.yaml>
uv run nemo-evaluator-launcher run --config <path.yaml> -t <a_single_task_to_be_run_by_name>
uv run nemo-evaluator-launcher run --config <path.yaml> -t <task_name_1> -t <task_name_2> ...
uv run nemo-evaluator-launcher run --config <path.yaml> -o evaluation.nemo_evaluator_config.config.params.limit_samples=10 ...

# Prévisualiser la config résolue et le script sbatch sans exécuter l'évaluation
uv run nemo-evaluator-launcher run --config <path.yaml> --dry-run

# Vérifier le statut (--json pour sortie lisible par machine)
uv run nemo-evaluator-launcher status <invocation_id> --json

# Récupérer les infos d'exécution de l'évaluation (chemins de sortie, IDs de jobs slurm, hostname du cluster, etc.)
uv run nemo-evaluator-launcher info <invocation_id>

# Copier uniquement les logs (rapide — idéal pour déboguer)
uv run nemo-evaluator-launcher info <invocation_id> --copy-logs ./evaluation-results/

# Pour les artefacts : utiliser `nel info` pour découvrir les chemins. Si distant, SSH pour explorer et rsync ce dont vous avez besoin.
# Si local, lire directement à partir des chemins affichés par `nel info`.
# ssh <user>@<hostname> "ls <artifacts_path>/"
# rsync -avzP <user>@<hostname>:<artifacts_path>/{results.yml,eval_factory_metrics.json,config.yml} ./evaluation-results/<invocation_id>.<job_index>/artifacts/

# Reprendre une exécution échouée/interrompue (re-soumet le run.sub existant du répertoire d'exécution d'origine)
uv run nemo-evaluator-launcher resume <invocation_id>

# Lister les exécutions passées
uv run nemo-evaluator-launcher ls runs --since 1d   

# Lister les tâches d'évaluation disponibles (par défaut, affiche uniquement les tâches des conteneurs les plus récents)
uv run nemo-evaluator-launcher ls tasks
uv run nemo-evaluator-launcher ls tasks --from_container nvcr.io/nvidia/eval-factory/simple-evals:26.03

Flux de travail

Le flux de travail d'évaluation complet est divisé en étapes à suivre DANS L'ORDRE.

1. Créer ou modifier une config avec le skill nel-assistant. Si l'utilisateur fournit une exécution passée, utiliser son artefact config.yml comme point de départ.
2. Exécuter l'évaluation. Consulter references/run-evaluation.md lors de cette étape.
3. Surveiller la progression (OBLIGATOIRE après chaque nel run) : interroger le statut répétitivement jusqu'à SUCCESS/FAILED. Consulter references/check-progress.md.
4. Actions post-exécution (quand l'état terminal est atteint) :
   1. Quand le statut d'évaluation est SUCCESS, analyser les résultats. Consulter references/analyze-results.md lors de cette étape.
   2. Quand le statut d'évaluation est FAILED, déboguer l'exécution échouée. Consulter references/debug-failed-runs.md lors de cette étape.

Faits clés

• Les infos spécifiques aux benchmarks apprises lors du lancement/de l'analyse des évals doivent être ajoutées à references/benchmarks/
• PPP = compte Slurm / code de portefeuille de projet (le champ account dans cluster_config.yaml). Quand l'utilisateur dit « changer PPP en X », mettre à jour la valeur du compte (ex. <old_account> → <new_account>).
• Paires de jobs Slurm : NEL (nemo-evaluator-launcher) soumet des paires de jobs Slurm — un job RUNNING + un job restart PENDING (pour quand le walltime de 4h expire). Ne jamais annuler les jobs restart en attente — ils sont attendus et nécessaires.
• Exigence du cache HF : Pour les configs avec HF_HUB_OFFLINE=1, les modèles doivent être pré-téléchargés dans le cache HF de chaque cluster avant de lancer. Avant d'exécuter un modèle sur un nouveau cluster, toujours demander à l'utilisateur si le modèle est déjà caché là. Si non, sur le nœud de connexion du cluster : python3 -m venv hf_cli && source hf_cli/bin/activate && pip install huggingface_hub puis HF_HOME=<your_hf_cache_path> hf download <model> (sur les clusters HPC de style lustre, c'est généralement sous /lustre/.../<group>/users/<username>/cache/huggingface). Sans cela, vLLM échouera avec LocalEntryNotFoundError.
• data_parallel_size par nœud : dp_size=1 avec num_nodes=8 signifie 8 instances de modèle au total (une par nœud), équilibrées en charge par haproxy. Ne pas interpréter dp_size comme le nombre global de replicas.
• Intercepteur payload_modifier : La liste params_to_remove (ex. [max_tokens, max_completion_tokens]) supprime ces champs de la charge utile sortante, levant intentionnellement les limites de longueur de sortie pour que les modèles de raisonnement puissent réfléchir aussi longtemps qu'ils en ont besoin.
• Contournement auto-export git : Le conteneur d'export (python:3.12-slim) n'a pas git. Lors de l'installation du launcher à partir d'une URL git, définir auto_export.launcher_install_cmd pour installer git en premier (ex. apt-get update -qq && apt-get install -qq -y git && pip install "nemo-evaluator-launcher[all] @ git+...#subdirectory=packages/nemo-evaluator-launcher").
• Ne PAS utiliser nemo-evaluator-launcher export --dest local — il n'écrit qu'un JSON résumé (processed_results.json), il NE copie PAS les logs ou artefacts réels malgré l'acceptation des flags --copy_logs et --copy-artifacts. nel info --copy-artifacts fonctionne mais copie tout (très lent pour les grands benchmarks). Approche préférée : utiliser nel info pour découvrir les chemins — si local, lire directement ; si distant, SSH pour explorer et rsync uniquement ce dont vous avez besoin. Notez que nel info affiche les artefacts standard mais les benchmarks produisent des artefacts supplémentaires en sous-répertoires — explorer pour les trouver.