GLM-5 vs GLM-4.7 : ce qui a changé, ce qui compte et faut-il mettre à niveau ?

GLM-5, publié le 11 février 2026 par Zhipu AI (Z.ai), représente un grand saut architectural par rapport à GLM-4.7 : échelle MoE plus importante (≈744B contre ~355B de paramètres totaux), capacité de paramètres actifs supérieure, moindre hallucination mesurée, et gains nets sur les benchmarks agentiques et de codage — au prix d’une complexité d’inférence et (parfois) d’une latence accrues.

Qu’est-ce que GLM-5 et pourquoi sa sortie est-elle importante ?

Quel type de modèle est GLM-5 ?

GLM-5 est le tout dernier modèle de langage de pointe à poids ouverts de Zhipu AI (Z.ai), publié le 11 février 2026. C’est un transformeur à mélange d’experts (MoE) qui fait passer la famille GLM à ~744 milliards de paramètres totaux, tout en activant environ 40 milliards de paramètres par inférence (c’est‑à‑dire que le routage MoE du modèle maintient le calcul actif bien inférieur au nombre total de paramètres). Le modèle est proposé sous licence MIT et est optimisé pour des charges de travail agentiques — des tâches longues et multi‑étapes telles que l’orchestration d’outils, l’écriture et le raffinage de code, l’ingénierie documentaire et le travail de connaissance complexe.

Quelles sont les améliorations majeures par rapport aux variantes GLM précédentes ?

Liste courte des changements les plus conséquents :

• Montée en paramètres : GLM-5 ≈ 744B au total (40B actifs) vs GLM-4.7 ~355B au total / 32B actifs — environ un saut de 2× à l’échelle du modèle.
• Benchmarks et factualité : Forte amélioration sur des benchmarks indépendants (Artificial Analysis Intelligence Index : GLM-5 = 50 vs GLM-4.7 = 42), et forte réduction des hallucinations sur la métrique AA Omniscience (baisse rapportée de 56 points de pourcentage par rapport à GLM-4.7).
• Capacités agentiques : Fiabilité accrue pour l’appel d’outils, la décomposition de plans et l’exécution sur long horizon (Z.ai positionne GLM-5 pour “l’ingénierie agentique”).
• Déploiement et puces : Conçu et benchmarké pour tourner sur du matériel d’inférence domestique chinois (Huawei Ascend et autres), reflétant l’orientation de Z.ai vers des piles de puces variées.

Pourquoi c’est important : GLM-5 réduit l’écart entre les modèles à poids ouverts et les modèles propriétaires de pointe sur les tâches agentiques et de connaissance — rendant les modèles open source à haute capacité une option réaliste pour les entreprises qui ont besoin de déploiements contrôlables et de flexibilité de licence.

Quoi de neuf dans GLM-5 (détaillé)

Positionnement : « ingénierie agentique » à l’échelle

GLM-5 est explicitement positionné par Z.ai comme un modèle pour « l’ingénierie agentique » : une classe de cas d’usage où le modèle planifie, émet des appels d’outils, inspecte les résultats et itère de manière autonome sur de nombreuses étapes (par ex., construire une pipeline CI, trier et corriger des suites de tests défaillantes, ou assembler des microservices). Il s’agit d’un virage stratégique par rapport à la génération de code purement mono‑tour vers des modèles conçus pour fonctionner et raisonner à travers des traces d’exécution et des sorties d’outils.

Modes de pensée, raisonnement conservé/intercalé

GLM-5 introduit des modes de « pensée » affinés (parfois mentionnés dans la documentation comme pensée intercalée, pensée conservée), ce qui signifie que le modèle peut émettre — puis réutiliser — des traces de raisonnement internes dans les tours et appels d’outils suivants. Concrètement, cela réduit les coûts de re‑dérivation dans de longs workflows et améliore la cohérence quand un agent doit maintenir l’état du plan à travers les résultats d’outils. GLM-4.7 avait introduit des variantes de pensée et un comportement sensibilisé aux outils ; GLM-5 affine la mécanique et les recettes d’entraînement pour rendre ces traces plus fiables et réutilisables.

Ingénierie du long contexte et stabilité du système

