GLM-5.2 da Z.ai (Zhipu AI) chegou com uma pilha de números de benchmark, e alguns deles são genuinamente impressionantes. A manchete é o SWE-bench Pro com 62.1, superando o GPT-5.5. A história maior está enterrada uma linha abaixo: o Terminal-Bench saltou de 62.0 para 81.0 em uma única geração. Este post detalha cada pontuação de benchmark do GLM-5.2, explica o que o teste realmente mede e aponta onde a liderança é real versus onde é um erro de arredondamento.
Todos os números de lançamento aqui são resultados publicados pela Z.ai, a menos que indicado o contrário. Quando um modelo afirma superar os concorrentes em suas próprias avaliações, você lê com uma sobrancelha levantada. Então, seremos específicos sobre o que cada benchmark prova e o que não prova.
A versão curta: pontuações de benchmark do GLM-5.2 em resumo
Aqui está a tabela completa de benchmarks do GLM-5.2, com os rivais mais próximos para contexto. Trate as colunas de comparação como os números reportados pela Z.ai para esses modelos, e não como reexecuções independentes.
| Benchmark | O que mede | GLM-5.2 | GLM-5.1 | GPT-5.5 | Claude Opus 4.8 |
|---|---|---|---|---|---|
| SWE-bench Pro | Correções de bugs em repositórios do mundo real | 62.1 | 58.4 | 58.6 | n/a |
| Terminal-Bench 2.1 | Tarefas multi-etapas de shell/agente | 81.0 | 62.0 | n/a | n/a |
| MCP-Atlas | Uso de ferramentas em servidores MCP | 77.0 | n/a | 75.3 | 77.8 |
| Último Exame da Humanidade (c/ ferramentas) | Raciocínio especializado difícil | 54.7 | n/a | 52.2 | n/a |
| AIME 2026 | Matemática de competição | 99.2 | n/a | n/a | n/a |
| GPQA-Diamond | Ciência em nível de pós-graduação | 91.2 | n/a | n/a | n/a |
A Z.ai também relata o GLM-5.2 como o modelo de código aberto com maior pontuação no FrontierSWE, PostTrainBench e SWE-Marathon. Abordaremos o que esse qualificador (“código aberto”) significa.

