Une requête avance, certaines ressources du GPU attendent
Votre serveur exécute un modèle déjà entraîné pour répondre à une requête : c’est l’inférence. Il prépare le prochain token, un morceau de texte prédit par le modèle. Il lit ses poids, les paramètres appris pendant l’entraînement, puis enchaîne des calculs matriciels et consulte les résultats conservés pour le contexte. Si le modèle est réparti sur plusieurs GPU, il échange aussi des résultats intermédiaires entre eux. La requête progresse, mais chaque étape ne sollicite pas les mêmes ressources.
Une multiplication de matrices peut solliciter surtout les unités de calcul, tandis qu’une autre opération dépend surtout de la vitesse de lecture en mémoire. Un transfert peut retarder un calcul alors que d’autres calculs indépendants seraient déjà possibles. L’enjeu est de trouver ce travail indépendant, puis de lui réserver des ressources sans introduire d’erreurs. Un mégakernel réunit plusieurs opérations dans un même programme GPU et organise leur enchaînement : il peut commencer une portion prête sans attendre que toute l’opération précédente soit terminée.
Le financement de Flapping Airplanes remet ce sujet dans l’actualité. Le laboratoire est cofondé par Ben Spector, l’un des auteurs de ThunderKittens, avec Asher Spector et Aidan Smith. Il veut agir sur l’exécution des programmes GPU et sur les méthodes d’apprentissage. Ce dossier confronte ses annonces aux mécanismes documentés et développe des exemples pédagogiques. LeCompute n’a pas testé son système.
Ce que la levée de fonds d’octobre 2026 établit
Le 21 octobre 2026, Index Ventures annonce une série A, un tour de financement que Flapping Airplanes présente comme codirigé avec Lux Capital. Converti au taux indicatif de LeCompute, son montant atteint 920 millions d’euros. Le financement initial rendu public lors du lancement du 28 janvier représentait 165,6 millions d’euros au même taux. Ces sommes décrivent des financements annoncés, pas un budget intégralement consacré à acheter des GPU. Annonce d’Index en octobre, lancement du 28 janvier, montant initial annoncé par l’entreprise.
NVIDIA figure parmi les soutiens remerciés dans l’annonce de la série A publiée par Flapping Airplanes. Celle-ci ne chiffre aucun apport individuel de NVIDIA et ne décrit pas les modalités de son soutien. Les communications examinées portent sur un financement du laboratoire ; elles n’annoncent pas le rachat de ThunderKittens par NVIDIA.
Bloomberg rapporte une valorisation de 5,52 milliards d’euros, financement inclus, au taux indicatif retenu ici. Ce chiffre est attribué à son reportage du 21 octobre et n’est pas confirmé dans les annonces de l’entreprise et d’Index que nous avons consultées. Une valorisation traduit les conditions économiques d’un investissement ; elle ne mesure ni le chiffre d’affaires ni un gain de performances. Reportage de Rachel Metz pour Bloomberg.
Le parcours de l’équipe mérite la même précision. Ben Spector a signé le papier ThunderKittens avec Simran Arora, Aaryan Singhal, Daniel Fu et Christopher Ré dans sa version arXiv de 2024. Asher Spector et Aidan Smith ne figurent pas dans cette liste. Flapping Airplanes et ThunderKittens sont donc liés par des personnes et des travaux, tout en restant deux objets distincts. Papier original.
ThunderKittens facilite le travail à l’échelle des tuiles
Un kernel est une fonction dont de nombreux threads, des fils d’exécution, exécutent le code en parallèle sur le GPU. Pour multiplier deux grandes matrices, le programme répartit le résultat en petits blocs, ou tuiles. Un groupe de threads charge les données nécessaires à une tuile, effectue le calcul puis écrit ses résultats. Les dimensions et l’organisation de ces tuiles déterminent quelles opérations le matériel pourra exécuter efficacement.
ThunderKittens fournit des primitives de tuiles directement dans CUDA C++. Cela permet de composer des opérations avec un vocabulaire plus lisible tout en conservant le contrôle nécessaire pour approcher le matériel. Le dépôt public est sous licence MIT et présente le projet comme une bibliothèque pour GPU NVIDIA. L’abstraction ne remplace donc pas CUDA par une plateforme indépendante de ses instructions. Dépôt et licence.
Les Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. Approfondir dans le glossaire , les unités spécialisées dans le calcul matriciel, ne constituent qu’une partie du trajet. Il faut les alimenter assez vite, organiser la mémoire et rendre disponibles les résultats attendus par l’opération suivante. Une primitive concise aide à exprimer ce travail ; son nom ne garantit pas que la charge complète utilisera mieux le GPU.
Le programme s’exécute sur des SM Streaming Multiprocessor. Bloc de calcul indépendant d'un GPU NVIDIA, contenant ses propres unités d'exécution, registres, mémoire partagée et Tensor Cores. Un H100 SXM5 en compte 132. L'occupation des SM est la métrique-clé de saturation d'un GPU. Approfondir dans le glossaire , les multiprocesseurs qui regroupent les ressources de calcul du GPU. Leurs registres conservent des valeurs de travail pour les threads ; leur mémoire partagée permet aux threads d’un même bloc d’échanger des données. Un bloc est un groupe de threads affecté à un SM, et ses threads sont organisés en warps de 32. Certains warps peuvent préparer les transferts pendant que d’autres calculent ou stockent les résultats. Pour obtenir un pipeline, où ces étapes se chevauchent, le programme doit suivre les données prêtes et les emplacements réutilisables. Modèle de programmation des kernels CUDA.
Cette distinction explique le prolongement vers les mégakernels. Optimiser chaque étape séparément laisse encore ouverte la question de leur enchaînement. Pour un lecteur qui connaît FlashAttention et les limites du calcul matriciel, le déplacement est naturel : une fois un calcul accéléré, les transferts et la coordination peuvent prendre une place plus visible.
Suivre le travail plutôt qu’un seul pourcentage d’utilisation
Prenons une requête qui vient de finir son prefill Phase initiale d'une inférence LLM : les tokens du prompt sont traités en parallèle pour construire l'état du contexte. Cette réutilisation augmente l'intensité arithmétique et peut rendre la phase limitée par le calcul ; le régime exact dépend du modèle, du batch, du contexte et du backend. Approfondir dans le glossaire , la phase qui traite le prompt pour construire l’état du contexte. Pendant le decode Phase de génération autorégressive d'un LLM : un token est produit à la fois en relisant les poids et l'état de contexte utile. À faible batch, ce trafic peut limiter le decode par la bande passante mémoire. Sa part dans le coût total dépend toutefois des longueurs d'entrée et de sortie, du batching et de la réutilisation du cache. Approfondir dans le glossaire , elle produit les tokens successivement. Son comportement dépend des poids à relire, du contexte à consulter et des autres requêtes avec lesquelles le serveur peut la regrouper.
La HBM High Bandwidth Memory. Mémoire DRAM empilée, intégrée au même package que l'accélérateur et reliée par une interface très large. Elle fournit plusieurs To/s, mais sa topologie de packaging exacte dépend du produit. Approfondir dans le glossaire est la mémoire à haut débit placée près du processeur GPU. Elle reste différente des registres d’un thread et de la mémoire partagée d’un groupe de threads, qui servent à travailler sur des portions plus petites. Garder une opération active ne signifie pas que ses unités matricielles calculent en permanence, ni que la mémoire fournit son débit maximal.
Nsight Systems, l’outil de profilage de NVIDIA, affiche la chronologie des kernels et des transferts. Lorsque la collecte des métriques GPU est activée et prise en charge, il permet aussi d’examiner l’activité des SM, des Tensor Cores et de la mémoire. Rapprocher ces informations aide à distinguer un calcul long d’une attente entre deux étapes. Une moyenne seule peut masquer une alternance de phases très différentes. Guide d’analyse de Nsight Systems.
Notre question pour la requête devient donc concrète : pendant qu’un résultat est stocké, pouvons-nous charger les poids nécessaires à un autre morceau de travail ? La réponse dépend de ses dépendances et de la place disponible. Si les deux morceaux réclament toute la même bande passante au même instant, leur concurrence ne crée pas une nouvelle ressource.
Fusion, CUDA Graphs et mégakernels agissent à des niveaux différents
La fusion locale réunit plusieurs opérations dans un kernel. Par exemple, un programme peut transformer une valeur puis l’utiliser immédiatement, sans écrire un tableau intermédiaire que le programme suivant relirait. Le gain potentiel vient du trafic évité et des lancements supprimés ; il faut le comparer au surcroît de ressources consommées par le kernel fusionné. Explication de NVIDIA.
CUDA Graphs décrit un ensemble de tâches et de dépendances que l’hôte peut soumettre comme un objet réutilisable. Les tâches peuvent conserver des kernels séparés. NVIDIA propose aussi le lancement de graphes depuis le GPU, ce qui permet certaines décisions sans retour au CPU. Il serait donc inexact de décrire CUDA comme limité à une intervention du processeur hôte avant chaque opération. Lancement de graphes côté GPU.
| Approche | Travail réorganisé | Question à mesurer |
|---|---|---|
| Kernel spécialisé | Une opération ou un petit groupe | Son coût domine-t-il la requête ? |
| Fusion locale | Des opérations partageant des intermédiaires | Quel trafic disparaît et quelle pression mémoire apparaît ? |
| CUDA Graphs | La soumission et les dépendances entre tâches | Quelle part de l’attente vient du lancement ? |
| Mégakernel persistant | L’exécution interne de plusieurs opérations | Le recouvrement compense-t-il la coordination ajoutée ? |
Le compilateur PyTorch torch.compile ajoute une autre possibilité : transformer les régions de calcul qu’il arrive à analyser. Une rupture de graphe survient lorsqu’il rencontre du code qu’il ne peut pas intégrer à cette représentation ; avec ses réglages par défaut, ce morceau s’exécute en Python avant que l’analyse reprenne. Ces interruptions peuvent limiter l’optimisation. Une comparaison sérieuse doit donc donner aux moteurs existants une configuration adaptée. Documentation PyTorch sur les ruptures de graphe.
Un programme persistant doit organiser sa propre progression
Un stream CUDA est une file d’opérations dont l’ordre est défini par le programme. Dans le cas classique, les kernels d’un même stream s’exécutent dans cet ordre ; des streams différents peuvent déjà faire se chevaucher du travail si le matériel et les dépendances le permettent. Une frontière de kernel n’immobilise donc pas nécessairement tout le GPU. CUDA propose aussi des mécanismes comme Programmatic Dependent Launch pour amorcer un kernel dépendant avant la fin complète du précédent. Exécution asynchrone et mécanismes de recouvrement CUDA.
Un mégakernel persistant reste actif pour enchaîner plusieurs portions de travail. Il doit les répartir, vérifier quand leurs entrées sont prêtes, leur attribuer des ressources et signaler quand leurs résultats deviennent disponibles. C’est l’ordonnancement : décider quel travail peut avancer et où l’exécuter. Le runtime, le logiciel qui organise cette exécution, prend ainsi en charge des dépendances auparavant séparées par des lancements de kernels.
Les travaux publics de Hazy Research proposent un interpréteur sur le GPU : il lit une suite d’instructions préparée par le CPU et déclenche les portions de calcul correspondantes. Ces instructions décrivent des opérations du modèle ; elles ne remplacent pas le jeu d’instructions matériel du GPU. Dans le prototype de mai 2025, un kernel couvre une passe avant du modèle, le calcul qui prépare la prédiction suivante, et non toute la conversation. Il reste du travail côté hôte et d’autres passes pour produire la suite. Le code de recherche public éclaire cette approche, sans établir que Flapping Airplanes utilise aujourd’hui la même implémentation.
Choisir entre un programme fixé à l’avance et du travail à distribuer
Un ordonnanceur peut préparer une liste fixe pour chaque unité ou placer les portions prêtes dans une file commune. Dans le premier cas, il évite une partie des décisions pendant l’exécution. Dans le second, une unité qui termine plus tôt peut prendre du travail supplémentaire. Ce sont deux choix de conception possibles ; leur intérêt dépend du coût d’une décision par rapport à celui du travail distribué.
Dans notre exemple, une liste fixe peut laisser une unité attendre alors qu’une autre possède encore plusieurs portions longues. Une file partagée peut rééquilibrer cette situation, mais sa consultation et ses mises à jour ont aussi un coût. Pour des portions extrêmement courtes, ce coût peut dépasser l’attente économisée. Le nombre de décisions et les dépendances réellement libérées méritent donc d’apparaître dans le profil.
Le CPU conserve également un rôle dans le service : recevoir les requêtes, préparer les entrées et traiter les sorties. Même lorsqu’une partie de l’ordonnancement descend sur le GPU, il faut mesurer le chemin complet. Un générateur d’instructions très rapide ne raccourcit pas une attente provenant d’un modèle à charger ou d’une requête placée en file avant l’exécution.
Préparer l’opération suivante sans écraser la précédente
Revenons à notre requête. Une unité termine une projection, une transformation matricielle des valeurs du modèle, et doit encore stocker ses résultats. Elle pourrait commencer à charger les données suivantes avant la fin de cette écriture. Mais les deux opérations peuvent avoir besoin des mêmes emplacements de mémoire partagée. Le runtime doit savoir quand un emplacement peut être réutilisé, et pas seulement quand une instruction a commencé.
Un exemple pédagogique permet de voir le danger. Si le chargeur réécrit un tampon que le stockeur lit encore, les calculs peuvent être rapides et les résultats faux. Réserver une zone pour l’étape suivante évite ce conflit, mais réduit la place disponible pour l’étape actuelle. La gestion mémoire et le pipeline doivent donc être conçus ensemble.
Rendre les dépendances visibles sans attendre inutilement
Un signal de fin ne suffit pas si le code qui lit le résultat n’a pas la garantie de voir les données correspondantes. Il faut ordonner l’écriture du résultat, la publication du signal et la lecture qui suit. Le modèle mémoire CUDA définit ces garanties et leur portée. Cooperative Groups permet notamment de synchroniser les threads d’un groupe, avec des règles adaptées à sa taille et à son mode de lancement. Cela ne fournit pas une barrière arbitraire entre tous les GPU. Cooperative Groups, modèle mémoire CUDA C++.
L’autre difficulté est la progression. Imaginons que tous les blocs actuellement résidents attendent un producteur qui n’a pas encore obtenu de place pour s’exécuter. L’attente empêche alors le travail qui devait la résoudre. Cet exemple illustre pourquoi une boucle persistante réclame une analyse des ressources et de l’ordonnancement, au-delà d’un simple compteur partagé.
Les résultats publics concernent des charges identifiées
En mai 2025, Hazy Research étudie Llama-3.2-1B en BF16, un format flottant sur 16 bits, avec une seule séquence, un prompt de 32 tokens et 128 tokens générés. Le test n’utilise pas le décodage spéculatif, qui fait proposer plusieurs tokens par un mécanisme auxiliaire avant de les vérifier. La figure publiée montre un débit de décodage d’environ 1,5 fois celui de SGLang sur H100 et B200. Les références de comparaison de ce billet utilisent déjà CUDA Graphs et la compilation PyTorch. Étude à faible latence et figure 1.
En septembre 2025, leur mégakernel Llama-70B réparti sur huit H100 est intégré à Tokasaurus, un moteur qui regroupe les requêtes et gère leur état mémoire. Sur 65 536 prompts et longueurs de réponse échantillonnés dans ShareGPT, un corpus de conversations, le débit total rapporté passe de 19 170 à 23 468 tokens/s face à SGLang, soit environ 22,4 %. Ce total additionne les tokens d’entrée traités et les tokens de sortie générés ; il ne désigne pas la vitesse d’une seule conversation. Le test consiste à terminer l’ensemble de ces requêtes. C’est un résultat publié par les auteurs en 2025, pas un benchmark de la plateforme annoncée en octobre 2026. Protocole et tableau 4.
Cette seconde charge ajoute un problème absent de notre requête sur une seule carte : un GPU peut attendre des activations, les résultats intermédiaires du modèle, produites ailleurs. Le programme doit coordonner transferts et calculs. L’interconnexion entre GPU conserve ses limites physiques ; le travail de l’ordonnanceur consiste à placer d’autres opérations utiles pendant certaines de ces attentes.
Il faut aussi lire le statut du code. Le README de la branche de recherche indique explicitement qu’il est publié comme référence de recherche, et non comme produit supporté. Pour un exploitant, cette différence change le coût d’intégration, de validation et de maintenance. README au commit consulté.
Les résultats de ThunderKittens 2.0 répondent encore à une autre question : les kernels de multiplication matricielle générale, ou GEMM, sélectionnés sur B200 peuvent-ils égaler ou dépasser cuBLAS, la bibliothèque d’algèbre linéaire de NVIDIA ? La publication insiste sur la comparabilité des entrées, des caches et de l’état thermique. Un avantage sur ces multiplications ne constitue pas à lui seul une accélération du service complet. Méthode ThunderKittens 2.0.
Ce que Flapping Airplanes affirme désormais pouvoir exécuter
Dans son annonce d’octobre, l’entreprise décrit un framework de mégakernels capable de réaliser des entraînements complets, de servir de l’inférence et de jouer à des jeux vidéo, y compris simultanément dans un seul kernel. Elle relie ce travail à la possibilité de faire se chevaucher une inférence limitée par la mémoire et un entraînement limité par la capacité de calcul. Ce sont les capacités revendiquées par Flapping Airplanes. Annonce officielle de la série A.
Pour les examiner, séparons les preuves nécessaires. Un test reproductible faisant fonctionner plusieurs activités montrerait leur coexistence dans ses conditions. Pour établir un bénéfice opérationnel, il faudrait aussi comparer le travail achevé, la qualité des résultats, la mémoire consommée, l’énergie et les délais imposés aux activités prioritaires. Cette annonce ne fournit pas, à elle seule, ce protocole comparatif.
Supposons qu’un entraînement soit ralenti pour laisser répondre des requêtes interactives. La démonstration serait utile si la machine termine davantage de travail dans une fenêtre donnée tout en respectant les délais. Elle le serait beaucoup moins si elle augmente le débit moyen en laissant certaines requêtes attendre longtemps. Notre critère doit inclure la distribution des latences, et pas uniquement sa moyenne.
La complémentarité des ressources doit elle aussi être vérifiée. L’entraînement lit et écrit de la mémoire, même lorsqu’il est limité par le calcul. L’inférence effectue des calculs, même lorsqu’elle attend surtout la mémoire. Réunir les deux peut créer des conflits sur les caches, la mémoire partagée ou les unités d’exécution. Leur profil isolé aide à proposer un partage ; seul le profil de leur exécution commune permet de voir ce qui subsiste de cette complémentarité.
Pourquoi le soutien de NVIDIA peut être cohérent
Du point de vue d’un constructeur, un logiciel qui rend une puce utile à davantage de tâches peut accroître sa valeur. Une entreprise hésitant à déployer une application à cause de son coût peut changer de décision si le même parc accomplit plus de travail. Les investisseurs de Flapping Airplanes défendent cette logique de nouveaux usages rendus accessibles par l’efficacité. Nous l’analysons comme une hypothèse économique, sans l’attribuer comme motivation officielle à NVIDIA.
Le raisonnement ne permet pas de prédire automatiquement davantage de ventes. Si un client traite une quantité fixe de travail, un gain peut d’abord réduire ses besoins matériels. Si de nouveaux usages absorbent cette capacité, le volume total peut au contraire augmenter. Il faut connaître les prix, la demande et les contraintes de déploiement pour trancher entre ces effets.
La dépendance technique compte aussi. ThunderKittens s’insère dans CUDA ; améliorer les programmes pour ces GPU peut renforcer l’intérêt de cette plateforme. Le soutien annoncé de NVIDIA ne démontre toutefois ni une exclusivité ni un engagement du laboratoire à utiliser seulement ses puces. Ces éléments demanderaient des informations contractuelles absentes des annonces consultées.
Économiser du calcul et apprendre avec moins de données
La communication de lancement de Flapping Airplanes insiste sur l’efficacité en données. Cela concerne la quantité et la nature des exemples nécessaires pour obtenir une capacité donnée. L’efficacité matérielle concerne le temps, l’énergie et les machines nécessaires pour exécuter un programme. Un modèle peut progresser sur l’un de ces axes sans progresser sur l’autre.
Un modèle demandant moins d’exemples mais davantage de calcul par exemple ne coûte pas nécessairement moins cher à entraîner. Inversement, un runtime plus rapide peut exécuter exactement le même algorithme et le même corpus, sans améliorer la façon dont le modèle apprend. Pour comparer deux méthodes, fixons d’abord le niveau de qualité demandé, puis mesurons les ressources nécessaires pour l’atteindre.
Le lien potentiel entre les deux axes reste intéressant. Imaginons qu’une nouvelle architecture soit difficile à exprimer efficacement dans les outils existants. Un meilleur contrôle du GPU pourrait réduire le coût de ses expériences, et permettre d’en explorer davantage. C’est une chaîne de raisonnement plausible ; elle ne transforme pas les résultats publics d’inférence en preuve d’un nouvel algorithme d’apprentissage.
Les limites apparaissent dans la mémoire, les formes et l’exploitation
Un programme qui réunit davantage d’opérations peut devoir conserver davantage de valeurs intermédiaires. Une forte consommation de registres ou de mémoire partagée peut réduire le nombre de blocs actifs simultanément sur un SM. Si les registres manquent, certaines valeurs peuvent aussi être stockées dans la mémoire locale, plus coûteuse à consulter. Fusionner davantage peut donc finir par ralentir le programme. Gestion des ressources et occupation.
Les entrées d’un service changent aussi. Un lot de courtes conversations, une requête à long contexte et une charge dominée par le prefill n’exigent pas le même découpage. La forme d’un tenseur désigne ses dimensions, par exemple le nombre de requêtes et la longueur de leurs séquences. Un compilateur peut spécialiser du code pour certaines dimensions, puis devoir le recompiler lorsqu’elles changent. PyTorch propose aussi des dimensions dynamiques pour éviter certaines recompilations. Pour un runtime spécialisé, il faut mesurer le coût de préparation, d’adaptation et du retour à un chemin moins optimisé. Formes dynamiques.
Enfin, l’exploitant doit pouvoir arrêter un travail, appliquer des priorités, récupérer une erreur et observer une requête lente. Déplacer des décisions dans un programme persistant déplace aussi une partie de ces responsabilités. Notre dossier sur le coût de l’inférence rappelle pourquoi le temps de GPU ne suffit pas : l’intégration et l’exploitation participent au coût utile.
Convertir un gain de débit sans gonfler sa portée
Prenons une hypothèse indépendante des résultats de Flapping Airplanes : à travail identique, un système atteint 1,22 fois le débit de sa référence. Supposons que le prix par heure de la machine reste identique, que sa capacité supplémentaire soit entièrement utilisée et que le coût retenu soit proportionnel au temps d’exécution. Le coût par unité de travail vaut alors 1 / 1,22, soit environ 0,820 fois l’ancien. La baisse est proche de 18 %, pour une hausse de débit de 22 %. Les deux pourcentages n’ont pas le même dénominateur.
Supposons maintenant que, dans un traitement séquentiel, la partie accélérée représente seulement 30 % de la durée initiale et que les 70 % restants demeurent inchangés. La durée relative devient 0,70 + 0,30 / 1,22, soit environ 0,946 : le traitement dure 5,4 % moins longtemps. L’inverse de cette durée donne un facteur d’accélération de 1,057, soit 5,7 % de vitesse supplémentaire. Ce calcul suppose que les parties ne se chevauchent pas ; il ne prédit pas l’effet de toutes les optimisations d’un GPU.
Ce cadre aide à examiner une annonce : quelle fraction du parcours est accélérée, et quelle métrique est réellement comptée ? Une meilleure multiplication matricielle, une passe de modèle plus rapide et un service répondant plus vite à ses utilisateurs sont trois niveaux à relier par des mesures, pas par la répétition du même pourcentage.
Quel protocole permettrait de juger la promesse
Nous commencerions par une référence récente et correctement réglée, avec ses versions et options enregistrées. Le modèle, sa précision, les données d’entrée et les critères de qualité seraient identiques. Le test distinguerait compilation et préparation, démarrage à froid, régime établi et changements de forme. Cette proposition est notre protocole de lecture des futurs résultats, pas une expérience déjà réalisée.
Pour l’inférence, nous mesurerions le délai avant le premier token, les délais entre tokens et le débit à plusieurs niveaux de concurrence. Les longues requêtes et les pics d’arrivée resteraient dans le jeu de test. Le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire , l’état mémorisé de l’attention, ferait partie de l’occupation mémoire et de la capacité de concurrence. Comprendre ce budget mémoire.
Pour l’entraînement, le critère serait le temps et l’énergie nécessaires pour atteindre une qualité définie, avec les arrêts, les sauvegardes et la reprise. Pour une charge mêlant entraînement et inférence, nous publierions séparément les performances des deux activités avant et après leur réunion. Le lecteur pourrait alors voir qui bénéficie du partage et qui en paie le prix.
Une trace Nsight fournirait enfin les éléments permettant d’expliquer le résultat : attente de lancement, activité mémoire, calcul et communication. Les métriques de ressources seraient rapportées au temps de bout en bout. Si une optimisation disparaît quand les entrées changent ou que le cache est vidé, cela ferait partie du résultat publié.
Ce qu’un développeur peut retenir aujourd’hui
Pour votre propre serveur, commencez par localiser l’attente sur une requête représentative. Si une bibliothèque existante, une fusion locale, un meilleur batching ou CUDA Graphs répond au problème mesuré, leur coût d’intégration entre dans la décision. Un mégakernel devient une piste quand le contrôle supplémentaire de l’exécution peut apporter un bénéfice que vos outils actuels n’obtiennent pas, et que l’équipe peut en maintenir la correction.
ThunderKittens et les mégakernels publics fournissent des objets concrets à étudier : du code, des protocoles et des configurations. Flapping Airplanes cherche à élargir cette capacité de contrôle à un programme de recherche qui touche aussi les modèles et leur apprentissage. Pour suivre son avancée, le prochain élément décisif sera une comparaison reproductible sur ce système, avec ses conditions de qualité, de charge et d’exploitation.
Sources et méthode
Périmètre. Recherche arrêtée au 31 octobre 2026. Aucun benchmark GPU ni essai de la plateforme de Flapping Airplanes n’a été réalisé par LeCompute. Nous distinguons faits d’annonce, mesures rapportées par leurs auteurs, explications documentaires et hypothèses de notre analyse.
Financement et personnes. Index Ventures, lancement du 28 janvier 2026, annonce initiale de Flapping Airplanes, Index, série A du 21 octobre, annonce de série A de l’entreprise et entretien du 28 octobre. Ces communications établissent ce qui est annoncé ; elles ne constituent pas un audit technique. Aucun apport individuel de NVIDIA n’y est chiffré. La valorisation est séparément attribuée au reportage original de Rachel Metz, Bloomberg, 21 octobre, et non présentée comme une confirmation de l’entreprise.
Conversion monétaire. Tous les montants de cette édition sont en euros. Taux indicatif conventionnel du site : 1 USD = 0,92 EUR, référence mi-2026, et non cours de change au jour du financement. Calculs : 1 milliard × 0,92 = 920 millions ; 180 millions × 0,92 = 165,6 millions ; 6 milliards × 0,92 = 5,52 milliards. L’édition anglaise conserve les montants source en dollars.
Travaux publics. ThunderKittens, arXiv:2410.20399, version du 27 octobre 2024, dépôt ThunderKittens et licence MIT, étude Llama-1B du 27 mai 2025, étude Llama-70B du 28 septembre 2025, code Megakernels, commit consulté 91eaff2, ThunderKittens 2.0 du 19 février 2026. Les résultats cités décrivent ces travaux et leurs références historiques. Pour Llama-1B, nous retenons « environ 1,5 fois » après lecture de la figure originale, plutôt que le seuil strict « plus de 1,5 fois » annoncé dans le texte du billet, dont la barre H100 ne fournit pas une confirmation nette. Pour Llama-70B, le tableau 4 compte entrée et sortie ; notre calcul (23 468 / 19 170 - 1) × 100 donne environ 22,4 %. Aucun de ces résultats ne compare les moteurs dans leurs versions d’octobre 2026.
Mécanismes et observation. NVIDIA : fusion de kernels, graphes lancés par le GPU, exécution asynchrone, Cooperative Groups, modèle mémoire, bonnes pratiques CUDA, analyse Nsight Systems. PyTorch : ruptures de graphe et formes dynamiques. Ces documentations expliquent leurs propres systèmes, pas l’implémentation privée du laboratoire.
Hypothèses et calculs. Le tampon réutilisé trop tôt, les blocs attendant un producteur non résident, le partage d’un GPU et les scénarios à 1,22 fois le débit sont des exemples de LeCompute. Le coût relatif de 0,820 suppose un prix horaire constant et l’utilisation de toute la capacité supplémentaire. Pour le traitement séquentiel, 1 - (0,70 + 0,30 / 1,22) donne 5,4 % de temps en moins ; 1 / (0,70 + 0,30 / 1,22) - 1 donne 5,7 % de vitesse en plus. Ces calculs ne prédisent ni un gain commercial ni une économie d’énergie.
Couverture. Illustration générée par IA pour LeCompute le 1er novembre 2026 avec l’outil intégré de génération d’images OpenAI. La silhouette s’inspire de l’avion visible sur le site officiel de Flapping Airplanes, dont une capture a servi de référence. L’image est une interprétation éditoriale indépendante, et non un visuel officiel. Les lignes vertes évoquent un écoulement d’air ; elles ne représentent pas une simulation physique mesurée. Le prompt de création est conservé avec les images du site.
