In den vergangenen Monaten haben wir ein Multi-Agenten-System entwickelt, das komplexe Software autonom erstellen, warten und bereitstellen kann. Im Rahmen dieser Arbeit haben wir das System in ganz unterschiedlichen Bereichen erprobt – unter anderem, indem wir es einen Browser von Grund auf entwickeln ließen und im Benchmark First Proof ein mathematisches Problem auf Forschungsniveau lösen ließen.

Vor Kurzem haben wir gemeinsam mit NVIDIA an einer neuen Herausforderung gearbeitet: unser Multi-Agenten-Harness auf die Optimierung von CUDA-Kerneln anzusetzen. Das sind anspruchsvolle technische Probleme mit wichtigen praktischen Auswirkungen: CUDA-Kernel sind die zentrale Software, die das Training und die Inferenz von KI-Modellen auf NVIDIA-GPUs ermöglicht. Schnellere Kernel bedeuten eine bessere GPU-Auslastung, geringeren Energieverbrauch, niedrigere Latenz und geringere Kosten pro Token – sodass Anbieter größere, leistungsfähigere Modelle gleichzeitig für mehr Benutzer bereitstellen können.

Unser Multi-Agenten-Harness arbeitete drei Wochen lang autonom an 235 Problemen. Das System erreichte eine geometrisch gemittelte Beschleunigung von 38 %, indem es Blackwell-GPU-Kernel von Grund auf erstellte und optimierte – bis hinunter auf die Assembly-Ebene.

Solche Leistungssteigerungen lassen sich normalerweise nur durch monate- oder jahrelange Arbeit sehr erfahrener Kernel-Ingenieure erzielen. Das Multi-Agenten-System schaffte dies in wenigen Wochen und bearbeitete dabei einen Long Tail von Kernel-Problemen, die mit bestehenden Ansätzen bislang unpraktikabel waren.

#Kernel-Optimierung als Test für die Fähigkeiten von Agent-Systemen

Eine der besten Möglichkeiten, langlaufende Multi-Agenten-Systeme zu bewerten, besteht darin, ihnen offene Optimierungsprobleme zu geben, bei denen selbst wir die richtige Antwort nicht kennen. Kernel-Optimierungsprobleme erfüllen dieses Kriterium: Sie bieten messbare Ziele, an denen das System sich iterativ optimieren kann, statt auf einen einfachen, bekannten Diff hinzuarbeiten.

Heute optimieren Ingenieure Kernel, indem sie Modelle in einzelne mathematische Operationen zerlegen und jede davon separat abstimmen. Das macht das Problem handhabbar, lässt aber Leistungspotenzial ungenutzt, weil eine schrittweise Optimierung mögliche Gewinne übersieht, die sich aus einer gleichzeitigen Optimierung des gesamten Systems ergeben könnten. Bislang war die GPU-Leistung dadurch begrenzt, dass wir den gesamten Lösungsraum jenseits dieser manuellen Vereinfachungen nicht vollständig erkunden konnten.

Mit diesem Experiment wollten wir herausfinden, ob unser Multi-Agenten-System außerhalb dieser Einschränkungen arbeiten, einen breiteren Lösungsraum erkunden und so schnellere Kernel hervorbringen kann.

#SOL-ExecBench für Problemgenerierung und Benchmarking

NVIDIA nutzte SOL-ExecBench, um 235 Optimierungsprobleme aus über 124 produktionsreifen Open-Source-Modellen wie Deepseek, Qwen, Gemma, Kimi und Stable Diffusion zu generieren. Im Gegensatz zu synthetischen Daten oder vereinfachten Kernels bildet jedes Problem einen realen Engpass in Trainings- oder Inferenz-Workloads für eine Vielzahl von Modellarchitekturen ab: LLMs, Diffusions-, Vision-, Audio-, Video- und multimodale Hybridmodelle.

Wir haben außerdem SOL-ExecBench genutzt, um Multi-Agent-Kernel-Lösungen auf 27 NVIDIA Blackwell 200 GPUs zu benchmarken. SOL-ExecBench ist ein effektives Auswertungstool, das die Kernel-Performance mit bestehenden Software-Baselines und den theoretischen Hardware-Leistungsgrenzen vergleicht. Wenn Agenten Tricks wie Caching nutzen und eine Performance liefern, die über das hinausgeht, was ein B200 leisten kann, verwirft die Pipeline das Ergebnis.

#So haben wir das Experiment durchgeführt

