> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/fr/commencer/reinforcement-learning-rl-guide/grpo-long-context.md). # Apprentissage par renforcement GRPO avec un contexte 7x plus long Découvrez comment Unsloth permet un fine-tuning RL avec des contextes ultra-longs. Le plus grand défi de l'apprentissage par renforcement (RL) est de prendre en charge de longues traces de raisonnement. Nous introduisons de nouveaux algorithmes de batching pour permettre \~**un contexte 7x plus long** (peut dépasser 12x) Entraînement RL sans dégradation de la précision ni de la vitesse par rapport à d'autres configurations optimisées utilisant FA3, des kernels et des pertes chunkées. * Unsloth entraîne désormais gpt-oss en QLoRA avec **380K de contexte** sur un seul GPU NVIDIA B200 de 192 Go * [Qwen3](/docs/fr/modeles/tutorials/qwen3-how-to-run-and-fine-tune.md#fine-tuning-qwen3-with-unsloth)-8B GRPO atteint **110K de contexte** sur un H100 doté de 80 Go de VRAM via [vLLM](#vllm-for-rl) et QLoRA, et **65K** pour [gpt-oss](/docs/fr/modeles/gpt-oss-how-to-run-and-fine-tune/gpt-oss-reinforcement-learning.md) avec LoRA BF16. * Avec 24 Go de VRAM, gpt-oss atteint un contexte de 20K et 32K pour [Qwen3-VL](/docs/fr/modeles/tutorials/qwen3-how-to-run-and-fine-tune/qwen3-vl-how-to-run-and-fine-tune.md)-8B QLoRA * Les exécutions RL GRPO d'Unsloth avec Llama, Gemma et tous les modèles prennent automatiquement en charge des contextes plus longs Nos nouveaux kernels et algorithmes de déplacement des données et de batching débloquent davantage de contexte grâce à : * Dynamic [découpage aplati de la séquence](#flattened-sequence-length-chunking) pour éviter de matérialiser d'énormes tenseurs de logits et * [Déchargement du log softmax](#offloading-activations-for-log-softmax) des activations, ce qui empêche une croissance silencieuse de la mémoire au fil du temps. {% hint style="info" %} **Vous pouvez combiner toutes les fonctionnalités d'Unsloth ensemble :** 1. d'Unsloth [partage de poids](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md) fonctionnalité avec [vLLM](https://github.com/vllm-project/vllm) et notre fonctionnalité de veille dans [RL économe en mémoire](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md) 2. d'Unsloth [Flex Attention](/docs/fr/modeles/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) pour gpt-oss à long contexte et notre [500K Context Training](/docs/fr/blog/500k-context-length-fine-tuning.md) 3. entraînement Float8 dans [FP8 RL](/docs/fr/commencer/reinforcement-learning-rl-guide/fp8-reinforcement-learning.md) et le [checkpointing asynchrone des gradients](https://unsloth.ai/blog/long-context) et bien plus encore {% endhint %} ### :tada:Premiers pas Pour commencer, vous pouvez utiliser n'importe quel [Notebooks GRPO](/docs/fr/commencer/unsloth-notebooks.md#grpo-reasoning-rl-notebooks) (ou mettre à jour Unsloth s'il est installé localement) : {% columns %} {% column width="33.33333333333333%" %} [**gpt-oss-20b**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(20B\)-GRPO.ipynb) GSPO {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [**Qwen3-VL-8B**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_VL_\(8B\)-Vision-GRPO.ipynb) de RL vision {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [Qwen3-8B - **FP8**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_8B_FP8_GRPO.ipynb) L4 GPU {% embed url="" %} {% endcolumn %} {% endcolumns %} Adopter Unsloth pour vos tâches RL fournit un cadre robuste pour gérer efficacement des modèles à grande échelle. Pour utiliser efficacement les améliorations d'Unsloth : * **Recommandations matérielles**: Utilisez un NVIDIA H100 ou l'équivalent pour une utilisation optimale de la VRAM. * **Conseils de configuration**: Assurez-vous que `batch_size` et `gradient_accumulation_steps` les paramètres soient adaptés à vos ressources de calcul pour des performances optimales. {% hint style="success" %} Mettez à jour Unsloth vers la dernière version PyPI pour obtenir les dernières mises à jour : ``` pip install --upgrade --no-cache-dir unsloth unsloth_zoo ``` {% endhint %} Nos benchmarks mettent en évidence les économies de mémoire obtenues par rapport aux versions antérieures pour GPT OSS et Qwen3-8B. Les deux graphiques ci-dessous (sans [veille](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md)) ont été exécutés avec `batch_size = 4` et `gradient_accumulation_steps=2` , car la veille utilise par conception toute la VRAM. Pour nos benchmarks, nous comparons BF16 GRPO à Hugging Face avec toutes les optimisations activées (tous les kernels de la bibliothèque kernels, Flash Attention 3, kernels de perte chunkée, etc.) : ### :1234:Découpage aplati de la longueur de séquence Auparavant, Unsloth réduisait l'utilisation de la mémoire en RL en évitant la matérialisation complète du tenseur de logits grâce à un découpage sur la dimension du batch. Une estimation approximative de la VRAM nécessaire pour matérialiser les logits pendant la passe avant est présentée dans l'équation (1). $$ \text{Equation 1: } \text{Logit Memory (GB)} = \frac{\text{batch size} \times\text{context length} \times \text{vocab dim}}{1024^3} $$ En utilisant cette formulation, une configuration avec `batch_size = 4`, `context_length = 8192`et `vocab_dim = 128,000` nécessiterait environ **3,3 Go de VRAM** pour stocker le tenseur de logits. Par [Long Context gpt-oss](/docs/fr/modeles/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) l'an dernier, nous avons ensuite introduit une approche de perte fusionnée pour GRPO. Cette approche garantit qu'un seul échantillon du batch est traité à la fois, réduisant considérablement l'utilisation maximale de la mémoire. Dans la même configuration, l'utilisation de la VRAM tombe à environ **0,83 Go**, comme le montre l'équation (2). $$ \text{Equation 2: }\text{Logit Memory (GB)} = \frac{\text{context length} \times \text{vocab dim}}{1024^3} $$

