GLM 5.2 : le reasoning effort, voilà le vrai levier de coût

GLM 5.2 est désormais disponible sur Synthorai à environ un sixième du prix par token des modèles frontier, et l’argument open-weight aux benchmarks dignes du frontier est bien réel. Mais le prix par token est le mauvais repère. Ce qu’une tâche de code coûte réellement sur GLM 5.2 varie de plus d’un ordre de grandeur selon un seul réglage, le reasoning effort, et le défaut place justement ce curseur dans sa pire position. Bien réglé, GLM 5.2 répond juste et coûte moins cher que le frontier, aussi bien sur les tâches faciles que difficiles. Laissé au défaut, la même réponse coûte vingt fois plus et prend plusieurs minutes. On l’a mesuré.

Ce qu’est GLM 5.2

GLM 5.2 est le modèle open-weight frontier de Zhipu, sorti le 2026-06-13 : un réseau mixture-of-experts (~744B au total, ~40B actifs), un contexte utilisable de 1M tokens, et une licence MIT qui permet l’auto-hébergement. Il vise le code et les tâches agentiques, avec des benchmarks publiés solides (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Sur Synthorai c’est glm-5.2, facturé 1,40 $ par million de tokens en entrée et 4,40 $ par million en sortie.

Le détail qui détermine tout ce qui suit : c’est un modèle de raisonnement, et le volume de raisonnement, c’est vous qui le fixez.

Sa place côté prix

Au prix par token affiché, GLM 5.2 se situe nettement sous le frontier occidental, parmi les modèles chinois les plus abordables. Les tarifs Synthorai pour un échantillon représentatif :

Son tarif de sortie à 4,40 $ représente environ un septième de gpt-5.5 et un sixième de claude-opus-4-8, même si deepseek-v4-pro et kimi-k2.5 font moins cher. GLM 5.2 offre donc une capacité de niveau frontier à des prix de modèle chinois, sans pour autant toucher le plancher absolu. Il n’y a pas de facturation séparée pour l’écriture en cache : une écriture est facturée au tarif d’entrée, et seule la lecture en cache bénéficie de la remise indiquée ci-dessus. Cette remise varie selon le fournisseur : pour GLM 5.2, la lecture en cache vaut environ un cinquième du tarif d’entrée, tandis que les modèles frontier (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) la ramènent à peu près au dixième.

C’est aussi un cran au-dessus de ses propres prédécesseurs. La génération GLM précédente était extraordinairement bon marché ; la ligne GLM 5 a relevé les prix, et GLM 5.2 arrive à environ 3x le tarif d’entrée de GLM-4.6 (tarifs officiels de Zhipu) :

C’est ce qui paie le contexte de 1M et les benchmarks frontier. Mais le tarif par token n’est que la façade. Ce que vous payez réellement par tâche dépend du reasoning effort.

Le curseur du reasoning effort

Le raisonnement de GLM 5.2 est un curseur, pas un interrupteur. Vous pouvez le couper (enable_thinking: false), régler reasoning_effort sur low, medium ou high, ou le laisser au défaut, qui fait tourner le raisonnement sans limite. Ce réglage modifie le coût et la latence bien plus que le prix lui-même. On a fait tourner une tâche de code facile et une difficile sur l’ensemble des réglages, en vérifiant chaque réponse contre une référence sur des centaines de cas randomisés.

Une tâche facile : le raisonnement ne fait qu’ajouter du coût

Ordonnancement d’intervalles pondérés, un problème de programmation dynamique de difficulté moyenne :

Deux points sautent aux yeux. D’abord, thinking désactivé donne la bonne réponse et reste l’option la moins chère du tableau, environ 8x sous les modèles de pointe ; chaque cran supplémentaire sur le curseur ne fait qu’ajouter du coût pour la même réponse. Ensuite, la facture suit le raisonnement, pas la réponse : le code renvoyé par GLM fait à chaque fois environ 150 tokens, tandis que le raisonnement qui le précède passe de zéro à environ 6,300, facturé au même tarif de $4.40/M en sortie. Le défaut sans limite dépense ce raisonnement pour atteindre la même réponse que thinking désactivé produisait sans rien, et cet écart représente la totalité de la différence de coût. Les modèles de pointe répondent ici avec peu ou pas de raisonnement rapporté : gpt-5.5 dépense 59 tokens de raisonnement, et l’usage de claude-opus-4-8 n’en rapporte aucun.

Une tâche difficile : le raisonnement justifie son coût, la valeur par défaut non

Le pattern matching avec wildcards (? et *), le problème classique qu’on rate facilement sur un détail. Ici, sans raisonnement, ça a cassé. Le modèle a renvoyé une récursion mémoïsée :

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

Ça a l’air correct, et la mémoïsation laisse même croire à un certain soin. Mais la branche * appelle match(i + 1, j) sans borner i. Une fois la chaîne consommée alors que le pattern contient encore un *, i grimpe à l’infini et la stack déborde. Rapide, pas cher, et faux.

Pousse le curseur et le modèle renvoie le bon algorithme itératif à deux pointeurs, qui revient au dernier * au lieu de récurser :

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

Le curseur complet sur cette tâche :

Tous les niveaux d’effort explicites ont résolu le problème. reasoning_effort: high l’a fait pour $0.0031 en 13 secondes, soit environ vingt fois moins cher et trente fois plus rapide que la valeur par défaut sans borne pour la même réponse, et il passe sous les modèles frontier en coût, à quelques secondes près. Une bizarrerie à connaître : le low de GLM a produit plus de raisonnement que le high, de façon constante sur les deux tâches, donc les noms ne reflètent pas le nombre de tokens. Medium et high étaient les réglages les moins chers et les plus rapides.

La valeur par défaut sans borne est le seul réglage à éviter. C’est le pire des deux mondes : elle paie pour un raisonnement dont la tâche n’a peut-être pas besoin et y met plusieurs minutes, pour arriver à la même réponse que reasoning_effort: high à vingt fois le coût.

La règle de décision

Le levier, c’est l’effort de raisonnement, et le bon réglage dépend de la tâche, pas du modèle :

• Travail simple ou à fort volume où la correction est facile : thinking off (enable_thinking: false). Correct, et environ 8x moins cher que le frontier.
• Problèmes plus durs où thinking off échoue : reasoning_effort: medium ou high. Correct, autour de $0.003 par tâche, sous le frontier en coût et seulement quelques secondes plus lent.
• Jamais la valeur par défaut sans borne. Laisser le raisonnement actif sans plafond d’effort, c’est ainsi qu’une réponse à $0.003 devient une réponse à $0.06 en sept minutes.

Si tu ne peux pas savoir à l’avance si une tâche a besoin de raisonnement, reasoning_effort: high est une valeur par défaut sûre : il est peu coûteux, il a résolu les deux tâches, et il ne s’est jamais emballé.

Le cache aide l’input, pas le raisonnement

GLM 5.2 prend en charge le cache au niveau du gateway, et il aide là où on l’attend. Nous avons envoyé un préfixe partagé de 1 494 tokens (un module de code à examiner) accompagné de plusieurs questions différentes :

Dès qu’un préfixe volumineux a été vu une fois, il se met en cache. Les tokens d’input en cache sont facturés à environ un cinquième du tarif d’input normal, ce qui a fait passer une requête par ailleurs identique de $0.0026 à $0.0009, soit environ 64 %. Une répétition exacte est servie directement depuis le cache sémantique : même réponse, même coût que l’appel mis en cache, mais de retour en une seconde environ au lieu de cinq.

Le piège est le même que celui révélé par le réglage : le cache réduit le coût de l’input, mais dès que le raisonnement est activé, le coût et la latence se logent dans l’output de raisonnement, qui n’est pas mis en cache. Le cache est donc un vrai gain pour les tâches sans réflexion et à fort contexte (le même system prompt ou la même codebase à chaque appel), et un gain minime une fois le raisonnement activé.

L’utiliser sur Synthorai

glm-5.2 est disponible sur le gateway. Trois remarques pratiques tirées de nos tests :

• Réglez explicitement l’effort de raisonnement. Utilisez enable_thinking: false pour les tâches simples et reasoning_effort: medium ou high pour les problèmes plus difficiles. La seule chose à éviter est de laisser le raisonnement activé sans plafond d’effort (la valeur par défaut, illimitée), qui est le piège à $0.06 et sept minutes.
• Utilisez le streaming quand le raisonnement est activé. Les réponses avec raisonnement peuvent durer plusieurs minutes, et une requête sans streaming reste suspendue sur une connexion silencieuse assez longtemps pour que votre client tombe probablement en timeout avant l’arrivée de la réponse. Avec stream: true, vous obtenez un output incrémental et le résultat complet.
• Réutilisez votre contexte. Si vous envoyez le même gros system prompt ou la même codebase à chaque appel, le cache de préfixe réduit le coût de l’input ; associé au raisonnement désactivé, il rend la requête entière bon marché.

Le tarif est de $1.40 / $4.40 par million de tokens, et le gateway renvoie un champ cost à chaque appel pour que vous voyiez exactement ce qu’a coûté chaque requête.

En résumé

GLM 5.2 est un modèle de code réellement bon marché et capable ; bien configuré, il bat les prix des modèles de pointe aussi bien sur les tâches faciles que difficiles. Le piège, c’est la configuration. Son raisonnement est un réglage, et la valeur par défaut le laisse illimité : c’est ainsi qu’une tâche qui devrait coûter $0.003 devient un appel à $0.06 et sept minutes. Mettez enable_thinking: false pour les tâches simples et reasoning_effort: medium ou high pour le reste, et GLM 5.2 est bon marché et correct sur toute la ligne. Laissez le raisonnement sur sa valeur par défaut, et c’est l’option la plus lente et la plus chère que vous pouviez choisir.

Sources

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

(Les prix affichés ci-dessus pour Synthorai sont les tarifs de cette plateforme au 2026-06-24 ; les tarifs par génération de GLM sont la liste officielle de Zhipu.)

Coûts mesurés sur Synthorai le 2026-06-24 (glm-5.2 à $1.40 / $4.40 par M de tokens) ; vérifiez les tarifs actuels avant de vous y fier.

← Retour au blog