GGUF, quantification et VRAM : calculer la mémoire nécessaire aux modèles locaux

La quantification réduit la taille des poids, mais pas toute la mémoire nécessaire

La quantification consiste à représenter les poids d’un modèle avec une précision numérique moindre afin de réduire l’espace qu’ils occupent et, sur certaines machines, d’accélérer l’inférence. Dans les fichiers GGUF, vous rencontrerez des noms comme Q4_K_M, Q5_K_M ou Q8_0. Ils donnent des indications sur la quantification, mais ne décrivent ni toute l’empreinte mémoire, ni ne garantissent une qualité ou une vitesse précises.

GGUF est un conteneur de modèle couramment utilisé avec llama.cpp et des outils reposant sur ce moteur. Ce n’est pas synonyme de quantification : un fichier GGUF peut contenir des poids stockés avec différents types et niveaux de précision. De même, « Q4 » ne signifie pas que chaque paramètre occupe exactement quatre bits. Les métadonnées, les échelles et les éléments conservés à une autre précision augmentent la taille. Il est donc préférable, quand elle est disponible, de vérifier la taille réelle du fichier quantifié à charger.

Pour dimensionner un déploiement, il faut distinguer au moins quatre postes : les poids, le cache clé-valeur (KV), la mémoire temporaire de calcul et la surcharge du moteur. Leur total dépend de l’architecture du modèle, du contexte, du lot, de la répartition entre appareils et du logiciel utilisé. Un calcul fondé uniquement sur le nombre de paramètres peut écarter une configuration qui fonctionnerait, ou faire croire qu’une autre tiendra alors qu’elle échouera lors de la réservation de mémoire pour la conversation.

La première question n’est pas « quelle est la meilleure carte graphique ? », mais « de quel modèle, de quel contexte, de quelle concurrence et de quelle latence ai-je besoin ? ». On peut ensuite estimer la mémoire et tester les configurations compatibles. Pour comparer des moteurs ou des modèles, consultez un comparatif et définissez une charge de travail commune ; pour explorer les solutions d’inférence locale, filtrez les options selon la tâche et le matériel disponible.

Ce que signifient Q4_K_M, Q5_K_M et Q8_0

En général, quantifier revient à réduire la précision avec laquelle les poids sont stockés. Le bénéfice attendu est une empreinte mémoire plus faible pour ces poids ; le coût possible est un écart entre les réponses et celles du modèle de référence. Cet équilibre n’est pas le même pour tous les modèles et ne peut pas être résumé de manière fiable par un pourcentage fixe de perte.

Dans les variantes GGUF, le nombre indique une catégorie de quantification, mais pas toute la composition du fichier. Les suffixes distinguent des méthodes et des répartitions de précision. Dans un nom comme Q4_K_M, la famille K et la variante M font partie du schéma ; elles ne signifient pas qu’on applique uniformément quatre bits à chaque paramètre. La taille du fichier est une donnée plus fiable que le calcul d’un nombre exact d’octets à partir du seul nom.

À titre indicatif, une configuration Q4 nécessite généralement moins d’espace pour les poids qu’une configuration Q5 ou Q8 du même modèle. En contrepartie, Q5 et Q8 conservent une précision supérieure pour les poids, mais consomment davantage de mémoire. Cela ne prouve pas qu’elles produiront de meilleures réponses pour toutes les tâches : il faut mesurer les résultats dans l’application concernée. Un classificateur, un générateur de code et un chatbot généraliste peuvent réagir différemment à une même quantification.

GGUF permet également de choisir différents formats de quantification pour une même famille de modèles, mais la compatibilité dépend du moteur et de son implémentation. Ne supposez pas que deux fichiers portant des étiquettes proches s’exécuteront à la même vitesse ou produiront les mêmes résultats. Vérifiez que le modèle est compatible avec le moteur, que le backend attendu a bien été chargé et que l’évaluation porte sur la même version du modèle.

Calculer séparément les poids, le cache KV et la marge

