KREX: Kernel-Benchmarking auf geteilten GPUs, ohne die Suche des Agenten zu korrumpieren

Die Kernel-Agenten-Welle hat eine unbeleuchtete Abhängigkeit: Jeder Agent — OpenAI-Systeme im AlphaEvolve-Stil, KernelBench-Leaderboards, Alibabas Produktions-Fleet — schließt seine Schleife über ein einziges Primitiv: miss die Dauer dieses Kernels auf einer echten GPU. Ein September-2026-Paper von HKUST und Alibaba Group, KREX: Concurrent Kernel Benchmarking on Shared GPUs via Region-Granular Exclusivity (Tianyu Feng, Haoxuan Yu, Tianyuan Wu, Lingyun Yang, Daocheng Ying, Yuxiao Wang, Ruibo Fan, Yinghao Yu, Guodong Yang, Liping Zhang, Wei Wang; arXiv:2609.30057, cs.DC, 24. September 2026) startet bei der betrieblichen Skala dieses Primitivs: Die Produktionsumgebung der Autoren fährt über 300.000 Kernel-Benchmarking-Jobs pro Tag über sechs GPU-Modelle von drei Herstellern¹. Und es benennt die Kopplung präzise: Messgenauigkeit wird heute erkauft durch Nicht-Teilen — was bei dieser Skala enormous Verschwendung ist, denn fast nichts eines Benchmarking-Kommandos braucht die GPU wirklich exklusiv.

Das Anti-Hype-Framing verdient sich das Paper statt es nur zu behaupten: Eine korrumpierte Messung ist nicht „etwas verrauschte Daten". Sie ist ein falscher Gradient für einen Agenten, der in genau die Richtung läuft, die die Zahlen zeigen. Ein langsames Benchmark verschwendet eine Iteration; ein falsches Benchmark optimiert aktiv auf Rauschen zu — und der Agent behält gerne den langsameren Kernel, weil die Messung sagte, er sei schneller. Die Fleet-Daten des Papiers enthalten den Rauchfang: Unter ungeschütztem Sharing blähen sich wiederaufgeführte Benchmark-Dauern auf das 1,5-fache bis 3,2-fache ihrer unkandidierten Werte auf (acht Kommandos pro GPU), und die Inflation hängt von den Co-Tenas ab — d. h. sie hebt sich in Kandidaten-Vergleichen nicht auf. In einer aufgezeichneten Trajektorie eines Agenten, der einen MoE-Token-Alignment-Kernel optimierte, kehrte sich unter Sharing die Reihenfolge von sechs von zehn paarweisen Vergleichen nahezu gleich schneller Kandidaten um; der beste Kandidat (wahrhaftig 49,0 μs gegen 50,3 μs des Konkurrenten) maß sich schlechter (53,9 μs gegen 49,3 μs). Die Suche des Agenten wurde nicht verlangsamt — sie wurde fehlgeleitet¹.

1. Wohin ein Benchmarking-Kommando seine Zeit wirklich steckt

Zerlegt man ein typisches Agenten-Benchmarking-Kommando — Frameworks importieren, den Kandidaten-Kernel kompilieren, Inputs generieren, Korrektheit gegen die Referenz prüfen, dann timen — in Phasen, dann fällt die Exklusivitäts-Anforderung direkt aus der Struktur ab:

• Framework-Imports und Kernel-Kompilierung berühren die GPU überhaupt nicht.
• Input-Generierung und Korrektheitsprüfungen nutzen die GPU, aber ein Co-Tenant kann sie nur verzögern; er kann weder die erzeugten Tensoren noch das Korrektheits-Urteil verändern.
• Nur die getimte Schleife ist lastsensitiv: Ihr Output ist die Zahl, die der Agent optimiert.

Das Profil des Papiers für eine repräsentative Agenten-Workload auf dem eigenen Testbed: Startup und Kompilierung machen 81% der medianen Kommando-Dauer aus, die Korrektheitsprüfung 10%, die getimte Schleife nur 8,5% — 0,22 s von 2,6 s Kommando¹. Unter kommandogranularer Exklusivität wird die GPU für die ganzen 2,6 s reserviert, um 0,22 s zu schützen. Eine größere Stichprobe (1.069 Kommandos aus einer Stunde KREX-serial-Ausführung auf einer NVIDIA H20) setzt den medianen kritischen Regions-Anteil auf 12%, 73% der Kommandos liegen unter 25%; die Medianwerte pro Suite sind 4,4% (KernelBench), 18,2% (FlashInfer-Trace), 22,7% (Atrex-Bench)¹.

