Ich betreibe seit einiger Zeit ein privates ChatGPT‑ähnliches Modul auf einem Raspberry Pi — vollständig lokal, ohne Cloud‑Zugriff. In diesem Artikel schildere ich meine praktische Vorgehensweise, welche Hardware und Software sich bewährt haben, wie ich Modelle deploye und welche Sicherheits‑ und Datenschutzmaßnahmen ich umgesetzt habe. Mein Anspruch: nachvollziehbar, praktisch und so einfach wie möglich nachzubauen.

Warum lokal auf einem Raspberry Pi?

Für mich war der Antrieb zweierlei: erstens der Wunsch nach voller Datenkontrolle — keine Texte verlassen mein Heimnetz — und zweitens die Herausforderung, ein performantes System auf günstiger, energieeffizienter Hardware zu betreiben. Ein Raspberry Pi (insbesondere Pi 4 mit 8 GB oder Pi 5) bietet ein gutes Kosten‑/Leistungs‑Verhältnis für private Anwendungen wie einen lokalen Chat‑Assistenten für Notizen, Skripte oder persönliche Wissensdatenbanken.

Welche Hardware brauchst du?

Meine Empfehlung:

  • Raspberry Pi 5 oder Raspberry Pi 4 Modell B mit 8 GB RAM (Pi 5 bringt merklich bessere CPU‑Leistung).
  • Schnelle microSD (oder besser: NVMe/SSD über USB 3.0 für Lese/Schreib‑Performance).
  • Optional: USB‑Beschleuniger wie Google Coral USB‑TPU oder ein Neural‑Network‑Accelerator (abhängig von Modellunterstützung).
  • Gehäuse mit Kühlung (aktive Kühlung ist bei Dauerlast sinnvoll).

Ich betreibe meine Installation auf einer externen NVMe‑SSD via USB‑3.0, weil Modelle und Swap deutlich Speicherplatz und IO benötigen.

Modellauswahl: welches LLM läuft lokal?

Wichtig ist: die echten "GPT"‑Modelle von OpenAI laufen nicht offline. Stattdessen nutze ich freie bzw. lokal ausführbare Modelle wie LLaMA‑Derivate (ggml‑kompatibel), Mistral‑Mini, Vicuna oder kleinere BLOOM‑Abkömmlinge. Für Raspberry Pi greife ich auf stark quantisierte Modelle (4‑bit, 8‑bit) zurück — das macht den Unterschied zwischen funktionalem Chatbot und unbrauchbarem Ruckeln.

Tools und Projekte, die ich nutze oder getestet habe:

  • llama.cpp – kompiliert effizient für ARM und unterstützt quantisierte GGML‑Modelle.
  • text-generation-webui – komfortable Web‑UI, Plug‑ins, unterstützt llama.cpp Backend.
  • ggml und quantisierte Modell‑Weights (z. B. ggml‑q8_0)\, — wichtig, um Speicherbedarf zu senken.
  • Bei Nutzung von Coral/TPU: entsprechende Edge‑optimierte Modelle (aber die Auswahl ist limitiert).

Vorbereitung des Systems

Meine Basis ist Raspberry Pi OS (64‑bit) oder eine minimal Debian/Ubuntu‑Variante. Wesentliche Schritte:

  • System updaten: sudo apt update && sudo apt upgrade
  • Wesentliche Pakete installieren: build‑tools, python3, pip, git, libopenmpi, cmake, etc.
  • Swap oder zram konfigurieren, falls RAM knapp ist (ich nutze eine kleine zram‑Swap Kombination).
  • SSD einbinden und als primäres Datenlaufwerk nutzen für Modelle und Logs.

llama.cpp & text-generation-webui: wie ich es aufsetze

Kurz meine Schritte (vereinfacht):

  • Repository klonen: git clone https://github.com/ggerganov/llama.cpp.git und kompilieren (make mit ARM Unterstützung).
  • text-generation-webui klonen: git clone https://github.com/oobabooga/text-generation-webui.git
  • In webui die Option wählen, llama.cpp als Backend zu nutzen — so läuft die Inferenz CPU‑gerecht.
  • Modelle in ggml‑Format ablegen (ggml quantisierte Gewichte). Ich konvertiere und teste verschiedene Quantisierungen (q4_0, q8_0) und messe Antwortzeit vs. Qualität.

Beispiel für lokale Start‑Kommandos (abhängig vom Setup):

  • python server.py --model /pfad/zum/ggml‑model.bin --api --listen

