GLM-5.2: Desempenho e Especificações – SWE-bench Pro, Terminal-Bench e Análise dos Dados

Benchmarks do GLM-5.2 decifrados: SWE-bench Pro 62.1, Terminal-Bench 81.0, MCP-Atlas 77.0, além de especificações, contexto, licença, e o que cada pontuação realmente significa.

INEZA Felin-Michel

INEZA Felin-Michel

17 junho 2026

GLM-5.2: Desempenho e Especificações – SWE-bench Pro, Terminal-Bench e Análise dos Dados

Apidog para empresas

Implantação local

SSO & RBAC

Conforme SOC 2

Explorar Apidog Enterprise

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.

💡
Se você cria ou testa APIs ao avaliar modelos como este, o Apidog é a plataforma completa que usamos para projetar, depurar, simular e documentar os endpoints que esses modelos chamam. Mais sobre isso depois, mas é relevante: muitos dos ganhos do GLM-5.2 aparecem em trabalhos com agentes e uso de ferramentas, que é exatamente o território das APIs.
botão

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:

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.

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:

  1. 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.
  2. 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.
  3. 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.

Pratique o design de API no Apidog

Descubra uma forma mais fácil de construir e usar APIs