Mon agent IA a créé un outil de benchmarking pour mes agents IA

Le 2026-08-11, j'ai demandé à mon agent de codage un outil qui évalue les modèles locaux dans ma pile d'agents. Il m'a livré bench-llm : 1 660 lignes de Python qui mesurent la vitesse dans LM Studio, exécutent le code qu'un modèle écrit, et vérifient si le modèle peut gérer une petite tâche d'agent. En deux semaines, tous les modèles qui m'intéressaient obtenaient 5/5, je l'ai donc reconstruit sous le nom de CrucibleForge : 251 cas, dont 158 difficiles, désormais open source sur GitHub. Cette page couvre les deux. Utilisez bench-llm pour obtenir un premier chiffre sur un modèle en cinq minutes. Utilisez CrucibleForge quand vous devez classer des modèles qui réussissent tous les tests faciles.

Résultat final

Une seule commande exécutée sur un modèle affiche ceci (exemple d’exécution, tronqué) :

$ bench-llm gemma-4-31b-it

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

Le fichier JSON contient toutes les données brutes relatives aux temps de traitement, toutes les réponses du modèle ainsi qu’un résumé. Vous pouvez le renvoyer à votre agent en lui demandant : « Lequel de mes modèles devrait se charger du traitement massif de fichiers JSON ? »

Ce que teste bench-llm

Vitesse

Il envoie trois longueurs de prompt (environ 50, 200 et 800 caractères), effectue des exécutions d’initialisation, puis mesure trois choses. Le TTFT (temps jusqu’au premier token) indique combien de temps on attend avant que le texte n’apparaisse ; plus de 500 ms donne l’impression d’une réponse lente dans un chat. Le Débit (tokens/seconde) montre à quelle vitesse le modèle écrit une fois le processus lancé. Le Préchargement T/s indique la rapidité avec laquelle il lit votre prompt.

Il effectue également un contrôle de plausibilité par rapport aux limites matérielles connues. Si un modèle de 30 Go prétend atteindre 200 T/s sur une carte 7900 XTX, bench-llm signale ce chiffre, car le décodage spéculatif ou un cache déjà chauffé a probablement faussé les résultats.

Capacités

• Génération de code : écrire median_of_list(numbers) en gérant les cas particuliers. bench-llm exécute la fonction sur six cas de test au lieu de se contenter de lire le texte.
• Problème logique : un casse-tête concernant quatre personnes et leurs animaux domestiques. Le vérificateur extrait les quatre affectations du texte de réponse.
• Conformité JSON : renvoyer un objet contenant des clés précises. C’est le minimum requis pour qu’un modèle puisse interagir avec des outils.
• Respect des instructions : lister les nombres de 1 à 10, indiquer ceux qui sont pairs et en calculer la somme. Le calcul est simple ; c’est le format qui fait l’objet du test.
• Résumé : condenser un paragraphe dense tout en conservant six faits nommés. La plupart des modèles en omettent au moins un.

Aptitude à agir en agent

Le modèle reçoit une tâche réaliste d’agent : rechercher dans les journaux système les lignes contenant « ERROR », les regrouper par service et renvoyer un rapport au format JSON. Trois critères évaluent cette seule réponse :

• Reconnaissance de la tâche : le modèle décrit-il une approche et mentionne-t-il ce qu’il ne peut pas faire ? Un modèle qui invente des lignes de journal échoue.
• Respect du format : y a-t-il un tableau services, un entier total_errors et une chaîne de caractères scan_period ?
• Concision : rapport entre la longueur de la réponse et celle du prompt. Une réponse de 20 000 caractères pour un prompt de 1 300 caractères est qualifiée de VERBEUSE, car un agent trop bavard remplit rapidement sa fenêtre de contexte à chaque tour.

Comment cela a été construit

Ma demande adressée à l’agent de programmation se résumait à une seule phrase : « J’ai besoin d’un outil qui évalue les modèles locaux dans LM Studio, teste leur vitesse et leurs capacités, puis génère un fichier JSON ainsi qu’un tableau. » En l’espace d’un après-midi, l’agent a créé cet outil en quatre étapes : des tests de vitesse via l’API de streaming compatible OpenAI de LM Studio, ensuite des tests de capacités, puis la mise en œuvre des fonctions demandées, et enfin les retouches finales (localisation du fichier GGUF sur le disque, vérification de la plausibilité, options --quick, --list et --check). L’agent a écrit chaque ligne de code. Mon rôle s’est limité à exécuter le programme sur de vrais modèles et à donner mon retour. La vérification de la plausibilité a été ajoutée car j’avais indiqué à l’agent qu’une certaine valeur de débit était impossible pour un modèle de 123 milliards de paramètres.

