Matériel
Choisir son matériel pour l'inférence LLM locale
VRAM, bande passante, mémoire unifiée : pourquoi le decode est limité par la mémoire et comment arbitrer entre GPU discret et iGPU à mémoire partagée.
Comprendre le matériel d’inférence LLM, c’est d’abord comprendre une vérité contre-intuitive : la génération de tokens n’est presque jamais limitée par la puissance de calcul, mais par la bande passante mémoire. Ce détail change tout dans le choix d’une machine, et il explique nos arbitrages d’infrastructure chez SoberCloud.
Les deux ressources clés : calcul et mémoire
L’inférence sollicite deux ressources matérielles dont l’importance varie selon la phase :
- Puissance de calcul : capacité à effectuer des multiplications matricielles, exprimée en FLOPS (flottants) ou TOPS (entiers).
- Bande passante mémoire : vitesse de transfert des données entre la mémoire et les unités de calcul, en Go/s.
Contrairement aux jeux ou au rendu 3D, l’inférence LLM en génération de tokens est limitée par la mémoire, pas par le calcul. Un GPU très puissant avec une bande passante moyenne sera bridé par cette dernière.
La bande passante mémoire : le vrai goulot
À chaque token généré (phase de decode), le modèle doit relire l’intégralité des poids actifs depuis la mémoire. La vitesse de génération suit donc une formule approximative :
Tokens/s ≈ Bande passante (Go/s) / Taille des poids actifs (Go)Exemple : un modèle dense 7B en Q4 pèse ~4 Go. Sur une carte à 1000 Go/s, la limite théorique est 1000/4 = 250 tok/s ; sur une mémoire unifiée à 256 Go/s, c’est ~64 tok/s. En pratique on atteint 60 à 80 % de ces valeurs.
Types de mémoire et bande passante
| Type | Bande passante | Capacité typique | Usage |
|---|---|---|---|
| HBM3e | 4000-5300 Go/s | 80-192 Go | GPU datacenter |
| HBM3 | 2000-3500 Go/s | 40-80 Go | GPU datacenter |
| GDDR6X | 700-1000 Go/s | 12-24 Go | GPU consumer (RTX 30xx/40xx) |
| GDDR6 | 400-960 Go/s | 8-24 Go | GPU consumer |
| LPDDR5X | 250-550 Go/s | 16-128 Go | Apple Silicon, APU AMD |
| DDR5 | 50-100 Go/s | 32-256 Go | RAM desktop/serveur |
| DDR4 | 25-50 Go/s | 16-128 Go | RAM desktop/serveur |
La puissance de calcul : FLOPS, TOPS et unités matricielles
La puissance de calcul s’exprime selon la précision utilisée : FP32, FP16/BF16, INT8, INT4. Attention aux chiffres marketing : les fabricants communiquent souvent les TOPS en INT8 ou INT4, 2 à 4 fois supérieurs aux TFLOPS FP16. Comparez toujours les mêmes précisions, et comptez 50 à 70 % d’efficacité réelle par rapport au théorique.
Les architectures modernes embarquent des unités spécialisées pour les multiplications matricielles : Tensor Cores chez NVIDIA (Ampere, Ada, Hopper), Matrix Cores et AI Accelerators chez AMD (CDNA, RDNA), Neural Engine chez Apple, NPU chez Intel et dans les Ryzen AI.
Prefill vs decode : deux phases, deux goulots
L’inférence se déroule en deux phases aux contraintes opposées.
| Prefill (traitement du prompt) | Decode (génération) | |
|---|---|---|
| Goulot | Puissance de calcul (FLOPS) | Bande passante mémoire |
| Parallélisme | Élevé (batch de tokens) | Faible (1 token à la fois) |
| Métrique | Tokens/s en entrée | Tokens/s en sortie |
| Impact | Time To First Token (TTFT) | Vitesse perçue |
| Favorise | GPU discrets (Tensor Cores) | Haute bande passante |
Un long prompt (RAG, code) sur une machine à faibles FLOPS aura un TTFT élevé mais une génération fluide ensuite. Sur GPU discret, le TTFT sera court grâce au prefill rapide. C’est pourquoi les TFLOPS ne prédisent pas la vitesse de génération : une carte 20 fois plus puissante en FP16 ne sera que ~2 fois plus rapide en decode si sa bande passante n’est que double.
Dense vs MoE : l’impact crucial du matériel
La limitation par la bande passante explique pourquoi les modèles MoE (Mixture of Experts) brillent sur les architectures à mémoire unifiée.
- Dense (ex. Qwen3.6-27B) : tous les paramètres sont lus à chaque token. Bande passante requise élevée, idéal sur GPU discret haute performance.
- MoE (ex. Qwen3.6-35B-A3B, 35B au total mais seulement 3B actifs par token) : seule une fraction des experts transite par la mémoire à chaque token. Empreinte disque plus grande, mais decode bien plus léger.
Sur une mémoire unifiée modeste en bande passante, un MoE permet de charger un modèle plus gros tout en gardant un decode rapide, souvent avec une meilleure qualité grâce au nombre total de paramètres supérieur. C’est exactement ce que nous observons sur nos bancs de test — détaillé dans /decouvertes/dense-vs-moe-strix-halo/.
Nos deux bancs de test comme cas d’école
Nous comparons deux plateformes aux philosophies opposées, dans une démarche de sobriété : des machines basse consommation, et des modèles dimensionnés pour le matériel plutôt que l’inverse.
Strix Halo — AMD Ryzen AI MAX+ 395
- iGPU Radeon 8060S (gfx1151), 128 Gio de mémoire unifiée (UMA, partagée CPU/GPU).
- Bande passante modeste : inférence bandwidth-bound, pas compute-bound.
- Modèle testé : Qwen3.6-35B-A3B MoE en GGUF Q5_K_XL (~26 Go) via llama.cpp Vulkan, autour de 73 t/s.
- Sur UMA,
--no-mmapest obligatoire (le mmap fait crasher l’allocation).
RTX 3090 — NVIDIA
- 24 Go de GDDR6X (Ampere), 23,56 Gio réellement utilisables.
- Modèle testé : Qwen3.6-27B dense en int4 AutoRound via vLLM.
- KV cache en fp8_e5m2, ce qui pousse le contexte jusqu’à 81k tokens.
Deux philosophies : la plateforme UMA mise sur la capacité mémoire pour faire tourner un gros MoE à bas coût énergétique ; la RTX 3090 mise sur la bande passante GDDR6X et le batching pour un dense quantifié. Le bon matériel dépend du modèle visé, et inversement.
Recommandations rapides
- Budget contraint, modèles jusqu’à 20B : un GPU consumer 24 Go offre le meilleur rapport perf/prix.
- Gros MoE, contextes longs, faible consommation : une plateforme à mémoire unifiée généreuse (Apple Silicon, APU Strix Halo) charge des modèles inaccessibles à VRAM équivalente.
- Production multi-utilisateurs, prefill lourd : un GPU discret pour exploiter le batching et les Tensor Cores.