Warum ich meine KI lokal betreibe — und was das wirklich bedeutet

Es gibt zwei ehrliche Gründe warum ich einen dedizierten Raspberry Pi 4 in meinem Heimnetzwerk betreibe, auf dem rund um die Uhr ein lokales Sprachmodell läuft. Der erste ist Datenschutz und digitale Souveränität — eine Überzeugung, keine Paranoia. Der zweite ist purer Spieltrieb: Ein kleiner Rechner auf dem ein Sprachmodell läuft hat etwas Magisches, und ich bin seit jeher jemand der verstehen möchte, wie Dinge funktionieren — von innen. Denn Theorie ist wichtig, aber die praktische Erfahrung kann durch nichts ersetzt werden.

Die Reise dahin war eine echte Experimentierphase: angefangen auf dem MacBook Air M2 wo Apple Silicon zeigt was lokale Inferenz leisten kann, weiter zum Raspberry Pi 5 (16GB) als erstem dediziertem ARM-Server, dann zum Pi 4 mit 4GB RAM als pragmatischer Zwischenlösung — und schließlich zum aktuellen Setup: ein Pi 4 mit 8GB RAM, ausschließlich für Ollama reserviert. Jede Stufe hat etwas gelehrt — und erst durch die eigene Erfahrung weiß man wirklich warum.

Dieser Artikel ist kein Tutorial für den perfekten lokalen KI-Stack. Es ist ein ehrlicher Erfahrungsbericht mit allem was dazugehört: Motivation, Setup, Möglichkeiten, Grenzen und eine klare Einschätzung wann Cloud-KI — wie Claude — trotzdem die bessere Wahl ist.

Motivation: Datenschutz trifft Spieltrieb

Der Datenschutz-Aspekt

Wenn ich Claude, ChatGPT oder ein anderes Cloud-basiertes KI-Tool nutze, verlassen meine Prompts mein Netzwerk. Das ist keine Spekulation — es ist die technische Realität jedes API-Calls. Was mit diesen Daten passiert, hängt von den Nutzungsbedingungen, dem Tarif, und dem Vertrauen in den Anbieter ab.

Das ist kein Argument gegen Cloud-KI. Es ist ein Argument für einen bewussten und gezielten Umgang damit. Nicht jeder Prompt ist gleich sensibel. Ein allgemeines technisches Konzept zu erklären ist etwas anderes als interne Projektdokumentation zu verarbeiten, proprietären Code zu analysieren, oder persönliche Notizen zusammenzufassen.

Die Frage, die ich mir stelle, ist nicht: "Ist dieser Anbieter vertrauenswürdig?" Sondern: "Welche Daten möchte ich grundsätzlich das Haus verlassen lassen — und welche nicht?"

Für die zweite Kategorie ist lokale KI die Antwort. Nicht weil Cloud-Anbieter böswillig sind, sondern weil Datensouveränität bedeutet, diese Entscheidung selbst zu treffen.

Die regulatorischen Hintergründe — DSGVO, EU AI Act, Cyber Resilience Act — und ihre Implikationen für den KI-Einsatz beleuchte ich ausführlich in einem eigenen Artikel. Coming soon.

Der Spieltrieb-Aspekt

Ein lokales Sprachmodell zum Laufen zu bringen, ist technisch interessant. Es geht darum zu verstehen wie Quantisierung funktioniert, warum RAM die entscheidende Ressource auf CPU-only-Hardware ist, welche Modellarchitekturen effizient sind und welche nicht. Es ist das gleiche Gefühl das mich dazu gebracht hat, einen Raspberry Pi als Gitea-Server, einen zweiten als Ghost-Instanz, und mein eigenes CI/CD mit Gitea Actions aufzubauen.

Self-hosting ist für mich kein Mittel zum Zweck. Es ist eine Haltung.

Das Setup: Raspberry Pi 4 als lokale KI-Zentrale

Hardware

Mein KI-Server ist ein Raspberry Pi 4 mit 8GB RAM, der headless im Heimnetzwerk läuft — dediziert für Ollama, nichts anderes. Kein Bildschirm, kein Keyboard — nur SSH-Zugriff über das lokale Netzwerk.

