Exécuter CrucibleForge avec vos propres modèles : guide d’installation

Publié
5 novembre 2026
Mis à jour
5 novembre 2026
Par
Jacob Lloyd — rédigé avec l'aide de l'IA, une fois le projet terminé
Temps de lecture
10 min de lecture

En clair : CrucibleForge est l’outil gratuit et open source qui génère chacune des évaluations figurant sur le tableau de bord MakoBench. Cette page explique comment l’installer, le connecter à un modèle local ou hébergé, exécuter un test de base et lire les résultats. Si vous ne disposez pas de GPU, vous pouvez nous demander de faire fonctionner votre modèle sur notre propre matériel.

Aller à : CrucibleForge sur GitHub

CrucibleForge est l’outil open source qui génère tous les scores affichés sur le tableau de bord MakoBench. Il est gratuit (licence MIT-0, sans condition) et vous pouvez l’utiliser avec vos propres modèles, sur votre propre machine. Cette page explique comment l’installer et effectuer une première exécution. Chaque commande ci-dessous a été lancée sur une copie fraîche du dépôt public ; les résultats affichés proviennent de cette exécution. Pas de GPU ou pas le temps nécessaire ? Demandez-nous de faire tourner votre modèle sur notre infrastructure.

Pas de GPU ? Demandez-nous de faire tourner votre modèle sur notre infrastructure.

Demander l’exécution d’un modèle Voter pour le prochain modèle à tester

Vous n’avez pas besoin de GPU pour exécuter CrucibleForge. Il vous suffit d’un endpoint pour effectuer les tests. Le formulaire de demande s’adresse aux modèles que vous ne pouvez pas héberger vous-même.

Résumé en quelques mots

  • Quatre commandes suffisent pour passer du clonage du dépôt à l’exécution du benchmark : uv sync, config --init, status, all.
  • Tout endpoint compatible OpenAI fonctionne. Ollama, LM Studio, llama.cpp, vLLM, ou toute API hébergée.
  • La machine sur laquelle tourne CrucibleForge n’a pas besoin de GPU. Un modèle local met environ 25 à 30 minutes à s’exécuter sur une machine dotée d’un GPU rapide, évaluation incluse.
  • Testez d’abord le test de validation. Notre exécution a duré 1,6 minute et coûté 0,0229 $.
  • Ce test ne génère pas de score. Il couvre seulement 4 des 33 cas du tableau de bord ; par conséquent, aucun score total ni classement n’est calculé.

De quoi avez-vous besoin avant de commencer ?

  • Python 3.12 ou une version ultérieure avec uv, ou Docker. uv se chargera de télécharger Python pour vous.
  • Un modèle à tester accessible via un point de terminaison /chat/completions compatible avec OpenAI.
  • Un “juge”, c’est-à-dire tout modèle d’instruction capable, qu’il soit local ou hébergé. Le code est évalué en étant exécuté, mais le Chat a besoin d’un juge.
  • Sous Linux, bubblewrap (bwrap). Le code généré par le modèle s’exécute à l’intérieur de celui-ci. Sous Windows et macOS, il n’y a pas de bubblewrap ; vous devez alors utiliser --allow-unsandboxed ou opter pour l’image Docker, où le conteneur fait office de sandbox.

Comment l’installe-t-on ?

C’est la méthode native sous Linux. Docker est une option plus simple si vous préférez ne pas installer d’outils Python. Le fichier README contient des blocs de code copiables pour Windows, Linux et macOS ; dans chaque cas, Docker Desktop ou Compose constitue la méthode 1. Nous n’avons pas utilisé la méthode Docker pour cette page.

git clone https://github.com/LaserLloyd/CrucibleForge.git
cd CrucibleForge
uv sync --python 3.13
uv run crucibleforge --version
crucibleforge 4.0.1

Il s’agit de la version 4.0.1, la dernière version publique au moment de la rédaction de ces lignes. Créez maintenant votre fichier de configuration :

uv run crucibleforge config --init
wrote models.yaml - edit providers/models, then `crucibleforge status`

Le fichier de démarrage liste les fournisseurs tels que LM Studio, Ollama, llama.cpp ou tout autre serveur local, DeepSeek, OpenRouter, OpenAI et Open WebUI, ainsi que quatre modèles d’exemple. Rien ne fonctionne tant qu’un fournisseur n’est pas activé.

Comment connecter votre modèle ?

