Weight-Space Programming: Der dritte Hebel für LLMs

Gradient Descent war nie heilig. Es war ein Gerüst – das einzige universelle Werkzeug, das wir hatten, um Milliarden Zahlen zu formen, die kein Mensch lesen kann, also haben wir die gesamte Religion des Deep Learning darum herum gebaut. Ein Team am MIT CSAIL hat das Gerüst gerade eingerissen. Sie gaben einem Frontier-Modell die rohen Gewichte trainierter neuronaler Netze und baten es in einfacher natürlicher Sprache, sie zu erklären, zu debuggen und umzuschreiben – ohne Trainingsschleife, ohne Gradienten, ohne Forward-Passes. Es funktionierte. Weight-Space Programming, also das Schlussfolgern direkt über Parameter statt sie bergab zu schubsen, ist vom Gedankenexperiment zur Demo geworden, und ich glaube, es degradiert Fine-Tuning still und leise von „die Art, wie wir Modelle anpassen“ zu einer von drei Optionen.

Das Hauptergebnis verdient den Hype. Als man Qwen3.5-0.8B ohne jegliche Gradienten-Updates besser in Mathe machen sollte, verfolgte das Modell – GPT-6 Astra – eine pathologische Reasoning-Schleife bis zu einer einzelnen Richtung, die in zwei MLP-Schichten kodiert war, zog sie von 0,016 % der Gewichte ab und hob die MATH-500-Genauigkeit von 7,9 % auf 48,1 %. Gleiche Sampling-Einstellungen, alles gleich. Der Fix übertrug sich sogar auf Instruction Following und verdreifachte IFEval. Das ist keine Hyperparameter-Feinjustierung, das ist Chirurgie. Aber bevor wir das Gradient Descent begraben, lohnt es sich, genau zu sein, was tatsächlich gezeigt wurde, wo es sich verallgemeinert und wo es schon jetzt scheitert.

Was Weight-Space Programming eigentlich ist

Seit Jahren haben wir genau zwei Wege, das Verhalten eines Modells zu ändern. Prompting verändert die Eingabe; die Gewichte bleiben eingefroren. Fine-Tuning verändert die Gewichte, aber blind – man zeigt der Loss-Landschaft einen Batch von Beispielen und lässt Gradienten die Parameter in die Richtung drücken, die den Fehler senkt, mit wenig Kontrolle darüber, welche interne Mechanik dabei umverdrahtet wird. Weight-Space Programming schlägt einen dritten Hebel vor: Man wirft die Loss-Funktion komplett weg und lässt ein Reasoning-System die Gewichte lesen, eine Hypothese darüber bilden, was sie berechnen, und sie so editieren, dass sie einer Spezifikation in natürlicher Sprache entsprechen.

Am unheimlichsten sind die Leseergebnisse. Die Forscher trainierten vier winzige Policies mit PPO auf Gitterwelt-Versionen von Breakout, Pong, Pac-Man und Freeway – identische Architekturen, identische Eingabekanäle, identische Aktionsräume, sodass nur die Gewichte sie unterscheiden konnten. Astra benannte alle vier Spiele korrekt, ohne die Kandidatenliste zu kennen. Dasselbe gelang bei Diffusionsmodellen, die auf Kreise, Quadrate und Dreiecke trainiert waren, und – die schwerere Version – es erkannte, welcher von drei Character-Level-Transformern auf Python, Englisch oder romanisiertes Japanisch trainiert war, und zwar nur anhand der mittleren Schichten, mit entfernten Embeddings und Output-Schichten und ohne beschriftete Dimensionen. Nebenbei fand es jeden Induction Head, also die Kopierschaltkreise, mit denen ein Modell früheren Text wiederholt, indem es Gewichtsmatrizen miteinander multiplizierte. Das ist eine bekannte Technik aus der Interpretierbarkeitsforschung, von der ihm niemand erzählt hat. Wer die mühsame Arbeit an der mechanistischen Interpretierbarkeit verfolgt hat, dem wird beim Zusehen, wie ein universelles Modell das nebenbei tut, ein wenig schwindelig.

Dann schrieb es Gewichte. Bei einem PPO-trainierten Auto-Controller, der in einem lokalen Minimum feststeckte – die Policy fuhr geradewegs auf eine Rampe zu, statt zuerst rückwärts zu fahren, um Geschwindigkeit aufzubauen – diagnostizierte Astra den Fehler anhand der Gewichte plus einer aufgezeichneten Episode, und seine Änderung ließ das Auto in allen 1.024 Evaluationsepisoden Erfolg haben, nachdem es 3,5 % der Parameter verändert hatte. Als es Spiel-Netze ohne jegliches Environment-Feedback von Grund auf schreiben sollte, produzierte es Policies, die Netze übertrafen, die 100 Millionen Schritte mit PPO trainiert worden waren. Lies das noch mal: keine Interaktion, kein Reward-Signal, nur eine Beschreibung eines Spiels in natürlicher Sprache, die durch das Schlussfolgern eines Sprachmodells in funktionierende Gewichte übersetzt wurde.

