Les avancées d'Open R1, ce projet qui veut reproduire les modèles DeepSeek

Et si on recréait un DeepSeek-R1, mais totalement ouvert ?

Fin janvier, Hugging Face avait impulsé un tel projet : Open R1. En ligne de mire, deux "pièces manquantes", non publiées par DeepSeek : les datasets et le code d'entraînement. D'où un plan décliné en trois temps :

• Être capable de distiller un ensemble de données de raisonnement de haute qualité à partir de DeepSeek-R1
• Répliquer le pipeline d'apprentissage par renforcement de R1-Zero
• Appliquer cette combinaison à des modèles de base pour en faire des modèles de raisonnement

Pour rappel, R1 et R1-Zero découlent tous deux de DeepSeek-V3, un modèle de type MoE (Mixture of Experts) à 671 milliards de paramètres.
R1-Zero a été formé uniquement grâce à de l'apprentissage par renforcement. Il a développé des aptitudes au raisonnement, mais ses réponses manquent souvent de clarté et de lisibilité.
Pour résoudre ce problème, DeepSeek a intégré une forme de "démarrage à froid" : du fine-tuning sur un petit ensemble d'exemples. Il a ensuite poursuivi l'apprentissage par renforcement tout en incluant, entre autres, du rejet d'échantillons, y compris sur la base de la préférence humaine. Il en a résulté R1.

DeepSeek et ses modèles verbeux

Hugging Face a d'abord vérifié qu'il était capable de reproduire, avec son toolkit lighteval, les scores d'évaluation communiqués par DeepSeek sur plusieurs modèles distillés à partir de R1. Dans ce cadre, un leaderboard fut créé. Et diverses observations furent faites. Notamment quant à la verbosité des LLM en question. Sur le dataset OpenThoughts, certaines réponses dépassaient 20 000 tokens (moyenne : 6000). Une longueur susceptible de complexifier l'apprentissage par renforcement, de longues réponses exigeant d'autant plus de mémoire GPU pour stocker activations et gradients lors de l'étape d'optimisation.

La première expérimentation de génération de données de raisonnement s'est faite sur un noeud à 8 cartes H100. Le remplissage rapide du cache clé-valeur limitait le nombre de requêtes parallèles. Aussi le nombre de GPU a-t-il été quadruplé, tout en passant du batch au streaming pour stabiliser l'utilisation du CPU.

Un premier dataset pour le raisonnement mathématique

Pour distiller les capacités de raisonnement de R1 vers d'autres modèles, DeepSeek dit avoir utilisé 600 000 traces (chaînes de pensée). Il ne les a cependant pas publiées. La communauté a ainsi constitué des palliatifs, comme OpenThougts-114k, Dolphin-R1 ou LIMO. Le projet Open R1 a pour sa part commencé par un dataset axé sur le raisonnement mathématique. Hugging Face l'a généré sur un cluster local à 512 H100. Brut, il couvre 400 000 problèmes (2 traces pour chacun), tirés de NuminaMath-1.5. Filtré, il en englobe 220 000. La sélection s'est faite en associant un moteur de règles (Math Verify) et un modèle juge (Llama 3.3 70B Instruct).

Pour générer les données, Hugging Face a suivi les paramètres recommandés par DeepSeek et a intégré, au début de chaque prompt, une instruction appelant R1 à raisonner étape par étape. La limite d'output a été fixée à 16k, une analyse ayant montré que la plupart des problèmes étaient solvables en moins de 8k tokens. Le processus avait débuté avec vLLM, qui permettait de produire 15 générations par heure sur chaque H100. Il s'est poursuivi avec SGLang, qui a permis de monter à 25 générations. Le choix de produire plusieurs réponses par problème est censé favoriser le rejet d'échantillons comme les méthodes d'optimisation basées sur la préférence.

Le dataset obtenu (OpenR1-Math-220k) a été divisé en deux parties. L'une, dite "par défaut", regroupe 94 000 problèmes et engendre les meilleures performances. L'autre, dite "étendue", réunit 131 000 problèmes... et ne produit pas d'aussi bons résultats, probablement parce que les questions sont plus simples.

En faisant travailler Qwen-7B-Math-Instruct pour trois cucles sur la partie "par défaut", Hugging Face affirme être parvenu à égaler la performance de DeepSeek-Distill-Qwen-7B.

De CodeForces-CoTs à OlympicCoder

Les travaux se sont ensuite étendus au codage, avec la production d'un dataset basé sur les compétitions CodeForces. Au menu, environ 10 000 problèmes, dont 60 % accompagnés de l'explication de la solution correcte par les organisateurs. Sur cette base, Hugging Face a fait produire des chaînes de pensée à R1 (environ 100 000 exemples), aboutissant au dataset CodeForces-CoTs. Il a servi à affiner Qwen 2.5 Coder Instruct 7B et 32B. En ont découlé les modèles OlympicCoder. Mis à l'épreuve sur la dernière Olympiade internationale d'informatique, ils ont rivalisé avec des LLM à l'état de l'art (le 32B s'en sortant même mieux que R1 et o1-mini si on l'autorise à produire 50 propositions de solutions par problème).

De l'entraînement des modèles OlympicCoder se sont dégagées des tendances. Entre autres au sujet du sample packing. Cette méthode concatène les échantillons d'entraînement en des chunks de taille égale, éliminant le besoin de recourir à des tokens de padding. Elle apparaît contre-productive lorsqu'il s'agit de traiter les traces de R1 : vu leur longueur, elles se retrouvent coupées... quand la question et la réponse n'atterrissent pas dans des chunks différents.

Hugging Face a aussi constaté qu'inclure les explications des organisateurs n'améliorait pas nettement les résultats. Il a également conclu à la nécessité de forcer un prefill avec une balise dans le template de conversation du modèle final. C'est un moyen d'assurer la production constante de longues chaînes de pensée. Un comportement pas systématique sinon, notamment quand on envoie des requêtes qui sortent du domaine de spécialisation des modèles.

Illustration générée par IA