Comparer deux modèles locaux avec un seul chiffre de vitesse conduit facilement à une mauvaise conclusion. Un modèle peut générer rapidement après une longue attente, un autre répondre immédiatement puis avancer plus lentement. Un troisième peut être rapide sur une question courte et s’effondrer avec un document volumineux.
Un benchmark IA locale utile doit donc mesurer plusieurs étapes séparément : chargement du modèle, traitement du prompt, arrivée du premier token, génération continue, mémoire consommée et qualité de la réponse. Le but n’est pas de battre un record, mais de savoir quel réglage convient réellement à son PC et à son usage.
Ce guide propose un protocole, pas les résultats d’un essai effectué sur une machine de l’auteur. Les sources ont été revérifiées le 22 octobre 2026. Pour une première installation plutôt qu’une comparaison de performances, commence par tester une IA locale sans acheter de matériel.
Pourquoi le nombre de tokens par seconde ne suffit pas
Le débit de génération indique combien de tokens le modèle produit chaque seconde une fois la génération engagée. C’est utile pour estimer si la réponse se lit naturellement, mais ce chiffre ne décrit pas tout ce qui se passe avant. Il ne dit pas combien de temps le logiciel a passé à charger le fichier, à lire le prompt ou à remplir le cache de contexte.
L’outil officiel llama-bench de llama.cpp distingue justement le traitement du prompt et la génération de texte. Sa documentation précise aussi que les résultats sont répétés, moyennés et accompagnés d’un écart-type. C’est beaucoup plus informatif qu’une capture isolée choisie parce qu’elle affiche le meilleur nombre.
Attention à son périmètre : la documentation indique que llama-bench exclut le temps de tokenisation et celui de l’échantillonnage. Son débit ne remplace donc pas une mesure de bout en bout dans ton application. Note séparément l’attente entre l’envoi de la question et l’apparition du premier token visible.
Les six mesures que je conserve
- Temps de chargement : durée entre le lancement et le moment où le modèle est prêt.
- Traitement du prompt : vitesse à laquelle le modèle absorbe les tokens d’entrée.
- Latence du premier token : attente ressentie avant que la réponse commence.
- Débit de génération : tokens produits par seconde après le démarrage.
- Mémoire maximale : VRAM et RAM réellement utilisées pendant le test.
- Résultat utile : réponse correcte, complète et conforme à la consigne.
La documentation des métriques de Text Generation Inference illustre bien cette séparation : durée totale de la requête, temps passé en file d’attente, tokens générés, longueur d’entrée et temps moyen par token sont des mesures différentes. Même si l’on n’utilise pas TGI chez soi, cette décomposition donne une bonne grille de lecture.
Fixer le matériel et le logiciel avant de comparer
Je commence par noter le processeur, la carte graphique, la quantité de RAM et de VRAM, le système, la version du moteur d’inférence et le pilote. Une mise à jour peut changer les performances. Comparer un résultat obtenu avec un ancien moteur à un autre mesuré après une optimisation n’isole plus l’effet du modèle.
Je conserve aussi le même mode d’alimentation et je ferme les applications lourdes. Sur un portable, je précise s’il est branché. La température compte : un premier passage à froid et le cinquième passage après plusieurs minutes peuvent diverger si le processeur ou le GPU réduit sa fréquence.
Utiliser exactement le même modèle et la même quantification
Le nom commercial d’un modèle ne suffit pas. Il faut relever le fichier précis, sa quantification, sa taille, le contexte demandé et la part déchargée sur le GPU. Un Q4 et un Q8 ne sollicitent pas la mémoire de la même manière et peuvent produire des réponses différentes. Mon article sur la quantification des LLM en 4 ou 8 bits explique ce que l’on gagne et ce que l’on perd.
Le contexte doit également rester identique. Une fenêtre immense augmente le cache mémoire même si le prompt de test est court. Pour préparer une comparaison réaliste, je pars d’abord du guide sur la VRAM, la RAM et le contexte d’un LLM local, puis je choisis une valeur cohérente avec l’usage quotidien.
Construire trois prompts au lieu d’un seul
Un test unique favorise parfois un type de tâche. Je préfère une petite série stable que je peux rejouer après chaque changement :
- Prompt court : une question factuelle ou une reformulation de quelques lignes, pour mesurer la réactivité.
- Prompt long : un document connu suivi de questions précises, pour observer le traitement de l’entrée.
- Tâche structurée : un tableau, une liste de contrôles ou un petit format JSON, pour vérifier que la vitesse ne détruit pas le respect des consignes.
Je fixe aussi le nombre maximal de tokens générés. Une réponse qui s’arrête à 80 tokens ne doit pas être comparée à une autre autorisée à en produire 500 sans le mentionner. Pour réduire la variabilité, je conserve les mêmes paramètres d’échantillonnage ou j’utilise une seed fixe quand le moteur le permet. Mon guide sur la température, le top-p et la seed d’une IA locale détaille cette méthode.
Faire un passage à froid et plusieurs passages à chaud
Le passage à froid inclut le chargement du modèle depuis le stockage. Il représente le lancement après un redémarrage ou un changement de modèle. Les passages à chaud réutilisent des données déjà présentes en mémoire et mesurent mieux l’usage continu. Mélanger les deux sans les étiqueter rend le résultat illisible.
Je réalise au minimum cinq répétitions à chaud, puis je conserve la moyenne et la dispersion. Si une mesure est très éloignée des autres, je cherche la cause au lieu de la supprimer silencieusement : analyse antivirus, téléchargement, chauffe, manque de mémoire ou autre application active.
Mesurer la mémoire au pic, pas seulement au repos
Un modèle peut tenir au chargement puis provoquer un basculement vers la RAM pendant un prompt long. Je relève donc la VRAM et la RAM au repos, après chargement, pendant le traitement du plus long prompt et pendant la génération. Une petite marge est indispensable pour le système et l’interface graphique.
Quand le GPU est saturé et que des couches repartent vers le processeur, la réponse peut rester fonctionnelle mais devenir beaucoup moins fluide. Ce n’est pas un échec si le but est d’exécuter ponctuellement un gros modèle ; c’est en revanche un mauvais réglage pour un assistant utilisé toute la journée.
Ne pas sacrifier la qualité pour un graphique flatteur
Le modèle le plus rapide n’est pas forcément le plus utile. Pour chaque prompt, je vérifie les faits attendus, les omissions, le format et les inventions. Une réponse très rapide qui oublie la moitié des contraintes coûte ensuite du temps de correction.
J’ajoute une note simple sur cinq pour la conformité à la consigne et je conserve le texte produit. Cette archive permet de revoir une décision quelques semaines plus tard. Elle complète la sauvegarde du modèle et des réglages expliquée dans mon article sur la sauvegarde d’une IA locale.
Un tableau minimal pour comparer proprement
| Test | Mesure à conserver | Ce qu’elle révèle |
|---|---|---|
| Démarrage à froid | Temps de chargement | Confort lors d’un changement de modèle |
| Prompt court | Premier token et tokens/s | Réactivité d’une conversation |
| Prompt long | Traitement du prompt et mémoire | Capacité à travailler sur des documents |
| Réponse structurée | Conformité et erreurs | Utilité réelle au-delà de la vitesse |
| Cinq répétitions | Moyenne et dispersion | Stabilité du réglage |
Ma règle : comparer un seul changement à la fois
Si je change à la fois le modèle, la quantification, le contexte, le nombre de couches GPU et le prompt, je ne sais plus expliquer le résultat. Je pars d’une configuration de référence, je modifie une variable, puis je rejoue exactement la même série.
Le bon benchmark n’est pas celui qui produit le plus grand chiffre. C’est celui que l’on peut reproduire, comprendre et relier à un besoin. Avec la latence, le débit, la mémoire et la qualité dans le même tableau, choisir une IA locale devient une décision technique plutôt qu’une compétition de captures d’écran.