Die Rollenverteilung im Homelab hat sich dabei klar herauskristallisiert: Der Pi 5 (16GB) läuft als NAS und Gitea-Server, der Pi 4-1 (4GB) kümmert sich um Ghost, Nginx und OpenWebUI als Webservice-Layer, und der Pi 4-2 (8GB) ist ausschließlich für Ollama reserviert. Klare Trennung der Verantwortlichkeiten — kein Mischen von Web und KI auf demselben Gerät.

Eine wichtige Einschätzung vorab: Ich habe das Setup ursprünglich auf einem Raspberry Pi 5 mit 16GB RAM gestartet — und der Unterschied in Performance und Modellauswahl ist erheblich. Vor dem Pi 5 habe ich auch auf einem MacBook Air M2 mit 24GB RAM experimentiert, was nochmal eine eigene Liga ist: Apple Silicon mit Unified Memory ist für lokale LLM-Inferenz ausgezeichnet geeignet.

Wer neu einsteigt und die Wahl hat, dem empfehle ich daher klar: Raspberry Pi 5 mit 8GB oder 16GB RAM als dedizierter Server — oder Apple Silicon wenn ohnehin ein Mac vorhanden ist.

Technische Mindestanforderungen für lokale LLM-Inferenz mit Ollama:

Quellen: serverman.co.uk, toolhalla.ai, mljourney.com — CPU-only Inferenz, Q4-Quantisierung. Werte können je nach Modell und Prompt variieren.

Software: Ollama

Ollama ist das Werkzeug der Wahl für lokale LLM-Inferenz auf ARM-Hardware. Die Installation ist einzeilig — die vollständige Anleitung gibt es unter ollama.com:

curl -fsSL https://ollama.com/install.sh | sh

Ollama kümmert sich automatisch um Model-Download, Quantisierung und Serving über eine lokale API (Standard: Port 11434). Es läuft als systemd-Service und startet automatisch beim Booten.

Modellauswahl für den Pi 4 (8GB)

Die Modellwahl auf einem Pi 4 mit 8GB RAM ist deutlich komfortabler als auf einem 4GB-Modell — mehr RAM bedeutet mehr Spielraum bei der Modellgröße und keine Swap-Nutzung mehr. Hier sind die Modelle die ich getestet habe und ehrlich bewerte:

Quellen: serverman.co.uk, toolhalla.ai, eigene Tests. Q4_K_M Quantisierung, CPU-only.

phi3:mini von Microsoft profitiert auf dem 8GB-Modell deutlich: kein Swap, stabiler Betrieb, und die Qualität kommt voll zur Geltung. Das war auf dem 4GB-Modell noch ein Balanceakt.

gemma2:2b von Google bleibt die pragmatische Wahl wenn Geschwindigkeit wichtiger ist als maximale Qualität — für Batch-Aufgaben und einfache Klassifizierungen ideal.

Meine ehrliche Empfehlung: Der Pi 4 mit 8GB ist ein solider dedizierter KI-Server für den Heimbereich — wenn er wirklich nur für Ollama reserviert ist. Der Schlüssel ist die Rollentrennung: kein Mischen mit anderen Diensten.

Das Netzwerk: Vollständige Abschottung möglich

Einer der überzeugendsten Aspekte lokaler KI ist die Kontrolle über den Netzwerkzugriff. Mein Pi 4 läuft in einem dedizierten VLAN im Heimnetzwerk, verwaltet über einen UniFi UCG Max.

Wie die Abschottung funktioniert

Der Pi kann vollständig vom Internet isoliert werden, ohne seine Funktionalität für lokale Anfragen zu verlieren. Das UniFi Policy Engine ermöglicht:

graph TD
    A[MacBook / lokale Clients] -->|Port 11434| B[Raspberry Pi 4\nOllama]
    B -->|Kein ausgehender Traffic| C[🚫 Internet]
    D[UniFi UCG Max] -->|Firewall-Regel: Block WAN| B
    D -->|Traffic-Monitoring| E[Dashboard]
    B -->|Lokales VLAN| A

