Que signifie une faible charge du GPU lors de l’exécution d’un LLM avec llama.cpp ?

Cela signifie souvent que de nombreuses couches restent sur le CPU, ce qui fait chuter brutalement la vitesse d’inférence. Vous pouvez tenter d’augmenter le déchargement des couches sur le GPU via le paramètre ngl, choisir une quantification plus légère ou réduire la taille du contexte afin que davantage du modèle tienne en mémoire GPU.

Comment une fenêtre de contexte plus longue affecte-t-elle le nombre de jetons par seconde sur 16 Go de VRAM ?

Un contexte plus long augmente la taille du cache KV et la consommation de VRAM, ce qui peut réduire le nombre de tokens par seconde ou imposer un déchargement partiel. Un contexte plus court, des modèles plus petits ou des quantifications plus agressives contribuent à maintenir des vitesses élevées sur une seule carte de 16 Go.

Quels compromis de quantification sont déterminants pour faire tenir de grands modèles dans 16 Go ?

Les modèles quantifiés avec un nombre de bits plus élevé utilisent moins de VRAM et peuvent augmenter les tokens par seconde, mais peuvent nuire à la qualité. Les quantifications de style IQ3 et IQ4 sont des compromis courants pour llama.cpp sur une seule GPU de 16 Go lorsque vous avez besoin d’un contexte long ou de checkpoints plus importants.

Les modèles « mélange d’experts » peuvent-ils être rapides sur un seul GPU de 16 Go ?

Les modèles MoE peuvent atteindre un débit élevé en tokens par seconde car seule une partie du réseau s’exécute à chaque étape de propagation avant, mais vous avez toujours besoin d’une mémoire VRAM suffisante pour les experts actifs, les poids et le cache KV à la longueur de contexte choisie.

Que pouvez-vous essayer si le contexte de 64K est beaucoup plus lent que celui de 32K sur le même GPU ?

Réglez le nombre de couches chargées sur le GPU via ngl, acceptez un contexte plus court si cela convient à votre tâche, ou passez à une quantification plus légère afin que plus de couches restent sur l’appareil et que la pression sur le cache KV soit réduite.

Benchmarks LLM avec 16 Go de VRAM et llama.cpp (vitesse et contexte)

vitesse de traitement des tokens de llama.cpp sur 16 Go de VRAM (tableaux).

Sommaire

Voici une comparaison de la vitesse de plusieurs LLMs (modèles de langage grand) fonctionnant sur un GPU avec 16 Go de VRAM, et le choix du meilleur pour l’auto-hébergement.

J’ai exécuté ces LLMs avec llama.cpp avec des fenêtres de contexte de 19K, 32K et 64K tokens.

GPU stylisé avec des blocs VRAM et des graphiques de style benchmark

Dans cet article, je consigne mes tentatives pour extraire autant de performances que possible en termes de vitesse.

Tableau comparatif de la vitesse des LLMs (tokens par seconde et VRAM)

Modèle	Taille	VRAM 19K	GPU/CPU 19K	T/s 19K	VRAM 32K	Charge 32K	T/s 32K	VRAM 64K	Charge 64K	T/s 64K
Qwen3.6-35B-A3B-UD-IQ3_XXS	13.2	13.8 Go	96%/100%	147.5	14.0 Go	96%/101%	149.1	14.7 Go	96%/101%	145.8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3 Go	62%/266%	95.0	14.9 Go	58%/279%	92.3	14.9 Go	57%/293%	86.4
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3 Go	93%/100%	136.4	14.6 Go	93%/100%	138.5	14.9 Go	88%/115%	136.8
Qwen3.5-27B-IQ3_XXS-bartowsky	11.3	12.8	98/100	44.9	13.5	98/100	44.9	14.5	45/415	23.6
Qwen3.5-27B-UD-IQ3_XXS	11.5	12.9	98/100	45.3	13.7	98/100	45.1	14.7	45/410	22.7
Qwen3.5-27B-IQ4_XS.gguf	15.0	14.6	49/406	20.5	14.7	37/465	17.4	14.7	23/533	13.3
Qwen3.5-122B-A10B-UD-IQ3_XXS	44.7	14.7	30/470	22.3	14.7	30/480	21.8	14.7	28/490	21.5
Qwen3.5-122B-A10B-UD-IQ3_S	46.5	14.7	25/516	19.4	14.7	24/516	19.5	14.7	24/516	19.6
Mistral-Small-4-119B UD-IQ3_XXS	42.8	14.8	28/585	30.4	14.7	27/574	28.5	14.9	20/590	31.5
Qwen3-Coder-Next-UD-IQ4_XS	38.4	14.6	32/460	41.1	14.7	29/440	41.3	14.8	32/460	38.3
Nemotron Super 120b IQ3_XXS	56.2	15.0	26/517	17.5	14.6	26/531	17.4	14.6	26/535	17.6
gemma-4-26B-A4B-it-UD-IQ4_XS	13.4	14.7	95/100	121.7	14.9	95/115	114.9	14.9	75/190	96.1
gemma-4-31B-it-UD-IQ3_XXS	11.8	14.8	68/287	29.2	14.8	41/480	18.4	14.8	18/634	8.1
GLM-4.7-Flash-IQ4_XS	16.3	15.0	66/240	91.8	14.9	62/262	86.1	14.9	53/313	72.5
GLM-4.7-Flash-REAP-23B IQ4_XS	12.6	13.7	92/100	122.0	14.4	95/102	123.2	14.9	71/196	97.1

