High Bandwidth Memory — quand la mémoire bride les GPU IA

Les GPU les plus puissants sont souvent en attente, pas en train de calculer. La HBM, mémoire ultra-rapide collée sur les accélérateurs, est devenue le vrai facteur limitant de l'IA.

En bref

Les GPU modernes disposent de milliers de cœurs de calcul capables d’exécuter des milliards d’opérations par seconde. Pourtant, quand un grand modèle de langage génère du texte, ces cœurs passent la majeure partie du temps à attendre — non pas à calculer. Le goulot d’étranglement se situe dans la mémoire : combien de données on peut y lire par seconde. La High Bandwidth Memory (HBM) est la réponse de l’industrie à ce problème. Comprendre son fonctionnement, c’est comprendre pourquoi les datacenters IA coûtent si cher et pourquoi l’approvisionnement en puces est si tendu.

Le memory wall : un problème de 1994 qui n’a fait qu’empirer

En 1995, les chercheurs Wulf et McKee publient un article au titre évocateur : Hitting the Memory Wall: Implications of the Obvious. Leur observation : la vitesse de calcul des processeurs progresse bien plus vite que la vitesse d’accès à la mémoire. Les deux courbes divergent. Ce déséquilibre, ils l’appellent le memory wall.

Trente ans plus tard, le problème s’est aggravé de façon spectaculaire. Un GPU haut de gamme peut effectuer plusieurs centaines de téraflops. Mais si les données n’arrivent pas assez vite depuis la mémoire, cette puissance de calcul reste inutilisée.

Pour les grands modèles de langage, le problème est particulièrement aigu. Générer un token — une syllabe, un mot — exige de charger l’intégralité des poids du modèle depuis la mémoire. Pour un modèle de 70 milliards de paramètres stockés en demi-précision (FP16), cela représente environ 140 gigaoctets à chaque étape. À la vitesse de lecture d’un H100 (3,35 TB/s), cette seule opération prend ~42 millisecondes — quelle que soit la puissance de calcul disponible. C’est une limite dure, indépendante du nombre de cœurs.

Les chercheurs caractérisent ce phénomène avec le modèle Roofline : pour les modèles volumineux en inférence à faible parallélisme, le ratio opérations/octets lus est systématiquement inférieur au seuil à partir duquel le calcul devient le facteur limitant. La bande passante mémoire, pas les cœurs de calcul, bride l’inférence.

Ce qu’est la HBM, et pourquoi elle change les règles

La mémoire conventionnelle des GPU (GDDR6X) utilise un bus de 384 bits. La HBM adopte une approche radicalement différente : elle empile verticalement plusieurs couches de DRAM en 3D, les relie par des connexions traversant le silicium (les through-silicon vias, ou TSV), puis place cet empilement directement à côté du processeur sur un interposeur en silicium.

Le résultat : un bus de 1024 bits par stack au lieu de 384. La bande passante augmente sans qu’il soit nécessaire d’augmenter la fréquence d’horloge — ce qui limiterait la consommation et la chaleur dégagée.

La progression entre générations est notable :

Génération	Bande passante par stack	Capacité par stack	Exemple GPU
HBM2e (2019)	460 GB/s	jusqu’à 16 Go	A100 (Nvidia), MI200 (AMD)
HBM3 (2022)	819 GB/s	jusqu’à 24 Go	H100 SXM5 (Nvidia)
HBM3e (2024)	1,2 TB/s	jusqu’à 36 Go	H200 (Nvidia), MI300X (AMD), B200 (Nvidia)
HBM4 (prévue 2026)	~1,6 TB/s	en développement	—

Le H200 embarque 141 Go de HBM3e pour 4,8 TB/s de bande passante totale — 43 % de plus que le H100. Le MI300X d’AMD pousse jusqu’à 192 Go et 5,3 TB/s. Le Blackwell B200 de Nvidia franchit les 8 TB/s.

La HBM présente aussi une limite : la consommation énergétique. Un H100 SXM5 consomme 700 watts au total, en grande partie à cause des transactions mémoire. Dans les datacenters IA, cette contrainte thermique conditionne la densité d’installation et le coût d’exploitation — des postes rarement mis en avant dans les fiches techniques constructeur.

La pénurie : c’est la mémoire, pas le processeur

Une conséquence directe de cette architecture : la HBM est difficile à produire. L’empilement 3D et les TSV exigent des procédés de fabrication beaucoup plus contraignants que la lithographie standard. Les rendements sont faibles, la montée en capacité est lente.

Trois acteurs contrôlent la quasi-totalité du marché mondial :

SK Hynix (~50 % de part de marché) : fournisseur exclusif de Nvidia pour le H100 au lancement, puis principal fournisseur pour les générations suivantes.
Samsung (~40 %) : fournisseur d’AMD et de Google (TPU), mais qui a rencontré des difficultés à faire certifier sa HBM3e par Nvidia en 2024.
Micron (~10 %) : entré en production HBM3e en 2024, qualifié pour le H200.

Cette concentration crée une dépendance structurelle. Quand la demande des datacenters IA a explosé à partir de 2023, la capacité de production n’a pas suivi. Nvidia a dû rationner ses H100, les délais de livraison ont atteint 12 à 18 mois, et le prix sur le marché secondaire a culminé autour de 40 000 dollars — contre ~30 000 en catalogue. La prime reflétait directement la rareté du composant mémoire, pas du processeur.

Ce que cette pénurie révèle : ce qui coûte le plus cher dans un accélérateur IA haut de gamme, c’est la mémoire collée dessus.