models.yaml nécessite un fournisseur, un modèle et un juge.

  1. Fournisseur. C’est l’endroit où le modèle est hébergé. Tout serveur capable de répondre à /chat/completions fonctionne avec type: openai. Exemples locaux tirés du README : http://localhost:11434/v1 pour Ollama, http://localhost:1234/v1 pour LM Studio, http://localhost:8000/v1 pour vLLM. Pour une API hébergée, il faut utiliser api_key_env: NAME_OF_ENV_VAR. La clé elle-même ne doit jamais figurer dans le fichier.
  2. Modèle. Il s’agit d’une entrée contenant un name, le provider, le model_id connu du serveur, ainsi qu’un context_length.
  3. Juge. Il est indiqué à chaque exécution via --judge provider:model_id.

Pour savoir ce qu’un serveur propose, interrogez-le. Voici un exemple de fournisseur hébergé où la clé est définie dans l’environnement :

uv run crucibleforge models discover deepseek
  * deepseek-flash
  * deepseek-v4-pro

2 models on deepseek (* = in registry)

L’astérisque indique que le modèle figure déjà dans le registre. Le fichier de démarrage active par défaut deepseek-flash, donc aucune modification n’était nécessaire pour notre exécution. Pour votre propre modèle, ajoutez une entrée similaire à celle-ci :

models:
  - name: my-model
    provider: ollama
    model_id: qwen3:8b
    context_length: 32768

Comment vérifier la configuration ?

export DEEPSEEK_API_KEY=...       # only for a hosted provider or judge
uv run crucibleforge status

Sans clé définie, la sortie d’état pour le fournisseur hébergé se présente ainsi (extraits des lignes pertinentes) :

suite revision: 4.0.1+e3d1c6fb
providers:
  ollama         openai      http://localhost:11434/v1       DOWN conc=8
  deepseek       openai      https://api.deepseek.com/v1     UP   conc=8 key: $DEEPSEEK_API_KEY (NOT SET)
    reachable, but it wants an API key: set $DEEPSEEK_API_KEY (HTTP 401)
registry (models):
  [enabled ] deepseek-flash   deepseek   deepseek-flash    $0.14/0.28 per 1M
cases: 393 total (235 hard)
smoke subset: 37 cases
benchmark (bench): 33 cases

DOWN signifie qu’aucune réponse n’a été reçue à cette adresse, ce qui est normal pour les serveurs locaux que nous ne faisions pas tourner. UP avec un 401 indique que l’hôte est joignable et qu’il demande une clé. Le nombre de cas est important : il y a au total 393 cas, et le système en utilise 33.

Combien coûte une exécution avant de la lancer ?

Ajoutez --plan à toute exécution : rien ne sera exécuté. Le système affiche ce qui serait exécuté ainsi qu’une estimation :

uv run crucibleforge all --models deepseek-flash --judge deepseek:deepseek-v4-flash --plan
  T1 - every model: 29 rows (29 cases) + 4 perf probes
  one round - hosted API (nothing loaded): 29 rows, 8 requests at once
  estimate: generation 18.5 min; judge 16.0 min ... -> ~34 min
(plan only - no model, provider or judge was called; times are estimates)

Il s’agit de l’exécution complète sur un modèle hébergé : environ 34 minutes selon l’estimation du outil. Il s’agit d’une estimation, pas d’une mesure réelle. Pour un modèle local, le README indique un temps d’environ 25 à 30 minutes sur une machine dotée d’une GPU rapide.

À quoi ressemble une exécution de test “smoke” ?

Le paramètre --smoke exécute un petit sous-ensemble de données du début à la fin : génération, évaluation et création du rapport. C’est le moyen le plus rapide de vérifier que votre configuration fonctionne correctement. Nous avons utilisé DeepSeek Flash tant comme modèle que comme juge ; il s’agit du couple recommandé dans les instructions de démarrage du README. L’exécution a eu lieu en dehors des heures de pointe de DeepSeek.

uv run crucibleforge all --smoke --models deepseek-flash --judge deepseek:deepseek-v4-flash --yes
... profile bench: 4 cases, thinking cap 24576, judge deepseek:deepseek-v4-flash
... link check passed: deepseek reachable, data channel OK
... run: models=['deepseek-flash'] cases=4 smoke=True fresh=False
... [deepseek-flash] RD1-marisol r1 done (15 rows)
... judging done: 1 rows, 0 unparsable judge verdicts, 0 empty generations, 0 errored
run summary:
  deepseek-flash: 15 rows, load 0.0s (deepseek), $0.0229
timing: generation 1.2 min, judge 14 s, report 8 s, total 1.6 min
wrote results/report.md, results/failures.md, results/report.html