Wie direkte Gewichtsedits an echten Modellen funktionieren

Die Qwen-Reparatur ist das Ergebnis, das für Praktiker zählt, denn 0,8 Milliarden Parameter sind ein echtes Modell – die Art, die Teams tatsächlich fine-tunen und ausliefern. Das Problem ist gut dokumentiert: Winzige Reasoning-Modelle geraten in Schleifen, wiederholen denselben Text bis zum Token-Limit und liefern nie eine Antwort. Qwens eigene Model Card warnt davor, und in den Testläufen der Forscher verbrauchten 85 der ersten 96 Antworten auf diese Weise den gesamten Kontext von 32.768 Token. Astras Diagnose: Die MLPs in den Schichten 15 und 19 schrieben eine Richtung in den Residual Stream, die das Modell immer wieder in dieselbe generative Trajektorie zurückzog. Sein Fix bestand darin, diese Richtung von 64 Ausgabespalten in jedem der beiden MLPs abzuziehen – insgesamt 131.072 Gewichte, 0,016 % des Modells.

Die Arithmetik ist fast beleidigend einfach, und genau das ist der Punkt. Sobald man weiß, welche Richtung im Aktivierungsraum „endlos schleifen“ entspricht, ist das Entfernen eine Projektion: Für jeden betroffenen Gewichtsvektor zieht man die Komponente ab, die entlang der schlechten Richtung liegt. Das kann jeder in einem Dutzend Zeilen schreiben.

import numpy as np
def subtract_direction(W, v, columns):
"""Remove the component of each chosen column that lies along v."""
v = v / np.linalg.norm(v)
W[:, columns] -= np.outer(v, v @ W[:, columns])
return W
# The Qwen repair, schematically: for the MLP output projections of
# layers 15 and 19, subtract the "loop" direction from 64 columns each.
# 2 layers x 64 columns x 1024 rows = 131,072 edited weights.
W_down[15] = subtract_direction(W_down[15], loop_dir[15], cols[15])
W_down[19] = subtract_direction(W_down[19], loop_dir[19], cols[19])

Der schwierige Teil war nie die Subtraktion – sondern zu wissen, welche Richtung, in welcher Schicht, in einem Residual Stream, der tausende Dimensionen breit ist. Genau dafür brauchten wir bisher Gradient Descent, denn Gradienten sind ein Suchverfahren über den Gewichtsraum, das überhaupt kein Verständnis erfordert. Astra ersetzte Suche durch Diagnose. Das ist der Unterschied zwischen einem Elektriker, der Stromkreise per Versuch und Irrtum umverdrahtet, bis der Fehler verschwindet, und einem, der den Schaltplan liest und den richtigen Draht durchtrennt. Aus demselben Grund fand das Modell die Induction Heads durch Komposition von Gewichtsmatrizen: Es wandte eine veröffentlichte Interpretierbarkeitsmethode an, die man ihm nie gezeigt hatte, was auf echten Transfer von Reasoning statt auf auswendig gelernte Rezepte hindeutet.

Wann direkte Gewichtsedits Fine-Tuning schlagen

Hier ist meine Meinung, und ich verteidige sie: Für eng umrissene, lokalisierbare Fehler in kleinen bis mittelgroßen Modellen ist direktes Gewichtsediting bereits das bessere Werkzeug, und zwar mit deutlichem Abstand. Schau dir die Fine-Tuning-Alternative für den Loop-Bug an. Man würde einen Datensatz nicht-schleifender Reasoning-Traces zusammenstellen, SFT oder RL fahren und hoffen, dass der Loss-Druck das Verhalten entfernt, ohne alles andere zu verschlechtern, was das Modell weiß. Man würde GPU-Stunden damit verbrennen, auf einen Proxy hinzuoptimieren – mehr Mathedaten –, statt auf die eigentliche Absicht, nämlich „hör auf, dich zu wiederholen“. Weight-Space Programming lässt dich die Absicht formulieren. Der Edit hat ein Hundertstel Prozent des Modells berührt; ein Fine-Tune berührt alles, und die Kollateralschäden tauchen später als seltsame Regressionen auf, die niemand mehr mit dem Trainingslauf in Verbindung bringt.

Fine-Tuning optimiert auf einen Proxy für deine Absicht. Weight-Space Programming lässt dich die Absicht direkt formulieren.