19K, 32K et 64K sont les tailles de contexte.

La charge ci-dessus est la Charge GPU. Si vous voyez un chiffre bas dans cette colonne, cela signifie que le modèle fonctionne principalement sur le CPU et ne peut pas atteindre une vitesse décente sur ce matériel. Ce schéma correspond à ce que les gens observent lorsque trop peu de modèle tient sur le GPU ou lorsque le contexte repousse le travail vers l’hôte.

À propos de llama.cpp, des performances des LLMs, d’OpenCode et d’autres comparaisons

Si vous souhaitez des chemins d’installation, des exemples de llama-cli et llama-server, et les drapeaux qui comptent pour la VRAM et les tokens par seconde (taille de contexte, regroupement, -ngl), commencez par llama.cpp Quickstart with CLI and Server.

Pour une vue d’ensemble des performances (débit versus latence, limites de VRAM, requêtes parallèles et comment les benchmarks s’articulent entre les matériels et les environnements d’exécution), consultez LLM Performance in 2026: Benchmarks, Bottlenecks & Optimization.

La qualité de la réponse est analysée dans d’autres articles, par exemple :

Best LLMs for OpenCode - Tested Locally. Vous pouvez en savoir plus sur Opencode dans OpenCode Quickstart: Install, Configure, and Use the Terminal AI Coding Agent
Comparison of Hugo Page Translation quality - LLMs on Ollama

J’ai également effectué des tests similaires pour les LLMs sur Ollama : Best LLMs for Ollama on 16GB VRAM GPU.

Si vous exécutez Qwen 3.6 27B ou 35B via llama.cpp et souhaitez pousser la vitesse de génération plus loin, consultez Qwen 3.6 MTP vs Standard Decoding on 16GB GPU — le décodage spéculatif MTP ajoute jusqu’à 67 % de débit de génération pour le modèle dense 27B, avec des tableaux montrant le coût en VRAM et le compromis de fenêtre de contexte à chaque niveau --spec-draft-n-max.

Pourquoi la longueur du contexte change les tokens par seconde

Lorsque vous passez de 19K à 32K ou 64K tokens, le cache KV grandit et la pression sur la VRAM augmente. Certaines lignes montrent une grande chute des tokens par seconde à 64K tandis que d’autres restent plates, ce qui est le signal pour réviser les quants, les limites de contexte ou le déchargement de couches plutôt que de supposer que le modèle est « lent » en général.

Les modèles et quants que j’ai choisis de tester - sont à exécuter par moi-même pour voir s’ils donnent un bon gain en termes de coût/avantage sur cet équipement ou non. Donc pas de quants q8 ici avec un contexte de 200k :) …

GPU/CPU est une charge, mesurée par nvitop.

llama.cpp, lors de la configuration automatique des couches déchargées sur le GPU, essaie de garder 1 Go libre. Nous spécifions manuellement ce paramètre via le paramètre de ligne de commande -ngl mais je ne le règle pas finement ici, je dois juste comprendre que s’il y a une baisse significative de performance lors de l’augmentation de la taille de la fenêtre de contexte de 32k à 64k - nous pouvons essayer d’augmenter la vitesse à 64k en réglant finement le nombre de couches déchargées.

Matériel de test et configuration de llama.cpp

J’ai testé la vitesse des LLMs sur un PC avec cette configuration :

CPU i-14700
RAM 64 Go 6000Hz (2x32 Go)
GPU RTX-4080
Ubuntu avec pilotes NVidia
llama.cpp/llama-cli, aucune couche déchargée spécifiée
VRAM utilisée initialement, avant de lancer llama-cli : 300 Mo

Exécutions supplémentaires à 128K de contexte (Qwen3.5 27B et 122B)

Modèle	Charge 128K	T/s 128K
Qwen3.5-27B-UD-IQ3_XXS	16/625	9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS	27/496	19.2

Exécutions réglées finement

Pour certains modèles et quants intéressants, j’ai essayé de trouver des paramètres de ligne de commande llama-cpp spéciaux pour mieux utiliser la VRAM. Voici ce que j’ai pu accomplir :

Modèle	Contexte	Couches sur GPU	Charge CPU/CPU	Vitesse
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Conclusions pour les builds 16 Go VRAM

Mon favori actuel Qwen3.5-27B-UD-IQ3_XXS a l’air bien sur son point fort 50k de contexte (j’obtiens environ 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS dépasse en termes de performances le Qwen3.5 27B sur les contextes supérieurs à 64K.
Je peux pousser Qwen3.5-35B-A3B-UD-IQ3_S à gérer un contexte de 100k tokens, et il tient dans la VRAM, donc pas de baisse de performance
Je n’utiliserai pas gemma-4-31B sur 16 Go VRAM, mais gemma-4-26B pourrait être moyennement bien…, il faut tester.
Il faut tester comment Nemotron cascade 2 et GLM-4.7 Flash REAP 23B fonctionnent. Seront-ils meilleurs que Qwen3.5-35B q3 ? J’en doute mais quand même, je testerai pour confirmer le soupçon.