🤖 machine learning

Tile-Level Activation Overlap for Efficient LLM Inference

Cet article présente deux noyaux spécialisés basés sur CUTLASS pour SM90 qui fusionnent l'activation SwiGLU avec la multiplication matricielle au niveau du tile afin d'éliminer le surcoût de matérialisation des tenseurs intermédiaires, atteignant jusqu'à 2,47x d'accélération et 79,5 % d'utilisation de crête sur les GPU NVIDIA H100 tout en surpassant PyTorch et cuBLAS en termes d'efficacité et de précision numérique.

Auteurs originaux : Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Publié 2026-07-07

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous dirigez une usine à haute vitesse qui construit des robots complexes (ces robots sont des Modèles de Langage de Grande Taille ou LLM, comme ceux qui alimentent les chatbots). Pour construire chaque robot, votre usine dispose d'une ligne d'assemblage spécifique appelée MLP (une partie centrale du cerveau du robot).

Pendant longtemps, cette ligne d'assemblage a souffert d'une inefficacité majeure. Voici le problème et la solution présentée dans cet article, expliqués simplement.

Le Problème : Le goulot d'étranglement du « Intermédiaire »

Dans les usines de robots modernes, une étape spécifique appelée SwiGLU est utilisée pour rendre les robots plus intelligents. Considérez SwiGLU comme un contrôle qualité qui nécessite deux calculs distincts :

Calcul A : Mesurer l'état actuel du robot.
Calcul B : Mesurer le potentiel du robot.
La Colle : Combiner ces deux mesures pour obtenir le résultat final.

L'Ancienne Méthode (Le Goulot d'Étranglement) :
Dans la configuration standard d'une usine (comme celle utilisée par PyTorch), après avoir effectué le Calcul A, les ouvriers doivent noter les résultats sur un immense tableau blanc dans le couloir (Mémoire à Haute Bande Passante ou HBM). Ensuite, ils doivent marcher jusqu'au tableau, lire ce résultat, effectuer le Calcul B, écrire ce nouveau résultat sur un second tableau blanc, et enfin revenir lire les deux tableaux pour effectuer l'étape de la « Colle ».

L'article a découvert que pour les petits robots (petits modèles d'IA), ce « trajet vers le tableau blanc » représente 30 % à 37 % du temps total. C'est comme un chef qui passerait la moitié de son temps à marcher jusqu'au garde-manger pour attraper une seule épice, plutôt qu'à cuisiner.

La Solution : Deux nouvelles « Super-Cuisines »

Les auteurs ont construit deux nouvelles cuisines personnalisées (appelées Kernels) qui éliminent totalement les tableaux blancs. Au lieu d'écrire les résultats et de faire des allers-retours, les ouvriers gardent les ingrédients dans leurs mains (dans les Registres) et effectuent tout en un mouvement continu.

Ils ont créé deux stratégies différentes selon la taille de l'usine :

1. La Cuisine « Ping-Pong » (Kernel-1)

Comment ça marche : Imaginez une course de relais. Pendant qu'un ouvrier va chercher la prochaine fournée d'ingrédients (chargement des données), un autre ouvrier est déjà en train de mélanger la fournée actuelle.
L'Astuce : Ils utilisent un programme « Ping-Pong ». Pendant que la machine est occupée à chercher le deuxième ensemble d'ingrédients, les ouvriers utilisent exactement ce même temps pour effectuer le calcul de la « Colle » sur le premier ensemble.
Idéal pour : Les usines fabriquant de très gros robots (Grands Modèles) ou faisant fonctionner beaucoup de robots en même temps (Grands Batches). C'est comme une ligne d'assemblage massive où il y a assez d'ouvriers pour que les grosses machines soient pleinement occupées.

2. La Cuisine « Entrelacée » (Kernel-2)

Comment ça marche : Imaginez que vous emballez des boîtes. Au lieu d'emballer tous les objets rouges, puis tous les bleus, vous emballez un objet rouge, puis un bleu, puis un rouge, en les alternant parfaitement.
L'Astuce : Ils mélangent les deux matrices de poids (les « recettes » pour les calculs) avant de commencer. Cela permet aux ouvriers de saisir un ingrédient « rouge » et un « bleu » simultanément et de les traiter ensemble immédiatement.
Idéal pour : Les usines fabriquant de plus petits robots ou faisant fonctionner moins de robots à la fois (Petits Batches). Cette méthode est si efficace qu'elle maintient le sol de l'usine entièrement rempli d'ouvriers, évitant que quiconque ne reste à attendre sans rien faire.

Les Résultats : Vitesse et Précision

