Quantifier un modèle local sans deviner : comment choisir 4, 6 ou 8 bits selon la VRAM, le contexte et la perte acceptable

Le fait que les poids tiennent en VRAM ne signifie pas que le système fonctionne

L’erreur la plus fréquente au moment de choisir un modèle local consiste à comparer la taille du fichier quantifié à la mémoire du GPU, puis à considérer la décision comme réglée. Ce calcul ne couvre qu’approximativement les poids. Pendant l’inférence, interviennent aussi le cache de clés et de valeurs — le cache KV —, les activations et tampons temporaires, l’espace réservé par le runtime, le contexte de chaque requête et, dans un service, les requêtes simultanées. Une configuration peut charger le modèle, répondre à une question courte, puis échouer face à un long document ou à plusieurs requêtes en même temps.

La conséquence pratique est importante : « tenir » doit vouloir dire terminer la charge maximale prévue avec une marge mesurée, et non simplement démarrer une session isolée. Si cette marge disparaît, le résultat peut être une erreur de mémoire, une réduction automatique du contexte, le transfert d’une partie du travail vers la RAM système ou une latence très irrégulière. Le comportement effectif dépend du runtime et de sa configuration : il ne faut pas le supposer sans le vérifier.

La quantification est l’un des plusieurs leviers disponibles. Réduire le nombre de bits des poids libère généralement de la mémoire et peut permettre d’utiliser un modèle plus grand, mais cela n’élimine pas à lui seul le coût croissant du cache KV lorsque le contexte ou la concurrence augmente. Selon le format et le backend, cela peut aussi modifier la qualité, les performances ou les chemins d’exécution disponibles. Il n’existe donc pas d’équivalence universelle entre « 4 bits », « 6 bits » et « 8 bits ».

Ce guide part d’une charge de travail précise : quelle longueur d’entrée doit être acceptée, combien de tokens doivent être générés, combien de requêtes coexisteront, quelle latence est utile et quelles erreurs seraient inacceptables. Si vous choisissez encore une famille de modèles, consultez d’abord le guide des modèles locaux. Si l’hésitation porte sur plusieurs modèles de base, utilisez la section de comparaison avant d’attribuer à la quantification des différences qui proviennent du modèle lui-même.

Les postes mémoire à séparer

Une estimation utile commence par décomposer la mémoire en postes observables séparément. Le premier correspond aux poids du modèle. Leur taille dépend du nombre de paramètres, de la représentation quantifiée et de métadonnées propres au format, telles que les échelles, les blocs ou des structures auxiliaires. Diviser simplement le nombre de paramètres par huit, six ou quatre donne donc une orientation, mais ne remplace pas la taille réelle indiquée par le format et le runtime.

Le deuxième poste est le cache KV. Dans un décodeur autorégressif, le système conserve les clés et les valeurs des tokens déjà traités afin de ne pas les recalculer à chaque token généré. La documentation des runtimes décrit des tenseurs de cache avec des dimensions de lot, de têtes, de longueur de séquence et de dimension de tête. Il existe des clés et des valeurs, et ce stockage est répété à chaque couche. À architecture égale, augmenter le contexte, le lot ou la concurrence augmente la mémoire nécessaire.

Le troisième poste regroupe les activations et tampons temporaires. Leur taille dépend du backend, de la précision de calcul, des kernels, du préremplissage d’entrées longues, de la longueur de génération et de la manière dont les requêtes sont regroupées. Il ne faut pas les remplacer par une constante universelle. Le quatrième composant est la mémoire non directement attribuée au modèle : contexte d’exécution, bibliothèques, allocateurs et fragmentation. Le cinquième est une marge opérationnelle explicite, volontairement non allouée pour absorber les pics, les écarts entre mesures et la charge réelle.

Sur un serveur, il faut distinguer avec soin lot et concurrence. Un lot peut représenter le nombre de séquences traitées ensemble lors d’une étape, tandis que la concurrence désigne le nombre de requêtes actives. Selon l’ordonnanceur, ces valeurs peuvent être liées sans être interchangeables. Pour estimer le cache, comptez la somme des tokens actifs des séquences qui coexistent, et non seulement la longueur maximale d’une seule requête.

