A API gratuita do GLM-5.2 da NVIDIA é interessante por um motivo: a NVIDIA tornou um modelo pesado da Z.ai fácil de testar, mas os limites práticos do endpoint não são a mesma coisa que a capacidade total do modelo.
A versão curta:
Eu interpreto isso como uma configuração de avaliação útil. 40 solicitações por minuto são suficientes para protótipos, avaliações de agentes e comparações manuais. Os tokens máximos são a parte irritante, e é a parte que você precisa testar por conta própria, pois as especificações do modelo e os limites do endpoint do provedor podem divergir.
API Gratuita GLM-5.2 da NVIDIA: o que mudou
O GLM-5.2 é o novo modelo principal da Z.ai. A documentação do modelo da NVIDIA o descreve como um modelo Mixture-of-Experts de 753B de parâmetros, construído para tarefas de longo horizonte, agentes, codificação e uso de ferramentas. A própria documentação da Z.ai destaca contexto de 1M e até 128K tokens de saída.
Esse é o posicionamento em nível de modelo.
A página do NVIDIA Build é a camada prática. O GLM-5.2 está listado lá com um endpoint gratuito, endpoint de parceiro e opção de download. A amostra em Python chama o endpoint Integrate API compatível com OpenAI da NVIDIA com o modelo `z-ai/glm-5.2`. A amostra define `max_tokens` para 16.384.
Eu não escreveria "O GLM-5.2 é apenas 32k" como um fato do modelo. Eu escreveria isto em vez disso: no endpoint gratuito da NVIDIA, o espaço máximo de tokens parece ser limitado pelo provedor em comparação com a janela de contexto maior do modelo. Se você vir 32k na prática, trate isso como uma observação do endpoint que precisa ser testada contra sua conta, formato de solicitação e configuração atual da NVIDIA.
Essa distinção importa. Um modelo pode suportar contexto longo enquanto um endpoint gratuito expõe limites de saída menores, menos capacidades e limites de taxa mais rigorosos.
Benchmarks: GLM-5.2 vs GLM-5.1
A NVIDIA publica números de benchmark do GLM-5.2 contra o GLM-5.1 e vários outros modelos de fronteira. A comparação mais limpa começa com o GLM-5.1 porque mostra para onde a Z.ai moveu o modelo.
| Benchmark | GLM-5.2 | GLM-5.1 | Diferença | Por que importa |
|---|---|---|---|---|
| --- | ---: | ---: | ---: | --- |
| HLE | 40.5 | 31.0 | +9.5 | Tarefas difíceis de conhecimento e raciocínio |
| HLE com ferramentas | 54.7 | 52.3 | +2.4 | Resolução de problemas suportada por ferramentas |
| AIME 2026 | 99.2 | 95.3 | +3.9 | Matemática de competição e raciocínio estrito |
| GPQA-Diamond | 91.2 | 86.2 | +5.0 | Perguntas de ciência de nível especialista |
| SWE-bench Pro | 62.1 | 58.4 | +3.7 | Correções de código em ambientes semelhantes a repositórios |
| NL2Repo | 48.9 | 42.7 | +6.2 | Construção de código a partir de linguagem natural através do contexto do repositório |
| Terminal Bench 2.1 | 81.0 | 63.5 | +17.5 | Tarefas de engenharia baseadas em terminal |
| MCP-Atlas | 76.8 | 71.8 | +5.0 | Tarefas de agentes orientadas a MCP e ferramentas |
| Tool-Decathlon | 48.2 | 40.7 | +7.5 | Habilidade ampla de uso de ferramentas |
Raciocínio e matemática
AIME 2026 em 99.2 e GPQA-Diamond em 91.2 são números fortes. Eles mostram que o GLM-5.2 não está posicionado apenas como um modelo de codificação. Ele também avança fortemente no raciocínio estrito, perguntas de especialistas e tarefas onde o modelo não pode se safar com correspondência de padrões vagos.
Fluxos de trabalho de codificação e agentes
O número que se destaca para mim é o Terminal Bench 2.1: 81.0 vs 63.5. Isso não é uma melhoria cosmética. Se esse resultado se mantiver em testes práticos, o GLM-5.2 se torna interessante para trabalho em repositórios, fluxos de trabalho de CLI e tarefas de engenharia agêntica onde o modelo precisa inspecionar estado, executar etapas, interpretar erros e continuar.
É aí que eu começaria a testar. Sem prompts poéticos. Sem chat genérico. Eu o colocaria contra fluxos de trabalho de desenvolvimento reais: builds quebrados, pequenas correções de PR, depuração orientada a repositório e trabalho com MCP onde o modelo precisa manter várias ferramentas alinhadas com o objetivo.
40 solicitações por minuto é melhor do que parece
40 RPM soa baixo se você pensar em um sistema de produção com muitos usuários concorrentes. Para avaliações, é uma história diferente.
40 solicitações por minuto são suficientes para:
Não é suficiente para:
Para mim, o GLM-5.2 no endpoint gratuito da NVIDIA é uma superfície de avaliação, não uma superfície de produção. É assim que eu o usaria primeiro.
Tenho algumas ideias de aplicativos e agentes que quero testar com modelos como este, mas não vou revelá-los antes de executar testes reais. 40 RPM é suficiente para aprender se o modelo entende o fluxo de trabalho. Não é suficiente para provar que ele se sustenta em produção.
Tokens máximos: 32k é o limite a medir
Se o endpoint lhe der 32k de tokens máximos na prática, isso não é inútil. Ainda é uma restrição real.
Para prompts de codificação normais, 32k de saída é muito. Para fluxos longos de agentes, contexto completo de repositório, logs longos e patches gerados, pode ficar apertado rapidamente. Isso é especialmente verdadeiro quando você quer que o modelo raciocine, planeje, retorne código e preserve a rastreabilidade.
Esta é a lista de testes que eu executaria:
| Teste | O que eu mediria |
|---|---|
| --- | --- |
| Prompt longo de repositório | O modelo descarta arquivos ou restrições importantes? |
| Log grande mais correção | Ele consegue encontrar a causa raiz sem reescrever o módulo errado? |
| Saída de patch | A resposta está completa ou truncada? |
| Loop de uso de ferramentas | Ele mantém o estado através de várias etapas? |
| Carga de 40 RPM | Quando os erros 429 começam e quão estável é o retry/backoff? |
| Teto de tokens | O limite é 16k, 32k ou dependente da conta/endpoint? |
| Modelo de comparação | Ele supera o modelo atual na mesma tarefa ou apenas em benchmarks publicados? |
A última linha é a mais importante. Benchmarks dizem onde o modelo pode ser forte. Suas próprias tarefas dizem se ele é útil.
Uma ressalva da NVIDIA
A documentação da API da NVIDIA descreve o GLM-5.2 com suporte para chat multi-turno, chamada de ferramentas, saída estruturada e traços de raciocínio. Ao mesmo tempo, a página do NVIDIA Build para o modelo gratuito mostra "Function Calling", "Structured Output" e "Reasoning" como "Não suportado" na barra lateral.
Eu não assumiria funcionalidade completa de agente porque o modelo pode suportá-la em algum lugar. Eu testaria o endpoint real da NVIDIA como uma superfície de chat/completions compatível com OpenAI primeiro, depois verificaria cada recurso separadamente.
Esta é uma divisão comum de provedores: o card do modelo descreve o modelo, enquanto o endpoint descreve o produto que você pode usar.
Verificação de alegações
Minha primeira impressão
O GLM-5.2 parece forte nos benchmarks certos. O sinal mais claro para mim não é o número do AIME, embora 99.2 seja extremo. O sinal mais útil é a combinação de Terminal Bench 2.1, NL2Repo, SWE-bench Pro, MCP-Atlas e Tool-Decathlon.
É aí que um modelo começa a importar para fluxos de trabalho reais de desenvolvedores.
O endpoint gratuito da NVIDIA reduz a barreira. 40 RPM o torna útil para testes sérios. O limite de tokens máximos significa que você não deve tratá-lo como uma superfície de produção completa ainda.
Minha opinião: vale a pena fazer benchmark do GLM-5.2 contra seus próprios fluxos de trabalho de agentes agora. Registre cada solicitação, meça o truncamento de saída, execute os mesmos casos contra outros modelos e trate a API gratuita da NVIDIA como um banco de testes até verificar os limites na prática.
O trabalho não é correr atrás de hype. O trabalho é descobrir se o modelo resolve tarefas reais sem forçá-lo a construir todo o sistema em torno de suas fraquezas.