Figure 1 : gpt-oss BF16 GRPO LoRA (Unsloth vs HF avec toutes les optimisations activées)

Figure 2 : Qwen3-8B QLoRA GRPO LoRA (Unsloth vs HF avec toutes les optimisations activées)

Dans cette mise à jour, nous prolongeons encore la même idée en introduisant un découpage sur la **dimension de séquence** également. Au lieu de matérialiser les logits pour l'ensemble de l' `(batch_size × context_length)` espace d'un seul coup, nous aplatissons ces dimensions et les traitons en plus petits morceaux à l'aide d'un multiplicateur configurable. Cela permet à Unsloth de prendre en charge des contextes nettement plus longs sans augmenter l'utilisation maximale de la mémoire. Dans la figure 5 ci-dessous, nous utilisons un multiplicateur de `max(4, context_length // 4096)`, bien que n'importe quel multiplicateur puisse être spécifié selon le compromis mémoire–performance souhaité. Avec ce paramètre, la même configuration d'exemple (`batch_size = 4`, `context_length = 8192`, `vocab_dim = 128,000`) ne nécessite désormais que **0,207 Go de VRAM** pour la matérialisation des logits. $$ \text{Equation 3: }\text{Logit Memory (GB)} = \frac{\frac{\text{context length}}{\text{multiplier}} \times \text{vocab dim}}{1024^3} $$

Figure 3 : gpt-oss-20b (H100) nouvelle version d'Unsloth vs ancienne

Figure 4 : Qwen3-8B (H100) nouvelle version d'Unsloth vs ancienne

Figure 5 : gpt-oss-20b (H100)

Figure 6 : Qwen3-8B (B200)