Quelques choix de conception dignes d’être repris dans vos propres outils :

• Utilisez le streaming, pas les requêtes périodiques. Le chronométrage par token est le seul moyen d’obtenir un temps de réponse fiable.
• Exécutez toujours le code. Un code qui semble correct mais ne fonctionne pas doit être considéré comme un échec, et non comme un succès.
• Extrayez la réponse avant de la vérifier. Les outils de vérification suppriment les préambules du type « Bien sûr ! Voici votre réponse : ». Ainsi, le test évalue uniquement le contenu, et non ces introductions.
• Démarrez chaque exécution avec une GPU vide. Sinon, le cache laissé par le modèle précédent fausse les mesures de temps de réponse. La manière dont bench-llm procède à cela constitue d’ailleurs le premier piège à éviter, comme expliqué ci-dessous.

Configuration

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

# 3. Run it
./bench-llm --list                         # what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

Il n’y a ni fichiers de configuration ni base de données. LM Studio accepte n’importe quelle chaîne de caractères en tant que clé API. Les résultats sont enregistrés dans ~/benchmarks/. Copiez le script dans un dossier figurant sur votre PATH si vous souhaitez l’exécuter depuis n’importe où.

Pièges à éviter

• Le script met fin à tout processus llama-server en cours d’exécution. Avant chaque exécution, il lance pkill -f llama-server et attend que LM Studio signale qu’aucun modèle n’est chargé. Tout autre processus llama-server sur la machine est également arrêté. Ne l’exécutez pas sur une machine servant d’autres services, ou supprimez cette étape.
• Le test de codage exécute la sortie du modèle via exec(). Il utilise un espace de noms nouveau, qui ne constitue pas un sandbox. Exécutez-le en tant qu’utilisateur n’ayant rien à perdre, ou sautez les tests de capacités avec --speed-only.
• Les modèles de raisonnement semblent lents. Le temps moyen d’attente du premier jeton (TTFT) inclut le premier jeton de type « pensée ». Le format JSON sépare ce temps en ttft_reasoning_s et ttft_content_s.
• Un score de 4/5, avec seulement l’épreuve de résumé non réussie, est un très bon résultat. Presque tous les modèles omettent au moins un fait.
• Une exécution complète prend 2 à 5 minutes par modèle. Utilisez --quick pour comparer plusieurs modèles, puis lancez le test complet sur les meilleurs d’entre eux.
• LM Studio doit déjà être en cours d’exécution. Le script bench-llm se connecte à localhost:1234 sans démarrer quoi que ce soit.

Résultats : modèles de base sur mon ordinateur de bureau et mon mini PC

Ces chiffres proviennent du suite d’évaluation intermédiaire qui a suivi bench-llm (même méthode de mesure de la vitesse, plus de tests ; rapport daté du 18 août 2026). Le « rig » est une machine sans écran équipée de 2× RTX 5090 et 2× RTX 3090. L’« APU » désigne la GPU intégrée du mini PC (lorsque celui-ci exécutait encore un serveur de modèles locaux). Comparez les vitesses uniquement au sein d’un même appareil. Les colonnes « Code », « Tools », « Instruct » et « Reason » indiquent les taux de réussite.

Le modèle Gemma 4 26B à mélange d’experts (avec 4 milliards de paramètres actifs) est le principal outil de travail sur le rig : il atteint 229 tokens/s, avec un délai de 110 ms pour la génération du premier token, et assure un appel parfait aux outils. Son point faible réside dans le respect des instructions, élément crucial pour le bon fonctionnement d’un agent autonome. Le modèle Nemotron 3 Nano 4B sur le mini PC suit mieux les instructions (94 % contre 50 %). Toutefois, il est environ douze fois plus lent (18,5 contre 229 tokens/s), et s’exécute sur un autre appareil. Choisissez donc le modèle en fonction de la colonne qui correspond à vos besoins spécifiques, et non simplement du chiffre de vitesse le plus élevé.

Ce qui l’a remplacé : CrucibleForge

bench-llm a disparu suite à son propre succès. Cinq tests de capacités suffisent pour évaluer un bon détecteur de fumée, mais pas pour classer correctement les modèles : dès que chaque modèle obtient 5/5 et 3/3, l’outil n’a plus rien à dire. CrucibleForge est donc la nouvelle version. Il se compose d’environ 9 400 lignes de code Python ; sa règle fondamentale est que une question difficile doit rester facile à évaluer.