Und die grobere Alternative ist schlechter: Sessiongranulare Reservierung (ein Agent hält eine GPU für seine ganze Session) erreicht in der profilierten Session 3,4% Gerätenutzung, weil GPU-Kommandos nur 19,3% der Wanduhrzeit einnehmen und das Gerät davon nur 17,4% aktiv ist¹.

2. Warum natives Sharing Agenten nicht nur bremst — sondern in die falsche Richtung schickt

Kernel-Agenten rangieren Kandidaten nach relativer gemessener Dauer. Konkurrenz-Rauschen mittelt sich aus diesem Vergleich aus zwei Gründen nicht heraus, die das Papier explizit benennt. Erstens neigt Konkurrenz dazu, Dauern zu inflieren — Wiederholungsmessungen stellen den unkandidierten Wert also nicht wieder her. Zweitens variiert die Inflation mit den Co-Workloads, wirkt also auf die beiden verglichenen Kandidaten unterschiedlich — eine Verzerrung, keine Varianz im Vergleicher.

Die Hill-Climbing-Arithmetik ist brutal, weil echte Kandidaten-Abstände klein sind. Ist ein verbesserter Kandidat 2–5% schneller als sein Vorgänger und das Messrauschen von gleicher Größenordnung, dann kippt das Vorzeichen des Vergleichers mit substanzieller Wahrscheinlichkeit — und der Agent akzeptiert Rückschritte in dem Glauben, es seien Verbesserungen. Eine kleine Simulation genau dieser Schleife — zwei Kandidatenverteilungen mit überlappenden Rauschbändern, eine vereinfachte Gauß-Mittelwert-Messung, gieriges Akzeptieren nur wenn gemessen schneller:

# Cell 1: how measurement noise flips candidate rankings and misdirects a greedy search
import random
 
# Pairwise flips: candidate B is truly `gap` slower; the toy model averages
# N independent timed launches; per-launch relative noise ~ N(0, sigma).
def flip_rate(gap, sigma, n_launches, trials=20000, seed=2026):
    rng = random.Random(seed + int(gap * 1000) + int(sigma * 1000) + n_launches)
    eff = sigma / (n_launches ** 0.5)
    flips = 0
    for _ in range(trials):
        ma = 1.0 * (1 + rng.gauss(0, eff))
        mb = (1.0 + gap) * (1 + rng.gauss(0, eff))
        if mb < ma:
            flips += 1
    return flips / trials
 
print("P(measured ranking flips): B truly +gap slower, Gaussian average of N launches")
print("")
print(f"{'true gap':>9} {'sigma':>6} {'N=1':>7} {'N=10':>7} {'N=100':>7}")
for sigma in (0.01, 0.03, 0.05):
    for gap in (0.02, 0.03, 0.05):
        r1 = flip_rate(gap, sigma, 1)
        r10 = flip_rate(gap, sigma, 10)
        r100 = flip_rate(gap, sigma, 100)
        print(f"{gap*100:>8.0f}% {sigma*100:>5.0f}% {r1*100:>6.1f}% {r10*100:>6.1f}% {r100*100:>6.1f}%")
 
# Greedy hill-climb: accept a proposal only if its MEASURED duration beats the
# measured best. Proposals truly improve by 0-2% or regress by 0-5%.
def greedy(sigma, iters=500, seed=2026):
    r = random.Random(seed + int(sigma * 1000))
    best_true = 1.0
    wasted = 0
    for _ in range(iters):
        delta = r.uniform(-0.05, 0.02)
        cand_true = best_true * (1 + delta)
        m_best = best_true * (1 + abs(r.gauss(0, sigma)))
        m_cand = cand_true * (1 + abs(r.gauss(0, sigma)))
        if m_cand < m_best:
            if cand_true > best_true:
                wasted += 1
            best_true = cand_true          # agent trusts the measurement
    return wasted
 
print("")
print("Greedy hill-climb, 500 proposals, one measured comparison per proposal")
print("")
print(f"{'sigma':>6} {'regression accepts in 500 proposals':>36}")
for sigma in (0.01, 0.02, 0.04):
    w = greedy(sigma)
    print(f"{sigma*100:>5.0f}% {w:>36}")

