GLM-5.1: evolução rumo à execução de tarefas de longo prazo

• O modelo flagship de próxima geração para engenharia agêntica, GLM-5.1, foi projetado com foco em otimização de longo prazo e melhoria contínua, com grandes avanços em codificação e resolução de problemas
• Registrou desempenho de ponta em benchmarks importantes como SWE-Bench Pro, NL2Repo e Terminal-Bench 2.0, mantendo persistência produtiva mesmo em execuções repetidas de longa duração
• Em VectorDBBench, KernelBench e cenários de construção de webapps, continuou melhorando o desempenho ao longo de centenas a milhares de iterações, removendo gargalos por meio de análise dos próprios logs e revisão de estratégia
• O modelo opera com eficiência mesmo em tarefas complexas de engenharia de software por meio de autoavaliação e mudanças estruturais, e a qualidade dos resultados melhora de forma consistente em execuções longas
• Lançado como open source sob licença MIT, pode ser usado em várias plataformas e frameworks e é apresentado como um novo padrão para modelos de IA otimizados para o longo prazo

---

Visão geral do GLM-5.1

• O GLM-5.1 é um modelo de próxima geração para engenharia agêntica (agentic engineering) e é o modelo flagship com desempenho de codificação muito superior ao da versão anterior
• Registrou o melhor desempenho no SWE-Bench Pro e também abriu ampla vantagem sobre o GLM-5 no NL2Repo (criação de repositórios) e no Terminal-Bench 2.0 (tarefas reais de terminal)
• Foi projetado com ênfase não apenas no desempenho de execução única, mas também em capacidade de otimização de longo prazo e resolução contínua de problemas
• Julga melhor problemas ambíguos, mantém a produtividade em sessões longas e continua melhorando o desempenho mesmo após centenas de iterações, por meio de experimentos repetidos e revisão de estratégia
• Tem como característica central a capacidade de longo horizonte (long-horizon capability), com uma estrutura em que os resultados melhoram quanto mais tempo a execução continua

Tarefas complexas de engenharia de software

• O GLM-5.1 alcança desempenho de ponta em tarefas complexas de engenharia de software
• Enquanto modelos anteriores estagnam rapidamente após melhorias iniciais, o GLM-5.1 mantém a eficiência mesmo em trabalhos agênticos de longo prazo
• O modelo divide o problema em partes menores, realiza experimentos, analisa os resultados para identificar gargalos e ajusta a estratégia por meio de raciocínio iterativo
• Isso foi demonstrado em três tarefas com níveis progressivamente menores de estruturação
  • Problema de otimização de busca vetorial (baseado em uma única métrica numérica)
  • Benchmark de kernels de GPU (medição de ganho de velocidade por problema)
  • Construção de aplicação web (melhoria baseada em julgamento próprio, sem métrica explícita)

Cenário 1: otimização de banco de dados vetorial com 600 iterações

• VectorDBBench é um desafio open source que avalia a capacidade de codificação do modelo para construir bancos de dados de alto desempenho para busca aproximada de vizinhos mais próximos
• O modelo recebe código esqueleto em Rust e endpoints de API HTTP e, dentro de 50 chamadas de ferramenta (tool-calls), realiza leitura/gravação de arquivos, compilação, testes e profiling
• O melhor desempenho anterior era 3.547 QPS do Claude Opus 4.6 (Recall ≥ 95%)
• O GLM-5.1 adicionou um loop externo de otimização e executou mais de 600 iterações (mais de 6.000 chamadas de ferramenta), atingindo ao final 21.5k QPS
  • Isso representa cerca de 6× de melhora em relação a uma única sessão de 50 chamadas
• O processo de melhoria de desempenho mostra um padrão em escada (staircase), alternando entre tuning incremental e mudanças estruturais
  • Por volta da iteração 90: introdução de IVF cluster probing + compressão vetorial f16 → 6.4k QPS
  • Por volta da iteração 240: introdução de pipeline em duas etapas com u8 pre-scoring + re-ranking em f16 → 13.4k QPS
• Ao todo ocorreram 6 mudanças estruturais, cada uma resultado da análise dos próprios logs pelo modelo para identificar gargalos
• Os pontos em que o Recall caiu abaixo de 95% concentraram-se principalmente em momentos de exploração de novas estratégias

Cenário 2: otimização de workloads de machine learning com mais de 1.000 iterações

• KernelBench avalia a capacidade do modelo de converter implementações de referência em PyTorch em kernels de GPU mais rápidos com a mesma saída
• É composto por três estágios (Level 1~3), e o Level 3 inclui otimização em nível de modelo completo, como MobileNet, VGG, MiniGPT e Mamba
• A configuração padrão do torch.compile alcançou 1.15× de ganho de velocidade, e o max-autotune chegou a 1.49×
• O GLM-5.1 registrou 3.6× de ganho de velocidade no Level 3, sustentando otimizações úteis por muito mais tempo do que o GLM-5
• O GLM-5 cresce rapidamente no início e depois estagna, enquanto o Claude Opus 4.5 sustenta por mais tempo, mas desacelera na fase final
• O Claude Opus 4.6 mantém o melhor desempenho final com 4.2×, e ainda existe margem para melhorias adicionais

