SDPO : apprendre d'un retour d'environnement en texte plutôt que d'un score

Le goulot d'étranglement que SDPO attaque

L'apprentissage par renforcement avec récompense vérifiable réduit chaque tentative à un score scalaire. Le modèle apprend qu'une réponse est bonne ou mauvaise, sans savoir pourquoi. Or un environnement de code renvoie une trace d'exécution, un juge renvoie une évaluation rédigée : ces textes expliquent l'échec et restent inutilisés. Le README formalise ce cadre sous le nom de Reinforcement Learning with Rich Feedback (RLRF). SDPO s'adresse donc aux équipes qui post-entraînent des modèles sur des tâches vérifiables (mathématiques, code) et qui disposent déjà de retours textuels. Si votre environnement ne renvoie qu'un booléen, la moitié de la méthode perd son intérêt, même si le dépôt prévoit un mode dégradé décrit plus bas.

Le modèle devient son propre enseignant

Le mécanisme central tient en une phrase du README : SDPO traite le modèle courant conditionné sur le retour comme un enseignant, et distille ses prédictions du token suivant, informées par ce retour, dans la politique. Concrètement, la politique conditionnée sur le feedback sert de self-teacher, et la politique sans feedback apprend à reproduire ses distributions. Aucun modèle enseignant externe n'intervient, aucun reward model n'est entraîné. Le README décrit cela comme la capacité du modèle à identifier rétrospectivement ses erreurs en contexte. Le crédit est attribué plus finement que dans un schéma par séquence : la documentation présente une hiérarchie logit, puis token, puis séquence. Un point mérite d'être signalé : l'enseignant et l'élève partagent les mêmes poids au départ, et le README indique que l'élève final dépasse sensiblement l'enseignant initial. C'est une affirmation issue des courbes du papier, pas une garantie universelle.

Quand le retour d'environnement manque

Le dépôt ne se limite pas aux environnements bavards. Une section entière traite du cas où le retour est rare ou fondé sur des règles. SDPO réutilise alors les trajectoires à haute récompense comme feedback implicite, ce qui fournit une supervision dense malgré l'absence de texte explicatif. Le README donne l'exemple d'Olmo3-7B-Instruct sur un jeu de chimie, avec une précision moyenne sur 16 échantillons et une moyenne glissante de la longueur des réponses sur 5 pas. La comparaison annoncée porte sur GRPO avec ses hyperparamètres optimaux pour ce modèle et cette tâche, trois graines, erreurs standard en zones ombrées. Deux réserves : ces chiffres proviennent de la documentation du projet, et l'article n'a pas reproduit les expériences. Le protocole indiqué (une étape de gradient par lot de génération pour SDPO et GRPO, quatre mini-lots hors politique pour GRPO) compte autant que les courbes, car il change le coût par pas.

Installation : deux chemins, un seul confortable

La voie Docker est présentée comme recommandée pour les clusters HPC et GH200. Le README donne les commandes : podman build . -f Dockerfile.gh200 -t sdpo-gh200, puis enroot import -x mount -o sdpo-gh200.sqsh podman://localhost/sdpo-gh200:latest. L'image s'appuie sur le conteneur NGC vLLM et sur requirements-gh200.txt, qui reprend les versions figées de requirements-full.txt en excluant ce que NGC fournit déjà : torch, vllm, flash-attn, xformers, triton. L'installation locale demande d'abord PyTorch, avec deux variantes : torch==2.5.1 et l'index cu124 pour Ampere et Hopper, torch==2.7.0 et l'index cu128 pour Blackwell. Vient ensuite l'installation de SDPO et de ses dépendances. Le README est tronqué à cet endroit : la commande exacte d'installation du paquet n'apparaît pas dans le matériel fourni, et je ne peux pas la reconstituer. Les prérequis annoncés sont Linux (testé sur SLES 15 SP5 et Ubuntu 22.04), Python 3.12 (testé sur 3.12.3) et des GPU NVIDIA compatibles CUDA.

Le coût matériel n'est pas négociable