Das Multi-Agenten-System löste alle 235 GPU-Kernel-Optimierungsprobleme in einem einzigen Durchlauf, indem es einen Planner-Agenten einsetzte, der die Arbeit anhand von Leistungsmetriken auf autonome Worker verteilte und neu ausbalancierte.

Das gesamte Koordinationsprotokoll war in einer einzigen Markdown-Datei festgehalten, die Ausgabeformat, Regeln und Tests festlegte. Das Multi-Agenten-System lernte eigenständig, während seiner Durchläufe die Benchmarking-Pipeline aufzurufen, wodurch ein Kreislauf entstand, in dem das System Kernel kontinuierlich testete, Bugs behob und optimierte — ganz ohne Eingreifen von Entwicklern.

Um die Fähigkeiten des Multi-Agenten-Systems besser einschätzen zu können, baten wir es, seine Lösungen in zwei Sprachen in zwei separaten Durchläufen zu schreiben, an den entgegengesetzten Enden des GPU-Abstraktionsspektrums:

• CUDA C with inline PTX, das Agenten direkten Zugriff auf Register und ISA-Anweisungen gibt und damit testet, ob das System Hardware auf der niedrigsten Ebene verstehen kann.
• CuTe DSL, das hochgradig kombinierbare Abstraktionen auf hoher Ebene mit nur minimaler Präsenz in öffentlichen Trainingsdaten bereitstellt und damit testet, ob das System neue APIs ausschließlich anhand der bereitgestellten Dokumentation erlernen kann.

#38 % Beschleunigung, wobei 19 % der Optimierungen mehr als 2× erreichen

Wir geben die Leistung des Multi-Agenten-Systems auf zwei Arten an:

• geometrisch gemittelte Beschleunigung im Vergleich zu PyTorch-Code, der als Baseline von einem einzelnen Agenten optimiert wurde.
• Speed-of-Light-(SOL)-Scores, die auf einer logarithmischen Skala angeben, wie gut eine Lösung im Vergleich zu den theoretischen Hardwaregrenzen ist. Ein Score von 0,5 steht für die optimierte PyTorch-Baseline, und 1,0 ist die Leistungsgrenze.

Unser Multi-Agenten-System übertraf bei 149 von 235 Problemen (63 %) die Baselines, mit einem geometrischen Mittel von 1,38x (geometrisch gemittelte Beschleunigung um 38 %).

Bei 45 von 235 Problemen (19 %) erzigte das Multi-Agenten-System im Vergleich zu den Baselines Optimierungen von mehr als 2x. Du kannst die endgültigen Lösungen, die unser System entwickelt hat, in diesem öffentlichen Repo sehen.

#Verschiedene Optimierungsstrategien für unterschiedliche Probleme

Um zu zeigen, wie anpassungsfähig das System bei verschiedenen Problemtypen ist, heben wir drei Probleme hervor, bei denen es auf ganz unterschiedliche Optimierungsstrategien gekommen ist.

#BF16 Grouped-Query-Attention mit paginiertem Prefill

Grouped-Query-Attention mit paginiertem Prefill ist eine gängige Operation in der Prompt-Phase moderner LLM-Inferenz-Stacks. Eine gut optimierte Implementierung kann bei gleichem GPU-VRAM längere Kontexte, höhere Parallelität und besseren Durchsatz ermöglichen.

Der Agent nutzte CUDA C++, um dieses aus der SGLang-Inferenz für Llama 3.1 8B extrahierte Attention-Problem zu optimieren. Während der Agent den Kernel weiter iterierte, setzte er erfolgreich spezifische Hardware-Instruktionen für Speicherzugriffe und mathematische Operationen ein, ergänzte verbessertes Scheduling über persistente Kernel und optimierte die Implementierung gezielt für die Eingabegröße.

Wir verglichen den benutzerdefinierten Kernel des Multi-Agenten-Systems mit einer von Menschen optimierten Baseline in der FlashInfer-Bibliothek. Wir stellten fest, dass das System eine Lösung hervorbrachte, die mit einem SOL-Score von 0.9722 an die Hardwaregrenzen heranreichte und einer geometrisch gemittelten Beschleunigung von 84 % gegenüber der Baseline entspricht.

Wir ersetzten außerdem den vorhandenen Kernel in SGLang und beobachteten bei Llama 3.1 8B eine um 3 % kürzere Time to First Token (TTFT). Da dieses Attention-Problem je nach Serving-Konfiguration 2–5 % des Prefill-Prozesses ausmacht, werten wir dies als nicht triviale End-to-End-Beschleunigung.

