Un GPU Graphics Processing Unit. Processeur capable de faire avancer de nombreux calculs en parallèle, utilisé notamment pour entraîner et exécuter des modèles d’IA. termine une multiplication de matrices, puis attend les données nécessaires à la suivante. Ses unités les plus puissantes sont prêtes, mais une autre partie du programme doit encore transformer les résultats. Augmenter la vitesse de multiplication ne supprime pas cette dépendance.

C’est le problème que traite FlashAttention-4, une implémentation optimisée du calcul d’attention utilisé par les Transformers. Le projet poursuit son développement avec une bêta 33 publiée le 30 septembre. Le papier original date, lui, de mars 2026 : l’actualité est celle d’un logiciel qui évolue, pas d’un algorithme apparu en octobre. Version bêta 33, papier original.

Son intérêt dépasse ce numéro de version. FlashAttention-4 montre ce qui arrive lorsque certaines unités d’un accélérateur progressent beaucoup plus vite que celles qui préparent leur travail.

Entre deux multiplications il faut fabriquer les poids

L’attention permet au modèle de combiner les informations de plusieurs positions d’une séquence. Elle commence par comparer des requêtes, notées Q, à des clés, notées K. Ce premier produit matriciel fournit des scores. Le softmax transforme ensuite ces scores en coefficients positifs dont la somme vaut un. Un second produit utilise ces coefficients pour mélanger les valeurs V.

Q et K Comparer requêtes et clés
Softmax Normaliser les scores
V Combiner les valeurs
Sortie Résultat de l’attention
Dépendances de l’attention. Le traitement par tuiles permet de recouvrir une partie du travail.

La seconde multiplication dépend donc du softmax. Celui-ci doit notamment calculer des exponentielles et des sommes, puis fournir les coefficients dans une représentation exploitable. Les Tensor Cores, unités spécialisées dans les produits matriciels, ne réalisent pas seuls toute cette chaîne.

FlashAttention découpe le travail en blocs, appelés tuiles. Il accumule le résultat au fil de leur traitement, ce qui évite de stocker puis relire toute la matrice des scores dans la mémoire externe du GPU. Cette économie de transferts est le principe du travail fondateur. Elle ne supprime pas les comparaisons entre positions que demande l’attention dense.

Blackwell déplace la limite vers les autres unités

Dans l’analyse matérielle de l’équipe, le débit matriciel BF16 par cycle et par unité de traitement double entre Hopper et B200, tandis que le débit des exponentielles reste identique. La lecture de mémoire partagée ne suit pas non plus cette progression. Ces rapports décrivent les ressources comparées par les auteurs ; ils ne signifient pas qu’un kernel complet double de vitesse. Analyse de Tri Dao.

Un exemple hypothétique permet de suivre l’effet. Supposons qu’une tuile demande 80 unités de temps pour les multiplications, 30 pour le softmax et 20 pour les transferts. Sans recouvrement, elle coûte 130 unités. Doubler uniquement le débit matriciel ramène ce total à 90. Le gain du programme est de 1,44×, malgré des multiplications deux fois plus rapides.

Avec plusieurs tuiles, certaines opérations peuvent avancer ensemble. Dans un pipeline idéal, leur rythme serait limité par l’étape la plus longue. Si le temps matriciel descend à 20, le softmax à 30 devient cette limite. Il s’agit d’une borne pédagogique : les dépendances, la capacité des buffers et le démarrage du pipeline empêchent de supposer un recouvrement parfait.

Faire avancer plusieurs tuiles sans écraser leurs données

La réponse de FA4 consiste notamment à donner des rôles distincts aux groupes de threads, les fils d’exécution du GPU. Certains préparent les données, d’autres calculent le softmax, d’autres lancent les opérations matricielles. Pendant qu’une tuile passe par le softmax, une autre peut occuper les unités de multiplication.

Le code SM100 étudié réserve plusieurs zones pour les résultats intermédiaires. Il utilise la Tensor Memory, une mémoire interne liée au calcul matriciel sur cette architecture. Chaque zone a une durée de vie : un producteur y écrit, un consommateur la lit, puis elle peut être réutilisée. Une unité libre ne peut pas avancer si la seule zone disponible contient encore des valeurs nécessaires ailleurs. Implémentation forward à version fixe.

