Aller au contenu

10 · État de l'art et perspectives

Le panorama complet en août 2026, ce qui est établi, ce qui ne l'est pas, et les questions ouvertes.

10.1 Le tableau complet

Travail Origine Date Nature Résultat annoncé
Look Ma, No Bubbles Stanford, Hazy Research mai 2025 manuel, latence Llama-1B < 1 ms (H100), ~680 µs (B200) ; 78 % de la bande passante ; 2,5× vLLM, 1,5× SGLang
Kog monokernel Kog 2025 manuel, AMD > 3 000 j/s par requête (2 B, FP16, 8× MI300X) ; sync 7,6 → 0,9 µs
Megakernel TP Stanford sept. 2025 manuel, débit, 8 GPU Llama-70B : 23 468 j/s contre 19 170 (SGLang), +22 %
Mirage MPK CMU, UW, Berkeley, NVIDIA, Tsinghua déc. 2025 compilateur 1,0-1,7× vs SGLang/vLLM ; 1,1-1,4× sur 8 H100 ; jusqu'à 10× vs PyTorch+CUDA Graphs
Event Tensor / ETC CMU, NVIDIA, et al. avr. 2026 compilateur dynamique latence SOTA, préchauffage fortement réduit
Fleet AMD avr. 2026 abstraction chiplets 1,3-1,5× vs vLLM (lots 1-8) ; L2 12 % → 54 % ; −37 % HBM
Ada-MK Baidu mai 2026 production +23,6 % vs TensorRT-LLM, +50,2 % vs vLLM ; −50 % mémoire partagée
AutoMegaKernel indépendant juin 2026 synthèse par agent 7 160 ordonnancements validés, 0 faux positif ; 1,25-1,72×

10.2 Ce qui est établi

Cinq résultats solides

1. La technique fonctionne. Plusieurs équipes indépendantes, sur des matériels différents (H100, B200, A100, MI300X, MI350, L4/L40S), obtiennent des gains substantiels.

2. Le gain est concentré sur le décodage à petit lot. Tous les travaux évaluent ce régime, aucun ne prétend améliorer l'entraînement.

3. Le plafond de bande passante peut être poussé de ~50 % à ~78 %. C'est le chiffre le plus robuste du domaine.

4. La compilation automatique est possible. MPK démontre qu'on peut générer un megakernel depuis un modèle Hugging Face.

5. C'est déployable en production. Ada-MK tourne dans le système publicitaire de Baidu, comme greffon TensorRT-LLM.

10.3 Ce qui n'est pas établi

Cinq incertitudes

1. La reproductibilité des chiffres. Aucun des résultats cités n'a été reproduit indépendamment à la connaissance de ce document. Les lignes de base varient (versions de vLLM/SGLang, configurations, longueurs de contexte).

2. Le comportement en charge réelle. Les évaluations portent sur des configurations contrôlées. Un service réel a des longueurs de contexte variables, des arrivées irrégulières, des préemptions.

3. Le coût total de possession. Personne n'a publié le coût de maintenance sur plusieurs générations de matériel et de modèles.

4. Le comportement à grande échelle. Les évaluations multi-GPU vont jusqu'à 8 cartes. Au-delà (16, 64, 256), les propriétés de la synchronisation changent.

5. La généralité architecturale. Les travaux ciblent des transformeurs denses ou MoE classiques. Les architectures hybrides (attention + récurrence), les modèles à espace d'états, les architectures de diffusion sont peu explorées.

10.4 Les quatre lignes de recherche actives

Ligne 1 — le dynamisme

Le verrou : les megakernels statiques exigent une compilation par configuration.

L'état : Event Tensor propose une abstraction supportant le dynamisme de forme et de données. Ada-MK contourne par une recherche hors ligne éliminant le branchement à l'exécution.

Ce qui manque : un système qui gère le dynamisme intra-passe — décodage spéculatif à longueur variable, routage MoE dépendant des données, attention creuse.

Ligne 2 — la génération automatique

Le verrou : écrire un megakernel demande des mois d'expertise.

L'état : MPK compile depuis Hugging Face. AutoMegaKernel va plus loin avec une synthèse pilotée par agent, validée statiquement.

Ses résultats méritent d'être détaillés :

  • 7 160 ordonnancements adverses validés, avec zéro faux positif d'acceptation ;
  • parité jeton à jeton avec la référence Hugging Face (variance de perplexité de \(2{,}5\times10^{-7}\) sur SmolLM2-135M) ;
  • 1,25 à 1,72× d'accélération via des boucles d'auto-amélioration ;
  • des noyaux W8A16 int8 qui battent cuBLAS BF16 avec CUDA Graphs sur des GPU de classe inférence : 1,33× sur L4, 1,25-1,27× sur L40S.