#NVFP4-MoE-Linear mit Gating

Dieses Problem steht für ein häufiges Zwei-Kernel-Muster, das in Mixture-of-Experts-Modellen wie Qwen3 vorkommt, mit der Besonderheit, dass der Eingabe-Tensor und das Zwischenergebnis der Multiplikation auf NVFP4 (4-Bit-Gleitkomma) quantisiert sind.

Der Agent identifizierte den Quantisierungsbereich korrekt als primären Engpass und führte daher die Skalierungsberechnung und das Runden zusammen. Anstatt bei der Quantisierung erst zu skalieren und dann zu runden, nutzte er vorab berechnete Schwellenwert-Buckets, um FP32-Werte direkt auf FP4-Codes abzubilden. Das ist möglich, weil es nur 16 mögliche NVFP4-Werte gibt. Anschließend wandte er diese Optimierungen auf größere Testfälle an.

Der Agent übertraf schließlich die optimierte PyTorch-Baseline und erzielte eine geometrisch gemittelte Beschleunigung von 39 % sowie einen SOL-Score von 0,58.

#BF16-Matrixmultiplikation

Die Matrixmultiplikation ist bekanntermaßen schwer zu optimieren, weil sie ein tiefes Verständnis der verschiedenen Hardwareeinheiten und ihrer Ablaufplanung erfordert. Wirklich hochperformante Matrixmultiplikations-Kernel (GEMMs) erfordern Inline-PTX (vergleichbar mit Assemblersprache), Pipelining und Staging innerhalb eines Kernels. Deshalb blieb die Entwicklung schneller GEMMs lange Zeit hoch erfahrenen Kernel-Experten vorbehalten.

Das Cursor Multi-Agenten-System generierte von Grund auf einen spezialisierten CUDA-C++-GEMM-Kernel und kam damit erstaunlich nah (86 %) an eine von Menschen akribisch optimierte Baseline aus der NVIDIA-cuBLAS-Bibliothek heran. Das System erzielte dieses Ergebnis, indem es eigenständig lernte, Blackwell-spezifische Instruktionen zu nutzen, Speicherzugriffe auf die Hardware zu optimieren und anschließend exakt auf die jeweiligen Dimensionen hin zu hyperoptimieren.

Und bei Testfällen mit kleinem M, die für die Dekodierphase der LLM-Inferenz besonders wichtig sind, übertraf der Kernel des Multi-Agenten-Systems die Bibliothek um bis zu 9 %. Dieses Ergebnis deutet darauf hin, dass Multi-Agenten-Systeme schon bald selbst bei den schwierigsten Kernel-Problemen Fachexperten übertreffen werden.

#Ein Multi-Agenten-System zur Softwareentwicklung

Während das Multi-Agenten-Harness gegenüber den Baselines eine geometrisch gemittelte Beschleunigung von 38 % erzielte, lag der mediane SOL-Score immer noch nur bei 0,56, sodass weiterhin erheblicher Spielraum für weitere Optimierungen bestand. Wir glauben, dass sich Multi-Agent-Lösungen mit mehr Rechenleistung deutlich verbessern lassen, da wir Hunderte von Problemen und Agenten auf nur 27 GPUs ausführen mussten. Das schränkte unsere Möglichkeiten ein, das Multi-Agenten-System voll auszuschöpfen. Mit mehr GPUs könnte das System noch tiefergehende und noch neuartigere Lösungen erkunden.

Die ambitioniertesten Aufgaben in der Softwareentwicklung sind ergebnisoffen und haben keine eindeutige Lösung. Single-Agent-Systeme tun sich hier schwer, weil Modelle am besten für eng umrissene Aufgaben geeignet sind, die sie bereits im Training gesehen haben. Wir sehen das Kernel-Optimierungsexperiment als weitere Bestätigung dafür, dass Multi-Agent-Architekturen schnell zum Standardansatz für die Softwareentwicklung werden, weil sie neuartige Probleme angehen können, die weit außerhalb der Verteilung der Trainingsdaten liegen.

Die Techniken, die wir hier erforschen, werden bald in das Kernprodukt von Cursor einfließen. Wenn du daran interessiert bist, an schwierigen Problemen der Multi-Agent-Koordination zu arbeiten, freut sich das Cursor-Team darauf, von dir unter hiring@cursor.com zu hören.