Introduction
Fable 5 est devenu le centre d'une nouvelle discussion en ingénierie IA après avoir, selon les rapports, rédigé le premier véritable mégakernel CUDA soumis à KernelBench-Mega. Le résultat est frappant : une accélération du décodage de 18,71x sur une configuration RTX PRO 6000 Blackwell, produite au cours d'une seule session autonome d'environ 2 heures et demie.
Le titre n'est pas seulement qu'un système IA a écrit du code bas niveau rapide. Le point le plus important est la forme de la solution. Au lieu d'assembler plusieurs petits kernels GPU, Fable 5 a fusionné le flux de travail de décodage en un seul lancement de kernel coopératif par token. C'est ce qui a attiré l'attention des chercheurs et des ingénieurs.
![Image : tweet d'Elliot Arledge, photo de profil montrant un homme avec une casquette. Le tweet dit "Claude Fable 5 [max] a écrit le premier véritable (et le plus rapide) mégakernel jamais soumis à KernelBench-Mega." avec une traduction chinoise. Bouton "Subscribe" et icône à trois points en haut à droite. L'image est liée à la section présentant le premier véritable mégakernel de Fable 5 sur KernelBench-Mega, une annonce officielle de ce résultat.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/431a983a-5471-4a16-96a8-342eff6d0864-02-5fe28792-eb70-4fbf-8b72-848f2d0c7f66.png)
Cet article conserve la structure originale et le sens technique, mais réécrit l'histoire dans un anglais plus clair pour publication. Il explique ce que teste KernelBench-Mega, pourquoi ce résultat est important, en quoi le mégakernel diffère de la génération ordinaire de kernels GPU, et pourquoi certains chercheurs le relient à l'idée d'auto-amélioration récursive.
Fable 5 atteint 18,7x et devance GPT-5.5
Le résultat de référence provient de KernelBench-Mega, un benchmark axé sur la génération de mégakernels complets plutôt que sur l'optimisation d'opérateurs isolés. Dans cette exécution, Fable 5 a ciblé 02_kimi_linear_decode, une tâche de décodage hybride Kimi-Linear W4A16 utilisant des poids 4 bits et des activations bf16.
La configuration rapportée était stricte : une session autonome, un plafond de 3 heures en temps réel, et un véritable environnement de benchmark. Dans cette limite, Fable 5 a atteint une accélération du décodage de 18,71x par rapport à la référence PyTorch optimisée.

La comparaison rend le résultat plus facile à comprendre :
| Modèle | Accélération rapportée | Remarques |
|---|---|---|
| Fable 5 | 18,71x | Mégakernel CUDA, chemin de lancement fusionné unique |
| Claude Opus 4.8 | 14,40x | Bon résultat, mais pas le même schéma de mégakernel CUDA unique |
| GPT-5.5 | 4,34x | Accélération beaucoup plus faible sur cette tâche |
| Claude Sonnet 5 | 4,03x | Gamme similaire à GPT-5.5 sur ce classement |

oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/ce6c9cad-7360-4ac5-854b-279a01ab49ee-04-4d685459-6d03-4b22-840d-4e6787d38b10.png)
La répartition par longueur de contexte est également importante. Selon le classement affiché, Fable 5 est resté performant à mesure que le contexte s'allongeait :
- Contexte de 2K : environ 17,8x
- Contexte de 8K : environ 18,9x
- Contexte de 16K : environ 19,5x
Cela peut paraître contre-intuitif au premier abord. Un contexte plus long augmente généralement le coût de l'attention et de la gestion du cache KV. De nombreux systèmes commencent à perdre en performance. Le résultat de Fable 5 suggère que la conception fusionnée a suffisamment réduit les frais de lancement pour que son avantage relatif devienne plus important à mesure que la charge de travail s'alourdissait.