Le point méthodologiquement intéressant est le validateur d'IR figé : un agent propose des ordonnancements, qui sont rejetés avant exécution s'ils sont dangereux. On rend les courses impossibles par construction plutôt que de les déboguer.

Ce qui manque : la démonstration à l'échelle de modèles de production, et l'intégration dans des chaînes d'outils existantes.

Ligne 3 — la localité matérielle

Le verrou : le modèle plat de CUDA/HIP n'exprime pas les chiplets.

L'état : Fleet propose les chiplet-tasks. Le matériel commence à aider (Cluster Launch Control sur Blackwell).

Ce qui manque : une abstraction adoptée par les fournisseurs. Fleet est un papier de recherche, pas une API.

Ligne 4 — l'intégration dans les moteurs

Le verrou : les megakernels sont des prototypes ou des greffons.

L'état : Ada-MK comme greffon TensorRT-LLM, le megakernel de Stanford intégré à Tokasaurus.

Ce qui manque : une intégration dans vLLM ou SGLang, qui sont les moteurs dominants.

10.5 Les quatre questions ouvertes

Q1 — Le megakernel deviendra-t-il le mode d'exécution par défaut ?

Pour : le gain est réel à petit lot, la compilation automatique progresse, le matériel évolue dans le bon sens, et l'inférence à petit lot est le régime dominant.

Contre : le gain s'effondre à grand lot ; le dynamisme reste un verrou ; l'écosystème (cuBLAS, cuDNN, FlashAttention) est bâti sur des noyaux autonomes.

Le pronostic raisonnable : l'architecture hybride d'Ada-MK — megakernel pour le décodage, moteur classique pour le préremplissage — semble le point d'équilibre naturel. Le megakernel comme composant, pas comme remplacement.

Q2 — Le matériel va-t-il absorber le problème ?

Une file de travail matérielle (Cluster Launch Control) rend l'ordonnancement dynamique gratuit. On peut imaginer :

  • une synchronisation inter-blocs matérielle à grain fin ;
  • une hiérarchie explicite de chiplets dans le modèle de programmation ;
  • des files de tâches avec dépendances gérées en silicium.

Si cela arrive, écrire un megakernel deviendrait beaucoup plus simple — et l'écart avec les noyaux classiques se réduirait, ce qui pourrait paradoxalement réduire l'intérêt de la technique.

Q3 — Les modèles vont-ils s'adapter aux megakernels ?

Jusqu'ici, les megakernels s'adaptent aux modèles. L'inverse est possible : concevoir des architectures dont le graphe de dépendances se mega-noyaute bien.

Les leviers imaginables : des couches à dépendances plus locales, des tailles uniformes facilitant le pavage, moins d'opérations de rangement, un routage MoE plus prévisible.

C'est de la co-conception modèle/système, comme FlashAttention l'a été pour l'attention.

Q4 — Les LLM vont-ils écrire ces noyaux ?

AutoMegaKernel suggère que oui, au moins partiellement.

L'état plus large de la génération de noyaux par LLM en 2026 :

  • sur KernelBench (250 charges PyTorch, quatre niveaux de complexité), même les modèles de raisonnement de pointe ne battent la ligne de base PyTorch que dans moins de 20 % des cas, révélant un compromis critique entre complexité d'optimisation et correction ;
  • KernelBench-X étend le benchmark et reste la référence comparable ;
  • les approches agentiques avec profilage en boucle progressent nettement : CuGEdit annonce 2,08× à 10,32× contre torch.compile sur 50 charges de niveau 3, et sur les tâches où deux modèles produisent des noyaux corrects, GPT-5.2 obtient une accélération moyenne de 5,17× contre 4,63× pour Opus ;
  • des travaux comme ARGUS (optimisation guidée par des invariants de flux de données) et l'usage de micro-profileurs comme substituts d'expert suggèrent que la clé est de donner à l'agent les bons signaux, pas seulement plus de calcul.

La lecture prudente

Un LLM qui génère un noyau correct et rapide sur un benchmark n'est pas un LLM qui écrit un megakernel de production.

Mais la combinaison agent + validateur statique + boucle de profilage d'AutoMegaKernel est structurellement différente de « demander un noyau à un modèle » : elle contraint l'espace de recherche à des programmes sûrs et laisse la mesure décider.

C'est probablement la direction qui portera.

10.6 Ce qu'il faut suivre

Si vous voulez rester à jour :