Estimer les poids et le cache KV avant de télécharger ou déployer

L’estimation ne cherche pas à prédire chaque octet : elle sert à écarter les configurations irréalisables et à définir les essais qui méritent d’être exécutés. Pour les poids, utilisez la taille indiquée pour l’artefact précis que vous prévoyez de charger, et non un chiffre générique pour une famille de modèles. Si seul le nombre de paramètres est connu, considérez le résultat comme un minimum théorique incomplet. Les formats de quantification stockent des informations supplémentaires et certains runtimes convertissent ou dupliquent des structures au chargement.

Pour une architecture de type Llama, une approximation conceptuelle du cache KV par séquence est la suivante : nombre de couches multiplié par deux, multiplié par le nombre de têtes clé-valeur, multiplié par la longueur de séquence, multiplié par la dimension de tête, puis par le nombre d’octets de chaque élément du cache. Le facteur deux représente K et V. Pour plusieurs séquences simultanées, additionnez les tokens résidents de chacune. Si le runtime utilise un cache statique, il peut réserver une capacité maximale même lorsque l’usage instantané est plus faible ; avec un cache dynamique, l’usage peut croître avec la requête. Les deux stratégies exigent des mesures.

Il est essentiel d’utiliser le nombre de têtes clé-valeur, qui n’est pas toujours le nombre total de têtes d’attention. En attention multi-query ou grouped-query, plusieurs têtes de requête partagent des projections KV. Cela peut réduire fortement le cache par rapport à une architecture ayant une projection KV par tête d’attention. La configuration exacte du modèle doit fournir le nombre de couches, de têtes KV et la dimension de tête ; ne les déduisez pas d’un nom commercial.

Les octets par élément du cache doivent eux aussi être vérifiés. Quantifier les poids n’implique pas automatiquement de quantifier le cache KV. Certains environnements permettent de choisir un type de données de cache quantifié, d’autres emploient par défaut une précision différente, et d’autres encore appliquent de l’offloading. Ces options modifient le budget mémoire et peuvent influencer les performances ou le comportement numérique. Notez la configuration réelle du runtime, pas seulement le nombre de bits figurant dans le nom du fichier.

Ce qui change réellement entre 8, 6 et 4 bits

En règle générale, réduire la précision des poids diminue leur empreinte mémoire par rapport à une représentation plus précise du même modèle. Cela peut rendre un GPU plus modeste viable, laisser davantage de budget pour le contexte ou permettre plus de requêtes concurrentes. La réduction observée ne suit toutefois pas nécessairement une proportion exacte de huit à six à quatre : empaquetage, échelles par groupe, format de fichier, conversions internes et tampons du backend modifient le résultat.

La qualité ne dépend pas non plus uniquement du nombre de bits. L’algorithme de quantification, la taille des groupes, les tenseurs qui reçoivent un traitement particulier, le modèle de base et la tâche comptent tous. Une quantification 4 bits avec une méthode donnée peut bien préserver une tâche, tandis qu’une quantification 6 bits d’une autre méthode peut échouer ; l’inverse reste également possible. Les bits servent donc à formuler des hypothèses de test, pas à certifier la précision.

La vitesse exige la même prudence. Une empreinte mémoire plus faible peut réduire les transferts et améliorer la faisabilité sur un appareil limité, mais un format peut ne pas disposer de kernels efficaces sur un backend donné ou nécessiter des conversions. Un contexte plus long peut déplacer le goulot d’étranglement vers la gestion du cache et le préremplissage. Mesurez séparément le temps jusqu’au premier token pour des entrées représentatives et le débit de génération ensuite. Un unique chiffre de tokens par seconde masque des différences importantes.

