nemotron-customize

Objectif

Utilise cette skill pour transformer une demande de customisation de modèle en un pipeline d'étapes Nemotron natif du repo. Elle planifie le DAG des étapes, valide le câblage des artefacts et crée uniquement les configs YAML nécessaires pour exécuter les étapes existantes.

Utilise-la uniquement pour inspecter, configurer, valider, exécuter ou soumettre les étapes Nemotron existantes ou les pipelines d'entraînement/customisation multi-étapes. Si la demande concerne un frontend, un tableau de bord, une visualisation, des conseils ML génériques, la facturation/l'accès, ou une tâche de codage sans rapport, arrête-toi avec une note d'étendue courte et n'inspecte pas le catalogue d'étapes ni n'édite les fichiers lors de ce tour.

Notes de sécurité

Cette skill peut utiliser Write pour créer ou modifier les fichiers YAML/README et Bash pour exécuter des commandes du repo. Confirme avec l'utilisateur avant les écritures de fichiers ou l'exécution de shell. Maintiens l'utilisation de Bash limitée aux commandes sûres pour le repo, comme uv run nemotron steps ..., python -m pytest ..., git status/diff, et les commandes de validation ciblées. N'exécute jamais les dumps d'environnement (env, printenv, export large) ni les commandes qui exposent des valeurs secrètes.

Exigences

• Checkout du repo Nemotron avec src/nemotron/steps/ présent.
• Invoque depuis la racine du repo. Tous les chemins dans ce document sont relatifs à la racine du repo.
• Contraintes de modèle, données, matériel, backend et sortie fournies par l'utilisateur avant d'écrire les configs.
• Credentials du backend uniquement quand l'étape sélectionnée en a besoin (traduction, W&B, endpoints hébergés).

Limitations

• N'invente pas de nouvelles étapes du catalogue quand une étape existante convient.
• Du nouveau code Python/shell uniquement en mode Explorer après que l'écart soit explicite.
• Les demandes de déploiement post-entraînement ne sont pas dans le périmètre.

Invocation : /nemotron-customize. Le repo sous src/nemotron/steps/ est la source de vérité ; cette skill orchestre et ne duplique pas la connaissance par étape.

Ordre de priorité : (1) réutiliser le code repo existant, les CLIs, les recettes, les étapes, les runners et les configs ; (2) ajouter des configs YAML pour ta demande ; (3) générer du nouveau Python/shell uniquement quand le repo ne peut pas satisfaire la demande, et nomme d'abord l'écart.

Pour une demande de commande : vérifie la racine du repo, lis le catalogue d'étapes, lis le step.toml sélectionné, vérifie que la config demandée existe, lis le TOML env actif pour tout profil distant, puis émets la commande complète. Ne devine pas les profils --batch à partir d'exemples ou de conventions de nommage.

Arbre de décision rapide

