DGX Spark privat über WireGuard anbinden

Der DGX ist ein optionaler lokaler LLM-Server in Graz. Die Cloud-Sprachpipeline bleibt eigenständig; ein Ausfall der Heimleitung darf keinen ungeprüften vollständigen Telefonieausfall verursachen. Ob dein quantisiertes 8B-/14B-Modell die erforderliche Qualität/Latenz erreicht, wird gemessen. Diese Anleitung lädt kein Modell automatisch herunter und verspricht keine GPU-Kapazität. NVIDIA-DGX-Spark-Betrieb

Cloudhost: 10.70.0.1 ── WireGuard/UDP 51820 ── DGX: 10.70.0.2
Voiceworker ── http://10.70.0.2:8000/v1 ── privater LLM
             └─ bei Vor-Ausgabe-Fehler/Timeout ── Cloud-LLM

1. Je Host eigene Keys erzeugen

Installiere WireGuard auf Cloud und DGX. Übertrage deploy/wireguard/prepare_peer.py auch auf den DGX. Verwende auf jedem Host eigene Keys:

sudo apt-get install -y wireguard
sudo python3 deploy/wireguard/prepare_peer.py keys --directory /etc/wireguard/aihub

Der Helfer erzeugt die private Datei mit Modus 0600, verarbeitet sie nur im Speicher/über stdin und gibt sie nicht aus. Er überschreibt keine bestehenden Keys. Übertrage nur public.key an den anderen Host, etwa als cloud-public.key bzw. dgx-public.key. Private Keys werden weder in Chatnachrichten, wg set ...-Argumente noch in Shellhistory kopiert. WireGuard-Keyverfahren

2. Konfigurationen erstellen

Cloudhost, nachdem der öffentliche DGX-Key bereitliegt:

sudo python3 deploy/wireguard/prepare_peer.py config --role cloud --directory /etc/wireguard/aihub --peer-public-file /etc/wireguard/aihub/dgx-public.key --output /etc/wireguard/wg-aihub.conf

DGX, nachdem der öffentliche Cloud-Key bereitliegt; ersetze CLOUD_PUBLIC_IPV4:

sudo python3 deploy/wireguard/prepare_peer.py config --role dgx --directory /etc/wireguard/aihub --peer-public-file /etc/wireguard/aihub/cloud-public.key --endpoint CLOUD_PUBLIC_IPV4:51820 --output /etc/wireguard/wg-aihub.conf

Die Cloud lauscht auf UDP 51820. Der DGX initiiert die Verbindung und nutzt PersistentKeepalive=25, sodass für diesen Peer normalerweise keine Portweiterleitung im Heimrouter nötig ist. AllowedIPs enthält jeweils nur die Gegenstelle; dein übriger Internetverkehr wird nicht als Default-Route durch den Tunnel geschickt. NAT-Keepalive

sudo systemctl enable --now wg-quick@wg-aihub
sudo wg show wg-aihub

wg show zeigt öffentliche Peer-/Handshakeinformationen, keinen privaten Schlüssel. wg showconf kann dagegen den privaten Konfigurationsinhalt offenlegen und wird hier nicht für Diagnosen verwendet. Prüfe von der Cloud ping -c 3 10.70.0.2, vom DGX ping -c 3 10.70.0.1. Öffne UDP 51820 nur auf dem Cloudhost; keine öffentliche Freigabe von TCP 8000.

3. Modell und Inferenzserver bewusst auswählen

Prüfe auf dem DGX uname -m, nvidia-smi und den installierten CUDA-Compiler. Aktualisiere DGX OS/Runtime nach NVIDIA-Anleitung. Wähle ein kommerziell verwendbares quantisiertes Instruct-Modell mit zunächst 8B oder 14B Parametern. Dokumentiere Quelle, Lizenz, Quantisierung, Chattemplate und Dateiprüfsumme. Eine konkrete „neueste Qwen-Version“ wird nicht ungeprüft festgelegt.

Als nachvollziehbarer OpenAI-kompatibler Servingpfad ist llama.cpp vorgesehen. Wähle einen überprüften Release-/Commitstand, baue auf ARM64 mit zum DGX passendem CUDA und installiere die Binary unter /opt/llama.cpp/build/bin/llama-server:

sudo apt-get install -y git cmake build-essential
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout --detach DEIN_GEPRUEFTER_RELEASE_ODER_COMMIT
cmake -S . -B build -DGGML_CUDA=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target llama-server --parallel 8
sudo install -d -m 0755 /opt/llama.cpp/build/bin
sudo install -m 0755 build/bin/llama-server /opt/llama.cpp/build/bin/llama-server
ldd /opt/llama.cpp/build/bin/llama-server

Ersetze den Commitplatzhalter. Bei nicht unterstütztem Compiler/GPU-Ziel korrigiere Runtime/Build anhand des gewählten Release; verwende keinen x86-only-Container auf dem ARM64-DGX. Lege das bewusst beschaffte Modell unter /srv/aihub-models/operator-model.gguf ab. Die Projektvorlage startet keine Modellbeschaffung. Offizieller CUDA-Build

4. Privaten Serverkey und Dienst einrichten

Lege auf dem neuen DGX einen Systembenutzer aihub-llm an, falls dieser noch nicht besteht. Er benötigt Lesezugriff auf Binary/Modell, kein Rootkonto:

sudo useradd --system --user-group --home-dir /nonexistent --shell /usr/sbin/nologin aihub-llm
sudo install -d -o aihub-llm -g aihub-llm -m 0700 /etc/aihub-dgx
sudo install -d -o root -g aihub-llm -m 0750 /srv/aihub-models
sudo install -o root -g aihub-llm -m 0640 /PFAD/ZU/DEINEM_MODELL.gguf /srv/aihub-models/operator-model.gguf

Ersetze den Modellpfad und prüfe, dass ldd keine fehlenden CUDA-/Systembibliotheken meldet. Übernimm den bereits erzeugten AIHUB_DGX_API_KEY aus der geschützten Cloudumgebung über einen sicheren Kanal; gib ihn nicht als CLI-Argument aus. Schreibe ihn per verdeckter Eingabe in die lokale Datei:

sudo python3 - <<'PY'
import getpass, os, pwd
key = getpass.getpass('DGX API-Key verdeckt eingeben: ').strip()
if not key or '\n' in key:
    raise SystemExit('Ungültiger Key')
account = pwd.getpwnam('aihub-llm')
fd = os.open('/etc/aihub-dgx/api-key', os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0o600)
with os.fdopen(fd, 'w') as file:
    file.write(key + '\n')
os.chown('/etc/aihub-dgx/api-key', account.pw_uid, account.pw_gid)
PY

Die Vorlage deploy/dgx/aihub-llm.service bindet ausschließlich an 10.70.0.2:8000, liest den Key aus der geschützten Datei und gibt das API-Modell als Alias aihub-local bekannt. --parallel 4, Kontextgröße und GPU-Offloading sind Startparameter für Tests, keine Leistungszusage. Passe sie an das tatsächlich gewählte Modell und den gemessenen Speicherverbrauch an. Server-/Keyfile-Optionen

Der Dienst schaltet den modellabhängigen Jinja-Chattemplate-Pfad für Toolaufrufe ausdrücklich ein und deaktiviert die eingebaute Weboberfläche. Prüfe mit deinem gewählten GGUF-Modell einen tatsächlichen search_knowledge-Toolturn; Modell und Chattemplate müssen Toolaufrufe korrekt ausgeben. Ein erreichbarer /v1-Endpunkt allein beweist diese Fähigkeit nicht.

Installiere den Dienst erst nach Prüfung der Pfade/Rechte:

sudo cp deploy/dgx/aihub-llm.service /etc/systemd/system/aihub-llm.service
sudo systemctl daemon-reload
sudo systemctl enable --now aihub-llm.service
sudo systemctl status aihub-llm.service
sudo ss -lntp

TCP 8000 darf nicht auf 0.0.0.0, der LAN-IP oder der öffentlichen Adresse lauschen. Erlaube über deine tatsächliche Firewall nur den Cloudpeer am WireGuard-Interface. Bestehende DGX-Firewallregeln werden nicht pauschal ersetzt.

5. Cloudworker und Hybridmodus

In der Cloud-Betreiberdatei:

AIHUB_DGX_BASE_URL=http://10.70.0.2:8000/v1
AIHUB_DGX_MODEL=aihub-local
AIHUB_DGX_API_KEY=DERSELBE_GESCHUETZTE_SERVERKEY
AIHUB_LOCAL_LLM_TIMEOUT_SECONDS=1.2
VOICE_LLM_PROVIDER=openai
OPENAI_MODEL=DEIN_VERFUEGBARES_CLOUDMODELL

HTTP wird hier ausschließlich innerhalb des verschlüsselten WireGuard-Pfads verwendet. Eine frei im Agenten eingegebene URL darf das Operatorziel nicht überschreiben. Prüfe die vollständige Konfiguration:

sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps app python manage.py check-config --voice --hybrid
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml up -d --force-recreate app
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml --profile voice up -d --force-recreate voice-worker-a voice-worker-b

Aktiviere im Assistenten das Feld data.llm_route=hybrid und veröffentliche den Agentstand erst, wenn lokale URL, Modell-ID und Cloudanbieter funktionieren. Alternativ gilt die Arbeitsbereichseinstellung llm_route=hybrid, solange der Agent keine eigene Route vorgibt (PATCH /api/settings mit {"llm_route":"hybrid"}).

Prüfe auch aus dem Docker-Voicecontainer die Erreichbarkeit des privaten DGX. Ein erfolgreicher Host-Ping allein beweist keine Containerroute. Bei Problemen kontrolliere Docker-Bridge-/NAT-/Forwardingregeln und die VPN-Handshakezeit, ohne Header oder Schlüssel mitzuschneiden. Jede zusätzliche physische Workermaschine benötigt einen eigenen Peer/Key und eine passende eigene VPN-Adresse; kopiere nie den privaten Cloudkey auf mehrere Hosts.

6. Fallback wirklich abnehmen

Führe einen autorisierten Einzelanruf durch. Stoppe anschließend für einen kontrollierten Test nur aihub-llm, danach nur den DGX-WireGuardpeer. Prüfe, dass der nächste Antwortturn zum Cloudmodell wechselt, bevor lokale Ausgabe wiederholt wird. Miss Ausfall-/Antwortdauer und beobachte Fehlerzähler. Starte die Dienste anschließend wieder und prüfe die Rückkehr.

Ein Timeoutwert von 1,2 Sekunden ist ein Konfigurationsziel, keine garantierte End-to-End-Antwortzeit. Bereits erzeugtes Audio, unterbrochene Toolaktionen und Providerlimits benötigen eigene Fehlerbehandlung. Der Last-/Ausfallnachweis gehört in das Protokoll unter Kapazitätsabnahme, nicht in eine unbelegte Marketingzusage.