# Apprentissage par renforcement en FP8
Nous introduisons l'entraînement en précision FP8 pour le RL, rendant FP8 GRPO désormais possible sur **GPU grand public** (RTX 40, 50, etc.). DeepSeek-R1 a démontré la puissance du FP8 et avec Unsloth, Qwen3-1.7B FP8 GRPO fonctionne maintenant simplement sur **5 Go de VRAM**.
Une inférence RL plus rapide est critique car c'est la charge de calcul la plus intensive en RL. Nous avons collaboré avec [TorchAO](https://github.com/pytorch/ao) de PyTorch pour permettre des gains de performance sans perte de précision.
* **≈1,4× plus rapide** inférence RL via [vLLM](https://github.com/vllm-project/vllm) • contexte 2x plus long vs. BF16 et FP16
* **60% de VRAM en moins** et **10× plus long** contexte que d'autres implémentations FP8 RL
* Unsloth est le **seul framework** à faire fonctionner FP8 RL LoRA sur les GPU grand public (p. ex. NVIDIA GeForce RTX 40 et 50 Series). Fonctionne aussi sur H100, H200, B200, etc.
* Utilisez `load_in_fp8 = True` dans `FastLanguageModel` pour activer FP8 RL.
* Bien que Qwen3-8B tienne dans 16 Go de VRAM, les GPU NVIDIA Tesla T4 gratuits de Colab **ne prennent pas en charge FP8**. Donc nos notebooks utilisent **des GPU L4 de 24 Go qui contiennent Qwen3-14B**.
**Notebooks :** [Qwen3-8B FP8 GRPO](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_8B_FP8_GRPO.ipynb) et [Llama-3.2-1B FP8 GRPO](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Llama_FP8_GRPO.ipynb)
{% hint style="success" %}
Bonus : Vous remarquerez qu'Unsloth utilise maintenant beaucoup moins de VRAM. Nous partagerons les détails dans un nouveau blog bientôt.
{% endhint %}
Notre support FP8 utilise la [fonctionnalité de partage de poids](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md), réduisant l'utilisation de la VRAM de **50%**, permettant **10× plus de** contexte sans perte de précision. Nous utilisons [vLLM](https://github.com/vllm-project/vllm) pour une inférence rapide et, nos techniques comme Unsloth [Standby](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md) et [et notre fonctionnalité Standby dans](/docs/fr/modeles/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) pour réduire encore l'utilisation de la VRAM. TorchAO permet le FP8 universel à la volée, donc Llama, Gemma, Mistral et d'autres fonctionnent. Nous avons aussi [téléversé](#unsloth-fp8-uploads) la plupart des modèles FP8 (y compris Qwen3).
Le graphique de récompense montre que FP8 suit la même tendance que BF16
### :sunflower:FP8 vs BF16 Entraînement
La recherche montre que l'entraînement en FP8 peut en grande partie égaler la précision du BF16 et si vous servez des modèles en FP8, **entraîner et servir dans la même précision** aide à préserver la précision. De plus, FP8 vs BF16 offre un débit 1,6× supérieur sur les H100 et utilise 2× moins de mémoire.
#### Échelles de poids et types FP8
L'entraînement quantifié stocke un poids en basse précision (par ex., FP8) plus une échelle en haute précision (FP16/BF16/FP32). Vous récupérez approximativement le poids original via : `original_weight ≈ quantized_weight * weight_scale`
L'échelle mappe la plage du poids à la plage représentable par le FP8. Plus d'échelles améliorent généralement la précision, mais les échelles coûtent de la mémoire en haute précision, donc c'est un compromis. [DeepSeek R1](https://arxiv.org/abs/2501.12948), par exemple, favorise principalement la quantification par bloc.
Il existe 3 types FP8 courants tels que définis par [llm-compressor](https://github.com/vllm-project/llm-compressor). Nous avons benchmarké Qwen3-8B sur les 3 types, et avons aussi vérifié le débit, MMLU Pro et GQPA Diamond. Nous trouvons que **FP8 bloc-wise ou par canal (-FP8-Dynamic) est le meilleur** en termes de précision et de débit.
Type
Débit
MMLU Pro
GQPA Diamond
Baseline Bfloat16
11,367
62.04%
28.79%
Bloc-wise
Échelles par bloc (128X128)
12,041
62.37%
29.29%
Par canal
1 échelle par ligne ou colonne
12,963
61.89%
31.82%
Par tenseur
1 échelle pour tout le tenseur
13,681
61.83%
27.78%
### :zap:Benchmarks de performance FP8
L'inférence RL Unsloth FP8 via vLLM est généralement 1,4x plus rapide que BF16. Vous pouvez observer encore plus d'améliorations de vitesse si le modèle est plus grand !
#### Précision Benchmarks de perte d'entraînement
Nous avons testé plusieurs modèles incluant Qwen3-4B, 8B, 14B, Llama 3.2 1B, 3B, Qwen3-VL-2B, Qwen3-VL 4B et bien d'autres. Tous ont été entraînés à la fois en BF16 et FP8. Comme vu dans les graphiques, les **courbes de perte pendant le SFT pour BF16 et FP8 se suivent de près**. Il n'y a pas grand-chose à choisir entre les deux types de données en termes de perte d'entraînement :
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
Pour GRPO spécifiquement, en raison des différences de génération, le but est de voir si les graphiques de récompense au moins correspondent et ne divergent pas (parfois, par ex. les runs Qwen3-14B peuvent ne pas être exactement similaires)
{% columns %}
{% column width="50%" %}
{% endcolumn %}
{% column width="50%" %}
{% endcolumn %}
{% endcolumns %}
### :shinto\_shrine:L'inférence = 96% de l'entraînement RL
En RL, nous devons appeler le LLM / VLM pour générer quelques solutions candidates pour une exécution, puis nous notons chaque solution possible et **récompenser les bonnes solutions, et pénaliser les mauvaises réponses**. Pour atteindre une efficacité maximale, nous devons rendre l'inférence presque 100% du run d'entraînement. Dans Unsloth, nous **avons réussi à faire en sorte que l'entraînement ne prenne que <4% de l'ensemble du run RL, 96% étant purement de l'inférence vLLM.**
Par exemple pour Qwen-3-8B, qui est 1,15x plus rapide sur des longueurs de séquence plus courtes, vLLM FP8 lui-même pour l'inférence (sans entraînement) a aussi un débit 1,15x plus rapide. Nous voyons notre run RL dans Unsloth obtenir aussi 1,15x plus rapide sur les tokens traités, montrant à quel point **le surcoût d'entraînement est négligeable dans Unsloth.**
### :1234:60% moins d'utilisation mémoire
En théorie, vous vous attendriez à ce que les économies de mémoire soient à peu près **égales à la mémoire des poids du modèle**, parce que : les états de l'optimiseur sont toujours stockés en haute précision et les activations sont aussi stockées en haute précision (pour l'instant). Nos constats correspondent à la théorie. Pour le fine-tuning LoRA, nous avons observé : **≈30 Go économisés** pour **Qwen3-32B, ≈14 Go économisés** pour **Qwen2.5-14B** et **≈8 Go économisés** pour **Qwen3-8B**
Pour **Fine-tuning LoRA BF16 sur** Qwen3-32B, nous faisions des OOM à des tailles de batch plus élevées et avons dû réduire la taille du batch. Le **variant FP8 n'a pas eu de tels problèmes**, et nous pouvions utiliser **des tailles de batch plus grandes** sans OOM.
Aussi rappel : dans Unsloth nous partageons l'espace mémoire de vLLM pour les poids comme introduit dans [RL économe en mémoire](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md) — nous avons apporté cette astuce au domaine FP8 !
| GPU 80 Go | Moteur d'inférence | Moteur d'entraînement |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | --------------------------------------------- |
| Poids du modèle | **8Go PARTAGÉS FP8** | **<<< PARTAGÉ** |
|
Polyvalent
Espace de 72 Go
| Cache KV | Activations, gradients, états de l'optimiseur |
Pour permettre la [Unsloth Standby](/docs/fr/commencer/reinforcement-learning-rl-guide/memory-efficient-rl.md) pour le RL en FP8 (ou BF16), ajoutez simplement ce qui suit à tous les runs d'entraînement RL / GRPO avant tout import Unsloth :
```python
import os
os.environ["UNSLOTH_VLLM_STANDBY"] = "1"
```
### :question:Comment utiliser FP8 RL / installation
Mettez simplement à jour Unsloth ou installez Unsloth dans un nouvel environnement virtuel pour H100, L4, RTX 50x, RTX 40x, H200s, B200s, et tout GPU NVIDIA (grand public ou datacenter) sorti après le RTX 4090.
Pour mettre à jour Unsloth : `pip install --upgrade --force-reinstall --no-cache-dir --no-deps unsloth unsloth_zoo`Ou créez un nouvel environnement :
{% code overflow="wrap" %}
```bash
python -m venv unsloth_env
source unsloth_env/bin/activate
pip install unsloth vllm
pip install --pre torchao --index-url https://download.pytorch.org/whl/nightly/cu128 --force-reinstall
pip install --pre fbgemm-gpu fbgemm-gpu-genai --index-url https://download.pytorch.org/whl/cu128 --force-reinstall
pip install --upgrade numba numpy
```
{% endcode %}
Puis utilisez `load_in_fp8 = True` et c'est parti ! Nous mapperons automatiquement le nom du modèle à la variante Float8, ou nous convertirons le modèle en Float8 à la volée !
import os
os.environ['UNSLOTH_VLLM_STANDBY'] = "1" # Unsloth standby économise 30%+ de mémoire pour le RL
from unsloth import FastLanguageModel
import torch
max_seq_length = 2048 # Peut être augmenté pour des traces de raisonnement plus longues
lora_rank = 32 # Rang plus grand = plus intelligent, mais plus lent
model, tokenizer = FastLanguageModel.from_pretrained(
model_name = "unsloth/Qwen3-8B",
max_seq_length = max_seq_length,
load_in_4bit = False, # False pour LoRA 16bit
fast_inference = True, # Activer l'inférence rapide vLLM
max_lora_rank = lora_rank,
load_in_fp8 = True, # Float8 RL / GRPO !
)
Par exemple sur une RTX 5090 (rappel de définir `os.environ["UNSLOTH_VLLM_STANDBY"] = "1"` )
Ensuite, utilisez nos 2 notebooks FP8 pour le RL :
{% columns %}
{% column %}
**Qwen3-8B FP8 RL Colab**
{% embed url="" %}
{% endcolumn %}
{% column %}
**Llama-3.2-1B-FP8 RL Colab**
{% embed url="" %}
{% endcolumn %}
{% endcolumns %}
### :cd:Implémentation de l'entraînement FP8
Notre premier point de référence était `transformers`, qui prend déjà en charge le FP8 de plusieurs manières. L'une d'elles est une implémentation matmul quantifiée par bloc : lorsqu'une couche reçoit des activations 16 bits, elle les quantifie et les passe à un noyau matmul FP8 personnalisé. Après avoir connecté cela et benchmarké sur une NVIDIA H100, nous avons vu le contraire de ce que nous voulions : le fine-tuning est devenu environ **4× plus lent** que le fine-tuning standard en BF16.
### 🔥Collab TorchAO
Nous avons donc travaillé avec l'équipe [TorchAO](https://github.com/pytorch/ao) (énormes remerciements à[ Andrew](https://github.com/unslothai/unsloth/pull/3440)) pour incorporer le support FP8 de TorchAO dans nos charges RL et avons observé environ **1,4× de débit plus élevé** et jusqu'à **60% d'utilisation mémoire du modèle en moins**. À un niveau élevé :
* Nous stockons les poids LoRA gelés en FP8.
* Pendant la passe avant, nous appliquons une quantification FP8 dynamique aux activations d'entrée, tout en gardant les adaptateurs LoRA entraînables en BF16.
* Ces poids FP8 partagent les mêmes buffers que les poids du modèle vLLM, donc il n'y a qu'une seule copie FP8 du modèle en mémoire à tout moment (pas de surcharge mémoire de « double modèle »).
* Dans la passe arrière, nous déquantifions les poids LoRA afin que tout le calcul des gradients soit effectué en BF16 pour une meilleure précision.
Cette configuration générale fonctionne pour tous les algorithmes RL supportés, y compris [GSPO](/docs/fr/commencer/reinforcement-learning-rl-guide/advanced-rl-documentation/gspo-reinforcement-learning.md), Dr. GRPO, PPO et DPO.
TorchAO fournit un support FP8 natif PyTorch pour l'entraînement et l'inférence, offrant une variété de granularités d'échelle incluant tensorwise, row-wise et blockwise 128x128 (prototype). Le support FP8 de TorchAO peut améliorer le débit d'inférence jusqu'à [1,64x à l'échelle 27B](https://huggingface.co/pytorch/gemma-3-27b-it-FP8/blob/main/README.md#results-h100-machine) avec granularité d'échelle par ligne. Pour plus de détails, visitez le [README FP8](https://github.com/pytorch/ao/blob/main/torchao/float8/README.md).
#### Matmul FP8 quantifié par bloc de TorchAO
Nous avons utilisé l'implémentation matmul FP8 quantifiée par bloc de TorchAO qui a fourni :
* **80% du débit BF16**
* Sans dégrader la perte ni la stabilité d'entraînement
Donc pendant un certain temps, cela est devenu notre backend matmul FP8 par défaut, jusqu'à ce que FBGEMM rattrape son retard — nous utilisons désormais par défaut l'implémentation de FBGEMM, si votre GPU la supporte ! La version actuelle d'Unsloth peut choisir automatiquement le meilleur backend en fonction de ce qui est installé. Si vous avez les bons paquets, vous n'avez pas à laisser de performance sur la table 🙂
PS : Nous avons également expérimenté DeepGEMM de DeepSeek, mais n'avons pas pu l'intégrer complètement de bout en bout pour obtenir des comparaisons propres et équitables.
### :bird:Quantification FP8 à la volée TorchAO
Un immense merci à [Andrew](https://github.com/unslothai/unsloth/pull/3440) de TorchAO, Unsloth FP8 RL vous permet aussi de quantifier le modèle à la volée en effectuant la quantification lors du chargement du modèle et en la transmettant ensuite à vLLM. De cette façon, vous n'avez pas besoin de quantifier explicitement le modèle vous-même (nous nous en chargeons). Vous pouvez le faire en définissant `load_in_fp8 = True` dans les arguments de chargement du modèle, et nous ferons du FP8 hors ligne si nous ne trouvons pas de checkpoint pré-quantifié approprié.
```python
from unsloth import FastLanguageModel
fp8_model = FastLanguageModel.from_pretrained(
"unsloth/Llama-3.3-70B-Instruct", # Peut être n'importe quel nom de modèle !
load_in_fp8 = True, # Peut être "block" pour FP8 par bloc, True pour FP8 par ligne, False
)
```
### :tada:Téléversements FP8 Unsloth
Pour plus de commodité, nous avons téléversé des modèles FP8 Dynamic et FP8 Block sur Hugging Face. Vous pouvez les utiliser pour l'entraînement FP8 ou aussi pour le service/déploiement efficace et rapide via [vLLM](/docs/fr/bases/inference-and-deployment/vllm-guide.md)/[SGLang](/docs/fr/bases/inference-and-deployment/sglang-guide.md) etc.
FP8 Dynamic offre un entraînement légèrement plus rapide et une utilisation de VRAM inférieure à FP8 Block, mais avec un petit compromis sur la précision. [Voir ici](/docs/fr/commencer/unsloth-model-catalog.md#fp8) pour notre liste complète de quantifications FP8, mais voici les plus populaires :
| Modèle | Téléversements FP8 |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Qwen3 (2507)** |
|
### :person\_tipping\_hand:Remerciements
Un énorme merci à l'ensemble des équipes PyTorch et TorchAO pour leur aide et collaboration ! Un grand merci en particulier à : Andrew Or, Jerry Zhang, Supriya Rao, Scott Roy et Mergen Nachin pour leur aide lors de nombreuses discussions sur le FP8 RL, et pour l'intégration dans Unsloth ! Merci également à l'équipe Executorch !
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://unsloth.ai/docs/fr/commencer/reinforcement-learning-rl-guide/fp8-reinforcement-learning.md?ask=
```
The question should be specific, self-contained, and written in natural language.
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.