Quel modèle local pour quel travail : un banc qui mesure le vrai travail
Chaque semaine, un nouveau modèle domine un classement. Sur votre carte, avec votre agent, il peut n'écrire rien d'utilisable. Nous avons cessé de croire des scores que nous n'avions pas produits, et construit notre propre banc : des tests courts jugés par du code, puis du vrai travail jugé par les tests qui tournent ensuite. C'est la seconde moitié qui a changé nos choix.
Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.
Ce que vous y gagnez. Une façon de choisir le modèle de chaque tâche à partir de faits, sur votre matériel, et quatre réglages qui ont rendu fiables des modèles jugés « inutiles ». Notre banc remet la machine dans l'état où il l'a trouvée et n'interrompt jamais un jeu.
1. Deux moitiés : des tests, puis du vrai travail
- Des capacités jugées par du code : un outil vraiment appelé, un JSON qui valide, une réponse qui correspond, un programme dont les tests passent, une aiguille retrouvée de 4k à 128k jetons, une couleur lue sur une image. Aucun modèle n'en juge un autre.
- Du vrai travail : le modèle reçoit un petit dépôt et une tâche dans une session d'agent, et les tests qui tournent ensuite tranchent.
Le code généré tourne dans un interpréteur jetable, sans environnement, processeur et mémoire plafonnés. Un banc ne doit pas être ce qui casse votre machine.
2. Ce qu'il a montré
| Modèle | Tests | Vitesse | Vrai travail |
|---|---|---|---|
| 27B, Q6 | 8/8 | 28,6 jetons/s | 3 délais dépassés, zéro ligne |
| 9B, Q8 | 7/8 | 61,7 jetons/s | 2 demandes de fusion propres |
| 4B, Q8 | 8/8 | 139,8 jetons/s | 1 demande de fusion, 342 lignes, 2 bugs |
Les tests favorisaient le 4B ; le vrai travail a favorisé le 9B. Sur les fichiers longs, le 4B perdait la trace de ses propres noms de fonctions. Le 27B n'a rien produit d'utilisable. Petit et cadré bat gros et vague.
3. Quatre réglages qui comptent plus que le modèle
- Coupez la réflexion sur les modèles distillés (
enable_thinking: false). Laissée active, elle a brûlé 2 500 jetons sans écrire une ligne ; coupée, le même code juste sortait en 2,5 s. Leur gabarit ignore « low » ou « medium » : c'est allumé ou éteint. - Un cache d'attention en f16 et une fenêtre de 128k : le 9B retrouvait alors une aiguille dans 101 050 jetons, aussi bien que le 27B, en 13,1 Go.
- Déclarez les outils dans le style du modèle. Certains modèles choisissent la bonne fonction depuis un schéma JSON mais n'en remplissent jamais les valeurs ; déclarées comme des fonctions Python, le même modèle fait 5/5.
- Mesurez avec les réglages exacts que l'agent utilisera, pas ceux de la démo.
4. Qui a été écarté, et pourquoi
- Un modèle de code qui n'émettait jamais d'appel d'outil au format de l'agent, et l'écrivait en prose dans un bloc de code.
- Une variante plus rapide qui ratait un test de raisonnement : 40 % plus vite ne vaut pas une mauvaise réponse.
- Des quantifications qui ne se chargeaient jamais : supprimées, 26 Go récupérés.
Pièges
Testez chaque modèle dans sa langue. Testé avec des outils en JSON, un petit modèle semblait incapable d'appeler quoi que ce soit ; avec des outils en Python, il était parfait. Un verdict dans la mauvaise langue est un verdict sur votre harnais.
N'expulsez jamais un jeu pour lancer un banc : le nôtre saute la carte qu'un jeu utilise, et remet chaque modèle à sa place.
Utile ? Dites-nous ce qu'il faut mesurer ensuite.