GLM-5.2 Benchmarks et Spécifications : SWE-bench Pro, Terminal-Bench et Analyse des Résultats

GLM-5.2 de Z.ai (Zhipu AI) est arrivé avec une série de chiffres de référence, et certains d'entre eux sont vraiment impressionnants. Le titre est SWE-bench Pro à 62,1, devançant GPT-5.5. L'histoire plus importante est enfouie une ligne plus bas : Terminal-Bench a bondi de 62,0 à 81,0 en une seule génération. Cet article passe en revue chaque score de référence de GLM-5.2, explique ce que le test mesure réellement, et indique où l'avance est réelle par rapport à une erreur d'arrondi.

Tous les chiffres de lancement ici sont les résultats publiés par Z.ai, sauf indication contraire. Lorsqu'un modèle prétend battre ses concurrents sur ses propres fiches d'évaluation, il faut le lire avec un sourcil levé. Nous serons donc précis sur ce que chaque référence prouve et ce qu'elle ne prouve pas.

bouton

La version courte : les scores de référence de GLM-5.2 en un coup d'œil

Voici le tableau complet des références de GLM-5.2, avec les rivaux les plus proches pour le contexte. Considérez les colonnes de comparaison comme les chiffres rapportés par Z.ai pour ces modèles, et non comme des réexécutions indépendantes.

Z.ai rapporte également GLM-5.2 comme le modèle open source le mieux noté sur FrontierSWE, PostTrainBench et SWE-Marathon. Nous verrons ce que ce qualificatif ("open source") signifie.

Pour une version simple de ce qu'est ce modèle, consultez l'aperçu de GLM-5.2. Pour savoir comment il se compare directement aux modèles propriétaires, il existe une analyse dédiée GLM-5.2 vs GPT-5.5, Opus et Gemini.

SWE-bench Pro : 62,1 et ce que cela vous dit réellement

SWE-bench Pro est le cousin plus difficile et plus sélectif du SWE-bench original. Il soumet à un modèle un problème GitHub réel ainsi que le dépôt complet, et lui demande de produire un correctif qui fasse passer la suite de tests cachée du projet. Pas de choix multiples, pas de fonctions jouet. Soit vous corrigez le bug dans les fichiers réels, soit vous ne le faites pas.

GLM-5.2 obtient un score de 62,1. GPT-5.5 se situe à 58,6 et GLM-5.1 à 58,4, selon Z.ai. Voici donc deux conclusions honnêtes :

• L'avance de 3,5 points sur GPT-5.5 est significative mais pas un gouffre. Sur une référence aussi "bruyante", quelques points peuvent varier en fonction des détails de l'environnement de test, des budgets de nouvelle tentative et de l'échafaudage de l'invite. On peut parler de "compétitif au sommet", pas de "dominant".
• Le gain de 3,7 points par rapport à GLM-5.1 est le signal le plus fiable, car c'est le même laboratoire qui mesure de la même manière deux de ses propres modèles. Les deltas d'une génération à l'autre sont la lecture la plus claire que l'on puisse obtenir.

Pourquoi se soucier de SWE-bench Pro ? Parce que c'est le proxy public le plus proche de "ce modèle peut-il faire mon vrai travail ?". Corriger un bug dans une base de code tentaculaire nécessite de lire du code inconnu, de localiser le bon fichier et de modifier sans casser trois autres choses. C'est la réalité quotidienne du travail logiciel, c'est pourquoi les modèles de codage sont évalués en premier lieu.

Terminal-Bench 2.1 : 81,0 est le chiffre vedette

Si vous lisez une ligne du tableau, lisez celle-ci. Terminal-Bench évalue un modèle en tant qu'agent dans un véritable shell : installer des dépendances, exécuter des commandes, analyser la sortie, récupérer des erreurs et effectuer une tâche multi-étapes de bout en bout. Il récompense la persévérance et la discipline des outils, et non l'ingéniosité en un seul essai.

GLM-5.1 a obtenu un score de 62,0. GLM-5.2 obtient un score de 81,0. C'est un bond de 19 points en une génération, et c'est la statistique de performance la plus remarquable de GLM-5.2, et ce pour une bonne raison. Passer de "échoue environ quatre tâches sur dix" à "achève environ quatre tâches sur cinq" fait la différence entre un modèle que vous devez surveiller et un modèle auquel vous pouvez confier un terminal.

C'est aussi là que l'histoire de l'architecture se connecte à l'histoire des benchmarks. Z.ai attribue au GLM-5.2 son "IndexShare" sparse attention, qui réutilise un indexeur sur toutes les quatre couches d'attention sparse pour réduire les coûts d'attention dans un contexte long. Les tâches d'agent à long horizon génèrent de longues transcriptions : commande, sortie, commande, sortie, sur des dizaines de tours. Un modèle qui maintient ce contexte de manière peu coûteuse et précise est un modèle qui ne perd pas le fil à mi-chemin d'une construction. Le bond de Terminal-Bench est le résultat pratique de cette conception. Pour une comparaison générationnelle complète, voir GLM-5.2 vs GLM-5.1.

