Karpathys AutoResearch: 630 Zeilen Python, die über Nacht 100 Experimente durchführen

Andrej Karpathy hat am 6. März 2026 AutoResearch veröffentlicht. Zwei Wochen später: 48.000 GitHub-Sterne, 6.700 Forks und konkrete Forschungsergebnisse, die Karpathys eigene handoptimierte Einreichungen auf ML-Benchmarks schlagen. Das gesamte System besteht aus 630 Zeilen Python. Ein KI-Agent liest den Code, schlägt eine Änderung vor, führt ein 5-Minuten-Trainingsexperiment auf einer einzelnen GPU durch, prüft ob die Validierungsmetrik sich verbessert hat, behält oder verwirft das Ergebnis und wiederholt. Kein menschlicher Eingriff nötig, nachdem man Enter gedrückt hat.

Das ist kein Framework. Das ist keine Plattform. Es ist ein Loop: Hypothese, Experiment, Auswertung, Wiederholung. Der Agent führt 12 Experimente pro Stunde durch, etwa 100 über Nacht. Karpathy lief 700 Experimente über zwei Tage und fand 20 kombinierbare Verbesserungen, die die GPT-2-Trainingszeit von 2,02 Stunden auf 1,80 Stunden senkten: 11% schneller.

So funktioniert AutoResearch: Drei Dateien, eine Metrik, null Handarbeit

Die Designphilosophie hinter AutoResearch ist radikale Einfachheit. Das gesamte System besteht aus drei Dateien:

train.py (~630 Zeilen): Enthält die GPT-Modelldefinition, den Muon+AdamW-Optimizer und den Trainingsloop. Dies ist die einzige Datei, die der Agent bearbeiten darf. Jedes Experiment ist eine Modifikation dieser Datei.

prepare.py: Kümmert sich um Datenvorbereitung, Tokenisierung und definiert die Evaluierungsfunktion evaluate_bpb(). Der Agent kann diese Datei lesen, aber nicht ändern. Das verhindert, dass der Agent die Bewertungsmetrik manipuliert.

program.md: Natürlichsprachliche Anweisungen, die dem Agenten sagen, was er tun soll. Vergleichbar mit einem System-Prompt für den Forschungsloop. Eine zentrale Anweisung sticht heraus: “Halte NICHT an, um den Menschen zu fragen, ob du weitermachen sollst. Du bist autonom. Der Loop läuft, bis der Mensch dich unterbricht. Punkt.”

Die einzige Metrik ist val_bpb (Validation Bits per Byte). Niedriger ist besser. Weil sie unabhängig von der Vokabulargröße ist, kann der Agent Architekturänderungen vornehmen (Schichten hinzufügen oder entfernen, Attention-Mechanismen ändern) und bekommt trotzdem einen fairen Vergleich zwischen Experimenten.

Der Acht-Schritte-Loop

Jedes Experiment folgt einem identischen Zyklus:

1. Analysieren: train.py lesen, Git-Status prüfen, vorherige Ergebnisse durchgehen
2. Hypothese aufstellen: Eine konkrete Modifikation vorschlagen (Architektur-Tweak, Hyperparameter-Änderung, Optimizer-Anpassung)
3. Ändern: train.py mit der vorgeschlagenen Änderung bearbeiten
4. Committen: Die Änderung per Git committen
5. Trainieren: uv run train.py > run.log 2>&1 für exakt 300 Sekunden ausführen
6. Extrahieren: val_bpb aus dem Trainingslog parsen
7. Bewerten: Mit dem bisherigen Bestwert vergleichen
8. Entscheiden: Bei Verbesserung den Commit behalten. Bei Verschlechterung oder Crash git reset HEAD~1. Zurück zu Schritt 1.

Jedes Ergebnis wird in results.tsv mit dem Status keep, discard oder crash protokolliert. Das gibt dem Agenten eine wachsende Historie, die zukünftige Hypothesen informiert.