Pour une première approximation, estimez la taille des poids résidents à partir du fichier de modèle réellement chargé. Si seul le nombre de paramètres est connu, on peut effectuer un calcul indicatif : nombre de paramètres multiplié par le nombre moyen d’octets par paramètre. Mais cette moyenne doit correspondre à la quantification réelle et non au chiffre du nom, pris à tort pour une valeur exacte. Dans un fichier GGUF, le mélange de précisions peut fausser cette simplification.

Le cache KV conserve des informations sur les jetons précédents dont le modèle a besoin pendant la génération. Sa taille augmente généralement avec la longueur de séquence et la taille du lot, et dépend de l’architecture : nombre de couches, têtes KV, dimension des têtes et type de données du cache. On peut l’exprimer sous une forme générale ainsi : deux fois le nombre de couches, multiplié par le nombre de têtes KV, la dimension par tête, le nombre de jetons stockés, la taille du lot et le nombre d’octets par élément. Il faut adapter cette formule à l’implémentation et aux architectures qui utilisent d’autres mécanismes d’attention.

Pour obtenir les dimensions pertinentes, consultez la configuration du modèle et la documentation du moteur plutôt que de les déduire uniquement du nombre de paramètres ou des têtes de requête. Avec l’attention groupée, le nombre de têtes KV peut être inférieur au nombre de têtes de requête ; calculer comme si chaque tête de requête disposait de son propre cache peut donc surestimer le résultat. D’autres architectures peuvent nécessiter une formule différente.

La mémoire temporaire et la surcharge ne correspondent pas à un pourcentage fixe des poids. Le préremplissage de longs prompts peut nécessiter des tampons plus importants que la génération jeton par jeton. La fragmentation, le backend, la réservation mémoire, les bibliothèques et le nombre de GPU influent également sur le résultat. L’estimation d’AIMultiple sépare poids, cache KV, activations et surcharge : elle fournit une structure de calcul utile, mais ses résultats doivent être vérifiés pour le modèle, le moteur et la configuration exacts.

Il n’existe pas de réponse unique et vérifiable à la question « de combien de VRAM a besoin un modèle 7B Q4_K_M avec 4096 jetons ? » sans préciser le modèle, la taille du lot, le type de cache KV, le moteur, la répartition et la marge. Une séquence de 4096 jetons indique une longueur, mais ne suffit pas à définir le cache : il manque les dimensions de l’architecture et d’autres paramètres. La taille du fichier peut servir de base pour estimer les poids, mais pas le besoin total.

Choisir entre VRAM, RAM et déchargement partiel

La VRAM disponible détermine la quantité de données pouvant résider sur le GPU. La RAM système peut servir à charger certaines parties du modèle lorsque le moteur prend en charge le déchargement partiel. Mais une grande quantité de RAM ne garantit pas une expérience interactive : le transfert de données entre la RAM et le GPU peut réduire les performances, selon la liaison entre les deux et la manière dont les couches sont réparties.

Si les réponses doivent être rapides et fréquentes, privilégiez une configuration où les poids et le cache actif tiennent dans la mémoire du GPU, avec une marge suffisante. Si l’objectif est de faire tourner un modèle qui ne tiendrait autrement pas, le déchargement vers la RAM peut être une solution de capacité, au prix d’une latence accrue. Ne confondez pas « le modèle se charge » et « il respecte l’objectif de vitesse ».

Sur Apple Silicon, la mémoire unifiée est partagée entre CPU et GPU, mais le système et les autres applications l’utilisent également. La quantité de RAM installée ne correspond donc pas nécessairement à la mémoire disponible pour le modèle. Dans une configuration à plusieurs GPU, il ne suffit pas non plus d’additionner leurs capacités : la communication entre appareils et les réserves propres à chacun ont un coût, et le logiciel doit prendre en charge la répartition prévue.

La bande passante influe particulièrement sur la génération, qui implique des lectures répétées des poids. La capacité détermine si les données peuvent tenir en mémoire ; la bande passante et l’implémentation contribuent à la vitesse une fois le modèle chargé. Le moteur, la prise en charge des kernels, le type de quantification et la concurrence peuvent modifier les résultats. Choisir un matériel en fonction de la seule VRAM ou d’une valeur théorique de bande passante laisse donc de côté des facteurs déterminants.

