Selbst gehosteter KI-Agent auf Proxmox: LXC-Guide 2026

Warum Proxmox-Homelabber ihre KI-Agenten in LXC-Containern betreiben

Wenn bei Ihnen bereits eine Proxmox-Maschine unter dem Schreibtisch summt und Pi-hole, Home Assistant sowie Nextcloud betreibt, ist ein selbst gehosteter KI-Agent der offensichtliche nächste Schritt in diesem Stack. Die Homelab-Community hat sich in der Antwort weitgehend geeinigt: Setzen Sie den Agenten in einen LXC-Container, nicht in eine VM, nicht auf den nackten Host. Ein aktueller Uptown4-Leitfaden und ein vielgeteilter dev.to-Bericht über sieben autonome Agenten auf einem 3-Node-Proxmox-Cluster landen aus demselben Grund bei LXC: Ein Agenten-Container verbraucht im Leerlauf 200-400 MB RAM und nahezu keine CPU, sodass Sie fünf bis acht davon auf einer 16-GB-Maschine unbemerkt betreiben können.

Dieser Beitrag zeigt, wie ein selbst gehosteter KI-Agent auf Proxmox 2026 konkret aussieht: wie Sie den LXC dimensionieren, ob Sie Docker darin oder nativ betreiben sollten, wie Sie ihn sichern, damit ein misslungenes Update nicht den Speicher des Agenten kostet, und wo GPU-Passthrough den Aufwand wert ist. Der Text richtet sich an Leser, die Proxmox bereits kennen und ein konkretes Rezept wollen, keine Proxmox-Einführung.

LXC vs. VM für einen KI-Agenten: die Zahlen zählen wirklich

Die häufigste Frage lautet, ob ein LXC-Container oder eine vollständige QEMU-VM verwendet werden soll. Für einen textbasierten KI-Agenten, der mit einer Cloud-LLM-API spricht, gewinnt LXC auf jeder Achse, die für einen Homelabber zählt.

Der Overhead-Unterschied ist real. Ein reines Debian-LXC verbraucht 30-60 MB RAM vor jedem Dienst, während eine Debian-VM mit demselben Footprint 200-400 MB benötigt, vor allem weil der Container keinen Gast-Kernel, kein QEMU und keinen virtio-Gerätezustand braucht (Quelle). Der CPU-Overhead liegt bei etwa 1-3 % für LXC gegenüber 5-15 % für VMs, und Container starten in 1-3 Sekunden statt in 30-90. Ein Produktions-Cluster berichtete von 180 LXC-Containern auf Hardware, die zuvor 35 VMs trug, eine 5-fache Dichte.

Für einen KI-Agenten wirkt sich das konkret aus. Die Agenten-Laufzeit selbst ist klein: ein Python- oder Node-Prozess, ein Postgres für den Zustand und ein Webhook-Listener. Die schwere Arbeit läuft auf der GPU einer anderen Instanz, bei OpenAI, Anthropic oder einer lokalen Ollama-VM auf demselben Host. Der Container ist ein leichtgewichtiger Koordinator, keine Last. VM-Overhead für einen Koordinator zu zahlen, ist Geld, das Sie in weitere Agenten stecken könnten.

Der einzige Punkt, an dem VMs gewinnen, ist Isolation. Wenn Sie dem Code des Agenten oder seinen Erweiterungen nicht vertrauen, ist eine VM die stärkere Grenze. Für einen persönlichen Agenten, den Sie selbst geschrieben oder eine Open-Source-Laufzeit, die Sie geprüft haben, reicht das Shared-Kernel-Modell von LXC.

Das Referenzrezept: LXC Ubuntu 22.04, 2 Kerne, 2 GB, 8 GB Disk

Die Standardgröße für einen ersten selbst gehosteten KI-Agenten auf Proxmox ist bewusst klein. Sie können den Container jederzeit vergrößern, und es gibt keinen Grund, RAM zu reservieren, den Sie nicht nutzen.

Einstellung	Wert	Warum
Template	`ubuntu-22.04-standard`	Die am besten unterstützte Basis für Docker, Node, Python
CPU	2 Kerne	Leerlauflast ist trivial, aber LLM-Callbacks sind IO-Spitzen
RAM	2 GB	Genug Puffer für Postgres plus den Agenten-Prozess
Swap	512 MB	Günstige Absicherung gegen einen Chrome-artigen Speicherpeak
Disk	8 GB local-lvm	Später vergrößern, falls Sie einen Vector Store auf Disk ergänzen
Netzwerk	vmbr0, DHCP	Hinter Ihrem Router, nicht direkt am WAN
Unprivilegiert	Ja	Standard; belassen, außer Sie brauchen Docker
Features	`nesting=1, keyctl=1`	Nur wenn Sie Docker im Container betreiben