La contrainte ne réside pas dans la lithographie — les DRAM HBM sont fabriquées en nœuds avancés (1Z nm). Elle réside dans le processus TSV et l’assemblage 3D, qui sont des opérations précises, difficiles à paralléliser et à scaler. SK Hynix a annoncé 15 milliards de dollars d’investissement sur cinq ans pour augmenter ses capacités. Le délai entre l’investissement et la capacité de production disponible dépasse deux ans. C’est pourquoi les analystes divergent sur la résolution de la tension : les nouvelles capacités arrivent, mais la demande liée aux modèles de plus en plus grands pourrait absorber les gains au fur et à mesure.

Ce que cela change pour le déploiement

Comprendre le memory wall a des conséquences directes sur la façon dont les modèles sont déployés.

La taille du batch compte autant que la bande passante. Quand plusieurs requêtes sont traitées simultanément (batching), les poids du modèle sont chargés une seule fois pour servir tout le lot — ce qui dilue le coût mémoire par requête. Un modèle 70B servi en batch de 64 requêtes coûte environ 64 fois moins en bande passante par requête qu’en mode un-par-un. C’est pourquoi les services d’inférence cloud maximisent le regroupement des requêtes : c’est une optimisation mémoire avant d’être une optimisation de calcul.

La taille du modèle détermine directement le nombre de GPU nécessaires. Un modèle de 70B en FP16 occupe ~140 Go. Un H100 offre 80 Go de HBM. Il faut donc au minimum deux H100 pour héberger ce modèle, plus de la marge pour le KV cache. Pour des modèles de 400B ou plus, on passe à des configurations de 8 ou 16 GPU avec du parallélisme de tenseur — chaque GPU ne détient qu’une fraction des poids, et les activations circulent entre eux via NVLink. La bande passante inter-GPU devient alors un second goulot.

La quantisation est une décision hardware autant que qualité. Passer de FP16 à INT8 réduit de moitié l’empreinte mémoire et le volume à lire à chaque token. Pour un déploiement sur un seul GPU, c’est parfois la différence entre possible et impossible.

La mémoire, seul levier ? Des nuances importantes

La thèse “la bande passante mémoire est le facteur limitant” est la plus répandue, mais elle n’est pas sans contre-arguments.

L’optimisation logicielle peut réduire la quantité de données à transférer. Les techniques de quantisation — réduire la précision des poids de 16 bits à 8 ou 4 bits — divisent mécaniquement le volume de mémoire à lire. Les travaux de Dettmers et al. (LLM.int8(), NeurIPS 2022) et les méthodes de quantisation à 4 bits (GPTQ, AWQ) montrent qu’il est parfois plus efficace de comprimer les données que d’augmenter la bande passante. La course aux téraoctets par seconde n’est pas l’unique réponse.

Les architectures alternatives contournent le problème autrement. Cerebras, avec ses puces wafer-scale, intègre la mémoire directement sur le chip sous forme de SRAM, atteignant des bandes passantes intrinsèques de plusieurs dizaines de TB/s — mais avec une capacité plus limitée et un coût élevé. Cette approche fait disparaître le memory wall en supprimant la distance physique entre calcul et mémoire.

Le processing-in-memory (PIM) est une troisième voie explorée : intégrer des unités de calcul à l’intérieur même de la stack mémoire. Samsung a présenté une HBM-PIM à l’IEEE Hot Chips 2022 avec des gains mesurés sur certaines opérations ML. La généralisation à la production reste cependant limitée.

La gestion du KV cache est un défi propre aux longs contextes. Les travaux de Kwon et al. (PagedAttention, SOSP 2023) montrent qu’un contexte de 128 000 tokens pour un modèle 70B peut nécessiter plusieurs dizaines de gigaoctets de cache d’attention seul — un poste mémoire qui s’ajoute aux poids et qui force des compromis entre taille de lot traité et longueur du contexte accepté. L’article FlexGen (Sheng et al., ICML 2023) explore une autre piste : délester une partie de la mémoire vers le stockage NVMe ou la RAM CPU, au prix de la latence, pour permettre l’inférence sur matériel moins coûteux.

Les mémoires non-volatiles via CXL constituent une quatrième piste, encore expérimentale. Le protocole CXL (Compute Express Link) permettrait d’ajouter de la DRAM ou de la mémoire persistante directement sur le bus PCIe à faible latence, créant un tier intermédiaire entre la HBM rapide et le stockage lent. En 2025-2026, la viabilité de ce tier en production pour les charges LLM reste à démontrer.

Ce qu’il faut retenir

Les grands modèles de langage en inférence sont limités par la bande passante mémoire, pas par la puissance de calcul brute : charger les poids depuis la mémoire à chaque token généré est la contrainte dominante.
La HBM résout partiellement ce problème en empilant de la DRAM en 3D, reliée par des connexions traversant le silicium, pour atteindre des buses de 1024 bits — contre 384 bits pour les mémoires conventionnelles.
Trois entreprises (SK Hynix, Samsung, Micron) contrôlent la production mondiale, avec des procédés difficiles à scaler rapidement. La pénurie de 2023-2024 était une contrainte mémoire, pas une contrainte de calcul.
Des alternatives existent — quantisation, architectures wafer-scale, processing-in-memory — qui réduisent l’importance de la bande passante HBM sans l’éliminer.
La HBM4 (prévue 2026, interface élargie à 2048 bits) ciblerait 1,6 TB/s par stack, mais la tendance long terme reste défavorable : la puissance de calcul progresse plus vite que la capacité mémoire, et les contraintes de production (TSV, assemblage 3D) freinent la montée en volume.
Les voies alternatives — mémoires non-volatiles via CXL, délestage NVMe — restent expérimentales en production pour les charges LLM à haute performance.