Erstaunlich einfache Self-Distillation-Methode verbessert die Leistung bei der Codegenerierung

• Simple Self-Distillation (SSD) ist eine Methode, mit der große Sprachmodelle ihre Leistung verbessern, indem sie ihren selbst generierten Code erneut zum Lernen verwenden — ohne Lehrermodell oder Reinforcement Learning
• Beim Modell Qwen3-30B-Instruct verbessert SSD den LiveCodeBench-v6-pass@1-Wert von 42,4 % auf 55,3 %, insbesondere um +15,3 Prozentpunkte im Segment schwieriger Aufgaben
• SSD mildert den Konflikt zwischen Präzision und Exploration bei der Codegenerierung und unterdrückt je nach Kontext die Tail-Wahrscheinlichkeiten, während nützliche Diversität erhalten bleibt
• Allein durch Temperaturanpassung oder Änderungen der Decoding-Policy lässt sich derselbe Effekt nicht reproduzieren; SSD formt die interne Verteilung des Modells selbst um
• Als einfaches Post-Training-Verfahren, das sich ohne externe Daten oder Verifikation anwenden lässt, bietet SSD eine praktische Alternative zur Verbesserung der Codegenerierungsqualität von LLMs

---

Simple Self-Distillation (SSD)

• SSD (Simple Self-Distillation) ist eine Methode, mit der große Sprachmodelle (LLMs) ihre Leistung mithilfe selbst erzeugter Codeausgaben verbessern — ohne Lehrermodell, Verifizierer oder Reinforcement Learning
  • Das Modell erzeugt Samples mit bestimmten Einstellungen für Temperatur (temperature) und Trunkierung (truncation) und lernt diese Ergebnisse anschließend erneut per standardmäßigem Supervised Fine-Tuning (SFT)
  • Es werden keinerlei externe gelabelte Daten, Reward-Modelle oder Laufzeitumgebungen benötigt
• Beim Modell Qwen3-30B-Instruct steigt der LiveCodeBench-v6-pass@1-Wert von 42,4 % auf 55,3 % (+12,9 Prozentpunkte, +30 % relative Verbesserung)
  • Die größten Verbesserungen treten insbesondere bei schwierigen Aufgaben (hard split) auf (+15,3 Prozentpunkte)
  • Das Verfahren generalisiert über 4B-, 8B- und 30B-Modelle der Qwen- und Llama-Familien hinweg
• SSD arbeitet, indem es den Konflikt zwischen Präzision und Exploration (precision-exploration) entschärft
  • Bei der Codegenerierung erfordern einige Tokens hohe Präzision („lock“), andere vielfältige Exploration („fork“)
  • SSD unterdrückt je nach Kontext unnötige Tail-Verteilungen, während nützliche Diversität erhalten bleibt

---

1. Forschungshintergrund

• Es mangelt an hochwertigen überwachten Signalen (z. B. von Menschen geschriebener Code), was die Verbesserung der Codegenerierungsleistung von LLMs begrenzt
• Grenzen bestehender Ansätze
  • Destillation auf Basis von Lehrermodellen: übernimmt die Leistungsgrenzen des Lehrermodells
  • Reinforcement Learning (RL): benötigt Reward-Modelle und ausführungsbasierte Verifikation, ist instabil
  • Unüberwachte Alternativen (z. B. Mehrheitsvotum, Entropieminimierung): bergen bei langfristigem Lernen Kollapsrisiken
• SSD zeigt, dass Verbesserungen ohne externe Daten oder Verifikation allein mit den Ausgaben des Modells möglich sind

---

2. SSD-Methodik

• Datensynthese

  • Für eine gegebene Menge von Problem-Prompts X wird aus dem Modell pθ mit Trainings-Temperatur Ttrain und Trunkierungsparametern ρtrain (top-k, top-p) gesampelt
  • Die generierten Ausgaben (y) werden ohne Verifikation direkt als Trainingsdaten (DSSD) verwendet
  • In den meisten Fällen reicht N=1 (ein Sample pro Problem) aus

