Choisir une quantification sur ses résultats, pas sur ses bits.

Décrire la variante au-delà de son nombre de bits

Nommez la méthode, son implémentation, sa version et la révision exacte de l’artefact. Deux variantes en quatre bits peuvent employer des représentations, groupes, métadonnées et kernels différents. Séparez le format de stockage des poids de celui des opérations de calcul. Notez aussi les modules conservés à une autre précision et tout déport vers le CPU.

Dans bitsandbytes, des couches linéaires quantifiées remplacent certaines couches ordinaires ; les autres modules suivent leur dtype configuré. Ce comportement ne décrit donc pas à lui seul le pic du processus. Lisez la configuration effective après chargement, puis vérifiez que la variante réalise bien le traitement attendu plutôt qu’un repli logiciel différent.

Sources techniques : Hugging Face Transformers 5.17 — couches quantifiées et autres dtypes

Séparer calibration et évaluation

Certaines méthodes utilisent des exemples pour préparer la quantification. La procédure GPTQ documentée dans Transformers demande notamment un jeu de calibration et un tokenizer. Ce jeu participe à la fabrication de l’artefact : il ne constitue pas une preuve indépendante de qualité. D’autres méthodes suivent un autre chemin ; ne supposez pas qu’un même protocole de calibration s’applique à tous les formats.

Réservez les exemples de calibration dans les données autorisées pour préparer le modèle, puis consignez identifiants, provenance, longueurs et transformation appliquée. Gardez la validation pour choisir les réglages, et le test final pour la confirmation. Si vous choisissez plusieurs jeux de calibration après avoir comparé leurs scores, cette recherche fait partie du développement et doit être inscrite au bilan.

Sources techniques : Hugging Face Transformers 5.17 — calibration d’une quantification GPTQ · Construire des partitions selon leur rôle

Calculer une borne de poids sans la vendre comme un pic

Prenons un modèle fictif de trois milliards de paramètres, tous stockés au même nombre de bits. Le volume brut se calcule par paramètres × bits / 8. À 16 bits, on obtient 6 milliards d’octets ; à 8 bits, 3 milliards ; à 4 bits, 1,5 milliard. Ces nombres sont une arithmétique illustrative, pas les tailles observées d’un artefact ni les besoins d’un modèle exécuté.

La différence brute entre 16 et 4 bits est de 4,5 Go, soit environ 4,191 Gio. Elle exclut échelles, métadonnées, modules non quantifiés, cache et temporaires. Elle permet de formuler une hypothèse de mémoire à vérifier, sans prédire une division par quatre du pic. Le dossier mémoire explique comment séparer les phases et interpréter les compteurs.

Sources techniques : NIST — préfixes binaires et décimaux · IteraGPU — estimations et pics mémoire

Changer les poids avant de changer le cache

Commencez par une référence dont vous connaissez le comportement. Comparez ensuite les variantes de poids avec le même cache, les mêmes longueurs, le même batch ou la même concurrence. Si vous changez aussi ces paramètres, vous comparez des configurations complètes : annoncez-le et n’attribuez pas tout l’écart à la quantification des poids.

Le cache KV peut lui-même être quantifié lorsque le modèle et le moteur le permettent. Il s’agit d’un choix distinct. La documentation Transformers signale notamment qu’un cache quantifié peut pénaliser la latence pour des contextes courts lorsqu’il reste assez de mémoire. Testez ce second changement dans une série séparée ; davantage de mémoire économisée ne garantit pas un meilleur délai.

Sources techniques : Hugging Face Transformers 5.17 — cache KV quantifié et compromis de latence

Exemple de règle qualité : une petite baisse peut rester inadmissible

Voici une illustration de décision, sans exécution de modèle. Un projet évalue 200 documents et définit avant les essais une perte maximale d’un point de pourcentage face à la référence. Il exige aussi au moins 90 % de réussite sur 20 documents critiques inclus dans ces 200. Un document est accepté uniquement si tous ses champs requis sont corrects.

Les valeurs fictives ci-dessous rendent A admissible sur ces deux règles : 94 % au lieu de 95 %, et 18/20 sur le groupe critique. B échoue sur les deux. On ne peut pas encore déclarer A gagnante : ni pic mémoire ni durée ne sont donnés. De plus, les totaux ne montrent pas quels documents ont changé ; examinez les erreurs appariées pour détecter de nouvelles régressions importantes.

Sources techniques : Examiner les erreurs plutôt que le seul total

Exécuter une comparaison dont les écarts s’expliquent

Préparez d’abord le contrat de comparaison, puis les fichiers de résultats. Le protocole suivant est à réaliser sur votre charge ; les chiffres précédents ne le remplacent pas. Si une variante ne charge pas ou ne possède pas les opérateurs requis, conservez cet échec comme une information de compatibilité.

• Figez corpus, références, modèle, tokenizer, prompt et règles de sortie ; gardez les cas longs et difficiles identifiables.
• Consignez calibration, artefact exporté et configuration effective. Vérifiez les appareils utilisés et les éventuels transferts CPU/GPU.
• Séparez fabrication, chargement, échauffement et traitement stabilisé. Utilisez les mêmes bornes de mesure et conservez les répétitions brutes.
• Relevez le pic par appareil et par phase ; gardez allocated et reserved séparés. Ne sommez pas ces compteurs et ne soustrayez pas leurs maxima indépendants.
• Évaluez le format, le contenu et les sous-groupes convenus, puis rapprochez les erreurs par identifiant.
• Rechargez l’artefact retenu dans un nouveau processus et rejouez un contrôle défini. Un résultat obtenu avant export ne valide pas automatiquement le rechargement.

Sources techniques : Mesurer correctement la mémoire · Définir les répétitions et le chronométrage

Relier le compromis au coût engagé

Une économie de mémoire peut élargir les configurations envisageables, permettre davantage de concurrence ou simplement laisser de la marge. Elle ne diminue pas automatiquement la dépense. Si la période, les lots réservés et les livrables acceptés restent identiques, le coût du forfait reste identique, même si un passage est plus rapide.

Incluez dans le calendrier la calibration éventuelle, la quantification, l’évaluation, les tentatives rejetées et le rechargement. Comparez ensuite les forfaits complets de 3, 7 ou 30 jours entre les options qui satisfont vos critères. Le ratio par corpus utile ne se calcule qu’avec des corpus réellement terminés et acceptés ; les répétitions de chronométrage ne créent pas de nouveaux livrables.

Si une seule location sert à comparer plusieurs variantes, son montant est une dépense commune de campagne. Ne facturez pas mentalement le forfait entier à chaque variante puis n’additionnez pas ces montants comme des dépenses réelles distinctes. Pour attribuer une part analytique, annoncez une convention ; elle ne change pas le total engagé.

Sources techniques : IteraGPU — forfait entier et coût d’une expérience

Conclure avec une configuration et ses limites

La décision finale nomme l’artefact, l’environnement, la charge couverte, le critère qualité franchi et la contrainte améliorée. Si les variantes sont proches, conservez cette incertitude et privilégiez un choix que vous savez recharger et expliquer. Le nombre de bits n’est pas à lui seul un ordre de préférence.

Une conclusion sur un corpus court ne s’étend pas automatiquement aux longs contextes, à une autre langue ou à davantage de requêtes simultanées. Une quantification retenue pour l’inférence ne définit pas non plus les paramètres entraînables d’un fine-tuning. Gardez ces questions séparées et confirmez la variante choisie sur le test tenu à part.

Questions pratiques