Les niveaux d'effort GLM sont le contrôle, requête par requête, dont dispose le modèle GLM phare sur la quantité de calcul consacrée à une tâche. Il y en a trois — Non-Thinking, High et Max — et choisir entre eux est le réglage le plus lourd de conséquences à votre disposition, car sur la courbe publiée l'écart entre le réglage le moins cher et le plus cher représente environ onze points de précision et 2.4× plus de tokens de sortie.
Un modèle GLM n'a pas une seule vitesse. Traiter le niveau d'effort comme une décision par tâche plutôt que comme un réglage global est ce qui rend la fonctionnalité utile : le travail de routine coûte peu, le travail difficile obtient le calcul dont il a besoin, et rien ne paie pour une profondeur qu'il n'utilise pas. Les chiffres ci-dessous sont tels que publiés par les auteurs du modèle.
La courbe publiée, moyennée sur Terminal-Bench 2.1, DeepSWE et SWE-Atlas QnA sous Claude Code 2.1.167, se présente à peu près comme suit. Les chiffres de tokens correspondent aux tokens de sortie moyens par tâche, c'est-à-dire au coût qui varie réellement.
Modifications rapides, code répétitif, refactorisations de routine où la latence prime sur la profondeur.
Le réglage par défaut pour la plupart des tâches de code agentique : une qualité proche de Max pour environ la moitié des tokens.
Problèmes difficiles et de longue haleine — allouez du calcul supplémentaire quand la tâche le justifie vraiment.
Moyenne sur Terminal-Bench 2.1, DeepSWE et SWE-Atlas QnA, évalués sur Claude Code 2.1.167. Chiffres annoncés par les auteurs du modèle. À budget de tokens comparable, GLM-5.2 se situe entre Claude Opus 4.7 et Opus 4.8.
Les deux paliers ne se valent pas. Passer de Non-Thinking à High rapporte environ neuf points de précision pour environ 23 % de tokens de sortie en plus — un échange sans ambiguïté favorable pour presque toute tâche qui vous importe. Passer de High à Max rapporte environ deux points de plus pour environ 93 % de tokens en plus, ce qui n'est un bon échange que lorsque ces deux points décident de la réussite ou de l'échec de la tâche.
Cette asymétrie explique pourquoi High est le réglage par défaut en pratique. Elle explique aussi pourquoi activer Max partout est une erreur courante et coûteuse : sur une file de tâches de routine, cela double presque la dépense en tokens pour un gain quasi nul, alors que sur des problèmes vraiment difficiles et de longue haleine, c'est le réglage qui fait la différence. À budgets de tokens comparables, les auteurs du modèle situent GLM-5.2 entre Claude Opus 4.7 et Opus 4.8. Il vaut aussi la peine de noter ce que la courbe ne dit pas. Ce sont des moyennes sur trois évaluations : le point de bascule sur votre propre charge de travail peut donc se situer n'importe où — une distribution de tâches dominée par de courtes modifications tirera encore moins de bénéfice de Max que la moyenne ne le suggère, tandis qu'une distribution dominée par du débogage de plusieurs heures pourra en tirer bien davantage. La forme de la courbe se transpose ; les chiffres exacts, non.
Aiguillez par classe de tâche plutôt que par préférence. Une politique par défaut viable ressemble à ceci :
Tous les chiffres de cette page sont des résultats tels que publiés par les auteurs du modèle. glmmodel.com les rapporte ; il n'exécute pas ces évaluations.
Consultez les benchmarks des modèles GLM, puis mettez un vrai modèle au travail. Le playground ci-dessus est gratuit et ne demande rien ; si vous cherchez une boîte à outils IA plus complète, l'offre gratuite de notre partenaire commence ici.