Der zweite Fall ist das Entkommen aus lokalen Minima, die Gradientenmethoden strukturell nicht verlassen können. PPO blieb an der Rampe hängen, weil Reinforcement Learning die aktuelle Policy durch Zittern erkundet, und keine kleine Störung von „geradeaus fahren“ findet „zwei Sekunden rückwärts zuerst“. Reasoning zittert nicht. Es kann in eine qualitativ andere Lösung springen, weil es auf einem Modell des Problems operiert und nicht auf einer Störung der aktuellen Antwort. Eine Milliarde PPO-Schritte fand nicht, was ein einziger Reasoning-Durchlauf fand – das ist kein Effizienzunterschied, sondern ein kategorialer.

Drittens kollabiert die Iterationsschleife. Fine-Tuning hat einen logistischen Schwanz – Datenkuratierung, Trainingsläufe, Eval-Sweeps, Regressionschecks –, der aus „kleine Verhaltensänderung“ ein mehrtägiges Projekt macht. Wer ein großes Modell auf eigener Hardware betrieben hat, weiß, wie viel Aufwand Plumbing statt Modellierung ist. Ein Gewichtsedit ist eher wie ein Code-Hotfix: diagnostizieren, patchen, Evals laufen lassen, zurückrollen, falls es falsch war. Wenn die Diagnose stimmt, überspringst du die gesamte Trainingspipeline. Die klaren Gewinne konzentrieren sich auf vier Situationen:

• Der Fehler ist diagnostiziert, aber es gibt keine Trainingsdaten, die die Korrektur ausdrücken
• Du brauchst chirurgische Reichweite – ein Verhalten ändern, ohne den Rest zu verschieben
• Das Modell steckt in einem lokalen Minimum, aus dem zufällige Exploration nicht entkommt
• Du kannst dir keine Trainingspipeline leisten, weder an GPUs noch an Kalenderzeit

Warum Weight-Space Programming spröde ist

Nun das kalte Wasser, denn davon gibt es genug. Der nützlichste Datenpunkt, den ich gesehen habe, stammt nicht aus dem Paper, sondern von einem Praktiker, der denselben Trick an einem kleinen Natural-Language-zu-Bash-Modell ausprobierte und unter dem Strich nichts gewann. Das Editieren von 1.920 Gewichten behob einige grep-Fehler und zerstörte andere Befehle. Das ist das erwartbare Ergebnis, und es ist das tiefe Problem: Verhalten in trainierten Netzen ist verflochten. Der Qwen-Edit funktionierte, weil das Schleifenverhalten zufällig in einer kompakten, entfernbaren Richtung lebte. Viele Verhaltensweisen tun das nicht. Sie sind über Superposition verschmiert, wobei dieselben Spalten mehrere unabhängige Features tragen; eine „Richtung“ abzuziehen ist, als würde man einen Ton aus einem Akkord entfernen. Du wirst die anderen mit abschneiden. Niemand hat eine Theorie, die im Voraus vorhersagt, welche Fehler geometrisch kompakt und welche verschmiert sind. Bis wir das haben, ist jeder Gewichtsedit ein Glücksspiel.

Auch die Lesedemos verdienen einen Abschlag. Astras Schlüsse über die Spiel-Netze stützten sich auf Oberflächenstatistiken – wo sich die Gewichte der ersten Schicht konzentrieren, welche Output-Logits sich trennen –, und die Spracherkennung war faktisch eine Dreifach-Multiple-Choice-Frage, bei der eine Option, das romanisierte Japanisch, eine auffällig ungewöhnliche Buchstabenverteilung hat (kein q, l, v oder x). Beeindruckende Mustererkennung? Auf jeden Fall. Beleg für tiefes, nativ gewachsenes Verständnis des Gewichtsraums? Weniger klar. Das Diffusions-Ergebnis wirkt in beide Richtungen: Astra zeichnete alle Formen als Umrisse, obwohl die Modelle tatsächlich gefüllte Formen erzeugen. Das ist ein Fehler, der belegt, dass es Geometrie las statt das Netz zu simulieren, zeigt aber auch, dass sein „Verständnis“ strukturell falsch sein kann und dennoch den Test besteht.