• Training

  • Supervised Fine-Tuning mit dem standardmäßigen Cross-Entropy-Loss
  • L(θ) = −E(x,y)∼DSSD Σ log pθ(yt | x, y<t)

• Inferenz

  • Das trainierte Modell pθ* wird mit Evaluations-Temperatur Teval und Trunkierungsparametern ρeval decodiert

  ---

3. Experimente

• Modellaufbau

  • Llama-3.1-8B-Instruct, Qwen3-4B/30B (Instruct, Thinking) und 5 weitere Modelle
  • 2 Familien (Llama, Qwen), 3 Größen (4B, 8B, 30B), 2 Inferenzstile (Instruct, Thinking)

• Daten

  • Verwendet wurden rund 10K Wettkampfprogrammieraufgaben aus dem rSTARcoder-Datensatz
  • Es wurde ohne Korrektheitsverifikation gearbeitet; angewendet wurde nur eine einfache Syntaxfilterung

• Trainingseinstellungen

  • Basierend auf Megatron-LM, mit 8×B200-GPUs
  • AdamW-Optimierer, maximale Sequenzlänge 65.536
  • Instruct-Modelle: 2.500 Schritte, Thinking-Modelle: 300 Schritte

• Evaluation

  • LiveCodeBench v6 (LCB v6) als Hauptbenchmark
  • Auswertung nach pass@1, pass@5 sowie nach Schwierigkeitsgrad (Easy/Medium/Hard)

  ---

4. Zentrale Ergebnisse

• Allgemeine Leistungssteigerung

  • Qwen3-30B-Instruct: 42,4 % → 55,3 % pass@1 (+12,9 Prozentpunkte)
  • Qwen3-4B-Instruct: +7,5 Prozentpunkte, Llama-8B: +3,5 Prozentpunkte
  • Auch Thinking-Modelle verbessern sich um +2 bis +3 Prozentpunkte

• Verbesserungen nach Schwierigkeitsgrad

  • Qwen3-30B-Instruct: Easy +6,5 Prozentpunkte / Medium +14,2 Prozentpunkte / Hard +15,3 Prozentpunkte
  • Auch bei Thinking-Modellen fällt der größte Zugewinn im Hard-Segment an

• Erhalt der Diversität

  • Die Verbesserung bei pass@5 ist größer als bei pass@1 → Diversität bei der Generierung bleibt erhalten und nimmt sogar zu
  • Beispiel: Qwen3-30B-Instruct pass@5 +18,1 Prozentpunkte (Hard +23,0 Prozentpunkte)

• Domänenübergreifende Generalisierung

  • Auch außerhalb von Wettkampfprogrammierung — in Mathematik-, allgemeinem Code- und Verständnisaufgaben — bleibt die Leistung erhalten

  ---

5. Vergleich der Decoding-Policies

• Temperaturanpassung allein kann den SSD-Effekt nicht reproduzieren

  • Temperature Sweep beim Basismodell: Veränderungen bei pass@1 nur im Bereich von 1,5–3,0 Prozentpunkten
  • SSD verbessert unter denselben Bedingungen um +11,8 Prozentpunkte (Qwen3-30B-Instruct)
  • Besonders groß ist der Abstand bei schwierigen Aufgaben und bei pass@5
  • SSD verändert die interne Verteilung des Modells selbst und ist daher nicht durch bloße Decoding-Anpassungen ersetzbar

  ---

6. Interaktion der Hyperparameter

• Das Produkt aus Trainings-Temperatur (Ttrain) und Evaluations-Temperatur (Teval), Teff = Ttrain × Teval, bestimmt die Leistung
  • Bestleistung bei Teff ≈ 1,2
  • Mit höherem Ttrain steigt die Empfindlichkeit gegenüber Änderungen von Teval
