Débogage Nemo Gym

Vérification d'invocation

Utilisez cette skill quand quelque chose a échoué ou paraît suspect dans une exécution Nemo Gym. Si la tâche consiste à ajouter un nouvel env, utilisez la skill nemo-gym-env-integration ; si elle concerne un changement de comportement de profiling, utilisez la skill nemo-gym-reward-profiling.

Déboguez par classification, pas par devinette. Le premier objectif est de décider si le problème concerne :

• infra : Slurm, Ray, container, filesystem, network, ports
• model serving : démarrage/disponibilité/throughput de vLLM
• config : bundle config incorrect, agent manquant, mauvais args supplémentaires
• data/schema : les champs JSONL ne correspondent pas aux attentes du verifier/resource server
• verifier/runtime : exception du resource server ou réponse verify malformée
• cache/resume : inputs matérialisés obsolètes ou sortie de rollout partielle
• throughput/resources : concurrence trop élevée, goulot du judge, latence tool/sandbox

Ordre de débogage

1. Vérifiez l'état et les logs du job Slurm/Ray.
2. Vérifiez la disponibilité de vLLM et la disponibilité de /models.
3. Vérifiez la disponibilité du serveur Gym : tous les serveurs attendus ont démarré.
4. Vérifiez le routage des tools si l'env utilise des tools ; vérifiez la disponibilité du sandbox uniquement si un sandbox est configuré.
5. Vérifiez les inputs matérialisés et les timestamps des données source.
6. Vérifiez la sortie de rollout et les nombres de résultats profiling/metrics.
7. Inspectez la première réelle exception verifier, pas le bruit d'arrêt.
8. Comparez le schéma de la ligne défaillante par rapport au modèle de requête du resource server.

Suspects à haute valeur

• Si les données ont changé et que resume_from_cache était activé, les inputs matérialisés obsolètes sont un suspect de première classe.
• Si la sortie de rollout contient peu de lignes et que profiling est vide, inspectez les erreurs verifier et le cache de sortie partielle.
• Si tous les serveurs sont prêts mais que verifier retourne 422/500, inspectez le schéma du corps de la requête avant de déboguer l'infra.
• Si les tool envs plantent ou fonctionnent partiellement, vérifiez la propriété/chargement des tools avant de modifier les paramètres du modèle ; vérifiez la disponibilité du sandbox uniquement quand un sandbox fait réellement partie de l'env.
• Si les lignes tool-call échouent avant la génération avec des erreurs grammar/schema vLLM, lisez references/vllm-tool-call-schema-checks.md et exécutez une vérification statique de tool-schema avant de modifier les wrappers Gym.
• Si les logs ne montrent que des 500 "inner server" imbriqués sans le vrai corps provider/verifier, activez d'abord la visibilité de requête existante avec ++global_aiohttp_client_request_debug=True. Lisez references/request-boundary-visibility.md avant de changer le code.

Chargement de références

• Lisez references/error-profiles.md pour classifier la couche défaillante avant de changer le code ou les données.
• Lisez references/diagnostic-snippets.md quand vous avez besoin de commandes prêtes à copier-coller pour inspecter les logs, les nombres de sorties, les inputs matérialisés, la forme JSONL de rollout, la disponibilité du serveur, ou les résumés de reward sans muter l'état de la run.
• Lisez references/vllm-tool-call-schema-checks.md quand un dataset tool-call peut être rejeté par la compilation grammar vLLM/Outlines avant toute génération significative.
• Lisez references/request-boundary-visibility.md quand /run 500s cache l'identité de ligne ou que des 500 Gym imbriqués cachent l'erreur réelle model/verifier/provider. Elle couvre le flag de débogage Gym existant, les marqueurs de requête expédiés, les corps provider vides, et l'escalade côté provider vLLM.

Modèle de communication

Quand vous signalez, déclarez :

• symptôme observé
• couche défaillante
• preuves des logs/fichiers
• cause probable
• prochaine action concrète