Le malentendu sur les FLOPS
Quand on compare deux GPU, le premier chiffre cité est toujours le même : les FLOPS. C’est aussi le moins utile pour l’inférence LLM. Un modèle de langage en génération autorégressive est, dans l’immense majorité des cas, memory-bound : la vitesse n’est pas fixée par la puissance de calcul mais par le débit avec lequel on peut lire les poids et le KV cache depuis la mémoire.
Le modèle du roofline le résume bien : tant que l’intensité arithmétique d’un kernel — le nombre d’opérations par octet lu — reste basse, on est plaqué contre le plafond « bande passante ». Et le decode d’un LLM, qui produit un seul token à la fois, a une intensité arithmétique désespérément basse.
Prefill vs decode : deux régimes opposés
Une requête LLM se déroule en deux phases qu’il faut absolument distinguer.
Le prefill traite le prompt entier d’un coup. Les matrices sont grandes, l’intensité arithmétique est élevée : cette phase peut effectivement saturer les Tensor Cores. Le decode génère ensuite les tokens un par un. Chaque token relit l’intégralité des poids et tout le KV cache accumulé. L’intensité arithmétique s’effondre.
La HBM, vrai plafond du decode
La mémoire à haute bande passante (HBM) est empilée au plus près du die précisément pour répondre à ce besoin. Chaque génération repousse le plafond — et c’est ce plafond, bien plus que les FLOPS, qui prédit le débit de génération.
| Génération | Bande passante / pile | Usage typique | Génération GPU |
|---|---|---|---|
| HBM2e | ≈ 410 Go/s | A100 80 Go (~2,0 To/s) | Ampere |
| HBM3 | ≈ 670 Go/s | H100 80 Go (3,35 To/s) | Hopper |
| HBM3e | ≈ 1,0 To/s | B100 / B200 192 Go (~8 To/s) | Blackwell |
Le saut Hopper → Blackwell tient surtout à la mémoire, comme on le détaille dans H100 vs B100. Doubler la bande passante double, en première approximation, le débit de decode d’un modèle memory-bound.
Le KV cache, ce poids qu’on oublie
Les poids du modèle sont fixes. Le KV cache, lui, grossit : pour chaque token déjà vu, chaque couche stocke un vecteur clé et un vecteur valeur. Sa taille croît linéairement avec la longueur de contexte et avec le nombre de requêtes traitées en parallèle.
Sur un modèle 70 B de type Llama servi en FP16, un contexte de 8k tokens représente déjà de l’ordre de 2 à 3 Go de KV cache par requête. Multipliez par un batch de 32 et la HBM se remplit de KV cache bien avant d’être limitée par les poids. C’est la raison d’être de techniques comme PagedAttention, abordées dans le comparatif des runtimes, et de la quantification du cache lui-même.
NVLink : quand un GPU ne suffit plus
Dès qu’un modèle — ou son KV cache — ne tient plus sur une seule carte, il faut le répartir. Le tensor parallelism découpe chaque couche entre plusieurs GPU, qui doivent alors s’échanger des activations à chaque étape. La bande passante de l’interconnexion devient un prolongement de la bande passante mémoire.
La règle pratique : tout ce qui force à descendre d’un cran dans cette hiérarchie coûte cher. Un modèle qui tient sur un seul GPU avec NVLink rapide bat souvent un modèle éclaté sur un réseau lent, même avec plus de FLOPS cumulés.
Ce que ça change pour le dimensionnement
Trois réflexes en découlent. Choisir un GPU pour sa bande passante et sa capacité HBM avant ses FLOPS. Budgéter le KV cache comme un poste de mémoire à part entière, fonction du contexte et du batch visés. Et préférer, à FLOPS égaux, la configuration qui garde le modèle sur le moins de GPU possible avec l’interconnexion la plus rapide.
Conclusion
Les LLM ne sont pas limités par le calcul ; ils sont limités par la vitesse à laquelle on leur sert leurs propres poids et leur propre cache. HBM et NVLink ne sont pas des détails de fiche technique : ce sont les deux variables qui décident réellement du débit et du coût par token en production.
Sources et méthode
Modèle roofline — S. Williams, A. Waterman, D. Patterson, Roofline: an insightful visual performance model for multicore architectures, Communications of the ACM, vol. 52, n° 4, p. 65-76, 2009 (DOI 10.1145/1498765.1498785).
Spécifications mémoire — bandes passantes totales issues des fiches constructeur : NVIDIA A100 (80 Go HBM2e, ~2,0 To/s), H100 (80 Go HBM3, 3,35 To/s) et B100/B200 (192 Go HBM3e, ~8 To/s) ; NVIDIA Hopper Architecture In-Depth pour le détail des piles. Les valeurs par pile du tableau sont des ordres de grandeur dérivés (bande passante totale ÷ nombre de piles actives : 5 pour A100 et H100, 8 pour B100/B200), pas des chiffres publiés tels quels.
Ordres de grandeur du KV cache — estimations calculées via 2 × couches × têtes KV × dimension de tête × longueur × octets, à partir des dimensions publiées de Llama 2/3 70B (80 couches, 8 têtes KV en GQA, dimension 128).
NVLink — bandes passantes par GPU issues de la documentation NVIDIA : 3ᵉ génération 600 Go/s (A100), 4ᵉ génération 900 Go/s (H100), 5ᵉ génération 1,8 To/s (Blackwell).