• Zusätzliche Trunkierung (truncation) erhöht die Leistungsobergrenze
  • Optimale Einstellung: Ttrain=2.0, Teval=1.1, top-k=10 → pass@1 49,7 % (+7,3 Prozentpunkte)
  • Trunkierung bringt zusätzliche Verbesserungen durch das Entfernen von Low-Probability-Tails

---

7. Funktionsweise von SSD

• Konflikt zwischen Präzision und Exploration (Precision–Exploration)

  • Lock: Positionen, an denen die grammatisch richtige Antwort nahezu feststeht → niedrige Temperatur nötig
  • Fork: Positionen, an denen mehrere Lösungswege möglich sind → hohe Temperatur nötig
  • Mit einer einzigen Temperatur lassen sich beide Anforderungen nur schwer zugleich erfüllen

• Rolle von SSD

  • Bei Lock-Positionen werden Tail-Wahrscheinlichkeiten unterdrückt und so die Präzision erhöht
  • Bei Fork-Positionen werden die Wahrscheinlichkeiten unter den Top-Kandidaten geglättet, damit die Explorationsdiversität erhalten bleibt
  • Dadurch entsteht eine kontextabhängige Umformung der Verteilung

  ---

8. Experimentelle Verifikation

• Experimente in simulierter Umgebung

  • SSD wurde in einer einfachen Umgebung mit einer Struktur aus einmal Fork + dreimal Lock angewendet
  • Nach SSD stieg die Erfolgswahrscheinlichkeit, und der optimale Temperaturbereich wurde breiter
  • Das bestätigt, dass Training und Decoding sich gegenseitig ergänzen

• Analyse realer Modelle

  • Nach SSD steigt die kumulierte Wahrscheinlichkeit der Top-Tokens, während die Tail-Wahrscheinlichkeiten sinken
  • Selbst bei hohem Teval nimmt die Zahl gültiger Top-Kandidaten zu, ebenso die Entropie
  • SSD erreicht also gleichzeitig Tail-Entfernung und Ausweitung der Top-Verteilung

  ---

9. Theoretische Analyse

• Der SSD-Trainingsverlust lässt sich in drei Terme zerlegen
  1. Support Compression: Entfernen von Tail-Wahrscheinlichkeiten
  2. Within-Support Reshaping: Umformung der Top-Verteilung
  3. Alignment to Base Model: Erhalt der Ausrichtung zum ursprünglichen Modell
• Bei Lock dominiert der erste Term → Tail-Entfernung
• Bei Fork wirkt der zweite Term → Glättung der Top-Verteilung
• Die Gesamtentropie sinkt, aber die nützliche Explorationsentropie bleibt erhalten
• Eine bloße Anpassung des Decodings kann diese kontextabhängige Umformung nicht leisten

---

10. Experimente mit anormalen Daten

• Bei mit Ttrain=2.0, ohne Trunkierung erzeugten Daten bestehen 62 % aus bedeutungslosem Rauschen (gibberish)
• Trotzdem ergibt SSD anschließend
  • pass@1: 42,4 % → 48,1 % (+5,7 Prozentpunkte)
  • pass@5: 53,5 % → 64,0 % (+10,5 Prozentpunkte)
  • Bei Hard-Aufgaben Verbesserungen von +7,3 bzw. +13,8 Prozentpunkten
• Das zeigt, dass SSD Verbesserungen nicht über die Qualität richtiger Antworten, sondern über das Lernen der Verteilungsstruktur erzielen kann

---

Fazit

• Simple Self-Distillation (SSD)
  • verbessert die Codegenerierungsleistung allein anhand der Modell-Ausgaben selbst, ohne externe Lehrer oder Verifikation
  • entschärft den Konflikt zwischen Präzision und Exploration und erzielt durch Umformung der Verteilung generalisierbare Verbesserungen
• SSD ist eine einfache und zugleich leistungsstarke Methode, die sich in der Post-Training-Phase anwenden lässt und eine praktische Alternative zur Verbesserung der Codegenerierungsqualität von LLMs bietet