Le programme peut aussi annoncer qu’une première partie des coefficients est prête avant la fin du reste. Le consommateur commence alors à travailler sur cette partie. Des synchronisations distinctes protègent la suite. C’est une manière de raccourcir l’attente sans autoriser la lecture de données incomplètes.

Ce mécanisme explique pourquoi l’optimisation ne se résume pas à lancer davantage de threads. Conserver plusieurs tuiles en cours consomme de la mémoire interne et des registres, les petits espaces de stockage proches du calcul. Augmenter le parallélisme peut finir par réduire les ressources disponibles pour chaque groupe.

Déplacer une partie des exponentielles

FA4 agit aussi sur le travail à réaliser entre les produits matriciels. Dans le code de softmax examiné, une partie des exponentielles peut être calculée par une approximation utilisant des multiplications et additions ordinaires, pendant que les autres utilisent l’instruction spécialisée. Cette répartition donne du travail à des unités différentes. Softmax, fonctions d’approximation.

L’opération a un coût : elle ajoute des instructions et des valeurs temporaires. Son intérêt dépend donc de la pression sur les unités spécialisées et des ressources encore disponibles. Remplacer toutes les exponentielles de la même manière ne serait pas automatiquement meilleur.

Le softmax traité par tuiles doit également conserver une échelle commune entre les contributions anciennes et nouvelles. Le code peut éviter certains changements d’échelle sous condition. Ce choix réduit des corrections intermédiaires, tout en imposant de préserver la cohérence des sommes et une plage numérique admissible. La normalisation finale ne peut pas réparer une valeur qui a déjà débordé.

Le FP4 ajoute un compromis numérique

Un travail distinct, signé Robert Hu et publié en septembre, explore le calcul en quatre bits. Il prolonge la question du pipeline : préparer et convertir les données peut absorber une partie du bénéfice d’une multiplication plus rapide. Il ne faut pas l’attribuer à l’équipe du papier FA4 original ni supposer qu’il est intégré à la bêta officielle. Prépublication FP4.

Ses variantes et leurs frontières de mesure diffèrent. Une passe forward calcule les sorties de l’attention ; en mode non causal, elle peut utiliser toutes les positions de la séquence. Son accélération ne démontre pas un gain identique pour la génération de texte, où chaque position ne doit accéder qu’aux positions autorisées par le masque causal. Les essais d’entraînement demandent aussi de suivre la qualité sur la durée. Le meilleur ratio d’un kernel ne suffit donc pas à annoncer la vitesse d’un modèle complet.

Le gain du kernel doit encore traverser le modèle

Le papier FA4 rapporte jusqu’à 1,3× face à cuDNN 9.13 en BF16 sur B200. Ce plafond concerne les tests d’attention publiés. Une incohérence subsiste dans la version consultée : l’annexe A.1 mentionne B100 et mars 2025, alors que le corps présente B200 et que le papier date de mars 2026. Nous conservons le chiffre comme résultat attribué, sans corriger silencieusement le protocole. Papier et annexe.

Pour le développeur, il reste à savoir quelle fraction du travail ce kernel occupe. Dans une hypothèse où l’attention représente 40 % du temps total, la rendre deux fois plus rapide ramène la durée à 80 % de l’original, soit 1,25× de vitesse globale. Les autres couches, communications et traitements continuent à coûter du temps.

L’intérêt pratique de FA4 se mesure donc avec le modèle, les longueurs de séquence et le matériel visés. Il faut vérifier quel kernel le moteur sélectionne effectivement, puis comparer la durée totale et la qualité des résultats. La leçon technique reste forte : les gains du silicium deviennent utiles lorsque le logiciel parvient à alimenter ses unités rapides sans déplacer toute l’attente juste à côté.

Sources et méthode

Analyse rédigée le 6 octobre 2026 à partir du dossier technique du 2 octobre, des copies de code fournies et d’une réouverture ciblée des publications. Aucun benchmark GPU n’a été exécuté par LeCompute. Les exemples chiffrés de pipeline et de gain global sont des hypothèses pédagogiques.

Le papier FA4 et le billet de Tri Dao établissent le problème architectural. Le tag bêta 33 établit l’actualité logicielle du 30 septembre. L’explication du code porte sur le commit 843bf0b86bda1c92edc440ec58f9b5194609abac, conservé dans le dossier ; ce n’est pas le commit supposé de toutes les mesures historiques. Le papier FP4 de Robert Hu est traité séparément. Les observations SM100 ne sont pas transposées aux RTX 50.