Un benchmark de LLM local paraît simple jusqu’à ce que l’on demande ce qu’il mesure réellement. Une valeur en jetons par seconde ne décrit pas, à elle seule, l’expérience d’utilisation. Il faut au minimum distinguer le préremplissage de la génération, la longueur du contexte, la quantification, le moteur d’inférence et la mémoire disponible.

Deux vitesses, deux usages

Le préremplissage est la phase où le modèle lit les jetons du prompt. Il est important pour l’analyse de documents, la recherche augmentée et les conversations longues. La génération produit ensuite la réponse, jeton après jeton ; c’est elle qui détermine le plus directement la sensation de réactivité dans une conversation.

Comparer deux mesures de génération sans préciser le prompt, la quantification et le backend est donc trompeur. Un modèle peut être excellent sur un prompt court et se comporter très différemment avec un contexte long ou une sortie structurée.

Les paramètres actifs comptent souvent davantage que le total

Les modèles Mixture-of-Experts (MoE) rendent les comparaisons de taille moins intuitives. Ils possèdent beaucoup de paramètres au total, mais n’en activent qu’une fraction à chaque jeton. Cette propriété peut améliorer le débit lorsque la bande passante mémoire est la contrainte principale.

À l’inverse, un modèle dense mobilise ses poids à chaque génération. Il peut rester le meilleur choix pour une tâche donnée, mais sa taille nominale ne permet pas de prédire sa vitesse. L’architecture, le nombre de paramètres actifs et le format des poids sont plus instructifs qu’un seul chiffre sur l’étiquette.

Lire les résultats sans leur faire dire trop

Un tableau de vitesse devrait indiquer :

  • la version exacte du moteur d’inférence ;
  • le format et la quantification des poids ;
  • la longueur du prompt et de la sortie ;
  • l’état du cache et le temps de chargement ;
  • la méthode de mesure du préremplissage et de la génération.

Le temps total est particulièrement fragile : il peut inclure le chargement du modèle, la compilation de shaders ou d’autres coûts qui ne se répètent pas dans une session déjà active.

La qualité reste une métrique séparée

Le modèle le plus rapide n’est pas automatiquement celui qui résume le mieux, respecte le mieux un format ou appelle correctement des outils. Pour une sélection utile, il faut confronter le débit à des tâches représentatives : extraction d’information, rédaction, code, appels d’outils et robustesse sur des prompts plus longs.

Les chiffres de performance sont des observations de configuration, pas des vérités universelles. Ils sont néanmoins très utiles quand ils sont reproductibles et accompagnés de leur contexte. C’est ainsi qu’un benchmark devient un outil de décision plutôt qu’un concours de nombres.

Sources