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, entraînant une chute brutale de la vitesse de génération des jetons. Vous pouvez tenter d’augmenter le déchargement des couches sur le GPU via ngl , de choisir une quantification plus petite ou de réduire la longueur du contexte afin que plus du modèle soit placé 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 l’utilisation de la VRAM, ce qui peut réduire le nombre de jetons par seconde ou imposer un déchargement partiel. Un contexte plus court, des modèles plus petits ou des quantifications plus agressives aident à maintenir une vitesse élevée sur une carte unique de 16 Go.

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

Les quants à bits plus faibles consomment moins de VRAM et peuvent augmenter le nombre de jetons par seconde, au détriment potentiel de la qualité. Les quants de type IQ3 et IQ4 sont des compromis courants pour llama.cpp sur un GPU de 16 Go, notamment lorsqu’il est nécessaire de gérer un long contexte ou des points de contrôle plus volumineux.

Les modèles mixture-of-experts peuvent-ils être rapides sur une seule 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 active à chaque étape de propagation avant, mais il reste nécessaire de disposer d’un VRAM suffisant pour les experts actifs, ainsi que les poids et le cache KV à la longueur de contexte choisie.

Que pouvez-vous essayer si un contexte de 64K est beaucoup plus lent que 32K 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 pour que davantage de couches restent sur l’appareil et que la pression sur le cache KV se réduise.

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

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

Sommaire

Ici je compare la vitesse de plusieurs LLM fonctionnant sur un GPU doté de 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 le maximum de performance en termes de vitesse.

Tableau comparatif de la vitesse des LLM (jetons par seconde et VRAM)

Modèle	Taille	VRAM 19K	GPU/CPU 19K	T/s 19K	VRAM 32K	Chargement 32K	T/s 32K	VRAM 64K	Chargement 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 colonne load ci-dessus correspond à la GPU Load (charge du 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 utilisateurs constatent lorsqu’une part trop faible du modèle tient dans la VRAM du GPU, ou lorsque le contexte pousse le calcul vers l’hôte.

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

Si vous souhaitez connaître les chemins d’installation, des exemples de llama-cli et llama-server, ainsi que les options qui comptent pour la VRAM et les jetons par seconde (taille de contexte, batch, -ngl), commencez par Guide de 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 matériel et environnements d’exécution), consultez Performances des 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](https://www.glukhov.org/fr/ai-devtools/opencode/llms-comparison/ “Comparaison pratique des LLM dans OpenCode - modèles locaux Ollama et llama.cpp vs cloud. Tâches de codage, statistiques de précision de la carte de migration et analyse honnête des échecs.”}). Vous pouvez en savoir plus sur Opencode dans Démarrage rapide d’OpenCode : installation, configuration et utilisation de l’agent de codage IA en terminal
Comparaison de la qualité de la traduction de pages Hugo - LLMs sur Ollama

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

Si vous exécutez Qwen 3.6 27B ou 35B via llama.cpp et souhaitez augmenter encore la vitesse de génération, voir 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 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 grandit et la pression sur la VRAM augmente. Certaines lignes montrent une forte baisse des jetons par seconde à 64K, tandis que d’autres restent stables ; c’est le signal qu’il faut réexaminer les quantisations, 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 types de cache à 32K/64K/128K, et comment calculer votre propre marge — voir Cache KV sur GPU 16 GB : Faire tenir réellement les longs contextes.

Les modèles et quantisations que j’ai choisis pour tester servent à moi-même à voir si ils offrent un bon gain en termes de coût/bénéfice sur cet équipement, ou non. Donc pas de quantisations q8 avec 200k de contexte 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 l’option de ligne de commande -ngl, mais je ne le régle pas finement ici, je veux juste comprendre que s’il y a une chute de performance significative en augmentant 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 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 le démarrage de llama-cli : 300Mo

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

Modèle	Chargement 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 quantisations intéressants, j’ai essayé de trouver des paramètres spécifiques de la ligne de commande de llama-cpp pour 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

Conclusions pour les configurations 16 GB VRAM

Mon favori actuel, Qwen3.5-27B-UD-IQ3_XXS, semble performant sur son point optimal de contexte 50k (j’obtiens environ 36 t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS dépasse en performance le Qwen3.5 27B sur les contextes supérieurs à 64K.
Je peux pousser Qwen3.5-35B-A3B-UD-IQ3_S pour gérer un contexte de 100k jetons, et il tient dans la VRAM, donc pas de chute de performance
Je n’utiliserai pas gemma-4-31B sur 16GB VRAM, mais gemma-4-26B est peut-être correct… il faut tester.
Il faut 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 qu’il faudra tester pour confirmer le soupçon.