H100 vs B200 : analyse microarchitecturale et performance réelle en inférence LLM

Pourquoi cette comparaison compte

Avec Blackwell, NVIDIA introduit une génération pensée pour l’inférence à très grande échelle. Le sujet n’est pas seulement le débit brut : comparer deux fiches techniques sur la ligne « FLOPS FLOPS Floating-Point Operations Per Second. Métrique brute de débit de calcul flottant, en téra ou péta. Pour l'inférence LLM, c'est rarement le facteur limitant : la bande passante mémoire le devance presque toujours. Approfondir dans le glossaire » manque l’essentiel, parce que ce n’est presque jamais ce qui limite un LLM en production. Il faut regarder la mémoire, les chemins de données, les formats numériques et la capacité à maintenir les Tensor Cores Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. Approfondir dans le glossaire alimentés sous charge réelle, plutôt qu’à mesurer leur pic théorique.

Cette analyse confronte le H100 SXM5 (Hopper) au die GB100 de Blackwell, mesuré ici en profil B100 SXM (700 W), dans des scénarios représentatifs : batch continu, longues fenêtres de contexte, KV cache sous pression et kernels denses exécutés via Triton, llama.cpp et vLLM. Une précision de lecture qui simplifie tout : le B200, la déclinaison réellement déployée en volume, embarque le même silicium, la même mémoire (192 Go HBM3e, ~8 To/s) et le même NVLink 5 ; il ne s’en distingue que par son enveloppe (1 000 W contre 700) et ses fréquences soutenues. Toute l’analyse mémoire de cet article, le cœur du sujet en inférence, vaut donc à l’identique pour le B200 ; seuls les chiffres de calcul brut y sont un cran plus hauts. L’objectif n’est pas de rejouer les chiffres marketing, mais de comprendre où le gain apparaît et pourquoi : la nuance qui décide si un upgrade Blackwell vaut son coût pour votre charge précise.

Ce qui change dans l’architecture

Hopper et Blackwell partagent la même logique d’ensemble : des Streaming Multiprocessors, des Tensor Cores, une hiérarchie de cache, de la HBM HBM High Bandwidth Memory. Mémoire empilée en couches, soudée à proximité immédiate du GPU, avec une bande passante de plusieurs To/s (contre ~50 Go/s pour de la DDR5). Indispensable au-delà d'une certaine taille de modèle. Approfondir dans le glossaire et du NVLink NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s par GPU ; NVLink 6 (Rubin) double à 3,6 To/s. Permet à plusieurs cartes de partager leur mémoire et de se comporter quasi comme un seul accélérateur. Approfondir dans le glossaire . Blackwell ne réinvente rien : il pousse chaque maillon plus loin, et la différence apparaît dans la combinaison de ces poussées, pas dans une seule.

Le saut le plus visible est mémoire. Le H100 SXM5 embarque 80 Go de HBM3 avec ≈3,35 To/s de bande passante ; le B100 monte à 192 Go de HBM3e à ≈8 To/s. C’est un facteur 2,4× sur la capacité et 2,4× sur la bande passante, deux dimensions qui agissent ensemble sur la phase decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse, le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. Approfondir dans le glossaire d’un LLM. Les Tensor Cores de 5ᵉ génération ajoutent les formats compacts FP6 et FP4 FP4 Format à virgule flottante 4 bits, frontière 2026 de l'inférence à haut débit. Quatre fois moins de mémoire que le FP16, mais une portée dynamique très étroite : ne tient qu'avec un scaling fin via formats à blocs (MXFP4, NVFP4). Approfondir dans le glossaire (voir FP8, FP6, FP4), qui divisent encore par deux ou quatre la pression mémoire des poids et du KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire . Le NVLink 5 double la bande passante inter-GPU pour passer de 900 Go/s à 1,8 To/s par GPU (18 liens × 100 Go/s), ce qui change la donne pour les modèles qui ne tiennent pas sur une seule carte.

Le vrai goulot : mémoire et bande passante

Pour comprendre pourquoi Blackwell ne se mesure pas en FLOPS, il faut regarder ce qui se passe à chaque token généré. En inférence autorégressive, la phase decode enchaîne des forward passes minuscules : un seul nouveau token traverse la pile à chaque itération. Pour ce token unique, le GPU doit recharger l’intégralité des poids du modèle depuis la HBM, plus l’ensemble du KV cache accumulé depuis le début de la requête. Ce sont des centaines de gigaoctets à transférer pour quelques milliards d’opérations utiles : le ratio calcul/mémoire est si défavorable que les Tensor Cores passent l’essentiel de leur temps à attendre des données, pas à en consommer.