Cenário 3: construção de webapp de desktop Linux ao longo de 8 horas

• A criação de websites é uma tarefa subjetiva sem métrica numérica explícita, em que os critérios de avaliação são completude, qualidade visual e qualidade da interação
• Prompt de teste: “Construa um ambiente de desktop no estilo Linux como uma aplicação web”
  • Iniciado sem código inicial, design ou feedback intermediário
• A maioria dos modelos cria apenas uma UI básica e encerra, mas o GLM-5.1 evolui continuamente por meio de loops de revisão e melhoria dos próprios resultados
• Ao longo de 8 horas de execução iterativa, expande gradualmente um layout simples inicial para um ambiente de desktop completo
  • Adiciona explorador de arquivos, terminal, editor de texto, monitor do sistema, calculadora, jogos etc.
  • Cada recurso é integrado em uma UI consistente, com melhorias graduais de estilo e qualidade de interação
• O resultado final é um ambiente de desktop completo e visualmente consistente executado no navegador

Significado e desafios da otimização de longo prazo

• Em todos os três cenários, a variável central não é o tempo de execução em si, mas se o tempo adicional realmente é útil
• O GLM-5.1 amplia bastante o horizonte produtivo (productive horizon) em comparação com o GLM-5
• Ainda assim, em algumas tarefas como o KernelBench, ainda há espaço para melhoria
• Desafios restantes
  • Escapar de ótimos locais quando o tuning incremental atinge seu limite
  • Manter consistência ao longo de milhares de chamadas de ferramenta
  • Autoavaliação confiável (self-evaluation) em tarefas sem métricas numéricas explícitas
• O GLM-5.1 é apresentado como o primeiro passo nessa direção de otimização de longo prazo

Resumo comparativo de benchmarks

• O GLM-5.1 supera o GLM-5 em benchmarks importantes de codificação, como SWE-Bench Pro 58.4, NL2Repo 42.7 e Terminal-Bench 2.0 63.5
• Fica entre os melhores frente a modelos concorrentes em Reasoning, Coding e Agentic
• Mesmo em comparação com modelos recentes como Claude Opus 4.6, Gemini 3.1 Pro e GPT-5.4, aparece próximo ou à frente em vários itens

Disponibilização e formas de uso

• Lançado como open source sob licença MIT
• Disponível em api.z.ai e BigModel.cn, com compatibilidade com Claude Code e OpenClaw
• Assinantes do GLM Coding Plan podem usar imediatamente alterando o nome do modelo para "GLM-5.1"
  • No horário de pico (UTC+8 14:00–18:00), o consumo de cota é 3×; fora de pico, 2×
  • Até o fim de abril, fora de pico há promoção com consumo de 1×
• Como ambiente GUI, é oferecido o Z Code, com suporte a desenvolvimento remoto via SSH e trabalho em dispositivos móveis
• Os pesos do modelo estão disponíveis no HuggingFace e no ModelScope
• Suporte aos principais frameworks de inferência, como vLLM e SGLang, com guia de distribuição no GitHub
• Em breve também poderá ser usado na plataforma de chat Z.ai

Configuração de avaliação e observações

• HLE e outras tarefas de raciocínio: geração máxima de 163.840 tokens, com GPT-5.2 usado como modelo avaliador
• SWE-Bench Pro: janela de contexto de 200K, execução baseada em OpenHands
• NL2Repo: inclui detecção e bloqueio de comandos maliciosos
• Terminal-Bench 2.0: limite de 16 CPUs, 32GB de RAM e timeout de 3 horas
• KernelBench Level 3: ambiente com GPU H100, limite de 1.200 chamadas de ferramenta e auditoria independente
• Avaliações independentes também foram realizadas em vários benchmarks externos, como CyberGym, MCP-Atlas, τ³-bench e Vending Bench 2

[GN⁺]

Comentários do Hacker News

• A cada dia, três coisas estão ficando mais claras
  (1) OpenAI e Anthropic agora quase não têm mais competitividade
  (2) Estou convencido de que inferência local/privada é o futuro da IA
  (3) Ainda não surgiu um “produto matador”, então agora é a hora de realmente construí-lo

  • Não concordo com a ideia de que “não existe produto matador”. Assistentes de programação e LLMs são a conquista tecnológica mais impressionante da minha vida. Assim como existe um antes e um depois da Revolução Industrial, acho que em breve a história da humanidade será dividida em antes e depois da IA
  • Assistentes de programação com IA estão entre as tecnologias mais úteis já criadas. Como a qualidade do modelo é o fator mais importante, acho difícil que a inferência local vire mainstream a menos que o hardware mude de forma fundamental
  • Fico me perguntando que vantagem prática existe, além de um hobby legal, em alguém gastar US$ 50 mil em GPUs para rodar isso por conta própria

