Qwen 35B-A3Bを16GB M4 Macで常時稼働エージェントとして使う場合：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トークン/秒を実現する。バッチツールとしてなら、このマシンでも問題なく動作する。しかし、継続的なエージェントループに拡張し、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でプロキシ
• 1～2の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）のバグが報告されている。1つのハーネスだけなら目立たないが、2つに加えてページングを行う35Bで実際のループを実行すると、最初にディスクが限界に達する。

安定した回避策

• 35Bのllama-server LaunchDaemonを無効化（plistを.disabledにリネーム）
• 35BのGGUFと古い26BのGemmaを削除して24GBを解放
• Anthropic向けのルートはすべてOllamaへ：opus/sonnetはqwen3.5:9b、haikuはqwen3.5:4b
• どちらも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のスレッドはまだアクティブです。