Les expériences rapportées tournent sur un nœud à 4 GPU NVIDIA GH200, avec environ 6 heures par exécution, initialisation et validation comprises. Le tableau de résultats compare les meilleures performances atteintes en 1 heure et en 5 heures de temps mural. Autrement dit, le projet est conçu pour du multi-GPU, et l'image Docker cible explicitement l'architecture aarch64 de GH200. Sur une carte unique, ou sur une architecture différente, rien dans le matériel fourni n'indique que l'entraînement tienne. C'est la limitation la plus concrète du dépôt : la barrière d'entrée est matérielle, pas logicielle. À cela s'ajoute une dépendance à la qualité du retour : un feedback bruité ou trompeur sera distillé tel quel, puisque le modèle enseignant est le même modèle. Le README ne décrit pas de garde-fou contre ce cas.

Auto-distillation au moment de l'inférence

SDPO propose aussi une variante sans entraînement supplémentaire. Le modèle génère plusieurs solutions candidates, identifie les meilleures réponses, et les réutilise comme démonstrations pour affiner ses sorties à l'inférence. Le README annonce des gains sur des problèmes de code difficiles, y compris des questions que ni le modèle de base ni une interaction multi-tours ne résolvent, avec un taux de découverte supérieur selon le budget de génération. Le coût se déplace : pas de gradient, mais plusieurs générations par question. Cette variante est la plus accessible du dépôt, puisqu'elle ne demande pas le nœud à 4 GPU. Elle reste tributaire d'un mécanisme de sélection des bonnes réponses, que le matériel fourni ne détaille pas.

GRPO et la différence de granularité

Le comparatif principal du README est GRPO. La différence n'est pas une question de vitesse mais de niveau d'attribution : GRPO apprend d'une récompense scalaire par tentative, SDPO apprend d'une distribution de tokens conditionnée sur le retour. Quand le retour est riche, SDPO en tire un signal plus dense et converge plus vite selon les courbes du projet. Quand le retour est pauvre, SDPO se rabat sur les trajectoires gagnantes comme feedback implicite, et le README revendique malgré tout un avantage sur GRPO. Cette seconde affirmation est la plus discutable : sans texte explicatif, la méthode se rapproche d'une distillation sur ses propres succès, une famille d'approches déjà connue. Le lecteur qui hésite entre les deux doit surtout regarder son environnement. Si celui-ci produit des traces d'exécution ou des évaluations rédigées, l'écart de conception est réel. Sinon, l'argument se réduit à un réglage d'hyperparamètres.

Maintenance, licence et ce qu'il reste à vérifier

Le dépôt est sous licence Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Ce n'est pas un avis juridique : faites relire le fichier LICENSE et vérifiez les licences des dépendances, notamment celles des composants NGC et de vLLM, qui ne sont pas couvertes par Apache-2.0. Le dépôt n'est pas archivé et la dernière poussée date du 1er juillet 2026, mais aucune release n'a été récupérée. Il n'existe donc pas de version étiquetée sur laquelle s'appuyer : vous suivrez la branche main. Le papier est référencé sous arXiv:2601.20802 et les journaux d'entraînement sont publiés sur Weights & Biases, ce qui donne un point de comparaison avant de lancer vos propres exécutions. Le README ne documente pas de procédure de mise à jour ni de compatibilité ascendante, et la commande d'installation locale est absente du matériel fourni. Ce sont les deux premiers points à clarifier avant de bâtir un pipeline dessus.

Conclusion éditoriale

SDPO vise les équipes qui entraînent déjà des modèles de raisonnement sur des nœuds GPU multi-cartes et disposent d'environnements produisant du texte exploitable. Ce n'est pas un outil pour une seule carte ou pour un retour purement scalaire. Avant d'investir, vérifiez que requirements-full.txt s'installe avec votre version de PyTorch, que le Dockerfile.gh200 correspond à votre architecture, et que vos environnements fournissent bien un retour textuel et non un simple booléen.

Sources officielles

1. Issues
2. lasgroup/SDPO on GitHub
3. License: Apache-2.0
4. Project website
5. README