Samedi 20 juin 2026 | Mise à jour quotidienne L'intelligence artificielle au service des constructeurs

GLM 5.2 expliqué : le codeur Open 1M-Context de Zhipu

Le 13 juin 2026, Zhipu AI (qui commercialise désormais ses produits sous la marque Z.ai) a déployé la version GLM 5.2 sur tous les niveaux de son forfait GLM Coding Plan. Le chiffre phare est une fenêtre de contexte de 1 000 000 de tokens, soit cinq fois celle offerte par GLM 5.1, associée à des poids ouverts sous licence MIT que Zhipu avait promis de mettre à disposition dans la semaine, parallèlement à l’API autonome et au chatbot. Pour un modèle clairement destiné au codage agentique à long terme, l’ampleur de ce bond en termes de contexte est l’élément déterminant.

Ce qui manquait dans l’annonce de lancement était tout aussi frappant : pas le moindre résultat de benchmark. Ni SWE-bench, ni Terminal-Bench, ni aucun chiffre de Code Arena. C’est inhabituel pour une version d’envergure, et pendant les premiers jours, tout ce qui a été écrit sur les ’ performances “ de GLM 5.2 relevait soit du marketing du fournisseur, soit d’une simple évaluation informelle réalisée par quelqu’un pendant le week-end. La situation a changé lorsque les poids ouverts ont été rendus publics le 16 juin : Zhipu a publié une suite complète de tests de performance, et des évaluateurs indépendants ont rapidement emboîté le pas. Cet article explique ce qu’est réellement le GLM 5.2, les spécifications confirmées par Zhipu, les chiffres désormais disponibles (et dans quelle mesure on peut s’y fier), comment accéder à un modèle de cette envergure ou l’héberger soi-même, comment il se positionne par rapport au GLM 5.1 et à d’autres modèles à codage ouvert, et à qui cela s’adresse.

Principaux enseignements

  • Sorti le 13 juin 2026 concernant le plan de codage GLM ; l'API, le chatbot et les poids ouverts du MIT ont suivi 16 juin.
  • ~Mélange d'experts à 753B paramètres (selon la fiche technique du modèle de Zhipu) avec environ 40 milliards de paramètres actifs par jeton, indiqués dans Claude Code sous la forme de l'identifiant du modèle glm-5.2[1m] (ID de base glm-5.2).
  • Contexte de 1 000 000 de jetons (contre environ 200 000 pour la version 5.1 de GLM), avec une sortie plafonnée à 131 072 tokens et deux modes de raisonnement : ’ High » et « Max ».
  • Point de terminaison compatible avec Anthropic c'est-à-dire Claude Code, Cline, OpenCode, OpenClaw et d'autres y renvoient en modifiant une URL de base.
  • Il existe désormais des tests de performance. Ils étaient absents lors du lancement en avant-première du 13 juin, mais ont été livrés avec les scores suivants : SWE-bench Pro 62,1 et Terminal-Bench 2,1 (81,0) communiqués par le fournisseur, ainsi qu'un score indépendant Analyse artificielle Avec un score de 51 à l'indice d'intelligence, ce modèle s'impose comme le meilleur de la catégorie « poids libre ». Il convient de considérer les chiffres fournis par les fabricants comme tels ; ceux des organismes indépendants viennent corroborer cette tendance générale.
  • L'auto-hébergement relève de la compétence des centres de données : environ 8 fois H200 à FP8, ou moins de GPU avec une quantification INT4 agressive, sans tenir compte du cache KV d'un million de contextes.

Qu'est-ce que GLM 5.2, au juste ?

GLM 5.2 est la troisième version de la gamme GLM-5 de Zhipu, après GLM 5 et GLM 5.1, et elle est conçue pour une seule mission : écrire et maintenir des logiciels au cours de longues sessions comportant plusieurs étapes. Il s’agit d’un modèle « Mixture-of-Experts » (MoE) clairsemé, comptant environ 753 milliards de paramètres au total, mais dont seuls environ 40 milliards sont actifs pour un token donné. (La fiche du modèle de Zhipu sur Hugging Face indique 753 milliards ; certains outils de suivi tiers arrondissent ce chiffre à environ 744 milliards, soit le même nombre que pour le GLM 5.1.) C’est cette structure clairsemée qui permet à un modèle de cette envergure de fonctionner à une vitesse et à un coût acceptables, car la puissance de calcul est facturée pour les quelque 40 milliards de paramètres actifs, et non pour la totalité des 753 milliards, à chaque passage en avant.

