> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://fr.nvidia-localization.ferndocs.com/fr/nemo/rl/0-2-1/model-quirks/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://fr.nvidia-localization.ferndocs.com/_mcp/server.

# Particularités du Modèle

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éé](https://github.com/vllm-project/vllm/blob/964472b9667508b1d4a7ed92068ff81740ae0036/vllm/model_executor/models/gemma3.py#L372) 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](https://github.com/pytorch/pytorch/blob/main/torch/distributed/tensor/experimental/_attention.py). 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](https://github.com/pytorch/pytorch/blob/134179474539648ba7dee1317959529fbd0e7f89/torch/distributed/tensor/experimental/_attention.py#L262).

* 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](https://github.com/huggingface/transformers/blob/bda75b4011239d065de84aa3e744b67ebfa7b245/src/transformers/modeling_utils.py#L2317) 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](https://github.com/NVIDIA-NeMo/RL/issues/659) 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 :**

* Les graphiques CUDA doivent être désactivés en définissant `enforce_eager: True` dans la configuration vLLM ([https://github.com/NVIDIA-NeMo/RL/pull/857](https://github.com/NVIDIA-NeMo/RL/pull/857) force l'exécution eager par défaut).

## 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.

```bash
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.