Un exemple chiffré rend la chose tangible. Un Llama 3 70B en FP8 FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. Approfondir dans le glossaire pèse ≈70 Go de poids. Sur H100 SXM5 (3,35 To/s), il faut ≈21 ms juste pour lire les poids une fois, soit le temps physique minimum d’une étape de génération sur ce GPU, peu importe la vitesse des Tensor Cores. Sur B100 SXM (8 To/s), ce plancher tombe à ≈9 ms. Avant même de regarder le calcul ou les optimisations de kernels, la bande passante mémoire impose un débit théorique ≈2,4× plus élevé. Ajoutez le KV cache d’une session longue (typiquement 20 à 60 Go en plus en contexte 32k), et l’écart s’amplifie : c’est la somme poids + cache qui doit traverser la HBM à chaque token, et c’est elle qui dicte le plafond.

C’est exactement là que Blackwell concentre ses gains. Plus de capacité (192 Go vs 80) pour garder des batches plus larges et des contextes plus longs intégralement en mémoire, au lieu de paginer vers la mémoire CPU, qui effondrerait la latence. Plus de bande passante (8 To/s vs 3,35) pour les servir à un débit qui rapproche les Tensor Cores de leur saturation utile. Et des formats compacts (FP4 vs FP8 minimum) qui font tenir 2× plus de poids et de KV cache par giga-octet, ce qui rend la double augmentation capacité+bande passante encore plus efficace par token. On détaille ce mécanisme dans HBM et NVLink : pourquoi les LLM sont limités par la mémoire.

Performances mesurées en inférence

Les mesures ci-dessous comparent le débit en génération (tokens/s) sur quatre charges, à longueur de contexte et batch fixés, runtime vLLM 0.20 pour les modèles serveurs et llama.cpp pour les variantes quantifiées. Le contexte reste court (4k) pour isoler l’effet du matériel : un contexte long amplifierait l’écart, mais brouillerait la lecture de ce qui vient du GPU et de ce qui vient du KV cache.

Extrait de kernel optimisé pour FP8

Une partie du gain Blackwell n’apparaît que si le kernel exploite réellement les nouveaux formats. Voici un squelette de kernel matmul matmul Multiplication de matrices, l'opération dominante des couches d'un réseau de neurones. Quand on dit qu'un GPU « calcule », il fait à 90 % des matmul. FP8 écrit en Triton : la structure de tuilage compte autant que les unités matérielles, parce que c’est elle qui décide combien de bytes chaque thread doit recharger depuis la HBM.

@triton.jit
def matmul_fp8_kernel(a, b, c, m, n, k, BLOCK_M: tl.constexpr, BLOCK_N: tl.constexpr):
    # Un programme par tuile de sortie (pid_m, pid_n)
    pid_m = tl.program_id(0)
    pid_n = tl.program_id(1)
    offs_m = pid_m * BLOCK_M + tl.arange(0, BLOCK_M)
    offs_n = pid_n * BLOCK_N + tl.arange(0, BLOCK_N)
    offs_k = tl.arange(0, BLOCK_K)
    acc = tl.zeros((BLOCK_M, BLOCK_N), tl.float32)
    for k0 in range(0, k, BLOCK_K):
        x = tl.load(a + offs_m[:, None] * k + offs_k[None, :], mask=offs_m[:, None] < m)
        y = tl.load(b + offs_k[:, None] * n + offs_n[None, :], mask=offs_n[None, :] < n)
        acc += tl.dot(x, y, out_dtype=tl.float32)
    tl.store(c + offs_m[:, None] * n + offs_n[None, :], acc)

L’accumulateur reste en FP32 : on charge en FP8, on calcule en FP8, mais on accumule large pour éviter qu’une longue chaîne d’additions ne fasse dériver le résultat. Sur Blackwell, c’est cette discipline (accumulation FP32, tuilage adapté à la nouvelle L2 de 126 Mo) qui transforme la bande passante gagnée en débit réel. Un kernel écrit pour Hopper et redéployé sans retuner laisse typiquement 15 à 25 % du gain sur la table. Cette discipline du tuilage a désormais son modèle de programmation dédié : CUDA Tile et cuTile.

Comparatif technique consolidé

Le rapport le plus parlant n’est pas le débit brut mais le débit par watt et le débit par giga-octet de KV cache : c’est là que Blackwell se détache, parce que le B100 SXM délivre ses gains mémoire à enveloppe thermique constante (700 W, comme le H100 SXM5). Le surcroît de débit est directement un gain d’efficacité, sans budget thermique supplémentaire. À l’échelle d’un rack qui livre la même puissance électrique, cela se traduit par un gain de débit total et un gain de densité de tokens par kilowatt.