L’entraînement et le finetuning de GLM-5 testent explicitement la génération avec des contextes très longs (202 752 tokens lors des cycles SFT/évaluation). C’est une augmentation pratique qui devient importante dès que vous avez besoin que le modèle voie plusieurs dépôts, des journaux de tests et des sorties d’orchestration dans un seul prompt. Des configurations d’évaluation poussent les longueurs de génération à 131 072 tokens pour certaines charges de raisonnement. C’est un effort notable d’ingénierie visant à atténuer l’instabilité habituelle lors du conditionnement sur des contextes gigantesques.

Architecture et montée en charge (MoE)

Les rapports publics indiquent que GLM-5 utilise une grande architecture MoE (mixture‑of‑experts) avec plusieurs centaines de milliards de paramètres au total (les décomptes publics listent ~744–745B). GLM-4.7 a des variantes MoE et Flash, ajustées pour différents compromis de déploiement (par exemple, des variantes « Flash » avec des nombres de paramètres actifs plus petits pour l’inférence locale ou à faible coût). Le design MoE aide GLM-5 à pousser la capacité de pointe tout en permettant des choix de configuration (paramètres actifs plus faibles pour une inférence moins chère). Attendez-vous à des profils d’inférence différents (latence, VRAM) selon la variante déployée.

Comment Z.ai a-t-il fait évoluer et entraîné GLM-5 par rapport à GLM-4.7 ?

Différences architecturales majeures

À retenir : GLM-5 double presque la capacité totale comparé à GLM-4.7 et augmente les paramètres actifs, ce qui contribue à de meilleures capacités de raisonnement et de synthèse, en particulier pour du contenu technique long, des pipelines de raisonnement étendus et des tâches d’ingénierie de code complexes.

Architecture : qu’est-ce qui a changé ?

GLM-4.7 est une conception mélange d’experts (MoE) dans ses variantes les plus grandes (documentée à ~355B de paramètres totaux avec un ensemble actif par token plus petit). GLM-5 conserve les idées de parcimonie style MoE mais y superpose un nouveau mécanisme d’attention clairsemée — le rapport l’appelle DeepSeek Sparse Attention (DSA) — qui alloue dynamiquement des ressources d’attention aux tokens jugés importants. L’affirmation est que DSA réduit le coût d’inférence/de formation tout en préservant (ou améliorant) le raisonnement sur long contexte, permettant au modèle de gérer des contextes bien plus longs que les checkpoints historiques avec un compute maîtrisé.

Échelle : paramètres et données

• GLM-4.7 : documenté à environ 355 milliards de paramètres totaux pour la version MoE principale (avec un ensemble de paramètres actifs par passage beaucoup plus petit pour l’efficacité).
• GLM-5 : rapporté à ~744 milliards de paramètres et entraîné avec ~28,5 trillions de tokens dans son budget de pré‑entraînement, avec une emphase d’entraînement sur le code et les séquences agentiques. Cette combinaison vise à améliorer la synthèse de code et la planification agentique soutenue.

Le saut de paramètres, couplé à l’expansion du budget de tokens et aux mises à jour architecturales, est la raison principale côté entrée pour laquelle GLM-5 montre de meilleurs résultats numériques sur les classements de code et d’agentique.

Stratégie d’entraînement et post‑entraînement (RL)

Alors que GLM-4.7 a introduit des modes de pensée « intercalés » ou conservés pour améliorer le raisonnement multi‑étapes et l’utilisation d’outils, GLM-5 formalise ce pipeline en :

1. Étendant la longueur de contexte via un calendrier en cours d’entraînement (l’équipe rapporte une extension progressive du contexte jusqu’à 200K tokens).
2. Mettant en œuvre un pipeline RL séquentiel de post‑entraînement (RL de raisonnement → RL agentique → RL général) avec une distillation inter‑étapes on‑policy pour éviter l’oubli catastrophique.
3. Ajoutant du RL asynchrone et des moteurs de rollout découplés pour mettre à l’échelle les trajectoires d’agents pendant le RL sans goulots d’étranglement de synchronisation.

