GLM 5.2 en production : le modèle ouvert qui obéit à la lettre

GLM 5.2 est le premier modèle à poids ouverts que nous avons branché sur un produit en production sans faire de compromis sur la licence. Z.ai diffuse ses poids sous licence MIT, avec un million de tokens de contexte et une taille qui le place au niveau des modèles fermés. Sur le papier, c'est un modèle de frontière que vous pouvez héberger vous-même.

En pratique, nous l'avons cassé deux fois avant de le faire marcher. La première fois parce qu'il raisonne par défaut et qu'un agent vocal ne supporte pas dix secondes de silence. La seconde fois parce qu'il lit les descriptions de nos outils comme un juriste lit un contrat. Ce deuxième point est la partie utile de ce retour d'expérience, et elle vaut pour tous les modèles récents.

Ce que Z.ai a livré avec GLM 5.2

Le modèle a été mis en ligne le 16 juin 2026 sur Hugging Face, en FP8 et en BF16. La recette officielle de vLLM le décrit comme une architecture Mixture-of-Experts d'environ 743 milliards de paramètres au total, dont 39 milliards actifs à chaque token. Le dépôt de code est publié sous Apache 2.0, tandis que les poids portent la licence MIT. Sur son model card, Z.ai revendique un modèle « Pure Open », avec une licence MIT et sans limite régionale. Pour une agence qui livre à des clients européens, cette ligne de licence pèse plus lourd que deux points d'écart sur un classement.

Les chiffres de performance publiés par Z.ai placent GLM 5.2 à 62,1 sur SWE-bench Pro, 81,0 sur Terminal-Bench 2.1, 76,8 sur le sous-ensemble public de MCP-Atlas et 48,2 sur Tool-Decathlon, tous relevés sur le tableau de son model card. Ce sont des mesures du fournisseur, sur ses propres harnais, et le document détaille honnêtement chaque protocole : contexte de 400 000 tokens sur SWE-bench Pro, modèle juge tiers sur les épreuves de raisonnement, effort de raisonnement maximal partout. Ce même tableau mérite d'être lu jusqu'au bout, parce que sur Tool-Decathlon, la colonne qui mesure l'usage d'outils, GLM 5.2 se classe derrière les modèles fermés du panel. Nos propres mesures, plus bas, vont exactement dans ce sens.

Le contexte annoncé mérite la même prudence. Un million de tokens, oui, à condition de servir le modèle sur une machine capable de les tenir. Sur les offres managées, ce plafond tombe, et nous y revenons plus bas avec des chiffres précis. Si vous suivez déjà la famille des poids ouverts, GLM se compare surtout à Qwen côté modèles ouverts chinois : même terrain, arbitrages techniques différents.

Le raisonnement est actif par défaut, et il se paie en secondes

Le dépôt de Z.ai est explicite : l'effort de raisonnement se règle par le paramètre reasoning_effort, qui accepte max et high, et max est la valeur par défaut. La documentation de l'API ajoute un détail décisif pour qui écrit du code de streaming : la chaîne de pensée arrive dans un champ reasoning_content séparé, pas dans content.

Laissé tel quel sur un agent téléphonique, ce comportement produit exactement ce qu'on redoute, et c'est devenu le premier point que nous contrôlons sur les projets d'agents IA sur mesure. Sur un endpoint managé, en juillet 2026, avec notre prompt de production complet, nous avons mesuré 10,01 secondes avant le premier mot prononcé, dont 3 863 caractères de raisonnement envoyés dans le champ séparé pendant que content restait vide. Avec un max_tokens serré, le budget partait entièrement en raisonnement et l'appelant n'entendait rien du tout. En voix, cela s'appelle un appel perdu.

Cette mécanique nous a aussi appris une leçon de méthode que nous appliquons depuis à tous les bancs. Notre première mesure annonçait fièrement 669 millisecondes de temps au premier token. Ce chiffre était juste et sans intérêt : il mesurait le premier token de raisonnement, pas la première syllabe entendue par l'appelant. Sur un modèle à raisonnement, la seule métrique honnête est le délai avant le premier delta.content. Les tableaux de latence publiés un peu partout ne font pas toujours cette distinction, ce qui explique une partie des écarts entre les bancs et le terrain, comme sur notre projet d'agent vocal Tala.

Couper le raisonnement : le bon commutateur dépend de l'endroit où tourne le modèle

