GLM melhorou a inferência. Os engenheiros definem a meta

A Z.ai relata que um agente de programação baseado no GLM-5.3 ajudou a otimizar o software que serve o GLM-5.3-Flash, atingindo cerca do triplo do débito inicial. No relato de 17 de setembro de 2026, os engenheiros orientam o trabalho e revêm as alterações críticas. A conclusão que retiro é prática: um agente de programação precisa de medições que expliquem as falhas e de alguém responsável por decidir o que conta como sucesso. [1]

O que construiu realmente o GLM?

O trabalho incidiu sobre o software de inferência, que executa um modelo já treinado para responder a pedidos. A documentação da Z.ai descreve um motor baseado em SGLang, com processos separados para tratar entradas multimodais, ler prompts e gerar tokens. O agente de infraestrutura ajudou os engenheiros a melhorar kernels e a investigar estrangulamentos no desempenho. [2]

Segundo as notas de lançamento da Z.ai, o GLM-5.3-Flash foi lançado a 26 de agosto de 2026. O relatório de setembro explica o trabalho que sustentou essa entrada em produção; não anuncia um novo modelo. Convém distinguir as duas datas quando um relato de engenharia acabado de publicar começa a circular como notícia de um novo modelo. [4]

O software tinha de suportar uma carga de trabalho considerável. A Z.ai documenta a entrada nativa de imagens e vídeo, além de texto, uma janela de contexto de um milhão de tokens e uma arquitetura de atenção híbrida. O sistema de inferência separa as etapas que têm necessidades de recursos diferentes. Por isso, o trabalho de infraestrutura está ligado às capacidades reais do produto, em vez de ser um exercício isolado de geração de código. [2]

Também não resumiria os dois nomes de modelo à frase «o GLM construiu-se a si próprio». Dizer que um agente melhora software de produção é diferente de dizer que um sistema desenvolve o seu próprio sucessor. Essa distinção muda as provas que quero ver.

O que significa o ganho de 3× no débito?

A Z.ai relata que o sistema de inferência atingiu o triplo do débito da versão inicial, no mesmo hardware. Isso sustenta uma afirmação sobre o esforço de otimização conjunto. Não permite isolar a rapidez do agente face a uma equipa equivalente de engenheiros. [2]

O pormenor mais útil é um caso concreto de depuração. Segundo a Z.ai, a diferença de desempenho entre processar prompts com transferência de cache e processá-los sem essa transferência ultrapassava 20% em alguns cenários. Depois de uma correção na concorrência entre Python e C++, essa diferença caiu para menos de 1% nas mesmas condições de teste. [1]

Estas percentagens medem o custo adicional naquela comparação. Não são um ganho extra que se possa multiplicar pelo fator de 3× anunciado. Manteria cada resultado associado à respetiva referência, tal como faço ao analisar o que as pontuações dos benchmarks de IA realmente medem. Sem esse cuidado, várias medições válidas podem levar a uma conclusão inválida.

A questão que me resta é a atribuição do resultado. Uma comparação útil manteria a tarefa e o código inicial constantes, registando depois o tempo decorrido, as intervenções dos engenheiros e as alterações aceites. O relato de engenharia publicado dá-me motivos para investigar este método de trabalho, mas não transformaria o valor do débito numa afirmação de que os programadores passaram a ser três vezes mais produtivos.

Trata-se de autoaperfeiçoamento recursivo?

A Z.ai diz que ainda não atingiu o autoaperfeiçoamento recursivo. No seu relato, os engenheiros definem os objetivos e as restrições e fazem as revisões críticas, enquanto o agente propõe alterações e executa experiências. [1]

Uma publicação de 18 de setembro no r/AIGuild apresentou o trabalho como um exemplo inicial de autoaperfeiçoamento recursivo, reconhecendo depois a mesma dependência de decisões humanas. O enquadramento é interessante, mas a publicação comenta o relatório da Z.ai; não reproduz os resultados de forma independente. [3]

Para aceitar a afirmação mais ambiciosa, exigiria mais: que decisões sobre o sistema seguinte tomou a IA, que provas justificaram a sua aprovação e conseguiria o processo continuar sem uma pessoa fornecer o próximo objetivo? Melhorar o software que serve um modelo responde a uma pergunta mais limitada.

Ainda assim, o trabalho merece atenção. Interessa-me primeiro saber se um agente consegue fazer trabalho útil de investigação e engenharia; o nome que se dá a isso vem depois. A mesma distinção orienta a minha leitura dos relatos de Claude a liderar investigação em IA: o âmbito do trabalho delegado e o processo de revisão dizem-me mais do que uma afirmação genérica de autonomia.

O que adotaria no trabalho com um agente de programação

Adotaria a preparação das experiências: escolher uma ação lenta do utilizador, preservar a implementação inicial e definir tanto uma medição do tempo como o comportamento que tem de continuar correto. Assim, o agente tem um problema concreto para investigar antes de começar a editar.

Numa página que fica lenta depois de carregar um grande conjunto de dados, incluiria esses dados na descrição da tarefa, juntamente com uma ação repetível cujo tempo pudesse medir. Se o agente propusesse usar cache, o teste também teria de detetar resultados desatualizados. Um resultado mais rápido com dados antigos não cumpriria a minha condição de aceitação.

Seria o percurso completo do utilizador a determinar se mantinha a alteração. Uma medição local promissora justifica continuar a testar, mas não basta para aceitar a solução. Compararia as duas versões com os mesmos dados de entrada e registaria por que motivo a alteração foi aceite ou rejeitada.

Esses registos devem acompanhar o conhecimento do projeto de que falo no meu guia de gestão de contexto. O próximo agente precisa do comando usado para obter a medição de referência e dos resultados medidos, incluindo as abordagens que falharam, para poder continuar a investigação.

No trabalho em paralelo, a lição dos agentes que comunicam através de um quadro de mensagens partilhado é definir quem é responsável por cada experiência. Alguém tem de decidir em que resultado se deve basear a alteração seguinte. O meu primeiro resultado concreto seria um diagnóstico reproduzível de uma operação lenta numa aplicação que já conheço.