Flash Attention réduit le trafic mémoire en découpant l’attention exacte en tuiles, afin que les scores intermédiaires puissent être traités sur la puce au lieu d’être écrits puis relus à plusieurs reprises depuis la HBM du GPU.
Sur un serveur IA local, cet effet devient plus important à mesure que la longueur du prompt augmente, car l’attention standard génère un volume de travail intermédiaire de plus en plus important. Flash Attention ne modifie pas les connaissances du modèle et ne supprime pas son cache KV : il réorganise le calcul de l’attention afin de transférer moins de données à travers les niveaux les plus lents de la hiérarchie mémoire du GPU.
L’attention standard fait transiter de grands tenseurs intermédiaires par la HBM
L’attention commence par des tenseurs de requêtes, de clés et de valeurs. Elle doit calculer les scores, les normaliser, puis les combiner avec les valeurs. Une implémentation directe matérialise de grandes matrices intermédiaires dans la mémoire à large bande passante entre ces étapes.
L’article original consacré à FlashAttention soutient que les performances de l’attention sont limitées non seulement par les calculs arithmétiques, mais aussi par les lectures et écritures entre la HBM et la SRAM sur puce. Les longues séquences amplifient ce trafic, car la matrice des scores augmente avec le nombre de paires de tokens.
Un GPU domestique peut donc consacrer un temps considérable au déplacement des données plutôt qu’à l’exécution de calculs matriciels utiles, en particulier lorsque la longueur du contexte augmente.
Flash Attention découpe le problème en ensembles de travail stockés sur la puce
Flash Attention traite des blocs de requêtes, de clés et de valeurs suffisamment petits pour tenir dans la mémoire rapide sur puce. Chaque tuile exécute plusieurs étapes de l’attention avant que les données intermédiaires ne quittent la puce.
FlashAttention-3 décrit l’approche centrale de cette famille comme une stratégie de découpage en tuiles qui évite le trafic intermédiaire vers la mémoire globale. L’algorithme produit toujours une attention exacte pour la formulation prise en charge.
La taille des tuiles dépend des ressources matérielles et de l’implémentation du noyau. Le mécanisme essentiel est la localité des données : réutiliser les valeurs chargées tant qu’elles restent proches des unités de calcul.
Le softmax en ligne évite de stocker la matrice complète des scores
Le softmax ordinaire semble nécessiter l’ensemble des scores d’une ligne avant la normalisation, ce qui obligerait l’implémentation à matérialiser une grande matrice. Flash Attention conserve plutôt des statistiques de normalisation cumulées entre les tuiles.
Le tutoriel de Triton sur l’attention fusionnée présente une attention fusionnée avec un état de softmax traité par blocs. Les blocs de scores partiels peuvent ainsi être consommés puis supprimés sans réécrire chaque valeur intermédiaire dans la HBM.
C’est là que se rejoignent la réduction du trafic mémoire et celle de la mémoire temporaire : l’algorithme réorganise le calcul de sorte qu’un grand objet intermédiaire n’ait jamais besoin d’exister dans la mémoire globale.
La fusion des noyaux maintient une plus grande partie de la chaîne d’attention dans un seul chemin d’exécution
Le calcul des scores, la mise à l’échelle, l’application du masque, la normalisation et l’agrégation des valeurs peuvent être fusionnés dans un noyau coordonné, plutôt que d’être exécutés par des noyaux distincts qui échangent des données intermédiaires complètes via la mémoire globale.
L’interface d’attention à produit scalaire mise à l’échelle de PyTorch peut sélectionner des implémentations d’attention fusionnées lorsque le périphérique, le type de données, la forme et les fonctionnalités demandées sont pris en charge.
Le résultat peut être un traitement des prompts plus rapide et une quantité moindre de mémoire temporaire maximale utilisée, mais le gain exact dépend du fait que l’environnement d’exécution utilise réellement ou non un noyau compatible avec Flash Attention.
La réduction des entrées-sorties n’équivaut pas à la suppression du cache KV
Lors de l’inférence autorégressive, les clés et valeurs déjà générées doivent toujours rester disponibles pour les tokens suivants, sauf si le modèle ou l’environnement d’exécution utilise un mécanisme distinct d’éviction, de compression, de fenêtrage ou de déport.
La documentation ROCm d’AMD décrit Flash Attention comme une technologie améliorant la localité mémoire entre le stockage sur puce et la HBM. Cette optimisation concerne la manière dont l’attention lit et traite l’état actif, et non l’existence ou non de l’état KV historique.
Cette distinction permet d’éviter une erreur courante lors de la planification : Flash Attention peut réduire la mémoire de travail et les entrées-sorties, tandis qu’un serveur à contexte long peut tout de même manquer de capacité parce que le cache KV conservé continue de croître.
La prise en charge du matériel et des formes détermine l’utilisation du chemin rapide
Les noyaux Flash sont spécialisés. La dimension des têtes, le type de données, le masque d’attention, l’architecture du GPU, la version de l’environnement d’exécution et d’autres fonctionnalités peuvent imposer un retour à une autre implémentation.
L’article de ZimaSpace sur la mémoire de l’attention par rapport aux paramètres du modèle traite de la question de la capacité. Flash Attention doit être évalué séparément, comme une optimisation du chemin d’exécution.
Testez des prompts courts et longs, vérifiez le moteur sélectionné, puis consignez la latence de préremplissage, la mémoire maximale allouée, la bande passante mémoire et le débit de tokens générés. Le guide de ZimaSpace sur le matériel d’IA local fournit la référence générale en matière de capacité que l’optimisation des noyaux ne peut pas remplacer.
Le Transformer Engine de NVIDIA présente des moteurs d’attention optimisés et une exécution dépendante du matériel dans le cadre d’une pile plus large de sélection des noyaux.
Centre Tech & IA
Plus à lire

Les caméras domestiques peuvent-elles synchroniser les événements sans services horaires cloud ?
Une explication axée sur les mécanismes de l’heure de la caméra sans cloud, ses compromis liés aux ressources partagées, trois FAQ sur la diffusion...

Un service d’IA local peut-il détecter les couches de modèle corrompues avant l’inférence ?
Une explication axée sur les mécanismes de la détection des couches de modèle corrompues, de ses compromis en matière de ressources partagées, de trois...

Un système RAG peut-il être restauré sans régénérer chaque embedding ?
Une explication de la restauration RAG sans réencodage, axée sur le mécanisme, de ses compromis en matière de ressources partagées, trois FAQ sur la...