P(measured ranking flips): B truly +gap slower, Gaussian average of N launches
 
 true gap  sigma     N=1    N=10   N=100
       2%     1%    8.0%    0.0%    0.0%
       3%     1%    1.9%    0.0%    0.0%
       5%     1%    0.0%    0.0%    0.0%
       2%     3%   31.6%    7.4%    0.0%
       3%     3%   24.4%    1.4%    0.0%
       5%     3%   12.5%    0.0%    0.0%
       2%     5%   38.9%   18.7%    0.2%
       3%     5%   33.7%    9.2%    0.0%
       5%     5%   24.3%    1.3%    0.0%
 
Greedy hill-climb, 500 proposals, one measured comparison per proposal
 
 sigma  regression accepts in 500 proposals
    1%                                   29
    2%                                   50
    4%                                   59

Die zweite Tabelle zählt akzeptierte Regressionen unter 500 Vorschlägen: 29 bei 1 % und 59 bei 4 % Rauschen in diesem Modelllauf. Das sind keine Anteile an allen akzeptierten Vorschlägen. Die erste Tabelle verwendet einen unabhängigen gaußschen Mittelwert als Näherung, nicht den Median vieler realer Messsysteme. Ihre 1/√N-Reduktion gilt für zufälliges Rauschen, nicht für eine systematische Konkurrenz-Verzerrung. Bei modellierten 3 % Einzelmessungsrauschen und 2 % wahrem Abstand sinkt die Flip-Rate von 31,6 % (N=1) auf 7,4 % (N=10). Der Trajektorien-Replay des Papiers zeigt dieselbe Form empirisch: KREXs paarweise Flip-Raten bleiben in jeder Abstands-Klasse innerhalb von drei Prozentpunkten eines unkandidierten Native-Repeats, während ungeschütztes Sharing das pro-Trajektorie-Kendall-τ (Rangkorrelation) auf einen Median von 0,432 drückt — gegen 0,820 für das Native-Repeat selbst, KREX liegt bei 0,857¹².

3. KREX in einem Absatz: Exklusivität nur dort, wo Timing lebt

KREX' Schnittstelle ist absichtlich klein: die kritische Region markieren — die Timing-Phase — und vollständig markieren; die Runtime erzwingt die Grenze für das ganze Kommando (Anforderung R1 im Paper), ohne den zu testenden Kernel zu verändern. Der Eintritt in eine Region triggert ein vierteiliges Protokoll pro GPU: neue konkurrierende GPU-Submissions blocken (ein Shared-Memory-Gate mit Epoch-Tagging, geprüft bei jeder Operation, die Arbeit auf dem Gerät hinterlassen könnte); ausstehende GPU-Arbeit der Siblings drainieren (In-Flight-Zähler in jedem Kontextprozess, sodass eine fliehende Submission entweder vom Drain erfasst oder blockiert wird, bevor sie den Driver erreicht); die Prozessbäume der Siblings einfrieren (per-Tenant-Freezer-Cgroups, damit ein Host-Thread der Siblings die messenden Threads nicht präemptieren und Kernel-Launches verzögern kann); und die messenden Threads des Kommandos auf reservierte CPU-Kerne pinnen — physische Kerne werden für den ganzen Lauf in disjunkte Slices pro GPU partitioniert, weil allein CPU-Konkurrenz die gemeldeten Dauern messbar inflate¹. Außerhalb markierter Regionen laufen konkurrierende Kommandos frei, getragen von persistenten Kontextprozessen, die vorab erzeugte GPU-Kontexte halten und Driver-Aufrufe über asynchrones IPC weiterleiten. Das letzte Stück ist keine Zierde: Eine CUDA-Kontexterstellung nimmt ein node-weites Driver-Lock („64 CUDA-Kontexte auf einem Server zu erstellen dauert über 30 Sekunden, selbst wenn die Requests parallel über verschiedene GPUs gestellt werden"), also serialisiert Kommando-Admission unter dem Kommando-pro-Prozess-Modell über den ganzen Node¹. Kontext-Pooling eliminiert die wiederkehrenden Kosten und bringt allein ~9% Durchsatz (KREX-serial bei 17,5 cmds/min gegenüber 16,0 native auf H20)¹.

4. Die Arithmetik regionsgranularer Exklusivität

