Qwen 35B-A3B как постоянно активный агент на 16 ГБ M4 Mac: отказ ввода-вывода на диск до возникновения проблем с ОЗУ

Запуск модели Qwen 35B-A3B MoE в качестве постоянного агента на 16GB M4 Mac Mini (базовая конфигурация) казался возможным на бумаге: с --mmap и --flash-attn в llama.cpp, IQ3_XXS квантизация (12GB на диске) удерживает RAM на уровне 4–6ГБ за счет страничной подкачки экспертов, выдавая ~17 ток/с с --threads 8 --ctx-size 4096. Как пакетный инструмент, это работает на данной машине. Но масштабирование до непрерывного агентного цикла, работающего бок о бок с Claude Code (Opus/Sonnet) и Codex CLI, провалилось — и узким местом оказался диск, а не RAM.

Конфигурация, которая сломалась

• Демон Ollama, обслуживающий qwen3.5:9b + qwen3.5:4b (настройки: OLLAMA_MAX_LOADED_MODELS=2, OLLAMA_KEEP_ALIVE=10m, OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0)
• llama-server для 35B на отдельном порту
• Прокси LiteLLM, перенаправляющий всё на совместимый с Claude эндпоинт через :4000
• Одна или две сессии Claude Code
• Сессия Codex CLI
• Обычные домашние серверные cron, наблюдатели, очередь почты

Что пошло не так

Непрерывная страничная подкачка mmap от 35B + файловый наблюдатель/индексатор Claude Code + контекст Codex CLI = постоянная конкуренция за SSD. Mac начал самопроизвольно перезагружаться (нет логов паники в log show --predicate 'eventMessage CONTAINS "panic"'), фоновые задачи cron пропускали окна выполнения на 5+ минут, затем тихо завершались с ошибкой. Известные проблемы: у Claude Code и Codex CLI есть открытые баги по росту памяти в длительных сессиях (#22968), занятости CPU в простое (#19393) и накоплению процессов (#11122). С одним движком это незаметно; с двумя плюс страничной 35B, выполняющей реальные циклы, диск выходит из строя первым.

Стабильное обходное решение

• LaunchDaemon llama-server для 35B отключен (plist переименован в .disabled)
• Освобождено 24ГБ удалением GGUF-файла 35B и старой 26B Gemma
• Все маршруты, имитирующие Anthropic, перенаправлены на Ollama: qwen3.5:9b для opus/sonnet, qwen3.5:4b для haiku
• Обе модели находятся в памяти через Metal (около 3ГБ GPU + 0,5ГБ CPU каждая), корректно выгружаются в простое
• LiteLLM перемещен в правильный пользовательский LaunchAgent (KeepAlive=true, ThrottleInterval=30) — до этого он работал как голый процесс python -m litellm в течение 7 дней

Вывод

Мечта об агентном цикле на 35B-A3B жива на машинах другого класса. На унифицированной 16ГБ это инструмент для одноразовых пакетных задач, а не постоянный слой. Автор оценивает минимум 32ГБ унифицированной памяти для устойчивого вывода MoE-агента без проблем с подкачкой или конкуренцией демонов.

Если у вас есть трюк для устойчивой работы на 16ГБ без дисковых конфликтов, обсуждение в r/LocalLLaMA все еще активно.