Ces méthodes visent spécifiquement à améliorer le comportement agentique sur long horizon — par exemple, en maintenant un état interne stable sur de longues sessions où le modèle effectue plusieurs appels d’outils et éditions de code dépendants.

Comment GLM-5 et GLM-4.7 se comparent-ils en performances et capacités ?

Benchmarks et mesures d’intelligence

Interprétation :

• GLM-5 surpasse GLM-4.7 de manière générale sur les benchmarks de codage et de raisonnement, avec des marges mesurables. Cela est particulièrement clair pour l’automatisation multi‑étapes, la décomposition de problèmes et les tâches de logique profonde.
• Les améliorations sont non triviales : par ex., la capacité sur Terminal Bench passe d’environ ~41 % à 56 %, un gain relatif majeur en fiabilité d’automatisation agentique.
• Sur des tests de raisonnement (comme des métriques internes HLE), GLM-5 montre des sorties de raisonnement plus solides, brutes et avec outils.
• Montre des gains mesurables sur des tests agentiques réels : dans la métrique ISR HTML frontend CC‑Bench‑V2, GLM-5 a enregistré 38,9 % contre 35,4 % pour GLM-4.7 sur un sous‑ensemble de tâches frontend. (C’est l’une des métriques évaluées automatiquement utilisées pour démontrer une compétence pratique en développement front‑end.)

Taille du contexte et tâches longues

• Les deux modèles prennent en charge des contextes larges (~200k tokens) — ce qui signifie qu’ils peuvent consommer et raisonner sur des documents, des bases de code ou des dialogues plus longs.
• Des rapports anecdotiques réels suggèrent que des déploiements GLM-5 ont parfois montré des perceptions de problèmes de gestion de contexte sur certaines plateformes — mais cela peut refléter des limites spécifiques à l’hôte plutôt que le design du modèle lui‑même.

Appel d’outils et de fonctions

Les deux prennent en charge l’invocation structurée de fonctions/outils ; GLM-5 exécute simplement une logique de script plus complexe avec plus de fidélité, surtout sur des branches étendues d’opérations.

Exemples : en quoi la qualité de sortie diffère selon les tâches

Exemple de codage (conceptuel)

• GLM-4.7 : Produit des scripts monofichier compétents avec une syntaxe correcte et une logique lisible.
• GLM-5 : Excelle dans la génération de code multi‑fichiers, des suggestions de débogage approfondies, et de longues boucles de feedback avec une troncature de contexte minimale.

Raisonnement et planification

• GLM-4.7 : Bon raisonnement multi‑étapes mais fait parfois défaut sur des chaînes de raisonnement très profondes.
• GLM-5 : Meilleur pour fragmenter le raisonnement, rappeler des étapes antérieures et naviguer dans de longues chaînes — utile pour la synthèse de données et des stratégies multi‑domaines.

Comment la latence et le coût évoluent si l’on passe de GLM‑4.7 à GLM‑5 ?

Compromis de latence et où GLM‑4.7 reste gagnant

Messages courts et interfaces réactives : Des benchmarks de praticiens montrent que GLM-5 peut ajouter une petite surcouche fixe sur des réponses courtes (routage et gestion de la sélection d’experts) qui peut se traduire par une latence légèrement plus élevée pour des charges minuscules. Pour des interfaces ultra‑basse latence à petits messages, GLM-4.7 ou les variantes Flash restent attractifs.

GLM-5 comparé à GLM-4.7 :

• GLM-4.7 : entrée $0.60/1M tokens, sortie $2.20/1M tokens.
• GLM-5 : entrée $1.00/1M tokens, sortie $3.20/1M tokens.

Coût vs. temps d’édition humaine

Un prix de modèle plus élevé peut se justifier lorsque GLM-5 réduit significativement le temps humain en aval (par ex., l’édition de merge requests, la priorisation et correction de correctifs automatisés, ou l’évitement d’appels répétés au modèle). Une règle de décision simple :

Si GLM-5 réduit le temps d’édition manuelle de > X % (X dépend du coût horaire humain et du nombre de tokens par workflow), il peut être rentable malgré un coût par token plus élevé. Plusieurs analyses de blog ont modélisé de telles conditions de seuil de rentabilité et constatent que GLM-5 s’avère souvent payant pour des workflows agentiques lourds et répétitifs (par ex., réparation de code automatisée à grande échelle).

