- Von KI erzeugte CUDA-C-Kernel erreichen eine ähnliche oder bessere Leistung als die von PyTorch-Experten optimierten Kernel
- Ein einzelnes LLM (Large Language Model) wiederholt die Generierung von Optimierungsideen in natürlicher Sprache und verschiedenes Code-Branching und erzielt damit gegenüber bestehenden Methoden eine überlegene Vielfalt der Optimierungen sowie parallele Suche
- Repräsentative Benchmark-Ergebnisse zeigen gegenüber PyTorch eine klare Überlegenheit bei Matmul (101 %), Conv2D (179,9 %), Softmax (111,8 %), LayerNorm (484,4 %), Conv2D+ReLU+MaxPool (290,1 %)
- Um die Grenzen der bisherigen „sequentiellen Kernel-Verbesserung“ zu überwinden, wurde eine Struktur aus natürlichem Sprachschlussfolgern + Branching eingesetzt, die schnell hochperformante Kernel erzeugt
- Auch bei modernen ML-Workloads wie FP16 und Flash Attention gibt es Fortschritte; langfristig deutet sich ein Paradigma an, in dem KI selbstständig schnellere Kernel sucht und verbessert
TL;DR Zentrale Ergebnisse
- Das Forschungsteam von Stanford CRFM hat Beispiele gefunden, bei denen von KI erzeugte hochperformante CUDA-C-Kernel ähnliche oder bessere Geschwindigkeiten erreichen als die bestehenden, von Experten entwickelten Kernel in PyTorch
- Ursprünglich sollte über synthetische Daten ein besseres Modell zur automatischen Kernel-Erzeugung trainiert werden, doch schon bei der Erzeugung dieser synthetischen Daten wurde beobachtet, dass automatisch überraschend schnelle Kernel entstanden
- Daher wurden Methode, Performance-Benchmarks, Optimierungsstrategien und die weitere Richtung frühzeitig veröffentlicht
- Benchmark: Nvidia L40S GPU. Leistung (%): Laufzeit von PyTorch ÷ Laufzeit des erzeugten Kernels
- Matmul (FP32): 101,3 % von PyTorch (4096x4096-Matrix)
- Conv2D: 179,9 % (Eingabe: 100, 3, 224, 224; AlexNet Conv1-Spezifikation)
- Softmax: 111,8 % (4096x65536-Tensor)
- LayerNorm: 484,4 % (16, 64, 256, 256-Tensor)
- Conv2D + ReLU + MaxPool: 290,1 % gegenüber der PyTorch-Referenz, 189,0 % gegenüber
torch.compile()
Forschungsmotivation und Methode
- Das ursprüngliche Ziel war die Erzeugung synthetischer Daten zum Training eines Kernel-Generierungsmodells, doch im Verlauf der Experimente erreichten die selbst erzeugten Kernel eine unerwartet hohe Performance
- Nutzung von KernelBench (offener Stanford-Benchmark, veröffentlicht im Dezember 2024)
- Für gegebenen
torch-Code schreibt das LLM einen neuen Kernel mit optimaler Geschwindigkeit
- Die Korrektheit wird über numerische Äquivalenz von Ein- und Ausgaben geprüft
- Bisheriger Ansatz: ein sequentieller Änderungs-Loop, bei dem der Kernel schrittweise leicht angepasst und nach und nach verbessert wird
- Nachteil: geringe Ideenvielfalt, Wiederholung derselben Optimierungen, Konvergenz zu lokalen Optima
- Verbesserungsansatz
- Optimierungsideen werden in natürlicher Sprache entwickelt und festgehalten, danach werden mehrere Code-Implementierungszweige dieser Ideen gleichzeitig erzeugt
- In jeder Runde laufen mehrere Optimierungsversuche parallel → der leistungsstärkste Kernel dient als Seed für die nächste Runde
- So werden innerhalb begrenzter Suchiterationen verschiedene Optimierungsstrategien und parallele Suche möglich
Beispiele für Optimierungsideen
- Optimierung des Speicherzugriffs: bessere Nutzung der Hierarchie aus global/shared/register memory
- Asynchrone Verarbeitung und Verbergen von Latenz: Überlappung von Berechnung und Datenbewegung
- Optimierung von Datentypen/Präzision: Nutzung von FP16/BF16 und hardwarespezifischen Operationen
- Berechnungs- und Instruktionsoptimierung: Optimierung von Rechenmenge, Anzahl der Instruktionen und hardwarespezifischen Spezialbefehlen
- Parallelität und Occupancy: maximale Auslastung der SMs (Streaming Multiprocessors)
- Optimierung von Schleifen/Verzweigungen/Indexierung: weniger Schleifen, Entfernen unnötiger Indexoperationen
Tatsächlicher Ablauf der Kernel-Optimierung (Beispiel Conv2D)
- Verlauf von Optimierungsideen und Performance-Verbesserungen pro Runde
- Start (Runde 0): einfacher CUDA-Port (20 % der Geschwindigkeit von PyTorch)
- Nächste Runden: → Nutzung des Read-Cache → FP16-Tensor-Core-Berechnung (GEMM-Umwandlung) → Double Buffering/Pipeline → Vorberechnung von Indizes/Shared Memory → Vektorisierung → gleichzeitiges Buffering der K-Schleife usw. mit fortgeschrittener Nutzung der GPU-Architektur
- Finale Version (Runde 13): 179,9 % Performance gegenüber PyTorch
- Der tatsächliche Code nutzt in großem Umfang fortgeschrittene CUDA-Programmiertechniken
- In jeder Runde werden neue Ideen in natürlicher Sprache erzeugt, mehrere Implementierungen parallel ausprobiert und der beste Code ausgewählt
Takeaways und Implikationen
- KI-basierte Kernel-Erzeugung kann mit einem starken Such-Loop und der Kombination vielfältiger, sprachbasierter Optimierungsideen das Niveau menschlicher Experten übertreffen
- Bei einigen modernen Operatoren (FP16 matmul, Flash Attention) liegt die Performance derzeit noch unter PyTorch
- FP32-Berechnungen sind auf aktueller Hardware im Vergleich zu FP16/BF16 relativ weniger optimiert → dadurch ist in diesem Bereich ein Performance-Vorsprung möglich
- Selbst unter begrenzten Such-Token (insgesamt 7 Millionen Ein-/Ausgabe-Token) wurden kontinuierliche Leistungssteigerungen bestätigt
- Jüngere Forschung wie AlphaEvolve und Gemini 2.5 Pro deutet ebenfalls darauf hin, dass Suche auf Basis massiven Branchings und Verifikation auch ohne Retraining drastische Performance-Verbesserungen ermöglichen kann
- Künftig dürfte dieser Ansatz synthetische Daten und hochperformante Kernel in großem Umfang erzeugen und sich zu einem selbstverbessernden KI-Loop weiterentwickeln
Fazit
- Die KI-basierte automatische Erzeugung und Optimierung von Kerneln hat bereits das Niveau von handoptimiertem Expertencode erreicht; in naher Zukunft erscheint ein selbstverbesserndes KI-System aus Modell + Branching-Suche + Verifikation realistisch
- Es zeichnet sich ab, dass KI die Performance-Grenzen von Frameworks wie PyTorch und TensorFlow eigenständig überschreiten könnte
Anhang: Vollständiger Conv2D-Kernel-Code
- Enthalten sind die vollständigen Funktionen und der gesamte Quellcode des Kernels (detaillierter Code hier ausgelassen)
- Wichtige Merkmale im Code:
- Vektorisierung im Shared Memory, hierarchisches Double Buffering in der K-Dimension, CUDA WMMA, Warp-Level-Output-Buffer usw.
- dynamische Indexberechnung in Echtzeit, Bias-Verarbeitung, gleichzeitiges Laden verzögerter Daten innerhalb der K-Schleife usw.
- Vollständiger Beispielcode und Beispielkernel sind im GitHub-Repository verfügbar
2 Kommentare
Sollte man wohl als eine Art Ensemble-Methode bezeichnen. Wirklich beeindruckend.
Hacker-News-Kommentare
Ich finde die Sichtweise der Autoren auf „AI-Agenten“ ziemlich interessant.
Die meisten Menschen neigen dazu, Agenten wie menschliche Mitarbeitende zu betrachten.
Sie setzen nur wenige Agenten parallel auf, oft sogar nur einen, und lassen jeden in einer Schleife immer nur eine Aufgabe nach der anderen abarbeiten.
Man bleibt damit in einer Welt mit weiterhin fester Personalstärke, Mitarbeitenden, die immer nur eine Sache gleichzeitig tun können, und langsamem Aufgabenwechsel.
Aber so funktionieren LLMs nicht.
Man kann praktisch unbegrenzt Agenten jederzeit nach Belieben erzeugen.
Ob man LLM-Anfragen seriell oder parallel verarbeitet, macht kostenmäßig keinen Unterschied.
Sobald man das verstanden hat, liegt ein Muster nahe, bei dem sich jeder Agent je nach Bedarf in mehrere Unteragenten aufspaltet.
Genau das haben die Autoren hier versucht.
Es wirkt passender, Agenten als „Tasks“ oder „Jobs“ zu betrachten und die Lehren aus Celery oder Sidekiq darauf anzuwenden.
„FP32 wird in modernen ML-Workloads deutlich seltener verwendet, und auf aktueller Hardware ist es im Vergleich zu FP16 oder BF16 auch weniger optimiert. Das könnte einer der Gründe sein, warum sich die FP32-Kernel leichter gegenüber PyTorch verbessern ließen.“
Entwickler haben über Jahre hinweg fast keine Zeit in die Optimierung der fp32-Kernelvarianten investiert.
Wirklich spannend wird es meiner Meinung nach erst dann, wenn sich die Performance von Kerneln steigern lässt, die tatsächlich intensiv entwickelt und real genutzt werden.
Ich denke, diese guten Ergebnisse lassen sich teilweise dadurch erklären, dass NVIDIA keine ausreichend detaillierte Dokumentation zu seinen GPUs bereitstellt.
Bei Prozessoren mit gut dokumentierter Mikroarchitektur können Programmierer oder Compiler deterministisch optimale Programme schreiben, sodass es schwer ist, mit ML/AI über das Auffinden bereits bekannter Lösungen hinaus spektakuläre Verbesserungen zu erzielen.
Bei weniger gut dokumentierten Systemen wie NVIDIA-GPUs braucht man dagegen oft entweder zufällige Suche anhand von Beispielen zuvor optimierter Programme oder Reverse Engineering, um herauszufinden, wie sich die reale Hardware in bestimmten Situationen tatsächlich verhält.
In so einer Lage kann ML/AI Potenzial zeigen und durch das Lernen aus Daten gut geschriebener Programme undocumented behavior erfassen, die selbst für menschliche Programmierer schwer zu finden ist.
Ich frage mich, ob die bereits bekannten Verbesserungen für fp16/bf16-Kernel vielleicht einfach auf fp32 übertragen wurden.
„Heißt das, dass über Jahre hinweg niemand die fp32-Kernel überhaupt angefasst hat?“
Wow, falls das so ist, wäre es wirklich großartig, wenn AI tatsächlich einen neuen Algorithmus in einem Bereich ohne vorgefertigte Lösung hervorgebracht hätte.
Mein Fazit ist, dass dieser Artikel, Googles AlphaEvolve(hier) und die jüngste Nachricht, dass o3 einen Zero Day im Linux-Kernel gefunden hat(hier), zeigen,
dass insbesondere Gemini Pro 2.5 und o3 ein neues Fähigkeitsniveau erreicht haben, auf dem ihnen plötzlich Ideen gelingen, die mit früheren Modellen nicht möglich waren.
Ich glaube nicht, dass plötzlich etwas möglich geworden ist, was vorher unmöglich war.
Vielmehr sind Iteration und Tests praktisch mit einer Geschwindigkeit möglich geworden, die weit über der des Menschen liegt,
und zugleich kann sofort auf große Informationsmengen zugegriffen werden.
Wir sind meiner Ansicht nach an einem Punkt angekommen, an dem die Kombination aus enormer Informationsmenge, Fortschritt und intelligent angewandter Brute Force in manchen Anwendungsfeldern Erfolge erzielt.
Ich denke, die von dir genannten Beispiele und dieses Ergebnis hier haben tatsächlich viele Gemeinsamkeiten.
Im Text heißt es auch: „Die Iterationsschleife zur Testzeit ähnelt eher einer strukturierten Suche mit aktiver paralleler Auswertung auf Basis klarer Optimierungshypothesen als einem interaktiven Chatbot, der nacheinander die Resultate von Codeänderungen prüft.“
Mein Fazit ist, dass man auf Grundlage der Fähigkeiten von LLMs inzwischen gelernt hat,
wie man bei klaren Evaluierungsfunktionen oder bei Lösungssuchräumen mit ähnlichen Mustern den Suchraum deutlich verkleinern kann.
Dass ein Modell ein anderes überholt oder nur ein bestimmtes Modell etwas lösen kann, ist für mich nicht der eigentliche Punkt.
Viel bedeutsamer ist die Realität, dass sich solche Anwendungen nun klar genug zeigen.
Gemini Pro 2.5 fühlte sich für mich wie die erste AI an, die ein Mensch tatsächlich nutzen kann, aber streng genommen hat sie diese Schwelle nur gerade eben überschritten.
Es gibt oft Fälle, in denen die Erfolgsquote unter 20 % fällt.
Wenn 3.0 kommt … dann könnte es langsam ein wenig beängstigend werden.
Moment, wie ist das gemeint? Das hier hat nichts mit dem Linux-Kernel zu tun, sondern mit „Kernels“ im Sinne des GPU-Programmierens.
Hast du vielleicht den ganzen Text missverstanden?
Interessant, aber gibt es dafür auch stärkere Belege? Ein einmaliges Ergebnis allein überzeugt noch nicht ausreichend.
„Der Referenzcode verwendet standardmäßig FP32, und die Toleranz beträgt 1e-02.“
Bei dieser Fehlertoleranz kann man einen „fp32“-Kernel leicht durch fp16-Operationen ersetzen.
Wenn man noch einen Schritt weiterdenkt, war der eigentliche Kern dieser Arbeit vielleicht einfach, möglichst viele fp32-Operationen in diesem Kernel durch fp16 zu ersetzen.
Wie schwierig so eine Portierung in der Praxis wirklich ist, müsste man prüfen,
aber intuitiv wirkt das auf mich nicht besonders beeindruckend.
Falls ich damit falsch liege, sollten die Autoren diesen Punkt klarer behandeln.
Dann wäre das Ergebnis bedeutungslos.
Vielleicht wurde der relative Fehler geprüft.
float32 einfach durch float16 zu ersetzen, ist nicht sinnvoll.
Präzision ist praktisch der einzige Grund, überhaupt float32 zu wählen,
und wenn dieses Merkmal verloren geht, gibt es auch keine sinnvolle Unterscheidung zwischen den Varianten mehr.
Bin ich der Einzige, der beim Titel dieses Artikels zuerst dachte, AI hätte einen OS-Kernel erzeugt?
400 % Geschwindigkeitszuwachs sind schon beeindruckend,
aber noch interessanter ist vor allem die Methodik: Nicht bloß einfache Rechenoptimierung pro Iteration, sondern eine erzwungene Phase sprachlicher Schlussfolgerung, um Vielfalt in der Suche zu erzeugen.
Dass das in der Praxis tatsächlich gut funktioniert hat, macht es besonders spannend.
Für mich wirkt es einfach wie gewöhnliche memetische Evolution.
Wirklich ein interessantes Ergebnis.
Diese Leute scheinen so begeistert gewesen zu sein, dass sie es gleich im Blog veröffentlicht haben.
Vielleicht wollten sie vor einer Publikation auch gezielt Feedback einsammeln.
Ich weiß nicht, ob das wirklich der legendäre Weg zur „self improvement“ ist,
aber solche Resultate wirken durchaus wie Beispiele, die man auf diesem Weg erwarten würde.
Diese Methoden funktionieren nur dann gut, wenn es eine extrem klare Evaluierungsfunktion gibt.
Ein Erfahrungsbericht von mir: Bei einem Replikationsversuch erschien mir der LayerNorm-Kernel numerisch nicht stabil und daher nicht validierbar.
Es wurde nur mit Mittelwert 0 und Standardabweichung 1 getestet, sodass numerical cancellation nicht sofort sichtbar wurde.
Außerdem habe ich später bestätigt gefunden, dass danach eine numerisch stabile Version neu erstellt wurde.
Das halte ich für sehr positiv.
Wirklich ein starkes Ergebnis.
Es wurden o3 und Gemini 2.5 Pro verwendet,
aber leider wird nicht erwähnt, welche Seite den besseren Kernel erzeugt hat.
Interessant wird zu beobachten sein, wie AI-generierter Code größere Bereiche wie fused kernels behandelt.
Zum Beispiel gemm + relu + gemm + normalization und Ähnliches.
So etwas mit einem Tuner komplett zu durchkämmen oder von Hand zu schreiben, ist ziemlich mühsam.
Nur dass es kein OS-Kernel ist, scheint sicher zu sein.