Aller au contenu principal

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.

Par Antoine Michéa, Fondateur & ingénieur infrastructure · · mis à jour le

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.8-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 bancs de mesure 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-mmap est 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.

RTX 5090 — NVIDIA Blackwell

  • 32 Go de GDDR7, et surtout des tensor cores FP4 : c’est la génération qui exécute NVFP4 nativement, sans déquantifier vers 16 bits.
  • Modèle servi : Qwen3.8-27B en NVFP4 via SGLang — 17,1 Gio de poids seulement (contre ~56 Gio en BF16).
  • Mesuré : ~120 tok/s pour un utilisateur, 119-138 tok/s chacun pour cinq utilisateurs simultanés, 185 000 tokens de contexte, décodage spéculatif compris.
  • L’architecture hybride du modèle y est pour beaucoup : le cache KV tombe à 32 Kio/token, ce qui libère la mémoire nécessaire au contexte long.

Trois philosophies, donc : la plateforme UMA mise sur la capacité mémoire pour faire tourner un gros MoE à bas coût énergétique ; la RTX 3090 sur la bande passante et le batching ; la RTX 5090 sur le calcul basse précision natif, qui rend un dense de 27B plus rapide qu’un MoE sur APU tout en tenant un contexte de 185k. Le bon matériel dépend du modèle visé, et inversement.

Note de lecture. Ces machines sont nos bancs de mesure : elles servent à produire les chiffres publiés ici, sur du matériel que chacun peut se procurer et donc reproduire. Elles ne décrivent pas le dimensionnement des offres SoberCloud, qui est adapté à chaque projet.

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.
  • Modèle récent, contexte long, budget carte unique : une carte Blackwell et un checkpoint NVFP4. Le gain est double — mémoire et débit — parce que le silicium calcule directement en 4 bits.

Pour aller plus loin

← Toutes les découvertes