🤖 AI

Memory-Bound but Not Bandwidth-Limited: The Physical AI Inference Gap in Batch-1 LLM Decode

Cet article révèle que si l'inférence LLM en batch-1 de l'IA physique est dominée par la mémoire, les GPU plus rapides souffrent de surcoûts de lancement disproportionnés qui empêchent des gains de latence proportionnels, et que les méthodes de quantification standard échouent souvent à atteindre les accélérations attendues à moins d'être couplées à des noyaux hautement optimisés comme GPTQ+ExLlamaV2.

Auteurs originaux : Josef Chen

Publié 2026-06-01

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Josef Chen

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

La vue d'ensemble : La « Voiture de course » vs le « Embouteillage »

Imaginez que vous essayiez de conduire une voiture du point A au point B. Vous avez deux types de voitures :

La L4 : Une berline standard et fiable.
La H100 : Une voiture de Formule 1 hyper rapide avec un moteur massif.

Le papier pose une question simple : Si vous conduisez seul (Batch-1) et que vous n'avez besoin de transporter qu'un tout petit peu de bagages (un seul robot ou une seule session utilisateur), quelle voiture vous amènera plus vite ?

La croyance commune était : « La voiture de Formule 1 (H100) est 11 fois plus rapide car elle a un moteur beaucoup plus gros (bande passante mémoire). Elle devrait gagner à tous les coups. »

La conclusion du papier : La voiture de Formule 1 perd en réalité, ou du moins ne gagne pas de beaucoup. Pourquoi ? Parce que la voiture de course est si rapide que le temps nécessaire pour démarrer le moteur et passer la vitesse (le surcoût de lancement CPU) devient le principal retard. Sur la berline plus lente, c'est le moteur qui est le goulot d'étranglement, donc démarrer n'a pas autant d'importance.

Le problème central : « La taxe de lancement »

Dans le monde de l'IA, lorsqu'un ordinateur génère un mot (token) à la fois, il doit effectuer un ensemble de tâches spécifiques encore et encore.

La vision classique : La vitesse dépend entièrement de la rapidité avec laquelle l'ordinateur peut lire sa mémoire (comme la vitesse à laquelle un bibliothécaire peut courir vers les étagères pour attraper des livres). La H100 possède des étagères super rapides, donc cela devrait être instantané.
La nouvelle vision : La vitesse dépend du nombre de fois où l'ordinateur doit dire : « OK, commence cette tâche ! » au matériel.

L'analogie :
Imaginez un livreur (le GPU) qui doit livrer un colis.

Sur la L4 (Livreur lent) : Le livreur passe 20 minutes à conduire jusqu'à la maison et 1 minute à se garer. La conduite est le goullet d'étranglement.
Sur la H100 (Livreur rapide) : Le livreur peut conduire jusqu'à la maison en 1 minute. Mais, chaque fois qu'il dépose un colis, il doit passer 30 secondes à marcher du camion jusqu'à la porte, signer un formulaire et revenir en arrière.
- Parce que la conduite est très rapide, ces 30 secondes de « marche vers la porte » (la Taxe de lancement) deviennent la raison principale pour laquelle la livraison est lente.
- La H100 est si puissante qu'elle reste inactive, attendant que le livreur finisse la paperasse.

L'expérience : Le correctif des « Graphes »

Pour prouver cela, les chercheurs ont testé une astuce appelée CUDA Graphs.

L'analogie :
Au lieu que le livreur demande : « Puis-je commencer ? OK, allez-y. Puis-je commencer ? OK, allez-y » pour chaque colis, ils écrivent un script maître (un graphe) qui dit : « Conduire, Se garer, Déposer, Retourner, Répéter ». Ils remettent ce script au livreur une seule fois, et le livreur suit simplement le script sans demander la permission à chaque fois.

Les résultats :

Sur la H100 (Voiture de course) : Ce script a fait une énorme différence. La voiture a accéléré de 26 %. Cela a prouvé que la « paperasse » (le surcoût de lancement) était bien le problème.
Sur la L4 (Berline) : Le script n'a fait presque aucune différence (seulement 3 % de vitesse en plus). C'est parce que la berline passait déjà la majeure partie de son temps à conduire (lire la mémoire), et non à attendre la paperasse.

L'échelle des coûts « inversée »

Voici la partie la plus surprenante du papier.

Habituellement, les entreprises pensent : « Si je veux économiser de l'argent, je devrais acheter la puce la moins chère et la plus lente (L4). Si je veux de la vitesse, j'achète la puce la plus chère et la plus rapide (H100). »

Le papier dit : Pour l'IA à flux unique (comme un robot qui vous parle), c'est l'inverse.

La H100 est chère et rapide, mais elle gaspille une grande partie de sa vitesse dans la « paperasse ».
La L4 est bon marché et lente, mais elle utilise 100 % de sa vitesse pour le travail réel.