[GN⁺]

Hacker-News-Kommentare

• Interessant an dieser Arbeit ist, dass sie das Konzept des context-aware decoding tatsächlich umsetzt.
  Sie erklärt, dass im Prozess der Codegenerierung abwechselnd „fork“-Punkte auftreten, also kreative Verzweigungen mit mehreren möglichen Interpretationen, und „lock“-Punkte, also syntaktische Entscheidungen, bei denen Genauigkeit nötig ist.
  Beeindruckend ist, dass die SSD-Methode (Simple Self-Distillation) in beiden Situationen das Ranking optimaler Tokens verbessert und dem Modell so hilft, beim Explorieren kreativer und dann, wenn Korrektheit gefragt ist, präziser zu arbeiten.

  • Eigentlich wirken solche Entdeckungen neuer Eigenschaften von LLMs weniger überraschend als selbstverständlich.
    Selbst das menschliche Gehirn wird seit Jahrtausenden erforscht und bleibt in vielen Teilen unverständlich.
    Sogar das emergent behavior des Verkehrsflusses wurde bis vor Kurzem nicht klar verstanden.
    Deshalb ist es nur natürlich, dass wir weiterhin neue Eigenschaften von LLMs entdecken.
  • Interessant ist auch, dass das Modell für „fork“- und „lock“-Tokens die gleiche Rechenmenge aufwendet.
    Mit Grammar-basiertem Sampling oder grammar-aware decoding ließen sich grammatikalisch eindeutige Tokens sogar direkt ohne Modellaufruf einfügen.
    In heute weit verbreiteten Systemen wird das aber kaum eingesetzt.
    Ich frage mich, ob ein verallgemeinerter Ansatz möglich wäre, der für wichtige Entscheidungen mehr Rechenleistung und für offensichtliche Tokens weniger aufwendet.
  • Beim Fine-Tuning kleiner Modelle hatte ich einmal ein mode collapse-Problem, das verschwand, nachdem ich die Reihenfolge der Felder im Training zufällig gemischt hatte.
    Ich überlege noch, ob ich dieselbe Methode auch bei der Inferenz anwenden sollte.
  • Spannend ist, dass SSD wirkt, ohne die temperature in Echtzeit anzupassen oder fork/lock-Punkte vorherzusagen.
  • Das Konzept lässt sich nicht nur auf Code anwenden, sondern auf generative Inhalte allgemein.
    Bei Code ist der Unterschied nur, dass die Struktur klarer ist; der fork/lock-Mechanismus funktioniert aber in vielen Problemräumen.

• Self-Distillation scheint eine zentrale Richtung für die Weiterentwicklung von LLMs zu sein.
  Die von MIT und ETH veröffentlichte Arbeit Self-Distillation Fine-Tuning(SDFT) hat bereits eine hohe Effizienz gezeigt.
  Das SSD (Simple Self-Distillation) dieser Arbeit ist im Grunde eine Fortsetzung davon, nur unter anderem Namen.
  Dass die Bezeichnung SSD sich mit SSD (Solid State Drive) überschneidet, macht es zusätzlich verwirrend.
  Ich hätte mir gewünscht, dass die ursprüngliche SDFT-Arbeit als Quelle und genealogische Vorarbeit klarer anerkannt wird.

• Kürzlich habe ich ein Video gesehen, in dem Gemma 4 lokal mit 50 Tokens pro Sekunde lief.
  Funktional liegt das bereits auf dem Niveau von Sonnet 3x bis 4.
  Wenn dann noch Verfahren wie SSD dazukommen, werden günstige und leistungsfähige Code-Modelle bis etwa 2028 wohl weit verbreitet sein.
  Erfahrene Entwickler werden wahrscheinlich eigene Modelle als nichtdeterministische Transpiler betreiben, die natürliche Sprache in Code umwandeln.

  • Daran denke ich auch oft. Wenn ein Modell nur auf den neuesten Versionen der von mir genutzten Sprachen trainiert würde, also PHP, SQL, JS usw., könnte es dann nicht viel kleiner und schneller sein?
    Im Moment fühlt es sich an, als würde man „ein Haus auf Nägeln bauen“.
  • Natürlich könnten bis dahin auch Frontier-Modelle mit projektspezifischem Gedächtnis und On-Demand-Lernen persönliche Modelle klar übertreffen.