Warum 630 Zeilen entscheidend sind

Das ist kein zufälliger Minimalismus. Karpathy hat die Codebasis so entworfen, dass sie vollständig in ein einziges LLM-Kontextfenster passt. Jedes fähige Modell (Claude Opus 4.6, GPT-4, Sonnet) kann alle 630 Zeilen im Arbeitsspeicher halten, während es über Modifikationen nachdenkt. Sobald Code auf mehrere Dateien und tausende Zeilen verteilt wird, verlieren aktuelle KI-Agenten den Überblick über Wechselwirkungen zwischen Komponenten.

Die Einschränkung macht die Ergebnisse auch glaubwürdig. Der Agent kann keine neuen Pakete installieren, die Evaluierungsfunktion nicht ändern und nicht schummeln. Er muss echte Verbesserungen an echtem Trainingscode erzielen.

Was AutoResearch tatsächlich herausgefunden hat

Karpathy hat AutoResearch nicht als Spielzeug-Demo veröffentlicht. Er hat es gegen sein eigenes nanochat-Leaderboard laufen lassen, einen kompetitiven Benchmark für kleinformatiges GPT-Training, und der Agent produzierte Ergebnisse, die für Platz 5 reichten. Dieser Eintrag schlug jede vorherige Einreichung, die Karpathy selbst manuell gemacht hatte.

Über ~700 Experimente in zwei Tagen auf Depth-12-GPT-Modellen fand der Agent etwa 20 echte Verbesserungen, die sich stapeln ließen:

• QKNorm fehlte ein Skalierungsmultiplikator, was die Attention zu diffus machte. Der Agent fügte ihn hinzu und sah sofortige Verbesserung der Validierung.
• Value Embeddings hatten keine ordentliche Regularisierung. Der Agent entdeckte dies eigenständig, ohne Vorwissen aus der Forschungsliteratur.
• Das Banded-Attention-Fenster war zu konservativ. Der Agent erweiterte es.
• AdamW-Beta-Parameter waren suboptimal. Dutzende Experimente, um bessere Werte einzugrenzen.
• Weight-Decay-Scheduling und Netzwerk-Initialisierung brauchten Feintuning. Kleine Änderungen, aber sie addierten sich.

Zusammen brachten sie die “Time to GPT-2”-Metrik von 2,02 Stunden auf 1,80 Stunden. Und alle 20 Verbesserungen übertrugen sich perfekt von Depth-12 auf Depth-24-Modelle ohne Nachtuning.

Jenseits von Karpathy: Tobi Lutkes Ergebnisse

Shopify-CEO Tobi Lutke wandte das AutoResearch-Muster auf zwei grundverschiedene Probleme an. Zuerst eine ML-Aufgabe: 37 Experimente über Nacht. Ein 0,8B-Parameter-Modell erzielte 19% höhere Scores als sein vorheriges handgetuntes 1,6B-Modell. Bessere Leistung mit buchstäblich der Hälfte der Parameter.

Dann versuchte Lutke etwas Interessanteres. Er richtete dasselbe Muster auf Shopifys Liquid-Template-Engine, das Rendering-System hinter jedem Shopify-Webshop. 93 automatisierte Commits später: 53% schnelleres Rendering und 61% weniger Objektallokationen. Das war keine ML-Forschung, sondern Performance-Optimierung an Produktionscode, erledigt von einem Agenten-Loop über Nacht.

Für deutsche E-Commerce-Unternehmen, die auf Shopify setzen, ist das eine bemerkenswerte Entwicklung. Dieselbe Infrastruktur, die ihre Shops ausliefert, wurde von einem KI-Agenten signifikant beschleunigt, ohne dass ein Mensch eine einzige Zeile Code reviewen musste.

SkyPilot: Skalierung auf 16 GPUs für 300 Dollar