Trois commutateurs documentés désactivent le raisonnement, et ils ne viennent pas de la même source. Le dépôt GLM et la recette de service parlent de enable_thinking: false passé dans chat_template_kwargs. L'API de Z.ai expose un objet thinking avec {"type": "disabled"}. Un hébergeur managé, lui, expose sa propre surface : le catalogue de modèles de Scaleway annonce pour glm-5.2 trois efforts de raisonnement acceptés, none, high et max, et sa note de bas de page prévient noir sur blanc que les arguments du genre chat_template_kwargs avec enable_thinking ne sont pas pris en charge, en recommandant reasoning_effort comme équivalent. Cette valeur none n'existe pas dans la documentation amont, et la note se lit en petits caractères sous le tableau des modèles.

Nous avons appris cette note à nos frais, en testant les quatre variantes sur le même endpoint managé, avec le même prompt de production, en juillet 2026. Les délais mesurés donnent le prix d'un paramètre envoyé sans vérifier qu'il s'applique.

Sources des paramètres documentés : dépôt zai-org/GLM-5, documentation API Z.ai et catalogue de modèles Scaleway, consultés le 30/07/2026. Les délais sont nos propres mesures de juillet 2026 sur un endpoint managé en préversion, avec notre prompt de production.

Seule la dernière ligne a réellement coupé le raisonnement, avec zéro caractère émis dans le champ dédié. Les trois autres ont été acceptés sans message d'erreur et sont restés sans effet, ce qui correspond exactement à ce que la note du catalogue annonce pour les deux premiers. La leçon opérationnelle tient en une phrase : la surface d'API d'un endpoint managé n'est pas celle du modèle amont, et un paramètre accepté n'est pas un paramètre appliqué. Le seul test valable est le vôtre, sur votre endpoint, en comptant les caractères de raisonnement reçus. Nous rejouons désormais cette matrice de quatre variantes à chaque changement de fournisseur ou de version, d'autant qu'une préversion peut évoluer sans préavis et invalider un relevé daté comme celui-ci.

Il ne se trompe jamais d'outil, il s'abstient

Le reproche qu'on lit le plus souvent sur GLM en usage agent concerne le déclenchement d'outils. Nous l'avons mesuré sérieusement en juillet 2026, sur notre endpoint managé : 9 variantes de configuration, 5 tours de conversation réels rejoués, 20 tirages par combinaison, soit 900 générations. Le résultat a inversé notre diagnostic initial.

Premier fait, sur les 800 générations des huit variantes en choix d'outil libre, GLM n'a jamais appelé le mauvais outil. Quand il se trompe, il ne se trompe pas de cible, il ne fait rien. Cette nuance change tout, parce qu'un modèle qui appelle le mauvais outil est dangereux alors qu'un modèle qui s'abstient est corrigeable.

Deuxième fait, la cause de l'abstention se trouvait dans nos propres prompts. Sur nos agents, la transition attendue portait comme description entière « Après accueil ». Quand l'appelant posait une question au lieu de dire bonjour, GLM déclenchait la transition 0 fois sur 20, quelle que soit la configuration. Quand l'appelant disait simplement « oui, bonjour », donc quand la description collait au tour, il la déclenchait 15 fois sur 20. Sur des workflows où les transitions portent une vraie condition, formulée par exemple comme « l'appelant a exposé sa demande de prise en charge », le taux remontait entre 9 et 11 sur 20. Nos étiquettes étaient écrites pour un humain qui lit un canevas, pas pour un modèle qui lit une spécification.

Troisième fait, deux réglages populaires n'ont rien réparé sur ce corpus. La température n'a eu aucun effet mesurable, 24 déclenchements contre 26 sur 100 tirages, ce qui est du bruit. Et rallumer le raisonnement a dégradé l'ensemble : toutes les variantes qui le réactivent font baisser le déclenchement et ouvrent deux pannes que notre configuration de production n'a pas, entre 24 et 38 % de réponses entièrement vides et jusqu'à 14 % de tours où le modèle prononce le nom de l'outil à voix haute. Ces deux taux sont ceux de ce corpus de juillet 2026, sur cet endpoint et cette version du modèle.

Dernier relevé, sur le même endpoint et à la même date, le paramètre tool_choice à required a été accepté par l'appel puis n'a rien forcé : 30 appels corrects et 70 réponses vides sur 100. Le catalogue de l'hébergeur annonce pourtant l'appel de fonctions et les appels parallèles comme pris en charge, donc traitez ce relevé comme un comportement observé à une date sur une préversion, à revérifier chez vous avant d'en dépendre.

