Pesquisa · 2026-10-24 · Todas as pesquisas

Cortamos pela metade um modelo de programação de 321B para rodá-lo num PC doméstico. Veja o que quebrou, e como consertamos.

O GLM-5.3-Flash tem 288 especialistas em cada camada. Mantivemos 152, escolhidos por otimização, e publicamos o resultado com pesos abertos. No caminho, nossa primeira versão quebrou a aritmética, e os arquivos menores caíram num loop de raciocínio que uma única configuração elimina.

Photo: Jakub Pabis / Pexels

O GLM-5.3-Flash é um dos modelos de pesos abertos mais fortes para programação e trabalho agêntico. Também tem 321 bilhões de parâmetros: 341 GB em 8 bits. Quase ninguém consegue rodar isso em casa.

É um modelo de mistura de especialistas (mixture-of-experts). Cada camada tem 288 especialistas, e para cada token o roteador usa só alguns deles. A maioria dos especialistas raramente é necessária para código. Então a pergunta é simples: quantos podemos remover, e quais, antes que o modelo deixe de ser o mesmo modelo?

Nossa resposta é o GLM-5.3-Flash-Coder-RCO-152E: 152 dos 288 especialistas em cada camada, publicado com pesos abertos sob a mesma licença MIT do original. O arquivo de 3 bits tem 75 GB e roda numa GPU de 24 GB com 64 GB de RAM.

A primeira tentativa, e por que a substituímos

Nossa primeira versão mantinha 144 especialistas por camada, escolhidos com uma pontuação de saliência publicada (REAP), medida em sessões de agente em Python. Em tarefas de agente em Python, ela se saiu bem.

Depois rodamos um teste de regressão mais amplo, e ela falhou de maneiras que um benchmark de programação não mostra. Podia errar 17 x 23. Entrava em loop em perguntas sobre outras linguagens de programação. A causa foi a calibração: os especialistas que cuidam de aritmética, de outras linguagens e de raciocínio geral eram pouco usados nas sessões de agente em Python, então a pontuação os classificou mal e nós os cortamos.

Dissemos isso na página do modelo, tiramos os arquivos do ar e reconstruímos. A lição é geral: um modelo podado mantém aquilo em que você o mede, e perde o resto em silêncio. Se o conjunto de teste não cobre uma habilidade, a poda não vai protegê-la.

Como escolhemos os especialistas desta vez

Duas mudanças.

Os dados de calibração. Em vez de um único tipo de sessão, uma mistura: sessões de programação agêntica escritas pelo modelo completo, código em 21 linguagens de programação, matemática e 15% de texto geral. Tudo fora dos nossos conjuntos de avaliação.

O método de seleção. Em vez de pontuar cada especialista isoladamente, usamos o RCO, um método de otimização do IST Austria. Ele trata o conjunto de especialistas mantidos como uma única decisão e minimiza diretamente a diferença entre a saída do modelo podado e a saída do modelo completo nos dados de calibração.

Com os mesmos 152 especialistas, a máscara otimizada empatou com a máscara baseada em pontuação em código e texto agêntico, teve erro 22% menor em texto geral e produziu muito menos loops: 4 problemas no nosso teste de loop com 30 execuções, contra 22 da primeira versão.

Em seguida veio uma breve etapa de recuperação: um pequeno adaptador nos pesos de atenção e do especialista compartilhado, treinado para reproduzir a distribuição de saída do modelo completo.

O que ele mantém

Em 8 bits, contra o modelo completo, com os mesmos prompts e amostragem padrão:

Aritmética, código executado e chamadas de ferramentas passam em todos os tamanhos publicados.

O loop que só aparece depois da quantização

O modelo de 8 bits estava limpo. Os arquivos de 4 e 3 bits não estavam, e a falha levou um tempo para ser entendida.

Em exercícios de programação mais difíceis, o modelo começava a raciocinar normalmente, hesitava, escrevia "hmm" e depois nunca mais parava de escrever "hmm" até acabarem os tokens. Nenhum código. Pior: depois que uma tentativa entrava em loop, as tentativas seguintes, que veem o raciocínio anterior no histórico, entravam em loop de novo em poucos milhares de caracteres.

No Aider Polyglot, com até dez tentativas por exercício, os exercícios em que cada arquivo entrou em loop:

As correções óbvias não funcionaram. Uma penalidade de presença acabou com a repetição, mas aí o modelo continuava raciocinando sem nunca terminar. Um limite no tamanho do raciocínio ajudou em um exercício a cada três, porque o loop muitas vezes começava bem antes do limite.

O que funcionou foi bem mais específico: proibir os três tokens "hmm" deste tokenizador. Com essa única configuração, o modelo de 3 bits resolveu os três exercícios em que tinha entrado em loop, dois deles na primeira tentativa. A configuração exata está na página do modelo; é uma única flag --logit-bias no llama.cpp.

Acreditamos que a causa de fundo é que o modelo quantizado nunca foi treinado com as próprias saídas: quando ele desliza para um estado de hesitação, nada o puxa de volta. É isso que vamos testar a seguir, treinando a versão de 2 bits com as próprias gerações, com o modelo completo como professor.

Experimente

• Pesos: huggingface.co/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E-GGUF
• Receita, máscara, scripts e harness de avaliação: github.com/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E

Esta pesquisa usou capacidade computacional de alocações da EuroHPC JU AI Factory no supercomputador LUMI. RCO e GSQ são métodos do IST Austria; REAP é de Lasby et al., 2025.