L'astuce « Magique » :
Les chercheurs ont découvert que si l'on prend la L4 bon marché et que l'on utilise un type spécifique de « compression » logicielle (appelée ExLlamaV2), la L4 devient presque aussi rapide que la H100.

H100 avec des astuces : 11,78 millisecondes par étape.
L4 avec des astuces : 17,36 millisecondes par étape.

Même si la H100 est 11 fois plus puissante sur le papier, la L4 (avec le bon logiciel) n'est qu'environ 1,5 fois plus lente, mais elle coûte 10 fois moins cher à faire fonctionner.

Résumé des points clés

Rapide ne signifie pas toujours plus rapide : Ce n'est pas parce qu'une puce a une « autoroute mémoire » (bande passante) plus large qu'elle terminera le travail plus vite si le « temps de démarrage » (surcoût de lancement) est trop long.
Le goulot d'étranglement se déplace :
- Sur les puces bon marché (L4), le goulot d'étranglement est le déplacement des données (bande passante mémoire).
- Sur les puces coûteuses (H100), le goulot d'étranglement est le démarrage des tâches (surcoût de lancement CPU).
Le logiciel compte plus que le matériel : Pour ces tâches d'IA spécifiques (traitement « un par un »), choisir le bon logiciel (comme ExLlamaV2) sur une puce bon marché est une meilleure affaire que d'acheter la puce la plus chère.
À qui cela s'adresse-t-il ? Cela s'applique à l'IA Physique : les robots, les voitures autonomes et les assistants personnels qui vous parlent phrase par phrase. Cela ne s'applique pas aux chatbots qui parlent à des milliers de personnes à la fois (traitement par lots/batch processing), où les règles sont différentes.

En bref : Si vous construisez un robot qui doit réfléchir et vous parler en temps réel, n'achetez pas simplement le supercalculateur le plus cher. Achetez un ordinateur moins cher et optimisez le logiciel pour éviter qu'il ne perde du temps sur la « paperasse ». Vous obtiendrez de meilleures performances pour moins d'argent.

Résumé technique : Limité par la mémoire mais pas par la bande passante : le fossé de l'inférence de l'IA physique dans le décodage LLM en batch-1

Énoncé du problème

Les systèmes d'IA physique (robots, véhicules autonomes, copilotes en périphérie/edge) opèrent généralement sous une charge de travail de décodage autoregressif à flux unique, en batch-1. Contrairement au service dans le cloud qui optimise le débit via de grands batchs, l'IA physique attend le jeton suivant pour un utilisateur ou un agent unique. L'hypothèse dominante de l'industrie est que cette charge de travail est strictement limitée par la bande passante de la HBM, ce qui signifie que la latence évolue inversement avec la bande passante de crête ( $B_{peak}$ ). Par conséquent, l'échelle de déploiement est supposée être $L4 \to L40S \to A100 \to H100$ , où une bande passante plus élevée se traduit directement par une latence et un coût par jeton plus faibles.

Cette publication remet en question cette hypothèse, arguant que pour le décodage en batch-1 sur du silicium rapide (ex: H100), le goulot d'étranglement passe de la bande passante mémoire à l'overhead de lancement de noyau par le CPU. Les auteurs postulent que la mémoire plus rapide ne se traduit pas par des gains de latence proportionnels car le coût fixe de lancement des noyaux devient la fraction dominante du temps d'étape sur les GPU à haute bande passante, tandis que les GPU plus lents restent véritablement limités par la bande passante.

Méthodologie

L'étude est une expérience de mesure contrôlée, et non un modèle théorique, menée sur des hôtes cloud Modal utilisant quatre GPU NVIDIA : H100 SXM5, A100-80GB SXM4, L40S et L4.

Charge de travail : Trois transformeurs GQA de 7 à 8 paramètres (Qwen-2.5-7B, Mistral-7B-v0.3, Llama-3.1-8B) avec des poids bf16 et une attention SDPA.
Portée : 44 cellules valides couvrant 4 longueurs de contexte (de 2048 à 16384) et 4 GPU.
Métriques :
- $R_{floor}$ : Le ratio entre le plancher analytique de la mémoire ( $t_{floor} = (W+K)/B_{peak}$ ) et le temps d'étape observé ( $t_{obs}$ ). Une valeur de 1,0 indique une utilisation parfaite de la bande passante.
- Test A/B CUDA Graphs : Une expérience de falsification comparant l'exécution "eager" (impulsive) à l'exécution "graphée" (rejeu de DAG) pour isoler l'overhead de lancement.
- Matrice de la pile logicielle : Comparaisons des backends d'attention (SDPA, FlashAttention-2/3, FlashInfer) et des chemins de quantification (bf16, bnb-nf4, AutoAWQ+Marlin, GPTQ+ExLlamaV2).

