“Really excellent work by the inference team to serve this model so efficiently!
To a significant degree, we have to become an AI inference company now.” — Sam Altman, 23 avril 2026
Lis-le deux fois.
OpenAI. L’entreprise qui a entraîné GPT-4 avec des centaines de millions de dollars. Qui aligne des milliers de H100 dans ses datacenters. Qui dispose probablement des meilleurs ingénieurs ML de la planète.
Et leur CEO te dit, en 2026, qu’ils doivent devenir une inference company.
Pas une training company. Pas une research company. Une inference company.
Ce n’est pas un détail de communication. C’est l’aveu, à demi-mot, que l’inférence LLM est un problème d’ingénierie qu’on a largement sous-estimé. Et que celui qui résoudra ce problème mieux que les autres aura un avantage stratégique.
Et c’est ce qui fera la difference entre l’outil massivement utilisé et l’outil marginalisé. Entre l’entreprise qui domine le marché et celle qui se fait rattraper.
Dans le premier article de la série, on a posé les bases : entraînement vs inférence, pourquoi la VRAM est la ressource clé, comment lancer un modèle local en deux commandes. Là, on rentre dans le moteur.
Cet article, un seul sujet, et je vais la défendre du début à la fin :
L’inférence LLM n’est pas un problème de calcul. C’est un problème de mémoire.
Tout le reste en découle.
La grande contre-intuition : ton GPU passe son temps à attendre
Quand tu regardes la fiche technique d’une NVIDIA L40S, tu vois ça :
- 18 176 CUDA cores
- 568 Tensor cores de 4ᵉ génération
- 91.6 TFLOPS en FP16
- 48 Go de VRAM GDDR6 ECC
Sur le papier, c’est un monstre. Capable de faire des dizaines de milliers de milliards d’opérations par seconde. Et pourtant, pendant l’inférence d’un LLM, ce monstre passe le plus clair de son temps à… attendre.
Pas attendre des données du réseau. Pas attendre un disque. Attendre sa propre mémoire.
C’est ce qu’on appelle un workload memory-bound. Le goulot d’étranglement, ce n’est pas le calcul, c’est la bande passante mémoire.
Prefill vs decode : deux mondes
Avant d’aller plus loin, une distinction critique. L’inférence d’un LLM se fait en deux phases :
- Prefill : on traite tout le prompt d’entrée d’un coup. Toutes les couches, tous les tokens, en parallèle. C’est compute-bound. Le GPU est utilisé à fond. Si ton prompt fait 4 000 tokens, le prefill, c’est rapide et efficace.
- Decode : on génère la réponse, un token à la fois. À chaque step, il faut relire les poids du modèle pour produire le prochain token. C’est memory-bound. Le GPU attend la mémoire. La majorité du temps perçu par l’utilisateur, c’est du decode.
C’est cette deuxième phase qui domine l’expérience utilisateur sur des réponses longues. Et c’est elle qui pose problème.
Pourquoi le decode bride tout
Pendant le decode, le modèle doit lire tous ses poids depuis la VRAM pour générer un seul token. Un Llama 3.1 70B en FP16, c’est 140 Go de poids à parcourir. Token par token.
Si ton GPU dispose de 1 To/s de bande passante, le calcul est trivial :
1000 GB/s ÷ 140 GB ≈ 7 tokens/seconde
Au maximum théorique. Juste à cause de la mémoire. Avant même d’avoir parlé de calcul.
Pendant ce temps, tes Tensor cores s’ennuient. Ils ont fini leur multiplication matricielle bien avant que la prochaine fournée de poids n’arrive en cache. C’est l’arithmetic intensity, le ratio entre opérations effectuées et octets lus. Pour un transformer en decode, ce ratio est ridiculement faible.
C’est contre-intuitif, mais c’est fondamental :
Pour servir un LLM, tu n’achètes pas du compute. Tu achètes de la bande passante.
Tout le reste de cet article découle de cette phrase.
La hiérarchie de la mémoire GPU : HBM, GDDR, LPDDR
Si la bande passante est reine, alors le type de mémoire qui équipe ta carte n’est pas un détail. C’est l’élément central. Trois grandes familles existent, et leurs caractéristiques expliquent pourquoi certaines cartes sont conçues pour l’inférence et d’autres non.
HBM : la Rolls-Royce
La High Bandwidth Memory est empilée en 3D directement à côté du GPU. Latence très faible, bande passante astronomique.
| GPU | Mémoire | Bande passante |
|---|---|---|
| A100 80 Go | HBM2e | ~2 000 GB/s |
| H100 80 Go | HBM3 | ~3 350 GB/s |
| H200 | HBM3e | ~4 800 GB/s |
| MI300X | HBM3 | ~5 300 GB/s |
C’est ce qu’OpenAI utilise. C’est ce que tu trouves dans les datacenters d’inférence à grande échelle. Et c’est cher. Une H100, c’est 30 000 à 40 000 € à l’achat. Une H200, on monte au-delà. Une MI300X, idem.
Des prix au-dela de ce qu’un simple mortel peut se permettre pour son serveur perso.
À cette bande passante, un Llama 70B en FP16 peut atteindre 20-25 tokens/seconde sur un seul GPU. Multiplié par les centaines de milliers de cartes, ça donne le débit d’OpenAI.
GDDR6 / GDDR6X / GDDR7 : le compromis pro
La mémoire des cartes “consumer pro” et workstation. Bonne, mais pas dans la même ligue que la HBM.
| GPU | Mémoire | Bande passante |
|---|---|---|
| RTX 4090 | GDDR6X | ~1 008 GB/s |
| RTX 5090 | GDDR7 | ~1 792 GB/s |
| L40S | GDDR6 ECC | ~864 GB/s |
| RTX Pro 6000 Blackwell | GDDR7 | ~1 792 GB/s |
C’est ce qu’on a sur EVA. La L40S, c’est un excellent compromis pour une infrastructure universitaire : 48 Go de VRAM (de quoi loger un Qwen 2.5 72B quantizé en Q4), GDDR6 ECC, et un coût qui reste dans le raisonnable.
Mais 864 GB/s, ça veut dire que sur un Qwen 72B en Q4 (~40 Go de poids), le plafond théorique est de :
864 ÷ 40 ≈ 21 tokens/seconde
C’est cohérent avec ce qu’on observe en pratique. La L40S ne sera jamais aussi rapide qu’une H100 sur ce workload, peu importe les optimisations logicielles, parce que la limite est physique : c’est la mémoire qui n’arrive pas à suivre.
LPDDR5x : le pari de la mémoire unifiée
Le pari récent de NVIDIA avec les Grace CPUs et la DGX SPARK. La mémoire est partagée entre CPU et GPU sur un même bus, pas de PCIe entre les deux.
| GPU | Mémoire | Bande passante |
|---|---|---|
| DGX SPARK | 128 Go LPDDR5x | ~273 GB/s |
| Mac Studio M3 Ultra | 192 Go unifiée | ~819 GB/s |
Tu vois le piège ? 3 à 10× moins de bande passante que la HBM. Pour le même modèle, le DGX SPARK servira 3 à 10× moins vite qu’une H100.
Mais, et c’est là que ça devient intéressant, il loge des modèles que la H100 ne peut pas loger sur un seul GPU (128 Go vs 80 Go). C’est un trade-off différent. Tu sacrifies du débit pour de la capacité.
Comme le livre DDIA dit : “Un trade-off, c’est un compromis conscient entre plusieurs propriétés désirables, où améliorer une propriété implique souvent d’en dégrader une autre.” Totalement vrai ici.
Dès que les deux DGX SPARK arrivent dans le cluster EVA, on aura l’occasion de mesurer ça pour de vrai. Spoiler, ce ne sera pas comparable à la L40S sur les modèles qui rentrent dans 48 Go. Mais ça ouvrira la porte à des modèles qui ne rentrent nulle part ailleurs sans architecture multi-GPU.
Le tableau qui résume tout
Sors une calculette. Compare le coût par GB/s de bande passante :
| GPU | Prix (~) | Bande passante | €/GB/s |
|---|---|---|---|
| RTX 4090 | 1 800 € | 1 008 GB/s | 1.79 |
| L40S | 8 500 € | 864 GB/s | 9.84 |
| H100 | 35 000 € | 3 350 GB/s | 10.45 |
| H200 | 45 000 € | 4 800 GB/s | 9.38 |
Premier constat surprenant : la RTX 4090 est dingue en €/GB/s. C’est pour ça que beaucoup de petits acteurs (et même certaines grosses startups) montent des fermes de 4090 plutôt que d’investir dans des H100. Ce n’est pas un choix marketing, c’est un choix d’ingénieur.
Deuxième constat : la L40S, la H100 et la H200 sont quasiment au même prix par GB/s. Ce qui les distingue, c’est le plafond absolu (combien de tokens/seconde par GPU) et la VRAM totale (quels modèles tu peux loger).
Quand tu choisis ton infra, tu n’optimises pas un seul axe. Tu optimises trois en même temps : bande passante × VRAM × prix. Et selon ton workload (modèle 7B vs 70B, 1 utilisateur vs 100, contexte court vs long), le bon choix change.
Pourquoi Sam Altman a raison
Reviens au tweet du début.
OpenAI, en 2026, n’est plus dans la course à l’entraînement pure. Les modèles open source rattrapent. Llama, Qwen, DeepSeek, Mistral, l’écart s’est resserré, brutalement. La différenciation se déplace ailleurs :
Dans la capacité à servir ces modèles à des centaines de millions d’utilisateurs, à un coût qui ne ruine pas l’entreprise.
Et ce déplacement, c’est exactement ce qu’on vit à plus petite échelle dans une infra universitaire :
- Choisir le bon modèle pour le bon hardware
- Comprendre quel GPU sature à quel débit
- Décider entre latence et capacité selon les usages
- Mesurer, mesurer, mesurer
L’inférence n’est pas un problème résolu. Pas pour OpenAI, pas pour Mistral, pas pour AWS, et pas pour ton serveur perso. C’est un problème d’ingénierie système où la mémoire est reine, où le calcul est secondaire, et où les détails déterminent si tu fais 5 tokens/s ou 500.
Ce qu’il faut retenir
Avant que tu t’en ailles, voici les trois points clés à garder en tête :
- L’inférence LLM est memory-bound, pas compute-bound. Pendant le decode, ton GPU attend ses poids. Le bottleneck, c’est la bande passante mémoire, pas les TFLOPS.
- Le type de mémoire détermine le plafond physique. HBM > GDDR > LPDDR en bande passante. Une L40S ne pourra jamais égaler une H100, peu importe le logiciel — la limite est dans le silicium.
- Le bon GPU dépend de ton workload. Bande passante × VRAM × prix : l’équation à trois inconnues que personne ne peut résoudre à ta place.
Ok, next ?
Maintenant qu’on sait que la mémoire est reine, deux questions naturelles se posent :
- Comment cette mémoire est-elle utilisée pendant qu’on sert plusieurs utilisateurs en parallèle ?
- Comment on évite que le service s’effondre dès qu’on dépasse 5 utilisateurs concurrents ?
Ce sera l’objet du prochain article.
Et après, on rentre dans le concret pur, benchmarks réels sur L40S, mesure de la saturation de la bande passante, évolution du débit en fonction du batch size. Pas de la théorie. Pas du benchmark synthétique. Du terrain, sur EVA.
À bientôt.