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

GLM-5.2 da Z.ai (Zhipu AI) chegou com uma lista agressiva de benchmarks. A manchete é o SWE-bench Pro com 62.1, acima do GPT-5.5. Mas o número mais importante para desenvolvedores é outro: o Terminal-Bench saltou de 62.0 para 81.0 em uma única geração. Neste guia, vamos ler esses benchmarks de forma prática: o que cada teste mede, onde o GLM-5.2 realmente lidera e como validar isso na sua própria stack.

Experimente o Apidog hoje

Todos os números de lançamento citados aqui foram publicados pela Z.ai, salvo quando indicado. Como sempre, benchmarks de fornecedor devem ser lidos com cautela: eles ajudam a filtrar candidatos, mas não substituem testes com seu repositório, seus prompts, suas ferramentas e suas APIs.

💡 Se você cria ou testa APIs ao avaliar modelos como este, o Apidog é uma plataforma útil para projetar, depurar, simular e documentar os endpoints que esses modelos chamam. Isso é relevante porque boa parte dos ganhos do GLM-5.2 aparece em tarefas com agentes, terminal e uso de ferramentas.

A versão curta: benchmarks do GLM-5.2

Use esta tabela como ponto de partida. As colunas de comparação representam números reportados pela Z.ai, não 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 reais	62.1	58.4	58.6	n/a
Terminal-Bench 2.1	Tarefas multi-etapas em 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, com 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. Esse qualificador importa: “melhor entre modelos abertos” não é a mesma coisa que “melhor modelo geral em todos os cenários”.

Para uma visão geral do modelo, veja a introdução ao GLM-5.2. Para comparação com modelos proprietários, consulte GLM-5.2 vs GPT-5.5, Opus e Gemini.

Como interpretar o SWE-bench Pro: 62.1

O SWE-bench Pro testa algo próximo do trabalho real de engenharia de software:

1. O modelo recebe um problema real do GitHub.
2. Ele recebe o repositório completo.
3. Precisa localizar a causa do bug.
4. Precisa gerar um patch.
5. O patch é validado por testes ocultos.

Não é múltipla escolha, nem função isolada. O modelo precisa navegar por uma base real e alterar código sem quebrar o restante.

Segundo a Z.ai:

• GLM-5.2: 62.1
• GPT-5.5: 58.6
• GLM-5.1: 58.4

Leitura prática:

• A vantagem de 3.5 pontos sobre o GPT-5.5 é relevante, mas não transforma o GLM-5.2 em dominante. Em benchmarks desse tipo, detalhes de ambiente, prompts, retries e harness podem alterar alguns pontos.
• O ganho de 3.7 pontos sobre o GLM-5.1 é mais confiável, porque compara gerações do mesmo laboratório, provavelmente sob metodologia semelhante.

Se você quer testar algo parecido no seu contexto, use um fluxo simples:

# 1. Escolha um bug real do seu backlog
git checkout -b eval/glm-5-2-bugfix

# 2. Separe o contexto mínimo:
# - descrição do bug
# - stack
# - comandos de teste
# - arquivos relevantes, se conhecidos

# 3. Peça ao modelo para propor um patch
# 4. Aplique o patch
# 5. Rode a suíte
npm test
# ou
pytest
# ou
go test ./...

Critério de avaliação recomendado:

• O patch compila?
• Os testes existentes passam?
• O modelo alterou arquivos desnecessários?
• A solução é pequena e revisável?
• Ele explicou suposições e riscos?

Terminal-Bench 2.1: 81.0 é o número mais importante

O Terminal-Bench mede o modelo como agente em um shell real. Ele precisa:

• instalar dependências;
• executar comandos;
• ler logs;
• corrigir erros;
• continuar por várias etapas;
• concluir uma tarefa sem perder o estado.

Aqui está o salto reportado:

• GLM-5.1: 62.0
• GLM-5.2: 81.0

Esse ganho de 19 pontos é o destaque técnico do lançamento. Na prática, sair de 62 para 81 significa mudar de “precisa de supervisão frequente” para “pode completar muito mais tarefas com menos intervenção”.

Esse resultado também conversa com a arquitetura. A Z.ai atribui parte do ganho à atenção esparsa IndexShare, que reutiliza um indexador a cada quatro camadas de atenção esparsa para reduzir custo em contextos longos. Tarefas de terminal geram histórico longo:

comando -> saída -> erro -> novo comando -> saída -> ajuste -> teste -> log...

Quanto melhor o modelo mantém esse contexto, menor a chance de esquecer uma restrição ou repetir um comando inútil. Para comparação entre gerações, veja GLM-5.2 vs GLM-5.1.

Para validar esse tipo de capacidade, crie um teste interno com tarefas reais:

# Exemplo de tarefa para avaliação
# "Corrija o erro de build e abra um resumo do patch."

git clone <repo>
cd <repo>

npm install
npm run build
npm test

Observe se o modelo:

• identifica a primeira causa raiz em vez de corrigir sintomas;
• lê logs completos;
• evita loops;
• pede informações quando necessário;
• mantém um plano de execução;
• para quando a tarefa está concluída.

Ressalva: benchmarks de agentes são sensíveis ao harness. Timeouts, retries, prompts do sistema e permissões de execução podem mudar o resultado. Use o número como sinal forte, não como garantia.

MCP-Atlas: 77.0 e uso de ferramentas

O MCP-Atlas mede uso de ferramentas via Model Context Protocol. Em termos práticos, ele avalia se o modelo consegue:

1. escolher a ferramenta certa;
2. montar a chamada corretamente;
3. interpretar a resposta;
4. tratar erros;
5. continuar o fluxo.

Pontuações reportadas pela Z.ai:

• GLM-5.2: 77.0
• GPT-5.5: 75.3
• Claude Opus 4.8: 77.8

Aqui, a leitura correta é empate técnico. O GLM-5.2 está muito próximo do Opus 4.8 e ligeiramente acima do GPT-5.5, mas as margens são pequenas.

Para desenvolvedores, esse benchmark importa porque chamadas MCP se parecem muito com chamadas de API: entrada estruturada, resposta estruturada, erros, autenticação, limites e validação.

Um exemplo mínimo de contrato que um agente poderia chamar:

{
  "tool": "get_user_invoices",
  "arguments": {
    "user_id": "usr_123",
    "status": "open"
  }
}

O que você deve testar:

• o modelo usa user_id correto?
• passa enums válidos?
• trata resposta vazia?
• tenta novamente em erro transitório?
• não inventa campos inexistentes?

É aqui que o Apidog ajuda: você pode definir e simular endpoints antes de permitir que o agente toque produção. Depois, inspecione as cargas reais que o modelo envia e recebe. Se quiser testar esse fluxo, baixe o Apidog.

Raciocínio e matemática: HLE, AIME e GPQA-Diamond

O GLM-5.2 não aparece forte apenas em código. Ele também vem com bons resultados em raciocínio técnico.

HLE com ferramentas: 54.7

O Último Exame da Humanidade é um benchmark difícil, com perguntas especializadas em vários domínios. A configuração “com ferramentas” permite pesquisa e computação.

Segundo a Z.ai:

• GLM-5.2: 54.7
• GPT-5.5: 52.2

Em um benchmark desse nível, pontuações na casa dos 50 já indicam capacidade relevante.

AIME 2026: 99.2

O AIME é uma competição de matemática para estudantes de alto desempenho. Uma pontuação de 99.2 sugere que o benchmark já está perto do teto para modelos de fronteira. Ou seja: é mais um sinal de ausência de fraqueza do que um grande diferenciador.

GPQA-Diamond: 91.2

O GPQA-Diamond mede perguntas difíceis de ciência em nível de pós-graduação. Um resultado de 91.2 coloca o GLM-5.2 em território forte para raciocínio técnico.

Na prática, isso sugere que o modelo pode ser útil em tarefas como:

• explicar falhas complexas;
• comparar arquiteturas;
• revisar hipóteses técnicas;
• analisar logs extensos;
• propor planos de migração;
• escrever testes a partir de especificações.

A comparação GLM-5.2 vs concorrentes aprofunda esse ponto.

O que significa “maior pontuação de código aberto”

A Z.ai relata o GLM-5.2 como principal modelo de código aberto no FrontierSWE, PostTrainBench e SWE-Marathon.

Leia isso com precisão:

• Não significa que ele vence todos os modelos proprietários em todos os testes.
• Significa que, entre modelos de pesos abertos, ele aparece como líder nesses benchmarks reportados.

Isso é importante se você tem requisitos como:

• auto-hospedagem;
• controle de dados;
• execução em infraestrutura própria;
• auditoria;
• menor dependência de API fechada;
• customização de ambiente.

O modelo é descrito como lançado sob licença MIT, com pesos abertos e sem restrições regionais. Essa é uma proposta diferente de consumir apenas uma API proprietária.

O VentureBeat descreveu o valor como “superar o GPT-5.5 em codificação de longo horizonte por aproximadamente um sexto do custo”. Essa formulação deve ser atribuída ao VentureBeat, não tratada como medição universal.

Especificações do GLM-5.2

Benchmarks só fazem sentido quando comparados a limites reais de execução, custo e licenciamento.

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
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

Notas práticas:

• Os ~753B parâmetros representam o tamanho total do MoE, não a contagem ativa por token.
• A janela de 1M de tokens é especialmente relevante para agentes, execução em terminal e análise de repositórios grandes.
• A saída máxima de até 128K deve ser tratada como teto documentado, não garantia universal entre provedores.
• Não há variante de visão GLM-5.2 confirmada pela Z.ai.

Sobre preço: o OpenRouter lista US$ 1.40 por 1M de tokens de entrada e US$ 4.40 por 1M de saída, com entrada em cache em torno de US$ 0.26 por 1M, segundo dado citado pelo VentureBeat. Para mais detalhes, veja preços do GLM-5.2. Se quiser testar sem pagar por token, veja como usar o GLM-5.2 gratuitamente.

Como validar o GLM-5.2 na sua própria stack

Não use benchmarks como decisão final. Use-os para decidir o que testar primeiro.

1. Leia as fontes primárias

Comece por:

• blog GLM-5.2 da Z.ai
• documentação da Z.ai
• model card no Hugging Face

Verifique:

• metodologia dos benchmarks;
• limites de contexto;
• modos de raciocínio;
• instruções de execução;
• licença;
• requisitos de hardware.

2. Confira provedores e execução local

Fontes úteis:

• OpenRouter
• Ollama
• cobertura da VentureBeat

Valide:

• ID correto do modelo;
• preço por token;
• suporte a cache;
• limites de saída;
• latência;
• disponibilidade regional;
• compatibilidade com sua infraestrutura.

3. Monte um benchmark interno

Use tarefas reais, não prompts artificiais. Um bom conjunto mínimo:

Tipo de tarefa	Exemplo
Bugfix	Corrigir uma falha real com teste quebrando
Refatoração	Simplificar módulo sem alterar comportamento
API	Criar endpoint seguindo contrato existente
Testes	Gerar testes para caso de borda
Agente	Executar comandos, corrigir build e resumir patch
Ferramentas	Chamar APIs simuladas e tratar erros

Exemplo de prompt de avaliação:

Você está em um repositório existente.

Objetivo:
Corrigir o erro descrito abaixo e manter todos os testes passando.

Erro:
<cole aqui o erro real>

Restrições:
- Não altere APIs públicas sem necessidade.
- Não remova testes existentes.
- Explique o patch no final.
- Se precisar executar comandos, mostre o comando e interprete a saída.

Comandos de validação:
- npm test
- npm run build

Critérios objetivos:

[ ] Build passa
[ ] Testes passam
[ ] Patch é pequeno
[ ] Não introduz dependências desnecessárias
[ ] Não altera comportamento fora do escopo
[ ] Explicação final corresponde ao diff
[ ] Modelo não ficou preso em loop

4. Teste chamadas de ferramentas antes de produção

Falhas comuns em agentes:

• JSON inválido;
• endpoint errado;
• campos inventados;
• enum inválido;
• retry incorreto;
• tratamento ruim de erro 4xx/5xx;
• vazamento de dados sensíveis;
• ausência de idempotência.

Um contrato simples para simular:

POST /orders/{orderId}/refund
body:
  amount:
    type: number
  reason:
    type: string
  idempotency_key:
    type: string

Casos que o modelo deve tratar:

{
  "status": 400,
  "error": "amount exceeds refundable balance"
}

{
  "status": 409,
  "error": "duplicate idempotency_key"
}

{
  "status": 200,
  "refund_id": "ref_123",
  "status_detail": "processing"
}

Ao simular esses endpoints no Apidog, você consegue observar as chamadas reais do modelo sem atingir serviços de produção. Isso ajuda a separar um modelo bom em benchmark de um modelo confiável no seu fluxo real.

Para contexto adicional sobre gerações anteriores, veja GLM-5.1 e GLM-5 vs DeepSeek vs GPT-5: velocidade e custo.

Conclusão

Os benchmarks do GLM-5.2 são fortes, especialmente em tarefas de agente e terminal. O salto no Terminal-Bench de 62.0 para 81.0 é o sinal mais importante. A liderança no SWE-bench Pro sobre o GPT-5.5 é real, mas moderada. No MCP-Atlas, o resultado é melhor lido como empate técnico com modelos de ponta.

A decisão prática é simples:

1. Use os benchmarks para justificar uma avaliação.
2. Teste o modelo em bugs, builds, APIs e ferramentas reais.
3. Meça taxa de sucesso, qualidade do patch, custo e latência.
4. Simule chamadas de API antes de liberar o agente para produção.

Se sua avaliação envolve ferramentas e endpoints reais, configure os contratos no Apidog, observe o que o modelo envia e recebe, e decida com base no comportamento dele na sua stack — não apenas na pontuação publicada por outra pessoa.