Résultats clés

1. L'inversion de l'échelle du coût par jeton

L'étude révèle une divergence marquée dans l'utilisation de la bande passante :

L4 (300 Go/s) : Atteint environ 81 % de la bande passante HBM de crête ( $R_{floor} \approx 0,81$ ). La charge de travail est véritablement limitée par la mémoire.
H100 (3350 Go/s) : Atteint seulement environ 27 % de la bande passante HBM de crête ( $R_{floor} \approx 0,27$ ).
Implication : L'avantage de bande passante de 11x de l'H100 sur le L4 ne produit pas un gain de vitesse de 11x. Au lieu de cela, l'H100 est ralenti par l'overhead de lancement, tandis que le L4 est ralenti par le trafic mémoire.

2. Test de falsification par CUDA Graphs

Les auteurs ont isolé le mécanisme en supprimant l'overhead de lancement CPU via les CUDA Graphs :

Sur H100 (ctx=2048) : Les CUDA Graphs ont amélioré la latence de 1,259× (IC 95 % [1,253, 1,267]). Cela confirme que l'overhead de lancement représente environ 20 % du temps d'étape.
Sur L4 (ctx=2048) : Cette même intervention n'a produit qu'une amélioration de 1,028×.
Conclusion : La "taxe de lancement" est la contrainte limitante sur l'H100 pour le décodage en batch-1, tandis que la bande passante est la contrainte sur le L4.

3. Sélection du noyau d'attention

Contrairement à la croyance selon laquelle les variantes de FlashAttention sont toujours supérieures :

Sur l'H100 en batch-1, le dispatcher SDPA par défaut de PyTorch (36,05 µs/couche) a surpassé FlashAttention-3 explicite (79,25 µs), FlashInfer (48,20 µs) et même le contexte FlashAttention-2 (44,35 µs).
La contrainte limitante est la séquence de lancements de noyaux, et non le débit du noyau d'attention lui-même.

4. Quantification et implémentation de noyau sur L4

Sur le L4, limité par la bande passante, la quantification seule est insuffisante ; l'implémentation du noyau est cruciale :

bf16 : 62,32 ms/étape.
bnb-nf4 : 59,36 ms/étape (gain négligeable dû à l'overhead de déquantification).
AutoAWQ + Marlin : 45,24 ms/étape (accélération de 1,38×). Marlin est optimisé pour l'architecture Ampere (SM80), pas Ada (SM89).
GPTQ + ExLlamaV2 : 17,36 ms/étape (accélération de 3,59×). Les noyaux d'ExLlamaV2 sont optimisés pour l'architecture Ada (SM89), réalisant ainsi les économies théoriques de bande passante.
Résultat : Un L4 avec ExLlamaV2 (17,36 ms) est nettement plus rapide qu'un H100 en exécution eager standard (14,83 ms) et compétitif avec un H100 utilisant des CUDA Graphs (11,78 ms), malgré le fait que l'H100 possède 11x la bande passante de crête.

Signification et affirmations

L'article affirme démontrer que l'échelle de déploiement standard ( $L4 \to H100$ ) est inversée pour les charges de travail d'IA physique :

Dominance de l'overhead de lancement : Sur les GPU rapides (H100) avec des contextes courts, l'overhead de lancement CPU par noyau domine le temps d'étape, rendant la bande passante mémoire de crête largement non pertinente.
Implémentation de noyau > Mise à niveau matérielle : Pour le décodage de streaming en batch-1, optimiser l'implémentation du noyau (ex: utiliser ExLlamaV2 sur L4) produit des réductions de latence plus importantes que la mise à niveau vers un GPU à plus haute bande passante.
Efficacité des coûts : Aux tarifs publiés par Modal (mai 2026), un L4 avec des noyaux optimisés sert les jetons à un coût environ 6 fois inférieur à celui d'un H100 avec CUDA Graphs, malgré les spécifications brutes supérieures de l'H100.
Limitation de la portée : Les auteurs précisent explicitement que ces résultats s'appliquent aux transformeurs GQA de 7–8B, au batch-1, au bf16 et au décodage à flux unique. Ils ne prétendent pas que ces résultats se généralisent aux grands batchs (où la taxe de lancement diminue), aux différentes architectures (MHA/MQA) ou à d'autres matériels (AMD, Blackwell).

L'article conclut que pour l'inférence d'IA physique, l'étiquette "limité par la mémoire" est incomplète ; le système est souvent limité par le lancement sur le silicium haut de gamme (H100) et limité par la bande passante sur le silicium périphérique (L4), nécessitant des leviers d'optimisation différents (CUDA Graphs vs noyaux spécialisés) plutôt qu'un simple parcours de mise à niveau matérielle.