Il n’existe pas de minimum universel pour une configuration 7B Q4 avec 4096 jetons

Un modèle de 7 milliards de paramètres en Q4_K_M occupe généralement moins de mémoire pour ses poids que le même modèle en Q5 ou Q8. Ce principe ne permet cependant pas d’établir une valeur minimale universelle de VRAM ou de RAM. Le nombre de paramètres ne décrit pas complètement l’architecture, les tenseurs conservés à une autre précision ni la taille exacte du fichier.

Les 4096 jetons ne suffisent pas non plus à calculer le cache. Il faut au minimum connaître l’architecture, le nombre de couches, les têtes KV, la dimension par tête, le type de données du cache KV et la taille du lot. Avec une fenêtre d’attention ou un mécanisme différent, le calcul change. La réponse responsable consiste à mesurer une configuration précise, et non à promettre que tout modèle 7B Q4_K_M fonctionnera avec une quantité fixe de mémoire.

En pratique, prenez comme référence la taille du fichier exact pour les poids, calculez le cache KV à partir des paramètres de l’architecture, puis ajoutez la mémoire temporaire et la réserve du moteur. Vérifiez ensuite le pic d’utilisation lors du chargement et de la génération. Si le système ne dispose que de RAM, l’exécution peut être possible avec un moteur compatible, mais on ne peut pas en déduire la vitesse.

Il n’est donc pas recommandé d’acheter une carte en s’appuyant sur un tableau générique du type « 7B = X Go ». Commencez par préciser le modèle et l’objectif de service : utilisateur unique ou concurrence, contexte habituel et maximal, réponse en temps réel ou traitement par lots. Un cas d’usage défini permet de dimensionner ; une étiquette de nombre de paramètres, à elle seule, ne le permet pas.

Performances : mesurer la vitesse, la première réponse et la concurrence

Les jetons par seconde décrivent une partie des performances, mais il faut préciser si la mesure concerne le préremplissage du prompt ou la génération. La latence jusqu’au premier jeton inclut la réception, le préremplissage et la préparation ; elle peut augmenter avec de longs prompts, même si la génération qui suit est rapide. Pour une application interactive, ces deux mesures comptent.

Pour comparer des résultats, gardez constants le modèle, le prompt, la longueur de sortie, le contexte, la taille du lot, le moteur, la version logicielle et la température de l’appareil. Effectuez plusieurs répétitions et relevez la médiane et la variabilité, ainsi que la mémoire maximale. Évitez de comparer un test avec une réponse courte à un autre avec un long contexte : les charges mesurées seraient différentes.

Les sources fournies ne permettent pas d’attribuer un nombre de jetons par seconde ou une latence attendue à un modèle 13B Q5_K_M sur un GPU de 16 Go. Le résultat dépend du GPU concerné, de sa bande passante, du modèle et de son architecture, du moteur, des couches déchargées, du contexte et de la configuration. Une estimation de capacité ne remplace pas un benchmark sur la machine visée.

Pour un service multiutilisateur, mesurez aussi le débit agrégé et la latence par requête en situation de concurrence. Un moteur optimisé pour traiter plusieurs requêtes simultanément peut se comporter différemment d’un moteur local conçu pour une seule conversation. La charge d’essai doit refléter l’usage réel : un utilisateur unique qui génère du code ne représente pas un serveur avec plusieurs sessions et de longs prompts.

Évaluer la perte de qualité sur les tâches qui comptent

Aucun chiffre unique ne décrit la dégradation entre Q8 et Q4 pour tous les modèles et toutes les tâches. L’écart dépend de l’architecture, de la méthode de quantification, du jeu d’évaluation et du critère de notation. Affirmer qu’un modèle « perd 2 % » n’a pas de sens sans préciser la métrique, les données, la version et les conditions de comparaison.

