Hugging Face hat am 3. September ein vollständiges Trainingsprotokoll veröffentlicht: Ein Modell, das eigentlich Code schreibt, wird darauf trainiert, Aquarelle zu malen. In der gesamten Pipeline steckt kein Diffusionsmodell und keine Bildgenerierungs-Komponente. Das Modell gibt ein Stück JavaScript aus, das die Pinsel-Bibliothek p5.brush aufruft; wird es ausgeführt, entsteht auf der Leinwand ein Aquarell.
Autor ist Sergio Paniego, die ursprüngliche Idee stammt von Surya Narreddi. Als Basismodell dient Qwen3.5-35B-A3B, trainiert mit dem GRPO aus TRL, LoRA auf allen linearen Schichten, einer Lernrate von 5e-5 und einem constant_with_warmup-Scheduler. Codeausführung, Rendering und Punktevergabe laufen gekapselt in einer OpenEnv-Umgebung: Das Modell erzeugt Code, die Umgebung führt ihn aus, macht einen Screenshot und übergibt ihn an das Bewertungssystem.
Im Reward gibt es kein Richtig oder Falsch, nur einen Referenzpool
Die Szenarien, in denen Reinforcement Learning bei großen Modellen in den letzten zwei Jahren gut funktioniert hat, haben fast alle eines gemeinsam: ein automatisches Richtig-Falsch-Kriterium – eine Musterlösung bei Mathe, Unit-Tests bei Code. Bei einem Aquarell gibt es so etwas nicht. Die Lösung in diesem Protokoll zerlegt „wie schön ist es" in zwei Signale, die sich bewerten lassen.
Die Reward-Funktion besteht aus vier Teilen. Ob der Code fehlerfrei läuft, macht 0,05 aus, die Codelänge weitere 0,05, die restlichen neunzig Prozent verteilen sich auf zwei ästhetische Signale: ein Richter-Modell, das paarweise Vergleiche anstellt, und einen Human-Preference-Scorer namens HPSv3. Die Gewichtung der beiden wechselt je nach Experiment: In der Gruppe „judge-led" wiegt der Richter 0,60 und HPSv3 0,30, in der Gruppe „hps-led" ist es umgekehrt.
Der Maßstab des Richters stammt aus einem handbewerteten Referenzpool von insgesamt 178 Bildern. Jedes vom Modell erzeugte Bild wird mit einem Werk aus diesem Pool verglichen. Derselbe Pool legt auch fest, was als „vielfältig" gilt – im Blogbeitrag heißt es wörtlich: „The pool decides what counts as variety, the same way it decides what counts as quality". Diese 178 Bilder stecken faktisch die Obergrenze für das gesamte Trainingsziel ab.
Drei Durchläufe, drei Kurven
Der Autor führte drei Vergleichsexperimente durch. Die nur mit HPSv3 bewertete Gruppe lief 60 Schritte, die durchschnittliche Reward stieg von 0,58 auf 0,71; die judge-led-Gruppe lief 110 Schritte, von 0,45 auf 0,72; die hps-led-Gruppe, ebenfalls 110 Schritte, stieg von 0,57 auf 0,82 – Start- und Endwert waren hier von allen dreien am höchsten.
Den größten Zuwachs verzeichnete die judge-led-Gruppe mit +0,27, startete aber auch am niedrigsten. Die hps-led-Gruppe legte 0,24 zu, endete aber bei 0,82: den Human-Preference-Scorer in die Hauptrolle zu setzen und das Richter-Modell nur ergänzend einzusetzen, erwies sich als stabiler als umgekehrt. Die Gruppe, die nur den Scorer nutzt, ohne Richter, legte lediglich 0,13 zu – der kleinste Zuwachs der drei. Die Ebene des paarweisen Vergleichs liefert also tatsächlich ein zusätzliches Signal und ist kein verzichtbares Beiwerk.
Eine GPU, 34 Stunden, gut hundert Dollar
Beim Hardware-Kapitel bleibt es simpel. Durchgehend eine einzige H200: 18 Stunden für 60 Schritte, 34 Stunden für 110 Schritte. Das Rendering lief auf einem Space mit CPU-Spezifikation, der HPSv3-Scorer auf einem Space mit a100-large.
Beim aktuellen Cloud-Preis der H200 von 3 bis 4 Dollar pro Stunde liegt ein vollständiges Training über 110 Schritte grob zwischen 100 und 140 Dollar; zusammen mit dem Aufwand für Scorer und Rendering bewegt sich die gesamte Rechenrechnung des Projekts im Bereich weniger hundert Dollar. Für ein Team, das lediglich prüfen will, ob ästhetische Präferenzen als Reward taugen, ist die Einstiegshürde niedrig genug, um es einfach mal auszuprobieren.
Was offengelegt wurde, ist recht vollständig: Trainingsrezept und Skripte liegen auf GitHub, dazu der Datensatz mit den 178 Referenzbildern, ein direkt duplizierbarer Space der RL-Umgebung, der Space des HPSv3-Scorers, drei LoRA-Adapter samt ihrer jeweiligen Rollout-Datensätze sowie eine Galerie, in der sich alle generierten Ergebnisse durchblättern lassen. Wer es nachbauen will, muss keine eigene Umgebung aufsetzen – einfach den Space duplizieren, die Reward-Gewichte anpassen und loslegen.
Denkt man den Ansatz weiter, gibt es einige Einsatzfelder. Wie ein UI-Element wirkt, wie dicht ein Poster-Layout gesetzt ist, ob die Farben eines Diagramms passen – solche Aufgaben, bei denen richtig und falsch nicht klar sind, ein Mensch aber auf einen Blick den Unterschied erkennt, ließen sich bisher kaum in eine RL-Reward-Funktion übersetzen. Der jetzige Weg: zunächst einen Referenzpool mit ein paar hundert Beispielen zusammenstellen, einen ausreichend guten Preference-Scorer finden, den Rest dem GRPO überlassen. Der Knackpunkt bleibt der Referenzpool – ist er verzerrt, wird auch das Modell verzerrt, und zwar sehr konsequent.
Quellen: offizieller Hugging-Face-Blog, Dokumentation der Projekte TRL und OpenEnv, CocoLoop; Schrittzahl, Reward-Spanne und GPU-Laufzeit der drei Experimente wurden Punkt für Punkt anhand des im Blog veröffentlichten Trainingsprotokolls geprüft, die Rechenkosten sind eine grobe Schätzung auf Basis öffentlicher Listenpreise.