Die konkrete Konfiguration im UniFi Controller:

1. Dediziertes VLAN für den Pi anlegen (z.B. VLAN 20 "AI-Local")

2. Firewall-Regel im Policy Engine:
- Quelle: IP des Pi (statische IP empfohlen)
- Ziel: WAN / Internet
- Aktion: Blockieren
- Richtung: Ausgehend

3. Traffic-Monitoring über das UniFi Dashboard gibt vollständige Sichtbarkeit: jeder Verbindungsversuch nach außen wird protokolliert und — dank der Firewall-Regel — blockiert.

Das Ergebnis: Der Pi beantwortet lokale API-Anfragen von meinem MacBook, meinem Homelab, oder anderen lokalen Diensten — aber kein einziges Paket verlässt das Heimnetzwerk. Was auf dem Pi verarbeitet wird, bleibt auf dem Pi.

Quellen: Ubiquiti Help Center, help.ui.com — Traffic & Policy Management in UniFi

Warum das wichtig ist

Einem lokalen Modell ist es auf diese Weise technisch unmöglich, nach Hause zu telefonieren. Das ist ein grundlegend anderes Sicherheitsmodell als "wir vertrauen darauf, dass der Anbieter die Daten nicht weitergibt."

Es ist kein Misstrauen gegenüber bestimmten Anbietern. Es ist das Prinzip: Kontrolle durch Architektur statt durch Vertrauen.

Ein interessanter Nebeneffekt: Durch das Traffic-Monitoring lernt man sehr schnell, wie unterschiedlich sich lokale Modelle verhalten. Manche versuchen beim Start, Modell-Updates oder Telemetrie-Daten abzurufen — und man sieht es sofort im Dashboard. Das schärft das Verständnis dafür, was im Hintergrund wirklich passiert.

Was wirklich geht: Möglichkeiten lokaler LLMs

Lokale Modelle auf einem Pi 4 sind kein Ersatz für Claude oder GPT-4. Aber für bestimmte Anwendungsfälle sind sie genau das richtige Werkzeug:

Verarbeitung sensibler Dokumente
Interne Projektnotizen, persönliche Tagebucheinträge, proprietärer Code — alles was das Haus nicht verlassen soll, aber trotzdem von einem Sprachmodell verarbeitet werden kann. Das Modell sieht die Daten, aber nur lokal.

Lokale Automatisierungen und Scripts
Bash-Skripte die Text verarbeiten, einfache Klassifizierungsaufgaben, Zusammenfassungen von lokalen Logfiles — für diese Aufgaben braucht man keine Internetverbindung und kein großes Modell.

Heimautomatisierung und IoT
Sensor-Daten lokal mit einem LLM verarbeiten, Anomalieerkennung, natürlichsprachige Steuerung von Smart-Home-Geräten — alles ohne Cloud-Abhängigkeit.

Experimentieren und Lernen
Verstehen wie Quantisierung funktioniert, wie sich verschiedene Modellarchitekturen verhalten, wie man eine lokale RAG-Pipeline aufbaut — der Pi ist ein ausgezeichnetes Experimentierfeld.

Offline-Assistent für einfache Aufgaben
Texte umformulieren, kurze Zusammenfassungen, einfache Fragen beantworten — funktioniert auch ohne Internetverbindung.

Was nicht geht: Die ehrlichen Grenzen

Hier ist Ehrlichkeit angebracht. Ein Pi 4 mit lokalen 2B–4B Modellen ist kein Claude-Ersatz — und das sollte er auch nicht sein.

Performance
Ein Raspberry Pi 4 mit 8GB RAM erreicht bei 3B-Modellen etwa 1–2 Tokens pro Sekunde — deutlich komfortabler als mit 4GB, wo Swap-Nutzung die Performance zusätzlich drückt. Eine kurze Antwort von 100 Wörtern dauert dennoch 30–60 Sekunden. Für interaktiven Chat ist das unbefriedigend. Für Batch-Aufgaben im Hintergrund ist es akzeptabel.