Source Ce qu'on y trouve
HazyResearch/Megakernels le code de référence
mirage-project/mirage le compilateur
Catalyst, CMU les publications du groupe
arXiv cs.DC et cs.LG les papiers, avec les mots-clés megakernel, persistent kernel
GPU MODE les conférences et la communauté
Blogs vLLM et SGLang l'adoption éventuelle
FlashInfer-Bench l'évaluation systématique des noyaux d'inférence

10.7 Le résumé de la partie 8

Les dix idées à emporter

  1. Une frontière de noyau coûte trois choses : le lancement (~1,3 µs avec CUDA Graphs), la barrière globale implicite et la bulle mémoire. CUDA Graphs ne supprime que la première.
  2. Sur Llama-1B/B200, 62 % du temps d'une passe avant est du stockage, de la synchronisation, de l'attente et de la configuration.
  3. Un megakernel : un lancement, persistant, dépendances fines, hétérogénéité interne. L'idée vient des persistent threads de 2012.
  4. Trois mécanismes décisifs : allocateur de pages de mémoire partagée, compteurs en mémoire globale, ordonnancement dynamique.
  5. Quatre architectures publiées : interpréteur manuel (Stanford), compilateur statique (MPK), compilateur dynamique (Event Tensor), hiérarchie de chiplets (Fleet).
  6. AMD exige une reconception, pas un portage : sentinelles au lieu d'atomiques (9× plus rapide), duplication par XCD, streaming continu.
  7. Résultats : 78 % de la bande passante contre ~50 %, 1,0-1,7× contre vLLM/SGLang, +22 % en débit multi-GPU.
  8. Le gain est proportionnel au surcoût : ~25 % à lot 1 sur un petit modèle, négligeable en entraînement. En dessous de 20 % de surcoût, ne le faites pas.
  9. Essayez MPK avant d'écrire. Écrire de zéro coûte 2 à 6 mois.
  10. Le verrou actuel est le dynamisme. Il décidera si le megakernel reste un composant spécialisé ou devient le mode d'exécution par défaut.

Vérifiez que vous avez compris

Pourquoi les auteurs de megakernels évaluent-ils tous sur le décodage et jamais sur l'entraînement ?

Parce que le gain y serait nul, et ils le savent.

L'entraînement est limité par le calcul (\(I \approx 3bS\), soit des dizaines de milliers contre un seuil de 296). Les tensor cores sont saturés, et le surcoût de lancement — quelques centaines de microsecondes — est négligeable devant un pas d'entraînement de plusieurs centaines de millisecondes.

De plus, un megakernel priverait l'entraînement des GEMM de cuBLAS et de CUTLASS, qui sont proches du pic. Ce serait un recul net.

C'est un signe de rigueur : ils évaluent là où leur technique s'applique.

Sur KernelBench, les LLM battent PyTorch dans moins de 20 % des cas. Est-ce contradictoire avec les 1,25-1,72× d'AutoMegaKernel ?

Non, parce que les protocoles diffèrent radicalement.

KernelBench évalue de la génération « en un coup » : on demande un noyau, on vérifie qu'il est correct et rapide. C'est difficile — il faut produire du code CUDA correct et performant d'emblée.

AutoMegaKernel utilise une boucle : un agent propose un ordonnancement, un validateur statique le rejette s'il est dangereux, on mesure, on itère. L'agent ne génère pas du CUDA arbitraire mais choisit dans un espace d'ordonnancements contraint, à l'intérieur d'une infrastructure existante.

Les deux chiffres sont compatibles : la génération libre reste difficile, la recherche guidée dans un espace sûr fonctionne bien. C'est aussi ce que suggèrent les travaux sur le profilage comme substitut d'expert.

Si le matériel finit par fournir une synchronisation inter-blocs fine, les megakernels perdent-ils leur intérêt ?

En partie, et pas complètement.

Ce que le matériel supprimerait : le coût de la synchronisation, la difficulté de l'écrire correctement, et une partie du risque d'interblocage. Écrire un noyau qui coopère avec ses voisins deviendrait presque aussi simple qu'écrire un noyau ordinaire.

Ce qui resterait : les autres bénéfices du megakernel — garder les activations en mémoire partagée entre opérations, éliminer les bulles de pipeline mémoire, ordonnancer globalement des opérations hétérogènes, inventer des motifs de communication non standard.

Le plus probable est une convergence : les frontières de noyau deviendraient moins coûteuses, les megakernels plus faciles à écrire, et la distinction entre les deux s'estomperait.

Ce serait le meilleur résultat possible : la technique aurait gagné en changeant le matériel, comme FlashAttention a changé la façon dont on conçoit l'attention.

Partie suivante : Pratique

Sources de ce chapitre