Pourquoi KernelBench-Mega est plus difficile qu'un benchmark de kernel normal
KernelBench-Mega ne demande pas simplement à un modèle d'affiner un petit opérateur. Il demande à l'agent de fusionner un bloc de modèle plus large en un mégakernel de bloc entier. Cela compte car la partie difficile n'est plus simplement d'écrire du code CUDA ou Triton syntaxiquement valide. La partie difficile consiste à gérer de nombreuses phases de calcul en interaction au sein d'un seul chemin efficace.
La tâche 02_kimi_linear_decode inclut une charge de travail de décodage hybride pour Kimi-Linear W4A16. En termes pratiques, le modèle doit gérer des poids quantifiés, des activations bf16, un état lié à l'attention, le routage, la normalisation et le comportement du cache.
C'est pourquoi ce benchmark est un test de résistance significatif pour le code de performance de bas niveau généré par l'IA. Une accélération simple sur un petit opérateur isolé est utile, mais un mégakernel de bloc complet est plus proche du type de travail d'optimisation qui peut affecter les systèmes d'inférence réels.
Le premier véritable « Mégakernel »
L'affirmation technique la plus importante est que Fable 5 a produit le premier véritable mégakernel dans l'histoire de KernelBench-Mega.
Un mégakernel compresse un chemin d'inférence plus large en un seul kernel. Au lieu de lancer plusieurs kernels séparés et de faire des allers-retours de contrôle, il maintient le travail à l'intérieur d'un flux d'exécution coordonné unique. C'est difficile car le kernel doit coordonner de nombreuses phases tout en préservant l'exactitude.
Dans ce cas, le rapport indique que torch.profiler a montré exactement un lancement de kernel coopératif par token décodé. Ce lancement unique a géré un travail qui serait normalement divisé en plusieurs étapes, notamment :
- Désquantification int4
- Convolution
- Activation SiLU
- État delta à grille KDA
- Gestion de l'attention latente MLA
- Routage MoE et sélection des 8 meilleurs experts
- Opérations liées à RMSNorm
- Écritures dans le cache KV

D'autres entrées ayant obtenu un score élevé auraient divisé le travail en 4 à 14 lancements de noyau distincts. Fable 5 a fusionné le chemin temporel en un seul lancement coopératif. C'est la différence entre un « code de noyau généré rapidement » et un artefact de programmation GPU beaucoup plus agressif.
Comment un seul lancement de noyau modifie le profil de performance
Les lancements de noyau ne sont pas gratuits. Chaque lancement entraîne une surcharge, des coûts de synchronisation et des lacunes de planification. Dans une charge de travail de décodage, ces coûts peuvent devenir particulièrement pénibles car le travail se répète jeton par jeton.
L'approche de Fable 5 réduit cette surcharge répétée en plaçant les étapes de décodage dans un seul chemin coopératif. Le rapport original décrit la solution comme utilisant 14 barrières de grille pour organiser le calcul à l'intérieur du même lancement.
C'est pourquoi le résultat ne concerne pas seulement une astuce mathématique intelligente. Il s'agit d'une exécution GPU au niveau du système. Lorsque d'autres solutions quittent et réintègrent les noyaux à plusieurs reprises, elles perdent du temps dans la transition. Fable 5 évite une grande partie de ce coût en maintenant le pipeline fusionné.
En termes simples : d'autres effectuent le travail en plusieurs trajets ; Fable 5 tente de le faire en un seul.
2,5 heures et environ 550 000 jetons
Un autre aspect notable de l'exécution est la façon dont le modèle a utilisé son temps. Il n'a pas immédiatement commencé à déverser du code CUDA final. La trace suggère un flux de travail plus mesuré.
Pendant une grande partie de la session, Fable 5 a évalué la base de référence, exploré les coûts des barrières de grille et raisonné sur la bande passante mémoire. L'article décrit qu'environ 64 % de la session a été consacrée à la mesure et à la conception avant la mise en œuvre principale.

Une fois la version initiale écrite, le premier benchmark aurait atteint environ 14,4x. Fable 5 a ensuite utilisé le temps restant pour supprimer les barrières, resserrer la déquantification int4, tester les modifications et annuler une optimisation négative lorsque la mesure montrait qu'elle était pire.
L'exécution complète a duré environ 2,5 heures et a utilisé environ 550 000 jetons de sortie. Le détail clé n'est pas seulement l'échelle. C'est le comportement : benchmarker, construire, mesurer, revenir en arrière si nécessaire et optimiser en fonction des données plutôt que de la confiance.
La source originale note également que Fable 5 est décrit comme une version plus sûre ou réduite du modèle interne Mythos d'Anthropic. Cette affirmation doit être lue comme faisant partie du récit de la source plutôt que comme une annonce publique de produit.

« La boucle d'auto-amélioration de l'IA a démarré »
La discussion plus large provient de la newsletter Import AI de Jack Clark. Dans cette
Clark a présenté le résultat des GPU-kernel comme un signe que les systèmes d’IA améliorent leur capacité à automatiser certaines parties de la recherche et du développement en IA eux-mêmes.