• Die zentrale SSD-Hypothese eines precision-exploration-Konflikts ähnelt dem Problem, das Adaptive Decoding lösen will.

  • Ich interessiere mich ebenfalls sehr für Adaptive Decoding.
    Es scheint offensichtlich, dass während der Inferenz für Phasen kreativen Denkens eine hohe temperature nötig ist, während für syntaktische Genauigkeit eine niedrige temperature gebraucht wird.

• Schon das wiederholte Fragen „Ist das wirklich die eleganteste Lösung?“ verbessert die Ausgabe eines LLM sichtbar.
  Wenn das Modell so leicht eine bessere Antwort finden kann, fragt man sich, warum es das nicht gleich von Anfang an tut.

  • In der Praxis entsteht eine elegante Lösung meistens nicht im ersten Versuch.
    Erst baut man etwas, das funktioniert, und verfeinert es dann mehrfach, bis es wirklich knapp und sauber wird.
  • Bei menschlichen Entwicklern ist es genauso.
    Manche denken einen halben Tag nach, bevor sie Code schreiben, andere implementieren sofort die erste Lösung.
    Aktuelle LLMs ähneln eher Letzteren.

• Diese Forschung dürfte mit hoher Wahrscheinlichkeit zu besseren Modellen für Codegenerierung führen.
  Trotzdem verstehen wir noch immer nicht wirklich, was in hochdimensionalen Räumen vor sich geht.
  Letztlich erkunden wir das Feld immer noch nach dem Prinzip „etwas werfen und sehen, ob es kleben bleibt“.

• Durchbrüche im Machine Learning wirken nach außen oft einfach.
  Beim Transformer war es so, und bei SSD ist es genauso.
  Vermutlich liegt das daran, dass uns noch immer eine tiefe theoretische Grundlage fehlt.

  • Wie bei vielen Entdeckungen ist Einfachheit oft ein Zeichen von Richtigkeit.
    Komplexität ist häufig eher ein Signal dafür, dass das Verständnis noch fehlt.
    Meiner Programmerfahrung nach ist das eine ziemlich verlässliche Regel.

• Ironischerweise veröffentlicht Apple weiterhin AI-Forschung, während OpenAI das nicht tut.

  • Das finde ich auch seltsam. Es scheint keinen besonderen Grund zu geben, alles unter Verschluss zu halten.
  • Vielleicht liegt es auch daran, dass OpenAI noch keinen Markt zu verteidigen hat.

• Jemand hat diese Arbeit als „ein auf Benchmark-Code-Ergebnisse feinabgestimmtes Modell“ zusammengefasst, aber tatsächlich ist es etwas anderes.

  • Liest man die Arbeit, sieht man, dass ohne Verifikation der richtigen Antwort oder Qualitätsbewertung einfach Benchmark-Eingaben eingespeist und die erzeugten Ausgaben wieder fürs Training genutzt werden.
    Danach liefert ein Modell mit angepassten Decoding-Einstellungen (temp, top-k) bessere Resultate als das Original.
    Es geht also nicht einfach um Fine-Tuning auf Benchmarks, sondern um Leistungssteigerung auf Basis der eigenen Ausgaben.

• Man kann diese Forschung mit Golftraining vergleichen.
  Wenn man durch Tausende Schläge den grundlegenden Schwung automatisiert, kann man im echten Spiel auch kreative und riskante Schläge selbstbewusst versuchen.
  SSD verfolgt einen ähnlichen Ansatz: Grundmuster werden verstärkt, um mehr Spielraum für kreative Entscheidungen zu schaffen.