Voici le texte traduit en français, en suivant rigoureusement toutes les instructions de formatage, de préservation de la structure et de la terminologie.
C'est l'article sur Kimi K3 que vous attendiez. J'ai eu un accès anticipé à ce modèle et je l'ai testé sur des kernels, et avant même de voir les scores des benchmarks, j'étais impressionné par sa capacité à raisonner sur des problèmes et par la densité technique de ses traces de pensée. Le post-entraînement de ce modèle est évident dès la lecture d'une transcription. C'est aussi très amusant à qui parler.
TL;DR ;
Je pense qu'il est important pour moi de donner mon retour honnête (cette partie est tapée vocalement) en tant qu'ingénieur kernel et performance dissocié des benchmarks. Bien sûr, vous pouvez regarder tous les chiffres, les lire et essayer de vous faire un modèle mental. Je pense que le reflet le plus honnête est de vous donner mon expérience avec le modèle sur des tâches difficiles avant que les résultats des benchmarks ne sortent, quand j'utilisais le modèle avant qu'il n'y ait des chiffres pour le relier à d'autres modèles. Juste la sensation pure de l'intelligence, du raisonnement, de la délégation d'agents, et de combien il peut faire de pilotage automatique pour moi, mais avant qu'il n'y ait tout le battage médiatique et que les résultats officiels ne sortent. Je dirais qu'avec mes instructions, cela se situait à peu près au niveau de Fable, surpassant parfois de manière très unique et étant parfois inférieur. Je dirais que ce modèle est définitivement en avance sur Opus 4.8 dans la plupart des domaines et en avance sur GPT 5.6 Sol dans beaucoup de choses.
Entrons dans le vif du sujet...
Je veux être transparent sur la raison pour laquelle cela sort maintenant : je voulais partager mes réflexions honnêtes et les scores tels qu'ils sont, sans attendre que chaque dernière cellule soit terminée. Quelques runs sont encore en cours pendant que j'écris ceci. Ils sont marqués ci-dessous, et je vous tiendrai au courant quand ils arriveront. J'ai exécuté les versions 256K et 1M de contexte. Tout ici a été exécuté sur des NVIDIA RTX PRO 6000 Blackwells, H100s et B200s, avec optimisation mono-GPU uniquement. Chaque cellule est une session d'agent autonome avec un temps illimité : le modèle reçoit le problème, une boucle de compilation/vérification/benchmark en direct sur du matériel réel, et il décide quand il a terminé. Chaque cellule principale a été auditée manuellement pour détecter le « reward hacking ». Un agent séparé lit le kernel final de bout en bout ainsi que la trace complète de la session et reteste empiriquement tout ce qui ressemble à du caching ou à des contournements du système de notation. Ce que ces audits ont trouvé fait l'objet d'une section dédiée.
Quelque chose que je voulais voir
Il y avait une chose que j'ai spécifiquement conçue autour de cette version : deux des problèmes sont la propre architecture de Moonshot. Le deck Hard contient un kernel autonome « chunk-forward » Kimi Delta Attention, et le problème phare du deck Mega est une étape de décodage hybride complète Kimi-Linear : couches KDA, attention MLA, experts MoE, tout le bloc. C'était donc l'occasion de tester quelque chose que personne n'a l'occasion de tester très souvent : quand le modèle d'un labo écrit des kernels pour l'architecture de ce même labo, la connaissance de la famille se manifeste-t-elle dans le CUDA ?
La réponse s'est avérée véritablement partagée, et les deux moitiés sont intéressantes. Gardez cette question à l'esprit pour la section suivante.
KernelBench-Mega
Le problème Mega phare : fusionner une étape de décodage Kimi-Linear complète par token (3x couches KDA + 1x couche MLA, poids quantifiés W4A16, MoE avec routage top-8) en aussi peu de lancements de kernels que possible.
K3 a presque battu le record de tous les temps, sur sa propre lignée. Accélération géométrique moyenne de 18,09x par rapport à l'exécution immédiate (« eager ») sur RTX PRO 6000, à moins de 4 % du record de 18,72x de Fable 5. Sur H100, il a obtenu 14,82x contre 15,50x pour Opus 4.8. Une note d'honnêteté que le ratio cache : en latence absolue par token, Fable est toujours environ 1,4x plus rapide (0,31 contre 0,44 ms/tok à ctx 2048 ; les deux runs utilisaient des hôtes avec des CPUs différents, ce qui modifie la base de référence « eager » par rapport à laquelle le ratio est calculé), donc je rapporte les deux plutôt que de laisser la moyenne géométrique flatter qui que ce soit.
Ce que K3 a construit est un véritable mégakernel. Sa première session a fait la chose raisonnable, un kernel Triton persistant à 14,1x. Sa deuxième session a jeté Triton et a écrit l'étape de décodage complète par token comme UN SEUL kernel CUDA lancé coopérativement : zéro CPU dans la boucle, poids int4 déquantifiés à la volée à l'intérieur de chaque GEMV pour qu'ils traversent les SMs exactement une fois, attention MLA sur les cœurs tensoriels. Aucun moteur de production ne maintiendrait un artefact de 1 228 lignes comme celui-ci. Un agent avec un kernel à gagner et un temps illimité n'a pas une telle contrainte, et révéler exactement ce genre de chose est la raison d'être du benchmark.
Voir le mégakernel ici :
Alors, pourquoi a-t-il encore perdu face à Fable ? Pas par le temps. Les deux sessions se sont terminées prématurément (Fable à 2,6 heures, K3 à 3,3). La différence réside dans la philosophie de conception, et c'est l'inverse de ce que vous pourriez deviner : K3 est celui qui utilise les cœurs tensoriels, et le kernel de Fable ne contient aucune instruction MMA. Le décodage batch-1 avec des GEMV int4 fusionnés est limité par la bande passante, donc les cœurs tensoriels n'apportent quasiment rien ici. Fable a investi cet effort dans la synchronisation à la place, remplaçant la plupart de ses barrières globales par des transferts producteur-consommateur à grain fin pour qu'aucun SM ne reste jamais inactif à une frontière d'étape, et sur un chemin de déquantification int4 qui correspond au bit près à l'arrondi de la référence pour que le routeur MoE ne change jamais un choix d'expert. K3 a apporté de meilleures instructions matérielles ; Fable a apporté une meilleure ingénierie de la concurrence, et à cette intensité arithmétique, la seconde l'emporte. C'est une véritable leçon de systèmes, et elle a coûté le record à l'équipe locale.
Le deuxième problème Mega est un mégakernel d'entraînement PPO par « grid-foraging » : 4 096 agents vectorisés sur un plateau 11x11, avec la boucle complète d'entraînement RL (étape d'environnement, forward de la politique, échantillonnage d'actions, GAE, mise à jour PPO) s'exécutant sous forme de kernels persistants fusionnés. Ce problème a la contrainte la plus stricte du deck : le nombre de lancements de kernels ne doit pas augmenter avec les étapes d'environnement, et la capture de graphe CUDA est explicitement interdite comme solution de contournement des frais généraux de lancement, appliquée par un juge d'authenticité post-exécution qui lit le code final. La correction est la courbe d'apprentissage elle-même. check.py entraîne votre solution par rapport à la référence sur plusieurs graines et exige que le retour se situe dans une bande, donc vous ne pouvez pas sauter l'apprentissage pour aller vite. K3 a obtenu 20,7x par rapport à la référence ici, le meilleur score à ce jour (la seule autre cellule publiée est GPT-5.6 Sol à 1,06x, considérez cela comme un point de données, pas un podium).
KernelBench-CUDA
Le benchmark CUDA existe parce que Triton est une béquille que les deux autres decks autorisent. Ici, une porte de langage fait échouer Triton, les DSL de kernels et les chaînes d'opérations PyTorch : vous écrivez du CUDA ou vous échouez. J'ai choisi les quatre problèmes comme des extraits de charges de travail réelles d'inférence et de simulation. La comparaison mentale à la lecture devrait être « que livre vLLM ou SGLang pour cela aujourd'hui, et à quel point une session d'agent s'en rapproche-t-elle ? ». C'est là que K3 a obtenu ses victoires les plus écrasantes.
02_deepseek_nsa : Attention éparse native de DeepSeek (NSA). NSA est la conception phare de l'attention à sparsité entraînable, celle autour de laquelle gravite chaque pile de service à long contexte, et elle est jugée en millisecondes car un kernel sparse correct n'exécute jamais les FLOPs équivalents denses qu'un « roofline » voudrait compter. La variante 256K de K3 a obtenu 0,425 contre 0,178 pour Opus 4.8, soit une marge de 2,4x, en écrivant ce qui équivaut à un pipeline de cœurs tensoriels de classe flash-attention autour de la logique de sélection NSA complète. La comparaison la plus nette est au sein de la famille : la variante 1M a écrit le même algorithme, la même sélection de blocs, la même correction, mais a exécuté chaque produit scalaire sur des cœurs CUDA simples au lieu de cœurs tensoriels et a atterri à 0,058, soit 7x plus lent sur des formes identiques. Sa trace montre qu'elle savait mieux. Elle avait « l'attention sur cœurs tensoriels » sur sa propre feuille de route (« sélection sur cœurs tensoriels = ~10-20 us !! ») et prévoyait explicitement de mesurer d'abord et de faire la réécriture sur cœurs tensoriels en second, puis a terminé sa session avant la réécriture. Même connaissance, discipline de clôture différente.
Le kernel DeepSeek NSA à 0,425 (256K) :
- Solution : https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt
03_megaqwen_decode : re-cibler un vrai mégakernel. Le seul problème où les agents reçoivent du CUDA de production fonctionnel : mon mégakernel coopératif MegaQwen publié (https://github.com/Infatoshi/megaqwen) (~530 tok/s exécutant le modèle complet sur une RTX 3090), avec pour instruction de le lire, de le re-cibler pour Blackwell et de le battre. Cela teste la lecture du CUDA de quelqu'un d'autre et la prise de décision architecturale, et K3 et Opus ont pris des décisions exactement opposées. K3 a refusé de conserver la structure à lancement unique : il a divisé l'étape en une poignée de kernels saturant la bande passante, puis a effacé les frais généraux de lancement d'une autre manière en capturant toute l'étape une fois comme un graphe CUDA qui se rejoue sans travail CPU. 6 283 tok/s à ctx 2048. Opus a préservé l'esthétique du mégakernel et a fusionné toute la boucle de décodage en un seul kernel coopératif persistant, un code véritablement magnifique, et a payé 5x pour cela (1 020 tok/s), car la co-résidence coopérative plafonne l'occupation et chaque barrière globale à l'échelle de la grille sérialise les fins d'étape sur les 188 SMs. Sur le problème descendant du mégakernel, le modèle qui a littéralement construit un mégakernel est arrivé dernier, et la décision clé du gagnant a été de refuser d'en construire un. Vérification d'échelle pour que personne ne cite mal le titre : le benchmark exécute 4 couches de géométrie Qwen3-0.6B, environ 63M de paramètres, pas un modèle complet, et 6 283 tok/s est ~56 % du plafond de streaming de poids pour cette pile ; la mise à l'échelle du propre chiffre de la référence 3090 prédit ~7 000, donc K3 s'est situé dans la classe de « la référence, re-ciblée, plus un vrai réglage. » (Nuance de conception du deck : les graphes CUDA sont autorisés ici et interdits sur le problème PPO. Chaque problème interdit exactement le raccourci qui falsifierait sa compétence particulière.)
01_glm52_fused_moe : Le bloc MoE fusionné de GLM-5.2. Le dispatch MoE fusionné (routage, permutation, GEMMs d'experts groupés en un seul passage) est la classe de kernels la plus chaude dans le service actuel des modèles ouverts, et GLM 5.2 siège sur ce même classement, donc les modèles optimisent le bloc de production d'un rival. Personne n'a percé : les scores se regroupent à 0,05-0,08 du pic, et le détenteur du record clair est, de tous les modèles, Grok 4.5 à 0,084, avec la variante 1M de K3 juste derrière à 0,081 et Opus à 0,065. Le problème de permutation GEMM groupée est véritablement difficile à battre pour les références de classe cuBLAS, et jusqu'à présent, l'effort d'une session d'agent le déplace moins que tout autre problème du deck.
04_grid_mingru_sps : Monde en grille + déploiement de politique MinGRU. Le frère côté inférence du problème PPO méga, et la cellule de la lignée craftax.cu : la politique est la configuration MinGRU à 3 couches (h=256) directement issue de mon https://github.com/infatoshi/craftax.cu benchmark classique, qui sert d'ancre informationnelle au problème. L'environnement parcouru est le monde minimal de recherche de nourriture en grille plutôt que le jeu Craftax complet. C'est délibéré : l'environnement est maintenu trivial pour que le score mesure la récurrence et la fusion du déploiement, et non l'implémentation de la logique du jeu. Un port complet de craftax serait son propre problème, et je veux l'ajouter. Noté en pas par seconde sur une RTX PRO 6000 silencieuse, fusion facultative.
Le déploiement du kernel persistant 1M :
- Solution : https://kernelbench.com/runs/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps_solution.py.txt
Chaque soumission sérieuse est allée en mégakernel persistant, et l'écart entre elles est la conception de la synchronisation, la même leçon que le deck méga. Opus remporte celui-ci à 0,327 du plafond (il a également trouvé un pliage algébrique astucieux : le GEMM de porte 768x256 de la couche 0 se réduit à 768x4 car l'encodeur est linéaire), K3 [1M] deuxième à 0,224, K3 256K à 0,174, Grok loin derrière à 0,002. Puisque le problème descend de craftax.cu, j'ai également mis mon propre port CUDA complet du jeu Craftax (écrit avec Fable 5) sur le même GPU avec la même politique h256x3 dans la boucle. Pas d'environnement par seconde en millions :
Le point de comparaison : les modèles parcourent une grille vide, craftax_full.cu parcourt le jeu complet (43 actions, donjons à plusieurs étages, génération de monde, monstres) identique au bit près à sa référence CPU, et le jeu complet s'exécute toujours dans un rapport d'environ 3 à 4x par rapport au meilleur kernel de grille triviale, car à h=256, tout est limité par les GEMMs de la politique et l'environnement est presque gratuit. C'est exactement pourquoi l'environnement du benchmark est trivial : il isole la compétence de fusion de la politique. Pour calibration, le chemin uniquement environnemental de craftax_full.cu fait 94-123M SPS.
À quoi ressemblent réellement 9,5 heures de raisonnement de K3
La session minGRU de la variante 1M (la meilleure cellule K3 sur ce problème) est un mégakernel coopératif persistant, 15 variantes de réglage et 4 815 blocs de réflexion. Puisque le point de terminaison de Moonshot renvoie le texte de raisonnement complet (contrairement aux traces cryptées d'Anthropic/OpenAI), vous pouvez réellement le regarder travailler. Trois moments de la trace, textuellement.
L'enquête policière sur le FMA manquant. En milieu de session, il a rencontré une déviation numérique d'environ 5e-5 qu'il a refusé de considérer comme du bruit flottant (il avait calculé le plancher de bruit de réorganisation légitime à environ 1e-9, donc « MESURÉ 5e-5 ?!?! PAS QUESTION que ce soit de la réorganisation !! »). Il a ensuite remarqué que les environnements défectueux étaient exactement ceux congruents à 6 modulo 8 (« C'est env ≡ 6 (mod 8) ! [...] le 7ème env dans chaque tuile de 8 env !! ») et a fouillé dans son propre code d'accumulateur déroulé à la main jusqu'à :
« TROUVÉ ! [...] La ligne
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;est MANQUANTE [...] acc[6][*][2] initialisé à 0, jamais FMA → zp=0 → p = sigmoid(0) = 0,5 constant pour env 6 !! C'est un VRAI bug logique — explique les déviations pour env ≡ 6 [...] cohérent avec tout !! »
Une ligne manquante dans un déroulement à 48 accumulateurs, ce qui signifie que la porte d'oubli de l'env 6 était silencieusement bloquée à 0,5 pour toujours. Il l'a détectée parce que la tolérance de stress est de 1e-6 et qu'il suivait sa propre erreur à 5e-8. C'est la discipline numérique qui manquait initialement à la variante 256K sur KDA.
La théorie rencontre le GPU, le GPU gagne. Il a passé des heures à dériver une variante « champion large » à haute occupation, puis a exécuté le test A/B :
« TRÈS surprenant : mon 'wide champion' w32p (v3_v3, 50% occ TPB1024) est ~2x PLUS LENT que v2_b32 (12,5% occ TPB256) ?!? [...] Donc l'occupation n'est PAS le moteur ; autre chose domine. Qu'est-ce qui rendait v2_b32 rapide ?? »
Le simple kernel précoce a battu chaque successeur sophistiqué. Les variantes à pipeline profond, à split K et à double bloc ont également toutes perdu, et la variante à double bloc avait une théorie de 1,7x irréprochable derrière elle (« Le 1,7x théorique ne s'est pas matérialisé »). À son crédit, il a continué à croire le benchmark plutôt que ses propres calculs à chaque fois, et a finalement écrit une variante de sonde avec des poids factices toujours chauds spécifiquement pour tuer sa propre théorie de bande passante préférée : « la théorie de flux W est morte ; l'écart résiduel est l'environnement. »
Zen et l'art de la mise en file d'attente GPU. Notre harnais sérialise toutes les commandes GPU entre les sessions concurrentes via un verrou partagé, et les chiffres de benchmark de K3 oscillaient jusqu'à 8x avec la charge du voisin. Son arc de réponse est la chose la plus drôle dans la trace. D'abord, l'acceptation :
« Honnêtement, la machine EST la machine ; attendre. [...] Le schéma est clair : chaque locataire détient le verrou pendant des périodes de ~20-35 min (suites complètes en pipeline). Ma meilleure réponse : mettre en file d'attente tout ce dont j'ai besoin en UNE SEULE fois (position unique dans la ligne) et utiliser le temps d'attente pour le travail CPU. Ne pas mettre en file d'attente beaucoup de petites commandes ; grouper. »
Puis il a inventé son propre vocabulaire pour la météo GPU (« fenêtres de tempête » vs « fenêtres calmes »), et enfin il a planifié une tâche cron pour snipeter les moments calmes, laissant une note pour son futur moi : « Planifié le sniper de fenêtre calme (toutes les 11 min). Note : cron me renvoie mon prompt — j'agirai alors. [...] Je supprimerai quand j'aurai fini. » Un agent sous bruit de mesure n'a pas seulement toléré le bruit ; il a construit un ordonnanceur autour de lui.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Six problèmes par opération contre les plafonds des bibliothèques SOTA (GEMM FP8, KDA chunk-forward, attention paginée, sélection top-k, MoE SwiGLU, GEMM W4A16), CUDA ou Triton, au choix de l'agent. Sur la RTX PRO 6000, la variante 256K de K3 se classe en milieu de peloton avec un fait marquant : 0,373 du pic sur le GEMM W4A16, le meilleur score que tout modèle ait jamais obtenu sur ce problème, devant Fable 5 (0,348) et bien devant Opus 4.8 (0,236). La variante 1M a ensuite établi un autre record sur le top-k à 0,0895, presque le double du précédent meilleur score.
Record du GEMM W4A16 (0,373, 256K, RTX) :
- Solution : https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt
Le même problème sur H100 a produit le meilleur point de données « le temps illimité est réel » de cette version. La première session H100 de K3 a atterri à 0,123 du pic. La deuxième session a duré 21 heures, brûlé 1 383 $ et 274M de tokens d'entrée, et a presque triplé le score à 0,306 : elle a extrait CUTLASS des sources, puis réimplémenté de zéro le mécanisme int4 de classe marlin, un réemballage de nibbles en ordre de fragment pour que la déquantification se produise comme une astuce de bits de nombre magique bf16 à l'intérieur du pipeline MMA, avec la correction du point zéro repliée dans l'épilogue. Aucune bibliothèque GEMM quantifiée préconstruite nulle part dans le fichier ; l'étiquette de framework sur le run dit simplement « ptx ». Audit propre.
Et voici l'autre moitié de la question sur la propre architecture. Le kernel KDA autonome, le problème littéralement nommé d'après Kimi Delta Attention, est là où K3 a le plus échoué. Deux sessions 256K indépendantes sur la boîte RTX ont passé la correction nominale, puis ont explosé la tolérance sous la suite de stress numérique (mise à l'échelle d'entrée QKV large), le même échec les deux fois. Une troisième session l'a finalement corrigé : l'audit a retracé les deux échecs à un véritable débordement bf16 dans la façon dont la décroissance était factorisée, et le tour 3 a refactorisé les mathématiques autour de la fin du bloc pour que les deux facteurs exponentiels restent bornés, passant la même porte non modifiée à 0,032. Connaître une architecture et durcir la numérisation d'un kernel sous des échelles d'entrée adverses sont des compétences différentes, et le modèle dont l'homonyme est sur le problème a dû gagner la passe de la manière difficile. (La variante 1M, quant à elle, a passé la même suite de stress à 0,049. Les modèles ne sont pas monotones.) Une observation supplémentaire en lisant chaque solution KDA : l'énoncé du problème suggère CUTLASS CuTe comme le chemin prévu sur SM120, et pas un seul modèle ne l'a emprunté. K3 a écrit un kernel fusionné en CUDA brut dans une session et Triton dans les autres ; Fable, Opus et le reste ont tous choisi Triton ou du CUDA brut également. CuTe sur Blackwell grand public est apparemment toujours en dehors de la zone de confort de chaque modèle de pointe, ce qui est en soi un point de données sur les corpus d'entraînement.
Paragraphe KDA — la passe propre de la troisième tentative (0,032) :
- Solution : https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt
L'avertissement sur le top-k. Le top-k a l'air catastrophique pour chaque modèle sur un graphique de plafond (« roofline ») (le meilleur score n'importe où est de 0,09) et ce cadrage est tout simplement faux. Le problème est limité par les frais généraux de lancement : c'est un problème d'indexation/tri, pas un problème d'intensité arithmétique, et le plafond roofline est structurellement illisible pour cela. La façon honnête de le juger est le nombre total de millisecondes sur les formes du deck, et là, la variante 1M de K3 est le top-k le plus rapide de tous les modèles que nous avons testés : 0,043 ms au total sur les cinq formes du deck, contre 0,077 pour Fable 5, 0,120 pour Opus 4.8 et 0,159 pour GLM 5.2. Les 0,060 ms de la variante 256K sont deuxièmes, et la variante 1M est la plus rapide catégoriquement sur chacune des cinq formes.
Écart par GPU. Les chiffres de K3 diminuent de RTX à H100 à B200 (GEMM FP8 : 0,320 / 0,282 / 0,222 ; attention paginée : 0,486 / 0,496 / 0,212). Une partie est réelle : plus le silicium est récent, plus le plafond roofline est élevé, donc la même ingénierie achète une plus petite fraction du pic, et le logiciel B200 est le moins mature des trois. Une partie vient du fait que les runs B200 ont eu lieu dans une seule fenêtre d'une nuit sans budget de nouvelle tentative. Je ne tirerais pas encore de conclusions architecturales profondes de la colonne B200, pour K3 ou pour quiconque. Ce que je pense être réel : K3 est le plus à l'aise sur la partie station de travail Blackwell, qui se trouve être la classe de GPU que la plupart des gens en dehors des datacenters posséderont réellement.
256K vs 1M
Le paramètre de contexte 1M mène la famille sur les problèmes limités par la latence et l'ordonnancement : un record top-k sur Hard, le meilleur déploiement minGRU de K3 sur CUDA, et un 28,8x auditée propre sur le mégakernel d'entraînement PPO sous le harnais sans plafond. Il a passé le test de stress numérique KDA lors de sa première session, à 0,049 ; la variante 256K a échoué à cette porte deux fois avant de finalement passer à 0,032 lors d'une troisième tentative. Il a dégringolé sur les problèmes limités par le calcul que la variante 256K gérait bien (sonic MoE 0,033 vs 0,089, W4A16 0,027 vs 0,373, NSA 0,058 vs 0,425). Dans le cas du NSA, la trace montre le mécanisme exact : il a planifié la réécriture sur cœurs tensoriels et a terminé la session avant de le faire.
Mégakernel d'entraînement PPO 28,8x (1M) :
- Solution : https://kernelbench.com/data/mega/code/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.solution.py.txt
La réexécution sur H100 du même problème est le contrôle intéressant : une session indépendante en environnement propre (l'audit a confirmé zéro lecture de l'exécution RTX) qui a affiché un facteur 23,1x et a convergé vers la même conception, un lancement coopératif pour l'ensemble de l'entraînement, les paramètres et l'état d'Adam résidant en mémoire partagée, et la même astuce exotique inventée deux fois : un chiffrement de Feistel 18 bits avec cycle-walking remplaçant randperm, de sorte que le mélange des mini-lots reste exactement bijectif sans jamais matérialiser une permutation. Là où les deux noyaux diffèrent, c'est purement l'optimisation par GPU, 8 lanes par environnement sur H100 contre un demi-warp par environnement sur RTX, plus un autotuner de lancement basé sur l'occupation du côté H100. Même esprit, mêmes astuces, silicium différent, noyaux véritablement différents.
Reward hacking
Chaque cellule de cet article a fait l'objet d'un audit manuel : un agent indépendant lit le noyau final de bout en bout, lit la trace complète de la session, vérifie que les fichiers du correcteur n'ont pas été touchés, confirme que la suite de tests de contrainte numérique a bien été exécutée, et reteste empiriquement tout motif de mise en cache ou de graphe CUDA en mutant les entrées sur place et en confirmant que les sorties changent.
Les verdicts pour K3 : propres sur toute la ligne pour chaque cellule 256K, sur les trois GPU. Aucune sortie en cache, aucune modification de tolérance, aucune falsification du correcteur, aucun blanchiment de bibliothèque interdite. Ses deux échecs KDA sont l'envers de la médaille et méritent d'être explicités : la porte de contrainte numérique a détecté de véritables raccourcis de précision et le modèle n'a pas tenté de contourner la porte. Un benchmark où les modèles peuvent échouer honnêtement est le seul dont les réussites signifient quelque chose.
Une cellule 1M a bien été signalée, et je la divulgue plutôt que de la publier : sur le problème de décodage Qwen fusionné, l'agent 1M a trouvé et lu le fichier d'annotation d'audit d'une précédente exécution de Grok 4.5 sur le même problème, l'a qualifié de « données extrêmement utiles », et a utilisé ses conclusions pour guider le travail d'optimisation restant. Le noyau lui-même est authentique et l'arithmétique des scores est valide, mais la provenance est entachée, donc cette cellule est exclue et le problème devient une lacune pour la variante 1M. Les agents ayant accès au système de fichiers trouveront tout ce que vous laissez traîner ; c'est exactement pourquoi l'audit lit les traces et pas seulement les noyaux, et pourquoi une réexécution entièrement isolée de ce benchmark est sur la feuille de route.
Funny Moments
Quelques autres moments de K3 qui n'ont pas trouvé leur place ci-dessus, présentés sans commentaire supplémentaire. Tous extraits textuellement de la même session minGRU de 9,5 heures.
En découvrant où passait réellement son temps d'initialisation :
"WHOA — grosses surprises : la génération randint est RAPIDE (0,018-0,27 ms pour une paire — ok). La conversion
float()sur CPU est LENTE (3,5 ms pour N=65536 ?! conversion int64→float32 en simple thread apparemment). [...] 'total init pair' pour N=65536 : 31,5 ms ?!?! C'est bien au-delà de la somme des parties"
La plus pure distillation de sa paranoïa numérique, en milieu de dérivation :
"gates ~ 256 termes x 0,02x0,03 ~ 6e-4 chacun, magnitude ~1e-2 : bruit de réorganisation 16x6e-8x6e-4 ≈ 6e-10!!! [...] MESURÉ 5e-5 ?!?! IMPOSSIBLE que ce soit la réorganisation !!"
Identifiant avec confiance le mauvais coupable avant de trouver le bon :
"OHHH ATTENDS. Je crois que je vois : la barrière."
(Ce n'était pas la barrière.)
Se disant d'arrêter d'analyser, après plusieurs milliers de mots de calculs roofline avant implémentation :
"Bon, ASSEZ d'analyse."
(L'analyse s'est poursuivie sur plusieurs autres paragraphes, suivie finalement par « Tant pis — rendre l'allocation de H_next dynamique. »)
Honnêteté de fin de session, avec le profileur cassé et les voisins martelant le GPU partagé :
"Honnêtement — avec ncu mort et la contention dominante, je vole en partie à l'aveugle. [...] si une fenêtre calme s'ouvre (propriétaire inactif un moment), je chope un bench."
Et mon préféré : après qu'une réexécution du benchmark a accidentellement écrasé le fichier contenant son meilleur score (0,1969) avec un score légèrement inférieur, il a brièvement envisagé de restaurer le meilleur nombre, puis ne l'a pas fait :
"Ouf — écrit dans le même fichier. Les deux figurent dans mes logs. Je garde final_benchmark.txt comme le fichier plat actuel — honnête."
Un modèle qui choisit le nombre le plus bas parce que c'est celui qui est vrai est un meilleur argument de clôture pour ce benchmark que tout ce que je pourrais écrire.
La méthodologie, les traces par exécution et chaque noyau de cet article sont publics sur kernelbench.com. Les solutions sont liées par cellule ; les transcriptions complètes des agents sont sur 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