Deux éléments distinguent la génération GLM 5.2 de la précédente. Tout d'abord, le contexte : le modèle accepte jusqu'à 1 000 000 de tokens en entrée. L'API autonome expose un identifiant de modèle par défaut, à savoir glm-5.2 (avec un contexte plus court), tandis que la fenêtre complète d'un million de jetons est désignée par glm-5.2[1m] — la variante que vous intégrez à Claude Code. Un million de tokens suffit pour contenir un référentiel de taille moyenne, ses tests et un long historique d’exécution dans une seule fenêtre. Deuxièmement, la sortie : il peut générer jusqu’à 131 072 tokens en une seule réponse, ce qui est important lorsqu’un agent génère un module entier ou un diff de refactorisation volumineux plutôt qu’un simple extrait de code.

Zhipu a remplacé les anciens préréglages d’effort par deux niveaux d’effort mental, « High » et « Max », et recommande le niveau « Max » pour les tâches de programmation complexes comportant plusieurs étapes. Il n’existe pas de réglage « Low » ni « Auto ». Si vous souhaitez en savoir plus sur les modèles précédents de Zhipu et sur le parcours de l’entreprise jusqu’à aujourd’hui, consultez notre Présentation de la gamme GLM de Zhipu parcourt l'arbre généalogique.

Les caractéristiques techniques et les résultats des tests de performance, qui ont été communiqués avec un peu de retard

Voici la partie qu'il convient de lire attentivement, car les événements se sont enchaînés rapidement. Zhipu a intégré la version 5.2 de GLM au « Coding Plan » le 13 juin avec aucune évaluation publiée, quelle qu'elle soit. Les médias qui ont couvert ce lancement en avant-première, notamment MarkTechPost, ont tous relevé la même chose : l'annonce évoquait la disponibilité, la longueur du contexte et la feuille de route open source, mais ne disait rien sur les performances du modèle.

La situation a changé le 16 juin, lorsque les poids ouverts ont été rendus publics sur Hugging Face et que Zhipu a publié un tableau de référence en parallèle. Le “ vide en matière de référence ” était donc bien réel, mais il s’agissait d’une anomalie liée au calendrier de lancement, et non d’une situation permanente. Deux conséquences en découlent.

Tout d'abord, les chiffres communiqués par le fabricant. D'après les informations fournies par Zhipu, la GLM 5.2 affiche SWE-bench Pro de 62,1 (contre 58,4 pour GLM 5.1 et 58,6 pour GPT-5.5, mais derrière Claude Opus 4,8 qui affiche 69,2) et Terminal-Bench 2,1 sur 81,0 (contre environ 63,5 pour le GLM 5.1, et juste derrière l’Opus 4.8 à 85,0 et le GPT-5.5 à 84,0). Dans la suite FrontierSWE à horizon long, Zhipu indique que le GLM 5.2 est à environ un point derrière l’Opus 4.8. Il s’agit de chiffres fournis par les éditeurs et ils doivent être interprétés comme tels : il est courant que les tableaux fournis par les éditeurs eux-mêmes privilégient des choix de harnais favorables.

Deuxièmement, et c'est là le plus utile, des évaluateurs indépendants se sont désormais prononcés et confirment globalement ce tableau. Analyse artificielle résultats de GLM 5.2 à 51 selon son « Intelligence Index » v4.1, ce qui en fait le modèle de référence dans la catégorie « open-weights », devant MiniMax-M3 (44), DeepSeek V4 Pro (44) et Kimi K2.6 (43). Sur Code Arena, où les classements sont établis par la communauté, GLM 5.2 (Max) se classe #2 figure au classement Frontend/WebDev, juste derrière Claude Fable 5 et devance largement les autres modèles ouverts. Les données indépendantes mettent toutefois en évidence une véritable réserve : le GLM 5.2 consomme bien plus de jetons de sortie par tâche que ses concurrents (Artificial Analysis a mesuré environ 43 000 par tâche de l’Intelligence Index, contre environ 26 000 pour le GLM 5.1), ce qui réduit son avantage en termes de coût sur les tâches de longue durée.

