Moritz Conjé
Nach dem Konzept für die Suchschicht steht die erste Umsetzungsentscheidung an: Wo und wie soll das Ganze laufen? Die Antwort war schnell gefunden, der Weg dorthin nicht. Zwei Stolpersteine kosteten Zeit, und keiner davon war ein Programmierfehler. Beide beruhten auf falschen Annahmen: dass die eigene Dokumentation den aktuellen Zustand zeigt und dass sich durch Aufräumen Arbeitsspeicher freischaufeln lässt.
Keine Dienste roh auf dem Rechner
Meine Vorgabe lautete, keine einzelnen Dienste direkt auf einem NUC zu installieren. Die Lösung soll sich auf andere Hardware übertragen lassen, ohne dass etwas neu aufgebaut werden muss. Daraus wurde ein Docker-Compose-Stack aus vier Diensten:
- Postgres mit pgvector: die Datenbank, die neben normalen Daten auch die Zahlenfolgen zur Bedeutung der Notizen speichert und durchsuchbar macht.
- Ollama: stellt das Modell bereit, das diese Zahlenfolgen, die Embeddings, lokal berechnet, ganz ohne Cloud-Anbindung.
- Ingestion-Service: liest die Notizen aus dem Vault und schreibt sie samt Embedding in die Datenbank.
- MCP-Server: die Schnittstelle, über die der Redakteur die Suche als Werkzeug aufrufen kann.
Alle Dienste laufen mit fest gepinnten Versionen, nie mit latest, und zwar in einer eigenen, neu angelegten LXC statt auf der vorhandenen Docker-VM. Dort laufen bereits andere sicherheitskritische Dienste, die ich nicht mit einem neuen Experiment koppeln wollte. Der eigentliche Portabilitätsgewinn liegt im Stack selbst: Der Host bleibt austauschbar, weil sich alles per docker compose up neu starten lässt.
Welcher Host? Die Doku widersprach sich
Für die Platzierung kamen zwei Maschinen in Frage. Die Hardware-Spezifikation führte den dritten NUC, eine GMKtec NucBox G11, als "frei". Der Name eines bereits eingerichteten Claude-Connectors deutete dagegen auf Home-Assistant-Nutzung auf genau diesem Gerät hin. Bevor die LXC entstand, habe ich das gezielt nachgeprüft. Ergebnis: Die Spezifikation stammte aus der Zeit vor dem Umzug von Home Assistant. Der NUC lief seit dem 20. Juli produktiv mit einer Home-Assistant-VM und einer zweiten Docker-VM für Grafana und InfluxDB. Auch die zentrale Infrastruktur-Übersicht war an dieser Stelle nicht mehr aktuell. Beide Dokumente habe ich korrigiert, als Ziel-Host blieb der ASUS-Hauptserver (NUC 2). Wie sich die Geräte im Homelab verteilen, beschreibt der Beitrag zum Aufbau des Homelabs.
Die RAM-Jagd, die keine war
Auf dem NUC 2 waren nur etwa 6 GB Arbeitsspeicher frei, knapp für den Stack samt Embedding-Modell. Zwei Kandidaten zum Aufräumen standen fest: eine ungenutzte WireGuard-LXC, die längst durch Tailscale abgelöst ist (wie der Zugriff von unterwegs heute läuft, steht im Beitrag zu Claude Remote auf der LXC), und eine gestoppte Superset-VM, deren Projekt aktuell pausiert. Ich habe die LXC entfernt und den Status der VM geprüft, in der Erwartung, mehrere Gigabyte zurückzugewinnen.
Der Gewinn lag bei null. Beide Gäste liefen bereits nicht mehr, und ein gestoppter Proxmox-Gast belegt keinen Host-Arbeitsspeicher. Aufräumen schafft nur dann Platz, wenn das Entfernte vorher tatsächlich lief. Diese Erwartung war ein Denkfehler über die Ressourcenverwaltung, kein Zufall.
Kurswechsel: erst der Prototyp
Statt den NUC weiter auszuquetschen, läuft der Prototyp vorerst auf dem deutlich stärkeren Gaming-PC (i7-14700KF, 64 GB RAM, RTX 4070 Super), und der Stack stand dort binnen weniger Minuten, samt verifizierter GPU-Durchreichung. Welcher NUC am Ende die LXC bekommt, ist bewusst vertagt. Genau dafür war der portable Stack gedacht.
Fazit
Der Ausgangspunkt war eine einfache Frage: Wohin mit dem Stack? Die vorläufige Antwort ist der leistungsstärkere Gaming-PC, und der portable Compose-Stack macht diesen Umweg ohne Aufwand möglich; die Entwicklung kann später einfach auf anderen Geräten integriert werden.
Ausblick
Die vier Dienste sind hier nur kurz vorgestellt und bekommen in den nächsten Teilen ihren eigenen Auftritt: erst das Embedding-Modell, von dem die Hardware-Entscheidung abhängt (zwei Kandidaten treten gegeneinander an, und ein Ergebnis fiel anders aus, als der erste Messwert vermuten ließ), danach Datenbank und Ingestion und schließlich die Suche als Werkzeug. Wo der Stack am Ende produktiv läuft und ob dafür ein Umzug nötig wird, kommt in einem späteren Teil.