Para a versão em linguagem simples do que este modelo é, veja a visão geral do GLM-5.2. Para saber como ele se compara aos modelos proprietários, há uma análise dedicada GLM-5.2 vs GPT-5.5, Opus e Gemini.
SWE-bench Pro: 62.1 e o que ele realmente indica
O SWE-bench Pro é o primo mais difícil e curado do SWE-bench original. Ele entrega a um modelo um problema real do GitHub mais o repositório completo, e pede que ele produza um patch que faça a suíte de testes oculta do projeto passar. Sem múltipla escolha, sem funções de brinquedo. Você conserta o bug em arquivos reais ou não.
O GLM-5.2 pontua 62.1. O GPT-5.5 está em 58.6 e o GLM-5.1 em 58.4, de acordo com a Z.ai. Então, duas conclusões honestas:
- A liderança de 3.5 pontos sobre o GPT-5.5 é significativa, mas não um abismo. Em um benchmark tão ruidoso, alguns pontos podem variar devido a detalhes do ambiente de teste, orçamentos de retentativa e estrutura de prompts. Chame de “competitivo no topo”, não “dominante”.
- O ganho de 3.7 pontos sobre o GLM-5.1 é o sinal mais confiável, porque é o mesmo laboratório medindo da mesma forma em dois de seus próprios modelos. As diferenças de geração para geração são a leitura mais clara que você obtém.
Por que se importar com o SWE-bench Pro? Porque é o proxy público mais próximo para “este modelo consegue fazer meu trabalho real”. Corrigir um bug em uma base de código extensa requer ler código não familiar, localizar o arquivo certo e editar sem quebrar outras três coisas. Essa é a realidade diária do trabalho com software, razão pela qual os modelos focados em codificação são avaliados nele primeiro.
Terminal-Bench 2.1: 81.0 é o número de destaque
Se você ler uma linha na tabela, leia esta. O Terminal-Bench avalia um modelo como um agente em um shell real: instalar dependências, executar comandos, analisar a saída, recuperar-se de erros e completar uma tarefa de várias etapas do início ao fim. Ele recompensa a persistência e a disciplina no uso de ferramentas, não a astúcia de uma única tentativa.
O GLM-5.1 pontuou 62.0. O GLM-5.2 pontua 81.0. Isso representa um salto de 19 pontos em uma geração, e é a estatística de desempenho de destaque do GLM-5.2 por uma razão. Passar de “falha em cerca de quatro de cada dez tarefas” para “completa cerca de quatro de cada cinco” é a diferença entre um modelo que você tem que supervisionar e um que você pode entregar um terminal.
É também aqui que a história da arquitetura se conecta à história do benchmark. A Z.ai credita a atenção esparsa “IndexShare” do GLM-5.2, que reutiliza um indexador a cada quatro camadas de atenção esparsa para manter os custos de atenção baixos em contextos longos. Tarefas de agente de longo horizonte geram transcrições longas: comando, saída, comando, saída, por dezenas de turnos. Um modelo que mantém esse contexto de forma barata e precisa é um modelo que não se perde no meio de uma construção. O salto no Terminal-Bench é a recompensa prática desse design. Para a comparação geracional completa, veja GLM-5.2 vs GLM-5.1.
Uma ressalva honesta: o Terminal-Bench é um número relatado pela Z.ai, e benchmarks de agentes são sensíveis à estrutura em torno do modelo (limites de tempo, retentativas permitidas, o prompt do harness). O salto é grande o suficiente para que a estrutura sozinha provavelmente não o explique, mas verifique em sua própria carga de trabalho antes de apostar um pipeline nele.
MCP-Atlas: 77.0, e um empate honesto no topo
O MCP-Atlas mede o uso de ferramentas através do Model Context Protocol, a forma padrão como os modelos chamam ferramentas e servidores externos. É o benchmark que se alinha mais diretamente ao trabalho de agente e API: o modelo consegue escolher a ferramenta certa, formatar a chamada corretamente, ler o resultado e continuar.
O GLM-5.2 chega a 77.0. O GPT-5.5 está em 75.3, e o Claude Opus 4.8 em 77.8, de acordo com a Z.ai. Esta é a linha onde você deve resistir à tentação de declarar um vencedor. O GLM-5.2 supera o GPT-5.5 por 1.7 e fica atrás do Opus 4.8 por 0.8. Essas são margens de erro de arredondamento. A afirmação justa é que, no uso de ferramentas no estilo MCP, os três estão em um empate técnico, e o GLM-5.2 conquistou seu lugar nesse grupo.
Isso importa porque o uso de ferramentas é onde um modelo de codificação encontra sua pilha tecnológica. Cada chamada MCP é, funcionalmente, uma interação de API: uma requisição estruturada, uma resposta para analisar, um erro para tratar. Se você está conectando um modelo a serviços reais, você quer a mesma higiene que aplicaria a qualquer integração. É exatamente aqui que o Apidog se encaixa. Você pode definir e simular os endpoints que um agente irá acessar, então depurar as cargas de requisição e resposta reais que o modelo gera, antes de liberá-lo para produção. Baixe o Apidog se você quiser testar essas chamadas de ferramentas da mesma forma que testaria qualquer outra API.

