Le 3 septembre, Hugging Face a publié un compte rendu complet d'entraînement : partir d'un modèle conçu pour écrire du code et lui apprendre à peindre à l'aquarelle. Toute la chaîne se passe de modèle de diffusion et de tout composant de génération d'image. Le modèle produit un script JavaScript qui appelle la bibliothèque de pinceaux p5.brush ; une fois exécuté, il laisse une aquarelle sur la toile.
L'auteur du projet est Sergio Paniego, l'idée initiale venant de Surya Narreddi. Le modèle de base retenu est Qwen3.5-35B-A3B, entraîné avec le GRPO de TRL, un LoRA branché sur toutes les couches linéaires, un taux d'apprentissage de 5e-5 et un planificateur constant_with_warmup. L'exécution du code, le rendu et le calcul du score sont encapsulés dans un environnement OpenEnv : le modèle génère le code, l'environnement l'exécute, prend une capture d'écran, puis la transmet au système de notation.
Dans la récompense, pas de bien ou de mal, seulement une réserve de références
Ces deux dernières années, les scénarios où l'apprentissage par renforcement fonctionne bien sur les grands modèles ont presque tous un point commun : un critère automatique de vrai ou faux — une réponse type pour les mathématiques, des tests unitaires pour le code. Une aquarelle n'a rien de tel. La solution retenue dans ce compte rendu consiste à décomposer « est-ce beau » en deux signaux mesurables.
La fonction de récompense comporte quatre éléments. Le fait que le code s'exécute correctement compte pour 0,05, sa longueur pour 0,05, et les neuf dixièmes restants se répartissent entre deux signaux esthétiques : un modèle-juge qui fait des comparaisons par paires, et un système de notation des préférences humaines nommé HPSv3. Le poids de ces deux éléments varie selon les expériences : dans le groupe « judge-led », le juge pèse 0,60 et HPSv3 0,30 ; dans le groupe « hps-led », c'est l'inverse.
Le critère du juge provient d'une réserve de références notées à la main, 178 images au total. Chaque image générée par le modèle est comparée à une œuvre piochée dans cette réserve. Cette réserve définit aussi ce qui compte comme « varié » — selon les mots mêmes du billet de blog, « The pool decides what counts as variety, the same way it decides what counts as quality ». Ces 178 images fixent en réalité le plafond de tout l'objectif d'entraînement.
Trois essais, trois courbes
L'auteur a mené trois expériences comparatives. Le groupe noté uniquement par HPSv3 a tourné 60 étapes, la récompense moyenne passant de 0,58 à 0,71 ; le groupe judge-led a tourné 110 étapes, de 0,45 à 0,72 ; le groupe hps-led, également 110 étapes, est passé de 0,57 à 0,82 — le point de départ et d'arrivée les plus hauts des trois.
La plus forte progression revient au groupe judge-led, avec +0,27, mais il partait aussi du plus bas. Le groupe hps-led progresse de 0,24 mais termine à 0,82 : placer le système de préférences humaines au premier plan et le modèle-juge en soutien s'avère plus stable que l'inverse. Le groupe qui n'utilise que le système de notation, sans juge, ne progresse que de 0,13 — la plus faible des trois. La couche de comparaison par paires apporte donc bien un signal supplémentaire, ce n'est pas un simple ornement.
Un seul GPU, 34 heures, une centaine de dollars
Côté matériel, c'est sobre. Un seul H200 du début à la fin : 18 heures pour 60 étapes, 34 heures pour 110 étapes. Le rendu tourne sur un Space au gabarit CPU, le système de notation HPSv3 sur un Space en a100-large.
Au tarif actuel du H200 dans le cloud, entre 3 et 4 dollars de l'heure, un entraînement complet de 110 étapes se situe entre 100 et 140 dollars ; en ajoutant le coût du système de notation et du rendu, la facture de calcul totale du projet tourne autour de quelques centaines de dollars. Pour une équipe qui veut simplement vérifier si une préférence esthétique peut servir de récompense, le seuil d'entrée est assez bas pour être testé sans hésiter.
Le matériel mis en open source est plutôt complet : la recette d'entraînement et les scripts sont sur GitHub, ainsi que le jeu de données des 178 images de référence, un Space d'environnement RL directement duplicable, le Space du système de notation HPSv3, trois adaptateurs LoRA avec leurs jeux de données de rollout respectifs, et une galerie permettant de parcourir tous les résultats générés. Quiconque veut reproduire l'expérience n'a pas besoin de construire son propre environnement : il suffit de dupliquer le Space et d'ajuster les poids de récompense pour démarrer.
Dans cette direction, les usages possibles ne manquent pas. Le rendu d'un composant d'interface, la densité d'une mise en page d'affiche, la pertinence des couleurs d'un graphique : autant de tâches où le bien et le mal ne sont pas tranchés, mais où un humain distingue le meilleur du pire d'un coup d'œil — et qui étaient jusqu'ici difficiles à traduire en fonction de récompense pour le RL. La méthode consiste désormais à constituer d'abord une réserve de référence de quelques centaines d'éléments, à trouver un système de notation des préférences suffisamment fiable, puis à laisser le GRPO faire le reste. Le point délicat reste la réserve de référence : si elle est biaisée, le modèle le devient aussi, et de façon très cohérente.
Sources : blog officiel de Hugging Face, documentation des projets TRL et OpenEnv, CocoLoop ; le nombre d'étapes, la plage de récompense et la durée par GPU des trois expériences ont été vérifiés point par point d'après le compte rendu d'entraînement du blog, le coût de calcul est une estimation basée sur les tarifs publics.