Creez un site vitrine et genere des leads en quelques minutes
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Le raisonnement est simple :
- De meilleurs systèmes d’IA peuvent écrire de meilleurs noyaux bas niveau.
- De meilleurs noyaux peuvent accélérer ou réduire le coût de l’entraînement et de l’inférence.
- Des systèmes d’IA plus rapides et moins chers peuvent aider à construire la génération suivante.
- La génération suivante pourrait devenir encore meilleure pour écrire des noyaux.
C’est pourquoi l’expression « amélioration récursive de soi » apparaît dans cette discussion. Cela ne signifie pas qu’une boucle autonome incontrôlée s’est déjà produite. Cela signifie qu’un élément de la boucle — l’amélioration par l’IA de l’infrastructure utilisée pour construire l’IA — devient plus visible et mesurable.

De l’écriture de noyaux au travail à distance
L’article original relie également ce résultat de noyau à des références plus larges en matière d’automatisation. Import AI discute de l’Indice de Travail à Distance, où les agents d’IA sont évalués sur des projets en ligne économiquement utiles.
Le but n’est pas de dire que l’écriture de noyaux CUDA et l’automatisation des tâches freelance sont la même chose. Ce n’est pas le cas. Mais les deux vont dans la même direction : les systèmes d’IA de pointe s’améliorent dans des tâches plus longues et structurées qui nécessitent planification, utilisation d’outils, vérification et itération.
Un commentaire dans la source capture bien l’inquiétude : une fois qu’un modèle peut écrire des noyaux qui accélèrent les modèles, l’outil ne se contente plus d’aider les utilisateurs. Il améliore également certaines parties de son propre substrat.

C’est là que la vérification devient cruciale. Un noyau qui semble correct n’est pas nécessairement plus rapide. Un noyau qui semble plus rapide peut contenir des problèmes subtils de correction. Avec le travail GPU bas niveau, la boucle de révision doit rester stricte.
Progrès rapides, prudence réelle
L’histoire a deux faces. D’un côté, le résultat est excitant. Les systèmes d’IA produisent désormais des artefacts de performance bas niveau qui étaient autrefois limités à un petit nombre de programmeurs GPU experts.

com/cms-assets/image/2026/07/0fdc859f-d6a1-47e7-b2ba-5e2fefcf3a3f-12-593ae533-5c09-47f2-840c-11d03c53dc3a.png)
D'un autre côté, c'est exactement le genre de capacité qui mérite une attention particulière. Cette même newsletter imagine un avenir où l'informatique à usage général devient si puissante et dangereuse que les gens tentent de la contraindre. Cette fin fictive n'est pas une prédiction, mais elle reflète le malaise suscité par l'accélération des systèmes techniques.