• 158 cas difficiles. Problèmes mathématiques de compétition avec des réponses entières, grilles logiques à solution unique, ainsi que des problèmes de programmation dont les tests imposent une complexité minimale (un algorithme d’inversion en O(n²) dépasse le temps imparti). On y trouve aussi des pièges liés à l’utilisation d’outils, des injections de prompts, une récupération d’informations dans un contexte long (12 000 à 24 000 tokens), ainsi que des instructions multi-contraintes.
• Le code est évalué en le faisant exécuter dans un bac à sable bwrap sans accès au réseau, avec un système en lecture seule et une limite de 15 secondes. Pour être validé, le programme doit afficher une chaîne de caractères spécifique sur stdout ; il ne peut donc pas simuler un succès en renvoyant simplement un code de sortie nul. Sans bwrap (ce qui est toujours le cas sous macOS et Windows), l’outil refuse d’exécuter le code du modèle sauf si vous spécifiez --allow-unsandboxed.
• Les réponses en prose disposent d’une réponse de référence. Le modèle-juge dispose de cette réponse correcte et se contente de déterminer si la réponse fournie a le même sens. Tout modèle d’instruction compétent peut accomplir cela, de sorte que le modèle-juge ne constitue plus un point faible.
• Tout point de terminaison compatible OpenAI. LM Studio, Ollama, llama.cpp, vLLM, DeepSeek, OpenRouter, etc. Les modèles hébergés traitent les cas en parallèle et communiquent le coût en tokens. Les clés API ne sont lues que depuis les variables d’environnement.
• Il récupère les réponses perdues par les modèles capables de raisonnement. Un modèle qui consacre tout son budget de calcul à la réflexion renvoie une réponse vide. Le processus détecte cela, relance le test sans activation du raisonnement et compte le nombre d’occurrences. recover permet de relancer uniquement ces lignes issues d’une exécution antérieure.
• Il partage les GPU de manière équitable. Sur mon système StudioForge, chaque exécution réclame temporairement les GPU dont elle a besoin et les libère une fois terminée. Dans bench-llm, pkill résolvait le même problème en tuant tous les modèles en cours d’exécution.
• Une interface web disponible sur 127.0.0.1:8777 permet de sélectionner les modèles et les catégories, de consulter le journal d’exécution ainsi que chaque cas en échec : prompt, réponse, raisonnement du modèle et commentaire du modèle-juge. Un jeton est requis pour accéder à cette interface, sauf sur l’adresse locale.

Essayer CrucibleForge

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

Le profil standard propose un ensemble fixe de 56 cas conçus pour s’exécuter en moins d’une heure sur un modèle de 27 milliards de paramètres, à raison d’environ 70 tokens/s, y compris l’évaluation. Il est possible de relancer ce test sans risque. Il se décline également en deux parties : coding ne nécessite pas de modèle-juge, tandis que chat contient la partie évaluée. Les autres commandes disponibles sont run, judge, recover, report, pairwise, models, import-openclaw et cases.

La commande que je préfère est celle qui vérifie les questions elles-mêmes. Elle exécute chaque solution de référence dans le bac à sable, recalcule chaque réponse mathématique par force brute et reconstitue chaque base de données destinée aux tests à long contexte. Voici son output du 16 septembre 2026 :

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

L’ensemble de tests (335 tests) effectue la même vérification ; ainsi, une question défectueuse ne peut pas échouer discrètement pour tous les modèles tout en étant considérée comme correcte dans un niveau de difficulté plus élevé.

À quoi ressemble un rapport

report génère un fichier Markdown et un fichier JSON. Chaque modèle dispose d’une ligne récapitulative ainsi que d’une ligne par catégorie indiquant les comptes bruts. Voici la ligne correspondant à DeepSeek V4 Pro :

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

Chaque échec est listé avec sa cause. Les sept échecs liés à la programmation ressemblent tous au premier exemple ci-dessous. Le second exemple illustre l’un des deux cas où le modèle a échoué dans l’utilisation d’outils :

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

C’est là l’aspect utile du système : le modèle n’a pas produit de code mauvais ; il a simplement réfléchi jusqu’à épuisement du quota de 32 768 tokens sans jamais écrire quoi que ce soit. Un quota plus grand ou un effort de raisonnement moindre auraient probablement changé ce résultat. Le taux de réussite seul ne permettrait pas d’obtenir cette information.

Résultats pour le niveau difficile