Les auteurs ont testé ces nouvelles cuisines sur des puces NVIDIA H100 (les processeurs d'IA les plus puissants disponibles) en utilisant diverses tailles de robots (allant de minuscules modèles de 0,5 Md à des modèles massifs de 72 Md).

Accélérations Massives : Pour les plus petits robots, les nouvelles cuisines étaient 2,47 fois plus rapides que l'ancienne méthode standard. C'est comme réduire une tâche de 10 minutes à 4 minutes.
Déplacement du Goulot d'Étranglement : L'ancien système était « Limité par la Mémoire » (passant trop de temps à marcher vers le tableau blanc). Le nouveau système est « Limité par le Calcul » (passant tout son temps à réellement faire les mathématiques). Ils ont atteint 79,5 % de la vitesse théorique maximale de la puce.
Le Compilateur ne peut pas le faire : Les auteurs ont tenté d'utiliser le logiciel « pilote automatique » standard (le torch.compile de PyTorch) pour corriger cela automatiquement. Il a échoué. Le pilote automatique était 3 à 7 fois plus lent que leurs cuisines personnalisées. Cela prouve que pour ce problème spécifique, il faut un expert humain pour concevoir la solution à la main ; l'ordinateur ne peut pas encore le découvrir par lui-même.
Meilleure Précision : Étonnamment, les nouvelles cuisines personnalisées étaient également plus précises que la méthode standard. La méthode standard présentait de petites erreurs mathématiques dans 4,5 % à 11 % des résultats, tandis que les nouvelles cuisines affichaient zéro erreur.

Résumé

L'article montre qu'en réorganisant le fonctionnement du plancher de l'usine — spécifiquement en empêchant les ouvriers de marcher constamment vers le tableau blanc pour lire ou écrire des notes intermédiaires — nous pouvons faire fonctionner les modèles d'IA beaucoup plus rapidement, en particulier pour les modèles plus petits utilisés sur les appareils de bord (comme les téléphones ou les ordinateurs portables). Ils ont prouvé que les outils logiciels standards ne peuvent pas reproduire cette efficacité, nécessitant du code spécialisé écrit à la main pour atteindre ces résultats.

Résumé technique : Chevauchement d'activation au niveau des tuiles pour une inférence efficace de LLM

Énoncé du problème

Les modèles de langage de grande taille (LLM) modernes, incluant Qwen-2.5, LLaMA, Mistral et Gemma, utilisent principalement la fonction d'activation SwiGLU. Cette structure de porte MLP calcule $Y = \text{SiLU}(A \times W_1) \odot (A \times W_2)$ , ce qui nécessite deux multiplications matricielles (GeMM) indépendantes suivies d'une activation par produit élémentaire.

Dans les implémentations standards, ce processus matérialise deux tenseurs intermédiaires complets ($Gate$ et $Up$) dans la mémoire haute bande passante (HBM) entre les étapes de GeMM et d'activation. Le profilage sur les GPU NVIDIA H100 révèle que cette matérialisation intermédiaire et le calcul d'activation associé consomment 9 à 37 % du temps d'exécution total du MLP. L'overhead est plus sévère pour les petits modèles (ex. Qwen-2.5 0.5B), où SwiGLU représente plus de 30 % du temps du MLP. À mesure que la densité arithmétique des Tensor Cores augmente via la quantification (FP8, INT4), le coût relatif de ces opérations limitées par la mémoire croît, créant un goulot d'étranglement significatif.

L'infrastructure de compilation existante, spécifiquement torch.compile de PyTorch, ne parvient pas à résoudre ce problème. Elle ne peut pas fusionner des opérations à travers deux GeMM distincts possédant des matrices de poids différentes en raison de limitations fondamentales dans les passes de fusion au niveau du graphe. Les expériences montrent que torch.compile n'atteint que 34 à 94 % de la performance de PyTorch en mode "eager" pour ce motif, les indices de fusion explicites n'apportant qu'une amélioration négligeable.

Méthodologie

Les auteurs présentent deux noyaux (kernels) basés sur CUTLASS SM90 complémentaires, conçus à la main, qui fusionnent SwiGLU dans le GeMM au niveau des tuiles (tiles), éliminant ainsi la matérialisation intermédiaire en HBM. Les deux noyaux exploitent l'accélérateur de mémoire tensorielle (TMA) et l'ordonnancement spécialisé par warps disponible sur l'H100 (SM90).

1. Kernel-1 : Chevauchement de l'ordonnancement Pingpong pour la synchronisation SwiGLU

Mécanisme : Ce noyau utilise l'ordonnancement spécialisé par warps "Pingpong" de CUTLASS, qui partitionne les warps en producteurs (charge de données via TMA) et consommateurs (exécution de l'MMA).
Stratégie : Il crée une grille de threadblocks $[M, N]$ . Dans la phase de consommation, après le calcul de la tuile "Gate" mais avant l'arrivée des données de la tuile "Up", il existe une brève fenêtre où les warps consommateurs sont inactifs. Le noyau exploite cette fenêtre pour calculer l'activation Swish ( $\text{SiLU}(Gate)$ ) sur l'accumulateur de la Gate résidant dans les registres.
Chevauchement : Le calcul de Swish chevauche temporellement les chargements TMA des tuiles de poids "Up". La multiplication élémentaire finale ( $\text{SiLU}(Gate) \odot Up$ ) et le stockage ont lieu dans l'épilogue.
Optimisation : Cette conception est optimisée pour les tailles de batch importantes ( $M \ge 2048$ ) où la grille $[M, N]$ sature suffisamment les multiprocesseurs de flux (SM) du GPU.