Un peu plus d'un an après que les premiers travaux de KernelBench ont montré la difficulté des kernels générés par l'IA, ce résultat suggère un bond majeur. Fable 5 n'a pas simplement généré un kernel utilisable. Il a produit un chemin de mégakernel fusionné qui a atteint le sommet d'un benchmark difficile en une seule session limitée.
Pour l'infrastructure de l'IA, c'est un signal sérieux.
Notes sources
- Source originale : Article du BAAI Hub.
- L'article original cite des reportages et des discussions provenant de Import AI 464, KernelBench-Mega, le post X d'Elliot Arledge et une discussion Reddit.
- L'article original comprend plusieurs séparateurs de marque, logos décoratifs, graphiques d'engagement et une photo de personne. Ceux-ci ont été intentionnellement exclus car ils ne sont pas nécessaires pour le flux de lecture technique.
- Aucun bloc de code autonome n'était présent dans la source. Les identifiants techniques en ligne tels que
02_kimi_linear_decodeettorch.profileront été conservés.
FAQ
Qu'est-ce que KernelBench-Mega ?
KernelBench-Mega est un benchmark axé sur la génération de mégakernels de blocs entiers. Au lieu de demander à un modèle d'optimiser un seul opérateur isolé, il demande au modèle de fusionner une charge de travail plus importante en un chemin de kernel efficace, puis mesure les performances réelles.
Qu'a accompli Fable 5 sur KernelBench-Mega ?
Fable 5 aurait atteint une accélération de décodage de 18,71x par rapport à une référence PyTorch optimisée sur la tâche 02_kimi_linear_decode. Le résultat a été produit en une seule session autonome dans une limite de 3 heures.
Pourquoi un mégakernel CUDA est-il difficile à écrire ?
Un mégakernel doit coordonner de nombreuses étapes de calcul à l'intérieur d'un seul lancement de kernel. Cela signifie que l'implémentation doit gérer le mouvement des données, la synchronisation, l'exactitude numérique, la bande passante mémoire et l'ordre d'exécution sans diviser le travail en kernels plus petits et plus sûrs.
Pourquoi un seul lancement de kernel est-il important ?
Chaque lancement de kernel GPU a un coût. Lors du décodage token par token, les lancements répétés peuvent s'accumuler rapidement. Un seul lancement fusionné peut réduire les frais de synchronisation et de planification, c'est pourquoi
L'approche de Fable 5 est techniquement significative.
S'agit-il d'une preuve d'auto-amélioration récursive ?
Ce n'est pas la preuve d'une boucle d'auto-amélioration autonome complète. Il est plus juste de considérer cela comme un signal concret que les systèmes d'IA commencent à automatiser des tâches pouvant améliorer l'infrastructure de l'IA, telles que la conception de noyaux et l'optimisation des inférences.
Ce type de code CUDA généré par l'IA peut-il être utilisé en production ?
Pas directement sans un examen minutieux. Un code de performance nécessite des vérifications strictes de correction, du profilage, des tests de régression et une validation spécifique au matériel. Un résultat de benchmark rapide est prometteur, mais le déploiement en production nécessite beaucoup plus de vérifications.
Quels outils sont utiles pour étudier ce résultat ?
KernelBench-Mega fournit le classement et les artefacts d'exécution. Le profileur PyTorch, les outils CUDA, les jeux de données de traces Hugging Face et les outils de profilage GPU sont utiles pour comprendre le comportement du noyau généré.
Outils connexes
- KernelBench-Mega : La page de benchmark pour les résultats et les artefacts d'exécution des méga-noyaux.
- Dépôt GitHub KernelBench : Le cadre de benchmark original pour évaluer les noyaux GPU générés par LLM.
- NVIDIA CUDA Toolkit : La boîte à outils essentielle pour écrire, compiler et profiler des applications CUDA.
- PyTorch Profiler : Un outil de profilage utilisé pour inspecter le temps d'exécution, les lancements de noyaux et le comportement d'exécution dans les charges de travail PyTorch.
- Jeux de données Hugging Face : Une plateforme pour héberger des jeux de données et des traces de benchmark, y compris les artefacts d'exécution de KernelBench.
- Triton : Un langage et un compilateur pour écrire des noyaux GPU personnalisés souvent utilisés dans l'ingénierie de performance en IA.
Liens connexes
- Classement KernelBench-Mega : Classement officiel et explication pour le benchmark des méga-noyaux.
- Hub des résultats KernelBench : Résultats de benchmark publics, visualiseurs de transcription et jeux de données.
- Import AI 464 : Le numéro du bulletin de Jack Clark discutant de Fable, des noyaux GPU, de l'automatisation de l'IA et du calcul analogique.
- Trace de Fable 5 sur KernelBench-Mega : La trace d'exécution référencée dans l'article original.
- Article sur KernelBench sur arXiv : L'article de recherche présentant KernelBench comme un benchmark pour les noyaux GPU générés par LLM.
- Dépôt ScalingIntelligence KernelBench : Code source et outils d'évaluation pour le projet original KernelBench.
- Discussion Reddit : Discussion communautaire référencée par l'article source.
Résumé
Cet article explique pourquoi le résultat rapporté de Fable 5 à KernelBench-Mega est plus qu'une simple victoire de benchmark. Le détail important est que le
Mégakernel CUDA à lancement unique : un chemin fusionné qui traite une charge de travail de décodage complexe avec un surcoût de lancement bien moindre que les solutions multi-kernels.
Ce résultat est également important car il indique que les systèmes d’IA deviennent plus performants dans les tâches d’ingénierie des performances qui soutiennent le développement de l’IA elle-même. Des kernels plus rapides peuvent rendre l’inférence et l’apprentissage plus efficaces, créant ainsi une boucle de rétroaction à surveiller.
Dans le même temps, le code bas niveau généré par l’IA ne devrait pas être considéré comme prêt pour la production par défaut. La correction, le profilage, le comportement matériel et les tests de régression restent essentiels.
Le véritable enseignement : le mégakernel de Fable 5 est un signal fort que l’ingénierie des performances GPU assistée par l’IA passe du stade de démonstration à celui d’une infrastructure sérieuse.