Das SkyPilot-Team nahm AutoResearch und parallelisierte es über 13 H100s und 3 H200s auf CoreWeave Kubernetes. In 8 Stunden wurden ~910 Experimente eingereicht (~700 mit validen Ergebnissen), ein 9-facher Durchsatz im Vergleich zum sequentiellen Single-GPU-Betrieb.

Die Gesamtkosten lagen bei etwa 300 Dollar: 9 Dollar für Claude-API-Aufrufe und 260 Dollar für GPU-Compute. Die val_bpb verbesserte sich von 1,003 auf 0,974, ein Gewinn von 2,87%.

Ein Detail stach heraus: Der Agent entwickelte eigenständig eine Zwei-Stufen-Strategie. Er testete Ideen zunächst auf den günstigeren H100-GPUs und validierte vielversprechende Kandidaten dann auf den schnelleren H200s. Niemand hatte ihm das gesagt. Er hat Ressourcenoptimierung von alleine herausgefunden.

Der Karpathy Loop als Entwurfsmuster

Analyst Janakiram MSV prägte den Begriff “The Karpathy Loop” für das Muster, das AutoResearch antreibt. Es braucht drei Voraussetzungen:

1. Eine editierbare Datei, die der Agent vollständig kontrolliert
2. Eine objektiv testbare Metrik, die Erfolg oder Misserfolg bestimmt
3. Ein festes Zeitbudget pro Experiment, um unkontrollierte Kosten zu vermeiden

Jedes Problem, das sich so strukturieren lässt, kann “autoresearched” werden. Die Metrik muss kein Validierungsverlust sein. Es kann Seitenladezeit sein, Speicherverbrauch, Rendering-Geschwindigkeit, Testabdeckung oder Conversion-Rate.

Karpathy selbst hat das deutlich gemacht: “Jede Metrik, die euch wichtig ist, kann von einem Agenten-Schwarm autoresearched werden.” Er verglich die Zukunft von AutoResearch mit SETI@home, wo verteilte Agenten asynchron an einer gemeinsamen Forschungsfront zusammenarbeiten.

Was AutoResearch von AutoML unterscheidet

Traditionelle neuronale Architektursuche (NAS) und AutoML-Tools durchsuchen vordefinierte Parameterräume. Sie variieren Lernraten zwischen 1e-3 und 1e-5, probieren drei Aktivierungsfunktionen und testen vier Schichttiefen. Der Suchraum steht fest, bevor der Prozess beginnt.

AutoResearch funktioniert fundamental anders. Das LLM liest echten Python-Code, versteht, was jede Komponente tut, überlegt, warum eine Änderung helfen könnte, und schlägt neuartige Modifikationen vor, die in keinem vordefinierten Suchraum enthalten wären. Der Agent, der den fehlenden Skalierungsmultiplikator in QKNorm entdeckte, hat kein Gitter durchsucht. Er hat Code gelesen, einen mathematischen Fehler verstanden und ihn behoben.

Für deutsche Forschungseinrichtungen und KI-Labs, die unter dem EU AI Act ohnehin mehr Transparenz in ihren Trainingsmethoden brauchen, bietet AutoResearch einen interessanten Ansatz: Jede Änderung wird automatisch committet, jedes Ergebnis protokolliert, jede Entscheidung (keep/discard/crash) ist nachvollziehbar. Dokumentation ist eingebaut, nicht nachträglich aufgesetzt.

Welches LLM funktioniert am besten?

AutoResearch ist modellunabhängig. Latent Space berichtete, dass Claude Opus 4.6 über 12 Stunden durchgehend lief und 118 Experimente ohne Loop-Abbruch abschloss. GPT-5.4 im Extended-Thinking-Modus hatte Schwierigkeiten, kontinuierliche Loops über lange Sitzungen aufrechtzuerhalten.

Für die meisten Single-GPU-Runs funktioniert jedes Modell der Claude-Sonnet/Opus-Familie oder GPT-4-Klasse.