Cette mise à jour se reflète dans le `chunked_hidden_states_selective_log_softmax` ci-dessous, qui prend désormais en charge le découpage à la fois sur les dimensions du batch et de la séquence. Pour préserver le tenseur de logits (`[batch_size, context_length, vocab_dim]`), il est toujours découpé selon la dimension du batch. Le découpage supplémentaire de la séquence est contrôlé via `unsloth_logit_chunk_multiplier` dans la configuration GRPO ; s'il n'est pas défini, il prend par défaut `max(4, context_length // 4096)`. `input_ids_chunk[0]` correspond à la taille des mini-batchs des hidden states dans l'optimisation 2. ```python logprobs_chunk = chunked_hidden_states_selective_log_softmax( new_hidden_states_chunk, lm_head, completion_ids, chunks=input_ids_chunk.shape[0]*multiplier, logit_scale_multiply=logit_scale_multiply, logit_scale_divide=logit_scale_divide, logit_softcapping=logit_softcapping, temperature=temperature, ) ``` 1. Nous utilisons torch.compile avec des options de compilation personnalisées pour réduire la VRAM et augmenter la vitesse. 2. Tous les logits découpés sont convertis en float32 pour préserver la précision. 3. Nous prenons en charge le softcapping des logits, le réglage de la température et toutes les autres fonctionnalités. ### :ghost:Découpage des états cachés Nous avons également observé qu'à des longueurs de contexte plus élevées, les états cachés peuvent contribuer de manière significative à l'utilisation de la mémoire. À titre de démonstration, nous supposerons `hidden_states_dim=4096`. L'utilisation de mémoire correspondante suit une formulation similaire au cas des logits, présentée ci-dessous. $$ \text{Hidden States Memory (GB)} = \frac{\text{batch size} \times\text{context length} \times \text{hidden states dim}}{1024^3} $$ Avec un `batch_size = 8` et `context_length = 64000`, cela entraînerait une utilisation de la VRAM d'environ **2 Go**. Dans cette version, nous introduisons un découpage optionnel sur la dimension du batch pour le tenseur des états cachés lors du calcul des log-probabilités. Cela diviserait l'utilisation de la VRAM par la taille du batch ou, dans ce cas, la ferait passer à **0,244 Go**.Cela réduit la VRAM de pointe nécessaire pour matérialiser les états cachés, comme le montre l'équation mise à jour ci-dessous : $$ \text{Hidden States Memory (GB)} = \frac{\text{context length} \times \text{hidden states dim}}{1024^3} $$ Comme pour notre perte d'entropie croisée dans notre [500K Context Training](/docs/fr/blog/500k-context-length-fine-tuning.md) version, la nouvelle implémentation **ajuste automatiquement le batching des états cachés**. Les utilisateurs peuvent également contrôler ce comportement via `unsloth_grpo_mini_batch`. Cependant, augmenter `unsloth_grpo_mini_batch` au-delà de la valeur optimale peut entraîner une légère augmentation des performances ou un ralentissement (généralement plus rapide) par rapport à la fonction de perte précédente. Cependant, lors d'une exécution GPT-OSS (`context_length = 8192, batch_size = 4, gradient_accumulation_steps = 2`), définir `unsloth_grpo_mini_batch = 1` et `unsloth_logit_chunk_multiplier = 4` se traduit par **peu ou pas de dégradation de la vitesse tout en réduisant l'utilisation de la VRAM d'environ 5 Go** par rapport aux anciennes versions d'Unsloth.
{% hint style="success" %} **Remarque :** Dans les figures 3 et 4, nous utilisons la taille de batch effective maximale, qui est de 8 dans cette configuration. La taille de batch effective est calculée comme `batch_size × gradient_accumulation_steps`, ce qui donne `4 × 2 = 8`. Pour une explication plus approfondie du fonctionnement des tailles de batch effectives en RL, consultez notre [documentation avancée sur le RL](/docs/fr/commencer/reinforcement-learning-rl-guide/advanced-rl-documentation.md). {% endhint %} ### :cactus:Déchargement des activations pour le log softmax Au cours du développement de cette version, nous avons découvert que lors du pavage sur la dimension du batch pour les états cachés, les activations n'étaient pas déchargées après le calcul fusionné des logits et des logprobs. Comme les logits sont calculés un batch à la fois à l'aide de `hidden_states[i] @ lm_head`, la logique existante de déchargement des activations et de gradient checkpointing, conçue pour fonctionner dans la passe avant du modèle, ne s'appliquait pas dans ce cas. Pour y remédier, nous avons ajouté une logique explicite pour décharger ces activations en dehors de la passe avant du modèle, comme le montre le pseudo-code Python ci-dessous : ```python class Unsloth_Offloaded_Log_Softmax(torch.autograd.Function): def forward(...): with torch.no_grad(): output = chunked_hidden_states_selective_log_softmax(hidden_states, lm_head, ...) return output def backward(ctx, grad_output): hidden_states = ctx.saved_hidden_states hidden_states.requires_grad_(True) with torch.enable_grad(): output = chunked_hidden_states_selective_log_softmax(hidden_states, lm_head, ...) torch.autograd.backward(output, grad_output) return ... ``` {% hint style="success" %} **Remarque :** Cette fonctionnalité n'est efficace que lors du découpage sur la dimension du batch ou lorsque `unsloth_grpo_mini_batch > 1`. Si tous les états cachés sont matérialisés d'un coup pendant la passe avant (c'est-à-dire `unsloth_grpo_mini_batch = 1`), la passe arrière nécessite la même quantité de mémoire sur le GPU, que les activations soient déchargées ou non. Étant donné que le déchargement des activations entraîne un léger ralentissement sans réduire l'utilisation de la mémoire dans ce cas, il n'apporte aucun bénéfice. {% endhint %} ### :sparkles:Configuration des paramètres : Si vous ne configurez pas `unsloth_grpo_mini_batch` et `unsloth_logit_chunk_multiplier`, nous allons **ajuster automatiquement ces deux paramètres** pour vous en fonction de votre VRAM disponible et selon la taille de votre longueur de contexte. Voici toutefois comment vous pouvez modifier ces variables dans votre exécution GRPO : ```python training_args = GRPOConfig( ... unsloth_grpo_mini_batch = 3 unsloth_logit_chunk_multiplier = 2 ... ) ``` Une visualisation des optimisations et `unsloth_grpo_mini_batch` et `unsloth_logit_chunk_multiplier` peut être vue dans le schéma ci-dessous.
Les 3 matrices représentent le batch global plus grand ou `unsloth_grpo_mini_batch` (représenté par le nombre d'accolades noires) et les lignes de chacune des matrices représentent la longueur de contexte que le `unsloth_logit_chunk_multiplier` découpe la longueur de séquence en (représenté par le nombre d'accolades rouges). ### :vhs:vLLM pour le RL **Pour les workflows RL, la phase d'inférence/génération est le principal goulot d'étranglement**. Pour y remédier, nous utilisons [vLLM](https://github.com/vllm-project/vllm), ce qui a accéléré la génération jusqu'à 11x par rapport à la génération normale. Depuis que GRPO s'est popularisé l'an dernier, vLLM est un composant essentiel de la plupart des frameworks RL, y compris Unsloth. Nous tenons à exprimer notre gratitude à l'équipe vLLM et à tous ses contributeurs pour leur travail, car ils jouent un rôle central dans l'amélioration du RL d'Unsloth ! Pour essayer le RL à contexte plus long, vous pouvez utiliser n'importe quel [Notebooks GRPO](/docs/fr/commencer/unsloth-notebooks.md#grpo-reasoning-rl-notebooks) (ou mettre à jour Unsloth s'il est installé localement) : {% columns %} {% column width="33.33333333333333%" %} [**gpt-oss-20b**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(20B\)-GRPO.ipynb) - GSPO {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [**Qwen3-VL-8B**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_VL_\(8B\)-Vision-GRPO.ipynb) de RL vision {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [Qwen3-8B - **FP8**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_8B_FP8_GRPO.ipynb) L4 GPU {% embed url="" %} {% endcolumn %} {% endcolumns %} Remerciements : un immense merci à l'équipe et aux bibliothèques Hugging Face pour alimenter Unsloth et rendre cela possible. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://unsloth.ai/docs/fr/commencer/reinforcement-learning-rl-guide/grpo-long-context.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.