- GLM-4.5 é um grande modelo de linguagem open source do tipo Mixture-of-Experts (MoE), com excelente desempenho em agentes, raciocínio e codificação
- O modelo evoluiu com 23T tokens por meio de treinamento em múltiplas etapas, iteração de modelos especialistas e aprendizado por reforço
- Registrou resultados de ponta em diversos benchmarks centrais, como TAU-Bench, AIME 24 e SWE-bench Verified
- Entrega desempenho eficiente mesmo com menos parâmetros, ficando próximo ou à frente de importantes modelos comerciais
- GLM-4.5 e sua versão menor, GLM-4.5-Air, foram lançados para uso em pesquisa e desenvolvimento de sistemas de IA
Visão geral
- GLM-4.5 é um grande modelo de linguagem open source do tipo Mixture-of-Experts (MoE), com 355 bilhões de parâmetros totais e 32 bilhões de parâmetros ativos
- Adota um método híbrido de raciocínio, oferecendo tanto o modo de pensamento profundo (Thinking) quanto o modo de resposta imediata (Direct Response)
- Passou por aprendizado em múltiplas etapas com 23 trilhões de tokens, iteração de modelos especialistas e pós-treinamento baseado em aprendizado por reforço
- Como resultado, alcançou alto desempenho nas áreas de agentes (Agentic), raciocínio (Reasoning) e codificação (Coding·ARC)
- TAU-Bench 70.1%, AIME 24 91.0%, SWE-bench Verified 64.2%
- Em comparação com modelos concorrentes, o GLM-4.5 usa menos parâmetros e ficou em 3º lugar no ranking geral e em 2º nos benchmarks de agentes
- Foram disponibilizadas duas versões: o modelo grande GLM-4.5 (355 bilhões de parâmetros) e o modelo reduzido GLM-4.5-Air (106 bilhões de parâmetros)
- Código completo, modelos e informações detalhadas estão disponíveis no GitHub oficial (https://github.com/zai-org/GLM-4.5)
Avaliação de desempenho de LLM: benchmarks de agentes, raciocínio e codificação
- O GLM-4.5 e os principais modelos globais foram testados em 12 benchmarks representativos (MMLU-Pro, AIME 24, SWE-Bench Verified etc.)
- O GLM-4.5 ficou em 3º lugar na média geral, e o GLM-4.5-Air em 6º
- Em pontuação de agentes, ficou em 2º lugar, atrás apenas do OpenAI o3, e em benchmarks de codificação alcançou o 3º lugar, próximo do Claude Sonnet 4
- O GLM-4.5 apresenta desempenho semelhante com metade dos parâmetros do DeepSeek-R1 e um terço dos do Kimi K2
- Em número de parâmetros versus desempenho no SWE-bench Verified, tanto o GLM-4.5 quanto o GLM-4.5-Air estão na Pareto Frontier
- Dados de desempenho válidos em 28 de julho de 2025
Introdução
- Grandes modelos de linguagem (LLM) estão evoluindo rapidamente de repositórios universais de dados para solucionadores universais de problemas
- O AGI (Artificial General Intelligence), considerado o destino final da inteligência artificial, busca modelos com capacidade cognitiva em nível humano em vários domínios
- Para isso, são exigidas de forma integrada capacidade de resolver problemas complexos, generalização e autoaperfeiçoamento
- As três capacidades centrais mais importantes para trabalho real e resolução de problemas profissionais complexos são:
- Capacidade agêntica: interação com ferramentas e com o mundo externo
- Raciocínio composto: resolução complexa e em etapas de problemas como matemática e ciência
- Codificação avançada: capacidade de executar engenharia de software de forma prática
- Modelos comerciais SOTA existentes (OpenAI, Anthropic) mostram desempenho especializado em áreas individuais, mas entre os modelos open source ainda são poucos os modelos públicos excelentes nos três campos ao mesmo tempo
Introdução aos modelos GLM-4.5 e GLM-4.5-Air
- GLM-4.5/GLM-4.5-Air apresentam desempenho de nível máximo entre modelos open source em agentes, raciocínio e codificação
- Ambos os modelos oferecem modo híbrido de raciocínio
- Thinking Mode tem vantagem em raciocínio complexo e tarefas agênticas
- Non-thinking Mode é especializado em respostas rápidas
- Principais resultados do GLM-4.5:
- Agentes: TAU-Bench 70.1%, BFCL v3 77.8%, BrowseComp 26.4% (à frente de modelos comerciais concorrentes)
- Raciocínio: AIME 24 91.0%, GPQA 79.1%, LiveCodeBench 72.9%, HLE 14.4%
- Codificação: SWE-bench Verified 64.2%, Terminal-Bench 37.5% (à frente de GPT-4.1 e Gemini-2.5-pro, e próximo do Claude Sonnet 4)
- O GLM-4.5-Air, com 106 bilhões de parâmetros, é equivalente ou superior mesmo entre modelos na faixa de 100 bilhões, como Qwen3-235B-A22B e MiniMax-M1
Situação e características do desempenho em benchmarks
- Em 12 benchmarks principais, tanto o GLM-4.5 quanto o GLM-4.5-Air registraram colocações elevadas
- O GLM-4.5 se destaca pelo desempenho equilibrado em agentes, raciocínio e codificação, além da eficiência de parâmetros
- Alcança a melhor faixa de eficiência em número de parâmetros versus desempenho no SWE-bench Verified (Pareto Frontier)
- Foi realizada uma comparação detalhada de desempenho com diversos modelos comerciais e open source
Disponibilização e suporte open source
- Os modelos GLM-4.5/GLM-4.5-Air foram disponibilizados não apenas na Z.ai e BigModel.cn, mas também no Huggingface (https://huggingface.co/zai-org/GLM-4.5)
- Para garantir a reprodutibilidade dos benchmarks, até mesmo o toolkit de avaliação (https://github.com/zai-org/glm-simple-evals) foi fornecido como open source
Pré-treinamento
Arquitetura
- A série GLM-4.5 adota uma arquitetura Mixture-of-Experts (MoE), aumentando bastante a eficiência computacional de treinamento e inferência
- Aplica loss-free balance routing e gating sigmoide às camadas MoE
- Diferentemente de DeepSeek-V3 e Kimi K2, reduz a largura do modelo (dimensão oculta, número de especialistas roteados) e aumenta a profundidade (número de camadas). Modelos mais profundos são mais eficazes para o avanço da capacidade de raciocínio
- Em Self-Attention, aplica Grouped-Query Attention + partial RoPE, com 96 attention heads formando uma configuração de 2,5x attention head para dimensão oculta 5120
- Foi confirmado que o aumento no número de heads não afeta a perda de treinamento, mas tem impacto positivo no raciocínio real e no desempenho em benchmarks
- A aplicação de QK-Norm melhora a estabilidade dos valores de attention logit
- Tanto o GLM-4.5 quanto o GLM-4.5-Air adicionam camadas MTP (Multi-Token Prediction) baseadas em camadas MoE, oferecendo suporte a speculative decoding na inferência
- No processo de contabilização dos parâmetros da arquitetura, os parâmetros das camadas MTP são incluídos, enquanto embeddings de palavras e camadas de saída não são incluídos
Conclusão e efeitos esperados
- GLM-4.5/GLM-4.5-Air são modelos de linguagem de próxima geração no mercado open source de IA, reunindo alto desempenho, eficiência e versatilidade
- Destacam-se pela capacidade integrada de resolver problemas difíceis em várias áreas, competitividade com modelos comerciais e eficiência de parâmetros
- Podem ampliar sua contribuição como base de inovação para grandes modelos de linguagem open source em pesquisa acadêmica, indústria e estudos de desenvolvedores em geral
2 comentários
Nos comentários do Hacker News e também no fórum LocalLLaMA do Reddit, parece que o GLM está sendo bem elogiado
GLM 4.5 AIR IS SO FKING GOODDD
Opiniões no Hacker News
Fiquei realmente feliz de ver que este artigo, diferente dos posts comuns de anúncio de modelo que costumamos ver, entra em bastante profundidade.
A equipe da Zhipu/Tsinghua explicou em detalhe não apenas o "o quê", mas também o "como", então é algo especialmente interessante para quem quer construir ou usar modelos assim por conta própria.
Em especial, a metodologia de pós-treinamento da Seção 3 foi impressionante.
A abordagem de criar separadamente "modelos especialistas" para raciocínio/agente/chat e depois destilar essas capacidades em um modelo final unificado é muito atraente.
Parece uma tentativa bem mais sistemática de resolver as limitações de um modelo generalista que faz vários papéis mais ou menos.
Em vez de simplesmente misturar dados, o desenho faz com que um modelo geral aprenda com um conjunto de especialistas.
Um ponto interessante nos resultados de RL é que aplicar RL de uma vez no contexto completo de 64K teve desempenho melhor do que RL em etapas (ver Fig 6).
Muita gente em outras equipes provavelmente presumiria o contrário, mas o resultado real foi diferente.
E também gostei da escolha pequena, porém inteligente, de usar um template XML para o formato de function calling, escapando dos problemas de escaping em JSON (ver Fig 4).
Na prática, escapar código dentro de JSON é realmente uma dor de cabeça enorme.
O desempenho no SWE-bench também é bem forte, comparável ao de modelos muito maiores ou comerciais.
O que me deixa curioso agora é se esse método híbrido de treinamento também funciona fora de avaliações no estilo ARC.
Por exemplo, fico pensando se o desempenho como agente se mantém em fluxos de trabalho complexos do mundo real, onde não há documentação de API, erros acontecem com frequência e as entradas são ambíguas.
Fico me perguntando se esse tipo de ajuste de post/mid-training é realmente necessário em aprendizado de domínios específicos onde já existe abundância de dados e rótulos bem validados.
Queria saber se uma equipe pequena já consegue chegar longe apenas acompanhando bem a stack mais moderna de treinamento em escala, ou se a diferença é grande sem usar essas técnicas.
Espero não parecer alguém caçando defeito à toa, mas o estilo de escrita do texto passa bastante aquela sensação típica de LLM.
Já vi essa mesma observação antes link.
Acho que apontar esse tipo de coisa ajuda a manter o ambiente online mais saudável.
Usei o modelo de código GLM-4.5 por bastante tempo, e o desempenho é realmente excelente.
Já aconteceu de eu confundir o GLM-4.5 com o Claude 4 ao rodá-lo no Octofriend, o agente de código que estou desenvolvendo.
Pela minha experiência, o Claude parece um pouco mais forte quando precisa considerar toda a base de código como contexto junto com interações de sistema.
Já o GLM-4.5 me parece mais "honesto" e não costuma fazer aquele tipo de coisa de o Claude alterar testes para contornar o problema discretamente.
Os dois são de alto nível, mas o GLM-4.5 já encontrou bugs que o Claude 4 Sonnet e o 4.1 Opus não detectaram.
Em depuração, o Claude ainda vence um pouco mais frequentemente, mas a diferença não é grande.
Em comparação com o GPT-5, tanto o Claude quanto o GLM são mais consistentes.
O GPT-5 às vezes produz resultados realmente incríveis, mas quando sai dos trilhos é difícil e frustrante trazê-lo de volta.
Referência do Octofriend: https://github.com/synthetic-lab/octofriend
Depois de ler este comentário, testei o GLM-4.5 no Kilocode.
Passei o dia inteiro tentando corrigir um bug complicado em código de compilador com o Gemini CLI, sem sucesso.
Mas o GLM-4.5 apontou o problema central logo de cara.
O Gemini CLI ficou suspeitando de funções erradas e repetindo correções mal orientadas, quando no fim eram partes totalmente sem relação.
Realmente chama atenção a capacidade do GLM-4.5 de manter o foco no problema.
Também tive uma boa experiência com o GLM-4.5 em projetos pequenos ou pedidos curtos.
Infelizmente, sinto que o desempenho cai quando o contexto fica mais longo, então hoje eu o uso como reserva do Sonnet 4.
Estou usando o modo architect no aider.
Uso uma combinação de Deepseek R1 (responsável pelo design de alto nível) + Qwen3 480B (responsável pela codificação de baixo nível, ou usando a qwen code API).
Essa configuração funciona muito bem.
Ela resolve 99,99% dos problemas sozinha.
Como a separação de papéis ainda não é perfeita no aider, estou pensando em criar uma ferramenta para melhorar esse workflow manualmente.
Concordo com o primeiro ponto.
Eu também vejo o Claude funcionando melhor quanto mais contexto há, enquanto o GLM-4.5 entrega resultados piores nessas situações.
Na série GLM-4.5, ao contar o número total/de parâmetros ativos, eles excluem as camadas de embedding e de saída e incluem apenas as camadas MTP.
Isso bate com o que eu calculei (355B A32B).
A série GPT OSS inclui embedding e saída na contagem de parâmetros totais, mas nos parâmetros ativos inclui apenas a saída.
A série Qwen3 inclui tanto embedding quanto saída em ambos, total e ativos.
Como cada modelo conta os parâmetros de forma diferente, fico me perguntando por que não existe um padrão e qual método faria mais sentido.
No caso dos parâmetros ativos, os parâmetros de unembedding são usados em toda geração de token, enquanto no embedding só uma coluna é usada, então esse tipo de característica deveria entrar no cálculo para entender corretamente a relação com largura de banda e latência.
Acho que, nos próximos anos, será possível programar com um modelo aberto local no nível do Sonnet 4 em uma workstation de uns 2 mil dólares.
Os modelos atuais baseados em nuvem já são úteis, mas como isso vai ser uma ferramenta central na experiência do desenvolvedor, eu gostaria que pudesse rodar localmente.
Na minha opinião, não em dois anos, mas já até o fim deste ano.
Do ponto de vista de open source, modelos assim são indispensáveis.
Caso contrário, o próprio desenvolvimento open source pode se tornar insustentável.
Na verdade, estou ainda mais otimista de que em até 2 anos será possível colocar desempenho acima do Sonnet 4 em um PC de 2 mil dólares.
Este me parece o primeiro modelo aberto que pode ser comparado quase de igual para igual com os modelos frontier comerciais existentes.
Só pela eficiência de parâmetros já dá para ver que houve inovação real no método de treinamento.
Também estou curioso para ver resultados de verificação independente de desempenho no LLM Leaderboard do Aider.
Para quem, como eu, gosta de começar lendo o resumo do artigo, deixo aqui o link: https://www.arxiv.org/abs/2508.06471
O fato de ser licenciado em Apache torna esse lançamento ainda mais incrível.
É realmente animador ver modelos open source continuando a desafiar os limites.
Há tantas observações neste artigo que cada uma delas daria um paper separado.
Especialmente a experiência relatada sobre o processo de treinamento e sobre coleta/síntese de dados é riquíssima.
Alguém sabe se esses autores já publicaram antes outros artigos tão bons quanto este?
Os indicadores dos gráficos no paper estão confusos.
Na primeira figura, a pontuação do Sonnet 4 no swebench aparece perto de 53, mas depois fica perto de 70.
O valor real parece ser mais próximo de 70 referência.
Queria entender por que o Qwen3 ficou de fora dos benchmarks de código, mas apareceu nos outros benchmarks.
O Qwen3-Coder está incluído na Section 4.3.2.
O Qwen ainda não é maduro para entender codebases grandes.