Reasoning und Komplexität
Kleine Modelle (1B–4B Parameter) stoßen bei komplexen mehrstufigen Aufgaben schnell an ihre Grenzen. Code-Debugging, komplexe Analysen, kreatives Schreiben — hier ist der Qualitätsunterschied zu Claude oder GPT-4 erheblich und spürbar.

Kontextfenster
Kleine Modelle haben oft begrenzte Kontextfenster. Lange Dokumente müssen aufgeteilt werden, was den Workflow verkompliziert.

Modellgröße
Auf einem Pi 4 mit 8GB sind Modelle über 7B Parameter nicht realistisch betreibbar. Die aktuell stärksten Modelle (Claude, GPT-4o, Gemini Ultra) haben Dutzende bis Hunderte Milliarden Parameter — das ist auf dieser Hardware schlicht nicht möglich.

Multimodalität
Bildverarbeitung, Audio-Transkription, und andere multimodale Aufgaben sind auf dem Pi mit Ollama nicht ohne weiteres verfügbar.

Lokal vs. Cloud: Was wofür?

Das ist keine Entweder-Oder-Frage. Ich nutze beides — bewusst und je nach Aufgabe:

Meine persönliche Entscheidungsregel:

Lokal, wenn die Daten das Haus nicht verlassen sollen, wenn die Aufgabe einfach genug für ein kleines Modell ist, oder wenn ich experimentieren möchte.

Cloud (Claude), wenn ich maximale Qualität brauche, wenn die Aufgabe komplex ist, wenn Geschwindigkeit wichtig ist, oder wenn die Daten nicht sensibel sind.

Das ist keine Schwäche des lokalen Ansatzes. Es ist ein durchdachtes hybrides Modell — das Beste aus beiden Welten, bewusst eingesetzt.

Regulatorik als Rückenwind

Die regulatorische Entwicklung in der EU stärkt das Argument für lokale KI in bestimmten Kontexten — insbesondere für Unternehmen und Entwickler die mit sensiblen Daten arbeiten.

Die DSGVO stellt klare Anforderungen an die Verarbeitung personenbezogener Daten. Der EU AI Act definiert Risikokategorien und Transparenzpflichten. Der Cyber Resilience Act schreibt Security by Design vor. Lokale KI-Infrastruktur vereinfacht die Compliance in vielen dieser Bereiche erheblich — weil die Daten schlicht nie das eigene System verlassen.

Die regulatorischen Details — Zeitpläne, Bußgeldrahmen, konkrete Anforderungen — beleuchte ich ausführlich in einem eigenen Artikel. Coming soon.

Fazit: Souveränität ist keine Frage der Paranoia

Wer seine KI lokal betreibt, trifft eine bewusste Entscheidung. Nicht aus Misstrauen, nicht aus Paranoia — sondern weil Datensouveränität bedeutet, selbst zu entscheiden welche Daten welche Systeme berühren.

Ein dedizierter Raspberry Pi 4 mit 8GB RAM und Ollama ist kein perfektes System. Er ist langsam, in der Modellwahl eingeschränkt, und kein Ersatz für die Qualität großer Cloud-Modelle. Aber er ist meiner. Vollständig unter meiner Kontrolle, vollständig vom Internet abschottbar, vollständig transparent in dem was er tut.

Und manchmal ist genau das das Richtige — nicht das Schnellste, nicht das Leistungsstärkste, sondern das Kontrollierbare.

Der Spieltrieb hat dabei auch seinen Platz. Zu verstehen wie ein Sprachmodell auf einem ARM-Prozessor mit 4 Watt Verbrauch Texte generiert, ist faszinierend. Und wer einmal ein Modell lokal zum Laufen gebracht hat, versteht die Technologie auf eine Art die kein API-Call jemals vermitteln kann.

Alle Performance-Angaben basieren auf öffentlich verfügbaren Benchmarks und eigenen Tests. Stand: Juni 2026. Hardwarepreise und Modellverfügbarkeit können sich ändern.

Dieser Artikel gibt ausschließlich meine persönliche Meinung wieder und steht in keinem Zusammenhang mit beruflichen Tätigkeiten.