Comme point de départ, essayez 8 bits lorsque la qualité est critique et que le budget le permet ; 6 bits lorsqu’il faut récupérer une part importante de mémoire sans adopter immédiatement l’option la plus agressive ; et 4 bits lorsque la VRAM est la contrainte dominante ou lorsque les essais prouvent qu’il n’y a pas de perte inacceptable. Ce sont des priorités d’essai, pas des recommandations universelles.

Procédure de décision : de la contrainte au candidat viable

Définissez d’abord le contrat opérationnel. Écrivez la longueur maximale d’entrée réellement nécessaire, une réserve de tokens de sortie, le nombre maximal de requêtes actives, l’objectif de latence et les tâches critiques. Distinguez un maximum exceptionnel d’un objectif habituel. Si l’application traite de longs documents, ne mesurer que des messages courts ne représente ni son risque mémoire ni sa qualité utile.

Réunissez ensuite les paramètres de l’architecture et du runtime. Pour le modèle, consignez les couches, les têtes KV, la dimension de tête et le format des poids. Pour le runtime, notez le type de données du cache, le caractère statique ou dynamique de sa réservation, les possibilités d’offloading, la limite de mémoire GPU et tout réglage de lot ou de tokens en vol. Dans les outils de service, le budget du cache peut être fixé explicitement ou dérivé d’une fraction de la mémoire disponible ; les deux cas doivent apparaître dans l’expérience.

Calculez une plage plutôt qu’un chiffre unique : poids observés ou estimés, cache KV pour la charge cible, réserve pour les temporaires et marge. Si le total dépasse la VRAM avant même la marge, écartez la combinaison. S’il tient de justesse, classez-la comme candidate à risque et testez-la sous charge maximale. S’il tient avec marge, ne l’approuvez pas avant d’avoir validé qualité et latence.

Choisissez au moins trois candidats répondant à des hypothèses différentes : le modèle souhaité en 8, 6 et 4 bits ; ou, lorsqu’un candidat n’a pas de sens, un modèle plus petit avec une précision plus élevée. Gardez constants le modèle de base, sa révision, le prompt, le contexte maximal, la limite de sortie, la graine lorsque c’est compatible, les paramètres de décodage, le matériel et la version du runtime. Modifier plusieurs variables à la fois empêche d’attribuer une différence à la quantification.

Le test minimal pour détecter une perte importante

Un test utile n’a pas besoin d’être immense, mais il doit être représentatif. Constituez un petit ensemble de cas couvrant le travail qui justifie le déploiement : extraction structurée, classification, synthèse de documents, assistance au code ou réponses sous contraintes, selon le cas. Incluez des entrées de longueur habituelle et certaines proches de la limite opérationnelle. Les longues entrées sont indispensables, car elles peuvent révéler à la fois des erreurs de mémoire et des pertes dans le suivi des instructions ou la récupération de détails.

Pour chaque cas, définissez ce qui sera validé avant d’exécuter le modèle. Certaines tâches permettent une comparaison exacte : schéma JSON valide, étiquettes autorisées, champs obligatoires, requête devant contenir des valeurs précises ou tests automatisés pour le code. D’autres nécessitent une revue humaine avec une grille : fidélité au document, couverture, absence d’inventions, respect du format et utilité. Ne confondez pas fluidité et exactitude.

Fixez un seuil explicite. Une configuration peut, par exemple, être écartée si elle échoue sur plus de cas critiques que le candidat de référence, si elle dégrade la validité structurelle au-delà d’une limite définie par l’équipe, ou si elle produit de nouvelles erreurs sur des données sensibles. Le seuil dépend du risque de l’application : il ne peut pas être déduit du nombre de bits. Une tâche de brouillon créatif peut tolérer davantage de variation qu’une extraction de données destinée à un traitement ultérieur.

Répétez les essais. Avec un décodage stochastique, plusieurs exécutions aident à distinguer la variation de génération d’une dégradation systématique. Avec un décodage déterministe, les répétitions restent utiles pour observer la stabilité des performances et les erreurs mémoire. Présentez les résultats par type de tâche et longueur d’entrée, pas seulement comme une moyenne globale. Une quantification apparemment équivalente en moyenne peut concentrer ses échecs sur les documents les plus longs ou la tâche la plus importante.