AutoResearch selbst ausprobieren

Das Setup ist unkompliziert. Man braucht eine einzelne NVIDIA-GPU (das Repo zielt auf H100, aber Community-Forks existieren für RTX-Karten unter Windows, Mac Mini M4 und AMD-GPUs), Python 3.10+ und den UV-Paketmanager.

git clone https://github.com/karpathy/autoresearch
cd autoresearch
uv sync
python prepare.py  # Trainingsdaten herunterladen und tokenisieren

Dann den bevorzugten KI-Coding-Agenten auf program.md richten und laufen lassen. Der Standard-Trainingsdatensatz funktioniert sofort. Für Maschinen mit weniger VRAM empfiehlt die Community TinyStories als Trainingskorpus.

Etwa 60% der Experimente werden fehlschlagen oder abstürzen, besonders am Anfang. Das ist beabsichtigt. Der Agent probiert aggressive Modifikationen, lernt aus Abstürzen und grenzt sich schrittweise auf produktive Änderungen ein. Ein Nutzer dokumentierte einen Mac-Mini-M4-Run, bei dem 26 von 35 Experimenten scheiterten, aber die 7 erfolgreichen zeigten, dass “das Modell besser wurde, indem es einfacher wurde.”

Häufig gestellte Fragen

Was ist Karpathys AutoResearch?

AutoResearch ist ein Open-Source-Tool von Andrej Karpathy, das einem KI-Agenten erlaubt, autonom ML-Forschungsexperimente auf einer einzelnen GPU durchzuführen. Der Agent liest ein 630-Zeilen-Python-Trainingsskript, schlägt Modifikationen vor, führt 5-Minuten-Experimente durch und behält oder verwirft Änderungen basierend auf einer einzigen Validierungsmetrik. Es erreichte 48.000 GitHub-Sterne innerhalb von zwei Wochen nach der Veröffentlichung im März 2026.

Welche Ergebnisse hat AutoResearch erzielt?

In Karpathys eigenem Run fanden 700 Experimente über zwei Tage 20 stapelbare Verbesserungen, die die GPT-2-Trainingszeit um 11% reduzierten. Shopify-CEO Tobi Lutke nutzte dasselbe Muster, um Liquid-Rendering 53% schneller zu machen bei 61% weniger Objektallokationen. SkyPilot skalierte es auf 16 GPUs und führte 910 Experimente in 8 Stunden für etwa 300 Dollar durch.

Welche Hardware braucht man für AutoResearch?

AutoResearch wurde für eine einzelne NVIDIA-GPU entworfen, ursprünglich auf H100 getestet. Community-Forks unterstützen RTX-Karten unter Windows, Mac Mini M4 und AMD-GPUs. Zusätzlich braucht man Python 3.10+ und den UV-Paketmanager. Kleinere GPUs können TinyStories statt des Standard-Datensatzes verwenden.

Wie unterscheidet sich AutoResearch von AutoML?

Traditionelles AutoML durchsucht vordefinierte Parameterräume (Lernraten, Schichtanzahlen). AutoResearch nutzt ein LLM, das echten Python-Code liest, versteht was jede Komponente tut und neuartige Modifikationen vorschlägt, die keine Rastersuche finden würde. Der Agent entdeckte Architekturfehler wie einen fehlenden Skalierungsmultiplikator in QKNorm.

Kann AutoResearch auch für Nicht-ML-Aufgaben eingesetzt werden?

Ja. Das Karpathy-Loop-Muster funktioniert für jedes Problem mit einer editierbaren Datei, einer testbaren Metrik und einem festen Zeitbudget. Shopify nutzte es für Produktions-Liquid-Template-Optimierung. Andere haben es auf Seitenladezeit angewendet, und ein PM nutzte das Muster, um die Landing-Page-Conversion von 41% auf 92% in vier Runden zu verbessern.