GLM-5.2 localmente: Ollama + LM Studio, o gigante MIT

#Por que usar o GLM-5.2 localmente

A maioria dos modelos “frontier” (os maiores e mais capazes) continua restrita ao acesso por uma API: GPT, Gemini ou as versões de mais de 100 bilhões de parâmetros de Qwen e DeepSeek. O GLM-5.2 rompe com essa lógica. A Zhipu AI publicou os pesos completos sob a licença MIT — a mais permissiva que existe, sem cláusula de atribuição nem de compartilhamento sob a mesma licença — e a comunidade produziu versões quantizadas em GGUF funcionais já no lançamento. Resultado: você pode hospedar um modelo de classe frontier em sua casa, sem conta, sem cota, sem vazamento de dados.

O interesse não está na velocidade — sejamos claros: um modelo de 753B executado localmente nunca rivalizará com um endpoint na nuvem em rapidez de resposta. O interesse está na soberania total sobre um modelo que, em qualidade bruta, está no mesmo nível dos melhores serviços proprietários: raciocínio longo, trabalho com código em grandes bases e contexto de 1 milhão de tokens. Para um agente de código que trabalha por horas com código proprietário sob NDA, a velocidade fica em segundo plano em relação à confidencialidade.

#O que mudou desde GLM-5.1

Se você procura instalar um GLM de tamanho razoável em uma GPU de 12 a 24 GB, este guia não é o indicado: o GLM-5.1 (modelos densos de 9B e 32B) foi feito para isso, e nosso guia dedicado o aborda em detalhes. O GLM-5.2 se destina a outro público. A confusão é comum porque os nomes seguem uma sequência, mas os dois modelos não pertencem à mesma categoria de hardware.

Arquitetura

GLM-5.1 é denso (9B, 32B). GLM-5.2 é um MoE de 753B no total, com uma fração dos especialistas ativada por token. Não é possível executá-lo em uma única GPU de consumo.

Licença

O GLM-5.1 está sob a GLM License (variante da Apache com atribuição). O GLM-5.2 passa para a licença MIT pura — uso comercial sem restrições, nenhuma cláusula viral.

Contexto

128k no GLM-5.1 (1M via YaRN, com degradação). O GLM-5.2 suporta nativamente 1M de tokens, uma verdadeira vantagem para a análise de grandes repositórios.

Hardware-alvo

GLM-5.1: uma GPU de 8 a 24 GB. GLM-5.2: Mac com 256 GB de memória unificada, ou máquina com várias GPUs, ou servidor com muita RAM e offload.

Casos de uso

GLM-5.1 para um assistente local que responde rapidamente. GLM-5.2 para um modelo de fronteira de referência, quando a qualidade tem prioridade sobre a velocidade.

#753B MoE: compreender o modelo

O GLM-5.2 é um Mixture-of-Experts: de seus 753 bilhões de parâmetros, apenas uma fração é ativada a cada token gerado. É isso que torna a inferência local uma possibilidade — o cálculo por token permanece razoável —, mas a armadilha está em outro ponto: todos os pesos precisam caber na memória, mesmo os especialistas que não são utilizados em um dado momento. É a memória, e não a capacidade de cálculo, que é o fator limitante.

Parâmetros totais

753B, distribuídos entre um backbone compartilhado e um conjunto de especialistas com roteamento dinâmico.

Configurações ativas

Uma fração por token (roteamento top-k). É o que permite uma taxa de processamento razoável apesar do tamanho total.

Contexto

Contexto nativo de 1 milhão de tokens. Atenção: o cache KV com 1 milhão de tokens consome muita memória; reserve-o para os casos que justifiquem seu uso.

Licença

MIT. Você pode fazer ajuste fino, redistribuir e integrar em um produto comercial sem obrigações.

Formato

Pesos originais em BF16 (~1,5 TB). Não é possível usá-los assim localmente: é aí que entram as versões quantizadas em GGUF.

#As versões quantizadas em GGUF (unsloth)

A comunidade produziu as quantizações que tornam o GLM-5.2 utilizável. As quantizações dinâmicas de unsloth são a referência: elas aplicam uma precisão variável de acordo com a importância das camadas, o que preserva melhor a qualidade do que uma quantização uniforme com o mesmo tamanho. Isso é decisivo em precisões muito baixas, em que cada bit conta.

Q2_K_XL (unsloth)

~200 GB. O ponto de entrada realista. Qualidade reduzida, mas utilizável: é a versão que cabe em um Mac de 256 GB ou em uma máquina com várias 4090.

Q4_K_M

~380-400 GB. O ponto ideal de qualidade, mas reservado para servidores com enorme capacidade de memória ou configurações potentes com múltiplas GPUs.