Latence et matériel

La VRAM d’inférence et la latence dépendent de la variante (Flash, FlashX, MoE complet). Les guides communautaires montrent que GLM-4.7 FlashX et les variantes 30B Flash sont déployables sur des GPU 24 Go ; les variantes MoE complètes nécessitent de grands ensembles multi‑GPU. Les configurations complètes de GLM-5 demanderont des ressources sensiblement plus élevées pour un même débit, même si la parcimonie MoE aide à réduire le compute actif par token. Attendez‑vous à un investissement d’ingénierie pour ajuster la quantification, le mappage mémoire et le streaming en production.

Quand faut-il passer de GLM‑4.7 à GLM‑5 ?

À mettre à niveau si :

• Vous avez besoin d’un meilleur raisonnement de code multi‑fichiers, d’une orchestration d’agents à long contexte, ou de taux de succès end‑to‑end plus élevés pour les agents.
• Vos tâches sont à forte valeur et justifient une complexité et un coût d’infrastructure par requête plus élevés.

Restez sur GLM‑4.7 si :

• Votre charge est à grand volume, prompts courts, où la prédictibilité du coût et de la latence compte plus que des gains marginaux de qualité.
• Cas d’usage qui privilégient le maintien sur GLM‑4.7
• Haut débit, petits payloads : Chatbots, autosuggestion, petites tâches de paraphrase — GLM-4.7 (surtout les variantes Flash) sera souvent moins cher et plus faible en latence.
• Budgets contraints et tâches à volume : Pour l’étiquetage, la classification ou des micro‑tâches exécutées à l’échelle, l’efficacité de GLM-4.7 et son prix par token plus bas sont convaincants.
• Vous n’avez pas l’infra ou le budget pour gérer le sharding MoE / l’autoscaling complexe.

Comment choisir le modèle dans mes appels d’API ? (exemples)

# GLM-4.7
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
 -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
 -d '{"model":"glm-4.7","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":800}'
# GLM-5
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
 -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
 -d '{"model":"glm-5","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":1200}'

Python (requests) : modifiez le champ model pour router vers GLM‑4.7 ou GLM‑5 — le reste du code client peut rester identique.

Évaluation finale :

GLM-5 apparaît comme évolutif avec des points d’inflexion importants :

• Évolutif car il prolonge le design MoE et « raisonnement d’abord » de la famille GLM et poursuit le schéma d’amélioration itérative (4.5 → 4.6 → 4.7 → 5).
• Point d’inflexion car il augmente matériellement l’échelle, introduit DSA et s’engage dans un curriculum RL spécifiquement adapté aux tâches agentiques sur long horizon — ce qui produit des améliorations significatives et mesurables sur un éventail de benchmarks pratiques.

Si vous évaluez uniquement par le placement dans les classements, GLM-5 revendique un leadership à poids ouverts sur plusieurs métriques et réduit les écarts avec les meilleurs systèmes propriétaires sur les tâches agentiques et de codage. Si vous évaluez par l’expérience développeur et les usages sensibles à la latence, des avantages et inconvénients pratiques restent à démontrer dans des déploiements plus larges et sur la durée. Cela signifie que GLM-5 est convaincant lorsque le cas d’usage exige une compétence agentique soutenue ; GLM-4.7 reste un choix mûr, plus rapide et plus économique pour de nombreux besoins de production actuels.

Les développeurs peuvent accéder à GLM-5 et à GLM-4.7 via CometAPI dès maintenant. Pour commencer, explorez les capacités du modèle dans le Playground et consultez le API guide pour des instructions détaillées. Avant d’y accéder, veuillez vous assurer de vous être connecté à CometAPI et d’avoir obtenu la clé API. CometAPI propose un prix bien inférieur au tarif officiel pour vous aider à intégrer.

Prêt à démarrer ? → Inscrivez-vous à GLM-5 dès aujourd’hui !

Si vous voulez davantage de conseils, guides et actualités sur l’IA, suivez-nous sur VK, X et Discord !