Warum reicht es, Exklusivität auf 8,5–12% eines Kommandos zu beschränken — für Genauigkeit und für 3,4× Durchsatz? Weil Exklusivität nur teuer ist, wenn sie über die Nicht-Timing-Phasen gehalten wird, und Off-Region-Konkurrenz nur billig ist, wenn die Queueing-Struktur Kommandos wirklich überlappen lässt. Die Zahlen des Papiers mit einem Spielzeugmodell der beiden Constraints — Amortisation des serialen kritischen Anteils und die Region-Grenze:

# Cell 2: where a benchmarking command's wall-time actually goes, and what
# region-granular exclusivity recovers (numbers from arXiv:2609.30057v1)
import random
 
# KREX Fig. 1a: median command is 2.6 s: startup+compile 81%, correctness 10%,
# timed loop 8.5% (0.22 s). Fig. 6b (1069 commands on H20): median critical-
# region fraction 12%, 73% of commands below 25%; KernelBench 4.4%,
# FlashInfer-Trace 18.2%, Atrex-Bench 22.7%.
median_fractions = {"KernelBench": 4.4, "FlashInfer-Trace": 18.2,
                    "Atrex-Bench": 22.7, "all commands (median)": 12.0, "73rd pct": 25.0}
 
# Utilization perspective: session-granular reservation (E1) yields 3.4% GPU
# utilization because GPU commands cover only 19.3% of wall-clock and the
# device is active only 17.4% of that.
cmd_wall = 0.193
dev_active_of_cmd = 0.174
print(f"E1 session-granular reservation utilization: {cmd_wall * dev_active_of_cmd:.3f}x -> {cmd_wall * dev_active_of_cmd * 100:.1f}%")
 
# Simplified steady-state model of one GPU: on command-granular exclusivity
# (E2), commands of median duration D = 10.2 s (H20, Fig. 6a) run one at a
# time; with region-granular exclusivity (E3), the critical 12% stays serial
# but the rest (88%) can be overlapped by up to C colocated commands.
D = 10.2
frac = 0.12
for C in (1, 2, 4, 8, 16):
    # Optimistic Amdahl-style throughput proxy: serialize the marked fraction,
    # overlap the remainder across C commands. It does not model queueing,
    # GPU work outside regions, CPU contention or setup costs.
    per_cmd = D * (frac + (1 - frac) / C)
    print(f"C={C:2d}: effective resource time {per_cmd:5.2f} s "
          f"-> {D / per_cmd:4.1f}x E2 throughput (toy upper bound)")

E1 session-granular reservation utilization: 0.034x -> 3.4%
C= 1: effective resource time 10.20 s ->  1.0x E2 throughput (toy upper bound)
C= 2: effective resource time  5.71 s ->  1.8x E2 throughput (toy upper bound)
C= 4: effective resource time  3.47 s ->  2.9x E2 throughput (toy upper bound)
C= 8: effective resource time  2.35 s ->  4.3x E2 throughput (toy upper bound)
C=16: effective resource time  1.79 s ->  5.7x E2 throughput (toy upper bound)

Die serielle Regions-Grenze des Modells liegt bei D × 12 % = 1,22 s Ressourcendauer pro Kommando, also höchstens 8,3× Durchsatz gegenüber exklusiven Kommandos selbst bei unbegrenzter Überlappung. Für C=16 sagt das optimistische Modell 5,7× voraus; KREX misst auf H20 54,8 statt 17,5 Kommandos/min, also 3,1× gegenüber KREX-serial. Die 12 % sind ein Median und kein fixer Anteil pro Kommando; reale GPU-Arbeit außerhalb der Region, CPU- und Kontextkosten sowie Warteschlangen begrenzen den Durchsatz zusätzlich. Gemessen wurden 3,4× gegenüber Native auf H20 und 2,6× auf MI308X¹. Man beachte auch den Datensatz zu ungeschütztem Sharing: ohne jeden Schutz erreicht Sharing auf H20 nur 41,9 cmds/min, unter KREX' 54,8 — weil KREX zusätzlich MPS einsetzt, um die Off-Region-Konkurrenz zu verbessern. Korruption und Durchsatz stehen hier nicht einmal in einem sauberen Trade-off; die ungeschützte Konfiguration verliert auf Genauigkeit und kann auch auf Durchsatz verlieren¹.

5. Genauigkeit: die Zahlen — und warum kurze Kernel strukturell schlechter dran sind