Q5_K_M

~480 GB. Pouco ganho perceptível em relação a Q4 para esse tipo de modelo; raramente justificado localmente.

Q8_0 / BF16

800 GB a 1,5 TB. É território de servidores profissionais com GPU, fora do alcance de um computador de consumo.

# huggingface-cli doit être installé : pip install -U huggingface_hub
# Q2_K_XL est réparti en plusieurs shards GGUF
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*Q2_K_XL*" \
  --local-dir ./glm-5.2-gguf

#Requisitos de hardware realistas

Não há configuração 'leve' para o GLM-5.2. Aqui estão os dois perfis que realmente funcionam, sem maquiar os números.

Mac Apple Silicon de 256 GB

Um Mac Studio da série M com 256 GB de memória unificada comporta o Q2_K_XL com margem para o contexto. A memória unificada é uma vantagem decisiva aqui: não há separação entre CPU e GPU.

Mac 192 GB

Viável, mas com pouca folga: o Q2_K_XL cabe, mas reduza a janela de contexto e feche todo o resto. 128 GB fica abaixo do mínimo necessário para um uso viável.

Máquina multi-GPU

Várias RTX 4090 (24 GB cada) + bastante RAM do sistema para offload para a CPU. Não é possível acomodar 200 GB apenas na VRAM; é preciso distribuir entre GPU e RAM.

Armazenamento

No mínimo 200 GB livres para o Q2, um SSD NVMe rápido (o carregamento inicial lê centenas de GB).

RAM do sistema (computador)

No mínimo 128 GB de RAM se você transferir a execução de especialistas para a CPU; 256 GB para ter uma margem confortável.

#1. Instalação com LM Studio

LM Studio costuma ser a opção mais simples para um modelo desse tamanho, especialmente no Mac: seu motor MLX e sua gestão de memória estão bem ajustados, e a interface mostra em tempo real quanta memória o modelo exige antes de carregá-lo. Isso é valioso quando você está perto do limite.

1. 01
   1. Instalar LM Studio

   Baixe LM Studio do site oficial (lmstudio.ai) e instale-o. No Mac, escolha a versão nativa para Apple Silicon.
2. 02
   2. Procure o modelo

   Na aba de pesquisa, digite «GLM-5.2» e localize o repositório unsloth GGUF. O LM Studio mostra, para cada quantização, se ela é compatível com a RAM disponível (indicador verde/laranja/vermelho).
3. 03
   3. Escolher a quantização Q2_K_XL

   Selecione a variante Q2_K_XL. LM Studio baixa todos os shards automaticamente — reserve bastante tempo, dependendo da sua conexão (200 GB).
4. 04
   4. Ajustar o contexto

   Antes de carregar, reduza o tamanho do contexto para um valor razoável (8k-16k para testar). Não configure 1M logo de início: o KV-cache faria o consumo de memória disparar.
5. 05
   5. Carregar e testar

   Clique em « Load ». Monitore a barra de memória. Após o carregamento, envie um primeiro prompt e meça a taxa exibida em tok/s.

#2. Instalação com Ollama

Ollama também pode servir o GLM-5.2 a partir de um GGUF, por meio de um Modelfile que aponta para os arquivos baixados. Essa é a opção preferencial se você quiser disponibilizar o modelo por uma API compatível com a da OpenAI para outras ferramentas (agentes, IDE, Open WebUI).

# Fichier : Modelfile
FROM ./glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf

PARAMETER num_ctx 16384
PARAMETER temperature 0.6

# Créer l'entrée Ollama à partir du Modelfile
ollama create glm-5.2 -f Modelfile

# Lancer
ollama run glm-5.2

Depois de criado, o GLM-5.2 é servido como qualquer modelo Ollama no endpoint padrão http://localhost:11434. Qualquer cliente compatível com OpenAI pode então consultá-lo apontando para esse endereço.

# Dans un autre terminal, après le premier prompt
ollama ps

#3. Configuração de Mac com 256 GB

Esta é a configuração mais elegante para o GLM-5.2. A memória unificada do Apple Silicon significa que a GPU e a CPU compartilham o mesmo pool: sem transferências dispendiosas, sem divisão manual. Um Mac Studio com 256 GB carrega o Q2_K_XL e ainda deixa espaço para um contexto confortável.

Modelo carregado

Q2_K_XL (~200 GB) cabe, com ~40-50 GB restantes para o cache KV e o sistema.

Taxa de geração esperada

Em torno de 5 a 12 tok/s na geração, dependendo do tamanho do contexto. Confortável para trabalho assíncrono, frustrante para um chat interativo rápido.

Contexto utilizável

32k a 64k sem problemas. É possível chegar a 128k+, mas isso consome rapidamente a memória por meio do KV-cache.

