Prefill, decode et cache KV : quel matériel pour un LLM (2026)
Un LLM ne sollicite pas le matériel de la même façon selon qu'il lit votre requête ou qu'il rédige sa réponse. Comprendre les deux temps, et le rôle de la bande passante, permet de choisir la bonne carte et la bonne architecture, d'un poste à une baie.
Les deux temps d'un LLM : prefill et decode
Une génération se déroule en deux phases aux besoins matériels opposés. Le prefill traite toute votre requête d'un coup, système, contexte et question. Ce sont de grosses multiplications matrice contre matrice, parfaitement parallèles, qui saturent le calcul de la carte. Cette phase est limitée par la puissance de calcul et fixe le délai avant le premier jeton. Un GPU à forte puissance, avec un format FP4 ou FP8 natif, la raccourcit.
Le decode écrit la réponse un jeton à la fois. Chaque jeton dépend des précédents, ce sont des opérations matrice contre vecteur qui font peu de calcul mais relisent une grande quantité de données. Cette phase est limitée par la bande passante mémoire et fixe la vitesse de génération, le temps entre deux jetons. L'intensité de calcul y tombe à quelques dizaines d'opérations par octet et l'occupation du GPU descend souvent sous la moitié. La règle qui en découle est simple : le prefill réclame des FLOPS, le decode réclame de la bande passante.
Le decode est limité par la bande passante mémoire
Comme la génération relit tous les poids du modèle à chaque jeton, la vitesse dépend directement de la vitesse à laquelle la carte lit sa mémoire. C'est le facteur décisif, et il varie d'un facteur trente selon la solution.
Un exemple chiffre l'écart. Sur un même modèle compact, le serveur RTX PRO 6000 génère environ 215 jetons par seconde là où un DGX Spark plafonne autour de 50, soit quatre fois moins, alors que les deux chargent le modèle sans peine. Sur un modèle de soixante-dix milliards de paramètres, un seul Spark ne tient plus que quelques jetons par seconde en génération : sa mémoire de 128 Go charge le modèle, sa bande passante de 273 Go/s ne le sert pas vite. À l'autre bout, une baie H200, B200 ou B300 vise le débit maximal pour le contexte long et le service à grande échelle, et un rack GB300 NVL72 pousse la mémoire cohérente à 20,7 To sur soixante-douze cartes.
Le DGX Station illustre un piège, signalé en orange sur le schéma. Ses 288 Go de HBM3e servent à 8 To/s, mais la machine ajoute 496 Go de LPDDR5X bien plus lente. Tant que le modèle et le cache KV tiennent dans les 288 Go de HBM, la génération est rapide. Dès qu'ils débordent sur la LPDDR5X, cette portion est lue à la vitesse de la RAM, quelques centaines de gigaoctets par seconde, et le decode ralentit fortement sur la part débordée. La grande capacité sert à charger de très gros modèles, pas à les servir tous à pleine vitesse.
Le cache KV, ce qui alourdit le decode
Pour ne pas tout recalculer à chaque jeton, le modèle mémorise les clés et les valeurs de l'attention dans un cache KV. Ce cache grandit avec la longueur du contexte, le nombre de requêtes simultanées et le nombre de couches. Sur de longues réponses et plusieurs utilisateurs, il peut dépasser la taille du modèle lui-même. Comme il est relu à chaque jeton, il aggrave le goulot du decode et occupe de la mémoire vidéo.
Trois leviers le contiennent : le regroupement des têtes d'attention, ou GQA, qui réduit le nombre de clés et de valeurs à stocker ; la quantification du cache KV, qui le compresse ; et un contexte maîtrisé. C'est aussi pourquoi le contexte très long exige d'abord de la bande passante mémoire, avant toute autre optimisation.
Ce qui doit tenir sur une carte
« Le modèle tient sur la carte » ne se limite pas aux poids. Quatre postes se partagent la mémoire vidéo, et le dernier est variable : les poids du modèle, le modèle d'embedding et le reranker d'une chaîne RAG, et le cache KV, qui grandit avec le contexte et le nombre de requêtes.
Prenons un exemple concret : Qwen3.6 35B A3B en NVFP4, contexte de 256K jetons, sur un RTX PRO 6000 de 96 Go. Le sigle A3B signifie que 3 milliards de paramètres sont actifs par jeton, mais les 35 milliards résident en mémoire, car un modèle à mélange d'experts charge tous ses experts.
| Poste | Taille (ordre de grandeur) |
|---|---|
| Poids Qwen3.6 35B A3B, NVFP4 (4 bits) | ~18 Go (les 35 Md résident) |
| Modèle d'embedding, ~4 Md en FP8 | ~4 Go |
| Reranker, ~2 Md en FP8 | ~2 Go |
| Framework et activations | ~4 Go |
| Sous-total fixe | ~28 Go |
| Cache KV pour 256K jetons, en FP16 | ~24 Go |
| Cache KV pour 256K jetons, en FP8 | ~12 Go |
Le cache KV est le poste qui varie. Sa taille par jeton vaut deux fois le nombre de couches, fois le nombre de têtes KV, fois la dimension de tête. Pour une architecture de ce type, de l'ordre de quarante-huit couches, quatre têtes KV en GQA et une dimension de 128, cela fait environ 96 Ko par jeton en FP16, donc ~24 Go pour 256K jetons ; moitié moins en FP8 (~12 Go), encore moitié moins en 4 bits (~6 Go). Une requête de 256K jetons avec un cache KV en FP8 demande donc environ 28 + 12 = 40 Go, ce qui tient largement sur une carte de 96 Go.
Combien de contexte tient, alors ? Après le sous-total fixe (~28 Go), il reste environ 68 Go pour le cache KV. En FP16, à 96 Ko le jeton, cela porte une seule requête à près de 700 000 jetons ; en FP8, au-delà du million. En pratique, ce budget se partage entre requêtes simultanées : à 256K jetons par requête avec un cache KV en FP8, la carte sert environ cinq requêtes en parallèle. Réduire la précision du cache KV, ou activer le GQA, achète donc directement du contexte ou de la concurrence. Co-loger embedding, reranker et LLM sur une seule carte est le schéma type d'une petite plateforme RAG souveraine ; au-delà, on dédie une carte à l'inférence et une autre aux modèles de recherche.
L'interconnexion : quand plusieurs cartes doivent se parler
Dès qu'un modèle est réparti sur plusieurs cartes en tensor parallelism, chaque couche déclenche un all-reduce qui synchronise les cartes, donc à chaque jeton. La vitesse de ce lien devient alors le goulot. Les ordres de grandeur sont sans appel.
| Solution | Interconnexion multi-GPU | Note (avec ou sans NVLink) |
|---|---|---|
| GB300 NVL72 (rack) | NVLink 5 et NVSwitch, 130 To/s sur le domaine | 72 GPU B300 vus comme un seul, 20,7 To de mémoire cohérente |
| B300 et B200 SXM | NVLink 5, 1,8 To/s par carte, maillage complet | Tensor parallelism quasi linéaire sur huit cartes |
| H200 SXM et H100 SXM | NVLink 4 et NVSwitch, 900 Go/s par carte | Maillage complet des huit cartes, avec NVLink |
| H200 NVL (PCIe) | Pont NVLink jusqu'à quatre cartes, 900 Go/s ; sinon PCIe | Même bande passante mémoire que le SXM, 4,8 To/s |
| H100 PCIe | Pont NVLink par paires, 600 Go/s ; sinon PCIe | Mémoire plus lente que le SXM, 2,0 contre 3,35 To/s |
| Toute carte PCIe seule, sans pont | PCIe Gen5 x16, ~128 Go/s | Sept fois plus lent que le NVLink 4, sans NVLink |
| DGX Station (GB300) | NVLink-C2C interne, 900 Go/s entre processeur et GPU | Poste mono-GPU, 784 Go de mémoire cohérente |
| Cluster DGX Spark (ConnectX-7 RoCE) | 200 Gb/s, soit ~25 Go/s | Lien réseau entre machines, sans commutateur |
Sur PCIe, l'all-reduce du tensor parallelism fait chuter l'efficacité de mise à l'échelle autour de 0,7, et peut consommer le tiers du temps de calcul sur huit cartes. Le NVLink, lui, garde cet échange négligeable.
Une carte, ou plusieurs ? PCIe, NVLink, SXM
Le bon choix suit une logique claire.
- Une seule carte. Aucun goulot d'interconnexion. C'est la meilleure option quand le modèle tient : le RTX PRO 6000 et ses 96 Go domine alors le rapport performance sur coût, devant même un H100 en débit mono-carte.
- Deux à huit cartes PCIe, sans NVLink. Le tensor parallelism souffre de l'all-reduce. Mieux vaut répartir le modèle en pipeline, qui n'échange qu'une fois par jeton, ou multiplier des répliques indépendantes pour servir plusieurs utilisateurs. PCIe suffit pour les modèles compacts et les gros lots de requêtes.
- Cartes SXM avec NVLink et NVSwitch. Le tensor parallelism passe à l'échelle presque linéairement. Mais en inférence, ce maillage reste souvent inutilisé : on paie un tiers à la moitié de plus, et le double de consommation, pour une capacité surtout utile à l'entraînement. Pour servir un modèle, PCIe est le choix économique, sauf très grands modèles denses répartis à faible latence.
Les moteurs modernes gèrent ce compromis : vLLM détecte la topologie au démarrage et bascule sur l'all-reduce optimisé pour NVLink quand les cartes sont pontées, sinon il passe par PCIe.
Empiler des DGX Spark : capacité, pas vitesse
Relier deux DGX Spark par leur port ConnectX-7 agrège 256 Go de mémoire et permet de charger un modèle de quatre cent cinq milliards de paramètres en FP4, impossible sur une seule machine. Mais le lien à 200 Gb/s reste lent face à la mémoire interne. En service à faible latence, NVIDIA annonce un temps par jeton qui suit à peu près le nombre de machines. En lot, le pipeline l'emporte largement sur le tensor parallelism sur ce lien réseau. Le message tient en une phrase : le cluster Spark débloque des modèles trop gros pour une seule machine, il n'accélère pas un modèle qui tient déjà.
Comment choisir : règles de dimensionnement
- Le modèle tient sur une carte : mono-GPU, le plus simple et le meilleur coût par jeton.
- Priorité à la latence sur un très grand modèle : SXM et NVLink, tensor parallelism dans la machine.
- Priorité au débit multi-utilisateurs : répliques mono-GPU ou pipeline, PCIe suffit.
- Contexte très long, gros cache KV : viser la bande passante mémoire, H200 ou B200, avec GQA et quantification du cache.
- Capacité maximale à budget ou silence contraints : mémoire unifiée, Mac Studio ou DGX Spark, la capacité prime, pas le débit.
- Plusieurs machines : tensor parallelism dans la machine par NVLink, pipeline entre machines par le réseau.
Le dimensionnement dépend donc du modèle, de la longueur de contexte et du nombre d'utilisateurs, pas d'une carte reine universelle. Les fourchettes de prix par gamme figurent dans notre guide des prix d'un serveur IA, et le choix du modèle dans notre comparatif des LLM open source. QDNA intègre ce matériel et l'exploite pour vous, du poste à la baie.
Questions fréquentes
Pourquoi mon LLM local génère-t-il lentement malgré un gros GPU ?
La génération, ou decode, est limitée par la bande passante mémoire, pas par la puissance de calcul. À chaque jeton, la carte relit tous les poids et le cache KV. Une carte à grande capacité mais faible bande passante, comme le DGX Spark à 273 Go/s, charge un gros modèle mais le génère lentement.
Faut-il du NVLink pour l'inférence d'un LLM ?
Rarement. Le NVLink sert quand un modèle est réparti sur plusieurs cartes en tensor parallelism, où un all-reduce synchronise les cartes à chaque jeton. En inférence courante, PCIe suffit, et le NVLink profite surtout à l'entraînement multi-GPU. Pour les très grands modèles répartis à faible latence, il redevient utile.
SXM ou PCIe pour servir un LLM ?
PCIe est plus économique et suffit pour la plupart des inférences, car le maillage NVLink des cartes SXM reste souvent inutilisé en génération. Le SXM se justifie pour l'entraînement multi-GPU, où l'all-reduce sur les huit cartes exige les 900 Go/s du NVSwitch.
Le DGX Spark est-il rapide pour un LLM ?
Le DGX Spark offre 128 Go de mémoire unifiée mais seulement 273 Go/s de bande passante. Il excelle en prototypage et sur des modèles compacts, mais génère lentement les grands modèles denses. Relier deux Spark débloque la capacité, jusqu'à Llama 405B en FP4, pas la vitesse par jeton.
Comment réduire le poids du cache KV ?
Trois leviers : le regroupement des têtes d'attention, ou GQA, qui réduit le nombre de clés et de valeurs à stocker ; la quantification du cache KV, qui compresse ces activations ; et un contexte maîtrisé, car le cache grandit avec la longueur de la conversation et le nombre de requêtes simultanées.
Dimensionnons votre matériel selon votre usage réel
Un échange pour cadrer la carte, l'architecture et le runtime selon vos modèles, votre contexte et votre nombre d'utilisateurs.
Réserver un échange