ADR-011: Dedizierte Maschine für KI-Inferenz mit llama-swap als einzigem Backend¶

Feld	Wert
Status	accepted
Datum	2026-07-31
Betrifft	aiserver, homeserver

Kontext¶

Lokale Sprachmodelle liefen bis Mitte 2026 auf dem Intel NUC — Ollama mit IPEX-Beschleunigung auf der Intel Iris Xe, dazu eine zweite Ollama-Instanz für Vision-Modelle auf der CPU. Der NUC trägt gleichzeitig rund 65 weitere Container, darunter Home Assistant, den Medien-Stack und den Monitoring-Stack.

Daraus ergaben sich zwei Probleme, die sich nicht gleichzeitig lösen ließen:

Die Modelle waren zu klein für ihre Aufgaben. Die Iris Xe teilt sich den Systemspeicher; praktikabel waren 3–4B-Modelle. Für die Sprachsteuerung reichte das nicht: Tool-Calling blieb inkonsistent, in Multi-Turn-Gesprächen kam es zu Token-Collapse. Als Übergangslösung wurde Google Gemini als Conversation-Agent eingebunden — womit transkribierter Text, Entity-Liste und Gesprächsverlauf das Haus verließen, entgegen dem Grundsatz, sensible Daten lokal zu halten.

Inferenz und Hausautomation konkurrieren um dieselbe Maschine. Ein laufendes Modell belegt Speicher und iGPU, die Home Assistant und der Medien-Stack ebenfalls brauchen. Eine dauerhafte Auslastung der Inferenz hätte den produktiven Betrieb beeinträchtigt.

Entscheidung¶

Erstens: KI-Inferenz bekommt eine eigene Maschine — eine Corsair AI Workstation 300 mit AMD Ryzen AI Max+ 395 „Strix Halo" und 128 GB Unified Memory, davon 96 GB als GTT für die iGPU freigegeben. Sie läuft bare metal mit Docker, ohne Hypervisor, und ist nicht extern erreichbar.

Zweitens: Auf dieser Maschine ist llama-swap das einzige LLM-Backend. Ollama wurde am 31.07.2026 gestoppt. Alle Rollen laufen als llama.cpp-Instanzen über Vulkan/RADV, in drei Gruppen aufgeteilt: resident (dauerhaft geladen), docs (bleiben zusammen geladen) und heavy (swappen, eine aktiv).

Der Ollama-Blob-Store bleibt als Dateiquelle erhalten — llama.cpp liest dieselben GGUF-Dateien read-only, es gibt keinen doppelten Download.

Beide Entscheidungen fielen nicht nach Datenblatt, sondern nach zwei Testrunden mit Turnieren je Rolle. Die Ergebnisse stehen in Modell-Rollen.

Alternativen¶

Option	Ergebnis
Bei Ollama auf dem NUC bleiben	Löst keines der beiden Probleme. Modellgröße bleibt durch die Iris Xe begrenzt, die Konkurrenz um Ressourcen bleibt bestehen.
Ollama auf der neuen Maschine	War der Ausgangszustand nach dem Aufbau. Gemessen unterlegen: `brain` erreicht mit MTP-Speculative-Decoding auf llama-swap 89 t/s statt 64 t/s. Dazu Fehlerbilder, die llama.cpp nicht zeigt — leere Antworten bei `qwen3-vl:4b`, und ein Standard-Kontext von 262k, der `german-ocr` auf 12 statt 4 GB aufblähte.
Beide Backends parallel (Ollama für Bequemlichkeit, llama-swap für Tempo)	War als Zielbild der ersten Ausbaustufe vorgesehen und wurde verworfen: doppelter Speicherbedarf, zwei Konfigurationsorte, zwei Fehlerquellen. Der Nutzen von Ollamas Modellverwaltung wiegt das nicht auf — Modelle ziehen lässt sich der gestoppte Container bei Bedarf weiterhin.
vLLM	Braucht auf Strix Halo float32; bfloat16 hängt die GPU auf. Sein Vorteil ist Multi-User-Batching, das bei Einzelnutzung keinen Wert hat.
Weiter Gemini als Conversation-Agent	Funktioniert und kostet wenig, verletzt aber die Datengrenze und fällt bei WAN-Ausfall aus.
KI-Last auf den NUC zurückholen, Hardware sparen	Die Anschaffung ist der teure Teil der Entscheidung. Sie rechtfertigt sich über den Dauerbetrieb: Sprachsteuerung, Dokumentenkette und RAG laufen ständig, nicht gelegentlich.

Konsequenzen¶

Positiv:

Modelle bis 35B laufen lokal; der Sprachpfad kommt auf 634 ms End-to-End und braucht keinen Cloud-Dienst mehr
Der NUC ist von Inferenzlast befreit
Ein Konfigurationsort für alle Rollen: llama-swap/config.yaml ist zugleich die Rollenkarte
Residente Modelle sind vor Verdrängung geschützt — der Sprachpfad wartet nicht, auch wenn parallel ein großes Modell rechnet
Jede Rolle ist durch eine Messung belegt, nicht durch eine Annahme

Negativ:

Eine weitere Maschine im Betrieb: eigenes Backup, eigenes Monitoring, eigene Update-Politik
Die Konfiguration ist anspruchsvoller als bei Ollama. Mehrere Flags sind Pflicht, und ihr Fehlen erzeugt kein Fehlerbild, sondern schlechtes Verhalten — siehe llama-swap
Modelle liegen als Blobs im Ollama-Store, die Ollama nicht als fremdgenutzt kennt. Ein unbedachtes ollama rm zerstört vier Rollen
Übergangszustand: Ollama, Open WebUI und der Sprachpfad laufen weiterhin auch auf dem NUC. Bis zur Abschaltung gibt es sie doppelt
Die RAG-Kette (Qdrant, Docling) ist auf der neuen Maschine noch nicht nachgebaut und hält den NUC-Stack am Leben