• Acabei de ver um post sobre Claude Mythos, e desta vez não parece uma simples melhoria, mas um verdadeiro salto. Ainda não sei quando será lançado, mas também estou ansioso pela próxima release do GLM, cujas especificações parecem absurdamente poderosas

• A versão com quantização do Unsloth também foi lançada. No modelo GLM-5.1-GGUF, o IQ4_XS tem 754B parâmetros e 361GB, então é inviável para o entusiasta típico de LLM local

  • Com bom suporte de software, também dá para fazer offloading para SSD. Claro que nesse caso seria mais “se arrastando” do que “rodando”, mas ainda assim daria para obter respostas localmente. Recentemente, até surgiram tentativas de projetar estruturas de n-grams e parâmetros internos de embedding já pensando em offloading para SSD

• Esse modelo não só desenhou um excelente pelicano para mim, como também o transformou em animação
  Link relacionado

  • Ficou muito mais realista. É mais natural para um pelicano voar pelo céu do que andar de bicicleta
  • Simon, chegou a hora de criar um benchmark melhor

• Sinceramente, fiquei um pouco decepcionado. O GLM 5.1 gera TypeScript muito melhor do que Opus ou Codex, mas em contextos longos às vezes entra em um modo estranho. Mesmo assim, já tive sessões em que funcionou de forma estável por mais de 200k tokens

  • Se funcionar bem e a velocidade for aceitável, isso já é realmente impressionante. Ontem ele resolveu um problema que o Kimi K2.5 não conseguiu. Ainda assim, às vezes continua lento. A sensação é de estar perto do nível do Opus 4.5
  • Eu configuro a janela de contexto para 100k e periodicamente faço compact ou documento o estado para começar uma nova sessão. Como o Opus 4.6 anda instável, tenho usado mais o GLM 5.1. É surpreendente como a qualidade dos modelos abertos melhorou
  • Para o usuário, é lucro líquido quando modelos open source se saem melhor do que modelos fechados
  • Por volta de 100k tokens, já é hora de abrir uma nova sessão ou usar o comando /compact
  • Ainda mantenho o hábito da época do Claude e Codex de limpar o contexto com frequência. Por mais moderno que o modelo seja, ainda não confio em contextos gigantes

• O GLM-5.0 é realmente muito forte entre os modelos open source. Sempre fica no topo dos benchmarks internos e está em nível parecido com o GPT-5.2. Tenho usado mais para tarefas não estruturadas do que para programação

  • Ainda não usei o 5.1, mas em programação PHP ele entrega resultados 99% parecidos com Sonnet/Opus/GPT-5. Além disso, também pode ser rodado localmente
  • Estou montando um dataset para conversão de Python ↔ Cython, e ele teve a segunda maior taxa de aceitação (16%), atrás apenas do Gemini Pro 3.1. Os modelos intermediários ficam na faixa de 6~7%, então nem dá para comparar
  • Meu caso de uso é mais entendimento de codebase e análise de documentação do que escrita de código, e esse modelo funciona melhor do que os modelos americanos custando metade do preço

• Nos meus testes, o GLM 5.1 tem desempenho inferior ao GLM 5
  Link de comparação
  Parece que o modelo agora foi ajustado mais para ser agêntico/focado em programação

  • A queda de desempenho é especialmente clara na versão (none)

• Acho interessante a abordagem de avaliar a qualidade do modelo pela velocidade de execução do código gerado pelo agente. Eu testo criando um benchmark, definindo uma baseline e depois melhorando em pelo menos 1,4x. O Opus 4.6 encontrou otimizações de baixo nível em código Rust e o deixou 6 vezes mais rápido do que antes, passando em todos os testes. Esse método permite comparar o desempenho real de forma mais prática

• Pelos comentários, parece que todo mundo já usa esse modelo há bastante tempo, e fico curioso se isso é verdade

  • O post do blog é novo, mas o modelo já estava disponível há 2 semanas
  • O site de reserva das quadras de tênis da minha região quebrou, então pedi ao GLM-5.1 para analisar a API. Em 5 minutos ele encontrou o endpoint /cancel.php e extraiu IDs de reserva por blind SQL injection. Foi até proativo demais, mas realmente impressionante
  • Ele já estava disponível havia bastante tempo

• Tenho usado principalmente a versão GLM 4.7 Flash localmente para programação com agentes, e ela é realmente excelente. Eu esperava que desta vez também saísse uma versão Flash, mas fiquei decepcionado porque não há menção a isso nas notas de release. Ainda assim, acredito que venha em breve