Trois profils opérationnels et leurs priorités

Sur un ordinateur portable doté d’un GPU limité, la priorité est généralement d’éviter une configuration qui dépend en permanence de la RAM système ou de l’offloading pour une expérience interactive. Commencez avec un contexte réaliste, une seule requête et un modèle ou une quantification laissant une marge. Si 4 bits est le seul moyen de charger le modèle, comparez aussi un modèle plus petit en 6 ou 8 bits. Ce dernier peut être plus stable et plus utile pour la tâche réelle, malgré un nombre inférieur de paramètres.

Sur une station de travail à un GPU, il y a davantage de marge pour arbitrer entre qualité, contexte et vitesse, mais la limite reste partagée entre poids, cache et temporaires. C’est un environnement adapté pour comparer 4, 6 et 8 bits sur le même corpus et déterminer s’il faut réserver de la VRAM aux longs contextes. Si vous prévoyez d’alterner sessions courtes et analyse documentaire, mesurez les deux profils : le résultat d’une courte conversation ne dimensionne pas le second.

Sur un serveur à concurrence modérée, l’unité de planification n’est plus le fichier du modèle, mais la capacité totale de tokens actifs. Le gestionnaire de cache et l’ordonnanceur de requêtes participent à la décision. Une configuration qui fonctionne pour une session peut épuiser la mémoire lorsque de longs préremplissages coïncident. Définissez les limites d’admission, la longueur maximale, la réserve de sortie et la concurrence ; testez ensuite des rafales et des mélanges de requêtes courtes et longues. Les métriques de file d’attente et les percentiles de latence sont plus instructifs que le meilleur résultat isolé.

Dans les trois profils, l’offloading est une option à déclarer, non une solution invisible. Il peut accroître la capacité apparente en déplaçant une partie des données, mais aussi modifier la latence et dépendre de la liaison entre CPU et GPU. Décidez à partir de mesures si ce compromis est acceptable pour le cas d’usage.

Signaux d’abandon et liste de contrôle avant adoption

Écartez une configuration lorsqu’elle produit des erreurs mémoire intermittentes, même si une brève démonstration fonctionne. L’intermittence indique souvent que la mémoire disponible dépend de la forme des requêtes, du pic de préremplissage, de la fragmentation ou d’autres charges du processus. Il faut également l’écarter si le runtime réduit silencieusement le contexte effectif, si le système n’est stable qu’à une charge inférieure à celle prévue ou si la marge observée disparaît lors d’essais répétés.

Analysez la dégradation de qualité par motif. Des erreurs concentrées sur l’extraction, les calculs, les champs obligatoires, le suivi des instructions ou les documents étendus pèsent davantage que des changements stylistiques lorsque ces tâches sont critiques. Une sortie apparemment raisonnable mais contenant des valeurs inventées ne doit pas être approuvée sur la seule base d’un score moyen. Vérifiez également la validité du format lorsque la sortie alimente un logiciel en aval.

Avant de fixer une option par défaut, vérifiez la confidentialité et l’exploitation. Exécuter l’inférence sur la machine ne garantit pas à lui seul qu’aucune donnée n’en sortira : téléchargements de modèles, télémétrie, journalisation des prompts, mises à jour de dépendances et outils d’observabilité sont des sujets distincts. Les données conservées et les communications effectuées par chaque composant doivent être vérifiées dans la configuration et l’environnement réseau choisis.

Le résultat final ne doit pas nécessairement être « la quantification la plus élevée possible ». Il peut s’agir de 6 bits pour un profil interactif, de 4 bits pour un profil d’analyse à grand contexte, ou de 8 bits pour une tâche où la perte détectée est inacceptable. Conservez les alternatives avec leur journal d’essais. Si le runtime, le matériel, le format des poids ou la charge de travail changent, mesurez de nouveau : la conclusion précédente cesse d’être une garantie.

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.