Évaluer un modèle sur des classements généralistes vous indique sa capacité à traiter la culture générale et les tests standardisés. Cela ne vous dit presque rien sur la manière dont il raisonnera face aux problèmes complexes et contraints auxquels vos systèmes de production sont réellement confrontés. Avant de déployer tout grand modèle de langage auprès de vos utilisateurs, vous avez besoin d'un banc d'essai qui sollicite les schémas cognitifs spécifiques exigés par votre application. Les benchmarks de raisonnement sont le terrain où les modèles se distinguent des simples chatbots.

Ce guide vous accompagne dans la création d'un benchmark de raisonnement ciblé à partir de zéro. Vous comparerez trois architectures distinctes : DeepSeek R1 671B MoE, Llama 3.3 70B et Qwen 3 32B. Plutôt que de bricoler des clusters de GPU, vous exécuterez les trois via Oxlo.ai. Pour l'évaluation, vous utiliserez Kimi K2.6 comme juge pour noter les résultats sur la clarté du raisonnement, l'exactitude et la qualité du code.

Pourquoi le raisonnement échoue en premier

Les échecs en production ressemblent rarement à des erreurs grammaticales ou à des refus. Ils se manifestent par des erreurs logiques subtiles. Un modèle peut générer une prose assurée tout en comprenant mal une contrainte, en sautant une étape ou en modifiant silencieusement une variable en cours de route. Les benchmarks publics privilégient souvent l'étendue à la profondeur, de sorte qu'un modèle peut obtenir un bon score sans jamais résoudre un problème combinatoire complexe.

Un benchmark ciblé force le passage. Il impose à chaque modèle la même tâche d'optimisation sous contraintes, exige une chaîne de pensée traçable et mesure si la solution générée respecte réellement les règles. Si un modèle ne peut pas raisonner de manière cohérente sur les mathématiques discrètes, il ne saura pas non plus gérer de manière fiable votre allocation de stocks, votre moteur de planification ou votre routeur de ressources.

Les modèles et la plateforme

DeepSeek R1 671B MoE utilise une conception de type mixture-of-experts. Seule une fraction de ses 671 milliards de paramètres s'active pour un token donné, ce qui modifie la courbe coût-performance et parfois la texture de son raisonnement. Llama 3.3 70B est un modèle dense, et Qwen 3 32B se situe à une échelle plus petite avec de solides capacités multilingues et de codage. Comparer ces trois modèles vous permet de savoir si la qualité du raisonnement suit le nombre total de paramètres, le nombre de paramètres actifs ou la méthodologie d'entraînement.

Oxlo.ai héberge ces modèles via une API unifiée. Vous n'avez pas à gérer l'infrastructure d'inférence ni à négocier des accords séparés avec différents fournisseurs. La plateforme utilise également une tarification par requête plutôt que par token. Un prompt système de deux mille mots coûte exactement la même chose qu'une seule ligne concise. Ce détail compte plus qu'il n'y paraît. Cela signifie que vous pouvez rédiger des instructions exhaustives, inclure des exigences de formatage détaillées et intégrer des exemples de few-shot sans voir les coûts des tokens d'entrée s'envoler. Vous payez pour l'appel, pas pour la verbosité.

Vous aurez besoin de Python 3.10 ou plus récent, de la bibliothèque Python OpenAI et d'une clé API Oxlo.ai.

Étape 1 : Se connecter au point de terminaison

Comme Oxlo.ai expose une API compatible avec OpenAI, l'intégration est simple. Dirigez le SDK OpenAI vers l'URL de base d'Oxlo, insérez votre clé API et vérifiez la connexion avec une requête légère vers DeepSeek R1. Ne négligez pas cette vérification de cohérence. Confirmez la latence, confirmez que l'identifiant du modèle est reconnu et assurez-vous que votre environnement peut diffuser (stream) ou mettre en mémoire tampon (buffer) le format de réponse que vous comptez stocker. Une fois la connexion établie, vous disposez d'un client unique capable d'interroger les trois modèles en changeant simplement une chaîne de caractères.

Étape 2 : Concevoir la tâche

Choisissez un problème qui exige une logique étape par étape et qui possède une réponse objectivement mesurable. Le bin-packing (mise en bacs) fonctionne exceptionnellement bien. C'est un problème NP-difficile, ce qui signifie que les heuristiques gloutonnes échouent de manière prévisible, et cela force le modèle à suivre plusieurs contraintes simultanément. Des objets de tailles variables doivent entrer dans des bacs de capacité fixe sans dépasser les limites.