Raciocínio e matemática: HLE 54.7, AIME 99.2, GPQA-Diamond 91.2
Codificação não é toda a história. O GLM-5.2 também apresenta fortes números de raciocínio.
- Último Exame da Humanidade (com ferramentas): 54.7. O HLE é um exame deliberadamente brutal, abrangendo questões de nível especializado em muitos campos, construído para resistir à saturação fácil. A configuração “com ferramentas” permite que o modelo pesquise e compute em vez de responder friamente. O 54.7 do GLM-5.2 supera o 52.2 do GPT-5.5 (segundo a Z.ai). Em um benchmark tão difícil, qualquer coisa na casa dos 50 é um resultado sério.
- AIME 2026: 99.2. O AIME é uma competição de matemática para estudantes do ensino médio com alto desempenho. Um 99.2 é efetivamente uma pontuação de teto, o que principalmente indica que o teste não mais diferencia modelos de fronteira. É um sinal de “sem fraquezas aqui” mais do que um diferenciador.
- GPQA-Diamond: 91.2. O GPQA-Diamond é a parte mais difícil de um conjunto de perguntas e respostas de ciência em nível de pós-graduação, filtrado para que não especialistas não possam resolvê-lo por força bruta, mesmo com acesso à web. Um 91.2 coloca o GLM-5.2 firmemente em território de fronteira no raciocínio técnico.
O padrão em tudo isso: o GLM-5.2 não é um especialista em código restrito que se desfaz em matemática ou ciência. Os dois níveis de esforço de pensamento (High e Max, com Max recomendado para codificação) permitem que você troque latência por profundidade em problemas mais difíceis. Se você quer o ângulo mais profundo de matemática e raciocínio ao lado da codificação, o artigo Benchmarks do GLM-5.2 vs os concorrentes aprofunda essa comparação.
A afirmação de “maior pontuação de código aberto”, detalhada
A Z.ai relata o GLM-5.2 como o principal modelo de código aberto no FrontierSWE, PostTrainBench e SWE-Marathon. Leia esse qualificador com atenção, porque ele tem um significado importante.
“O de código aberto com maior pontuação” é uma afirmação mais restrita do que “o de maior pontuação, ponto final”. O campo de pesos abertos é o contexto relevante aqui: o GLM-5.2 é lançado sob uma licença MIT com pesos abertos e sem restrições regionais, o que é uma proposta diferente de um modelo de API fechado que você aluga. Contra outros modelos de pesos abertos, ser o melhor no FrontierSWE (tarefas de software de dificuldade de fronteira), PostTrainBench (capacidade pós-treinamento) e SWE-Marathon (trabalho de software longo e sustentado) é uma afirmação forte, e é a afirmação que importa se sua restrição é “deve ser auto-hospedável”.
Não é o mesmo que superar todos os modelos proprietários nesses testes. Onde o GLM-5.2 realmente supera o GPT-5.5, como no SWE-bench Pro e HLE, a Z.ai afirma isso diretamente, sem a ressalva de código aberto. Então, o modelo mental é: na fronteira ou perto dela no geral, e claramente o primeiro entre os modelos que você pode baixar e executar por conta própria. O VentureBeat descreveu o valor de forma direta, relatando que o GLM-5.2 “supera o GPT-5.5 em codificação de longo prazo por aproximadamente um sexto do custo”. Essa é a caracterização do VentureBeat, que vale a pena atribuir em vez de afirmar como um fato medido.
Especificações do GLM-5.2 em resumo
Benchmarks só significam algo em relação à realidade do hardware e licenciamento. Aqui estão as especificações do GLM-5.2 que moldam como as pontuações se traduzem para sua configuração.
| Especificação | Valor |
|---|---|
| Parâmetros | ~753B total, mistura de especialistas (MoE) |
| Precisão | BF16 |
| Atenção | Atenção esparsa IndexShare (um indexador compartilhado por 4 camadas esparsas) |
| Janela de contexto | 1M de tokens (1.048.576) |
| Saída máxima | Até 128K por documentação da z.ai (verificar ao vivo; OpenRouter não lista um valor) |
| Modalidade | Texto de entrada, texto de saída (nenhuma variante de visão confirmada) |
| Esforço de raciocínio | Alto e Máximo; pode ser desabilitado |
| Licença | MIT, pesos abertos, sem restrições regionais |
| IDs do modelo | HF zai-org/GLM-5.2, API glm-5.2, Ollama glm-5.2, OpenRouter z-ai/glm-5.2 |
Algumas notas sobre a leitura desta barra lateral. A contagem de ~753B parâmetros é o tamanho total do MoE, não a contagem ativa por token, então não a interprete como “precisa de 753B de computação densa por passagem direta”, esse é o ponto do MoE. O contexto de 1M de tokens é a especificação que torna o resultado do Terminal-Bench crível: execuções longas de agentes precisam de um lugar para colocar todo esse histórico. Quanto à saída máxima, tenha cuidado. A documentação da Z.ai cita até 128K (a partir de junho de 2026, verifique o limite atual em z.ai), mas não é consistentemente listado entre os provedores, então trate-o como um teto documentado em vez de um garantido. E não existe um modelo de visão GLM-5.2. Se você vir “GLM-5.2V” em algum lugar, não é algo que a Z.ai tenha confirmado.
O preço segue a lógica dos pesos abertos: o OpenRouter lista $1.40 por 1M de tokens de entrada e $4.40 por 1M de saída, com entrada em cache em torno de $0.26 por 1M (dado do VentureBeat). Esse perfil de custo é a espinha dorsal da linha “um sexto do custo”. Para o detalhamento completo dos custos, incluindo os níveis do Plano de Codificação GLM, veja a página de preços do GLM-5.2, e se você quiser executá-lo sem pagar por token, como usar o GLM-5.2 gratuitamente cobre a rota de auto-hospedagem.
Como verificar esses benchmarks por conta própria
Os cartões de pontuação do fornecedor são um ponto de partida, não um veredito. Três coisas a fazer antes de confiar em qualquer um desses números para uma decisão real:
- Leia as fontes primárias. O blog GLM-5.2 da Z.ai e a documentação da Z.ai contêm a metodologia oficial. O cartão do modelo no Hugging Face possui os pesos e a configuração, caso você queira inspecionar a arquitetura diretamente.
- Verifique listagens de terceiros. A página do OpenRouter confirma os preços e o ID do modelo, e a entrada da biblioteca Ollama confirma o caminho de execução local. A cobertura da VentureBeat adiciona um enquadramento externo sobre a questão do custo.
- Execute sua própria avaliação. O único benchmark que realmente importa é sua carga de trabalho. Conecte o GLM-5.2 a uma tarefa real, idealmente uma tarefa de agente com chamadas de ferramentas, e observe como ele se comporta ao longo de muitas interações. Para contexto de gerações anteriores sobre este exato exercício, o artigo GLM-5.1 e a comparação GLM-5 vs DeepSeek vs GPT-5: velocidade e custo são linhas de base úteis.
Quando você executa essa avaliação da sua própria carga de trabalho, as chamadas de ferramentas são onde os modelos silenciosamente falham: JSON malformado, seleção de ferramenta errada, tratamento de erros ignorado. Simular esses endpoints no Apidog permite que você observe as requisições e respostas reais do modelo sem sobrecarregar os serviços em produção, que é a maneira mais rápida de diferenciar um herói de benchmark de um modelo que funciona em sua pilha.
Conclusão
A folha de benchmarks do GLM-5.2 resiste ao escrutínio melhor do que a maioria dos cartões de pontuação de lançamento. O salto do Terminal-Bench de 62.0 para 81.0 é o número genuinamente grande, a liderança do SWE-bench Pro sobre o GPT-5.5 é real, embora modesta, e o resultado do MCP-Atlas é um empate honesto entre três no topo. Combine essas pontuações com pesos abertos, uma licença MIT, um contexto de 1M de tokens e uma economia de aproximadamente um sexto do custo, e você obtém um modelo que merece uma avaliação séria em vez de um olhar superficial.
Os benchmarks apontam para o modelo certo. Sua própria carga de trabalho o confirma. Ao executar esse teste e ele envolver chamadas reais de API e ferramentas, configure os endpoints no Apidog para que você possa ver exatamente o que o modelo envia e recebe, então decida com base no que ele faz em sua pilha, e não no que ele pontuou na de outra pessoa.