Legen Sie ihn über die Proxmox-Oberfläche oder mit pct create per SSH auf dem Host an. Wenn Sie Docker im Container betreiben wollen (siehe nächster Abschnitt), aktivieren Sie nesting und keyctl bereits bei der Erstellung, nicht später; das nachträglich zu ändern bedeutet, die Konfiguration anzupassen und den Container neu zu starten.

Sobald der Container läuft, härten Sie ihn wie jede Maschine der Debian-Familie: ein Nicht-Root-Benutzer mit sudo, SSH-Keys statt Passwörtern, unattended-upgrades aktiviert und den Tailscale-Client installiert, wenn Sie ihn vom Handy aus erreichen wollen, ohne einen Port auf dem Router zu öffnen.

Docker im LXC oder natives systemd?

Es gibt zwei Philosophien, wie Sie den Agenten-Prozess betreiben, und beide funktionieren.

Docker im LXC. Sie installieren Docker in einem unprivilegierten Ubuntu-22.04-Container mit aktiviertem Nesting und starten den Agenten aus einer docker-compose.yml. Das spiegelt wider, was die meisten selbst gehosteten KI-Agenten-Laufzeiten ausliefern, also folgen Sie den exakten Anweisungen des Anbieters. Der Preis ist etwas Komplexität: Der Container muss mit features: nesting=1,keyctl=1 erstellt werden, und beim Debuggen stellt sich manchmal die Frage, ob das Problem am Container, an Docker oder am Agenten liegt. Der CoSci-Guide zu Docker im Proxmox-LXC beschreibt die benötigten Flags im Detail.

Natives systemd. Sie überspringen Docker vollständig und installieren den Agenten, seine Python- oder Node-Laufzeit und Postgres direkt im LXC als systemd-Dienste. Das ist leichter, einfacher zu überblicken und harmoniert deutlich besser mit LXC-Snapshots (Sie fotografieren ein echtes Dateisystem, keinen Stapel Overlay-Schichten). Der Preis: Nicht jeder Open-Source-Agent veröffentlicht saubere systemd-Anleitungen, sodass Sie am Ende ein Dockerfile in eine systemd-Unit übersetzen müssen.

Für einen ersten Aufbau ist Docker im LXC fast immer die pragmatische Wahl, er lässt Sie der gewählten Laufzeit ohne Abweichung folgen. Für einen langlebigen Homelab-Agenten, den Sie jahrelang pflegen wollen, lohnt sich natives systemd. Siehe unseren Guide zum selbst gehosteten KI-Agenten in Docker für die Form der compose-Datei, bei der beide Wege landen.

Snapshots und Backups: das Eine, was Sie nicht überspringen dürfen

Ein KI-Agent sammelt Speicher an: Gespräche, Embeddings, geplante Jobs, Nutzerpräferenzen. Nach einem Monat ist dieser Zustand mehr wert als der Container selbst. Proxmox gibt Ihnen dafür zwei verwandte, aber unterschiedliche Werkzeuge, und der Unterschied gehört ausdrücklich benannt: Ein Snapshot ist kein Backup. Ein Snapshot liegt auf derselben Disk wie der Container, also nimmt eine defekte SSD beides mit.

Das Homelab-Rezept, das im Alltag hält:

Snapshot vor jedem Upgrade. Nehmen Sie im Tab Snapshots des Containers einen direkt vor apt upgrade, vor dem Bearbeiten von docker-compose.yml, vor dem Umlegen eines Feature-Flags. Der Rollback ist ein Klick, wenn das Upgrade die Tool-Schleife des Agenten zerlegt.
Nächtliche Backups auf den Proxmox Backup Server. PBS ist das richtige Werkzeug: Es dedupliziert mit variabler Chunk-Länge, sodass sieben nächtliche Backups eines 4-GB-LXC näher an 4 GB als an 28 GB liegen. Betreiben Sie PBS auf einer zweiten kleinen Maschine oder einem NAS, nicht auf dem Proxmox-Host selbst.
Snapshot-Modus, nicht Stop-Modus. Für einen Agenten, mit dem Nutzer über Telegram sprechen, ist der Snapshot-Modus der richtige Default: Der Container läuft während des Backups weiter. Der Stop-Modus ist sicherer für Datenbanken, verliert aber eingehende Nachrichten.
Halten Sie eine Aufbewahrungsrichtlinie ein. Eine übliche Retention, die für persönliche Agenten funktioniert: die letzten 3 Backups, täglich für 7 Tage, wöchentlich für 4 Wochen, monatlich für 6 Monate. Testen Sie den Restore mindestens einmal, bevor Sie ihn wirklich brauchen.

