16-GPU-Skalierung von Karpathys Autoresearch: Ergebnisse & Methoden

Was ist Autoresearch?

Autoresearch ist Andrej Karpathys Projekt, bei dem ein Coding-Agent eigenständig ein Training-Skript für neuronale Netze verbessert. Der Agent bearbeitet train.py, führt ein 5-minütiges Trainingsexperiment auf einer GPU durch, überprüft den Validierungsverlust und wiederholt den Vorgang – behält Änderungen bei, die helfen, verwirft die, die es nicht tun. In Karpathys erstem nächtlichen Durchlauf fand der Agent ~20 Verbesserungen, die sich zu einer 11 %igen Reduzierung der Zeit bis GPT-2 auf dem nanochat-Leaderboard summierten.

Wie Autoresearch funktioniert

Das Projekt umfasst drei Dateien:

prepare.py – Lädt Daten herunter, trainiert einen Tokenizer, stellt den Dataloader und die Evaluierungsfunktion bereit. Schreibgeschützt. Der Agent kann sie nicht verändern.
train.py – Das GPT-Modell, der Optimierer und die Trainingsschleife. Dies ist die einzige Datei, die der Agent modifiziert.
program.md – Anweisungen für den Agenten: was er ändern darf, wie er Ergebnisse bewertet, wann er Änderungen beibehalten oder verwerfen soll.

Die Einschränkung ist ein festes 5-minütiges Training-Budget. Die Aufgabe des Agenten ist es, val_bpb (Validierungsbits pro Byte) innerhalb dieses Zeitfensters zu minimieren. Alles in train.py ist erlaubt – Architektur, Hyperparameter, Optimierereinstellungen, Batch-Größe, Modelltiefe – solange der Code ohne Absturz läuft.

Der Engpass: Eine GPU, ein Experiment

Wenn Experimente sequentiell ausgeführt werden, verbringt der Agent die meiste Zeit mit Warten. Ein typischer Zyklus sieht so aus:

Agent bearbeitet train.py (~30 Sekunden)
Training läuft (~5 Minuten)
Agent liest das Ergebnis, plant das nächste Experiment (~30 Sekunden)

Schritt 2 dominiert. Während Schritt 2 ist der Agent inaktiv – er könnte das nächste Experiment oder die nächsten zehn vorbereiten. Bei sequentieller Ausführung bedeutet das Testen von Parameterkombinationen, weitere 5 Minuten für jeden Test zu warten.

Dem Agenten Cloud-GPUs geben

Das Team nutzte SkyPilot, ein Open-Source-Tool, das Jobs über Clouds und Kubernetes aus einer YAML-Datei startet. Es enthält eine Fähigkeit, die Coding-Agenten beibringt, es zu verwenden. Der Agent liest die Fähigkeit und startet und verwaltet dann GPU-Cluster eigenständig – ohne manuelle Cloud-Einrichtung.

Jedes Experiment wird in einer kurzen YAML-Datei (experiment.yaml) definiert, die den GPU-Typ angibt, Abhängigkeiten installiert, train.py ausführt und Metriken auf stdout ausgibt. Der Agent überprüft Ergebnisse mit sky logs.

Ergebnisse: ~910 Experimente, ~8 Stunden, 16 GPUs

Claude Code nutzte die SkyPilot-Fähigkeit, um GPU-Experimente über 16 GPUs zu starten und zu verwalten. In 8 Stunden reichte er ~910 Experimente ein und senkte val_bpb von 1,003 auf 0,974 – eine 2,87 %ige Verbesserung gegenüber der Basislinie.

Wie Parallelität die Forschungsstrategie des Agenten veränderte

Mit einer GPU betreibt der Agent gieriges Hill-Climbing – etwas ausprobieren, prüfen, wiederholen. Mit 16 GPUs führte er faktorielle Gitter mit 10–13 Experimenten pro Welle durch und erfasste Wechselwirkungen zwischen Parametern, die sequentielle Suche verpassen würde.

Zum Beispiel testete der Agent sechs Modellbreiten in einer einzigen Welle, erkannte den Trend sofort und konzentrierte sich auf die beste – eine Runde statt sechs.

Der Agent entdeckte auch, dass er Zugriff auf mehrere GPU-Typen (H100s und H200s) hatte, und entwickelte eine Strategie, um den Leistungsunterschied auf heterogener Hardware auszunutzen: Ideen auf günstigeren H100s screenen, Gewinner zur Validierung auf H200s befördern.

Leistungsvergleich

Mit 16 GPUs erreichte der parallele Agent den gleichen besten Validierungsverlust 9-mal schneller als die simulierte sequentielle Basislinie (~8 Stunden vs. ~72 Stunden).