Ainsi, aujourd’hui, la formulation honnête n’est pas “ pas de chiffres, ne croyez rien ”. Elle est la suivante : GLM 5.2 est un modèle à poids ouverts puissant et vérifié sur des classements indépendants en matière d’intelligence et de codage front-end, tandis que ses scores en codage agentique en interne (SWE-bench Pro, Terminal-Bench) doivent être validés par un évaluateur neutre tel que LiveBench ou votre propre référentiel avant de considérer comme avéré tout titre du type “ surpasse GPT-5.5 ”. Plusieurs de ces titres sont techniquement étayés par des benchmarks spécifiques — GLM 5.2 devance effectivement GPT-5.5 sur SWE-bench Pro dans le tableau de Zhipu — mais il est devancé par Claude Opus 4.8 sur la plupart des tests de cette même suite ; le contexte a donc son importance.

AttributGLM 5.2 (confirmé)
Lancement du plan de codage13 juin 2026
API et poids ouverts16 juin 2026
Nombre total de paramètresenviron 753 milliards (ministère de l'Éducation ; certains observatoires indiquent environ 744 milliards)
Actif par jeton~40 milliards
Fenêtre contextuelle1 000 000 de jetons (glm-5.2[1m])
Puissance maximale131 072 jetons
Modes de raisonnementÉlevé, Max
LicenceMIT (poids libres)
Évaluation comparative indépendanteIndice d'analyse par intelligence artificielle 51 (modèle à pondération ouverte le plus performant)

Comment accéder à GLM 5.2 dans le cloud

La solution la plus rapide est le « GLM Coding Plan », un abonnement qui achemine les agents de codage via les points de terminaison hébergés par Zhipu. Les tarifs promotionnels de lancement s’élèvent à environ $10/mois pour la formule Lite (environ 400 requêtes/semaine), environ $30 par mois pour la version Pro (environ 2 000 requêtes par semaine) et environ $80 par mois pour la version Max (environ 8 000 requêtes par semaine), tandis que la version Team est facturée à l’utilisateur. Les tarifs catalogue (hors promotion) sont plus élevés — certains revendeurs proposent des prix avoisinant $18 / $72 / $160 — et les quotas varient ; il est donc recommandé de vérifier les chiffres actuels sur Z.ai avant de souscrire.

Si vous préférez payer au jeton, l’API autonome propose des tarifs d’environ $1,40 par million de jetons d’entrée et $4,40 par million de jetons de sortie sur le point de terminaison propre à Zhipu, avec une mise en cache des invites qui ramène le coût des jetons d’entrée mis en cache à environ $0,26 par million et peut réduire considérablement le coût effectif en cas de contexte répété. Les passerelles tierces telles qu’OpenRouter proposent des tarifs comparables (Simon Willison les a testés là-bas aux mêmes tarifs de $1,40 / $4,40) ; n’hésitez donc pas à comparer les revendeurs si le coût est un facteur déterminant.

Ce qui rend GLM 5.2 particulièrement intéressant pour les flux de travail existants, c’est son point de terminaison compatible avec Anthropic. Les outils qui utilisent déjà l’API Anthropic Messages peuvent être redirigés vers Zhipu en configurant une variable d’environnement, sans qu’aucune modification du code ne soit nécessaire :

CadreValeur
ANTHROPIC_BASE_URLhttps://api.z.ai/api/anthropic
Modèle (Claude Code, 1M)glm-5.2[1m]
Point de codage (Cline, etc.)https://api.z.ai/api/coding/paas/v4
Délai d'attente pour un appel longAugmenter API_TIMEOUT_MS (par exemple, 3 000 000) pour les exécutions en mode « Plan »

C'est grâce à cette seule modification que la version 5.2 de GLM intègre dès son lancement la prise en charge de Claude Code, Cline, OpenCode, Roo Code, Goose, Crush, OpenClaw et Kilo Code. Si vous utilisez un agent natif du terminal, notre guide pratique sur OpenCode et sa gestion des backends de modèles aborde le câblage plus en détail.

Les exigences matérielles pour faire tourner soi-même ~753B

La licence MIT est l’atout majeur, et elle est bien réelle : maintenant que les poids sont publics sur Hugging Face, vous pouvez télécharger, affiner et héberger vous-même GLM 5.2 sans aucune restriction d’utilisation ou géographique. Le hic, c’est que “ ouvert ” ne signifie pas “ fonctionne sur votre ordinateur portable ”. Un modèle d’environ 753 milliards de paramètres représente une charge de travail digne d’un centre de données.

Avec une précision FP8 (environ un octet par paramètre), les poids à eux seuls nécessitent de l’ordre de 750 Go de VRAM, ce qui correspond en pratique à environ 8 cartes H200 (141 Go chacune) ou 8 cartes B200. En passant à la précision INT4, l’empreinte mémoire tombe à environ 370 Go, ce qui tient sur environ 4 cartes H200 — ou vous pouvez répartir cette charge sur un plus grand nombre de cartes à mémoire réduite, comme 8 cartes H100, au prix d’une légère perte de qualité. Et ces chiffres ne tiennent pas compte du contexte : un cache KV d’un million de tokens ajoute environ 80 Go ou plus à ce total ; ainsi, la configuration pour un contexte d’un million de tokens nécessite, de manière réaliste, des nœuds de la classe H200/B200. Selon les guides de déploiement disponibles, le coût d’un seul boîtier 8x H200 se situe approximativement autour de 1 TP4T10k par mois en tarification spot, et peut atteindre 1 TP4T25k ou plus sur les clouds GPU à la demande.

Pour la grande majorité des équipes, ce calcul conduit à utiliser l’API. L’auto-hébergement de GLM 5.2 n’a de sens que lorsque la localisation des données, l’isolation physique ou un volume soutenu très élevé justifient la charge opérationnelle — et notez que l’API hébergée, très pratique, fonctionne sur une infrastructure chinoise, ce qui constitue un critère à part entière pour certains acheteurs. Si votre véritable objectif est de disposer d’un modèle que vous pouvez exécuter sur du matériel qui vous appartient réellement, un MoE d’environ 753B n’est pas l’outil qu’il vous faut, et notre guide sur le les meilleurs LLM locaux pour la programmation propose des solutions adaptées à un poste de travail unique ou à un serveur GPU de taille modeste.

Points forts

  • Le contexte de 1 million de tokens est véritablement vaste et particulièrement adapté aux tâches d'agent sur l'ensemble d'un dépôt.
  • Licence MIT permissive avec accès libre à l'ensemble des poids ; il ne s'agit pas d'une licence réservée à la recherche ou à un usage non commercial.
  • Il occupe à la fois la première place dans la catégorie « Open-Weights » de l’Artificial Analysis Intelligence Index et la première place dans le classement « frontend » de Code Arena avec le modèle #2.
  • La disponibilité immédiate d'un point de terminaison compatible avec Anthropic signifie un coût de migration quasi nul depuis les clients Claude, et la tarification de Coding Plan est plus avantageuse que celle des API fermées pour les gros utilisateurs.

Mises en garde

  • Les scores de codage agentique fournis par les éditeurs eux-mêmes (SWE-bench Pro, Terminal-Bench) sont gérés par ces derniers et sont inférieurs à ceux de Claude Opus 4.8 ; veuillez vérifier ces résultats auprès d'évaluateurs neutres ou à l'aide de vos propres tâches.
  • Il utilise nettement plus de jetons de sortie par tâche que ses homologues, ce qui réduit son avantage en termes de coût pour les tâches de longue durée.
  • L'auto-hébergement nécessite du matériel de centre de données prenant en charge plusieurs GPU, et non du matériel grand public ou semi-professionnel ; l'API hébergée fonctionne sur une infrastructure chinoise.
  • Uniquement les niveaux d'effort « High » et « Max » ; pas de mode « rapide et bon marché » pour les tâches simples. Les tarifs et les quotas sont encore en cours de définition.

GLM 5.2 par rapport à GLM 5.1 et le champ « open-weight »

Par rapport à sa version précédente, GLM 5.2 présente à peu près la même taille — Zhipu indique qu’il appartient à la même classe de paramètres que GLM 5.1 (~753 milliards contre ~754 milliards) —, avec la même architecture MoE et environ 40 milliards de paramètres actifs. Cette avancée réside presque exclusivement dans la fenêtre de contexte et le plafond de sortie, ainsi que dans une amélioration mesurable des scores aux benchmarks.

ModèleNombre total de paramètresContextePuissance maximaleLicenceSWE-bench Pro (fournisseur)
GLM 5.2~753B MoE1,000,000131,072MIT62.1
GLM 5.1~754B MoE~200,000~131 000MIT58.4

Dans la course plus large au codage en poids ouverts, GLM 5.2 s’impose désormais comme le favori sur plusieurs classements indépendants, et non plus comme un nouveau venu dont les capacités restent à prouver. La génération Kimi K2 de Moonshot ainsi que les derniers codeurs DeepSeek et Qwen publient tous des résultats sur le SWE-bench et en codage agentique, et le produit phare de Qwen propose également un contexte de 1 million de tokens — mais sur l’Artificial Analysis Intelligence Index, GLM 5.2 (51) devance DeepSeek V4 Pro (44) et Kimi K2.6 (43). Cela dit, le classement ne reflète pas nécessairement l’adéquation avec votre base de code, et sur les suites d’agents propriétaires, GLM 5.2 reste à la traîne par rapport à la référence actuelle (Claude Opus 4.8). Pour avoir une idée de la façon dont les autres laboratoires chinois se livrent à un bras de fer, consultez notre analyse détaillée de DeepSeek V4 face à Qwen 3, et pour le modèle avec lequel il est le plus souvent comparé, notre analyse de Kimi K2.7 pour la programmation. Nous avons également mis les deux en face à face dans GLM 5.2 ou Kimi K2.7 pour la programmation.

FAQ

GLM 5.2 est-il réellement open source ?

Les modèles sont mis à disposition sous licence MIT, qui est l'une des licences les plus permissives existantes et autorise l'utilisation commerciale, la modification et la redistribution. Les modèles ont été rendus publics sur Hugging Face (sous la forme de zai-org/GLM-5.2 et une version FP8) le 16 juin 2026. Notez que l’expression “ poids ouverts sous licence MIT ” ne signifie pas qu’il s’agit d’un projet entièrement open source avec des données d’entraînement publiques ; vous obtenez le modèle, pas la recette.

Combien coûte l'utilisation de GLM 5.2 ?

Via l'API, il faut compter environ $1,40 par million de jetons d'entrée et $4,40 par million de jetons de sortie sur le point de terminaison de Zhipu, la mise en cache réduisant le coût des jetons d'entrée mis en cache à environ $0,26 par million. L’abonnement au forfait GLM Coding Plan est souvent plus avantageux pour une utilisation régulière, avec des tarifs promotionnels commençant à environ $10 par mois pour la formule Lite et pouvant atteindre environ $80 par mois pour la formule Max (les prix catalogue sont plus élevés). Des fournisseurs tiers tels qu’OpenRouter proposent des tarifs par jeton comparables.

Puis-je exécuter GLM 5.2 sur ma propre carte graphique ?

À condition que “ mon propre GPU ” désigne un serveur multi-GPU. Les poids (~753 milliards) nécessitent environ 8 cartes H200 en FP8, ou environ 4 cartes H200 (ou davantage de cartes à mémoire réduite) avec une quantification INT4, et le contexte de 1 million de tokens ajoute en outre un besoin important en cache KV. Un seul GPU grand public ne peut pas exécuter ce modèle ; pour cela, il faut un modèle local plus petit, spécialement conçu à cet effet.

GLM 5.2 est-il compatible avec Claude Code ?

Oui. Zhipu met à disposition un point de terminaison compatible avec Anthropic ; il vous suffit donc de diriger Claude Code vers https://api.z.ai/api/anthropic, configurez le modèle sur glm-5.2[1m], et fournir une clé API Z.ai. Il est recommandé d'augmenter le délai d'expiration de la requête pour les sessions de planification de longue durée. La même approche fonctionne pour Cline, OpenCode, OpenClaw, Goose, Roo Code, Crush et Kilo Code.

En quoi la fenêtre de contexte de GLM 5.2 diffère-t-elle de celle de GLM 5.1 ?

Sa capacité est cinq fois supérieure : 1 000 000 de tokens contre environ 200 000 pour GLM 5.1. Le nombre maximal de tokens générés reste également élevé, à 131 072, ce qui rend GLM 5.2 mieux adapté pour traiter l'intégralité d'une base de code ainsi qu'une longue transcription d'agent en une seule session.

Zhipu a-t-il publié des résultats de tests de performances pour GLM 5.2 ?

Ce n'était pas le cas lors du lancement du « Coding Plan » le 13 juin — cette annonce portait principalement sur la disponibilité et la feuille de route concernant les poids ouverts. Mais Zhipu a publié un tableau complet de résultats de tests de performance lorsque les pondérations ont été rendues publiques le 16 juin, et des laboratoires indépendants ont emboîté le pas : Artificial Analysis le classe en tête des modèles à pondérations ouvertes dans son Intelligence Index (51), et Code Arena lui attribue la note #2 pour le codage front-end. Les scores « agentic » fournis par les éditeurs (SWE-bench Pro : 62,1 ; Terminal-Bench : 2,1 sur 81,0) doivent toutefois être recoupés avec des évaluations neutres pour s’assurer de leur fiabilité.

GLM 5.2 est-il plus performant que Kimi K2 ou DeepSeek pour le codage ?

En matière d’intelligence agrégée indépendante, il les devance actuellement : Artificial Analysis affiche un score GLM de 5,2 (51), contre DeepSeek V4 Pro et Kimi K2.6 qui se situent dans la fourchette basse des 40, et il devance les deux sur le classement « frontend » de Code Arena. Pour toute tâche spécifique de codage agentique, l'écart peut se réduire, voire s'inverser, et les trois systèmes publient des résultats détaillés du benchmark SWE. Ainsi, pour une décision à enjeux élevés, effectuez un test comparatif sur votre propre référentiel plutôt que de vous fier à un seul classement.

Résultat

GLM 5.2 est une version concrète et remarquable : un modèle de codage sous licence MIT comptant environ 753 milliards de paramètres, doté d’un contexte d’un million de tokens et d’une API compatible avec Anthropic, prête à l’emploi, qui permet de l’intégrer à Claude Code ou à Cline en quelques secondes. Pour les utilisateurs intensifs de la programmation agentique qui recherchent un contexte long et une licence permissive, l’offre est très attractive, et les tarifs du « Coding Plan » sont très compétitifs.

L'écart de performance qui a marqué les 72 premières heures s'est comblé : des évaluateurs indépendants classent désormais GLM 5.2 comme le premier modèle à poids ouverts en matière d'intelligence globale et parmi les meilleurs en codage front-end, ce qui constitue une véritable référence. Gardez toutefois deux mises en garde à l’esprit. Les affirmations les plus tapageuses du type “ surpasse GPT-5.5 ” reposent sur des benchmarks « agentic » menés par les fournisseurs, dans lesquels GLM 5.2 reste derrière Claude Opus 4.8 ; de plus, le modèle consomme beaucoup de tokens de sortie, il convient donc de vérifier la rentabilité par rapport à votre propre charge de travail. La réalité matérielle va dans le même sens : pour la quasi-totalité des utilisateurs, il s’agit d’une API cloud à tester, et non de poids à héberger soi-même. Un essai sérieux s’impose clairement ; la décision de migrer entièrement dépendra de ses performances sur votre code, et non de son classement.

Défiler vers le haut