Benchmark indépendant : GLM-5.2 devance MiniMax M3 en précision de codage, MiniMax M3 l'emporte en coût et en rapidité

Des écarts concentrés sur les créations ex nihilo

Un vaste banc d'essai indépendant a opposé deux modèles de langage open-weight récents, GLM-5.2 et MiniMax M3, sur soixante tâches de codage notées. Les résultats révèlent que GLM-5.2 affiche un taux de réussite complète de 92 % (165 sur 180 essais), contre 84 % pour MiniMax M3 (152 sur 180). Le score moyen de GLM-5.2 atteint 0,976, tandis que celui de MiniMax M3 s'établit à 0,961. La différence, qualifiée de modeste par les auteurs du test, se concentre presque exclusivement sur les projets démarrés dans un dépôt vide (greenfield). Pour les tâches de modification de code existant — corrections de bugs, ajouts de fonctionnalités ou réparations de tests — les deux modèles obtiennent des scores quasiment parfaits, de 0,999 à 1,000.

Cinquante-quatre tâches sans écart significatif

Sur les soixante tâches notées, cinquante-quatre présentent un écart de score inférieur à 0,1 point entre les deux modèles. Les six écarts les plus importants concernent tous des projets greenfield. Le plus grand écart favorable à GLM-5.2 est observé sur la tâche « ticketflow » : GLM-5.2 obtient un score parfait de 1,00 contre 0,33 pour MiniMax M3. L'étude précise que MiniMax M3 n'a pas échoué par incapacité de raisonnement, mais parce que deux de ses trois essais ont produit une structure de paquet que le correcteur automatique ne pouvait pas importer depuis la racine du projet. GLM-5.2 a livré une structure cohérente à chaque fois.

Des correctifs précis là où l'autre faiblit

La tâche « patchwise » a donné l'avantage à MiniMax M3 (1,00 contre 0,62 pour GLM-5.2). Les défaillances de GLM-5.2 sont imputables à des bugs concrets : une faute de frappe dans un nom de variable lors d'un essai, et une gestion incorrecte des retours à la ligne dans les deux autres. MiniMax M3 a traité cette épreuve sans erreur. De même, la tâche « microapi » a été remportée par GLM-5.2, MiniMax M3 ayant produit un cadre fonctionnel mais manquant un retour anticipé dans un intergiciel et une expression régulière de routage incorrecte. La tâche « migrato » est revenue à MiniMax M3, qui a respecté les contrats de migration là où GLM-5.2 a perdu des points.

Coût et latence : l'avantage économique de MiniMax

Les performances en coût et en rapidité penchent nettement en faveur de MiniMax M3. Le coût total des soixante passages notés s'élève à 6,67 dollars pour MiniMax M3, contre 18,47 dollars pour GLM-5.2. La latence moyenne par tâche est de 45 secondes pour MiniMax M3, contre 80 secondes pour GLM-5.2. En revanche, le nombre moyen de jetons consommés par tâche est plus élevé pour MiniMax M3 (135 060 contre 82 443), ce qui indique une génération plus verbeuse.

Comportement face à l'ambiguïté : deux philosophies

Une série de douze tâches non notées, délibérément vagues, a permis de comparer les choix d'implémentation des deux modèles. MiniMax M3 a systématiquement ajouté des fonctionnalités supplémentaires : pour un système de journalisation (auditlog), il a intégré une vérification par chaîne de hachage, un générateur de requêtes, un décorateur d'action et un durcissement des permissions de fichiers. GLM-5.2 est resté plus proche de la demande explicite, avec une chaîne de hachage, une vérification booléenne et des filtres de requête directs. Pour un hub de notification (notifyhub), MiniMax M3 a construit un système avec repli prioritaire et échec dur en l'absence de canal fonctionnel, tandis que GLM-5.2 a renvoyé un rapport des résultats par canal. Pour un validateur de formulaire (formvalidate), MiniMax M3 a créé une validation conditionnelle avec un combinateur when, alors que GLM-5.2 a explicitement refusé cette extension.

Interprétation : des profils complémentaires

Les auteurs du test concluent que les deux modèles sont capables de coder, mais que leurs forces divergent. GLM-5.2 se distingue par une meilleure régularité dans l'empaquetage et la livraison complète, tandis que MiniMax M3 peut le surpasser sur des constructions difficiles isolées, tout en offrant un coût et une latence réduits. Le choix entre les deux dépendra donc des priorités opérationnelles : la précision maximale ou l'économie de ressources.