24 Stunden, 1.000 Tool-Calls: Was die Kernel-Fallstudie wirklich beweist
Benchmarks messen den Sprint eines Agenten. Metas Kernel-Optimierungsstudie misst den Marathon — und das ist die deutlich spannendere Zahl.
Das Setup
Meta hat getestet, ob Muse Spark 1.2 GPU-Kernel über mehr als 1.000 Tool-Calls hinweg iterativ optimieren kann — in Läufen von bis zu 24 Stunden. In Muse Codes agentischer Umgebung schreibt das Modell einen Kernel, kompiliert ihn, profiliert ihn gegen eine vorgegebene Baseline und nutzt die Profiling-Daten für den nächsten Versuch: eine enge Write-Compile-Profile-Improve-Schleife, einen ganzen Tag lang durchgehalten. Als Benchmark-Ziele dienten KDA- und MLA-Attention-Kernel auf NVIDIA-Hopper-GPUs.
Eine Regel machte den Test ehrlich: Die Modelle durften keine Kernel-Bibliotheken von Drittanbietern wie FLA importieren. Kein Wrapping einer existierenden schnellen Implementierung, um sich mit fremden Federn zu schmücken — der Agent musste echtes Kernel-Optimierungswissen anwenden und die Algorithmen selbst in Triton implementieren.
Was der Agent tatsächlich gebaut hat
Die Lösungen waren alles andere als generisch. Für KDA — gebenchmarkt gegen die FLA-Triton-Implementierung — kombinierte Muse Spark 1.2 einen chunk-parallelen Vorbereitungs-Kernel mit einem sequenziellen Inter-Chunk-Scan und verband Standard-Fusion und -Tiling mit KDA-spezifischen Kniffen wie dem Re-Centering des gated kumulativen Decays am Chunk-Mittelpunkt. Für MLA — gegen eine PyTorch-Referenz bei Batch-Größe 1, 64 Heads, Sequenzlänge 8192, Latent-Dimension 512 — entwarf das Modell eine zweistufige Triton-Pipeline, die das geteilte KV-Latent gleichzeitig als K und V wiederverwendet.
Das sind Optimierungen, wie sie ein Spezialist schreibt, nachdem er die Struktur des Algorithmus verstanden hat — keine oberflächlichen Loop-Tweaks. Und der Agent fand über die gesamte Laufzeit hinweg weiter substanzielle Verbesserungen gegenüber der Baseline: Fortschritt, der sich über Hunderte Iterationen aufsummierte, statt nach dem ersten Schub abzuflachen.
Warum die 24 Stunden die eigentliche Schlagzeile sind
Einen Kernel zwanzig Minuten lang verbessern können viele Modelle. Zielgerichteten Fortschritt einen ganzen Tag durchzuhalten, verlangt Infrastruktur, die die meisten Agenten schlicht nicht haben. Drei Bausteine tragen die Last. Goal Conditioning sorgt dafür, dass Iteration 700 noch auf dasselbe Ziel einzahlt wie Iteration eins — das Modell wurde genau dafür trainiert. Context Compaction behält das Wissen, das zählt (welche Strategien gescheitert sind, was der Profiler gesagt hat), ohne in einem Tag Historie zu ertrinken. Und das Event-Log macht die Runtime restart-sicher — über 24 Stunden wird irgendetwas haken, und ein Crash, der Stunde 23 auslöscht, würde die ganze Übung sinnlos machen.
Was das für den Arbeitsalltag bedeutet
Kaum ein Team optimiert Hopper-Kernel. Aber die Form der Aufgabe — gegen ein messbares Ziel iterieren, aus jedem Versuch lernen, den Faden nicht verlieren — passt auf jede Menge unglamouröses Engineering: eine flaky Testsuite jagen, eine Bundle-Größe herunterschleifen, eine API über hundert Aufrufstellen migrieren. Die Fallstudie ist Metas Beleg dafür, dass „anstoßen und morgen nachsehen“ inzwischen ein echter Workflow ist. Die Evaluationsmethodik ist auf Metas Research-Seite veröffentlicht; die Produktseite der Long-Horizon-Arbeit beginnt in den Docs.