Qwen 35B-A3B als ständig aktiver Agent auf 16 GB M4 Mac: Festplatten-I/O versagt vor RAM

Die Ausführung eines Qwen 35B-A3B MoE-Modells als ständig aktiven Agenten auf einem 16GB M4 Mac Mini (Basisausstattung) schien auf dem Papier plausibel: Mit llama.cpp --mmap und --flash-attn hält die IQ3_XXS-Quantisierung (12 GB auf der Festplatte) den RAM mithilfe von Expert-Paging bei 4–6 GB und liefert ~17 tok/s mit --threads 8 --ctx-size 4096. Als Batch-Tool funktioniert es auf diesem Rechner. Aber die Skalierung auf eine kontinuierliche agentische Schleife, die neben Claude Code (Opus/Sonnet) und Codex CLI läuft, brach zusammen – und der Engpass war die Festplatte, nicht der RAM.

Das Setup, das brach

• Ollama-Daemon, der qwen3.5:9b + qwen3.5:4b bereitstellt (Konfiguration: OLLAMA_MAX_LOADED_MODELS=2, OLLAMA_KEEP_ALIVE=10m, OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0)
• llama-server für die 35B auf einem eigenen Port
• LiteLLM-Bridge, die alles als Claude-kompatiblen Endpunkt auf :4000 proxyed
• Eine oder zwei Claude Code-Sitzungen
• Codex CLI-Sitzung
• Übliche Home-Server-Cron, Watcher, Mail-Queue

Was fehlschlug

Kontinuierliches mmap-Paging von der 35B + Claude Codes Datei-Watcher/Indexer + Codex, das Kontext hält = ständige SSD-Konflikte. Der Mac begann spontan neu zu starten (keine Absturzprotokolle in log show --predicate 'eventMessage CONTAINS "panic"'), Hintergrund-Cron-Jobs verpassten Fenster um 5+ Minuten und scheiterten dann still. Bekannte Probleme: Claude Code und Codex CLIs haben offene Fehler für Speicherwachstum in langen Sitzungen (#22968), Leerlauf-CPU-Auslastung (#19393) und akkumulierende Prozesse (#11122). Mit einem Framework ist es unsichtbar; mit zwei plus einer pagingenden 35B, die echte Schleifen ausführt, stirbt zuerst die Festplatte.

Stabiler Workaround

• 35B llama-server LaunchDaemon deaktiviert (plist in .disabled umbenannt)
• 24 GB durch Löschen des 35B GGUFs und eines alten 26B Gemma zurückgewonnen
• Alle Anthropic-geformten Routen gehen zu Ollama: qwen3.5:9b für opus/sonnet, qwen3.5:4b für haiku
• Beide Metal-resident über Ollama (~3 GB GPU + 0,5 GB CPU jeweils), räumen bei Leerlauf sauber auf
• LiteLLM zu einem ordentlichen Benutzer-LaunchAgent verschoben (KeepAlive=true, ThrottleInterval=30) – es war ein bloßer python -m litellm-Prozess für 7 Tage

Das Fazit

Der Traum von 35B-A3B-als-Agenten-Schleife lebt auf einer anderen Rechnerklasse. Auf einheitlichen 16 GB ist es ein Single-Purpose-Batch-Tool, keine ständig aktive Schicht. Der Autor schätzt mindestens 32 GB einheitlichen Speicher für anhaltende MoE-Agenten-Inferenz ohne Swap-Probleme oder Daemon-Konflikte.

Falls Sie einen Trick haben, um es nachhaltig auf 16 GB ohne Festplattenkonflikte zu betreiben, der Thread auf r/LocalLLaMA ist noch aktiv.