Formulez le prompt de manière à ce que le modèle doive accomplir deux tâches : décrire son processus de raisonnement, puis fournir un code Python fonctionnel qui résout l'instance. Utilisez un prompt système qui exige explicitement que le modèle affiche sa chaîne de pensée (chain-of-thought) avant d'écrire le moindre code. C'est particulièrement important pour DeepSeek R1, qui est optimisé pour des traces de raisonnement étendues. Vous voulez voir si le modèle réfléchit aux vérifications de capacité ou s'il se contente de faire de l'association de motifs (pattern-matching) à partir de ses données d'entraînement. Une bonne tâche doit être suffisamment complexe pour déjouer les réponses types.

Étape 3 : Exécuter le benchmark

Soumettez le même prompt à DeepSeek R1, Llama 3.3 70B et Qwen 3 32B. Capturez l'intégralité des réponses textuelles, pas seulement les blocs de code finaux. Stockez-les avec des horodatages et des identifiants de modèle. Puisque Oxlo.ai facture à la requête, vous n'avez pas besoin de tronquer votre prompt ou de supprimer des instructions de clarification pour économiser de l'argent. Vous pouvez vous permettre d'être précis. Cette stabilité vous permet d'itérer sur la conception du prompt sans anxiété liée au coût, ce qui mène à des expériences plus propres et à des résultats plus reproductibles.

Exécutez chaque modèle plusieurs fois si votre budget le permet. Les modèles de raisonnement peuvent varier selon les générations stochastiques, et vous voulez savoir si un score élevé représente une compétence constante ou un échantillon chanceux.

Étape 4 : Évaluer avec un juge LLM

Le scoring manuel ne passe pas à l'échelle, mais les grilles de notation numériques seules manquent de nuance. Le juste milieu est un juge LLM. Ici, vous utiliserez Kimi K2.6. Soumettez-lui le problème original, la grille de notation et chaque réponse candidate. Demandez-lui d'évaluer trois dimensions spécifiques :

  • Clarté du raisonnement : L'explication suit-elle réellement la logique, ou se contente-t-elle de généralités ?
  • Exactitude : La solution proposée respecte-t-elle toutes les contraintes énoncées ?
  • Qualité du code : Le code Python est-il propre, exécutable et exempt de bugs évidents ?

Instruisez le juge de retourner les scores au format JSON. Une sortie structurée rend la comparaison des résultats (diff), le traçage des tendances et l'alimentation de l'automatisation en aval triviaux. Gardez le prompt du juge strict. Si vous lui donnez une instruction vague comme « note la réponse », vous obtiendrez des résultats vagues. Au lieu de cela, définissez ce qui constitue une solution de bin-packing correcte. Les capacités ne doivent pas être dépassées. Chaque élément doit être assigné. Le code doit être syntaxiquement valide. Plus vos critères sont concrets, plus vos notes deviennent fiables.

Vérifiez toujours le juge ponctuellement. Si Kimi K2.6 surévalue systématiquement un modèle en raison d'un polissage superficiel, votre benchmark est défaillant. Une petite couche d'audit humain prévient le principe du « garbage-in-garbage-out ».

Étape 5 : Construire le rapport

Agrégez les scores JSON et associez-les à des extraits des sorties brutes des modèles. Regroupez tout dans un fichier unique qui réside dans votre dépôt. Lorsque vous mettez à jour une version de modèle ou que vous ajustez le prompt, la différence (diff) dans votre pull request montre exactement comment le comportement a évolué. Un benchmark bien entretenu devient une documentation vivante. Il justifie pourquoi votre pipeline de production utilise un modèle plutôt qu'un autre, et il détecte les régressions silencieuses avant qu'elles n'atteignent les utilisateurs.

Structurez le rapport de manière à ce qu'un coéquipier puisse le lire sans exécuter le code. Incluez l'énoncé du problème, le modèle de prompt, les scores et des citations représentatives de la trace de raisonnement de chaque modèle. La transparence est essentielle. Si DeepSeek R1 obtient un score élevé mais hallucine une contrainte, vous voulez que cela soit visible dans l'extrait de texte, et non enfoui dans une moyenne.

Automatiser le pipeline

Un benchmark qui ne vit que sur votre ordinateur