Private KI lokal betreiben: Ollama, Open WebUI und WireGuard

Wenn die Cloud-Rechnungen für KI-Modelle langsam dein monatliches Budget sprengen oder du einfach nicht willst, dass deine privaten Prompts über US-Server wandern, ist es Zeit, das Thema lokal anzugehen.

Dies ist einer von vielen Wegen, eine private KI-Infrastruktur aufzubauen – mein Weg, weil ich damit die wenigsten Probleme mit Abhängigkeiten und Netzwerk-Instabilität hatte. Wir bauen uns einen Stack aus Ollama (Backend), Open WebUI (Frontend) und sichern das Ganze via WireGuard ab.

1. Das Backend: Ollama installieren

Ollama ist der Motor. Es abstrahiert die ganze Komplexität der Modell-Inferenz. Das Beste daran: Es erkennt meistens von selbst, ob du eine NVIDIA-GPU, Apple Silicon oder nur eine CPU hast.

Windows & macOS

Hier gibt es kein langes Gefummel.

Geht auf ollama.com/download.
Installiert das Paket wie gewohnt.
Sobald der Dienst im Tray läuft, ist die Basis gelegt.

Linux & die ASUS Ascent GX10 (ARM-Powerhouse)

Hier wird es interessant, denn die GX10 ist kein normaler Linux-Rechner, den ihr erst von Null aufsetzt. Das Gerät kommt mit NVIDIAs DGX OS vorinstalliert – einer angepassten Ubuntu-Variante (aktuell DGX OS 7, basiert auf Ubuntu 24.04) für die aarch64-Architektur der Grace-CPU. Heißt: Das nervigste am ganzen GPU-Geraffel ist euch schon abgenommen. Der NVIDIA-Treiber und das CUDA-Toolkit (Version 13) sind ab Werk drauf und korrekt konfiguriert. Kein Treiber-Roulette, kein „CUDA findet die GPU nicht“.

Beim ersten Start läuft eine ganz normale Ubuntu-Einrichtung durch: Benutzer anlegen, Netzwerk verbinden, fertig. Danach prüft ihr einmal, ob der GPU-Stack wirklich da ist und zieht das System aktuell:

# Zeigt GB10, Treiberversion (580.x) und CUDA-Version an
nvidia-smi
# System einmal aktuell ziehen
sudo apt update && sudo apt full-upgrade -y

Wenn nvidia-smi euch die GB10 mit Treiber 580.x und CUDA 13 ausspuckt, ist alles parat. Jetzt – und erst jetzt – kommt Ollama dazu. Wir nutzen das offizielle Shell-Skript, weil es die aarch64-Architektur sauber erkennt und den systemd-Service korrekt einbindet:

# Installation via offizielles Shell-Script
curl -fsSL https://ollama.com/install.sh | sh
# Checkt, ob das Binary im Pfad ist
ollama --version
# Smoke-Test mit einem kleinen Modell
ollama run llama3

Weil CUDA schon sauber installiert ist, erkennt Ollama die Blackwell-GPU automatisch und schiebt die Inferenz dort drauf – ihr müsst nichts weiter konfigurieren. Ob ein Modell wirklich auf der GPU läuft, seht ihr während einer laufenden Anfrage mit ollama ps (die Spalte „PROCESSOR“ sollte GPU zeigen, nicht CPU).

Ein Hinweis am Rande: DGX OS ist auf der GX10 das einzige offiziell getestete Betriebssystem. Ihr könntet zwar ein nacktes Ubuntu 24.04 nehmen und den DGX-Software-Stack nachinstallieren, aber ehrlich – warum solltet ihr euch das antun, wenn das passende System schon drauf ist? Das Skript und die ganze Inferenz laufen auf dem vorinstallierten DGX OS einfach ohne Mucken.

2. Das Interface: Open WebUI

Ollama alleine ist nur eine CLI (Command Line Interface). Um ein Erlebnis wie ChatGPT zu haben, brauchen wir Open WebUI. Hier gibt es zwei Wege – den schnellen zum Antesten und den sauberen für den Dauerbetrieb.

Der schnelle Weg: das Skript

Genau wie bei Ollama gibt es auch für Open WebUI eine Ein-Befehl-Installation. Es ist ein Python-Paket, das ihr direkt per pip zieht:

# Python 3.11 vorausgesetzt
pip install open-webui
# Starten
open-webui serve

Danach läuft das Interface unter http://localhost:8080. Wer uv nutzt, kommt mit uvx --python 3.11 open-webui@latest serve sogar ohne feste Installation aus. Perfekt zum schnellen Ausprobieren.

Der Haken: Das Python-Paket zieht dir je nach System ein ganzes Rudel Abhängigkeiten rein – und genau das wollten wir ja eigentlich vermeiden. Zum Antesten top, für den Dauerbetrieb nehme ich trotzdem Docker.

Der saubere Weg: Docker

Ich empfehle dringend, das produktiv über Docker zu lösen. Warum? Weil ihr euch sonst in einem unübersichtlichen Geflecht aus Python-Versionen und Abhängigkeiten verliert.

Erstellt eine docker-compose.yaml:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    restart: always
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    environment:
      # Hier die IP eures Ollama-Servers eintragen! (Wichtig!)
      - OLLAMA_BASE_URL=http://192.168.1.50:11434
    extra_hosts:
      - "host.docker.internal:host-gateway"
volumes:
  open-webui:

Deployment:

# Container im Hintergrund starten
docker compose up -d

Danach erreicht ihr das Interface unter http://<DEINE_IP>:3000.

Wichtig: Achtet bei OLLAMA_BASE_URL darauf, dass ihr die echte IP des Hosts (oder der GX10) nutzt und nicht localhost – der Docker-Container betrachtet sich selbst als localhost und findet Ollama dort nicht.