La recommandation qui en sort est inconfortable pour un chantier de migration. Avant de changer de modèle parce que le vôtre déclenche mal ses outils, réécrivez les descriptions de vos outils et de vos transitions comme des conditions vérifiables. C'est le travail que nous menons maintenant en premier sur nos chantiers d'agents conversationnels, avant tout arbitrage de modèle.

Où le faire tourner, et ce que vous perdez à chaque option

L'API de Z.ai donne accès au modèle complet avec son million de tokens de contexte et une sortie documentée jusqu'à 128 000 tokens. C'est le chemin le plus court pour évaluer, et le plus direct pour un usage de développement.

Le passage par un hébergeur européen coûte du plafond. Sur le catalogue de Scaleway, glm-5.2 tourne avec un contexte limité à 256 000 tokens pendant la phase de préversion, contre le million annoncé par le modèle, et une sortie maximale de 16 000 tokens en serverless. La note du catalogue est franche sur la raison : la limite existe pour tenir une vitesse de génération constante. Sortie structurée, appel de fonctions et appels d'outils parallèles sont annoncés comme pris en charge, et le déploiement dédié tourne sur une instance à huit accélérateurs B300. La grille tarifaire ne propose qu'une région pour ce service, Paris. Toutes les offres européennes ne l'exposent pas : au 30 juillet 2026, le catalogue d'AI Endpoints d'OVHcloud liste les familles gpt-oss, llama, mistral et qwen, sans GLM.

L'auto-hébergement, enfin, demande du matériel sérieux. La recette officielle de vLLM annonce que la version FP8 tient sur un seul noeud de huit H200, soit 1 128 Go de mémoire vidéo, et qu'il faut huit B200 (1 440 Go) avec un cache d'attention en FP8 pour atteindre le contexte complet d'un million de tokens. Il faut vLLM 0.23.0 au minimum, un parallélisme tensoriel de 8, plus les bons analyseurs de sortie pour les appels d'outils et pour le raisonnement. Le model card liste aussi SGLang à partir de la version 0.5.13.post1. Notre position est tranchée : à ce niveau de matériel, l'auto-hébergement se justifie par un volume soutenu ou par une contrainte de données qui interdit l'API, et la mise en oeuvre relève du travail d'infrastructure décrit dans notre article sur le service de modèles avec vLLM en production.

Le coût réel de GLM 5.2, et le piège du cache de prompt

La grille tarifaire de Z.ai affiche 1,40 dollar par million de tokens en entrée, 0,26 dollar en entrée mise en cache et 4,40 dollars en sortie. La grille de l'hébergeur parisien monte à 1,80 euro en entrée et 5,50 euros en sortie, sans ligne pour l'entrée mise en cache. L'écart de facturation brute est déjà réel, mais l'absence de tarif de cache pèse beaucoup plus lourd que ces quelques dizaines de centimes.

Sur notre agent vocal, le prompt système fait environ 11 000 tokens et il repart intégralement à chaque tour de conversation, pour une sortie d'environ deux cents fois plus courte. Toute la facture se joue donc sur l'entrée. Un fournisseur qui met en cache le préfixe divise cette entrée par cinq environ, au tarif affiché plus haut. En juillet 2026, sur notre endpoint managé, les métadonnées d'usage renvoyées par l'API ne portaient aucun détail de tokens mis en cache, ce qui est cohérent avec une grille sans ligne de cache.

Le chiffre qui remet tout à l'échelle est celui de la facture totale. Sur notre volume d'appels, l'ensemble du poste modèle de langage tourne autour de quelques euros par mois. À ce niveau, arbitrer un modèle sur son prix au million de tokens revient à optimiser la ligne la moins chère du budget, pendant que la qualité de conversation décide de la satisfaction du client final. Nous gardons quand même la mesure, parce que le raisonnement actif produit des milliers de caractères facturés en sortie pour une réponse d'une phrase, et que la note grimpe vite dès qu'on l'active à grande échelle, comme détaillé dans notre article sur la maîtrise des coûts de modèles de langage.

Pour qui GLM 5.2 est le bon choix aujourd'hui

Le modèle est un très bon candidat sur trois terrains. Le codage agentique de longue haleine, pour lequel Z.ai l'a manifestement optimisé et où les scores de son harnais sont cohérents avec ce que nous observons. Les traitements à gros contexte, à condition de vérifier le plafond réel de votre endpoint. Et tout projet où la licence commande, parce que MIT sans restriction régionale permet un déploiement chez soi que peu de modèles de ce calibre autorisent.