Das Headline-Genauigkeitsergebnis in der durchsatzsoptimierten Konfiguration: p95-Timing-Inflation von 0,30%/1,58%/3,90% für Kernel über 10 ms/1 ms/0,1 ms, gemessen gegen unkandidierte Native-Referenzen, wie im Abstract des Papers zusammengefasst¹. Auf dem Band >1 ms berichtet das Paper volle Verteilungen: P = 2,5% auf H20 und 2,4% auf MI308X, gegen 154% und 150% bei ungeschütztem Sharing. Ablationen zeigen: Der GPU-Schutz (Gate/Drain) liefert den größten Teil, und CPU-Schutz senkt den p95-Shift im Forwarding-Mikrobenchmark von 840 μs auf 296 μs¹.

Das Abstract des Papers nennt die p95-Timing-Inflation für drei verschachtelte Kernel-Dauergruppen:

Die Gruppen überlappen und enthalten unterschiedliche Kernel. Ihre unteren Grenzen sind keine repräsentativen Dauern; aus Quotienten der p95-Werte lässt sich deshalb weder ein fixes 1/d-Overheadmodell testen noch der Unterschied dem Sharing zuordnen. Abbildung 8 nennt für die gewählten Durchsatzkonfigurationen bei Kommandos >1 ms 2,5 % auf H20 und 2,4 % auf MI308X. Das ist eine andere Aggregation als die 1,58 % des Abstracts¹. Unter 0,1 ms zeigt selbst die zweite Native-Messung P = 12,1 % auf H20 und 7,6 % auf MI308X. Dieses Grundrauschen erschwert die Rangordnung bei kleinen Kandidatenabständen; KREXs paarweise H20-Flip-Raten bleiben in den untersuchten Abstandsklassen dennoch innerhalb von drei Prozentpunkten der Native-Wiederholung¹. Bei kleinen Abständen sollten Messungen wiederholt und Unsicherheit angegeben werden.

6. Was man behalten sollte — und wo man hedge

Behalten: Regions-Markierung als Schnittstelle ist die richtige Abstraktion — sie macht den Genauigkeits-Vertrag explizit und billig erzwingbar, und das Papier zeigt, dass die Maschinerie (In-Flight-Zähler, epoch-getaggte Gates, Freezer-Cgroups, Kern-Slices) auf zwei Herstellern mit einem gemeinsamen Protokoll funktioniert. Die Durchsatz-Behauptungen überleben den Replay: 3,4-fach/2,6-fach gegen kommandogranulares Native, bei Inflation unter 4% selbst im kürzesten Band — und das Ranking-Bewahrungs-Experiment ist das, dem ein Agenten-Betreiber tatsächlich vertraut¹.

Hedge: Die Vertrauensgrenze. KREX setzt kooperative Kandidaten voraus; Regionen werden vom Autor des Benchmarking-Codes markiert, und das Papier sagt klipp und klar, dass Pool-Timeouts Missbrauch begrenzen, aber nicht verhindern¹. Eine Region kann zu eng gezogen werden (lastsensitive Arbeit bleibt außerhalb) oder zu großzügig (für die eigenen Kommandos entsteht kommandogranulare Exklusivität wieder); die Runtime erzwingt, was markiert ist, nicht was wahr ist. Das Paper nennt Regions-Fairness und Region-Zugriffs-Starvation als ungelöste Scheduling-Probleme — die slot-basierte Admission liefert keine Regions-Fairness-Garantie pro Tenant¹. Und auf AMD wird das Kontext-Pooling weggelassen, weil sein Genauigkeitskosten dort höher sind als auf NVIDIA — deshalb landet MI308X bei 2,6 statt 3,4: Der Mechanismus ist portabel, die Effizienz ist hardware-getunt.

Die allgemeine Lektion überdauert das System: In agentischen Optimierungsschleifen ist das Messprimitiv der Gradient. Hardware teilen, ohne das getimte Intervall zu schützen, degradiert die Schleife nicht — es invertiert die Laufrichtung für jede Entscheidung, die auf einer verschmutzten Zahl beruht. KREX' Beitrag ist der Nachweis, dass der Schutz in der untersuchten H20-Stichprobe median 12 % der Kommando-Wandzeit abdeckt, und dass 0,3–3,9% p95-Inflation auf dieser geschützten Scheibe 2,6–3,4-fachen Fleet-Durchsatz zurückkaufen. Ein guter Trade für jede Operation mit 300.000 Benchmarking-Jobs pro Tag — und ein Designmuster, das sich überall lohnt, wo eine Agentenschleife über geteilte Mess-Hardware läuft.