L'API gratuite GLM-5.2 de NVIDIA est intéressante pour une raison : NVIDIA a rendu un modèle lourd de Z.ai facile à tester, mais les limites pratiques du point de terminaison (endpoint) ne sont pas la même chose que la capacité complète du modèle.
En bref :
Je vois cela comme une configuration d'évaluation utile. 40 requêtes par minute suffisent pour les prototypes, les évaluations d'agents et les comparaisons manuelles. Les tokens maximum sont la partie irritante, et c'est la partie que vous devez tester vous-même car les spécifications du modèle et les limites des points de terminaison des fournisseurs peuvent diverger.
API gratuite GLM-5.2 de NVIDIA : ce qui a changé
GLM-5.2 est le nouveau modèle phare de Z.ai. La documentation du modèle de NVIDIA le décrit comme un modèle Mixture-of-Experts de 753 milliards de paramètres conçu pour les tâches à long horizon, les agents, le codage et l'utilisation d'outils. La documentation propre à Z.ai met en avant un contexte de 1M et jusqu'à 128K tokens de sortie.
C'est le positionnement au niveau du modèle.
La page NVIDIA Build représente la couche pratique. GLM-5.2 y est répertorié avec un point de terminaison gratuit, un point de terminaison partenaire et une option de téléchargement. L'exemple Python appelle le point de terminaison Integrate API compatible OpenAI de NVIDIA avec le modèle `z-ai/glm-5.2`. L'exemple définit `max_tokens` à 16 384.
Je n'écrirais pas « GLM-5.2 est seulement 32k » comme un fait concernant le modèle. J'écrirais plutôt ceci : sur le point de terminaison gratuit de NVIDIA, l'espace de tokens maximum semble être limité par le fournisseur par rapport à la fenêtre de contexte plus large du modèle. Si vous observez 32k en pratique, traitez-le comme une observation au niveau du point de terminaison qui doit être testée par rapport à votre compte, à la forme de la requête et à la configuration actuelle de NVIDIA.
Cette distinction est importante. Un modèle peut prendre en charge un contexte long tandis qu'un point de terminaison gratuit expose des limites de sortie plus faibles, moins de capacités et des limites de débit plus strictes.
Benchmarks : GLM-5.2 vs GLM-5.1
NVIDIA publie les chiffres des benchmarks de GLM-5.2 par rapport à GLM-5.1 et plusieurs autres modèles de pointe. La comparaison la plus propre commence avec GLM-5.1 car elle montre où Z.ai a fait évoluer le modèle.
| Benchmark | GLM-5.2 | GLM-5.1 | Différence | Pourquoi c'est important |
|---|---|---|---|---|
| --- | ---: | ---: | ---: | --- |
| HLE | 40.5 | 31.0 | +9.5 | Tâches difficiles de connaissances et de raisonnement |
| HLE avec outils | 54.7 | 52.3 | +2.4 | Résolution de problèmes assistée par des outils |
| AIME 2026 | 99.2 | 95.3 | +3.9 | Mathématiques de compétition et raisonnement strict |
| GPQA-Diamond | 91.2 | 86.2 | +5.0 | Questions scientifiques de niveau expert |
| SWE-bench Pro | 62.1 | 58.4 | +3.7 | Corrections de code dans des environnements de type dépôt |
| NL2Repo | 48.9 | 42.7 | +6.2 | Génération de code à partir du langage naturel dans le contexte d'un dépôt |
| Terminal Bench 2.1 | 81.0 | 63.5 | +17.5 | Tâches d'ingénierie basées sur le terminal |
| MCP-Atlas | 76.8 | 71.8 | +5.0 | Tâches d'agents orientées MCP et outils |
| Tool-Decathlon | 48.2 | 40.7 | +7.5 | Capacité large d'utilisation d'outils |
Raisonnement et mathématiques
AIME 2026 à 99.2 et GPQA-Diamond à 91.2 sont des chiffres solides. Ils montrent que GLM-5.2 n'est pas positionné uniquement comme un modèle de codage. Il pousse également fort sur le raisonnement strict, les questions d'experts et les tâches où le modèle ne peut pas se contenter d'une correspondance de motifs vague.
Flux de codage et d'agents
Le chiffre qui me marque est Terminal Bench 2.1 : 81.0 contre 63.5. Ce n'est pas une amélioration cosmétique. Si ce résultat se confirme dans des tests pratiques, GLM-5.2 devient intéressant pour le travail sur les dépôts, les flux CLI et les tâches d'ingénierie agentiques où le modèle doit inspecter l'état, exécuter des étapes, interpréter les erreurs et continuer.
C'est là que je commencerais les tests. Pas de prompts poétiques. Pas de chat générique. Je le mettrais à l'épreuve de flux de développement réels : builds cassés, petites corrections de PR, débogage orienté dépôt, et travail MCP où le modèle doit garder plusieurs outils alignés avec l'objectif.
40 requêtes par minute est mieux qu'il n'y paraît
40 RPM semble faible si l'on pense à un système de production avec de nombreux utilisateurs simultanés. Pour les évaluations, c'est une autre histoire.
40 requêtes par minute suffisent pour :
Ce n'est pas suffisant pour :
Pour moi, GLM-5.2 sur le point de terminaison gratuit de NVIDIA est une surface d'évaluation, pas une surface de production. C'est ainsi que je l'utiliserais en premier.
J'ai quelques idées d'applications et d'agents que je veux tester avec des modèles comme celui-ci, mais je ne les révèle pas avant d'avoir effectué de vrais tests. 40 RPM suffit pour apprendre si le modèle comprend le flux de travail. Ce n'est pas suffisant pour prouver qu'il tient la route en production.
Tokens maximum : 32k est la limite à mesurer
Si le point de terminaison vous donne 32k tokens maximum en pratique, ce n'est pas inutile. C'est toujours une contrainte réelle.
Pour les prompts de codage normaux, 32k de sortie est beaucoup. Pour les longs flux d'agents, le contexte complet du dépôt, les longs journaux et les correctifs générés, cela peut devenir serré très rapidement. C'est particulièrement vrai lorsque vous voulez que le modèle raisonne, planifie, renvoie du code et préserve la traçabilité.
Voici la liste de tests que je lancerais :
| Test | Ce que je mesurerais |
|---|---|
| --- | --- |
| Prompt long de dépôt | Le modèle abandonne-t-il des fichiers ou des contraintes importants ? |
| Grand journal plus correction | Peut-il trouver la cause racine sans réécrire le mauvais module ? |
| Sortie de correctif | La réponse est-elle complète ou tronquée ? |
| Boucle d'utilisation d'outils | Garde-t-il l'état sur plusieurs étapes ? |
| Charge 40 RPM | Quand les erreurs 429 commencent-elles, et quelle est la stabilité du retry/backoff ? |
| Plafond de tokens | La limite est-elle de 16k, 32k, ou dépend-elle du compte/du point de terminaison ? |
| Modèle de comparaison | Bat-il le modèle actuel sur la même tâche, ou seulement dans les benchmarks publiés ? |
La dernière ligne est la plus importante. Les benchmarks vous disent où le modèle peut être fort. Vos propres tâches vous disent s'il est utile.
Une mise en garde NVIDIA
La documentation de l'API de NVIDIA décrit GLM-5.2 avec la prise en charge du chat multi-tours, de l'appel d'outils, de la sortie structurée et des traces de raisonnement. Dans le même temps, la page NVIDIA Build pour le modèle gratuit indique « Function Calling », « Structured Output » et « Reasoning » comme « Non pris en charge » dans la barre latérale.
Je ne supposerais pas une fonctionnalité d'agent complète parce que le modèle peut la prendre en charge quelque part. Je testerais d'abord le point de terminaison réel de NVIDIA comme une surface de chat/completions compatible OpenAI, puis je vérifierais chaque fonctionnalité séparément.
C'est une séparation courante chez les fournisseurs : la fiche du modèle décrit le modèle, tandis que le point de terminaison décrit le produit que vous pouvez utiliser.
Vérification des affirmations
Ma première lecture
GLM-5.2 semble fort sur les bons benchmarks. Le signal le plus clair pour moi n'est pas le chiffre AIME, même si 99.2 est extrême. Le signal le plus utile est la combinaison de Terminal Bench 2.1, NL2Repo, SWE-bench Pro, MCP-Atlas et Tool-Decathlon.
C'est là qu'un modèle commence à compter pour les vrais flux de travail des développeurs.
Le point de terminaison gratuit de NVIDIA abaisse la barrière. 40 RPM le rend utile pour des tests sérieux. La limite de tokens maximum signifie que vous ne devriez pas encore le traiter comme une surface de production complète.
Mon avis : GLM-5.2 vaut la peine d'être benchmarké contre vos propres flux de travail d'agents maintenant. Enregistrez chaque requête, mesurez la troncature de la sortie, exécutez les mêmes cas contre d'autres modèles et traitez l'API gratuite de NVIDIA comme un banc d'essai jusqu'à ce que vous vérifiiez les limites en pratique.
Le travail ne consiste pas à courir après le battage médiatique. Le travail consiste à découvrir si le modèle résout de vraies tâches sans vous forcer à construire tout le système autour de ses faiblesses.