Évaluer les modèles locaux quantifiés : qualité et vitesse sur votre matériel

Pourquoi mesurer avant de choisir

La quantification réduit la mémoire nécessaire au chargement des poids, mais ne permet pas, à elle seule, de prévoir dans quelle mesure la qualité changera pour une tâche donnée. Le nombre de paramètres d’un modèle ne suffit pas non plus à anticiper sa vitesse sur votre machine : le processeur, la mémoire disponible, la configuration d’inférence, la longueur du contexte et la charge du système entrent aussi en jeu. Pour prendre une décision utile, mesurez les différentes options sur des entrées représentatives de l’usage réel.

Une étude de 2025 portant sur six modèles exécutés localement avec Ollama dans un système de recherche d’informations académiques a comparé la précision, la latence jusqu’au premier token et la vitesse de génération. Elle illustre une démarche empirique pertinente, mais ne démontre pas qu’un niveau de quantification GGUF précis préservera la qualité avec d’autres modèles, tâches ou machines. Le protocole ci-dessous applique ce principe à vos besoins : définissez d’abord ce que signifie « réussir » et les performances requises, puis comparez chaque configuration à une référence explicite.

1. Définir la tâche et la référence

Commencez par décrire le rôle du modèle en production : qui l’utilisera, quelles entrées il recevra, quelle sortie il devra produire, quelles erreurs sont coûteuses et quel délai est acceptable. Pour une extraction de champs, il faut mesurer la correspondance des valeurs. Pour des réponses fondées sur des documents, il faut vérifier leur fidélité aux sources. Pour la génération de code, il faut exécuter des tests plutôt que de juger uniquement si la réponse semble plausible. Regrouper des tâches différentes dans une note unique risque de masquer des défaillances importantes.

Préparez un jeu de tests représentatif de la distribution attendue : types d’entrées fréquents, cas limites, entrées ambiguës et exemples difficiles. Associez à chaque cas une référence vérifiable — réponse correcte, champs attendus, tests automatisés ou grille d’évaluation — et notez sa provenance. Séparez un jeu de développement, que vous pouvez utiliser pour ajuster les prompts ou les paramètres, d’un jeu d’évaluation que vous n’utiliserez pas pour optimiser le système à répétition. Vous réduirez ainsi le risque de choisir une configuration qui ne réussit que sur des exemples déjà vus.

2. Mesurer la qualité en fonction de la tâche

La qualité ne se résume pas à une seule métrique. Pour les réponses ayant une solution connue, calculez la précision ou le taux de réussite. Pour l’extraction, mesurez la correspondance exacte par champ et par enregistrement. Pour la classification, indiquez la précision et le rappel lorsque les faux positifs et les faux négatifs ont des coûts différents. Pour la génération ouverte, utilisez une grille explicite — par exemple, factualité, couverture, clarté et utilité — et conservez des exemples d’erreurs pour interpréter les scores. Une évaluation automatique ou fondée sur un autre modèle peut aider à traiter de nombreux cas, mais ne doit pas être considérée comme une référence absolue sans avoir vérifié sa pertinence pour cet usage.

Évaluez le format séparément lorsque le système exige du JSON, une structure fixe, un appel d’outil ou une longueur maximale. Vérifiez que la sortie passe dans le véritable validateur et respecte les champs obligatoires, les types, les valeurs autorisées et les autres contraintes. Si l’échantillonnage n’est pas déterministe, mesurez aussi la cohérence entre plusieurs exécutions : une seule réponse correcte ne prouve pas la fiabilité du système. Pour les tâches à risque, comptez explicitement les erreurs graves et définissez une règle de refus ou de révision humaine avant de commencer l’évaluation.

3. Mesurer la vitesse, la latence et la mémoire

Mesurez au minimum la latence jusqu’au premier token et la vitesse de génération en tokens par seconde. La première indique le temps d’attente avant l’affichage d’une réponse ; la seconde décrit la cadence de production qui suit. Ajoutez le temps total nécessaire à la réponse, car une sortie longue peut prendre du temps même si son débit est élevé. Précisez l’outil utilisé pour chaque mesure et ce qu’elle inclut : chargement initial du modèle, préparation du prompt, traitement de l’entrée ou génération seulement.

