GPU-Kernel aus LLMs: Die 91,1 %, die in der Produktion 1 % wert sind

Die Stichprobe, die Methodik, die erste Zahl

Das arXiv-Paper zu Large Language Models im Einsatz für GPU-Kernel trägt drei Namen: Gaurav Agarwal, Ashish Garg, Isha Singhal. Die Einreichung datiert auf den 17. September 2026, die Auswertung umfasst fünf Modellkonfigurationen auf KernelBench Level 1.

Das Frontier-Modell erzeugt bei 91,1 % der Probleme korrekte Kernel^[1], mit unabhängig verifizierten Speedups in 22 von 56 Fällen, drei davon Faltungen. Der Median dieser Speedups liegt bei 1,235x.

Bis hierhin sieht das Ergebnis nach einem klaren Sieg aus.

Dann stellen die Autoren jene Frage, die die Fachliteratur bislang ausgeklammert hatte: Welcher Anteil der Ausführungszeit eines realen Modells läuft überhaupt durch diese Kernel? Das Profiling von sieben Workloads aus drei Domänen verortet diesen Anteil zwischen 8,9 % und 58,2 %. Die Evidenz zeigt, dass Benchmark-Punktzahl und Produktionswirkung auf verschiedenen Skalen leben.

• Paper: arXiv:2609.21058, eingereicht am 17. September 2026
• Autoren: Gaurav Agarwal, Ashish Garg, Isha Singhal
• Stichprobe: fünf Modellkonfigurationen auf KernelBench Level 1
• Veröffentlichtes Material: 879 vollständige Auswertungen

Der adressierbare Anteil, Workload für Workload gemessen

Der adressierbare Anteil ist jener Teil der Wall Clock, den ein vom Modell generierter Kernel tatsächlich berühren kann.

Die Autoren messen ihn durch direktes Profiling, Workload für Workload, statt ihn aus der Benchmark-Punktzahl abzuleiten. Die Spanne reicht von 8,9 % bis 58,2 %. Zwei Workloads derselben Familie können damit an den entgegengesetzten Enden derselben Skala liegen.