Die Web‑UI läuft dann im lokalen Netzwerk, meist auf Port 7860 oder konfigurierbar über systemd‑Service.

Performance‑Optimierung

Ein paar Praktiken, die bei mir geholfen haben:

  • Modelle quantisieren: 4‑bit/8‑bit reduziert RAM massiv.
  • Kontextlänge reduzieren — je länger der Kontext, desto mehr Arbeitsspeicher und CPU.
  • Batching und Token‑Sampling anpassen (top‑k/top‑p) um CPU‑Last zu drosseln.
  • Swap laut Bedarf, aber nicht zu groß — SSD‑Swap verkürzt Lebensdauer der NVMe, zram ist oft besser.

Sicherheit & Datenschutz: meine Prinzipien

Da das System vollständig lokal läuft, ist ein großer Teil des Datenschutzes bereits abgedeckt. Trotzdem beachte ich folgende Punkte strikt:

  • Kein Internet für den Dienst: Ich verhindere ausgehende Verbindungen des Chat‑Processes via iptables oder ufw (z. B. Blockieren aller Ports außer lokal).
  • Zugriffsbeschränkung: UI/API nur im lokalen Netzwerk verfügbar oder über VPN — niemals offen ins Internet.
  • Authentifizierung: Falls ich Zugang aus dem WLAN benötige, nutze ich Basic Auth oder besser ein Reverse‑Proxy (NGINX) mit HTTPS und Client‑Zertifikaten.
  • Least Privilege: Der Chat‑Service läuft unter einem eigenen Nutzeraccount, ohne sudo‑Rechte, auf schreibgeschützte Datenorte außer Logs.
  • Logging und Retention: Ich protokolliere nur das Nötigste und lösche Konversationen automatisiert nach definierter Frist (z. B. 30 Tage).
  • Updates: Sicherheitsupdates werden regelmäßig eingespielt; kritische Komponenten wie OpenSSH, NGINX und systemd sind aktuell.

Netzwerk‑Setup und Zugriff

Mein Setup ist streng segmentiert:

  • IoT/Gäste‑LAN getrennt vom vertrauenswürdigen Heimnetz.
  • Der Pi steht im vertrauenswürdigen LAN, Web‑UI ist nur per VPN erreichbar, falls ich außerhalb zugreifen will.
  • Optional: Tor Hidden Service oder SSH‑Tunnel für entfernten Zugriff — nur mit starken Keys und 2FA auf dem Client.

Backup, Monitoring und Wiederherstellung

Fehler passieren. Deshalb habe ich eingerichtet:

  • Regelmäßige Backups der Modellgewichte (externe HDD oder verschlüsselte Cloud‑Snapshots — nur falls man es zulässt).
  • Monitoring via Prometheus/Node‑Exporter oder einfache Cron‑Jobs, die Verfügbarkeit und CPU/Temperatur prüfen.
  • Recovery‑Plan: Bei Korruption stelle ich die letzte funktionierende SSD‑Image wieder her (Disk‑Image mit dd oder Raspberry Pi Imager).

Praktische Tipps für den Alltag

  • Teste verschiedene Modelle und Quantisierungen — für meine Bedürfnisse war ein 4‑bit LLaMA‑Derivat mit angepasstem Prompt‑Engineering oft besser als ein schlecht quantisiertes großes Modell.
  • Prompt‑Speicher/Templating: Lege häufig genutzte Systemprompts als Vorlagen ab, um konsistente Antworten zu erhalten.
  • Verbinde lokale Knowledge‑Bases (Markdown‑Dateien, Obsidian‑Vault, SQLite) über Retrieval‑Augmented‑Generation (RAG), damit Antworten kontextsensitiver sind.
  • Wenn du Sprach‑TTS möchtest: Lokale TTS‑Engines wie espeak-ng oder Coqui TTS können auf dem Pi mit moderater Qualität laufen.

Was du vermeiden solltest

  • Modelle ohne Quantisierung auf einem Pi laufen lassen — das wird nicht funktionieren.
  • Den Dienst offen ins Internet stellen ohne Authentifizierung oder Rate‑Limiting.
  • Sensitive Daten in Logs schreiben oder unbegrenzt speichern.

Wenn du magst, kann ich dir ein kurzes, konkretes Setup‑Skript schreiben (Installation von llama.cpp + text‑generation‑webui, Firewall‑Regeln, systemd‑Service). Sag mir nur, ob du Pi 4 oder Pi 5 nutzt und ob du eine SSD oder microSD bevorzugst — dann passe ich die Befehle entsprechend an.