Ferramenta recomendada

LM Studio pela simplicidade, ou Ollama se você conectar agentes a ele.

#4. Computador com RTX 4090 em 2 bits

No PC, é preciso lidar com a separação entre VRAM e RAM. Uma única RTX 4090 (24 GB) obviamente não é suficiente para conter 200 GB: a estratégia consiste em carregar o máximo de especialistas possível na VRAM e fazer o offload do restante para a RAM do sistema via llama.cpp. A taxa de transferência passa a depender diretamente da proporção GPU/CPU e da velocidade da sua RAM.

./llama-server \
  -m glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf \
  -c 16384 \
  -ngl 99 \
  --n-cpu-moe 40 \
  -fa \
  --host 0.0.0.0 --port 8080

-ngl 99

Tenta colocar o máximo de camadas na GPU. O llama.cpp preenche a VRAM disponível e transfere o restante para a CPU.

--n-cpu-moe 40

Mantém as camadas MoE indicadas na CPU. Esse é o ajuste-chave para um MoE: o backbone denso fica na VRAM, e os especialistas são transferidos para a RAM. Ajuste o número de acordo com a VRAM disponível.

-fa

Flash Attention reduz o consumo de memória do KV-cache. Manter ativado.

Multi-GPU

Com 2 a 4 RTX 4090, o llama.cpp distribui automaticamente (--split-mode). Mais VRAM = menos offload para a CPU = maior taxa de processamento.

#5. Agentes de programação de longa duração

É aí que executar o GLM-5.2 localmente faz todo o sentido, apesar da sua lentidão. Um agente de código que refatora uma grande base de código, lê dezenas de arquivos e raciocina por horas não se importa com uma latência de alguns segundos por token: ele trabalha em segundo plano. O que importa é a qualidade do raciocínio e o contexto de 1M, que permite ao agente manter todo o repositório em mente, tudo isso sem que uma linha de código proprietário saia da sua máquina.

Contexto massivo

Um milhão de tokens permite inserir uma base de código inteira no prompt em vez de fragmentá-la, o que melhora a coerência das alterações em vários arquivos.

Tool calling

O GLM-5.2 gerencia chamadas de ferramentas no formato OpenAI, indispensável para um agente que lê, escreve e executa.

Endpoint OpenAI

Por meio do Ollama (localhost:11434) ou do llama.cpp (localhost:8080), conecte o Aider, o Cline ou qualquer agente compatível com a API da OpenAI.

Trabalho assíncrono

Inicie a tarefa e faça outra coisa. A uma taxa de 5 a 10 tok/s, uma grande refatoração leva tempo, mas é executada sem supervisão.

#Expectativas realistas e solução de problemas

Nenhum guia sério afirmará que executar um 753B localmente é fluido. Estes são os problemas reais e suas correções.

Swap em disco = morte

Se o modelo não couber na RAM e passar a usar o swap em disco, a geração passa a levar segundos por token. Reduza o contexto, use uma versão quantizada menor ou feche os outros aplicativos que consomem muita RAM.

Carregamento muito lento

Carregar 200 GB de um SSD leva vários minutos. É normal. Um SSD NVMe rápido faz uma diferença real; um disco externo USB deve ser evitado.

OOM ao carregar

No Mac, ajuste o limite da GPU (iogpu.wired_limit_mb). No PC, aumente --n-cpu-moe para enviar mais especialistas para a RAM.

Qualidade em queda

Com quantização de 2 bits, o modelo pode produzir mais alucinações. Reduza a temperatura (0,6 ou menos) e prefira as quantizações dinâmicas unsloth em vez de um Q2 uniforme.

Velocidade de geração decepcionante

Isso é esperado. Um modelo do porte dos modelos de fronteira não é rápido quando executado localmente. Se você quer velocidade, GLM-5.1 32B ou um Qwen3 responderão muito mais rapidamente.

#Para se aprofundar

O GLM-5.2 é um caso extremo que envolve quantização, hardware e implantação de agentes. Estes guias abordam os fundamentos que você precisa dominar.

O irmão menor e sensato

“GLM 5.1 rodando localmente: a alternativa com pesos abertos que vale conhecer” — se seu hardware estiver limitado a 24 GB, esse é o modelo GLM de que você precisa, com respostas muito mais rápidas.

Entender as quantizações

« Escolher a quantização (Q4, Q5, Q8, FP16) » — essencial para entender por que a quantização dinâmica de 2 bits torna o GLM-5.2 acessível sem destruí-lo.

Programar com um agente local

« Aider + Ollama: programar no terminal com um agente 100% local » — o ponto de partida para conectar o GLM-5.2 a um verdadeiro fluxo de desenvolvimento.