Ein Red-Hat-Paper von September 2026 hetzt ein Fünf-Agenten-LLM-System auf GPU-Kernels — und die Geschichte ist nicht der Headline-Speedup, sondern wie schnell der Headline verblasst, wenn die Probleme schwerer werden. KernelOPT: Dispatch-Aware Agentic Search for GPU Kernel Optimization (Poddar, Prasad, Samanta, Chakraborty und Kollegen bei Red Hat, arXiv:2609.30059, cs.DC, eingereicht am 24. September 2026) berichtet geometrische Mittel der Speedups über torch.compile von 1,40× auf KernelBench Level 1, 1,15× auf Level 2 und 1,07× auf Level 3 — über alle Probleme pro Level, mit den Optimierungszahlen 51/100, 31/100 und 12/50 direkt daneben in Klammern1. Liest man diese Zähle als Teil des Headlines, wird die Kurve zum Befund: Die Passraten pro Problem fallen von 71 % (51 optimiert + 20 gematcht) auf 66 % auf 30 %, und parallel fällt der erreichte Speedup des gelösten Restes1.
Das ist die ehrliche Art, wie dieses Ergebnis kursieren sollte — und zu Papier's Kredit tut es das weitgehend: Outcome-Kategorien werden explizit berichtet, Fallbacks erhalten per Design die 1,0×-Compiler-Baseline, und das eigene Geomean über alle 250 Probleme ist mit 1,23× niedriger als jeder Level-Headline — exakt das Muster, das ein passraten-gewichtetes Verblassen erzeugt. Was dieser Guide hinzufügt, ist die Arithmetik: welchen Nenner die Zahlen verwenden, wie das Verblassen aussieht, wenn man effektiven Speedup gegen Passrate stellt, die Amdahl-artige Obergrenze, die das Bewahren der Vendor-Libraries aufzwingt (61 von 85 Fallbacks sind reine cuBLAS/cuDNN-Dominanz — der strukturelle Grund, warum Level 3 so wenig gewinnt), und warum die vierstufige Verifikationskaskade des Papers — besonders die Modell-Prüfung mit float64-Fallback — der Teil ist, der die Benchmark-Zahlen am längsten überleben wird.
1. Was KernelOPT ist: strukturbewusst, kein Black-Box
Die Hintergrund-Tatsache, aus der alles folgt: Ein von PyTorch Inductor kompiliertes Modell ist kein einzelner Kernel. Es ist ein strukturiertes Artefakt, in dem der Compiler bereits Dispatch-Entscheidungen getroffen hat — cuBLAS für GEMM, cuDNN für Faltung, Triton für die punktweisen und Reduktions-Operationen dazwischen1. Die Dispatch-Entscheidungen des Compilers für Libraries sind typischerweise korrekt; suboptimal ist die Qualität des verbleibenden Triton-Codes. Frühere LLM-Kernel-Optimierer (KernelAgent, AccelOpt, K-Search) behandeln ein Modell meist als Black-Box und optimieren Kernels einzeln — ohne die Dispatch-Entscheidungen zu respektieren und ohne das wieder zusammengesetzte Modell Ende-zu-Ende zu verifizieren1.
KernelOPT nimmt die Struktur ernst. Im Multi-Kernel-Modus läuft torch.compile mit max_autotune, die Extern-Library-Aufrufe werden per Regex über den Inductor-Output erkannt, als needs_triton_replacement: False markiert und nie angefasst. Die fünf Agenten — Planner, Executor, Summarizer (die AccelOpt-Triad2), plus ein Profiler-Agent und ein deterministischer Strategie-Analyst — arbeiten ausschließlich an den Triton-generierten Sub-Kernels und an fusionierbaren Gruppen davon. Der Profiler fährt NVIDIA Nsight Compute mit --set full und Kernel-Replay und destilliert den Report zu Speed-of-Light-Durchsatz, Dauer, Registerdruck, Occupancy und den Top-3-NCU-Regeln nach geschätztem Speedup; der Strategie-Analyst klassifiziert die Bottleneck-Stufe deterministisch (near-optimal, wenn ein SOL über 80 % liegt, memory-bound, compute-bound oder underutilized)1. Der Planner schlägt bis zu N Pläne pro Iteration in einer Beam-Search vor (UCB mit c = 1,4) über einen gewurzelten Baum von Kernel-Zuständen; der Executor erhält Compile-Fehler und Korrektheitsfehler als Feedback im selben Dialog mit bis zu K retries; ein Meltdown-Detektor erzwingt Diversität, wenn die letzten sechs Planrichtungen auf zwei oder weniger einzigartige Ansätze kollabieren1. Die Hyperparameter sind über alle 250 Probleme fix ohne Tuning pro Level: T = 5 Iterationen, N = 4 Pläne, K = 4 Retries, Beam-Breite B = 4 — auf einer einzelnen H200 mit Claude Sonnet 4.6, insgesamt rund 1.100 GPU-Stunden, einzelne Modelle von 6 Minuten bis 66 Stunden1.
Warum cuBLAS und cuDNN fixieren, statt das LLM auch sie neu schreiben zu lassen? Weil die Alternative gemessen wurde und schlecht ist. Die Ablationsstudie entfernt genau eine Komponente auf 50 gesampelten Problemen: Ohne Beam-Search oder NCU-Profiling fällt der Optimierungserfolg von 38 % auf 10 %, ohne Perf-Gate auf 6 % — und ohne Inductor-aware Synthese (nur auf Level 2) auf null von 20, weil das LLM jeden Versuch an hand-getunten Vendor-Library-Aufrufen verbrennt und „pervasive Regressions“ produziert1. Die Schlussfolgerung, die das Paper selbst daraus zieht, ist exakt richtig und erfrischend anti-hype: Die Wirksamkeit beruht auf struktureller Orchestrierung, nicht auf der rohen Coding-Fähigkeit des LLMs.
2. Die vierstufige Kaskade: warum die Fallback-Baseline überlebt
Die Verifikationsfunktion ist das Herz des Papers. Formal ist das Problem ein argmin über den (unhandhabbaren) Raum syntaktisch valider Triton-Programme der Kernel-Laufzeit, unter einer Verifikationsprädikat-Bedingung — und entscheidend: * Wenn kein Kandidat das Prädikat erfüllt, liefert das System die Compiler-Baseline unverändert zurück1. Das Prädikat ist die Konjunktion von vier Gates, sequenziell angewendet:
- Statische Validierung — ein Probelauf fängt Syntaxfehler und Crashes ab, bevor irgendein numerischer Vergleich stattfindet.
- Multi-Seed-Korrektheit — drei Zufallssamen,
allclosebei rtol/atol 10^-3 gegen die eager-PyTorch-Referenz, locker genug, um valide TF32-Kandidaten während der Suche zuzulassen; Fehler gehen direkt als Fehlermeldungen im Dialog an den Executor zurück. - Modell-Ebene-Korrektheit (V_model) — nach der Optimierung wird das wieder zusammengesetzte Gesamtmodell Ende-zu-Ende auf der strengeren 10^-4-Toleranz geprüft, mit dem float64-Fallback, auf den dieser Guide in Abschnitt 5 kommt. Weil Inductor Modell-Parameter als explizite Kernel-Argumente externalisiert, würde ein naiver Eingabe-Generator die Gewichte mit Zufallswerten füllen und sinnlose Ausgaben erzeugen; KernelOPT fängt die exakte flache Argumentliste mit einem Backend-Capture-Trick ab, sodass echter Modell-Zustand durch die Verifikation fließt1.
- Performance-Gate (V_perf) — die Wallclock-Zeit des wieder zusammengesetzten Modells muss bei oder unter gamma = 1,03 der kompilierten Baseline liegen, gemessen mit prozess-isoliertem
do_bench(25 ms Warmup, 100 ms Rep), damit CUDA-Zustand nicht zwischen Messungen leaken kann1.
Gate 4 ist die Komponente, die den meisten Systemen dieser Linie fehlt, und das Paper zeigt ihre Notwendigkeit konkret: Alle 15 Zurückweisungen durch das Level-1-Performance-Gate waren Kernels, die per Kernel wirklich schneller waren — bis zu 5,84× per-Kernel-NCU-Verbesserung auf Kernel 049 — aber als Modell marginal langsamer, weil das Ersetzen eines Inductor-gefusionierten Pfades durch einen eigenständigen Triton-Kernel Dispatch-Overhead zurückbringt. Ohne das Gate wären diese 15 als „Verbesserungen“ durchgegangen. Mit ihm werden sie ehrliche Fallbacks1. Das ist die ganze Design-Philosophie in einem Gate: besser, die Antwort des Compilers zurückzugeben, als einen Gewinn zu melden, den eine Ende-zu-Ende-Messung widerlegt.
3. Der Headline, geprüft: welcher Nenner, und was das Verblassen bedeutet
Das Abstract nennt die Geomeans „across all problems“ — und die eigenen Outcome-Definitionen des Papers machen das tragfähig statt zur Floskel: Ein Matched-Ergebnis „ersetzt die Baseline und trägt seinen gemessenen Speedup zum geometrischen Mittel bei“, Synthese-Fehler liefern die Inductor-AOT-Baseline zurück, „die der Compiler-Baseline entspricht“, und Fallbacks sind abgelehnte Kandidaten, deren Probleme den 1,0×-Compiler-Output behalten1. Ungelöste Probleme gehen also per Konstruktion mit 1,0× ins Mittel. Die folgende Zelle rekonstruiert alle drei Level-Geomeans aus der eigenen Tabelle 1 des Papers — den Outcome-Zahlen von Panel A plus dem Speedup-Histogramm von Panel B —, um zu bestätigen, welcher Nenner die berichteten Zahlen reproduziert, und legt dann das Verblassen explizit aus.
import math
# Rekonstruiere die berichteten Geomeans aus der eigenen Tabelle 1 des Papers:
# Panel-B-Histogramm der 94 optimierten Kernels (Zahlen pro Level, Bucket-
# Mittelpunkte als Proxies) + Outcome-Zahlen aus Panel A. Ungelöste Probleme
# behalten die torch.compile-Baseline, d. h. sie gehen mit 1,0x ins Geomean.
buckets = [(">=10x", [4, 1, 0], 20.0), ("[5,10x)", [6, 4, 0], 7.0),
("[2,5x)", [7, 0, 2], 3.2), ("[1.5,2x)", [2, 2, 1], 1.7),
("[1.1,1.5x)", [8, 8, 4], 1.27), ("[1.01,1.1x)", [24, 16, 5], 1.05)]
# pro Level: N, (optimiert, gematcht-opt, Synthese-Fail, Fallback), berichtetes Geomean
LEVELS = [("L1", 100, (51, 20, 13, 16), 1.40),
("L2", 100, (31, 35, 0, 34), 1.15),
("L3", 50, (12, 3, 0, 35), 1.07)]
gm = lambda vals: math.prod(vals) ** (1 / len(vals))
print(f"{'level':5} {'reported':>9} {'all-N midpoint':>14} {'solved-only':>12}")
for li, (lv, N, (opt, mopt, sf, fb), reported) in enumerate(LEVELS):
vals = [mid for _, per, mid in buckets for _ in range(per[li])]
all_n = vals + [1.0] * (N - len(vals)) # ungelöst bei 1,0x
solved = vals + [1.0] * max(opt + mopt - len(vals), 0)
print(f"{lv:5} {reported:8.2f}x {gm(all_n):13.2f}x {gm(solved):11.2f}x")
print()
print("Passraten und das Verblassen pro Level, ungelöst = 1,0x per Design:")
for lv, n, k, geo in (("L1", 100, 71, 1.40), ("L2", 100, 66, 1.15),
("L3", 50, 15, 1.07)):
print(f" {lv}: bestanden {k}/{n} = {k / n:4.0%}, Level-Geomean {geo:.2f}x")
allp = 1.40 ** 100 * 1.15 ** 100 * 1.07 ** 50
print(f" Paper-Geomean über alle 250: {allp ** (1 / 250):.2f}x < jeder Level-Headline")Ausgabe eines echten Laufs (Python 3, deterministisch, kein RNG):
level reported all-N midpoint solved-only
L1 1.40x 1.43x 1.66x
L2 1.15x 1.16x 1.25x
L3 1.07x 1.08x 1.31x
Passraten und das Verblassen pro Level, ungelöst = 1,0x per Design:
L1: bestanden 71/100 = 71%, Level-Geomean 1.40x
L2: bestanden 66/100 = 66%, Level-Geomean 1.15x
L3: bestanden 15/50 = 30%, Level-Geomean 1.07x
Paper-Geomean über alle 250: 1.23x < jeder Level-HeadlineDie Rekonstruktion bestätigt die Lesart: Nur der Nenner „alle Probleme“ (ungelöst bei 1,0×) reproduziert die berichteten Geomeans im Rahmen des Histogramm-Mittelpunktsfehlers. Die Alternative „nur gelöste“ müsste 1,66×/1,25×/1,31× ergeben — deutlich über allen berichteten Zahlen —, das Paper schenkt uns also keinen heimlich selektierten Nenner; das Verblassen steckt in den berichteten Zahlen. Aber die Berichterstattung verdient trotzdem eine ehrliche Fußnote: Die Klammer „(51/100)“ im Abstract zählt nur die Kategorie Optimized, während das Geomean auch die 20 Matches (Ergebnisse nahe 1,0×) enthält — und der schwere Ausläufer leistet viel Arbeit. Fünf der größten Gewinne sind Level-1-algebraische Umschreibungen — eine Diagonal-Matmul, die O(N^3) → O(N^2)-Struktur erkennt (88,63×), Dreiecks-Matrix-Operanden mit Skip-Null-Iteration (20,26×, 14,04×), Batched-Diagonal-Struktur (11,38×), symmetrische Matrixstruktur (8,65×)1 — Fälle, in denen Inductor eine generische cuBLAS-GEMM dispatcht für ein Problem mit ausnutzbarer mathematischer Struktur. Genau das sind die Probleme, die ein fester Pattern-Match-Satz des Compilers nicht sehen kann und ein LLM kann — und sie sagen etwas Wichtiges darüber, wo die verbleibenden Gewinne liegen: weniger in Scheduling-Mikrooptimierung als im Erkennen von Problemstruktur, die der Compiler generisch behandelt.
Das Verblassen selbst hat zwei multiplizierende Faktoren, und sie verstärken sich: Die Passrate fällt (71 % → 66 % → 30 %) und der erreichbare Speedup auf dem Bestandenen fällt (1,40× → 1,15× → 1,07×). Auf Level 3 — 50 vollständige Modellarchitekturen von 3-Schicht-MLPs bis zu 259-Kernel-LLaMA-Varianten — produziert das System zwölf optimierte und drei gematchte Ergebnisse und gibt 35 von 50 Problemen an den Compiler zurück. Der nächste Abschnitt erklärt, warum das strukturell ist und kein Prompt-Engineering-Defizit.
4. Die Obergrenze: Library-Dominanz und Amdahl auf einem erhaltenen Dispatch-Graphen
Das Bewahren der Vendor-Aufrufe macht KernelOPT robust — und begrenzt es zugleich. Von den 85 Fallbacks über alle Levels sind 61 Library-Dominanz: 37 GEMM-dominant (28 L2, 9 L3), wo cuBLAS-Matmuls die Mehrheit der Wallclock-Zeit verbrauchen und nur dünne Triton-Epiloge (unter 1 % der Laufzeit) optimierbar bleiben, und 24 Conv-dominant (6 L2, 18 L3), wo cuDNN in VGG-, ResNet-, EfficientNet- und MobileNet-artigen Modellen dominiert1. In den GEMM-dominanten Fällen produzieren die Agenten tatsächlich schnellere Epilog-Kernels — und das wieder zusammengesetzte Modell wird trotzdem langsamer, weil der Epilog-Dispatch-Overhead die Sub-1-%-Chance auffrisst. Das Performance-Gate verwandelt jeden davon in einen Baseline-erhaltenden Fallback statt in einen falschen Gewinn.
Das ist Amdahls Gesetz, angewandt auf einen Dispatch-Graph mit eingefrorener Region, und es verdient exakte Zahlen. Wenn Vendor-Aufrufe den Anteil f der Modell-Wallclock-Zeit haben und exakt so bleiben wie sie sind, und das LLM die verbleibenden Triton-Sub-Kernels um den Faktor S beschleunigt, ist die Obergrenze des Modell-Speedups 1/(f + (1-f)/S). Keine Agenten-Iteration bewegt f, denn f zu bewegen hieße, cuBLAS durch LLM-geschriebenes Triton zu ersetzen — was die Ablation zu null Erfolgen und „pervasive regressions“ kollabieren lässt. Die Zelle setzt die strukturelle Obergrenze der Suche in Zahlen, inklusive des per-Kernel-Speedups, der allein nötig ist, um die 3-%-Performance-Gate-Marge zu überwinden — trivial bei moderatem f, aber divergierend, sobald f sich 1/gamma ≈ 97,1 % nähert, jenseits dessen kein noch so großer Triton-Speedup einen messbaren Modell-Zugewinn kauft:
import math
def ceiling(f, S):
# Amdahl mit eingefrorener Vendor-Region mit Anteil f,
# Triton-Rest um Faktor S beschleunigt.
return 1.0 / (f + (1.0 - f) / S)
print("Graph-Ebene-Obergrenze vs Vendor-Anteil f, Triton-Speedup S:")
print(f"{'f':>5} " + " ".join(f"{'S=' + str(s):>7}" for s in (2, 5, 10, 100)))
for f in (0.5, 0.7, 0.8, 0.9, 0.95, 0.99):
row = [ceiling(f, S) for S in (2, 5, 10, 100)]
print(f"{f:4.0%} " + " ".join(f"{c:6.2f}x" for c in row))
print()
print("der Fall < 1 % Epilog des Papers (GEMM-dominante Fallbacks, f = 99 %):")
for S in (10, 100):
print(f" Epilog {S}x schneller -> Modell {ceiling(0.99, S):.4f}x "
f"(Gate-Marge gamma = 1.03 nicht einmal erreicht)")
print()
print("nötiger Triton-Speedup S für Modell-Ebene 1,03x (Gate-Schwelle):")
print("aus 1.03 = 1/(f + (1-f)/S):")
for f in (0.3, 0.5, 0.7, 0.9, 0.95):
# 1.03 = 1/(f + (1-f)/S) nach S aufloesen:
# f + (1-f)/S = 1/1.03 => S = (1-f)/(1/1.03 - f)
S = (1.0 - f) / (1.0 / 1.03 - f)
print(f" f = {f:4.0%}: S = {S:8.1f}x")Ausgabe eines echten Laufs (Python 3, deterministisch):
Graph-Ebene-Obergrenze vs Vendor-Anteil f, Triton-Speedup S:
f S=2 S=5 S=10 S=100
50% 1.33x 1.67x 1.82x 1.98x
70% 1.18x 1.32x 1.37x 1.42x
80% 1.11x 1.19x 1.22x 1.25x
90% 1.05x 1.09x 1.10x 1.11x
95% 1.03x 1.04x 1.05x 1.05x
99% 1.01x 1.01x 1.01x 1.01x
der Fall < 1 % Epilog des Papers (GEMM-dominante Fallbacks, f = 99 %):
Epilog 10x schneller -> Modell 1.0091x (Gate-Marge gamma = 1.03 nicht einmal erreicht)
Epilog 100x schneller -> Modell 1.0100x (Gate-Marge gamma = 1.03 nicht einmal erreicht)
nötiger Triton-Speedup S für Modell-Ebene 1,03x (Gate-Schwelle):
aus 1.03 = 1/(f + (1-f)/S):
f = 30%: S = 1.0x
f = 50%: S = 1.1x
f = 70%: S = 1.1x
f = 90%: S = 1.4x
f = 95%: S = 2.4xDie Tabelle erklärt das Verblassen ohne jeden Rückgriff auf „schwerere Probleme verwirren das LLM“. Level-1-Probleme sind Einzeloperatoren; manche haben ausnutzbare algebraische Struktur (die Ausläufer-Gewinne) und viele sind punktweise/Reduktions-Kernels, bei denen der Triton-Anteil der Laufzeit nahe 100 % liegt — f ist klein und die Obergrenze großzügig. Level-3-Probleme sind vollständige Architekturen, deren Laufzeit von Matmuls und Faltungen dominiert wird, die das System sich selbst anzufassen verbietet: f ist groß, die Obergrenze kollabiert Richtung 1,0×, und der nötige per-Kernel-Speedup explodiert in Richtung der 97-%-Mauer (bei f = 95 % braucht bereits eine 2,4×-Triton-Umschreibung für 3 % Modell-Zugewinn — 34× bei f = 97 %). Das Fazit des Papers deutet den richtigen nächsten Schritt an — Vendor-Library-Konfigurationen tunen (Algorithmus-Auswahl, Workspace-Größe, Math-Mode) statt die Aufrufe zu ersetzen — und stellt fest, dass dort, wo 72 % der Fallbacks aus cuBLAS/cuDNN-Dominanz entstehen, die heilbare Performance tatsächlich liegt1.
Das ist zugleich die faire Benchmark-Einschränkung: 1,07× auf Level 3 ist ein kleiner Zugewinn auf genau der Problemklasse, die die Produktions-Inferenz interessiert — und er ist per Design begrenzt, wobei die Design-Entscheidungen trotzdem richtig sind: Die Ablation beweist, dass die Alternative null Gewinne plus Regressionen ist.
5. Warum float64-Modellverifikation: sich aufschaukelndes per-Kernel-Rauschen
Das technisch interessanteste Gate ist Gate 3s float64-Fallback, und es adressiert eine Fehlerklasse, die per-Kernel-Tests strukturell nicht sehen können: Fehlerausbreitung durch den Graphen. Gate 2 prüft jeden Kandidaten-Kernel isoliert gegen die eager-Referenz auf lockerer 10^-3-Toleranz über drei Seeds — gut zum Filtern kaputter Kandidaten während der Suche. Aber ein kompiliertes Modell ist eine Kette: Kleine per-Kernel-numerische Deltas, die einzeln weit innerhalb der Toleranz liegen, können sich mit der Tiefe aufschaukeln — und umgekehrt kann ein korrekter Kernel mit TF32-Tensor-Cores eine naive strenge Prüfungfail lassen, die ein anderen Akkumulationsreihenfolge nutzender Artefakt-Deukel durchlassen würde.
KernelOPTs Gate 3 behandelt beide Richtungen mit einem Fehlerverhältnis statt einer absoluten Schwelle. Es berechnet drei Ausgaben: die FP32-Ausgabe des optimierten Kernels, die FP32-Ausgabe des Baseline-Kernels und die FP64-Ausgabe des Baseline-Kernels als hochpräzise Referenz. Dann ist d_ref die L^inf-Distanz zwischen den beiden Baselines (FP32 minus FP64 — der eigene FP32-Rundungsfehler der Baseline) und d_opt die Distanz der optimierten FP32-Ausgabe zur FP64-Referenz. Ist d_ref mindestens 10^-8, wird das Fehlerverhältnis rho = d_opt/d_ref gegen eine Grenze von 10 verglichen: Korrekte TF32-Kernels landen bei rho grob zwischen 1 und 3 (andere, aber legitime FP32-Akkumulationsreihenfolgen), algorithmisch inkorrekte Kernels über 100 — drei Größenordnungen Trennung, weshalb eine einzige Schwelle funktioniert1. Liegt d_ref unter 10^-8 (exakte Operationen wie max oder argmax, wo jede Abweichung ein echter Bug ist), fällt die Prüfung auf einen skalierungs-relativen Vergleich zurück, und eine absolute Grenze behandelt fusionierte Kernels, deren getrennte Operationen die Präzision künstlich verankern1.
Warum ist die FP64-Referenz nötig statt einfach optimiertes FP32 gegen Baseline-FP32 zu vergleichen? Weil beide um den wahren Wert rauschen, und die strukturierte Frage nicht lautet „stimmen sie überein“, sondern „liegt die Abweichung des optimierten Kernels von der Wahrheit im selben Band wie die eigene Abweichung der Baseline“. Die Zelle simuliert exakt das: eine Kette der Tiefe d aus numerisch harmlosen Stufen (jede Stufe stempelt die Elemente mit ein paar ULP32 relativen Fehler ab — trivial innerhalb der Stufen-Toleranz), gegen eine rauschfreie Referenz und eine verbuggte Alternative mit einem systematischen halben-Epsilon-pro-Stufe-Bias, den jeder einzelne 10^-3-Test der Stufe durchwinkt:
import random, math
random.seed(260930059)
ULP = 2.0 ** -23 # unit in the last place von float32
def chain_error(depth, u0, trials=400, n=256):
"""Maximaler Ende-zu-Ende-Fehler über `trials` Ketten der Tiefe `depth`.
Jede Stufe multipliziert jedes Element mit (1 + U(-u0, u0)); der
rauschfreie Zwilling liefert den Referenzwert."""
worst = 0.0
for _ in range(trials):
noisy = quiet = 1.0
for _ in range(depth):
noisy *= 1.0 + random.uniform(-u0, u0) # eine rauschende Stufe
quiet *= 1.0 # rauschfreier Zwilling
worst = max(worst, abs(noisy - quiet) / quiet)
return worst
print("relatives Stufenrauschen: U(-3 ULP32, +3 ULP32) ~ 3.6e-07")
print("eine solche Stufe passiert allclose(rtol=1e-3, atol=1e-3) mit ~1000fachem Spielraum")
print(f"{'Tiefe d':>8} {'Mittel aus 5 Laeufen, max rel E2E-Fehler':>40}")
for d in (1, 4, 12, 32, 64):
vals = [chain_error(d, 3 * ULP) for _ in range(5)]
print(f"{d:8d} {sum(vals) / len(vals):40.2e}")
print()
print("Gate 3s Fehlerverhaeltnis fuer (a) eine ehrliche Kette, (b) eine Kette")
print("mit systematischem +5e-4/Stufe-Bias -- ein Bug, den ein Stufen-1e-3-Test akzeptiert:")
d_ref = sum(chain_error(32, 3 * ULP) for _ in range(50)) / 50
d_honest = chain_error(32, 3 * ULP)
d_bugged = d_ref + 32 * 5e-4 # Bias akkumuliert linear
print(f" ehrlich : rho = {d_honest / max(d_ref, 1e-30):7.2f} (Paper-Band: 1..10, akzeptieren)")
print(f" verbuggt: rho = {d_bugged / max(d_ref, 1e-30):7.0f} (Paper-Band: >100, ablehnen)")Ausgabe eines echten Laufs (Python 3, Seed 260930059):
relatives Stufenrauschen: U(-3 ULP32, +3 ULP32) ~ 3.6e-07
eine solche Stufe passiert allclose(rtol=1e-3, atol=1e-3) mit ~1000fachem Spielraum
Tiefe d Mittel aus 5 Laeufen, max rel E2E-Fehler
1 3.57e-07
4 1.08e-06
12 2.28e-06
32 3.64e-06
64 5.38e-06
Gate 3s Fehlerverhaeltnis fuer (a) eine ehrliche Kette, (b) eine Kette
mit systematischem +5e-4/Stufe-Bias -- ein Bug, den ein Stufen-1e-3-Test akzeptiert:
ehrlich : rho = 1.10 (Paper-Band: 1..10, akzeptieren)
verbuggt: rho = 4502 (Paper-Band: >100, ablehnen)Zwei Lesarten. Erstens: der Ende-zu-Ende-Fehler der ehrlichen Kette wächst etwa mit sqrt(Tiefe) (zufällige Vorzeichen kürzen sich; 3.6e-7 pro Stufe werden etwa 3.6e-6 bei Tiefe 32) — echtes Aufschaukeln, aber zwei Größenordnungen unter jeder geprüften Toleranz, und entscheidend von derselben Größe wie die eigene Abweichung der Baseline von der Wahrheit, was rho nahe 1 bedeutet und warum der ehrliche Kernel passiert. Zweitens: die verbuggte Kette — jede Stufe fügt nur 5e-4 systematischen Bias hinzu, die Hälfte der Stufen-Toleranz, einzeln nicht nachweisbar —, aber Bias akkumuliert linear mit der Tiefe, während die Aufhebung das ehrliche Rauschband klein hält, also landet das Verhältnis bei Tiefe 32 im Tausenderbereich, weit jenseits des 100er-Bands, das das Paper für algorithmisch inkorrekte Kernels berichtet. Ein per-Kernel-Test bei 10^-3 akzeptiert jede Stufe dieser Kette; nur eine Modell-Ebenen-Messung gegen eine float64-Referenz sieht den Unterschied zwischen Rauschen und Bias. Für eine 259-Kernel-LLaMA-Variante ist das kein Grenzfall — es ist der Unterschied zwischen einem Verifikationsschema, das falsche schnelle Kernels entdecken kann, und einem, das nur kaputte entdecken kann. Die eigenen E2E-Zahlen des Papers bestätigen, dass das Gate nicht bloß dekorativ ist: Nur 2 von 250 Problemen failen an Gate 3 — die Verifikation arbeitet wie beabsichtigt, schlechte Kandidaten sterben meist früher an den billigeren Gates.
6. Was generalisiert, was nicht
Die faire Zusammenfassung sind zwei Sätze. Als Engineering-Ergebnis ist KernelOPT der stärkste Beweis bisher, dass LLM-Kernel-Optimierung Struktur braucht: Dispatch-Bewusstsein allein macht den Unterschied zwischen 38 % und 0 % Erfolg, NCU-Leitung und Beam-Search eliminieren jeweils 74 % der Optimierungen (19 → 5), und die vierstufige Kaskade verwandelt den üblichen Berichterstattungs-Bias des Feldes (korrekt-per-Kernel-aber-langsamer-Modell-Gewinne werden trotzdem gemeldet) in gemessene, Baseline-erhaltende Fallbacks1. Als Performance-Ergebnis quantifiziert es das agentische Verblassen ehrlich: 1,40×, wenn die Probleme Triton-geformt sind, 1,07× — kaum über dem Rauschen —, wenn die Probleme GEMM-geformte Modelle sind, und der Mechanismus ist nicht ein verwirrtes LLM, sondern eine eingefrorene Vendor-Region, die Amdahl exakt bepreist.
Die Einschränkungen sind die üblichen plus eine designbedingte Grenze. Die Studie ist Single-GPU-Inferenz auf einer H200 mit einem Frontier-LLM, ohne Vergleichszahlen gegen andere Tools (bewusst — Hardware- und Framing-Unterschiede machen Metrik-Transfer ungültig, so die Autoren), NCU-Profiling braucht erhöhte GPU-Counter-Rechte und treibt rund 60 K Tokens pro Profiling-Prompt, und die beambasierte Suche ist nicht billig (ungefähr 1.100 GPU-Stunden für 250 Probleme)1. Die Guidelines im Repo wurden nach der Evaluation extrahiert und dienen als Kaltstart-Kontext, sind also nicht für die berichteten Zahlen verantwortlich — eine Offenlegung, die das Paper unaufgefordert macht und die von seiner Hygiene zeugt.
Woran dieser Raum künftig gemessen werden sollte, wenn das Verblassen der Befund ist, sind nicht Headline-Geomeans. Sondern ob der Ansatz f bewegen kann — entweder durch sichere Vendor-Library-Konfigurationssuche (die eigene vorgeschlagene Richtung des Papers: cuBLAS-Algorithmus-Auswahl, Workspace-Größe, Math-Mode) oder durch formal verifiziertes Ersetzen von Library-Aufrufen, was ein viel härteres Problem ist als Triton-Sub-Kernel-Umschreiben. Bis dahin ist die ehrliche Composite-Zahl — 1,23× über alle 250 Probleme, dominiert vom Level-1-Ausläufer — und nicht die 1,40× das, was produktive Wiederverwendung realiter liefert.
Footnotes
-
Aheli Poddar, Sanskar Prasad, Arindam Samanta, Subha Chakraborty, Vishal Goyal, and Rohit Singh Rathaur. KernelOPT: Dispatch-Aware Agentic Search for GPU Kernel Optimization. arXiv:2609.30059 [cs.DC], eingereicht am 24. September 2026. https://arxiv.org/abs/2609.30059 — Autorenliste gegen die arXiv-Abstract-Seite verifiziert. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20
-
Genghan Zhang, Shaowei Zhu, Anjiang Wei, Zhenyu Song, Allen Nie, Zhen Jia, Nandita Vijaykumar, Yida Wang, and Kunle Olukotun. AccelOpt: A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization. arXiv:2511.15915. KernelOPTs Planner–Executor–Summarizer-Schleife und das Experience-Memory-Design folgen der Architektur dieses Papers, von NKI/Trainium auf NVIDIA-GPUs adaptiert — Autorenliste gegen die arXiv-Abstract-Seite verifiziert. ↩