Une mise en garde honnête : Terminal-Bench est un chiffre rapporté par Z.ai, et les benchmarks agentiques sont sensibles à l'échafaudage autour du modèle (limites de temps, tentatives autorisées, l'invite de l'harnais). Le bond est suffisamment important pour que l'échafaudage seul soit peu susceptible de l'expliquer, mais vérifiez sur votre propre charge de travail avant de parier une pipeline dessus.

MCP-Atlas : 77,0, et une égalité honnête au sommet

MCP-Atlas mesure l'utilisation d'outils via le protocole de contexte de modèle (Model Context Protocol), la manière standard dont les modèles appellent des outils et des serveurs externes. C'est le benchmark qui correspond le plus directement au travail d'agent et d'API : le modèle peut-il choisir le bon outil, formater correctement l'appel, lire le résultat et continuer.

GLM-5.2 se positionne à 77,0. GPT-5.5 est à 75,3, et Claude Opus 4.8 est à 77,8, selon Z.ai. C'est la ligne où vous devriez résister à l'envie de déclarer un vainqueur. GLM-5.2 bat GPT-5.5 de 1,7 point et est devancé par Opus 4.8 de 0,8 point. Ce sont des marges d'erreur d'arrondi. L'affirmation juste est que sur l'utilisation d'outils de style MCP, les trois sont au coude à coude, et GLM-5.2 a gagné sa place dans ce groupe.

Cela compte parce que l'utilisation d'outils est le point de rencontre entre un modèle de codage et votre pile technologique. Chaque appel MCP est, fonctionnellement, une interaction API : une requête structurée, une réponse à analyser, une erreur à gérer. Si vous connectez un modèle à des services réels, vous voulez la même hygiène que vous appliqueriez à n'importe quelle intégration. C'est exactement là qu'Apidog intervient. Vous pouvez définir et simuler les points d'extrémité qu'un agent va utiliser, puis déboguer les charges utiles de requêtes et de réponses réelles que le modèle génère, avant de le laisser s'exécuter en production. Téléchargez Apidog si vous voulez tester ces appels d'outils de la même manière que vous testeriez n'importe quelle autre API.

Raisonnement et mathématiques : HLE 54,7, AIME 99,2, GPQA-Diamond 91,2

Le codage n'est pas toute l'histoire. GLM-5.2 affiche également de solides chiffres de raisonnement.

• Humanity’s Last Exam (avec outils) : 54,7. HLE est un examen délibérément brutal couvrant des questions de niveau expert dans de nombreux domaines, conçu pour résister à une saturation facile. Le réglage "avec outils" permet au modèle de rechercher et de calculer plutôt que de répondre à froid. Le score de 54,7 de GLM-5.2 dépasse le 52,2 de GPT-5.5 (selon Z.ai). Sur un benchmark aussi difficile, tout score dans les 50 est un résultat sérieux.
• AIME 2026 : 99,2. L'AIME est une compétition de mathématiques pour les lycéens très performants. Un score de 99,2 est effectivement un score plafond, ce qui indique principalement que le test ne permet plus de distinguer les modèles de pointe. C'est un signal de "pas de faiblesses ici" plus qu'un facteur de différenciation.
• GPQA-Diamond : 91,2. GPQA-Diamond est la partie la plus difficile d'un ensemble de questions-réponses scientifiques de niveau universitaire, filtrée de manière à ce que les non-experts ne puissent pas la résoudre par la force brute, même avec un accès au web. Un score de 91,2 place fermement GLM-5.2 dans le territoire de pointe en matière de raisonnement technique.

Le schéma commun à ces éléments : GLM-5.2 n'est pas un spécialiste étroit du code qui s'effondre en mathématiques ou en sciences. Les deux niveaux d'effort de réflexion (Élevé et Max, avec Max recommandé pour le codage) vous permettent d'échanger la latence contre la profondeur sur les problèmes les plus difficiles. Si vous souhaitez approfondir l'angle mathématique et de raisonnement en plus du codage, l'article sur les benchmarks GLM-5.2 face au marché approfondit cette comparaison.

La revendication du « plus haut niveau open source », décortiquée

Z.ai présente GLM-5.2 comme le modèle open source le plus performant sur FrontierSWE, PostTrainBench et SWE-Marathon. Lisez attentivement ce qualificatif, car il a une réelle importance.

"Le plus haut niveau open source" est une affirmation plus étroite que "le plus haut niveau, point final". Le domaine des poids ouverts est le cadre pertinent ici : GLM-5.2 est livré sous licence MIT avec des poids ouverts et sans restrictions régionales, ce qui est une proposition différente d'un modèle d'API fermé que vous louez. Par rapport à d'autres modèles à poids ouverts, être en tête sur FrontierSWE (tâches logicielles de difficulté frontalière), PostTrainBench (capacités post-entraînement) et SWE-Marathon (travail logiciel long et soutenu) est une affirmation solide, et c'est l'affirmation qui compte si votre contrainte est "doit être auto-hébergeable".