2. Kernel-2 : Entrelacement de SwiGLU via un arbre de visiteurs d'épilogue personnalisé

Mécanisme : Ce noyau introduit un nœud d'Arbre de Visiteur d'Épilogue (EVT) personnalisé appelé PairMulStore.
Stratégie : Il concatène les matrices de poids $W_1$ et $W_2$ en une seule matrice fusionnée $W_{fused} \in \mathbb{R}^{K \times 2N}$ avec des colonnes entrelacées (colonnes paires pour Gate, impaires pour Up). Le noyau lance un GeMM standard sur $[M, 2N, K]$ , créant une grille de threadblocks $[M, 2N]$ .
Fusion : Le nœud PairMulStore opère sur l'accumulateur $[M, 2N]$ au sein de chaque threadblock. Il lit des paires de colonnes adjacentes $(D[m, 2n], D[m, 2n+1])$ , applique $\text{SiLU}(D[m, 2n]) \odot D[m, 2n+1]$ , et stocke le résultat.
Chevauchement : Cette conception entrelace le calcul SwiGLU avec les stockages de tuiles. L'arithmétique de la tuile actuelle chevauche les stockages TMA asynchrones de la tuile précédente, offrant un chevauchement calcul-stockage.
Optimisation : L'augmentation de $2\times$ du nombre de threadblocks améliore considérablement l'occupation des SM pour les petites tailles de batch ( $M \le 2048$ ), ce qui en fait l'option par défaut privilégiée pour la plupart des configurations.

Contributions clés

Fusion au niveau des tuiles : La première implémentation fusionnant SwiGLU dans le GeMM au niveau des tuiles, éliminant 4 opérations HBM intermédiaires (lecture/écriture de Gate et Up) par étape d'inférence.
Stratégie de double noyau : Une approche complémentaire utilisant le Kernel-1 pour les grands batches (séquence Gate $\to$ Swish $\to$ Up) et le Kernel-2 pour les petits batches (poids entrelacés avec un EVT personnalisé), répondant différemment aux contraintes d'occupation et d'ordonnancement.
Supériorité numérique : Les noyaux fusionnés atteignent zéro écart (0 % d'éléments avec une erreur relative > 1 %) par rapport à une référence FP32, alors que l'implémentation de base cuBLAS présente 4,5 à 11 % d'écarts dus à l'accumulation partielle agressive en BF16 à travers les tuiles.
Validation des limites du compilateur : Preuve empirique démontrant que torch.compile ne peut pas reproduire cette fusion, restant 3 à 7 fois plus lent que les noyaux faits main.

Résultats

Évalués sur des modèles Qwen-2.5 (0.5B à 72B) sur NVIDIA H100 :

Accélération (Speedup) : Les noyaux atteignent jusqu'à 2,47× de vitesse par rapport à PyTorch eager (cuBLAS + SwiGLU séparé). Le Kernel-2 l'emporte dans 13 des 20 configurations testées, tandis que le Kernel-1 l'emporte dans 7/20 (principalement pour les grands modèles à haut batch size).
Changement de régime : L'analyse Roofline confirme que la fusion déplace la charge de travail de limitée par la mémoire vers limitée par le calcul. Pour les petits modèles, l'intensité arithmétique augmente jusqu'à 247 %, déplaçant le point de fonctionnement de part et d'autre de la crête du Roofline.
Utilisation : L'utilisation de pointe en BF16 atteint 79,5 % sur H100, doublant presque l'utilisation de la base pour les petits modèles.
Efficacité : L'efficacité de la fusion (accélération réelle vs économies de mémoire théoriques) est proche de 100 % pour les petits modèles. Pour le Kernel-2, l'efficacité dépasse 100 % dans plusieurs configurations grâce aux bénéfices du chevauchement calcul-stockage.
Scalabilité : L'accélération diminue avec la taille du modèle (2,47× pour 0.5B contre ~1,0× pour 72B à haut batch size) car le calcul GeMM domine le temps total, et la fraction relative du trafic mémoire intermédiaire diminue.

Signification

L'article soutient que pour l'inférence des LLM modernes, particulièrement pour les modèles de taille "edge" ou mobile (0.5B–14B), le goulot d'étranglement est passé du calcul brut au trafic mémoire causé par la matérialisation de tenseurs intermédiaires. Les auteurs démontent que une conception faite main et consciente du matériel est nécessaire pour surmonter les limitations des infrastructures de compilation actuelles. En éliminant les accès HBM intermédiaires et en chevauchant le calcul d'activation avec le mouvement de données, ces noyaux réduisent considérablement la latence d'inférence et améliorent l'utilisation du calcul, offrant une optimisation critique pour les systèmes de service en production où la latence et le débit sont contraints.