Pour faire tourner un modèle de langage open-weight en local, l'appareil qui effectue les calculs doit disposer d'assez de mémoire rapide pour trois choses : les poids quantifiés, le cache KV correspondant à votre longueur de contexte et au nombre de requêtes simultanées, et une marge pour l'environnement d'exécution. La capacité détermine quels modèles tiennent, la bande passante mémoire détermine la vitesse de génération du texte, et la puissance de calcul détermine la vitesse de lecture des longs prompts. En règle générale, un GPU de 16 Go fait bien tourner les modèles de classe 8B, 24 à 32 Go suffisent pour les modèles de classe 32B en 4 bits, et les modèles de classe 70B demandent environ 48 Go ou plus : une carte de station de travail, deux GPU ou une machine à mémoire unifiée.
La formule de la mémoire
Tout dimensionnement part d'une seule somme :
memory ≈ weights + KV cache + runtime overhead
weights = parameters × bits per weight / 8
KV cache = 2 × layers × kv_heads × head_dim × bytes per element × tokens in flight
Un modèle de 70,6 milliards de paramètres a besoin d'environ 141 Go pour ses poids en 16 bits, et d'environ 42 Go à 4,8 bits par poids.
Le cache KV stocke les clés et les valeurs d'attention de chaque token suivi par le modèle ; il grandit donc avec chaque token du prompt et de la réponse. Le facteur 2 couvre les clés et les valeurs, et les autres termes viennent du config.json du modèle : num_hidden_layers, num_key_value_heads et head_dim. La plupart des modèles actuels utilisent le grouped-query attention, avec bien moins de têtes KV que de têtes de requête.
Le surcoût d'exécution couvre le contexte CUDA, ROCm ou Metal et les tampons de calcul. Prévoyez 1 à 2 Gio par appareil pour llama.cpp, dont l'ajustement automatique garde par défaut une marge de 1024 Mio par appareil, et davantage pour les serveurs qui réservent d'avance de la mémoire pour de gros lots. En mémoire unifiée, laissez aussi de la place au système d'exploitation.
Le cache KV grandit avec le contexte et la concurrence
Le coût par token découle directement des fichiers de configuration :
Llama 3.1 8B: 2 × 32 layers × 8 kv_heads × 128 head_dim × 2 bytes = 128 KiB per token
Qwen3-32B: 2 × 64 layers × 8 kv_heads × 128 head_dim × 2 bytes = 256 KiB per token
Llama 3.3 70B: 2 × 80 layers × 8 kv_heads × 128 head_dim × 2 bytes = 320 KiB per token
À 32 768 tokens, cela donne 4, 8 et 10 Gio avec un cache en 16 bits. À 131 072 tokens, le cache du modèle 70B atteint 40 Gio, autant que ses poids en 4 bits.
La concurrence multiplie le cache : quatre utilisateurs avec des conversations de 16K tokens occupent autant qu'une seule conversation de 64K. vLLM constitue un pool KV avec la mémoire restante après le chargement des poids, et llama-server partage un budget de contexte unique (-c) entre ses slots (--parallel). Le guide des serveurs d'inférence LLM en local explique comment chaque serveur répartit ce pool.
Deux leviers réduisent le cache. Un cache en 8 bits, -ctk q8_0 -ctv q8_0 dans llama.cpp ou --kv-cache-dtype fp8 dans vLLM, le divise à peu près par deux, et limiter le contexte à ce que l'application utilise réellement ne coûte rien. Les couches à fenêtre glissante, l'attention hybride et le multi-head latent attention stockent moins par token : vérifiez la taille du tampon KV que llama.cpp affiche au chargement.
Exemples chiffrés pour des modèles 8B, 32B et 70B
La documentation de quantification de llama.cpp indique les bits par poids mesurés sur Llama 3.1 8B : Q8_0 8,50, Q6_K 6,56, Q5_K_M 5,70, Q4_K_M 4,89, IQ4_XS 4,46 et Q3_K_M 4,00. Les modèles plus grands sont légèrement en dessous : les fichiers Q4_K_M publiés pour Qwen3-32B et Llama 3.3 70B reviennent à environ 4,8. Ce script applique la formule avec un contexte de 32K et 1,5 Gio de surcoût :
GiB = 2**30
def weights_gib(params, bits_per_weight):
return params * bits_per_weight / 8 / GiB
def kv_gib(layers, kv_heads, head_dim, tokens, bytes_per_elem=2):
return 2 * layers * kv_heads * head_dim * bytes_per_elem * tokens / GiB
models = {
"Llama 3.1 8B": (8.03e9, 32),
"Qwen3-32B": (32.76e9, 64),
"Llama 3.3 70B": (70.55e9, 80),
}
for name, (params, layers) in models.items():
kv = kv_gib(layers, 8, 128, 32768)
for quant, bpw in (("BF16", 16.0), ("Q8_0", 8.5), ("Q4_K_M", 4.85)):
w = weights_gib(params, bpw)
print(f"{name:14} {quant:7} weights {w:6.1f} GiB KV@32K {kv:5.1f} GiB total {w + kv + 1.5:6.1f} GiB")
Llama 3.1 8B BF16 weights 15.0 GiB KV@32K 4.0 GiB total 20.5 GiB
Llama 3.1 8B Q8_0 weights 7.9 GiB KV@32K 4.0 GiB total 13.4 GiB
Llama 3.1 8B Q4_K_M weights 4.5 GiB KV@32K 4.0 GiB total 10.0 GiB
Qwen3-32B BF16 weights 61.0 GiB KV@32K 8.0 GiB total 70.5 GiB
Qwen3-32B Q8_0 weights 32.4 GiB KV@32K 8.0 GiB total 41.9 GiB
Qwen3-32B Q4_K_M weights 18.5 GiB KV@32K 8.0 GiB total 28.0 GiB
Llama 3.3 70B BF16 weights 131.4 GiB KV@32K 10.0 GiB total 142.9 GiB
Llama 3.3 70B Q8_0 weights 69.8 GiB KV@32K 10.0 GiB total 81.3 GiB
Llama 3.3 70B Q4_K_M weights 39.8 GiB KV@32K 10.0 GiB total 51.3 GiB
Le modèle 8B tient sur une carte de 12 Go en Q4_K_M et sur une carte de 16 Go en Q8_0 ; sur 16 Go, aucune raison de capacité ne justifie de descendre sous Q6_K. Le modèle 32B en Q4_K_M demande une carte de 32 Go pour un cache complet de 32K ; sur 24 Go, il tient avec un contexte de 16K et un cache en 8 bits, pour environ 22 Gio. Le modèle 70B en Q4_K_M demande environ 51 Gio : deux GPU de 32 Go, une carte de station de travail de 72 ou 96 Go, ou au moins 64 Go de mémoire unifiée. Une carte de 48 Go le fait tourner avec environ 8K de contexte, et Q8_0 exige une carte de 96 Go ou 128 Go de mémoire unifiée.
Formats de quantification et leur coût
La quantification stocke les poids avec moins de bits, plus des facteurs d'échelle par bloc. Elle économise de la mémoire et accélère la génération, mais elle ajoute de l'erreur.
K-quants et I-quants en GGUF
GGUF est le format de fichier de llama.cpp, également utilisé par Ollama et LM Studio. Les K-quants comme Q4_K_M et Q6_K quantifient les poids par blocs et gardent les tenseurs sensibles dans un type plus précis. Les I-quants comme IQ4_XS compressent davantage. Les deux gagnent à utiliser une matrice d'importance (imatrix) calculée sur un texte de calibration, et la documentation de llama.cpp mesure leur perte par la perplexité et la divergence de Kullback-Leibler. GGUF fonctionne sur CUDA, ROCm, Vulkan, Metal et CPU, ce qui en fait le choix le plus portable.
8 bits et FP8
Q8_0 est le type GGUF en 8 bits. Sur les serveurs GPU, le format 8 bits courant est le FP8. Selon la documentation FP8 de vLLM, le calcul FP8 exige une compute capability NVIDIA de 8.9 ou plus (Ada Lovelace, Hopper, Blackwell), les GPU plus anciens se rabattent sur des noyaux W8A16 limités aux poids, et le FP8 divise par deux la mémoire du modèle avec jusqu'à 1,6 fois plus de débit et un impact minimal sur la précision.
AWQ, GPTQ et virgule flottante 4 bits
AWQ et GPTQ sont des méthodes 4 bits limitées aux poids, destinées aux serveurs GPU comme vLLM et SGLang. Elles calibrent les échelles de groupes de poids, gardent les activations en 16 bits, et de nombreux éditeurs publient directement ces versions, par exemple Qwen/Qwen3-32B-AWQ. Les GPU Blackwell ajoutent le calcul FP4 natif, et les modèles gpt-oss d'OpenAI stockent leurs poids d'experts en MXFP4.
Quelle qualité vous perdez
Les formats 8 bits sont généralement difficiles à distinguer du BF16. Q6_K et Q5_K_M ajoutent une hausse de perplexité faible mais mesurable et restent un choix sûr si la mémoire le permet. Le 4 bits est le compromis habituel : la perte est mesurable, et vous la remarquerez surtout là où les petites erreurs comptent, comme le code, les mathématiques et le rappel exact d'informations dans un long contexte. Sous 4 bits, l'erreur croît vite, et les petits modèles souffrent davantage que les grands. Un modèle plus grand en 4 bits bat souvent un modèle plus petit en 8 bits dans la même mémoire, mais vérifiez-le sur vos propres tâches, comme le décrit le guide d'évaluation des agents IA.
La bande passante fixe la vitesse de génération, le calcul celle du prompt
Générer un token avec un modèle dense lit chaque poids une fois, plus le cache KV du contexte courant. Avec un lot de taille 1, le déplacement des données domine, donc le plafond est simple :
decode tokens/s ≤ memory bandwidth / bytes read per token
bytes read per token ≈ weight bytes (dense) or active-expert bytes (MoE) + KV cache bytes at current depth
Le fichier Llama 3.3 70B Q4_K_M pèse 42,5 Go : le plafond est d'environ 42 tokens par seconde à 1792 Go/s, 14 à 614 Go/s et 6 à 256 Go/s. Le fichier 8B Q4_K_M (4,9 Go) atteint environ 91 tokens par seconde à 448 Go/s. Les environnements réels restent sous ces plafonds et ralentissent quand le contexte grandit : à 32K, le cache du modèle 70B ajoute environ 10,7 Go de lecture par token.
Le tableau de quantification de llama.cpp montre ce comportement sur une seule machine avec Llama 3.1 8B : la génération passe d'environ 29 tokens par seconde en F16 à 51 en Q8_0 et 72 en Q4_K_M, tandis que le traitement du prompt reste entre environ 700 et 920 tokens par seconde pour tous les types.
Le traitement du prompt travaille par lots de centaines de tokens : chaque lecture de poids sert de nombreux tokens et le débit matriciel devient la limite. Le travail représente environ 2 × parameters × prompt tokens opérations, soit à peu près 5 × 10^14 pour un prompt de 8000 tokens sur un modèle 32B. Cela fixe le temps jusqu'au premier token en retrieval-augmented generation, où les prompts transportent des passages récupérés comme dans la conception de recherche hybride avec pgvector, ainsi que pour les agents de code qui envoient de gros fichiers. Regardez les deux caractéristiques : NVIDIA DGX Spark a un plafond de génération modeste à 273 Go/s, alors que NVIDIA annonce jusqu'à 1 PFLOP de calcul FP4 creux pour sa puce GB10.
Le batching sert de nombreuses séquences par lecture de poids, donc le débit d'un serveur augmente jusqu'à épuisement du calcul ou du cache. Les boucles d'agents dépendent au contraire de la latence d'une requête, car chaque étape attend l'appel précédent, comme l'explique le guide d'architecture d'un agent IA en production.
Les modèles mixture-of-experts (MoE) séparent ces contraintes : la mémoire suit le nombre total de paramètres, la vitesse de génération suit les paramètres actifs. gpt-oss-120b compte 117 milliards de paramètres dont 5,1 milliards actifs, et sa fiche de modèle indique qu'il tient sur un seul GPU de 80 Go ; son fichier MXFP4 GGUF pèse 63,4 Go. gpt-oss-20b fonctionne dans 16 Go. C'est pourquoi les machines à grande capacité et bande passante modeste restent utiles.
Options matérielles par capacité
GPU NVIDIA par classe de VRAM
Les GPU NVIDIA ont la plus large prise en charge logicielle, car vLLM, SGLang, TensorRT-LLM et llama.cpp traitent CUDA comme plateforme de référence. Comparez d'abord la capacité, puis la bande passante au sein d'une classe : les cartes GeForce de 16 Go font tourner les mêmes modèles, mais la RTX 5080 a plus de deux fois la bande passante de la RTX 5060 Ti. La RTX PRO 6000 Blackwell accueille un modèle 70B en 8 bits sur une seule carte. Les cartes GeForce RTX 50 ne prennent pas en charge NVLink, donc le trafic entre plusieurs GPU passe par PCIe.
Mémoire unifiée : Apple Silicon, Ryzen AI Max, DGX Spark
Les systèmes à mémoire unifiée donnent au CPU et au GPU un même pool LPDDR : bien plus de mémoire pour le modèle que les GPU grand public, avec une bande passante inférieure à celle d'une carte GDDR7 rapide, sauf pour la puce Apple la plus haut de gamme. Pour le Mac Studio, Apple propose le M5 Ultra à partir de 96 Go, annonce la configuration de 512 Go pour fin octobre et prend en charge la mise en grappe via Thunderbolt 5 avec RDMA ; côté logiciel, on trouve llama.cpp sur Metal et MLX. Le Ryzen AI Max+ 395 d'AMD utilise une interface LPDDR5x-8000 de 256 bits, soit 256 Go/s, et le Ryzen AI Max+ PRO 495 passe au LPDDR5x-8533, avec des systèmes OEM annoncés pour le troisième trimestre 2026 ; llama.cpp tourne sur les deux via ROCm ou Vulkan. NVIDIA DGX Spark exécute la pile CUDA et dispose d'un port ConnectX-7 à 200 Gbit/s pour relier plusieurs unités.
D'après la formule du plafond, ces machines font tourner des modèles denses 70B à quelques tokens ou quelques dizaines de tokens par seconde, et les modèles MoE bien plus vite. Leurs GPU travaillent avec un budget de puissance bien plus faible qu'une carte de 575 W : mesurez le temps jusqu'au premier token avec vos vrais prompts.
| Plateforme | Mémoire pour le modèle | Bande passante | Puissance | Modèle dense à 32K de contexte |
|---|---|---|---|---|
| GeForce RTX 5060 Ti 16 GB | 16 Go GDDR7 | 448 Go/s | 180 W | 8B en Q8_0 |
| GeForce RTX 5070 Ti / 5080 | 16 Go GDDR7 | 896 / 960 Go/s | 300 / 360 W | 8B en Q8_0 |
| GeForce RTX 5090 | 32 Go GDDR7 | 1792 Go/s | 575 W | 32B en Q4_K_M |
| RTX PRO 4000 / 4500 Blackwell | 24 / 32 Go GDDR7 ECC | 672 / 896 Go/s | 145 / 200 W | 32B en 4 bits |
| RTX PRO 5000 Blackwell | 48 ou 72 Go GDDR7 ECC | 1344 Go/s | 300 W | 32B en Q8_0, 70B en Q4_K_M sur 72 Go |
| RTX PRO 6000 Blackwell | 96 Go GDDR7 ECC | 1792 Go/s | 600 W ou 300 W (Max-Q) | 70B en Q8_0 |
| DGX Spark | 128 Go LPDDR5x | 273 Go/s | alimentation de 240 W | 70B en Q8_0 |
| Ryzen AI Max+ 395 | 128 Go, jusqu'à 96 Go pour le GPU | 256 Go/s | 45 à 120 W | 70B en Q6_K |
| Ryzen AI Max+ PRO 495 | 192 Go, jusqu'à 160 Go pour le GPU | environ 273 Go/s | 45 à 120 W | 70B en Q8_0 |
| Mac Studio, M5 Max | jusqu'à 128 Go | jusqu'à 614 Go/s | 480 W maximum système | 70B en Q8_0 |
| Mac Studio, M5 Ultra | jusqu'à 512 Go | 1,2 To/s | 480 W maximum système | 70B en BF16 |
La dernière colonne découle des exemples chiffrés ci-dessus pour un seul utilisateur. Le tableau décrit des capacités, pas un rapport qualité-prix.
Plusieurs GPU et déchargement sur le CPU
Deux GPU doublent la capacité, mais la vitesse dépend du découpage. Avec un découpage par couches, le mode par défaut de llama.cpp, chaque GPU détient une plage de couches et leur cache KV, et avec un lot de taille 1 les GPU travaillent à tour de rôle : plus de capacité, même vitesse de génération. Seules de petites activations traversent le PCIe à chaque token, donc des liens x8 ou x4 conviennent. Avec le parallélisme tensoriel (--tensor-parallel-size 2 dans vLLM), les deux GPU lisent en même temps leur part de chaque couche, ce qui relève le plafond, mais chaque couche se synchronise via PCIe. Le parallélisme tensoriel de vLLM est conçu pour des GPU identiques, et le nombre de GPU doit diviser le nombre de têtes d'attention du modèle.
Le déchargement sur le CPU laisse certaines couches en RAM système, où le processeur les exécute. Le temps par token devient une somme : octets sur le GPU divisés par la bande passante de la VRAM, plus octets sur le CPU divisés par la bande passante de la RAM. De la DDR5-6000 en double canal offre 96 Go/s théoriques (2 canaux × 8 octets × 6000 MT/s), et le guide de la mémoire DDR5 explique comment se combinent canaux et fréquences. Un modèle 70B Q4_K_M avec 24 Go sur le GPU et 18,5 Go en RAM reste sous 5 tokens par seconde. Le déchargement règle la capacité, pas la vitesse.
Les modèles MoE se déchargent bien mieux. --cpu-moe et --n-cpu-moe N gardent les poids des experts en RAM tandis que l'attention et le cache KV restent sur le GPU, et seuls les experts actifs sont lus à chaque token. Les versions récentes de llama.cpp ajustent automatiquement les couches quand -ngl n'est pas défini (--fit est activé par défaut) ; fixez-le explicitement pour des résultats reproductibles. Les commandes montrent un modèle dense partiellement déchargé, un modèle MoE avec ses experts en RAM et un découpage par couches pondéré vers le plus grand GPU :
llama-server -m Llama-3.3-70B-Instruct-Q4_K_M.gguf -c 16384 -ngl 48 -fa on
llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 32768 -ngl all --n-cpu-moe 24 -fa on
llama-server -m Qwen_Qwen3-32B-Q8_0.gguf -c 32768 -ngl all --split-mode layer --tensor-split 3,2
Alimentation, refroidissement, lignes PCIe et RAM système
Pour la GeForce RTX 5090, NVIDIA indique 575 W de puissance graphique et 1000 W de puissance système requise. L'édition Max-Q de la RTX PRO 6000, à 300 W, garde la même mémoire que le modèle à 600 W, ce qui compte pour plusieurs cartes dans un même châssis. Comme la génération attend la mémoire, testez une limite plus basse avec nvidia-smi -pl et gardez le réglage où la vitesse de génération bouge à peine.
L'inférence est une charge soutenue, et deux cartes à refroidissement ouvert dans des emplacements voisins se soufflent de l'air chaud. Vérifiez fréquences, température et puissance pendant un test de 30 minutes.
Les cartes GeForce RTX 50 et RTX PRO Blackwell utilisent le PCIe 5.0 x16. Les plateformes de bureau grand public offrent en général un lien graphique x16, que certaines cartes mères divisent en x8/x8, et un emplacement relié au chipset fonctionne souvent en x4. Le découpage par couches le tolère ; le parallélisme tensoriel et le chargement des modèles préfèrent x8 ou plus, ce que fournissent les plateformes de station de travail. La génération de lien affichée peut baisser quand le GPU est au repos : vérifiez-la en charge.
Prévoyez au moins autant de RAM système que le plus gros fichier de modèle chargé, plus de la place pour l'OS, et beaucoup plus si vous déchargez. Les fichiers de modèles vont d'environ 5 Go à bien plus de 100 Go, donc un disque rapide raccourcit les temps de chargement ; le guide d'achat des SSD NVMe traite ce cas d'usage.
nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.width.current,power.draw,memory.used --format=csv -l 1
nvidia-smi dmon -s pucvmt -d 1
sudo nvidia-smi -pl 450
Mesurez votre propre débit
Les chiffres publiés correspondent rarement à votre fichier de modèle, votre contexte, votre pilote et votre version d'environnement d'exécution : mesurez vous-même et comparez à la formule du plafond. Dans llama-bench, -p fixe la longueur du prompt, -n le nombre de tokens générés, et -d préremplit le cache KV jusqu'à une profondeur donnée, ce qui montre comment la vitesse baisse à mesure que la conversation s'allonge. La seconde commande compare un cache en 16 bits et en 8 bits :
llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 512,4096 -n 128 -d 0,16384 -fa on -r 3 -o md
llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 4096 -n 128 -d 16384 -ctk f16,q8_0 -ctv f16,q8_0 -fa on
Testez ensuite la concurrence. vllm bench serve fonctionne avec les endpoints compatibles OpenAI et mesure le temps jusqu'au premier token, le temps par token de sortie, la latence entre tokens et le débit global :
vllm serve Qwen/Qwen3-32B-AWQ --max-model-len 32768
vllm bench serve --backend openai --base-url http://127.0.0.1:8000 --model Qwen/Qwen3-32B-AWQ --dataset-name random --random-input-len 4096 --random-output-len 256 --num-prompts 200 --max-concurrency 8
Divisez la vitesse mesurée sur un flux unique par le plafond. Si le rapport est anormalement bas, cherchez des couches déchargées sur le CPU à votre insu, un lien PCIe de largeur réduite, un bridage thermique ou électrique, ou un backend lent.
Liste de vérification pour dimensionner
- Relevez dans
config.jsonle nombre de paramètres, de couches, de têtes KV et la dimension des têtes. - Choisissez la quantification : 8 bits si cela tient, puis Q6_K ou Q5_K_M, puis 4 bits, et plus bas seulement après des tests.
- Fixez le contexte et la concurrence, calculez le cache KV et décidez si un cache en 8 bits est acceptable.
- Ajoutez 1 à 2 Gio par appareil, plus une marge pour l'OS en mémoire unifiée.
- Écartez les plateformes dont le plafond de génération est inférieur à la vitesse voulue.
- Pour les longs prompts de RAG ou d'agents de code, tenez compte du calcul et mesurez le temps jusqu'au premier token.
- Pour un MoE, dimensionnez la mémoire selon le total des paramètres et la vitesse selon les paramètres actifs.
- Vérifiez alimentation, refroidissement, lignes PCIe, RAM et stockage avant d'acheter un second GPU.
- Mesurez, et réduisez l'écart avec le plafond avant d'ajouter du matériel.