SDPO: Selbst-Distillation als Ersatz für den skalaren Reward
Reinforcement Learning via Self-Distillation (SDPO)
Auf einen Blick
- Was ist das?
- Self-Distilled Policy Optimization (SDPO) nutzt das eigene Modell als Lehrer, wenn Umgebungen nur eine Belohnungszahl liefern. Der Ansatz ist auf GH200-Hardware zugeschnitten, die Dokumentation deckt im gelieferten Ausschnitt aber nur den Installationsteil ab.
- Für wen ist es gedacht?
- SDPO ist für Gruppen interessant, die Reasoning-Modelle in verifizierbaren Domänen wie Mathematik oder Code nachtrainieren und dabei auf externes Lehrer-Modell oder Reward-Modell verzichten wollen, und die über NVIDIA-Hardware mit CUDA verfügen. Wer keine GPU-Cluster betreibt oder eine ausgereifte, breit dokumentierte Trainingsbibliothek mit stabiler API sucht, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 76 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: ein Skalar für eine ganze Antwort
Verifizierbares Reinforcement Learning für Sprachmodelle kennt heute meist genau ein Signal pro Versuch: richtig oder falsch. Der README beschreibt das als Credit-Assignment-Bottleneck. Ein Modell, das eine fehlerhafte Codezeile in einem ansonsten korrekten Lösungsweg produziert, bekommt dieselbe Rückmeldung wie eines, das komplett danebenliegt. Die Information, warum ein Versuch scheiterte, existiert oft bereits, etwa als Laufzeitfehler oder als Bewertung eines Judges, wird aber nicht in den Gradienten eingespeist. SDPO adressiert genau diese Lücke und richtet sich an Teams, die Reasoning-Modelle in Domänen mit überprüfbaren Antworten nachtrainieren, also Mathematik, Code und ähnliche Bereiche, in denen sich Korrektheit automatisch feststellen lässt.
Der Mechanismus: das Modell als eigener Lehrer
SDPO führt laut README kein externes Lehrer-Modell und kein explizites Reward-Modell ein. Stattdessen wird das aktuelle Modell mit dem Feedback im Kontext als Self-Teacher verwendet. Seine feedback-informierten Vorhersagen für das nächste Token werden in die Policy destilliert, also in das Modell, das gerade trainiert wird. Die Autoren formalisieren die Umgebung, in der neben der skalaren Belohnung auch Textfeedback vorliegt, als Reinforcement Learning with Rich Feedback (RLRF). Fehlt dieses reiche Feedback, greift der zweite Pfad: High-Reward-Rollouts werden als implizites Feedback wiederverwendet, sodass auch bei regelbasierten oder dünnen Umgebungen eine dichtere Aufsicht entsteht. Die Abbildungen im README deuten drei Granularitätsebenen an, Logit-, Token- und Sequenzebene, wobei die feinere Ebene laut Bildunterschrift zu besserer Credit-Zuweisung führt. Das ist eine Designentscheidung mit Kosten: Der Self-Teacher muss pro Schritt zusätzlich ausgewertet werden, was Rechenzeit und Speicher bindet.
Was die Ergebnisse im README belegen und was nicht
Die berichteten Zahlen stammen aus Läufen auf einem Knoten mit vier NVIDIA GH200 GPUs, jeweils etwa sechs Stunden inklusive Initialisierung und Validierung. Als Modell wird Olmo3-7B-Instruct genannt, als Vergleichsbasis GRPO mit für dieses Modell und diese Aufgabe optimierten Hyperparametern. Der README hält fest, dass SDPO und On-Policy-GRPO einen Gradientenschritt pro Generierungsbatch machen, während GRPO vier Off-Policy-Minischritte ausführt. Das ist ein wichtiger Unterschied in der Rechnung: Der Vergleich ist nicht allein ein Algorithmusvergleich, sondern auch ein Vergleich unterschiedlicher Schrittbudgets. Die Autoren berichten Standardfehler über drei Seeds, was die Aussagekraft erhöht. Alle Zahlen sind jedoch Eigenangaben der Projektgruppe, nicht unabhängig nachgestellt. Wer SDPO einschätzen will, sollte die verlinkten W&B-Logs als Primärquelle heranziehen, denn der README-Ausschnitt liefert keine Rohdaten und keine Auswerteskripte.
Installation: zwei Wege, ein klarer Hardware-Fokus
Der README nennt Linux als getestetes System (SLES 15 SP5 und Ubuntu 22.04), Python 3.12 und NVIDIA-GPUs. Für GH200-Cluster mit aarch64 und CUDA 13.1 gibt es ein Dockerfile namens Dockerfile.gh200, das auf dem NGC-vLLM-Container aufbaut. Die dokumentierten Befehle lauten: podman build . -f Dockerfile.gh200 -t sdpo-gh200, gefolgt von enroot import -x mount -o sdpo-gh200.sqsh podman://localhost/sdpo-gh200:latest. Diese Variante nutzt requirements-gh200.txt, das gepinnte Versionen aus requirements-full.txt enthält, ohne die im NGC-Container bereits vorhandenen Pakete torch, vllm, flash-attn, xformers und triton. Für lokale Installationen trennt der README nach Architektur: torch==2.5.1 mit dem cu124-Index für Ampere und Hopper, torch==2.7.0 mit cu128 für Blackwell. Der letzte Absatz des gelieferten Ausschnitts bricht mitten im Satz ab, daher lässt sich nicht sagen, welche weiteren Schritte folgen.
Wo SDPO das falsche Werkzeug ist
Die Einschränkungen ergeben sich direkt aus dem Aufbau. Erstens die Hardware: Alle dokumentierten Pfade setzen NVIDIA-GPUs mit passendem CUDA-Treiber voraus. Ohne Cluster oder mit AMD-Beschleunigern gibt es im gelieferten Material keinen Hinweis auf Unterstützung. Zweitens die Umgebung: Der Nutzen hängt davon ab, dass überprüfbare Belohnungen existieren. Für Aufgaben ohne automatisch prüfbare Korrektheit, etwa offene Textgenerierung oder subjektive Bewertungen, beschreibt der README keinen Anwendungsfall. Drittens die Reife: Es gibt keine abgerufenen Releases, die Versionsnummern der Abhängigkeiten sind gepinnt, und der Installationsabschnitt ist im vorliegenden Ausschnitt unvollständig. Wer eine Bibliothek mit langjähriger API-Stabilität und umfangreicher Community-Dokumentation braucht, findet hier ein Forschungsartefakt. Das ist kein Mangel des Ansatzes, aber ein praktischer Unterschied, der vor der Adoption zählt.
Alternative: GRPO ohne Self-Teacher
Der naheliegende Vergleich ist GRPO, das der README selbst als Baseline verwendet. Der Unterschied liegt nicht in der Belohnungsfunktion, sondern in der Quelle des Lernsignals. GRPO leitet seine Updates aus relativen Vorteilen innerhalb einer Gruppe von Antworten zu derselben Frage ab und bleibt damit auf der Ebene der Sequenz. SDPO setzt zusätzlich einen Self-Teacher ein, der das Feedback im Kontext sieht, und destilliert dessen Token-Vorhersagen in die Policy. Das verschiebt die Aufsicht von der Sequenz auf das Token, was laut README bei reichem Feedback zu stabilerem Training führt. Der Preis: Ein zusätzlicher Vorwärtsdurchlauf durch den Self-Teacher pro Schritt, und die Notwendigkeit, Feedback sinnvoll zu tokenisieren. Wer bereits eine funktionierende GRPO-Pipeline mit ausgereiftem Tooling betreibt, tauscht Stabilität und Bekanntheit gegen dichtere Signale und einen höheren Implementierungsaufwand.
Wartung, Abhängigkeiten und Lizenz
SDPO steht unter Apache-2.0, was kommerzielle Nutzung, Modifikation und Weitergabe erlaubt, sofern Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien gekennzeichnet werden. Die Lizenz enthält eine ausdrückliche Patentgewährung, aber auch eine Beendigungsklausel bei Patentstreitigkeiten. Das ist keine Rechtsberatung, sondern nur die Einordnung des Lizenzidentifiers aus dem Repository. Wartungsseitig fällt auf, dass die Abhängigkeiten stark gepinnt sind: torch==2.5.1 beziehungsweise torch==2.7.0, dazu vllm, flash-attn, xformers und triton im Container. Solche Pins schützen die Reproduzierbarkeit, erschweren aber Upgrades, weil ein Sprung bei torch oder vllm meist eine Neuabstimmung der übrigen Pakete nach sich zieht. Der letzte Push liegt laut Repository-Metadaten im Juli 2026, es wurden keine Releases abgerufen. Wer SDPO produktiv einsetzen will, sollte den Upgrade-Pfad für die gepinnten Pakete selbst einplanen, statt auf fertige Migrationshinweise zu warten.
Redaktionelles Fazit
SDPO ist für Gruppen interessant, die Reasoning-Modelle in verifizierbaren Domänen wie Mathematik oder Code nachtrainieren und dabei auf externes Lehrer-Modell oder Reward-Modell verzichten wollen, und die über NVIDIA-Hardware mit CUDA verfügen. Wer keine GPU-Cluster betreibt oder eine ausgereifte, breit dokumentierte Trainingsbibliothek mit stabiler API sucht, ist hier falsch. Vor dem ersten eigenen Lauf sollten Interessierte die verlinkte W&B-Log-Sammlung öffnen und dort prüfen, welche Hyperparameter und Batch-Konfigurationen tatsächlich verwendet wurden, denn der README-Ausschnitt endet mitten im Installationsabschnitt und enthält keine Startkommandos für das Training.
Community-Notizen