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 Herstellern1. 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 fehlgeleitet1.
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 Kommando1. 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)1.
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 ist1.
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, Median-bildende Harness, 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 harness reports the
# median of N 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, median 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, best_true
print("")
print("Greedy hill-climb, 500 proposals, one measured comparison per proposal")
print("")
print(f"{'sigma':>6} {'noise-driven regr. accepts':>26} {'final true speedup':>19}")
for sigma in (0.01, 0.02, 0.04):
w, bt = greedy(sigma)
print(f"{sigma*100:>5.0f}% {w:>26} {(1/bt - 1)*100:>18.2f}%")P(measured ranking flips): B truly +gap slower, median 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 noise-driven regr. accepts final true speedup
1% 29 597228.07%
2% 50 466934.20%
4% 59 96400.63%Die inflationierten End-Speedup-Spalten ignorieren — das Modell lässt den Best-so-far über 500 Akzeptanzen multiplikativ kompondieren, was den realisierten Speedup konstruktionsbedingt überschätzt; die tragende Spalte ist die mittlere. Bei 1% Rauschen pro Launch und Single-Shot-Timing waren 29 von 500 akzeptierten Kandidaten wahrhaftig schlechter als der Inkumbent, den der Agent schon hatte; bei 4% Rauschen liefen 59 Akzeptanzen rückwärts. Jede dieser vertanen Akzeptanzen ist eine volle Iteration aus Agenten-Reasoning, Generierung und Benchmarking, die auf Rauschen optimiert wurde. Die übliche Gegenmaßnahme — der Median von N getimten Launches — schrumpft Rauschen nur mit 1/√N: bei 3% Single-Shot-Rauschen und 2% wahrem Abstand liegt die Flip-Rate mit N=1 bei 31,6%, mit N=10 aber immer noch bei 7,4%. 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,85712.
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 inflate1. 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 Node1. 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)1.
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):
# regions cannot overlap: if the summed critical share exceeds the GPU's
# time, exclusivity -- not off-region work -- is the binding constraint
if C * frac <= 1.0:
per_cmd = D * (frac + (1 - frac) / C) # amortized per command
note = ""
else:
per_cmd = D * frac * C / 1.0 # GPU busy in regions of C cmds
note = " (region-bound)"
print(f"C={C:2d}: effective per-command time {per_cmd:5.2f} s "
f"-> {D / per_cmd:4.1f}x E2 throughput (toy upper bound){note}")E1 session-granular reservation utilization: 0.034x -> 3.4%
C= 1: effective per-command time 10.20 s -> 1.0x E2 throughput (toy upper bound)
C= 2: effective per-command time 5.71 s -> 1.8x E2 throughput (toy upper bound)
C= 4: effective per-command time 3.47 s -> 2.9x E2 throughput (toy upper bound)
C= 8: effective per-command time 2.35 s -> 4.3x E2 throughput (toy upper bound)
C=16: effective per-command time 19.58 s -> 0.5x E2 throughput (toy upper bound) (region-bound)Genau lesen: Der multiplikative Gewinn sättigt, sobald serielle Regionen das geteilte Gerät dominieren. Der serielle Bruchteil von 12% deckelt den Gewinn — die Per-Kommando-Zeit läuft auf die Regions-Kosten hinaus, sobald C × 12% eine GPU überschreitet. KREX' gemessene Konfiguration läuft mit 16 parallelen Kommandos pro GPU auf der H20 (mit MPS), wo das Spielzeugmodell sagt, dass die aggregierte kritische Last — 16 × 12% = 192% einer GPU — der Flaschenhals sein müsste — und trotzdem liefert KREX 54,8 cmds/min gegenüber 17,5 von KREX-serial, also 3,1-faches und nicht die 8-fache naive serielle Bruchteil-Arithmetik. Diese Lücke ist die ehrliche Lesart: Die 12% sind ein Median, keine Konstante (Regions-Anteile variieren je Kommando und Suite), Kommandos desynchronisieren, und Queueing außerhalb der Regionen ist burstig. Was einen echten Kommando-Mix überlebt, ist die Headline des Papiers — 3,4-fach über native, 3,1-fach über KREX-serial auf H20, 2,6-fach über native auf MI308X1. 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 verlieren1.
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, auf NVIDIA H20 wie AMD MI308X1. 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 μs1.
Warum wächst die Inflation, je kürzer der Kernel? Die Intuition „feste Exklusivitäts-Latenz, über weniger Mikrosekunden amortisiert" ist nur halb richtig — und die Daten des Papiers sagen es selbst. Eine feste Kostenkomponente f pro Region würde eine Inflation f/d erzeugen: zehnfach kürzere Kernel, zehnfach höhere Inflation. Die gemessenen Jahrzehnt-Sprünge:
# Cell 3: why short kernels suffer more -- how inflation scales with duration
# Bands and p95 inflation from arXiv:2609.30057v1 (Fig. 9 / abstract).
bands = [("(0.1, inf) ms", "lower band edge (us)", 100.0, 3.90),
("(1, inf) ms", "lower band edge (us)", 1000.0, 1.58),
("(10, inf) ms", "lower band edge (us)", 10000.0, 0.30)]
print("KREX p95 timing inflation by kernel-duration band")
for name, _, d, p in bands:
print(f" {name:>13}: {p:>5.2f}%")
print("")
print("If inflation came from a FIXED per-launch overhead f (us), a kernel of")
print("duration d would inflate by f/d: ten-times-shorter kernels should show")
print("ten-times-higher inflation. Check the observed step-up ratios:")
print("")
import math
print(f"{'bands':>22} {'duration ratio':>15} {'inflation ratio':>16} {'1/d prediction':>15}")
pairs = [(bands[i], bands[i+1]) for i in range(2)]
for (na, _, da, pa), (nb, _, db, pb) in pairs:
dr = db / da
ir = pa / pb
print(f"{na:>13}->{nb:>8} {dr:>14.0f}x {ir:>15.2f}x {dr:>14.0f}x")
print("")
print("Observed inflation grows with 1/d but SUBLINEARLY (5.3x and 2.5x when")
print("1/d predicts 10x): a fixed per-region handshake cost would be 10x per")
print("decade, so part of the gap is plain run-to-run variance, which the paper")
print("shows dwarfs everything below 0.1 ms (native repeat: P=12.1% on H20,")
print("7.6% on MI308X). Short kernels are structurally worse off on ANY system")
print("because fewer microseconds of signal must absorb the same floor.")KREX p95 timing inflation by kernel-duration band
(0.1, inf) ms: 3.90%
(1, inf) ms: 1.58%
(10, inf) ms: 0.30%
If inflation came from a FIXED per-launch overhead f (us), a kernel of
duration d would inflate by f/d: ten-times-shorter kernels should show
ten-times-higher inflation. Check the observed step-up ratios:
bands duration ratio inflation ratio 1/d prediction
(0.1, inf) ms->(1, inf) ms 10x 2.47x 10x
(1, inf) ms->(10, inf) ms 10x 5.27x 10x
Observed inflation grows with 1/d but SUBLINEARLY (5.3x and 2.5x when
1/d predicts 10x): a fixed per-region handshake cost would be 10x per
decade, so part of the gap is plain run-to-run variance, which the paper
shows dwarfs everything below 0.1 ms (native repeat: P=12.1% on H20,
7.6% on MI308X). Short kernels are structurally worse off on ANY system
because fewer microseconds of signal must absorb the same floor.Der sublineare Zerfall ist der ehrliche Hinweis: Eine rein fixe Komponente müsste 10-fach pro Jahrzehnt zeigen, und die Sprünge von 2,5-fach und 5,3-fach bedeuten, dass die Inflation im kürzesten Band teilweise irreduzible Run-to-Run-Varianz ist, kein Sharing-Schaden. Das Paper räumt diesen Boden explizit ein — unter 0,1 ms zeigt allein sein Native-Repeat P = 12,1% auf H20 und 7,6% auf MI308X; in dieser Größenordnung ist keine Messung (geteilt oder nicht) verlässlich genug, um einen Agenten an einstelligen Abständen zu steuern1. Für Agenten-Betreiber heißt das praktisch: KREX hält relative Vergleiche bis auf drei Prozentpunkte an Native-Repeat-Flip-Raten heran, selbst für Kernel um 49 μs — aber Kernel im Zehntel-Mikrosekunden-Bereich sollten auf jedem Runtime mit mehr Launches pro Messung getimet 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 vertraut1.
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 verhindern1. 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 Tenant1. 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 nur die 12% Wandzeit abdecken muss, in denen Timing tatsächlich passiert, 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.
Footnotes
-
Tianyu Feng, Haoxuan Yu, Tianyuan Wu, Lingyun Yang, Daocheng Ying, Yuxiao Wang, Ruibo Fan, Yinghao Yu, Guodong Yang, Liping Zhang, Wei Wang: KREX: Concurrent Kernel Benchmarking on Shared GPUs via Region-Granular Exclusivity, arXiv:2609.30057v1 [cs.DC], 24. September 2026, https://arxiv.org/abs/2609.30057. Feng und Yu haben gleichwertig beigetragen. Per Nummer referenzierte Abbildungen (Fig. 1a, 2, 6, 7, 9, 10, 11, 12) sind anhand ihrer Captions im HTML-Volltext beschrieben; exakte Abbildungs-Pixel wurden nicht eigenständig abgeleitet. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17
-
Rangkorrelationskoeffizient nach Kendall; τ = 1 bedeutet, dass die gemessene Rangfolge vollständig mit der Referenz-Ordnung übereinstimmt. ↩