Qwen 35B-A3B como agente siempre activo en Mac M4 de 16 GB: la E/S de disco falla antes que la RAM

Ejecutar un modelo MoE Qwen 35B-A3B como agente siempre activo en una Mac Mini M4 de 16 GB (especificación básica) parecía plausible sobre el papel: con --mmap y --flash-attn de llama.cpp, el cuantizado IQ3_XXS (12 GB en disco) mantiene residente en RAM de 4 a 6 GB mediante paginación experta, entregando ~17 tok/s con --threads 8 --ctx-size 4096. Como herramienta por lotes, funciona en este equipo. Pero escalar a un bucle agéntico continuo, junto a Claude Code (Opus/Sonnet) y Codex CLI, colapsó, y el cuello de botella fue el disco, no la RAM.

La configuración que falló

• Daemon de Ollama sirviendo 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 el 35B en su propio puerto
• Puente LiteLLM proxyando todo como un endpoint compatible con Claude en :4000
• Una o dos sesiones de Claude Code
• Sesión de Codex CLI
• Cron habitual del servidor doméstico, watchers, cola de correo

Lo que falló

La paginación mmap continua del 35B + el watcher/indexador de archivos de Claude Code + el contexto de Codex = contención constante del SSD. El Mac comenzó a reiniciarse espontáneamente (sin registros de pánico en log show --predicate 'eventMessage CONTAINS "panic"'), los trabajos cron de fondo perdieron ventanas por más de 5 minutos y luego fallaron silenciosamente. Problemas conocidos: Claude Code y Codex CLI tienen errores abiertos por crecimiento de memoria en sesiones largas (#22968), uso constante de CPU en inactividad (#19393) y acumulación de procesos (#11122). Con un solo arnés es invisible; con dos más un 35B paginando en bucles reales, el disco muere primero.

Solución alternativa estable

• LaunchDaemon de llama-server del 35B deshabilitado (plist renombrado a .disabled)
• 24 GB recuperados eliminando el GGUF del 35B y un Gemma 26B antiguo
• Todas las rutas de estilo Anthropic van a Ollama: qwen3.5:9b para opus/sonnet, qwen3.5:4b para haiku
• Ambos residentes en Metal mediante Ollama (~3 GB GPU + 0.5 GB CPU cada uno), se liberan limpiamente en inactividad
• LiteLLM movido a un LaunchAgent de usuario adecuado (KeepAlive=true, ThrottleInterval=30) — había sido un proceso python -m litellm desnudo durante 7 días

Conclusión

El sueño del bucle agéntico con 35B-A3B está vivo en una clase diferente de equipo. En una unificada de 16 GB, es una herramienta por lotes de un solo propósito, no una capa siempre activa. El autor estima un mínimo de 32 GB de memoria unificada para inferencia agéntica MoE sostenida sin problemas de swap ni contención de daemons.

Si tienes un truco para ejecutarlo de manera sostenible en 16 GB sin contención de disco, el hilo en r/LocalLLaMA sigue activo.