Qwen 35B-A3B en tant qu'agent toujours actif sur Mac M4 de 16 Go : les E/S disque échouent avant la RAM

Lancer un modèle MoE Qwen 35B-A3B comme agent toujours actif sur un Mac Mini M4 16 Go (configuration de base) semblait plausible sur le papier : avec --mmap et --flash-attn de llama.cpp, la quantification IQ3_XXS (12 Go sur le disque) maintient une empreinte RAM de 4 à 6 Go grâce au pagination par expert, offrant ~17 tok/s avec --threads 8 --ctx-size 4096. En tant qu'outil par lots, ça fonctionne sur cette machine. Mais le passage à une boucle agentique continue, aux côtés de Claude Code (Opus/Sonnet) et Codex CLI, a échoué — et le goulot d'étranglement était le disque, pas la RAM.

La configuration qui a planté

• Démon Ollama servant 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 pour le 35B sur son propre port
• Pont LiteLLM proxyant tout vers un endpoint compatible Claude sur :4000
• Une ou deux sessions Claude Code
• Session Codex CLI
• Cron habituel du serveur domestique, watchers, file d'attente de courrier

Ce qui a échoué

La pagination mmap continue du 35B + le watcher/indexeur de fichiers de Claude Code + le contexte de Codex = contention SSD constante. Le Mac a commencé à redémarrer spontanément (aucun journal de panique dans log show --predicate 'eventMessage CONTAINS "panic"'), les tâches cron en arrière-plan ont manqué leurs fenêtres de 5 minutes ou plus, puis ont échoué silencieusement. Problèmes connus : les CLI Claude Code et Codex ont des bugs ouverts pour la croissance mémoire lors de longues sessions (#22968), l'utilisation CPU inactif (#19393), et l'accumulation de processus (#11122). Avec un seul harnais c'est invisible ; avec deux plus un 35B paginant en boucle, le disque meurt en premier.

Solution de contournement stable

• LaunchDaemon llama-server du 35B désactivé (plist renommé .disabled)
• 24 Go récupérés en supprimant le GGUF du 35B et un vieux Gemma 26B
• Toutes les routes de type Anthropic vont vers Ollama : qwen3.5:9b pour opus/sonnet, qwen3.5:4b pour haiku
• Tous deux résidents Metal via Ollama (~3 Go GPU + 0,5 Go CPU chacun), se nettoient proprement au repos
• LiteLLM déplacé vers un LaunchAgent utilisateur approprié (KeepAlive=true, ThrottleInterval=30) — c'était un processus python -m litellm nu depuis 7 jours

Le constat

Le rêve du 35B-A3B en boucle agentique est réalisable sur une machine d'une autre catégorie. Sur une mémoire unifiée de 16 Go, c'est un outil par lots dédié, pas une couche toujours active. L'auteur estime qu'il faut 32 Go de mémoire unifiée minimum pour une inférence agentique MoE soutenue sans souffrance du swap ni contention de démon.

Si vous avez une astuce pour le faire fonctionner durablement sur 16 Go sans contention disque, le fil sur r/LocalLLaMA est toujours actif.