16GB M4 Mac에서 상시 작동 에이전트로 Qwen 35B-A3B 실행 시: RAM보다 먼저 디스크 I/O 실패

16GB M4 Mac Mini(기본 사양)에서 Qwen 35B-A3B MoE 모델을 항상 켜져 있는 에이전트로 실행하는 것은 이론적으로 가능해 보였습니다. llama.cpp --mmap 및 --flash-attn 옵션을 사용하면 IQ3_XXS 양자화(디스크 12GB)가 전문가 페이징을 통해 RAM 상주를 4-6GB로 유지하며, --threads 8 --ctx-size 4096으로 약 17 tok/s를 제공합니다. 배치 도구로서는 이 머신에서 작동합니다. 그러나 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)
• 35B용 llama-server는 별도 포트에서 실행
• LiteLLM 브리지가 모든 것을 Claude 호환 엔드포인트로 프록시 (:4000)
• 하나 또는 두 개의 Claude Code 세션
• Codex CLI 세션
• 일반적인 홈 서버 cron, 감시자, 메일 큐

실패한 부분

35B의 지속적인 mmap 페이징 + Claude Code의 파일 감시자/인덱서 + Codex의 컨텍스트 유지로 인해 SSD 경합이 계속 발생했습니다. Mac이 자발적으로 재부팅되기 시작했고 (log show --predicate 'eventMessage CONTAINS "panic"'에서 크래시 로그 없음), 백그라운드 cron 작업이 5분 이상 지연된 후 조용히 실패했습니다. 알려진 문제로는 Claude Code 및 Codex CLI에 긴 세션에서 메모리 증가(#22968), 유휴 CPU 고정(#19393), 프로세스 누적(#11122)에 대한 버그가 있습니다. 하나의 하네스에서는 보이지 않지만, 두 개에 페이징하는 35B가 실제 루프를 돌면 디스크가 먼저 죽습니다.

안정적인 해결 방법

• 35B llama-server LaunchDaemon 비활성화 (plist를 .disabled로 이름 변경)
• 35B GGUF 및 오래된 26B Gemma를 삭제하여 24GB 회수
• 모든 Anthropic 형태의 경로는 Ollama로 이동: qwen3.5:9b는 opus/sonnet용, qwen3.5:4b는 haiku용
• 둘 다 Ollama를 통해 Metal 상주 (각각 GPU ~3GB + CPU 0.5GB), 유휴 시 깔끔하게 제거
• LiteLLM을 적절한 사용자 LaunchAgent로 이동 (KeepAlive=true, ThrottleInterval=30) — 이전에는 7일 동안 python -m litellm 프로세스로 실행 중이었음

결론

35B-A3B를 에이전트 루프로 사용하는 꿈은 다른 등급의 머신에서 실현 가능합니다. 통합 16GB에서는 단일 목적 배치 도구일 뿐, 항상 켜져 있는 레이어가 아닙니다. 저자는 스왑 문제나 데몬 경합 없이 지속적인 MoE 에이전트 추론을 위해 최소 32GB 통합 메모리가 필요하다고 추정합니다.

디스크 경합 없이 16GB에서 지속적으로 실행하는 방법을 알고 계신다면, r/LocalLLaMA 스레드가 아직 활성화되어 있습니다.