Notez la mémoire utilisée pendant l’inférence et la longueur du contexte testé. La taille du fichier GGUF ne correspond pas automatiquement à la mémoire totale nécessaire : le contexte, le cache d’attention, le runtime et le système d’exploitation peuvent aussi jouer un rôle. Comparez le même modèle et la même tâche avec une limite de contexte, des paramètres de génération et un matériel identiques. Si une configuration ne tient pas en mémoire et recourt au stockage de masse ou à un autre mode d’exécution, notez-le : la comparaison n’est alors plus équivalente.

4. Effectuer une comparaison contrôlée

Pour attribuer les écarts à la configuration évaluée, gardez constants le jeu d’entrées, le modèle de prompt, la limite de tokens, la température et les autres paramètres pertinents. Notez le nom et la révision du modèle, la provenance du fichier GGUF et son niveau exact de quantification. Consignez également les versions d’Ollama ou de LM Studio, le système d’exploitation, le processeur, l’accélérateur, la mémoire et les options de déchargement des couches. Précisez dans le protocole si le modèle était déjà chargé ou si le temps de chargement initial est inclus.

Effectuez d’abord une passe de préparation si vous devez charger et stabiliser le modèle. Ne la mélangez pas aux mesures habituelles, sauf si le démarrage fait partie des exigences opérationnelles. Répétez chaque test plusieurs fois et indiquez la médiane ainsi que la variabilité, plutôt que la meilleure exécution. Si l’application produit des sorties stochastiques, fixez la graine lorsque l’outil le permet, ou évaluez plusieurs échantillons en appliquant la même méthode. Alternez l’ordre des configurations si la température ou la charge système peut évoluer au cours de la session. Reproduisez enfin des conditions proches du déploiement, et pas seulement celles d’une machine fraîchement redémarrée.

5. Choisir entre le niveau de quantification et la taille du modèle

Commencez par vérifier si chaque option respecte les exigences de qualité et de performance définies à l’avance. Écartez les configurations qui échouent à un critère critique, même si elles obtiennent de bons résultats sur une autre métrique. Parmi celles qui passent, comparez le temps total, la latence initiale, la mémoire et la stabilité du format. Une quantification plus agressive d’un grand modèle peut être préférable si elle préserve la qualité nécessaire et tient dans le matériel. Si elle réduit la précision dans une tâche sensible, un modèle plus petit avec une quantification plus conservatrice peut donner de meilleurs résultats. Aucune règle générale ne permet de trancher sans mesure.

Il est également possible que la meilleure option soit un modèle différent de celui envisagé au départ, ou que le flux confie les tâches simples à un modèle rapide et réserve un modèle plus performant aux cas difficiles. L’étude académique menée avec Ollama, mentionnée plus haut, a relevé des différences de rapidité et de précision entre des modèles dans son propre système RAG ; ses résultats ne garantissent pas les performances d’une autre configuration. Pour justifier une décision technique, conservez les résultats par type de tâche et expliquez les compromis acceptés par l’équipe. Si deux options sont très proches, tenez compte de l’incertitude des mesures et répétez le test avant de conclure.

6. Limites et bonnes pratiques

Un jeu de tests réduit peut manquer des erreurs rares ; un jeu trop proche des exemples de développement peut favoriser la configuration ajustée à ces cas. Un score agrégé peut également masquer des défaillances liées à la langue, à la longueur, au type de document ou à une classe minoritaire. Examinez les résultats ventilés et conservez des exemples d’erreurs. Si un écart reste dans la variabilité observée entre les exécutions, ne le présentez pas comme une amélioration concluante sans effectuer davantage de répétitions ou obtenir des éléments complémentaires.

Les résultats d’une étude publiée dans un contexte de RAG académique portent sur cette recherche et sa configuration ; ils ne constituent ni une évaluation de GGUF ni une recommandation universelle. De même, les chiffres génériques sur une perte de qualité supposément fixe pour chaque niveau de quantification ne remplacent pas un test du modèle et de la tâche concernés. Documentez la provenance des fichiers, évitez de saisir des données personnelles dans les prompts de test sans autorisation et prévoyez une révision humaine ou des mécanismes de refus lorsqu’une erreur pourrait causer un préjudice. Après le déploiement, examinez régulièrement un échantillon d’usage réel et relancez le protocole si le modèle, le runtime, le matériel ou les types d’entrées changent.

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.