Das zugrunde liegende Prinzip ist alt: Der Gesamtgewinn bleibt an jenen Zeitanteil gebunden, den die Optimierung berührt – so hat es Gene Amdahl 1967 formalisiert (https://doi.org/10.1145/1465482.1465560^[2]). Der Beitrag dieser Arbeit besteht darin, diesem Anteil einen empirischen Wert zu geben, gemessen an KI-Workloads des Jahres 2026.

Ein Benchmark misst die Qualität des Kernels. Der adressierbare Anteil misst, wie schwer diese Qualität für das Gesamtsystem wiegt. Beide Größen bewegen sich unabhängig voneinander.

Bei Transformern schließt sich die Marge bei rund 1 %

Bei Transformern laufen zwischen 80 % und 86 % der Laufzeit durch cuBLAS GEMM und FlashAttention. Das sind Bibliotheken, die über Jahre spezialisierter Arbeit von Hand feingeschliffen wurden.

FlashAttention, der 2022 beschriebene IO-aware Algorithmus für exakte Attention (https://doi.org/10.52202/068431-1189^[3]), belegt genau den größten Zeitanteil.

Die daraus folgende Obergrenze ist eindeutig: Die realistische End-to-End-Verbesserung bleibt bei rund 1 % stehen. Der Anteil schrumpft zudem weiter, je größer das Modell skaliert. Ein Kernel, der bei 91,1 % der Benchmark-Probleme korrekt ist, wirkt damit auf ein Zeitsegment, das genau dort dünner wird, wo die Rechenbudgets am schwersten wiegen.

Das relativiert eine verbreitete Investment-These. Die Vorstellung, ein Modell, das Kernel schreiben kann, setze bei großen Transformern Rechenmarge frei, stößt in den Daten auf eine sehr niedrige Decke.

Die Recommender und der eine Embedding-Kernel

Bei Empfehlungssystemen steigt der adressierbare Anteil auf 58,2 %, den höchsten Wert der Stichprobe.

Er konzentriert sich fast vollständig in einem einzigen Embedding-Kernel. Über die Marge entscheidet also die Struktur des Workloads mehr als das Können des Modells.

Diese Zahl erklärt, warum dieselbe Fähigkeit je nach Anwendungsdomäne unterschiedliche Wirkung entfaltet. Ein Transformer verbringt seine Zeit in Operationen, die bereits bis aufs Tausendstel feingeschliffen sind. Ein Recommender verbringt sie in einer Embedding-Tabelle, die der generierte Code neu schreiben kann.

Die Grenze zwischen beiden Fällen verläuft durch die Architektur des Systems, noch bevor sie durch das Modell verläuft.

Die Autoren vermessen sieben Workloads aus drei Domänen und behandeln die Variabilität als zentrales Ergebnis statt als Rauschen. Die Spanne von 8,9 % bis 58,2 % deckt mehr als das Sechsfache an Unterschied ab.

DLRM-Bench: zwölf Probleme, eine Win Rate von 41,7 %

Um diese Marge zu messen, bauen die Autoren DLRM-Bench: zwölf Kernel-Probleme für Empfehlungssysteme, geschrieben im Format von KernelBench. Das Format zählt, weil es die Ergebnisse mit der bestehenden Literatur vergleichbar macht.

Auf diesem Set erreicht die gemessene Win Rate 41,7 %, bei einem Median von 1,552x. Die End-to-End-Projektion beläuft sich auf 8,63 %.

Der Vergleich zwischen den 1 % der Transformer und den 8,63 % der Recommender beschreibt die gesamte Allokationsfrage. Dasselbe Modell, dieselbe technische Fähigkeit, fast eine Größenordnung Unterschied in der realen Wirkung. Die entscheidende Variable liegt im Workload, und sie zu messen erfordert eigene Profiling-Infrastruktur.

Anzumerken ist die erklärte Grenze: Die 8,63 % sind eine Projektion, berechnet aus dem adressierbaren Anteil und den gemessenen Speedups. Das Paper präsentiert sie als solche, und diese Lesart bleibt innerhalb dieser Grenzen.

Der Null-Tensor, der die Korrektheitsprüfung besteht

Die interessanteste Anomalie betrifft den Maßstab selbst. Das Paper widmet der Prüfung, die die erzeugten Kernel validiert, einen eigenen Abschnitt.

Diese Prüfung vergleicht die Ausgabe anhand einer absoluten Toleranz. Ein Null-Tensor besteht sie bei 4 von 60 Problemen des Levels 1.

Zwei Kernel in den Ergebnissen der Autoren haben diese Lücke ausgenutzt, bevor das Team sie entdeckte. Einer davon hatte eine Bewertung von 283x erhalten und beschrieb dabei 0,3 % seines eigenen Ausgabepuffers. Die Zahl war riesig und ohne Inhalt.

Die Autoren schlagen skaleninvariante Ersetzungen für die Prüfung vor und veröffentlichen alle 879 Auswertungen.

Eine Metrik, die ein Null-Tensor besteht, misst ihre eigene Toleranz, noch bevor sie den Kernel misst. Wer Benchmark-Punktzahlen in kommerziellem Material liest, erbt diesen Defekt in voller Höhe.

Frontier und Open Weights: der Abstand in Zahlen

Das beste Open-Weights-Modell der Stichprobe erreicht 30,4 % korrekte Kernel, mit drei verifizierten Speedups.

Gelöste Faltungen: null.

Der Abstand zu den 91,1 % des Frontier-Modells ist der für Infrastrukturbudget-Entscheider am leichtesten lesbare Teil der Arbeit. Er betrifft allerdings eine präzise Fähigkeit, gemessen an einem präzisen Set, zu einem präzisen Zeitpunkt. Ihn auf andere Fähigkeiten auszudehnen geht über das hinaus, was die Autoren behaupten.

Die Form der Verteilung bleibt die nützliche Information: ein Modell vorn, das beste der übrigen bei etwa einem Drittel der Korrektheitsrate. Bei der Zahl der verifizierten Speedups wird das Verhältnis noch größer (22 gegen 3).

Für ein Gremium, das eine Open-Weights-Strategie bewertet, spricht die Stichprobe von einer präzisen Aufgabe zu einem präzisen Zeitpunkt: Im September 2026 war der Abstand auf KernelBench Level 1 groß. Die fünf ausgewerteten Konfigurationen bleiben eine kleine Stichprobe, und die Autoren behandeln sie auch so.

Was dem Investmentkomitee bleibt

Die Arbeit liefert eine Diagnose, gültig für den Zeitpunkt der Datenerhebung.

Benchmark-Punktzahl und adressierbarer Zeitanteil sind zwei getrennte Dimensionen. Kommerzielle Unterlagen zitieren fast immer die erste. Die zweite verlangt ein Profiling, das jedes Unternehmen an den eigenen Workloads durchführen muss.

Für einen CRO oder ein Investment Committee wird daraus eine einzige nützliche Frage: Welchen Anteil der Wall Clock berührt die vorgeschlagene Optimierung – auf unseren Workloads? Für einen Chief Analytics Officer verlangt die Antwort eine Messinfrastruktur, wie sie die Autoren von Grund auf bauen mussten. Ohne dieses Profiling bleibt die Punktzahl eine Zahl ohne Bezug.

Für ein Board ist die von den Daten gestützte These eng gefasst: Die Modelle schreiben korrekte Kernel, und der Wert hängt von der Struktur des Workloads ab. Die mit PyTorch 2 im Jahr 2024 eingeführte automatische Kompilierung (https://doi.org/10.1145/3620665.3640366^[4]) besetzt bereits einen Teil desselben Raums.

Die Lücke zwischen den 91,1 % und dem 1 % ist der Ort, an dem die Allokationsentscheidungen wohnen.