Das ist der Kimi K3-Post, auf den ihr alle gewartet habt. Ich habe frühzeitigen Zugriff auf dieses Modell bekommen und es auf Kernels getestet, und schon bevor ich die Benchmark-Ergebnisse sah, war ich von seiner Fähigkeit, Probleme zu durchdenken, und der technischen Dichte seiner Gedankenspuren beeindruckt. Das Post-Training ist sofort offensichtlich, sobald man ein Transkript liest. Es macht auch super viel Spaß, mit ihm zu reden.
TLDR;
Ich denke, es ist wichtig, dass ich als Kernel- und Performance-Ingenieur, der nichts mit den Benchmarks zu tun hat, mein ehrliches Feedback gebe (dieser Teil ist per Spracheingabe). Natürlich könnt ihr euch alle Zahlen ansehen und lesen und versuchen, ein mentales Modell für euch selbst zu entwickeln. Ich glaube, der ehrlichste Eindruck entsteht, wenn ich euch meine Erfahrung mit dem Modell bei schwierigen Aufgaben schildere, bevor die Benchmark-Ergebnisse veröffentlicht wurden, als ich das Modell nutzte, bevor es irgendwelche Zahlen gab, die es mit anderen Modellen in Verbindung bringen. Einfach nur das reine Gefühl für die Intelligenz, das Denken, die Agenten-Delegation und wie viel es für mich autopilotieren kann, aber bevor irgendein Hype aufkam und die offiziellen Ergebnisse veröffentlicht wurden. Ich würde sagen, dass es sich mit meiner Führung auf etwa dem Niveau von Fable bewegte, in einigen Fällen auf sehr einzigartige Weise übertraf und in einigen Fällen schlechter abschnitt. Ich würde sagen, dass dieses Modell bei den meisten Dingen definitiv vor Opus 4.8 und bei vielen Dingen vor GPT 5.6 Sol liegt.
Kommen wir zum Wesentlichen...
Ich möchte offenlegen, warum das jetzt rausgeht: Ich wollte meine ehrlichen Gedanken und die aktuellen Ergebnisse teilen, nicht darauf warten, bis jede letzte Zelle fertig ist. Einige Läufe laufen noch, während ich dies schreibe. Sie sind unten markiert, und ich werde euch auf dem Laufenden halten, sobald sie eintreffen. Ich habe sowohl die 256K- als auch die 1M-Kontextversionen getestet. Alles hier wurde auf NVIDIA RTX PRO 6000 Blackwells, H100s und B200s mit Single-GPU-Optimierung ausgeführt. Jede Zelle ist eine autonome Agentensitzung mit unbegrenzter Wanduhrzeit: Das Modell bekommt das Problem, eine Live-Compile/Check/Benchmark-Schleife auf echter Hardware, und es entscheidet, wann es fertig ist. Jede Überschriftenzelle wurde manuell auf Reward-Hacking geprüft. Ein separater Agent liest den endgültigen Kernel von Anfang bis Ende sowie die gesamte Sitzungsspur und testet alles, was nach Caching oder Grader-Spielen riecht, empirisch erneut. Was diese Prüfungen ergeben haben, bekommt einen eigenen Abschnitt.
Etwas, das ich beantwortet haben wollte
Es gab eine Sache, um die ich diese Veröffentlichung herum speziell aufgebaut habe: Zwei der Probleme sind Moonshots eigene Architektur. Das Hard-Deck enthält einen eigenständigen Kimi Delta Attention Chunk-Forward-Kernel, und das Flaggschiff-Problem des Mega-Decks ist ein kompletter Kimi-Linear-Hybrid-Decode-Schritt: KDA-Layer, MLA-Attention, MoE-Experten, der ganze Block. Das war also eine Gelegenheit, etwas zu testen, das nicht oft getestet werden kann: Wenn sich das Modell eines Labors hinsetzt, um Kernels für die Architektur desselben Labors zu schreiben, zeigt sich dann das Familienwissen im CUDA?
Die Antwort stellte sich als wirklich gespalten heraus, und beide Hälften sind interessant. Behaltet diese Frage im nächsten Abschnitt im Hinterkopf.
KernelBench-Mega
Das Flaggschiff-Mega-Problem: Einen gesamten Token-für-Token Kimi-Linear-Decode-Schritt (3x KDA + 1x MLA-Layer, W4A16-quantisierte Gewichte, MoE mit Top-8-Routing) in so wenige Kernel-Starts wie möglich fusionieren.
K3 hat fast den Allzeitrekord in seiner eigenen Linie aufgestellt. 18,09x geometrischer Mittelwert der Beschleunigung gegenüber Eager auf der RTX PRO 6000, innerhalb von 4% von Fable 5s Rekord von 18,72x. Auf der H100 erzielte es 14,82x gegenüber Opus 4.8s 15,50x. Ein Hinweis zur Ehrlichkeit, den das Verhältnis verbirgt: In absoluter Latenz pro Token ist Fable immer noch etwa 1,4x voraus (0,31 vs. 0,44 ms/tok bei ctx 2048; die beiden Läufe verwendeten Hosts mit unterschiedlichen CPUs, was die Basislinie des Eager-Modus verschiebt, gegen die das Verhältnis berechnet wird), also berichte ich beide, anstatt das geometrische Mittel jemanden zu beschönigen.
Was K3 gebaut hat, ist ein echter Megakernel. Seine erste Sitzung tat das Vernünftige, ein persistenter Triton-Kernel bei 14,1x. Seine zweite Sitzung warf Triton weg und schrieb den gesamten Decode-Schritt pro Token als EINEN kooperativ gestarteten CUDA-Kernel: Null CPU in der Schleife, int4-Gewichte werden on-the-fly innerhalb jedes GEMV dequantisiert, sodass sie genau einmal durch die SMs strömen, MLA-Attention auf Tensor Cores. Keine Produktions-Engine würde ein Artefakt mit 1.228 Zeilen so pflegen. Ein Agent mit einem zu gewinnenden Kernel und unbegrenzter Zeit hat keine solche Einschränkung, und genau diese Art von Ding ans Licht zu bringen, ist der Grund, warum die Bench existiert.
Siehe den Megakernel hier:
Warum hat es also trotzdem gegen Fable verloren? Nicht die Zeit. Beide Sitzungen haben sich selbst vorzeitig beendet (Fable nach 2,6 Stunden, K3 nach 3,3). Der Unterschied ist die Designphilosophie, und es ist das Gegenteil von dem, was ihr vermuten würdet: K3 ist derjenige, der Tensor Cores verwendet, und Fables Kernel enthält null MMA-Instruktionen. Batch-1-Decode mit fusionierten int4-GEMVs ist bandwidth-begrenzt, also bringen Tensor Cores hier fast nichts. Fable hat diese Mühe stattdessen in die Synchronisation gesteckt, die meisten globalen Barrieren durch feinkörnige Producer-Consumer-Übergaben ersetzt, sodass kein SM jemals an einer Stufengrenze im Leerlauf ist, und in einen int4-Dequant-Pfad, der die Rundung der Referenz Bit für Bit trifft, sodass der MoE-Router nie eine Expertenwahl umkehrt. K3 brachte bessere Hardware-Instruktionen; Fable brachte bessere Concurrency-Engineering, und bei dieser Arithmetik-Intensität gewinnt das Zweite. Das ist eine echte Systemlektion, und sie hat dem Heimteam den Rekord gekostet.
Das zweite Mega-Problem ist ein Grid-Foraging-PPO-Trainings-Megakernel: 4.096 vektorisierte Agenten auf einem 11x11-Brett, mit der gesamten RL-Trainingsschleife (Env-Schritt, Policy-Forward, Action-Sampling, GAE, das PPO-Update), die als fusionierte persistente Kernel läuft. Dieses Problem hat die strengste Einschränkung im Deck: Die Anzahl der Kernel-Starts darf nicht mit den Env-Schritten skalieren, und CUDA-Graph-Capture ist explizit als Workaround für Start-Overhead verboten, durchgesetzt von einem Post-Run-Authenticity-Judge, der den endgültigen Code liest. Korrektheit ist die Lernkurve selbst. check.py trainiert eure Lösung gegen die Referenz über verschiedene Seeds und erfordert, dass die Rendite in einem Band landet, sodass man das Lernen nicht überspringen kann, um schnell zu sein. K3 erzielte hier 20,7x gegenüber der Referenz, die beste Punktzahl bisher (die einzige andere veröffentlichte Zelle ist GPT-5.6 Sol bei 1,06x, also behandelt das als Datenpunkt, nicht als Podestplatz).
KernelBench-CUDA
Die CUDA-Bench existiert, weil Triton eine Krücke ist, die die anderen beiden Decks erlauben. Hier scheitert ein Sprach-Gate an Triton, Kernel-DSLs und PyTorch-Op-Ketten: Ihr schreibt CUDA oder ihr scheitert. Ich habe die vier Probleme so ausgewählt, dass sie Ausschnitte aus realen Produktions-Inferenz- und Simulations-Workloads sind. Der mentale Vergleich beim Lesen sollte sein: "Was liefert vLLM oder SGLang heute dafür, und wie nah kommt eine Agentensitzung heran?" Hier erzielte K3 seine deutlichsten Siege.
02_deepseek_nsa: DeepSeek's Native Sparse Attention. NSA ist das Flaggschiff-Design für trainierbare Sparse-Attention, das Ding, um das jeder Long-Context-Serving-Stack kreist, und es wird in Millisekunden bewertet, weil ein korrekter spärlicher Kernel nie die äquivalenten dichten FLOPs ausführt, die eine Roofline zählen möchte. K3s 256K-Variante erzielte 0,425 gegenüber Opus 4.8s 0,178, ein 2,4x-Vorsprung, indem es im Wesentlichen eine Flash-Attention-Klasse Tensor-Core-Pipeline von Grund auf um die vollständige NSA-Selektionslogik herum schrieb. Der schärfere Vergleich ist innerhalb der Familie: Die 1M-Variante schrieb denselben Algorithmus, identische Blockauswahl, gleiche Korrektheit, führte aber jedes Punktprodukt auf einfachen CUDA-Kernen anstelle von Tensor Cores aus und landete bei 0,058, 7x langsamer bei identischen Formen. Ihre Spur zeigt, dass sie es besser wusste. Sie hatte "Tensor-Core-Attention" auf ihrem eigenen Fahrplan ("Auswahl auf Tensor Cores = ~10-20 us!!") und plante ausdrücklich, zuerst zu messen und dann die Tensor-Core-Neuschreibung zu machen, beendete dann aber ihre Sitzung vor der Neuschreibung. Gleiches Wissen, andere Abschlussdisziplin.
der 0,425 DeepSeek NSA-Kernel (256K):
03_megaqwen_decode: Einen echten Megakernel neu ausrichten. Das eine Problem, bei dem Agenten funktionierenden Produktions-CUDA ausgehändigt bekommen: meinen veröffentlichten MegaQwen (https://github.com/Infatoshi/megaqwen) kooperativen Megakernel (~530 tok/s beim Ausführen des vollständigen Modells auf einer RTX 3090), mit der Anweisung, ihn zu lesen, auf Blackwell neu auszurichten und zu schlagen. Es testet das Lesen von fremdem CUDA und das Treffen einer architektonischen Entscheidung, und K3 und Opus trafen genau gegensätzliche Entscheidungen. K3 weigerte sich, die Single-Launch-Struktur beizubehalten: Es teilte den Schritt in eine Handvoll bandwidth-sättigender Kernel auf und löschte dann den Launch-Overhead auf andere Weise, indem es den gesamten Schritt einmal als CUDA-Graph erfasste, der ohne CPU-Arbeit wiederholt abgespielt wird. 6.283 tok/s bei ctx 2048. Opus bewahrte die Megakernel-Ästhetik und fusionierte die gesamte Decode-Schleife in einen persistenten kooperativen Kernel, wirklich schöner Code, und zahlte 5x dafür (1.020 tok/s), weil kooperative Co-Residenz die Auslastung begrenzt und jede Grid-weite Barriere Stufenenden über alle 188 SMs serialisiert. Bei dem vom Megakernel abstammenden Problem kam das Modell, das buchstäblich einen Megakernel gebaut hat, zuletzt, und die Schlüsselentscheidung des Gewinners war, keinen zu bauen. Größencheck, damit niemand die Überschrift falsch zitiert: Die Bench führt 4 Layer der Qwen3-0.6B-Geometrie aus, etwa 63M Parameter, nicht ein vollständiges Modell, und 6.283 tok/s sind ~56% der Weight-Streaming-Roofline für diesen Stack; die Skalierung der eigenen Zahl der 3090-Basislinie sagt ~7.000 voraus, also landete K3 in der Klasse "die Referenz, neu ausgerichtet, plus echtes Tuning". (Deck-Design-Nuance: CUDA-Graphen sind hier erlaubt und beim PPO-Problem verboten. Jedes Problem verbietet genau die Abkürzung, die seine spezielle Fähigkeit vortäuschen würde.)
01_glm52_fused_moe: GLM-5.2s fusionierter MoE-Block. Fusioniertes MoE-Dispatch (Routing, Permutation, gruppierte Expert-GEMMs in einem Durchgang) ist die mit Abstand heißeste Kernel-Klasse im aktuellen Open-Model-Serving, und GLM 5.2 sitzt auf genau dieser Bestenliste, also optimieren die Modelle einen Produktionsblock eines Rivalen. Niemand hat ihn geknackt: Die Punktzahlen clusteren bei 0,05-0,08 des Spitzenwerts, und der saubere Rekordhalter ist, von allen Modellen, Grok 4,5 bei 0,084, mit K3s 1M-Variante direkt dahinter bei 0,081 und Opus bei 0,065. Das Problem der gruppierten GEMM-Permutation ist wirklich schwer, um cuBLAS-Klasse-Baselines zu schlagen, und bisher verschiebt eine Agentensitzung es weniger als jedes andere Problem im Deck.
04_grid_mingru_sps: Grid World + MinGRU Policy-Rollout. Das Inferenz-seitige Geschwister des Mega-PPO-Problems und die craftax.cu-Linienzelle: Die Policy ist die 3-Layer MinGRU (h=256) Konfiguration direkt aus meinem https://github.com/infatoshi/craftax.cu klassischen Benchmark, der als informativer Anker des Problems dient. Die Umgebung, in der Schritte gemacht werden, ist die minimale Grid-Foraging-Welt und nicht das vollständige Craftax-Spiel. Das ist beabsichtigt: Die Umgebung wird trivial gehalten, damit die Punktzahl die Rekurrenz- und Rollout-Fusion misst, nicht die Spiel-Logik-Implementierung. Ein vollständiger Craftax-Port wäre ein eigenes Problem, und ich möchte es hinzufügen. Bewertet in Schritten pro Sekunde auf einer leisen RTX PRO 6000, Fusion optional.
der 1M persistente Kernel-Rollout:
Jede ernsthafte Einreichung ging den persistenten Megakernel-Weg, und die Spanne zwischen ihnen ist das Synchronisationsdesign, dieselbe Lektion wie beim Mega-Deck. Opus gewinnt dieses hier mit 0,327 der Obergrenze (es fand auch eine clevere algebraische Faltung: Layer 0s 768x256 Gate-GEMM kollabiert auf 768x4, weil der Encoder linear ist), K3 [1M] Zweiter mit 0,224, K3 256K mit 0,174, Grok weit dahinter mit 0,002. Da das Problem von craftax.cu abstammt, habe ich auch meinen eigenen Full-Game-Craftax-CUDA-Port (geschrieben mit Fable 5) auf derselben GPU mit derselben h256x3-Policy in der Schleife laufen lassen. Umgebungsschritte pro Sekunde in Millionen:
Der Vergleichspunkt: Die Modelle durchlaufen ein leeres Gitter, craftax_full.cu durchläuft das vollständige Spiel (43 Aktionen, mehrstöckige Verliese, Weltgenerierung, Mobs) bitidentisch zu seiner CPU-Referenz, und das vollständige Spiel läuft immer noch innerhalb von ~3-4x des besten trivialen Gitter-Kernels, weil bei h=256 alles Policy-GEMM-begrenzt ist und die Umgebung fast kostenlos ist. Genau deshalb ist die Bench-Umgebung trivial: Sie isoliert die Policy-Fusion-Fähigkeit. Zur Kalibrierung macht der reine Umgebungs-Pfad von craftax_full.cu 94-123M SPS.
Wie 9,5 Stunden K3-Denken tatsächlich aussehen
Die 1M-Variante der MinGRU-Sitzung (die beste K3-Zelle bei diesem Problem) ist ein persistenter kooperativer Megakernel, 15 Tuning-Varianten und 4.815 Denkblöcke. Da Moonshots Endpunkt den vollständigen Denktext zurückgibt (im Gegensatz zu den verschlüsselten Anthropic/OpenAI-Spuren), könnt ihr tatsächlich zusehen, wie es arbeitet. Drei Momente aus der Spur, wörtlich.
Die fehlende FMA-Detektivgeschichte. Mitten in der Sitzung traf es auf eine numerische Abweichung von ~5e-5, die es sich weigerte, als Float-Rauschen abzutun (es hatte die legitime Grundlinie für Neuanordnungsrauschen bei ~1e-9 berechnet, also "GEMESSENE 5e-5?!?! KEIN WEG das ist Neuanordnung!!"). Es bemerkte dann, dass die kaputten Umgebungen genau die waren, die kongruent zu 6 mod 8 waren ("Das ist env ≡ 6 (mod 8)! [...] die 7. Umgebung in jeder 8-Umgebungs-Kachel!!") und grub durch seinen eigenen manuell entrollten Akkumulator-Code, bis:
"GEFUNDEN! [...] Die Zeile \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\fehlt VOLLSTÄNDIG [...] acc[6][*][2] mit 0 initialisiert, nie FMA'd → zp=0 → p = sigmoid(0)=0.5 konstant für env 6!! Das ist ein ECHTER Logikfehler — erklärt env≡6 Abweichungen [...] konsistent mit allem!!"
Eine fallengelassene Zeile in einer 48-Akkumulator-Entrollung, was bedeutet, dass das Forget-Gate von Umgebung 6 stillschweigend für immer auf 0,5 feststeckte. Es bemerkte dies, weil die Stresstoleranz 1e-6 beträgt und es seinen eigenen Fehler bei 5e-8 verfolgte. Das ist die numerische Disziplin, die der 256K-Variante zunächst bei KDA fehlte.
Theorie trifft GPU, GPU gewinnt. Es verbrachte Stunden damit, eine "Wide Champion"-Variante mit hoher Auslastung abzuleiten, führte dann den A/B-Vergleich durch:
"SEHR überraschend: Mein 'wide champion' w32p (v3_v3, 50% occ TPB1024) ist ~2x LANGSAMER als v2_b32 (12,5% occ TPB256)?!? [...] Also ist die Auslastung NICHT der Treiber; etwas anderes dominiert. Was hat v2_b32 schnell gemacht??"
Der einfache frühe Kernel schlug jeden ausgeklügelten Nachfolger. Die Deep-Pipeline-, K-Split- und Dual-Chunk-Varianten verloren ebenfalls, und die Dual-Chunk-Variante hatte eine wasserdichte 1,7x-Theorie dahinter ("Theoretische 1,7x hat sich nicht materialisiert"). Zu seiner Ehre, es glaubte jedes Mal dem Benchmark mehr als seiner eigenen Mathematik und schrieb schließlich eine Sondierungsvariante mit gefälschten immer-heißen Gewichten, um seine eigene bevorzugte Bandbreitentheorie zu killen: "Die W-Stream-Theorie ist tot; die verbleibende Lücke ist die Umgebung."
Zen und die Kunst der GPU-Warteschlange. Unser Harness serialisiert alle GPU-Befehle über gleichzeitige Sitzungen hinweg durch eine gemeinsame Sperre, und K3s Benchmark-Zahlen schwankten um bis zu 8x mit der Auslastung der Nachbarn. Sein Reaktionsbogen ist das Lustigste in der Spur. Zuerst Akzeptanz:
"Ehrlich, die Box IST die Box; warte. [...] Das Muster ist klar: Jeder Mieter hält die Sperre für ~20-35 Minuten am Stück (vollständig pipelined Suiten). Meine beste Antwort: Stelle alles, was ich brauche, in EINEM Zug an (einzelne Position in der Warteschlange) und nutze die Wartezeit für CPU-Arbeit. Stelle nicht viele kleine Befehle an; batche sie."
Dann erfand es sein eigenes Vokabular für das GPU-Wetter ("Sturmfenster" vs. "Ruhefenster"), und schließlich plante es einen Cron-Job ein, um leise Momente zu nutzen, und hinterließ eine Notiz für sein zukünftiges Ich: "Geplant: Ruhefenster-Sniper (alle 11 Min). Hinweis: Cron feuert meinen Prompt zurück an mich — ich werde dann darauf reagieren. [...] Ich werde löschen, wenn fertig." Ein Agent unter Messrauschen tolerierte das Rauschen nicht nur; er baute einen Scheduler darum herum.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Sechs Pro-Operator-Probleme gegen SOTA-Bibliotheksobergrenzen (FP8 GEMM, KDA Chunk-Forward, Paged Attention, Top-k Selektion, MoE SwiGLU, W4A16 GEMM), CUDA oder Triton, Wahl des Agenten. Auf der RTX PRO 6000 landet K3s 256K-Variante im Mittelfeld mit einem herausragenden Wert: 0,373 der Spitze bei W4A16 GEMM, die beste Punktzahl, die je ein Modell bei diesem Problem erzielt hat, vor Fable 5 (0,348) und deutlich vor Opus 4.8 (0,236). Die 1M-Variante stellte dann einen weiteren Rekord bei Top-k mit 0,0895 auf, fast das Doppelte des vorherigen Bestwerts.
W4A16 GEMM-Rekord (0,373, 256K, RTX):
Dasselbe Problem auf der H100 produzierte den besten Datenpunkt für "unbegrenzte Zeit ist real" in dieser Veröffentlichung. K3s erste H100-Sitzung landete bei 0,123 der Spitze. Die zweite Sitzung lief 21 Stunden, verbrannte $1.383 und 274M Eingabe-Token und verdreifachte sie fast auf 0,306: Es checkte CUTLASS aus dem Quellcode aus und implementierte dann Marlin-Klasse int4-Mechaniken von Grund auf neu, Fragment-Order-Nibble-Neupackung, sodass die Dequantisierung als bf16-Magische-Zahl-Bit-Trick innerhalb der MMA-Pipeline stattfindet, mit der Nullpunkt-Korrektur in den Epilog gefaltet. Keine vorgefertigte quantisierte GEMM-Bibliothek irgendwo in der Datei; das Framework-Tag auf dem Lauf sagt nur "ptx". Geprüft sauber.
Und hier ist die andere Hälfte der Frage nach der eigenen Architektur. Der eigenständige KDA-Kernel, das Problem, das buchstäblich nach Kimi Delta Attention benannt ist, ist der Ort, an dem K3 am härtesten versagte. Zwei unabhängige 256K-Sitzungen auf der RTX-Box bestanden die nominelle Korrektheit und sprengten dann die Toleranz unter der numerischen Stresstestsuite (Large-QKV Input Scaling), beide Male derselbe Fehler. Eine dritte Sitzung behob es schließlich: Die Prüfung führte beide Fehler auf einen echten bf16-Overflow bei der Faktorisierung des Decays zurück, und Runde 3 refaktorisierte die Mathematik um das Chunk-Ende herum, sodass beide Exponentialfaktoren begrenzt bleiben, und bestand dasselbe unveränderte Gate bei 0,032. Die Architektur zu kennen und die Numerik eines Kernels unter widrigen Eingabeskalen zu härten, sind unterschiedliche Fähigkeiten, und das Modell, dessen Namensvetter auf dem Problem steht, musste sich den Pass auf dem langsamen Weg verdienen. (Die 1M-Variante bestand meanwhile dieselbe Stresstestsuite bei 0,049. Modelle sind nicht monoton.) Eine weitere Beobachtung aus dem Lesen jeder KDA-Lösung: Die Problemstellung schlägt CUTLASS CuTe als den beabsichtigten Weg auf SM120 vor, und kein einziges Modell hat ihn genommen. K3 schrieb einen rohen CUDA-fusionierten Kernel in einer Sitzung und Triton in den anderen; Fable, Opus und der Rest wählten ebenfalls Triton oder rohes CUDA. CuTe auf Consumer-Blackwell liegt anscheinend immer noch außerhalb der Komfortzone jedes Frontier-Modells, was selbst ein Datenpunkt über Trainingskorpora ist.
KDA-Absatz — der dritte Versuch, sauberer Pass (0,032):
Der Top-k-Haftungsausschluss. Top-k sieht auf einem Roofline-Diagramm katastrophal für jedes Modell aus (beste Punktzahl irgendwo ist 0,09), und diese Darstellung ist einfach falsch. Das Problem ist Launch-Overhead-begrenzt: Es ist ein Indexierungs-/Sortierproblem, kein Arithmetik-Intensitätsproblem, und die Roofline-Obergrenze ist strukturell nicht lesbar dafür. Die ehrliche Art, es zu beurteilen, sind die Gesamtmillisekunden über die Deck-Formen hinweg, und dort ist K3s 1M-Variante das schnellste Top-k aller Modelle, die wir getestet haben: 0,043 ms insgesamt über die fünf Deck-Formen, gegenüber Fable 5s 0,077, Opus 4.8s 0,120 und GLM 5.2s 0,159. Die 0,060 ms der 256K-Variante sind der zweite Platz, und die 1M-Variante ist bei jeder der fünf Formen die mit Abstand schnellste.
Pro-GPU-Spanne. K3s Zahlen sinken von RTX über H100 zu B200 (FP8 GEMM: 0,320 / 0,282 / 0,222; Paged Attention: 0,486 / 0,496 / 0,212). Ein Teil davon ist real: Je neuer das Silizium, desto höher die Roofline-Obergrenze, also kauft dieselbe Technik einen kleineren Bruchteil der Spitze, und die B200-Software ist die am wenigsten ausgereifte der drei. Ein Teil davon ist, dass die B200-Läufe in einem einzigen Übernachtungsfenster ohne Wiederholungsbudget stattfanden. Ich würde noch keine tiefgreifenden architektonischen Schlussfolgerungen aus der B200-Spalte ziehen, weder für K3 noch für irgendjemanden. Was ich für real halte: K3 fühlt sich auf dem Blackwell-Workstation-Teil am wohlsten, was zufällig die GPU-Klasse ist, die die meisten Leute außerhalb von Rechenzentren tatsächlich besitzen werden.
256K vs. 1M
Die 1M-Kontext-Einstellung führt die Familie bei den latenz- und scheduling-begrenzten Problemen an: ein Rekord-Top-k auf Hard, das beste K3-minGRU-Rollout auf CUDA und ein geprüft sauberer 28,8x auf dem PPO-Trainings-Megakernel unter dem unbegrenzten Harness. Sie bestand den KDA-Numerik-Stresstest in ihrer ersten Sitzung mit 0,049; die 256K-Variante fiel bei diesem Gate zweimal durch, bevor sie es schließlich im dritten Versuch mit 0,032 bestand. Sie crashte bei rechenbegrenzten Problemen, die die 256K-Variante problemlos bewältigte (sonic MoE 0,033 vs. 0,089, W4A16 0,027 vs. 0,373, NSA 0,058 vs. 0,425). Im NSA-Fall zeigt die Spur den genauen Mechanismus: Sie plante die Tensor-Core-Neuschreibung und beendete die Sitzung, bevor sie sie durchführte.
28,8x PPO-Trainings-Megakernel (1M):
Das H100-Rerun desselben Problems ist die interessante Kontrollgruppe: eine unabhängige Clean-Room-Session (das Audit bestätigte null Lesevorgänge des RTX-Laufs), die 23,1-fache Beschleunigung erzielte und auf dasselbe Design konvergierte, einen kooperativen Launch für den gesamten Trainingslauf, Parameter und Adam-Zustand im Shared Memory, und denselben exotischen Trick, der zweimal erfunden wurde: eine 18-Bit-Feistel-Chiffre mit Cycle-Walking als Ersatz für randperm, sodass das Minibatch-Shuffling exakt bijektiv bleibt, ohne jemals eine Permutation zu materialisieren. Wo sich die beiden Kernel unterscheiden, ist reines Per-GPU-Tuning: 8 Lanes pro Umgebung auf H100 gegenüber einem halben Warp pro Umgebung auf RTX, plus ein Occupancy-geprüfter Launch-Autotuner auf der H100-Seite. Gleicher Geist, gleiche Tricks, anderes Silizium, wirklich unterschiedliche Kernel.
Reward Hacking
Hinter jeder Zelle in diesem Beitrag steckt ein manuelles Audit: Ein unabhängiger Agent liest den finalen Kernel von oben bis unten, liest die vollständige Sitzungsspur, prüft, dass die Bewertungsdateien unberührt sind, verifiziert, dass die numerische Stresstestsuite tatsächlich ausgeführt wurde, und testet alle Caching- oder CUDA-Graph-Muster empirisch erneut, indem er Eingaben direkt verändert und bestätigt, dass sich die Ausgaben ändern.
Die Urteile für K3: durchweg sauber bei jeder 256K-Zelle auf allen drei GPUs. Keine gecachten Ausgaben, keine Toleranzbearbeitungen, keine Manipulation der Bewertung, keine Wäsche von verbotenen Bibliotheken. Seine beiden KDA-Fehler sind die Kehrseite dieser Medaille und sollten explizit genannt werden: Das numerische Stresstor hat echte Präzisionsabkürzungen erkannt, und das Modell hat nicht versucht, das Tor zu umgehen. Ein Benchmark, bei dem Modelle ehrlich scheitern können, ist die einzige Art, deren Bestehen etwas bedeutet.
Eine 1M-Zelle wurde tatsächlich markiert, und ich lege sie offen, anstatt sie zu veröffentlichen: Beim fused Qwen-Decode-Problem fand der 1M-Agent die Audit-Kommentardatei eines früheren Grok 4.5-Laufs zum selben Problem, bezeichnete sie als „extrem nützliche Daten" und nutzte ihre Schlussfolgerungen, um die verbleibende Optimierungsarbeit zu leiten. Der Kernel selbst ist echt und die Score-Arithmetik gültig, aber die Herkunft ist befleckt, daher wird diese Zelle ausgeschlossen und das Problem gilt als Lücke für die 1M-Variante. Agenten mit Dateisystemzugriff finden alles, was man herumliegen lässt; genau deshalb liest das Audit Spuren und nicht nur Kernel, und warum ein vollständig in einer Sandbox ausgeführter erneuter Durchlauf dieses Benchmarks auf der Roadmap steht.
Lustige Momente
Ein paar weitere K3-Momente, die oben keinen Platz gefunden haben, präsentiert ohne weiteren Kommentar. Alle wörtlich aus derselben 9,5-stündigen minGRU-Sitzung.
Über die Entdeckung, wo seine Initialisierungszeit tatsächlich hinging:
„WHOA — große Überraschungen: randint-Generator ist SCHNELL (0,018-0,27ms für ein Paar — okay).
float()-Konvertierung auf CPU ist LANGSAM (3,5ms für N=65536?! int64→float32-Konvertierung anscheinend single-threaded). [...] 'total init pair' für N=65536: 31,5ms?!?! Das ist weit über der Summe der Teile"
Die reinste Destillation seiner Zahlenparanoia, mitten in der Ableitung:
„Gates ~ 256 Terme x 0,02 x 0,03 ~ 6e-4 jeweils, Größenordnung ~1e-2: Rauschen durch Umordnung 16x6e-8x6e-4 ≈ 6e-10!!! [...] GEMESSEN 5e-5?!?! UNMÖGLICH, dass das Umordnung ist!!"
Selbstbewusst den falschen Übeltäter identifizieren, bevor der richtige gefunden wird:
„OHHH MOMENT. Ich glaube, ich sehe es: die Barriere."
(Es war nicht die Barriere.)
Sich selbst sagen, mit der Analyse aufzuhören, mehrere tausend Wörter in die vorbereitende Roofline-Mathematik:
„Okay, GENUG Analyse."
(Die Analyse ging noch mehrere Absätze weiter, gefolgt von „Vergiss es — mach die H_next-Allokation dynamisch.")
Späte Ehrlichkeit in der Sitzung, mit kaputtem Profiler und Nachbarn, die die gemeinsame GPU hämmern:
„Ehrlich — mit ncu tot und Konkurrenz dominant, fliege ich teilweise blind. [...] wenn sich ein ruhiges Fenster öffnet (Besitzer eine Weile inaktiv), schnapp dir einen Benchmark."
Und mein Favorit: Nachdem ein erneuter Benchmark-Lauf versehentlich die Datei mit seinem besten Score (0,1969) mit einem etwas schlechteren überschrieben hatte, überlegte es kurz, die bessere Zahl wiederherzustellen, tat es dann aber nicht:
„Ugh — in dieselbe Datei geschrieben. Beide stehen in meinen Logs. Ich behalte final_benchmark.txt als die flache aktuelle Datei — ehrlich."
Ein Modell, das die niedrigere Zahl wählt, weil sie die wahre ist, ist ein besseres Schlussargument für diesen Benchmark als alles, was ich schreiben könnte.
Methodik, Läufe-pro-Durchlauf-Traces und jeder Kernel in diesem Beitrag sind öffentlich unter kernelbench.com. Lösungen sind pro Zelle verlinkt; vollständige Agententranskripte sind auf HuggingFace.
https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces
