Servir l'IA générative 56× plus vite sans acheter de GPU : le papier d'IBM, NVIDIA et Supermicro
Quand le contexte grandit, il ne tient plus dans la mémoire de la GPU. Le système jette les calculs précédents et doit les refaire dès que la session revient — et c'est là que partent vos requêtes par seconde. IBM, NVIDIA et Supermicro publient en juin 2026 le Redbook Context Without Limits avec les chiffres d'une autre approche : garder ces calculs sur un stockage partagé rapide. La latence du premier token passe de 32 s à une demi-seconde, et le système répond à 22 fois plus de requêtes.
Deux ans qu'on débat du nombre de GPU à acheter pour servir de l'IA générative. IBM, NVIDIA et Supermicro renversent la question dans le Redbook Context Without Limits (juin 2026) : si la GPU rame parce qu'elle passe son temps à refaire des calculs qu'elle vient de terminer, le problème n'est pas la quantité de GPU, mais l'endroit où l'on garde ces calculs. En les déplaçant vers un stockage partagé rapide, leurs tests donnent une réponse 56 fois plus rapide à l'utilisateur, 22 fois plus de requêtes par seconde et 95 % de temps total en moins. Ici on explique ce qu'ils mesurent, comment ça marche, quand ça vaut le coup et quelles options vous avez si vous préférez le construire sur Ceph plutôt qu'IBM.
Un grand modèle (Llama 70B, gpt-oss 120B) qui répond avec un contexte de 100 000 tokens ne tient plus entièrement dans la mémoire de la GPU. Le système doit jeter les calculs anciens et, dès que la session revient, les refaire depuis zéro — comme relire tout le livre à chaque fois qu'on pose une question dessus. Garder ces calculs sur un stockage partagé rapide évite la répétition. C'est ce que mesure le Redbook IBM MD260021 (29 juin 2026), avec 8 nœuds Supermicro, IBM Storage Scale ECE, NVIDIA Dynamo et vLLM 0.14.1.
Qu'est-ce que le KV cache et pourquoi c'est le nouveau goulot d'étranglement ?
Le KV cache (Key-Value cache) est la structure où un modèle transformer stocke les clés et valeurs d'attention de chaque token du contexte. Sans lui, chaque nouveau token obligerait à recalculer l'attention sur tout ce qui précède ; avec des contextes de 100 000 tokens, ce n'est plus tenable. Autrement dit : le KV cache est ce qui permet de servir des contextes longs à des vitesses acceptables.
Le problème apparaît quand la HBM de la GPU se remplit. La HBM est ultra-rapide (microsecondes) mais chère et limitée : une NVIDIA H100 a 80 Go, une RTX PRO 6000 Blackwell monte à 96 Go. Sur un modèle de 120 milliards de paramètres avec un contexte de 130 000 tokens, une seule requête peut consommer 60-80 Go de KV cache. Avec plusieurs utilisateurs simultanés, la GPU évince les caches anciens et, si la session revient, les recalcule depuis zéro. Chaque recalcul est une passe complète du modèle : des cycles GPU qui partent sans produire un seul token nouveau.
Acheter plus de GPU ajoute de la HBM au cluster, mais chaque HBM reste isolée par GPU. Le cache généré pour l'utilisateur A n'est pas disponible quand sa requête suivante tombe sur la GPU B. On paie le matériel sans améliorer le taux de hit — jusqu'au jour où le KV cache passe sur un tier partagé.
Combien de KV cache consomme votre déploiement ?
Choisissez un modèle, une longueur de contexte et une concurrence. Le calculateur applique la formule standard du KV cache et vous indique si ça tient dans la HBM d'une GPU typique ou s'il vous faut un tier partagé type G4. Les valeurs par token viennent des configurations officielles de chaque modèle (Llama 3.1, gpt-oss 120B) — ce ne sont pas des estimations.
La hiérarchie mémoire de NVIDIA Dynamo : G1, G2, G3, G3.5 et G4
NVIDIA Dynamo définit cinq tiers de stockage pour le KV cache, chacun avec un équilibre différent entre latence, capacité et coût. Les tiers G1-G3 sont bornés par le matériel d'un seul nœud. Le G4 est le seul tier partagé à l'échelle du cluster — celui qui permet qu'un cache généré par la GPU 12 soit réutilisé quand la même session atterrit sur la GPU 47.
Quel rôle joue IBM Storage Scale ECE ici ?
IBM Storage Scale est le nom commercial actuel de ce qui s'appelait historiquement GPFS (General Parallel File System). C'est un système de fichiers parallèle distribué avec plus de 25 ans d'HPC — le même qu'on retrouve derrière des systèmes comme Summit ou Sierra. ECE (Erasure Code Edition) est la variante software-defined qui se déploie sur des serveurs commodity, utilise l'erasure coding à la place du RAID classique et monte jusqu'à l'exaoctet.
Dans l'architecture du Redbook, Storage Scale ECE joue le rôle de tier G4 pour six raisons concrètes :
- POSIX, S3, NFS, SMB et CSI depuis le même backend — s'intègre à vLLM/Dynamo comme aux pipelines de données existants.
- NVIDIA GPUDirect Storage (GDS) : transfert direct stockage → GPU sans passer par le CPU, grâce à RDMA sur Ethernet lossless ou InfiniBand.
- Erasure coding 8+2P avec 80 % de capacité utile (vs 50-67 % du RAID6 classique), sans sacrifier la durabilité.
- Tiering automatique NVMe / SSD / HDD / bande — le KV cache chaud vit sur NVMe, le froid descend sur HDD.
- Snapshots et clones instantanés — utile pour versionner des datasets et checkpoints d'entraînement.
- Scalabilité sans redesign : de 3 nœuds à 256 sans changer l'architecture.
Les trois benchmarks du Redbook (mesurés, pas estimés)
IBM, NVIDIA et Supermicro ont monté 8 nœuds Supermicro Petascale ASG-1115S-NE316R (AMD EPYC 9535, 16 NVMe Micron E3 de 7,68 To par nœud, ConnectX-7 à 400 Gb/s), interconnectés par trois switches NVIDIA Spectrum-X SN5600 en spine-leaf avec uplinks 800 Gb/s. Comme client d'inférence, un seul nœud Supermicro SYS-212GB-FNR avec 4 GPU RTX PRO 6000 Blackwell. Le logiciel : IBM Storage Scale ECE v6.0.0.1 sur RHEL 9.6, clients Ubuntu 24.04, NVIDIA Dynamo v0.9.0+, vLLM v0.14.1 et modèle openai/gpt-oss-120b quantifié en MXFP4.
Benchmark 1 — Time-to-first-token (TTFT) par longueur de contexte
Les tiers G1 (HBM) et G2 (DRAM) ont été mis à capacité zéro pour forcer le scénario : tout le KV cache — 1,4 million de tokens — est passé par le G4.
Sans KV cache persistant, le temps jusqu'au premier token croît de manière quadratique avec la longueur du prompt. Avec Storage Scale, il reste en dessous d'une seconde sur toute la plage mesurée. À 130 K tokens, c'est 32 secondes contre une demi-seconde : à 32 secondes l'utilisateur a déjà fermé l'onglet ; à une demi-seconde il reste.
Benchmark 2 — Débit sous charge concurrente
200 requêtes sur le modèle de 120 milliards de paramètres avec 28 connexions concurrentes (100 prompts uniques, 24 millions de tokens, 825 Go de KV cache) :
22× plus de débit, 95 % de temps total en moins. Et le cache est parti à vide : l'accélération s'est construite au fil des 200 requêtes. Avec un cache préchauffé, le chiffre réel serait encore meilleur.
Benchmark 3 — Sous stress « noisy neighbor »
Quatre clients concurrents générant 200 Go/s de trafic parasite en parallèle, pour simuler un cluster multi-tenant réaliste.
18× d'amélioration sous stress, seulement 18 % de dégradation par rapport au scénario propre. La preuve que l'architecture ne s'effondre pas quand le cluster est plein.
Combien de nœuds, de GPU et de bande passante me faut-il ?
Le Redbook publie lui-même trois profils de dimensionnement. Les voici côte à côte — cliquez sur celui qui ressemble le plus à votre cas.
Production multi-tenant, LLM de 70 B à 120 B paramètres, RAG et multi-turn en contexte long. C'est la configuration exacte qui apparaît dans le Redbook avec les 315 Go/s mesurés.
Dans le benchmark du Redbook, le réseau est devenu le goulot d'étranglement avant le stockage : les 8 nœuds délivrent jusqu'à 315 Go/s en lecture, mais le réseau 2×400 GbE côté client plafonne à 80 Go/s. Si vous montez quelque chose de similaire, dimensionnez le réseau client au niveau du stockage, sinon les GPU passeront leur journée à attendre des données.
Alternatives open source : Ceph, Lustre, DAOS
L'idée de fond du papier — sortir le KV cache vers un tier G4 partagé avec GPUDirect et RDMA — ne dépend pas d'IBM. Vous pouvez la monter avec d'autres pièces.
Si vous êtes déjà client IBM avec un contrat SLA, Storage Scale ECE est la voie la plus rapide à atterrir. Si vous construisez depuis zéro et privilégiez coût et contrôle, commencez par Ceph. Si vous venez de l'HPC pur et avez besoin de 300 Go/s par nœud, Lustre ou DAOS sont des options légitimes. Si le diagnostic n'est pas clair, mieux vaut le valider avant de commander le matériel.
La comparaison détaillée avec benchmarks réels des trois options open source : Ceph : nouveautés de stockage 2026.
Six questions qui vous économisent du matériel
Un tier G4 bien monté rend les chiffres du papier. Un mal dimensionné, c'est des centaines de milliers d'euros de matériel cher qui attend des données toute la journée. Ces six questions séparent le cas où ça vaut le coup de celui où ça ne le vaut pas.
Si votre IA générative rame ou coûte trop cher, la GPU n'est probablement pas la coupable
Nous travaillons avec IBM Storage Scale, Ceph, Lustre et GPUDirect dans des systèmes en production. IBM Business Partner, plus de 15 ans d'infrastructures critiques 24/7. Si vous soupçonnez que le goulot d'étranglement n'est pas dans la GPU, nous aidons à valider le diagnostic avant qu'il ne devienne un projet à sept chiffres.
Questions fréquentes
Qu'est-ce que le KV cache dans un LLM ?
Le KV cache (Key-Value cache) est la structure où un modèle transformer stocke les clés et valeurs d'attention calculées pour chaque token du contexte. Sans lui, le modèle devrait recalculer l'attention sur tous les tokens antérieurs à chaque nouveau token généré. C'est ce qui rend viable le service de contextes longs.
Pourquoi le KV cache est-il un goulot d'étranglement pour servir des LLM ?
Parce que la HBM de la GPU est finie (80–96 Go sur les modèles actuels) et très chère. Avec plusieurs sessions concurrentes en contexte long, le KV cache ne tient plus : la GPU évince les caches anciens et les recalcule quand la session revient, brûlant des cycles qui pourraient produire des tokens. La solution consiste à sortir ce cache vers un tier de stockage partagé à haute vitesse.
Qu'est-ce qu'IBM Storage Scale et quel rapport avec GPFS ?
IBM Storage Scale est le nom actuel de ce qu'on appelait GPFS (General Parallel File System). C'est un système de fichiers parallèle distribué avec plus de 25 ans d'HPC. La variante ECE (Erasure Code Edition) est software-defined, tourne sur des serveurs commodity et utilise l'erasure coding à la place du RAID.
Puis-je faire la même chose avec Ceph au lieu de Storage Scale ?
Oui. Déplacer le KV cache vers un tier G4 partagé avec GPUDirect et RDMA est indépendant du système de fichiers. Ceph, Lustre et DAOS peuvent remplir ce rôle. Storage Scale est l'option la plus rapide si vous êtes déjà client IBM ; Ceph est le premier choix quand coût, contrôle et flexibilité comptent.
Qu'est-ce que GPUDirect Storage et pourquoi c'est important ?
GPUDirect Storage (GDS) est une technologie NVIDIA qui déplace les données directement entre le système de fichiers et la mémoire GPU, sans passer par le CPU ni la RAM de l'hôte. Cela empêche le CPU de devenir le prochain goulot d'étranglement lors du déplacement de téraoctets de KV cache entre stockage et GPU.
Quel gain réaliste puis-je espérer sur mon déploiement ?
Cela dépend du profil d'usage. Les 56× et 22× du papier viennent d'un contexte extrême (130K tokens) et d'un KV cache important (825 Go). Pour du contexte court et peu de trafic concurrent, le gain est moindre. Plus le contexte est long, plus l'usage est multi-turn et plus le trafic est concurrent, plus le tier G4 rapporte.
Faut-il obligatoirement utiliser NVIDIA Dynamo ?
Pour orchestrer un KV cache multi-tier (G1-G4) avec éviction intelligente entre tiers, Dynamo est aujourd'hui l'outil le plus complet. Vous pouvez construire quelque chose de similaire avec vLLM standalone et un scheduler maison, mais vous perdez le KV-aware routing et l'offloading transparent via NIXL. En production, vLLM + Dynamo + G4 partagé est la combinaison la plus consolidée en août 2026.
Blog!
Notre mission
SIXE garantit que vos infrastructures basées sur les technologies IBM®, Red Hat®, Canonical® et SUSE® restent stables, sécurisées et optimisées aussi longtemps que vous en avez besoin.
Chez SIXE, nous nous engageons pour la durabilité. C’est pourquoi nous vous aidons à concevoir, mettre en œuvre et maintenir des solutions technologiques durables et efficaces.
