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 entraîne une chute brutale de la vitesse de génération de jetons. Vous pouvez essayer d’augmenter le déchargement des couches GPU avec ngl, de choisir une quantification plus petite, ou de raccourcir le contexte afin que plus du modèle tienne sur le 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 les jetons par seconde ou obliger à un offload partiel. Un contexte plus court, des modèles plus petits ou des quantifications plus agressives aident à maintenir la vitesse sur une carte unique de 16 Go.

Quels compromis de quantification sont essentiels pour l’adaptation de grands modèles sur 16 Go ?

Les quantifications à bits inférieurs consomment moins de VRAM et permettent d’augmenter le nombre de jetons par seconde, mais peuvent nuire à la qualité. Les quantifications de type IQ3 et IQ4 constituent des compromis courants pour llama.cpp sur un GPU de 16 Go lorsqu’il est nécessaire de gérer de longs contextes ou des points de contrôle plus volumineux.

Les modèles de type mixture-of-experts peuvent-ils être rapides sur un seul GPU de 16 Go ?

Les modèles MoE peuvent atteindre un débit élevé de jetons par seconde, car seule une partie du réseau est exécutée à chaque étape d’inférence. Toutefois, vous devez disposer de suffisamment de VRAM pour les experts actifs, ainsi que pour les poids et le cache KV à la longueur de contexte choisie.

Que pouvez-vous essayer si un contexte de 64 Ko est beaucoup plus lent qu’un contexte de 32 Ko sur le même GPU ?

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

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

Vitesse de génération des tokens de llama.cpp sur 16 Go de VRAM (tableaux).

Sommaire

Ici je compare la vitesse de plusieurs LLM tournant sur un GPU avec 16 Go de VRAM, et je choisis le meilleur pour l’auto-hébergement.

J’ai exécuté ces LLM avec llama.cpp en utilisant des fenêtres de contexte de 19K, 32K et 64K jetons.

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

Dans cet article, je consigne mes tentatives pour extraire autant de performances que possible, et plus particulièrement en termes de vitesse.

Tableau comparatif des vitesses LLM (jetons par seconde et VRAM)

Modèle	Taille	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Chargement	32K T/s	64K VRAM	64K Chargement	64K: T/s
Qwen3.6-35B-A3B-UD-IQ3_XXS	13.2	13.8Go	96%/100%	147,5	14.0Go	96%/101%	149,1	14.7Go	96%/101%	145,8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3Go	62%/266%	95,0	14.9Go	58%/279%	92,3	14.9Go	57%/293%	86,4
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3Go	93%/100%	136,4	14.6Go	93%/100%	138,5	14.9Go	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.

Le chargement ci-dessus est une charge GPU. Si vous voyez un chiffre faible 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 constatent lorsqu’une trop petite partie du modèle est chargée sur le GPU ou lorsque le contexte repousse le travail vers l’hôte.

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

Si vous souhaitez des chemins d’installation, des exemples de llama-cli et llama-server, ainsi que les options importantes pour la VRAM et les jetons par seconde (taille de contexte, groupement, -ngl), commencez par Démarrage rapide de llama.cpp avec CLI et Serveur.

Pour une vue d’ensemble plus large des performances (débit par rapport à la latence, limites de VRAM, requêtes parallèles et la manière dont les benchmarks s’articulent entre les matériels et les temps d’exécution), voir Performances LLM en 2026 : Benchmarks, Goulots d’étranglement et Optimisation.

La qualité des réponses est analysée dans d’autres articles, par exemple :

Meilleurs LLM pour OpenCode - Testés localement. Vous pouvez en savoir plus sur Opencode dans Démarrage rapide OpenCode : Installation, Configuration et Utilisation de l’Agent de Codage IA en Terminal
Comparaison de la qualité de traduction des pages Hugo - LLM sur Ollama

J’ai également réalisé un test similaire pour des LLM sur Ollama : Meilleurs LLM pour Ollama sur GPU 16 Go VRAM.

Si vous exécutez Qwen 3.6 27B ou 35B via llama.cpp et souhaitez augmenter davantage la vitesse de génération, consultez Qwen 3.6 MTP vs Décodage Standard sur GPU 16GB — 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 la fenêtre de contexte à chaque niveau de --spec-draft-n-max.

Pourquoi la longueur du contexte modifie les jetons par seconde

Lorsque vous passez de 19K à 32K ou 64K jetons, le cache KV augmente et la pression sur la VRAM se renforce. Certaines lignes montrent une forte baisse des jetons par seconde à 64K tandis que d’autres restent stables, ce qui est le signal de revoir les quantifications, les limites de contexte ou le déchargement des couches, plutôt que de supposer que le modèle est « lent » en général. Pour le calcul budgétaire derrière ces chiffres — la formule exacte des octets KV par jeton, les tableaux de type de cache à 32K/64K/128K et comment calculer votre propre marge de manœuvre — voir Cache KV sur GPU 16 Go : Rendre le contexte long vraiment utilisable.

Les modèles et les quantifications que j’ai choisis pour tester sont destinés à être exécutés par moi-même afin de voir s’ils offrent un bon gain en termes de rapport coût/bénéfice sur cet équipement ou non. Donc pas de quantification q8 avec un contexte de 200k ici :) …

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

llama.cpp, lors de la configuration automatique du déchargement des couches vers 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 l’optimise pas ici, j’ai juste besoin de comprendre que s’il y a une chute de performance significative 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 ajustant finement le nombre de couches déchargées.

Matériel de test et configuration de llama.cpp

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

CPU i-14700
RAM 64Go 6000Hz (2x32Go)
GPU RTX-4080
Ubuntu avec pilotes NVidia
llama.cpp/llama-cli, aucun nombre de couches déchargées spécifié
VRAM utilisée initialement, avant de démarrer llama-cli : 300 Mo

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

Modèle	128K Chargement	128K: T/s
Qwen3.5-27B-UD-IQ3_XXS	16/625	9,6
Qwen3.5-122B-A10B-UD-IQ3_XXS	27/496	19,2

Exécutions optimisées

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

Modèle	Contexte	Couches sur GPU	Charge CPU/GPU	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

Points clés pour les configurations 16 Go VRAM

Mon Qwen3.5-27B-UD-IQ3_XXS actuel préféré se comporte bien sur son point idéal avec un contexte de 50k (j’obtiens environ 36 t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS surpasse Qwen3.5 27B en termes de performances sur les contextes au-dessus de 64K.
Je peux pousser Qwen3.5-35B-A3B-UD-IQ3_S à gérer un contexte de 100k jetons, et cela tient dans la VRAM, donc aucune baisse de performance
Je n’utiliserai pas gemma-4-31B sur 16 Go VRAM, mais gemma-4-26B pourrait être moyen… besoin de tester.
Besoin de tester à quel point Nemotron cascade 2 et GLM-4.7 Flash REAP 23B fonctionnent. Seront-ils meilleurs que Qwen3.5-35B q3 ? J’en doute mais peut-être tester pour confirmer le soupçon.