Et le B200 ? Même die, même mémoire, même NVLink : ce qui précède le décrit déjà. Sa différence est un choix d’intégration : NVIDIA relève l’enveloppe à 1 000 W pour tenir des fréquences soutenues plus hautes, ce qui paie sur les charges compute-bound (le prefill, les gros batches), presque pas sur le decode limité par la mémoire. En contrepartie, il ne se glisse pas dans un châssis prévu pour 700 W : l’upgrade B200 est un projet d’infrastructure (alimentation, refroidissement, densité), pas un échange de cartes. C’est cette logique de densité que prolonge le face-à-face MI355X vs B200.

Limites et zones d’incertitude

Trois réserves importantes encadrent ces chiffres.

D’abord, les gains B100 dépendent fortement de la maturité du runtime. Un kernel qui n’exploite pas FP6/FP4 calcule en FP8, donc traverse la même quantité de bytes que sur H100 : le gain mémoire disparaît, et il ne reste que le surplus de bande passante brute (≈2,4×) sans le multiplicateur de format compact (×2). On retombe alors sur des gains de +15 à +20 %, pas +30 à +40 %.

Ensuite, les charges prefill prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée, le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. Approfondir dans le glossaire -dominées (longs prompts ingérés, peu de tokens générés) profitent moins du saut mémoire que les charges decode-dominées. La passe prefill traite tous les tokens du prompt en parallèle, ce qui maximise la réutilisation des poids chargés en cache : le ratio calcul/mémoire devient bien plus favorable, et Hopper sature presque aussi bien ses Tensor Cores que Blackwell. Le delta réel mesuré en chat conversationnel (decode-dominé) n’est pas le même qu’en RAG à long contexte (prefill-dominé).

Enfin, à l’échelle du datacenter, le coût total de l’inférence intègre l’alimentation, le refroidissement et la densité rack, pas seulement le prix du GPU. Un B100 à enveloppe identique se loge dans les mêmes châssis qu’un H100, ce qui simplifie l’upgrade ; un déploiement plus dense (B200 ou GB200) ouvre d’autres dimensions de coût.

Autrement dit : le B100 n’efface pas le H100. Il déplace le point d’équilibre vers les charges où la mémoire et le KV cache deviennent dominants, et où l’amortissement du nouveau matériel sur la durée du contrat datacenter justifie son surcoût.

Conclusion

La question qui reste à trancher pour 2026 n’est pas « H100 ou B200 », mais « à partir de quelle taille de modèle et de quelle longueur de contexte l’upgrade s’auto-finance ». Pour un service qui sert un 7B en contexte court, le H100 garde une place : sa bande passante n’est pas le facteur limitant, et le delta de coût matériel n’est pas amorti par le gain de débit. Pour un service qui sert un 70B ou plus en contexte long, le calcul s’inverse : chaque mois sans Blackwell est un mois où la même facture électrique délivre 30 % moins de tokens utiles.

Blackwell marque une évolution incrémentale majeure : le vrai palier ne vient pas uniquement du silicium, mais de l’écosystème logiciel capable d’exploiter mémoire, KV cache et formats compacts.

Killian Pluenet, Architecte systèmes & IA

Pour aller plus loin sur le choix du runtime qui exploite réellement ce matériel, voir vLLM vs llama.cpp vs TensorRT-LLM.

Sources et méthode

Mesures de performance. Mesures internes LeCompute sur banc reproductible (vLLM 0.20, llama.cpp build de mai 2026, contexte 4k, batch 32). Ce sont des débits soutenus en génération, pas les chiffres « pic » communiqués par les constructeurs. Elles relèvent de l’estimation crédible, pas du fait vérifié : elles dépendent du runtime, du driver et des kernels, et n’engagent que notre banc.

Spécifications matérielles (faits vérifiés) :

• NVIDIA H100 Tensor Core GPU, datasheet : resources.nvidia.com
• NVIDIA Hopper Architecture In-Depth (SM, cache L2 du H100) : developer.nvidia.com
• NVIDIA Blackwell Architecture (NVLink 5, formats FP4/FP6) : nvidia.com
• NVIDIA Blackwell Tuning Guide (capacité L2 = 126 Mo) : docs.nvidia.com

Note sur le B100. NVIDIA n’a pas publié de fiche technique B100 aussi détaillée que celle du H100. Les caractéristiques de microarchitecture (148 SM, 126 Mo de L2, Tensor Cores 5ᵉ génération) sont celles du die GB100, commun aux B100 et B200 et mesuré au niveau B200 ; le B100 s’en distingue surtout par ses fréquences et son enveloppe (700 W), pas par le nombre d’unités.