Ce n'est pas la même chose que de surpasser tous les modèles propriétaires sur ces tests. Lorsque GLM-5.2 bat réellement GPT-5.5, comme sur SWE-bench Pro et HLE, Z.ai le dit directement sans la réserve "open source". Le modèle mental est donc le suivant : au niveau de la frontière ou près de celle-ci dans l'ensemble, et clairement premier parmi les modèles que vous pouvez télécharger et exécuter vous-même. VentureBeat a formulé la valeur de manière directe, en rapportant que GLM-5.2 "bat GPT-5.5 sur le codage à long terme pour environ un sixième du coût." C'est une caractérisation de VentureBeat, qu'il convient d'attribuer plutôt que d'affirmer comme un fait avéré.

Spécifications de GLM-5.2 en un coup d'œil

Les benchmarks n'ont de sens que face à la réalité matérielle et de licence. Voici les spécifications de GLM-5.2 qui déterminent comment les scores se traduisent dans votre configuration.

Quelques notes sur la lecture de cette barre latérale. Le nombre de paramètres de ~753B représente la taille totale du MoE, et non le nombre de jetons actifs, il ne faut donc pas le lire comme "nécessite 753B de calcul dense par passage avant", c'est le but du MoE. Le contexte de 1M de jetons est la spécification qui rend le résultat de Terminal-Bench crédible : les longues exécutions d'agents ont besoin d'un endroit pour stocker tout cet historique. Concernant la sortie maximale, soyez prudent. Les documents de Z.ai citent jusqu'à 128K (à partir de juin 2026, vérifiez la limite actuelle sur z.ai), mais ce n'est pas toujours listé de manière cohérente chez tous les fournisseurs, alors traitez-le comme un plafond documenté plutôt que garanti. Et il n'y a pas de modèle de vision GLM-5.2. Si vous voyez "GLM-5.2V" quelque part, ce n'est pas quelque chose que Z.ai a confirmé.

La tarification suit la logique des poids ouverts : OpenRouter indique 1,40 $ par million de jetons d'entrée et 4,40 $ par million de jetons de sortie, avec une entrée en cache d'environ 0,26 $ par million (chiffre de VentureBeat). Ce profil de coût est le fondement de la ligne "un sixième du coût". Pour la ventilation complète des coûts, y compris les niveaux du plan de codage GLM, consultez la page Tarification GLM-5.2, et si vous souhaitez l'exécuter sans payer par jeton, comment utiliser GLM-5.2 gratuitement couvre la voie de l'auto-hébergement.

Comment vérifier ces benchmarks vous-même

Les fiches d'évaluation des fournisseurs sont un point de départ, pas un verdict. Trois choses à faire avant de faire confiance à l'un de ces chiffres pour une décision réelle :

1. Lisez les sources primaires. Le blog Z.ai GLM-5.2 et la documentation Z.ai contiennent la méthodologie officielle. La fiche de modèle Hugging Face contient les poids et la configuration si vous souhaitez inspecter l'architecture directement.
2. Vérifiez les listes de tiers. La page OpenRouter confirme la tarification et l'identifiant du modèle, et l'entrée de la bibliothèque Ollama confirme le chemin d'exécution local. La couverture de VentureBeat ajoute un éclairage externe sur l'histoire des coûts.
3. Exécutez votre propre évaluation. Le seul benchmark qui compte pleinement est votre charge de travail. Intégrez GLM-5.2 dans une tâche réelle, idéalement une tâche d'agent avec des appels d'outils, et observez comment il se comporte sur plusieurs itérations. Pour un contexte de génération antérieure sur cet exercice exact, la présentation de GLM-5.1 et la comparaison GLM-5 vs DeepSeek vs GPT-5 vitesse et coût sont des références utiles.

Lorsque vous exécutez cette évaluation de votre propre charge de travail, les appels d'outils sont là où les modèles échouent discrètement : JSON malformé, mauvaise sélection d'outils, gestion des erreurs abandonnée. La simulation de ces points d'extrémité dans Apidog vous permet d'observer les requêtes et les réponses réelles du modèle sans surcharger les services en direct, ce qui est le moyen le plus rapide de distinguer un champion des benchmarks d'un modèle qui fonctionne dans votre pile.

Le point à retenir

La fiche de benchmark de GLM-5.2 résiste mieux à l'examen que la plupart des fiches de lancement. Le bond de Terminal-Bench de 62,0 à 81,0 est le chiffre vraiment impressionnant, l'avance de SWE-bench Pro sur GPT-5.5 est réelle, quoique modeste, et le résultat MCP-Atlas est une honnête égalité à trois au sommet. Associez ces scores à des poids ouverts, une licence MIT, un contexte de 1 million de jetons et une économie d'environ un sixième du coût, et vous obtenez un modèle qui mérite une évaluation sérieuse plutôt qu'un regard poli.

Les benchmarks vous orientent vers le bon modèle. Votre propre charge de travail le confirme. Lorsque vous effectuez ce test et qu'il implique de réels appels d'API et d'outils, configurez les points d'extrémité dans Apidog afin de pouvoir voir exactement ce que le modèle envoie et reçoit, puis décidez en fonction de ce qu'il fait dans votre pile, et non de ce qu'il a obtenu chez quelqu'un d'autre.