Passer à la navigation
Guides

Particularités du Modèle

Afficher en Markdown

Ce document décrit les cas spéciaux et les comportements spécifiques aux modèles nécessitant un traitement personnalisé dans NeMo RL. Ces cas spéciaux sont contrôlés par l’énumération ModelFlag.

Gemma-3

Initialisation vLLM

Les modèles Gemma-3 présentent un problème spécifique avec l’initialisation des poids factices vLLM en raison d’un bug vLLM où un tampon normalizer est créé qui n’est pas présent dans le modèle Hugging Face. Cela provoque le réglage du tampon normalizer sur des poids factices à l’initialisation, qui ne sont jamais mis à jour avec les valeurs correctes lors du réajustement du modèle. Comme solution de contournement pour ce problème, nous n’utilisons pas l’initialisation des poids factices pour vLLM avec les modèles Gemma-3 et utilisons plutôt le paramètre load_format="auto" pour charger les poids complets à l’initialisation.

Traitement Spécial :

  • Nous utilisons automatiquement load_format="auto" pour les modèles Gemma-3 lors de l’initialisation de vLLM.
  • Cela évite les problèmes d’initialisation des poids factices, où les poids factices de ce tampon ne seraient jamais remplacés lors du réajustement.

Runtime vLLM V1

NeMo-RL utilise le runtime vLLM V1 pour l’inférence synchrone et asynchrone. Le runtime V1 offre de meilleures performances et stabilité pour l’inférence.

Traitement Spécial :

  • Les modes d’inférence sync et async utilisent le runtime V1 par défaut.
  • Les utilisateurs peuvent remplacer le runtime V0 en définissant la variable d’environnement NRL_VLLM_USE_V1=0.
  • Important : L’implémentation asynchrone utilise toujours le runtime V1. Les utilisateurs qui ont besoin d’utiliser le runtime V0 doivent basculer vers l’inférence synchrone en définissant policy.generation.vllm_cfg.async_engine=False.

Context Parallel avec FSDP2

  • NeMo-RL a implémenté cette fonctionnalité basée sur l’implémentation CP de torch implementation. Et nous héritons de ses limitations. Le support au niveau du modèle pour CP ne dépend que des arguments transmis à torch.nn.functional.scaled_dot_product_attention. Actuellement, NeMo-RL transmet tous les masques d’attention à un dans model.forward. Pour Gemma-3, il n’ignorera pas le masque d’attention car attn_bias n’est pas None, ce qui n’est pas pris en charge par torch CP. Veuillez consulter l’assertion.

  • Context parallel ne peut pas être utilisé avec l’empaquetage de séquence. L’empaquetage de séquence nécessite attn_implementation="flash_attention_2", ce qui entre en conflit avec context parallel qui nécessite l’implémentation SDPA. Reportez-vous ici pour plus de détails.

  • C’est un problème connu que context parallel ne peut pas être utilisé avec sequence parallel. Reportez-vous ici pour plus de détails.

Problèmes de Convergence de la Recette DeepScaleR

La recette DeepScaleR (par exemple, examples/configs/grpo-deepscaler-1.5b-8K.yaml) a été trouvée en proie à des problèmes de convergence lorsque les graphiques CUDA sont activés dans vLLM.

Traitement Spécial :

Délai de Rollout Asynchrone vLLM

La génération asynchrone vLLM a un délai configurable pour attendre les résultats d’échantillonnage individuels. Ceci est particulièrement important pour les séquences plus longues sur les grands modèles.

export NRL_VLLM_ASYNC_TIMEOUT_SECONDS=1800  # Défaut : 600 (10 minutes)

Si vous rencontrez des erreurs de délai dépassé, le système suggérera de doubler la valeur de délai actuelle.