Créez une évaluation à partir d’exemples représentatifs, avec des réponses attendues ou des critères de notation définis avant les tests. Pour la classification, utilisez un jeu de données étiqueté et comparez l’exactitude, la précision, le rappel ou le F1, selon le coût des faux positifs et des faux négatifs. Pour la génération, évaluez le respect des consignes, l’exactitude factuelle vérifiable, le format et les erreurs critiques à l’aide d’une grille cohérente. Pour le code, exécutez des tests automatisés ; une impression subjective selon laquelle « le résultat semble correct » ne suffit pas.

Comparez chaque quantification au même modèle de référence, avec un prompt, un modèle de conversation et des paramètres de génération identiques. Conservez les mêmes graines si le moteur le permet et répétez les tâches stochastiques. Rapportez la moyenne ainsi que les échecs graves : une moyenne comparable peut masquer une baisse importante sur un petit groupe de cas.

Le travail présenté sur alphaXiv consacré à Qwen3.5-4B décrit un cas précis d’inférence INT4 avec distillation tenant compte de la quantification, décodage spéculatif et GPU A10G. Il constitue une preuve pour ce système et cette configuration, pas une démonstration que toute quantification Q4 de GGUF conserve la qualité ou produit la même accélération. En outre, l’extrait ne permet pas de généraliser ces résultats à un modèle 13B ou à un autre GPU.

Critères de choix de la quantification et du matériel

Commencez par définir le niveau de qualité exigé par la tâche, plutôt que de chercher la quantification la plus faible qui tient en mémoire. Si la qualité de référence est indispensable et que la mémoire le permet, conservez une précision supérieure et mesurez la différence avec Q4. Si la mémoire est le facteur limitant, testez Q4_K_M, mesurez les performances et comparez la qualité. Si cette dernière est insuffisante, envisagez Q5, une réduction du contexte ou un autre modèle avant de conclure que la seule solution est d’acheter du matériel.

Le choix du matériel doit tenir compte de la capacité mémoire, de la bande passante, de la compatibilité du moteur et de la facilité de maintenance du déploiement. Un appareil disposant d’assez de VRAM peut rester lent si la quantification ne bénéficie pas de kernels efficaces ou si une partie du modèle est déchargée. À l’inverse, un modèle qui tient dans la RAM peut être utile pour des essais ou des charges non interactives, sans atteindre la latence d’un GPU.

Évaluez chaque combinaison dans votre propre tableau de décision : modèle, quantification, contexte, taille du lot, mémoire maximale, latence jusqu’au premier jeton, vitesse de génération et score de qualité. Ce tableau peut justifier un achat en montrant le besoin qui n’est pas satisfait. Il évite également de prendre le prix d’une carte pour un substitut à un essai.

Pour comparer les moteurs et les configurations, conservez le même protocole et consultez un comparatif technique. Pour découvrir les modèles compatibles, filtrez par architecture, format, licence et taille réelle du fichier ; ne supposez pas que toutes les variantes ont le même comportement.

Conclusion : valider l’estimation initiale sur la machine cible

GGUF facilite la distribution de modèles locaux avec différentes quantifications, mais les noms Q4, Q5 ou Q8 ne suffisent pas à dimensionner un déploiement. Utilisez la taille réelle du fichier pour estimer les poids, calculez le cache KV à partir de l’architecture et de la configuration prévues, puis ajoutez les tampons et la réserve du moteur.

Il n’existe pas de valeur universelle de VRAM pour un modèle 7B Q4_K_M avec 4096 jetons, ni de prédiction fiable du nombre de jetons par seconde pour un modèle 13B Q5_K_M sur un GPU de 16 Go sans détails supplémentaires. Présenter de tels chiffres comme des garanties masquerait les variables qui déterminent le résultat.

La décision finale exige deux validations : la mémoire et les performances dans la charge réelle, ainsi que la qualité sur les tâches qui justifient le déploiement. Consignez le contexte, la taille du lot, le moteur, les versions, le pic mémoire, la latence et les métriques de qualité. Vous pourrez ainsi choisir entre une autre quantification, un contexte plus court, un déchargement partiel, un autre modèle ou une mise à niveau matérielle sur la base de résultats comparables.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.