• AutoModel vs Megatron-Bridge : petit nombre de GPU, modèle Hugging Face, LoRA/PEFT, ou JSONL chat style OpenAI → chemin AutoModel (sft/automodel ou l'étape PEFT AutoModel correspondante). Entraînement distribué large, données Parquet empaquetées/binidx, ou fine-tuning complet → Megatron-Bridge, mais vérifie par rapport à hardware.md et le README de catégorie en premier.
• Les entrées BYOB / benchmark MCQ vont vers byob/mcq, PAS translate/nemo_curator. BYOB préserve le schéma multiple-choix (question, choix, réponse) ; le chemin traduction aplatira ou supprimera ces champs. Déclenche sur des phrases comme « benchmark BYOB », « MCQ », « Parquet benchmark d'évaluation », « prep multiple-choix ».
• Curate puis traduis : quand l'utilisateur dit « curate et translate », « filter puis translate », ou « prep données avant traduction », chaîne curate/nemo_curator (filtre JSONL brut) → translate/nemo_curator (traduit JSONL curé). Ne saute pas l'étape de curation.
• Conversion de checkpoint : route « Megatron to HF », « HF export », « convert checkpoint », ou « iter_ to safetensors » vers convert/megatron_to_hf ; route « HF to Megatron » imports vers convert/hf_to_megatron. Utilise une source `iter_` concrète pour les exports Megatron.
• Évaluation endpoint ou checkpoint existant : route les smoke tests d'endpoint hébergé et les demandes de benchmark vers eval/model_eval ; utilise tiny_chat pour le smoke chat hébergé et default pour l'évaluation de checkpoint Megatron.
• Aucun profil env TOML présent : n'invente pas de profils Lepton ou --batch ; demande à l'utilisateur ou bascule vers l'exécution locale.

Entrées requises avant de finaliser les configs ou commandes :

• model, input_path, output_dir, matériel/nombre de GPU, backend/profil env, et toute variable d'environnement de clé API nécessaire, comme HF_TOKEN ou une clé d'évaluateur.
• Pour les commandes de traduction, collecte aussi server.url, langues cible/source, et les chemins d'entrée/sortie visibles au runtime.
• Pour BYOB, collecte chemin du benchmark/document source, étape (prepare, generate, translate, ou all), langues cible/source lors de la traduction, et répertoire de sortie.
• Pour conversion, collecte chemin du checkpoint source, chemin de sortie, source de modèle/config, et si la source est HF, Megatron iter_*, ou un adaptateur LoRA.
• Pour eval, collecte URL endpoint/ID modèle ou chemin du checkpoint, IDs de tâches, type d'endpoint, nom de variable d'environnement de clé API, et limite d'échantillon.

Forme de réponse pour les recommandations : Decision, Why, Required inputs, Config/command, Avoid, et Next step. Appelle toujours la pile à éviter quand les contraintes de l'utilisateur la rendent mauvaise.

Comment les informations sont divisées (et où les trouver)

Si deux sources disent la même chose, celle plus profonde, plus spécifique gagne (step.toml > category README.md > ce fichier).

Instructions

Pipeline workflow (≥2 étapes) : Orient → Plan → Act → Verify. Découvre les étapes candidates, propose un DAG avec câblage d'artefacts validé, attends l'approbation, crée les configs YAML minimales, et re-vérifie avant de rapporter fait. Pas de conseils ML génériques — src/nemotron/steps/ est la source de vérité.

Flux de commande mono-étape :

1. Confirme que la racine du repo a pyproject.toml et src/nemotron/steps/.
2. Exécute uv run nemotron steps list --json si disponible ; sinon lis src/nemotron/steps/STEPS.md.
3. Lis le step.toml de l'étape sélectionnée et la config vérifiée demandée.
4. Pour l'exécution distante, lis NEMOTRON_ENV_FILE ou un env*.toml à la racine du repo et choisis une section actuelle dont le profil correspond à l'étape.
5. Émets la commande complète en une réponse ; puis ajoute la raison brève pour les choix de config/profil. Pour la traduction, lis aussi src/nemotron/steps/translate/README.md et retourne Decision, Config, Run, Output, Env.

Tiers source pour les réponses de commande — Verified (CLI + manifest + config + env + dry-run tous réussis), Repo-grounded (manifest/config/env lus, pas de dry-run), Blocked (un fichier repo ou env TOML requis manque — nomme-le et arrête-toi avant de deviner).

Commandes canoniques :

uv run nemotron steps run <step_id> -c <config-or-path> --dry-run
uv run nemotron steps run <step_id> -c <config-or-path> --dry-run --batch <profile>
uv run nemotron steps run <step_id> -c <config-or-path> --batch <profile>

Workflow

Quatre phases, dans l'ordre : Orient → Plan → Act → Verify. Ne saute jamais Verify. Pour les listes de contrôle détaillées des phases et les règles d'implémentation du mode Explorer, lis references/WORKFLOW.md.

Nuances opérationnelles

• Les configs smoke (tiny.yaml, tiny_chat.yaml) sont des tests de câblage, pas des preuves de qualité.
• Les références ${art:...} appartiennent aux configs soutenues par des recettes ; les YAML standalone utilisent des chemins simples.
• Garde les données bin/idx de prétraitement et blend.json depuis la même version de Nemotron.

Exemples

• Étape unique : lis manifest + config + profil env, puis retourne une commande uv run nemotron steps run <step_id> -c <config> --dry-run complète.

• Translate (commande one-shot) : pour les demandes « translate EN → <lang> », collecte d'abord server.url, model, langue source/cible, api_key_env, et chemins d'entrée/sortie visibles au runtime, puis émets la commande complète en une réponse (ne divise pas entre les tours) :

  uv run nemotron steps run translate/nemo_curator \
    -c <translate-config.yaml> \
    --batch <env-profile-from-env.toml>

• Curate puis traduis : chaîne curate/nemo_curator → translate/nemo_curator. L'étape de curation produit du JSONL filtré qui devient l'entrée de l'étape de traduction. Les deux étapes ont besoin d'overlays YAML ; câble la output_dir de curation à la input_glob de traduction.

• Prep benchmark BYOB : route les entrées Parquet MCQ par byob/mcq, pas translate/nemo_curator, pour que le schéma multiple-choix soit préservé.

• Pipeline SFT : planifie le DAG (data_prep → sft/megatron_bridge ou sft/automodel), valide les arêtes d'artefact via types.toml, puis crée les overlays YAML.

Deux modes

Mode Catalog — une étape existe

Chemin rapide : STEPS.md → category/README.md → step.toml → step.py → adapter YAML config. Utilise chaque fois que la demande de l'utilisateur mappe à une étape du catalogue.

Mode Explorer — aucun chemin repo ne le supporte

Utilise uniquement après avoir confirmé qu'aucune étape, runner, recette, CLI, ou surface de config YAML existante ne peut satisfaire la demande. Suis references/WORKFLOW.md.

Choisir un mode

Limites

Fais : construis des pipelines à partir d'étapes existantes et cite step.toml directement ; réutilise les CLIs/runners/recettes repo en premier ; adapte les configs (ne copie pas default.yaml aveuglément) ; demande le matériel/données/backend/chemin de sortie ; présente les tradeoffs (Megatron-Bridge vs AutoModel, full FT vs LoRA) ; présente le plan et attends l'approbation.

Ne fais pas : invente des étapes ; saute Plan pour les pipelines ≥2 étapes ; génère du Python ou shell quand YAML suffit ; importe des modules en dehors du code de référence de l'étape ; ajoute la monitoring/W&B à moins que ce soit demandé ; tuner le parallelism au-delà de hardware.md et [[strategies]] ; suppose le nombre de GPU ; génère des wrappers Slurm/Airflow/Kubeflow ; gère les demandes sans entraînement dans cette skill ; modifie src/nemotron/steps/ ; restate les règles par étape ici — lie le README.md de l'étape.

Troubleshooting