Ce que MakoBench teste, et ce qu’il ne teste pas

Aller à : CrucibleForge sur GitHub

MakoBench a une seule mission : vous indiquer à quel point un modèle de texte général est performant dans deux domaines pour lesquels nous utilisons ces modèles. Nous précisons clairement ce que cela couvre, car un score n’a de sens que pour un modèle que les tests sont conçus pour évaluer.

Ce que nous testons

Nous testons un modèle dont l’entrée est du texte, dont la sortie principale est également du texte, et qui répond à des instructions ou à des conversations de type chat. Cela inclut :

• les modèles de chat et d’instruction de toute taille, exécutés en local ou via une API hébergée ;
• les modèles de raisonnement, exécutés selon les instructions des créateurs, avec le même budget de sortie que tous les autres modèles ;
• les modèles de programmation capables également de dialoguer. Ils subissent à la fois les tests de code et les tests de chat ; un score faible en chat n’est qu’un résultat, pas une raison de les écarter ;
• les versions non censurées, « désencensurées » ou adaptées au jeu de rôles des modèles susmentionnés ;
• les modèles de chat multimodaux (texte et image), testés uniquement sur les tests textuels. Leur ligne indique « suite de tests textuels uniquement », car nous n’avons pas évalué leurs capacités avec des images.

Les deux types de tâches sont Code et Chat ; chacun rapporte 10 points sur les tests standards. Le score total est la somme des deux. Le test « Code » consiste à écrire des fonctions Python fonctionnelles, à prédire le résultat de fragments de code, ainsi qu’à corriger des bugs avec l’aide d’outils. Le test « Chat » implique le jeu de rôles et la conversation : mémoriser des faits, maintenir un personnage et respecter les consignes d’écriture. Il ne s’agit pas d’un simple test de réponse à des questions ou de suivi d’instructions ponctuelles ; un modèle peut donc être un excellent assistant tout en affichant un score « Chat » moyen. Un test distinct consacré à la fiction pour adultes dispose de son propre onglet, le dernier, et ne contribue jamais au score total.

Ce que nous ne testons pas

• Les modèles qui ne produisent pas de texte. Générateurs d’images, de vidéos, de sons ou de musique, ainsi que générateurs 3D, CAD ou de scènes. Les tests ne peuvent pas évaluer une image ou un maillage ; tout score obtenu serait donc sans signification.
• Les modèles qui produisent un vecteur ou une étiquette. Modèles d’embedding, rerankers, classificateurs, ainsi que modèles de sécurité, de filtrage ou de récompense.
• Les outils textuels spécialisés dans une seule tâche. Modèles de traduction, générateurs de légendes, outils de reconnaissance vocale ou d’OCR, ainsi que modèles entraînés uniquement pour résumer ou extraire des informations. Ils excellent dans un domaine très précis que Code et Chat ne mesurent pas.
• Les checkpoints de base. Un modèle dépourvu de template de chat ne peut pas suivre les instructions envoyées par le test suite.
• Les modèles que CrucibleForge ne peut pas exécuter. Le moteur vérifie d’abord qu’il peut communiquer correctement avec un modèle avant de lui attribuer un score. En cas d’échec de cette vérification, le modèle est rejeté.

Lorsqu’une demande relève de l’une de ces catégories, nous la rejetons en indiquant une brève explication sur la page des votes ; le modèle n’est alors jamais soumis au vote final. Nous ne rejetons jamais un modèle simplement parce qu’il est trop volumineux ; ce cas est traité ci-dessous. Les modèles que nous sélectionnons automatiquement doivent également être sous une licence permissive et non restreinte ; toutefois, nous pouvons toujours en ajouter un manuellement.

Quelles conditions doivent être remplies pour qu’une ligne soit classée ?

• L’ensemble des tests doit avoir été exécuté. Un modèle avec un taux de couverture partiel affiche ses chiffres, mais ne présente ni total ni classement.
• Le contrôle de compatibilité doit être réussi. En cas d’échec, il est probable que la configuration de CrucibleForge mesure le modèle de manière incorrecte. La ligne reste visible, marquée d’un symbole d’avertissement et du mot « provisoire » ; elle n’a pas de classement, et nous la relançons.
• Une seule ligne par modèle. Le format de quantification standard pour les modèles locaux est Q8_0. Si Q8_0 ne convient pas à notre configuration, nous utilisons Q6, puis Q5 ; cette information figure dans la ligne correspondante. Nous ne descendons jamais en dessous de Q5. Un autre format de quantification, ou un niveau de service plus rapide pour le même modèle hébergé, apparaît sous la ligne principale en tant que variante supplémentaire et n’est pas classé.
• Les lignes antérieures utilisant des formats inférieurs à Q5 restent visibles. Leur format de quantification est indiqué, accompagné d’une note « en dessous de Q5 » dans les détails de la ligne. Nous retestons uniquement un modèle avec le format standard lorsqu’il se classe premier : soit sur son tableau spécifique (Main Bench ou le tableau consacré à la fiction pour adultes), soit dans une colonne principale, soit dans sa catégorie de taille.
• Les lignes relatives aux modèles hébergés indiquent la date du test. Un fournisseur peut modifier ou retirer un modèle portant le même nom ; par conséquent, chaque ligne hébergée représente un instantané à une date donnée.

Ce que notre rig peut tester, et ce qui nécessite un financement

MakoBench fonctionne sur une seule machine domestique dotée de quatre cartes graphiques : deux RTX 5090 et deux RTX 3090, soit au total 112 Go de mémoire vidéo. Nous testons chaque modèle en format Q8_0 ; nous passons ensuite aux formats Q6 puis Q5 uniquement si le format Q8_0 ne convient pas. En pratique, cela signifie que nous pouvons tester des modèles comptant jusqu’à environ 135 milliards de paramètres, avec un contexte de 32 000 tokens.

Les modèles plus volumineux sont indiqués comme Impossible à tester en local, sans jamais être rejetés pour autant. Si un service hébergé peut exécuter le modèle en 8 bits ou mieux, les utilisateurs peuvent financer le test. L’objectif de financement correspond à environ quatre fois le coût maximal que nous estimons pour l’exécution du test ; en effet, un test à distance nécessite également des préparatifs, éventuellement une deuxième tentative, ainsi que la vérification et l’évaluation sur notre propre machine. Les frais de paiement sont également déduits de ce montant. S’il n’existe aucun service hébergé proposant le modèle, la ligne indique « Trop volumineux pour être testé pour l’instant » sans objectif de financement ; les votes restent toutefois comptabilisés, et nous testerons le modèle si cela devient possible. Si un test financé ne peut pas être exécuté, ou si le modèle s’avère compatible avec notre rig, les fonds serviront à effectuer le test proprement dit. L’argent ne modifie jamais un score. Un don lié à un modèle le fait simplement monter dans son groupe de classement, sans influencer son score.

Pourquoi tant de soin ?

Un benchmark qui classe tout finit par classer des éléments que les tests ne peuvent pas mesurer ; un score dénué de toute signification est pire qu’aucun score du tout. En limitant la liste aux modèles adaptés aux tests et en ne classant que des mesures pertinentes, on permet de comparer deux scores entre eux. Pour en savoir plus sur la manière dont les scores sont calculés et interprétés, consultez Comment fonctionne MakoBench ; si vous souhaitez faire tester un modèle, utilisez la page de vote.