Dann gibt es Skalierung und Herkunft. Jedes saubere Ergebnis liegt zwischen 17.000 und 7 Millionen Gewichten, wobei Qwens 0,8 B der Ausreißer ist, und selbst das Experiment zum Lesen der mittleren Schichten brauchte bis zu hundert Python-Analyseläufe, um dorthin zu kommen. Niemand hat gezeigt, dass das bei einem 70B-Modell funktioniert, geschweige denn bei einem Frontier-Modell, und der naive Ansatz – die Gewichte in ein Kontextfenster kopieren – scheitert lange davor. Eine unbequeme Frage hängt zudem über dem Ganzen: Woher kommt diese Fähigkeit? LLMs, die auffällig gut Schach spielen, haben sich meist als Vielfraße für Schachnotation im Training erwiesen. Falls Astra gezielt mit Gewichtsdaten trainiert wurde, sagen diese Ergebnisse weniger über emergentes Verständnis aus und mehr über ein sehr gutes Curriculum. Wir wissen es wirklich nicht.

Schließlich braucht der MATH-500-Sprung ein Sternchen. Dieser Benchmark ist seit Jahren durch Trainingsdaten gesättigt, und ein Basismodell mit 7,9 % scheitert mit ziemlicher Sicherheit an Schleifen und Formatierung statt an mathematischer Fähigkeit – was bedeutet, dass der Edit latente Fähigkeit freigeschaltet hat, statt Können zu erzeugen. Das ist trotzdem wertvoll; Freischalten ist ein echter Gewinn. Aber es ist eine andere Behauptung als „der Edit hat das Modell in Mathe besser gemacht“, und sie passt in ein bekanntes Muster, in dem Benchmarks den Großteil dessen verfehlen, wie echte Arbeit aussieht.

Gewichtsedits in der Produktion: Behandle sie wie Hotfixes

Wenn du das ausprobieren willst – und bei kleinen Modellen solltest du das –, behandle Gewichtsedits mit der Disziplin, die du bei einem Hot-Patch an einer laufenden Datenbank anwenden würdest. Diff alles: Protokolliere genau, welche Tensoren sich wie stark verändert haben, denn 0,016 % sind so klein, dass ein stiller Bug in deinem Edit-Skript für immer verborgen bleibt. Evaluiere breit, nicht nur das Zielverhalten; der Qwen-Fix verbesserte zufällig das Instruction Following, aber das Vorzeichen dieses Nebeneffekts war Glück, und beim nächsten Mal kann es umgekehrt sein. Bewahre den Basis-Checkpoint heilig und versioniere jeden Edit als rückgängig machbaren Patch. Und begrenze deinen Ehrgeiz: Der demonstrierte Sweet Spot sind kleine, gut verstandene Fehler in Modellen, die du vollständig evaluieren kannst. Wenn dein Instinkt ist, ein vages Stimmungsproblem in einem 70B-Modell durch „Entfernen der schlechten Richtung“ zu beheben, wirst du die Superposition auf die harte Tour lernen.

• Base-Checkpoint fixieren; Edits als Diffs speichern, niemals in place überschreiben
• Breite Evals vor und nach dem Edit laufen lassen, nicht nur den Ziel-Benchmark
• Fehler mit scharfer, reproduzierbarer Signatur bevorzugen statt Stimmungen
• Reverts einplanen – geh davon aus, dass ein Teil der Edits etwas kaputt macht

Meine ehrliche Position: Heute ist das ein Interpretierbarkeitsinstrument und ein Debugging-Skalpell, keine Deployment-Pipeline. Die Teams, die zuerst Nutzen daraus ziehen, werden nicht die sein, die Gewichtsedits in die Produktion schicken. Es werden diejenigen sein, die ein Frontier-Modell einsetzen, um zu erklären, was ihre kleinen Modelle gelernt haben – Checkpoints so lesen, wie wir Reasoning-Traces bereits lesen – und dann mit gewöhnlichen, langweiligen, verlässlichen Werkzeugen darauf reagieren.

Gradienten sind nicht tot – sie wurden degradiert

Hier bricht meine Eingangsthese zusammen, und ich will dazu ehrlich sein. Gradient Descent kann etwas, was Weight-Space Programming nicht kann: aus Daten in großem Maßstab lernen. Jede Fähigkeit, die Astra für diese Edits nutzte, wurde selbst durch Gradienten über ein riesiges Trainingskorpus installiert. Reasoning kann am Wissen eines Netzes chirurgisch arbeiten; es kann einem Netz nicht die Summe des menschlichen Textes beibringen. Die realistische Zukunft ersetzt Gradienten nicht, sondern teilt die Arbeit auf. Gradienten gießen das Fundament; Weight-Space Programming macht die Feinarbeit. Vierzig Jahre lang haben wir trainierte Gewichte als undurchsichtiges Artefakt behandelt, eine Black Box, die man nur von außen steuern konnte. Die wirklich neue Idee hier ist, dass die Box lesbar wird – und das, was sie liest, sind nicht wir. Ob das beruhigend oder beunruhigend ist, hängt wohl davon ab, wie sehr du den Gradienten vertraut hast.