La prudence s'impose sur deux terrains. Le temps réel d'abord, voix comprise : tant que vous n'avez pas mesuré le délai avant le premier fragment de contenu, sur votre endpoint et avec votre prompt complet, vous ne savez pas si le modèle tient la conversation. Les workflows d'agent ensuite, dont les descriptions d'outils sont approximatives, parce que sur nos corpus GLM applique ces descriptions à la lettre au lieu de deviner l'intention.

Notre séquence d'évaluation, celle que nous appliquons désormais à chaque nouveau modèle avant de le proposer à un client, tient en quatre étapes.

• Rejouer de vrais tours de production, prompt complet et outils réels, jamais un prompt de démonstration.
• Mesurer le délai avant le premier fragment de contenu, en comptant les caractères de raisonnement reçus.
• Compter les déclenchements d'outils attendus et les déclenchements à tort, sur au moins vingt tirages par cas.
• Vérifier que les paramètres envoyés sont réellement appliqués par l'endpoint, pas seulement acceptés.

Sur nos quatre workflows internes suivis pendant trente jours, raisonnement coupé et en production, GLM 5.2 affiche 381 millisecondes de latence médiane par tour, avec un maximum à 2,1 secondes. Le petit modèle qu'il remplaçait montait à 5,7 secondes dans le pire cas sur la même période. Ce chiffre de 381 millisecondes mesure un tour complet une fois le raisonnement désactivé, il n'a rien à voir avec les 10 secondes du comportement par défaut. Si vous hésitez entre GLM et une option européenne native, faites l'arbitrage sur le déclenchement d'outils et sur l'hébergement, avec vos propres mesures de latence sur vos propres tours ; notre article sur Mistral AI en entreprise couvre l'autre côté du match. Et si vous voulez qu'on tranche sur votre cas plutôt que dans l'abstrait, le plus rapide reste de contacter Noxcod avec vos volumes et vos contraintes de données.

Questions fréquentes

GLM 5.2 est-il utilisable dans un produit commercial ?

Oui. Les poids sont publiés sous licence MIT sur Hugging Face, ce qui autorise l'usage commercial, la modification et la redistribution, sans restriction régionale annoncée. Le dépôt de code associé est sous Apache 2.0. Vérifiez tout de même les conditions de votre hébergeur, qui ajoute ses propres règles contractuelles par-dessus la licence du modèle, notamment sur la localisation des données et la conservation des requêtes.

Peut-on héberger GLM 5.2 en Europe ?

Oui, de deux manières. Un endpoint managé européen le sert déjà, avec un contexte plafonné à 256 000 tokens pendant la préversion et une sortie limitée à 16 000 tokens. Ou vous l'auto-hébergez, ce qui suppose selon la recette de vLLM huit GPU H200 en FP8, soit environ 1 128 Go de mémoire vidéo. Entre les deux, il n'existe pas d'option légère : le modèle pèse environ 743 milliards de paramètres.

Faut-il couper le raisonnement pour un agent conversationnel ?

Pour de la voix ou du chat en temps réel, oui, sans hésiter. Sur notre endpoint managé en juillet 2026, avec notre prompt de production, le raisonnement actif nous a coûté 10 secondes avant le premier mot, et il augmente aussi le taux de réponses vides dans nos mesures. Pour du codage agentique en tâche de fond, gardez-le : c'est le régime pour lequel le modèle a été entraîné, et la latence n'y coûte rien d'autre que de l'attente.

Mon agent déclenche moins ses outils depuis que j'ai changé de modèle, que faire ?

Regardez la description de vos outils avant d'accuser le modèle. Nos transitions décrites en deux mots passaient de 0 à 15 déclenchements sur 20 selon la formulation du tour de l'appelant. Réécrivez chaque description comme une condition vérifiable, du genre « l'appelant a exprimé une demande de rendez-vous », puis remesurez sur vingt tirages minimum avant de conclure.

Combien coûte GLM 5.2 par million de tokens ?

Chez Z.ai, 1,40 dollar en entrée, 0,26 dollar en entrée mise en cache et 4,40 dollars en sortie. Chez l'hébergeur parisien que nous utilisons, 1,80 euro en entrée et 5,50 euros en sortie, sans tarif de cache affiché. Tarifs consultés le 30 juillet 2026. Sur un agent au prompt long, cette absence de cache pèse plus lourd sur la facture que l'écart de prix affiché.