Qwen 35B-A3B como agente sempre ativo em M4 Mac de 16GB: falha de I/O de disco antes da RAM

Executar um modelo MoE Qwen 35B-A3B como um agente sempre ativo em um Mac Mini M4 de 16GB (configuração básica) parecia plausível no papel: com --mmap e --flash-attn do llama.cpp, o quant IQ3_XXS (12GB em disco) mantém-se residente na RAM entre 4 e 6GB via paginação por especialista, entregando ~17 tok/s com --threads 8 --ctx-size 4096. Como ferramenta de lote, funciona nesta máquina. Mas ao escalar para um loop agentivo contínuo, rodando junto com Claude Code (Opus/Sonnet) e Codex CLI, o sistema colapsou — e o gargalo foi o disco, não a RAM.

A configuração que quebrou

• Daemon Ollama servindo qwen3.5:9b + qwen3.5:4b (config: OLLAMA_MAX_LOADED_MODELS=2, OLLAMA_KEEP_ALIVE=10m, OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0)
• llama-server para o 35B em sua própria porta
• Bridge LiteLLM proxyando tudo como um endpoint compatível com Claude na porta :4000
• Uma ou duas sessões do Claude Code
• Sessão do Codex CLI
• Servidor doméstico usual com cron, watchers, fila de e-mail

O que falhou

Paginação contínua mmap do 35B + observador/indexador de arquivos do Claude Code + contexto mantido pelo Codex = contenção constante de SSD. O Mac começou a reiniciar espontaneamente (sem logs de crash em log show --predicate 'eventMessage CONTAINS "panic"'), tarefas cron de fundo perderam janelas por 5+ minutos e depois falharam silenciosamente. Problemas conhecidos: Claude Code e Codex CLI têm bugs abertos para crescimento de memória em sessões longas (#22968), uso contínuo de CPU ociosa (#19393) e acúmulo de processos (#11122). Com uma ferramenta é imperceptível; com duas mais um 35B paginado fazendo loops reais, o disco morre primeiro.

Solução estável

• LaunchDaemon do 35B llama-server desabilitado (plist renomeado para .disabled)
• 24GB recuperados deletando o GGUF do 35B e um Gemma 26B antigo
• Todas as rotas para Anthropic agora vão para Ollama: qwen3.5:9b para opus/sonnet, qwen3.5:4b para haiku
• Ambos residentes via Metal no Ollama (~3GB GPU + 0.5GB CPU cada), removem-se limpos em idle
• LiteLLM movido para um LaunchAgent de usuário adequado (KeepAlive=true, ThrottleInterval=30) — estava rodando como um simples processo python -m litellm há 7 dias

A conclusão

O sonho do agente em loop com 35B-A3B está vivo em uma classe diferente de máquina. Em 16GB unificados, é uma ferramenta de lote para propósito único, não uma camada sempre ativa. O autor estima mínimo de 32GB de memória unificada para inferência sustentada de agente MoE sem sofrimento com swap ou contenção de daemons.

Se você tem um truque para rodá-lo de forma sustentável em 16GB sem contenção de disco, o tópico no r/LocalLLaMA ainda está ativo.