Il s’agit des résultats obtenus lors d’exécutions sur l’ensemble du jeu de tests : les 251 cas, ou presque tous. Le pourcentage « Difficile » représente le taux de réussite sur les cas considérés comme difficiles (154 sur 158 ; les quatre autres ont été évalués séparément). Les colonnes « Code », « Math » et « Outils » indiquent les taux de réussite pour chaque catégorie de cas. J’ai exclu les résultats des exécutions portant sur 56 cas uniquement, car elles ne couvrent que 38 cas difficiles et ne sont donc pas comparables. J’ai également omis les scores relatifs au jeu de rôle et au contenu pour adultes figurant dans le rapport complet, car ils n’ont aucune pertinence pour l’évaluation des agents IA.

Les noms en minuscules correspondent à des versions modifiées ou adaptées par la communauté ; elles sont listées sous leurs étiquettes respectives. Les lignes non marquées ont été recalculées le 16-09-2026 à partir des fichiers d’exécution sauvegardés. Ces exécutions portent sur plusieurs versions du jeu de tests ; il convient donc de considérer les écarts de quelques points comme négligeables. ¹ Données issues du rapport du 25-08-2026. Des exécutions ultérieures portant sur 56 cas ont remplacé ces résultats complets. Une version antérieure de cette page indiquait que V4 Flash avait obtenu 272/308 : en réalité, deux exécutions complètes avaient été comptabilisées sous une seule étiquette ; le coût de 0,331 $ correspond donc à une seule exécution. ² MiniMax M3 est le modèle hébergé par MiniMax. Un cas n’a pas été évalué ; le coût indiqué est théorique : je bénéficie d’un abonnement forfaitaire, et ce chiffre repose sur le tarif par défaut défini dans mon fichier de configuration (0,255 $/1,02 $ par million de tokens entrants/sortants). Au tarif officiel de MiniMax (0,60 $/2,40 $), ce coût serait environ 2,4 fois plus élevé ; lors de la promotion actuelle à moitié prix, il serait environ 1,2 fois plus élevé. ³ Ces modèles ont été testés sur 140 des 154 cas difficiles ; pour les autres, le contexte fourni s’est avéré insuffisant.

Voici mes conclusions :

• Le modèle hébergé leader ne coûte qu’environ un dollar par exécution. V4 Pro a réussi 143 des 154 cas difficiles pour un coût de 1,10 $. Ce prix est suffisamment bas pour effectuer à nouveau les tests dès que les résultats locaux semblent trop bons.
• Un modèle de 27 milliards de paramètres exécuté localement s’en approche. Qwen3.8 27B a obtenu 135 succès, soit deux points de moins que V4 Flash, tout en générant les tokens 1,7 fois plus vite.
• La vitesse ne prédit pas forcément les capacités du modèle. MiniMax M3, le plus rapide dans la colonne « Tokens/s générés », n’affiche qu’un taux de réussite de 85 %, avec des résultats particulièrement faibles en mathématiques (77 %). Quant à joyfox-35b-rp, bien qu’il génère les tokens à une vitesse de 319 tok/s, son taux de réussite n’est que de 75 %.
• Modifier un modèle peut nuire à ses performances en programmation. Après modification, Qwen3.8 27B n’a obtenu que 62 % de succès en programmation, contre 85 % pour la version de base.
• La capacité de traitement d’un grand contexte ne suffit pas à elle seule. Les modèles de 1,5 milliard, 7 milliards et 256 millions de paramètres parviennent encore à trouver la plupart des réponses attendues (83 %, 80 % et 56 % respectivement), même si leurs performances en programmation et en mathématiques se sont considérablement dégradées.

Téléchargement

Le fichier téléchargeable est bench-llm, l’outil original désormais obsolète, et non CrucibleForge (disponible sur GitHub). Le fichier ZIP contient deux éléments : bench-llm, le script de 1 660 lignes, et README.md qui rassemble les instructions d’installation. Il n’y a rien à compiler ou à installer en plus de ces deux fichiers : il suffit de les décompresser puis de les exécuter. Les deux fichiers ont été rédigés par une IA et sont soumis à la licence MIT. Les dépendances requises sont openai et requests. Veuillez lire les précautions à prendre avant de l’exécuter sur une machine hébergeant d’autres services.

Voir aussi : StudioForge (le serveur GPU dont ces modèles tirent leurs ressources), Le coût réel de mes agents IA (pourquoi la vitesse locale est cruciale), DeepSeek Harness (un agent de programmation soutenu par ces modèles), ainsi que la pile d’agents IA locale qu’ils utilisent.

Téléchargements

• Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

Gratuit pour un usage personnel. Si ça vous fait gagner un après-midi, le bouton café n'est pas loin.