Wenn Sie PBS überspringen, senden Sie zumindest vzdump-Archive per Cron auf eine externe Disk. Die Erinnerungen eines Homelab-Agenten wegen einer toten Disk zu verlieren, ist ein schlechter Weg herauszufinden, dass Snapshots nie Backups waren.

GPU-Passthrough: fast nie den Aufwand wert

Der verführerische Homelab-Traum ist eine lokale GPU mit Ollama, gekoppelt mit einem Proxmox-LXC-Agenten, sodass der gesamte Stack im Haus bleibt. Technisch möglich und im richtigen Setup befriedigend. Aber seien Sie ehrlich zum Trade-off.

Die meisten Homelabs sind bandbreitenbegrenzt für ernsthafte lokale Inferenz. Eine einzelne RTX 3090 fährt ein 32B-Modell mit vielleicht 30-50 Tokens pro Sekunde, was für Chat passt, für einen Agenten, der Tool-Aufrufe in Schleife absetzt, aber träge wirkt. Alles Größere braucht professionelle GPUs, die mehr kosten als ein Gebrauchtwagen. Und die operative Steuer ist real: Kernel-Module, PCIe-Passthrough-Eigenheiten, Treiber-Updates, die den LXC-Namespace zerlegen, alles Dinge, für die Sie sich nicht angemeldet haben, als Sie einen KI-Assistenten auf Telegram wollten.

Das pragmatische Homelab-Muster 2026 ist das kleine Box, großes Gehirn woanders-Setup. Betreiben Sie den Agenten in einem 2-GB-LXC auf einem gebrauchten Mini-PC für 200 Dollar, der Cent-Beträge an Strom verbraucht, und lassen Sie das Modell bei OpenRouter, OpenAI oder Anthropic leben. Ihr Datenschutz-Narrativ lautet dann „der Agent-Code läuft auf meiner Hardware, der API-Aufruf ist zustandslos, der Anbieter behält keine Daten", was verteidigbar und günstig ist. Wenn Sie später lokale Modelle für bestimmte Aufgaben wollen, setzen Sie Ollama in eine Nachbar-VM mit GPU-Passthrough und lassen den Agenten sie als einen Anbieter unter mehreren aufrufen.

Wann Proxmox die falsche Antwort ist

Proxmox ist fantastisch, wenn Sie sich bereits darauf festgelegt haben. Wenn nicht, seien Sie ehrlich, was Sie wirklich wollen.

Sie wollen einfach nur einen KI-Agenten auf Telegram. Verwaltetes Hosting ist eine Minute und ein Kaffee. Proxmox ist ein Wochenende und ein gebrauchter Mini-PC. Siehe unsere Analyse zu Preisen von Hermes Agent selbst gehostet vs. verwaltet.
Sie betreiben noch kein Proxmox. Die Proxmox-Lernkurve lohnt sich für ein 10-Dienste-Homelab, nicht für einen einzelnen KI-Agenten. Ein 5-Dollar-VPS und Docker Compose bringen Sie an einem Abend ans Ziel.
Sie wollen eine starke Sicherheitsgrenze zwischen dem Agenten und allem anderen auf der Box. Nutzen Sie eine VM statt eines LXC oder gleich eine separate Maschine.

Die Hermify-Alternative: gleiche Kontrolle, ohne Container

Es gibt einen Mittelweg, bei dem viele Homelabber nach ein paar Upgrade-Zyklen tatsächlich landen. Betreiben Sie das Gewöhnliche auf Proxmox (Home Assistant, Medien, Netzwerk) und lassen Sie einen verwalteten Hermes Agent die KI-Seite übernehmen. Sie behalten dieselbe „Ihre Daten, Ihr Modell-Schlüssel, Ihr Agent"-Erzählung, ohne einen LXC zu betreuen oder eine PBS-Retention zu bedenken. Hermify betreibt die Container-Flotte, Sie bringen Ihren OpenRouter- oder OpenAI-Schlüssel mit, und der Agent lebt in etwa einer Minute auf Telegram. Starten Sie mit Hermify, wenn dieser Deal für Sie interessanter ist als ein weiterer Node im Cluster.