Otimizando o GLM-4.7-Flash no Mac Mini M4 com 24 GB de RAM

Configuração Prática para GLM-4.7-Flash no Hardware M4
Um desenvolvedor testando OpenClaw e Ollama em um Mac Mini M4 com 24GB de RAM compartilhou detalhes específicos de otimização para executar o modelo GLM-4.7-Flash. A fonte fornece realidades concretas de alocação de memória e parâmetros de configuração que funcionam dentro das limitações do hardware.
Realidade de Memória e Seleção de Modelo
Os testes revelam que o orçamento efetivo de memória GPU no M4 Mini é aproximadamente 17.8GB Metal (GPU-wired), não os 24GB completos. O restante é consumido pelo macOS, aplicativos e computação da CPU. Esta limitação afeta a seleção do modelo e o tamanho do contexto.
- Quantização Q4_K_XL (17.5GB GGUF) não consegue lidar com contexto de 32k: Modelo (14.4GB) + KV (2.8GB) + computação (1.4GB) = 18.6GB → Sem Memória
- Quantização Q3_K_XL (13.8GB GGUF) funciona em contexto de 32k: Modelo (12.7GB) + KV (3.2GB) + computação (1.4GB) = 16.1GB com 1.7GB de margem
- O limite de contexto é aproximadamente 34k antes que ocorra falta de memória
Detalhes da Configuração
A configuração bem-sucedida utiliza:
- Modelo: unsloth/GLM-4.7-Flash-GGUF do Hugging Face
- Quantização: Q3_K_XL
- Tamanho do contexto: 32k com MLA (Multi-Head Latent Attention)
- Implementação do cache KV: cache KV sem v do llama.cpp (PR #19067, Jan 2026) acionado por metadados GGUF (key_length_mla, kv_lora_rank)
- Requisito de compilação: llama.cpp b7860+
A implementação MLA reduz significativamente o uso de memória KV - o cache KV de contexto de 32k é apenas 3.2GB em vez de 13GB.
Considerações Específicas da Estrutura
Estruturas agentes como OpenClaw têm limiares de contexto internos que afetam o desempenho:
- OpenClaw aciona compactação agressiva abaixo de 32k de contexto
- Aumentar o contexto de 20k para 32k reduziu o tempo de inicialização de 5 minutos para 2 minutos e 17 segundos
- As passagens de compactação caíram de 2 para 1 ao combinar num_ctx com os limiares da estrutura
- num_ctx deve ser incorporado ao Modelfile do Ollama - OpenClaw e outros orquestradores que usam a API compatível com OpenAI do Ollama ignoram-no no nível da solicitação
Dados de Teste de Desempenho
O desenvolvedor forneceu dados de tempo específicos para várias tarefas:
Tarefa Tempo Tokens de Entrada Compactações Resultado Introdução de personalidade 119s ~13,900 2 ✅ Recuperação de perfil 60s 13,247 2 ✅ com ressalva Criação de tarefa 61s 13,375 2 ✅ Gravação de memória 165s 14,448 2 ✅ Recuperação de memória 89s 14,085 2 ✅ Busca web + síntese 273s 18,668 2 ✅
Considerações sobre MLX
O desenvolvedor observa que MLX e GGUF são formatos diferentes - arquivos GGUF Unsloth/bartowski não podem ser executados com mlx-lm. Atualmente, não existe nenhum modelo Flash de 3 bits no repositório mlx-community, apenas modelos de 4 bits estão disponíveis.
📖 Leia a fonte completa: r/openclaw
👀 See Also

Como um Agente Inativo Queimava 50M Tokens por Dia – e Como Corrigir Isso
Um agente OpenClaw ocioso queimava 50 milhões de tokens por dia com pings de heartbeat em uma sessão inchada. Um usuário do Reddit conta como rastreou o vazamento e o corrigiu com alterações na configuração.

Resultados de Teste do Plugin de Memória OpenClaw e Pilha Recomendada
Um usuário do Reddit testou todos os plugins de memória do OpenClaw e descobriu que a configuração padrão de markdown causa inchaço de tokens e compressão de instruções. A configuração recomendada combina Obsidian para notas legíveis por humanos, QMD para busca sem tokens e SQLite para dados estruturados.

OpenClaw 101: Um Resumo Rápido para Iniciantes
Nenhum

OpenClaw 4.1 com Gemma 4 Stack: Arquitetura Híbrida e Correções de Configuração
Uma postagem no Reddit detalha uma pilha de agentes locais otimizada que combina o OpenClaw 4.1 com o modelo Gemma 4 do Google, apresentando uma arquitetura híbrida, correções de configuração específicas para chamadas de ferramentas do Ollama e ajustes na janela de contexto.