L’exécution a duré 1,6 minute et a coûté 0,0229 $. Les 15 lignes traitées correspondent à un cas de rôle-play ainsi qu’à des tests de vitesse. Deux points importants méritent d’être mentionnés :

  • L’API du juge a rejeté une demande de sortie structurée ; CrucibleForge a donc recouru au format JSON en texte libre pour cette session. Les scores ont néanmoins été générés.
  • Le juge n’a pas réussi le test de calibration concernant les textes à contenu adulte. CrucibleForge s’est alors limité à évaluer les autres lignes, laissant celles contenant du contenu adulte en attente d’un juge capable de les traiter. Le README indique que la plupart des juges hébergés se comportent ainsi. Ces scores figurent bien dans le tableau, mais ne sont jamais ajoutés au total.

Comment interpréter les résultats ?

Ouvrez results/report.html dans un navigateur, ou lisez results/report.md. Notre exécution de test a affiché une seule ligne :

| Model          | Overall | Class | Coding | Chat        | tok/s | Suite | Notes                                          |
| deepseek-flash | -       | -     | -      | 2.5 +/- 0.1 | 159.7 | 4.0.1 | partial (4/33 cases); judged by deepseek-v4-flash |

La valeur de 2,5 indiquée pour Chat n’est pas un score du modèle. Il s’agit simplement du seul cas de rôle-play qui a été exécuté, parmi ceux relevant de la catégorie Chat. La ligne indique partiel (4/33 cas) ; un modèle fonctionnant en mode partiel ne dispose ni de score global, ni de classe, ni de rang. C’est également la règle appliquée sur le tableau principal. Exécutez l’ensemble des tests pour obtenir un score total réel (Code plus Chat, soit 20 points au total). Pour comprendre la signification de chaque colonne, consultez Comment fonctionne MakoBench et Ce que teste MakoBench.

La vitesse (tok/s) ne permet de comparer que des modèles exécutés sur le même matériel. La vitesse d’un modèle hébergé dépend de son fournisseur ainsi que de la charge de travail à ce moment-là.

Comment exécuter le benchmark dans sa totalité ?

uv run crucibleforge all --models my-model --judge my-provider:my-judge --yes

Ajoutez --fresh pour archiver d’abord la transcription précédente du modèle. Les résultats se trouvent dans results/, à côté de models.yaml : le relevé des scores, les échecs, le rapport HTML ainsi qu’une transcription de chaque invite et de chaque réponse. L’interface web se lance via une seule commande (uv run crucibleforge gui) et n’écoute que sur l’adresse loopback par défaut.

Quelques points à savoir au préalable

  • Les cas de test de codage exécutent du code généré par le modèle. Utilisez bubblewrap sous Linux ou l’image Docker ailleurs. --allow-unsandboxed permet d’exécuter ce code en tant que vous, avec accès à vos fichiers.
  • Les exécutions hébergées sont payantes. Lancez d’abord --plan ainsi que le test de vérification.
  • L’ensemble de tests comprend des cas de fiction pour adultes qui figurent sur le tableau mais ne sont jamais incluss dans le calcul du Total. Le fichier README contient une note à ce sujet.
  • Le juge modifie les scores Chat. Sur le tableau MakoBench, le juge est Gemma 4 31B (version non censurée dite « hérétique », Q8) exécuté sur notre propre matériel GPU. Vos scores Chat ne correspondront au tableau que si vous utilisez le même juge ; le code, lui, est évalué en étant exécuté, donc la comparaison reste possible dans tous les cas.
  • Les scores se comparent uniquement au sein d’une même version du suite de tests. Cette page concerne la version 4.0 ; consultez les changements apportés dans la Suite 4.0.

Tout s’est-il bien déroulé ?

Presque. Nous avons également exécuté uv run crucibleforge cases verify, qui recalcule les réponses attendues hors ligne. Cette commande a vérifié 393 cas et en a signalé un problème : il s’agit d’un cas du type « code-bank » dont la solution de référence a mis trop de temps à exécuter un test de signal. Cette exécution s’est faite sur notre machine en même temps que d’autres tâches ; nous ne pouvons donc pas déterminer s’il s’agit d’une véritable erreur ou simplement d’une machine lente. Nous ne l’avons pas encore signalé en amont. Si vous rencontrez le même cas, vous n’êtes pas seul.

Souhaitez-vous que nous le exécutions pour vous ?

Pas de GPU disponible pour cela ? Demandez-nous d’exécuter votre modèle sur notre matériel.

Demander un modèle Voter pour le prochain modèle

Nous décidons de ce qui sera exécuté, car un modèle volumineux doit pouvoir tenir sur notre matériel. Les votes déterminent l’ordre par défaut dans l’onglet « Vote ». Les résultats apparaissent sur le tableau de bord MakoBench.

Voir aussi : Comment fonctionne MakoBench, Suite 4.0 : quelles sont les modifications, ainsi que le tableau de bord.


← Plus de IA et LLM locaux