3. Remote Access: Sicher von überall zugreifen

Wir öffnen keine Ports in eurem Router. Wer sein WebUI direkt ins Netz stellt, lädt förmlich dazu ein, gehackt zu werden. Wir nutzen stattdessen WireGuard – aber statt daheim einen Port aufzumachen und mit DynDNS zu basteln, mieten wir uns den Treffpunkt in der Cloud.

Das Konzept: ein WireGuard-Server bei Hetzner

Die Idee: Eine kleine VM bei Hetzner für ein paar Euro im Monat (eine CX22 oder eine ARM-CAX11 reicht locker) bekommt eine feste öffentliche IP und spielt den zentralen Treffpunkt. Sowohl euer Heim-Server mit Ollama als auch euer Laptop oder Handy wählen sich in diesen WireGuard-Server ein. Alle treffen sich im selben VPN, und niemand muss daheim einen Port öffnen. Das Schöne daran: Es funktioniert sogar hinter CGNAT, wo ihr sonst gar keine Chance auf eingehende Verbindungen hättet.

Die Topologie sieht so aus:

Hetzner-VM = WireGuard-Server, bekommt 10.0.0.1
Heim-Server (Ollama + Open WebUI) = Peer, bekommt 10.0.0.50
Laptop / Handy = Peer, bekommt 10.0.0.2

Schritt 1: Den Server auf Hetzner aufsetzen

VM bestellen (Ubuntu 24.04), per SSH drauf und WireGuard installieren:

apt update && apt install -y wireguard
# Schlüsselpaar für den Server erzeugen
wg genkey | tee server_private.key | wg pubkey > server_public.key

IP-Forwarding aktivieren, damit der Server die Pakete zwischen den Peers weiterreicht:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

Dann die /etc/wireguard/wg0.conf auf dem Server anlegen:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
# NAT + Forwarding (eth0 ggf. anpassen, prüfen mit: ip a)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Laptop / Handy
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.0.0.2/32

[Peer]
# Heim-Server mit Ollama
PublicKey = <HOME_PUBLIC_KEY>
AllowedIPs = 10.0.0.50/32

Im Hetzner-Cloud-Panel (oder per ufw) den Port UDP 51820 freigeben, sonst kommt keiner rein. Dann den Tunnel starten und für den Autostart aktivieren:

systemctl enable --now wg-quick@wg0
# Status checken
wg show

Schritt 2: Den Heim-Server einhängen

Euer Heim-Server (der mit Ollama und Open WebUI) ist auch nur ein Peer. Auf ihm legt ihr ebenfalls eine wg0.conf an, die zur Hetzner-IP zeigt. Wichtig ist hier PersistentKeepalive, damit der Tunnel von daheim aus offen bleibt – sonst macht eure Fritzbox den nach kurzer Ruhe dicht:

[Interface]
Address = 10.0.0.50/32
PrivateKey = <HOME_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <HETZNER_PUBLIC_IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

Sobald der läuft, ist euer Open WebUI im VPN unter http://10.0.0.50:3000 erreichbar – von jedem Gerät, das ebenfalls eingewählt ist.

Schritt 3: Den Client installieren

Jetzt fehlt nur noch das Gerät, mit dem ihr unterwegs zugreift. WireGuard gibt es für alles:

Windows & macOS: Den offiziellen Client von wireguard.com/install holen, „Tunnel hinzufügen“ klicken und die .conf importieren.
Linux: apt install wireguard, Config nach /etc/wireguard/wg0.conf, dann wg-quick up wg0.
Android & iOS: WireGuard-App aus dem Store, Config per QR-Code einscannen. Den QR erzeugt ihr am Server fix mit qrencode -t ansiutf8 < client.conf.

Die Client-Config selbst ist schlank. Sie zeigt auf die Hetzner-IP und holt sich die 10.0.0.2:

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.0.0.2/32
MTU = 1280

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <HETZNER_PUBLIC_IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

Tunnel aktivieren, fertig. Ihr seid jetzt im selben Netz wie euer Heim-Server und tippt einfach http://10.0.0.50:3000 in den Browser.

Das Windows-Problem: MTU & Verbindungsabbrüche

Wenn ihr euch mit einem Windows-Client via WireGuard verbindet, werdet ihr vielleicht feststellen, dass die WebUI extrem langsam lädt oder die Verbindung sporadisch abbricht.

Das Problem ist die MTU (Maximum Transmission Unit). Durch den Overhead der VPN-Verschlüsselung werden die Pakete zu groß für den Standard-Tunnel und müssen fragmentiert werden – was unter Windows oft zum Abbruch führt. Deshalb steht in den Configs oben schon MTU = 1280.

DU ignorierst diesen Fix und behältst die Standard-MTU bei – auf eigenes Risiko, dass deine Sessions ständig wegbrechen! Ein Wert von 1280 ist der „Safe Bet“, da er fast jedes Netzwerk (auch Mobilfunk/LTE) problemlos überlebt.

Zusammenfassung

Ollama für die Inferenz – auf der GX10 dank vorinstalliertem DGX OS mit fertigem CUDA-Stack quasi Plug-and-Play, läuft genauso nativ auf x86.
Open WebUI als Frontend – per Skript zum Antesten, per Docker für den Dauerbetrieb.
WireGuard mit einem Server bei Hetzner als Treffpunkt für Heim-Server und Clients – keine offenen Ports daheim, und mit angepasster MTU stabil, wenn ihr Windows nutzt.

Läuft bei mir so seit Monaten stabil, hoffe es hilft jemandem.

Quellen: Ollama Official Docs · Open WebUI GitHub · NVIDIA DGX OS 7 User Guide · WireGuard Quick Start