Warum ich begonnen habe, ein lokales LLM auf eigenem Server zu betreiben – und was das konkret bedeutet: Hardware, Virtualisierung, GPU-Wahl und die realen Grenzen lokaler Modelle.
Die Nutzung lokaler Large Language Models ermöglicht den Einsatz leistungsfähiger KI-Assistenten bei gleichzeitiger voller Kontrolle über sensible Daten. Anstatt Informationen an externe Cloud-Anbieter zu senden, erfolgt die Verarbeitung direkt auf der eigenen Hardware im privaten Netzwerk. Dies schafft digitale Souveränität und schützt persönliche Inhalte vor dem Zugriff Dritter.
Diese Zusammenfassung wurde mit KI-Unterstützung erstellt.
Im Moment ist überall von KI-Assistenten die Rede. Von OpenAI, Anthropic und vielen anderen. Die Systeme werden immer leistungsfähiger, die Bedienung immer einfacher, und genau deshalb werden sie für immer mehr Menschen interessant. Was diese Angebote aber fast alle gemeinsam haben: Sie laufen auf fremder Infrastruktur. Wer sie nutzt, gibt Daten aus der Hand – Prompts, Dokumente, Mails, Notizen, Gesprächsverläufe. Mal offensichtlicher, mal weniger sichtbar, aber eben nie vollständig unter eigener Kontrolle.
Genau da lag für mich die Ausgangslage. Ich wollte keinen KI-Spielplatz, sondern einen Assistenten, der in meinem Alltag wirklich nützlich ist. Also nicht nur allgemeine Fragen beantworten, sondern Mails verarbeiten, Kalendereinträge lesen, Dateien analysieren, Zusammenhänge behalten und mich bei echten Abläufen unterstützen. Und genau an dem Punkt wird es heikel: Je nützlicher so ein System wird, desto tiefer schaut es in das eigene digitale Leben hinein.
Damit war für mich die Grundfrage schnell klar. Ich wollte die Vorteile moderner generativer KI nutzen, aber nicht um den Preis, zentrale Inhalte meines digitalen Alltags dauerhaft über externe Plattformen laufen zu lassen. Ein Assistent, der potenziell sehr viel über mich weiß, sollte auf Infrastruktur laufen, die ich selbst kontrolliere. Das garantiert natürlich keine absolute Sicherheit. Auch ein eigener Heimserver kann bei schlechter Absicherung selbst zum Risiko werden. Lokal bedeutet deshalb nicht automatisch sicher, sondern vor allem: mehr Kontrolle über Architektur, Zugriffe, Datenflüsse und Schutzmaßnahmen.
Die naheliegende Antwort darauf ist ein lokales LLM. In meinem Fall ist das inzwischen Gemma-4. Also kein Modell aus der Cloud, sondern ein Modell, das auf eigener Hardware im eigenen Netz läuft.
Der erste naheliegende Ansatz war ein lokales Modell auf dem Laptop. Technisch kann das sehr gut funktionieren. Gerade aktuelle MacBooks sind für lokale LLMs in mancher Hinsicht bemerkenswert gut geeignet, weil CPU, GPU und Arbeitsspeicher über eine gemeinsame Speicherarchitektur mit hoher Bandbreite zusammenarbeiten. Das ist für Inferenz-Workloads interessant, weil das Modell nicht auf einen klassischen dedizierten GPU-VRAM beschränkt ist, sondern den gemeinsam verfügbaren Speicher nutzen kann. Für viele Anwender kann ein solcher Laptop deshalb bereits völlig ausreichen.
Ich habe mich deshalb für einen Heimserver entschieden. Für meinen Anwendungsfall war nicht entscheidend, ob ein Laptop lokale LLMs grundsätzlich gut ausführen kann, sondern dass das System dauerhaft verfügbar, unabhängig von meinem Arbeitsgerät und für solche Aufgaben als eigene Infrastruktur ausgelegt ist.
Das kritischste Element war die GPU. LLM-Inferenz läuft in der Praxis vor allem über die GPU – Modellgröße, Geschwindigkeit und in gewissem Maß auch die nutzbare Qualität hängen direkt am verfügbaren VRAM. Gleichzeitig sollte die Hardware dauerhaft laufen, möglichst wenig Strom verbrauchen und im Heimbetrieb akustisch nicht stören.
Die Wahl fiel auf die NVIDIA RTX PRO 2000 Blackwell: 16 GB GDDR7-VRAM, 70 Watt TDP, maximal 0,6 Sone Geräuschentwicklung. Rein nach Preis-Leistung wäre eine RTX 3090 mit 24 GB VRAM für lokale LLMs auf dem Papier die stärkere Wahl gewesen. Für meinen Einsatzzweck war sie trotzdem keine sinnvolle Option. Ausschlaggebend waren der deutlich höhere Stromverbrauch unter Last und die Geräuschkulisse, die im dauerhaften Heimbetrieb eine wesentlich größere Rolle spielt als reine Maximalleistung. Die RTX PRO 2000 ist damit nicht die billigste und auch nicht die schnellste Lösung, aber für dieses Setup die stimmigere Entscheidung.
Mit weniger als 16 GB VRAM werden größere Modelle schnell ungemütlich. Dann muss stärker quantisiert, ausgelagert oder an anderer Stelle kompromittiert werden, als es einem lieb ist. Das kann die Ausgabequalität je nach Modell und Einsatz spürbar verschlechtern. Im Bereich von 16 GB wird lokale Inferenz für größere Modelle überhaupt erst ernsthaft interessant, auch wenn klar bleibt: Mit aktuellen Cloud-Modellen kann ein lokales Setup in einzelnen Anwendungsfällen durchaus mithalten, in Breite, Robustheit und Gesamtleistung aber noch nicht generell gleichziehen.
Das ist auch wenig überraschend. Hinter Diensten wie ChatGPT oder Claude stehen große, hochspezialisierte Rechenzentren mit massivem GPU-Einsatz. Training, Optimierung und Inferenz laufen dort auf einer technischen Basis, die mit einem einzelnen Heimserver weder wirtschaftlich noch physisch vergleichbar ist. Ein lokales LLM muss mit deutlich weniger Rechenleistung, weniger VRAM und insgesamt engeren Ressourcen arbeiten. Seine Stärke liegt deshalb heute nicht darin, Online-LLMs in jeder Disziplin zu schlagen, sondern darin, für klar definierte Anwendungsfälle genügend Qualität bei deutlich mehr Kontrolle über die eigenen Daten bereitzustellen.
Rein theoretisch könnte Ollama direkt auf dem Host laufen. Das wäre einfacher. Aber es gibt einen guten Grund dagegen: Ein System, das gleichzeitig als KI-Inferenz-Server, Mailserver, Dokumentenarchiv, Git-Server und Heimautomatisierungs-Zentrale dienen soll, braucht saubere Trennung zwischen den Diensten.
Proxmox als Hypervisor löst das: Jeder Dienst läuft in einer eigenen VM oder einem eigenen Container. Ein Speicherplatzproblem im Dokumentenarchiv betrifft den KI-Dienst nicht. Ein Container-Neustart für den Mailserver reißt die laufende Inferenz nicht mit. Snapshots reduzieren das Risiko bei Änderungen und Updates, machen sie aber natürlich weder folgenlos noch völlig risikofrei.
Der entscheidende Mechanismus für die KI-VM ist PCIe-Passthrough: Die GPU wird aus dem Proxmox-Host-Kontext herausgelöst und einer bestimmten VM direkt übergeben. Die VM sieht die GPU dann nahezu so, als wäre sie direkt eingebaut – ohne den typischen Virtualisierungs-Overhead, den man an dieser Stelle nicht haben will.
Das ist technisch aufwändiger als eine direkte Installation, aber der Betrieb danach ist sauberer getrennt und in der Praxis deutlich kontrollierbarer.
Anfangs war das System so aufgebaut, dass ein schnelles 4b-Modell dauerhaft im VRAM lag und für einfache Anfragen sofort verfügbar war. Je nach Nutzung wurde dieses Modell entladen, um stattdessen ein 9b-Modell als Standard oder ein 27b-Modell für anspruchsvollere Aufgaben in den VRAM zu laden. Alle drei Modelle passten nicht gleichzeitig in den verfügbaren Speicher, und gerade das 27b-Modell war überhaupt nur in quantisierter Form praktikabel. Das Profilsystem von Algroveon-Agent basierte genau auf dieser Logik: nicht mehrere Modelle parallel im VRAM, sondern ein gezieltes Umschalten je nach Aufgabe.
Mit dem Wechsel auf Gemma-4 als lokales LLM hat sich das geändert. Gemma-4 ist ein Mixture-of-Experts-Modell: Es hat 26 Milliarden Parameter, aktiviert bei jedem Schritt aber nur einen Teil davon. Das sorgt gegenüber einem dichten Modell ähnlicher Größenordnung für effizientere Inferenz, ohne dass die Ausgabequalität im Alltag sofort sichtbar einbricht.
Das Problem: Das Modell passte in meiner Konfiguration zunächst nicht vollständig in 16 GB VRAM. Drei Maßnahmen haben das gelöst:
Maßnahme 1 – Vision-Projector weglassen. Gemma-4 ist multimodal und kann auch Bilder verarbeiten. Dafür wird ein zusätzlicher Vision-Anteil benötigt, der VRAM belegt. Algroveon-Agent verarbeitet in meinem Setup aber keine Bilder direkt; PDFs werden als Text extrahiert. Dieser Teil war also überflüssig. Ein angepasstes Modelfile ohne diesen Anteil spart den entsprechenden Speicher konsequent ein.
Maßnahme 2 – Whisper auf Quantisierung umstellen. In meiner Konfiguration lief neben dem eigentlichen LLM auch Faster-Whisper für die Sprachverarbeitung. Dieser Teil belegte ebenfalls VRAM und musste deshalb in die Gesamtrechnung einbezogen werden. Ursprünglich lief Faster-Whisper mit float16-Gewichten. Der Wechsel auf int8_float16 reduzierte den VRAM-Bedarf deutlich, ohne dass im praktischen Einsatz ein relevanter Qualitätsverlust spürbar war. Die Latenz steigt dabei nur leicht, was in meinem Fall kaum ins Gewicht fällt, weil die TTS-Ausgabe ohnehin den größeren Zeitanteil bestimmt.
Maßnahme 3 – Context-Window reduzieren. Der KV-Cache, der den Gesprächskontext im VRAM hält, wächst mit der Context-Länge. Bei 8192 Token fehlte in meiner Konfiguration genau der kleine Rest, der für eine vollständige GPU-Allokation nötig gewesen wäre – ein Teil der Modell-Layer lief dadurch auf der CPU. Bei 4096 Token passten alle Layer vollständig in den VRAM. In der Praxis war das für mich vertretbar, weil Algroveon-Agent ein eigenes Gedächtnissystem nutzt, das Gesprächsinhalte über einzelne Sitzungen hinaus speichern kann. Die reine Context-Window-Größe ist in so einem Aufbau deshalb weniger entscheidend als bei einem Modell ohne externes Memory-System.
Der Server ist heute der Infrastrukturkern für alles, was bei mir unter algroveon läuft:
Kein einziger dieser Schritte muss dafür über externe KI-Dienste laufen. Genau das ist der eigentliche Punkt.
Der oft gehörte Einwand gegen lokale LLMs war bis vor Kurzem berechtigt: Lokale Modelle waren im Alltag meist deutlich schwächer als Cloud-Modelle. So pauschal stimmt das heute nicht mehr. Ein quantisiertes Gemma-4 auf aktueller Hardware kann für viele Aufgaben im täglichen Einsatz oder als persönlicher Assistent bereits erstaunlich brauchbare Ergebnisse liefern.
Aber das heißt nicht, dass lokale LLMs heute automatisch ein Selbstläufer sind. Mit den aktuellen Tools lässt sich ein lokales Modell auf einem Mac oder einem anderen geeigneten System zwar vergleichsweise schnell in Betrieb nehmen, auch ohne tiefen technischen Hintergrund. Spätestens wenn es aber über die reine Installation hinausgeht, werden die Grenzen schnell deutlich. Ohne Vorwissen ist kaum einschätzbar, welche Modelle sich für welche Aufgaben wirklich eignen, wo Quantisierung sinnvoll ist, wie Speichergrenzen zu bewerten sind oder welche Kompromisse zwischen Geschwindigkeit, Qualität und Ressourcenverbrauch sinnvoll sind.
Noch anspruchsvoller wird es, wenn daraus nicht nur ein gestartetes Modell, sondern ein echter Assistent werden soll. Ein solcher Aufbau ist konzeptionell, technisch und organisatorisch deutlich komplexer, als es auf den ersten Blick wirkt. Für Bequemlichkeit zahlt man am Ende fast immer einen Preis. Im Cloud-Fall sind das sehr oft die eigenen Daten.
algroveonbook ist ein selbst gehostetes System, in dem Algroveon-Agent eigenständig schreibt, Gedanken entwickelt und über Zeit ein persistentes Außengedächtnis aufbaut. Ein Entwicklertagebuch über autonome Kognition ohne 'AI Theater'.
Ein LLM erinnert sich an nichts – jede Session beginnt bei null. Dieser Beitrag erklärt, wie Algroveon-Agent dieses Problem mit einem vierlagigen Gedächtnis-System und einem mehrstufigen Agentic Loop löst.