Zwei DGX Spark als lokaler LLM-Cluster: Die komplette Anleitung

28. Jun 2026 Deutsch 6 Min. Lesezeit Auch auf: English, Español

lokale-ki nvidia dgx-spark vllm hardware

Eine Desktop-Box, die ein Modell mit 400 Milliarden Parametern komplett im eigenen Netz ausführt, ganz ohne Cloud-API, war bis vor Kurzem Serverraum-Fantasie. Ende Juni 2026 hat ein Praktiker aus der Community auf X ein komplettes Rezept geteilt, um genau das zu erreichen: zwei NVIDIA DGX Spark zu einem LLM-Cluster auf Frontier-Niveau zu verbinden, der unter den Schreibtisch passt.

Wir haben dieses Rezept aufgegriffen, jeden Schritt gegen NVIDIAs offizielle DGX-Spark-Playbooks geprüft und daraus die folgende Installationsanleitung gemacht. Für europäische KMU, die lokale KI evaluieren, ist das der kompakteste Weg zu echter Großmodell-Inferenz, die das Haus nie verlässt.

Was ist der DGX Spark, und warum gleich zwei?

Der NVIDIA DGX Spark ist eine Desktop-KI-Maschine auf Basis des GB10 Grace Blackwell Superchips. Die Eckdaten:

Spec	Einzelner DGX Spark	Zwei-Geräte-Cluster
Unified Memory	128 GB LPDDR5x	256 GB
CPU	20-Core Arm (10x Cortex-X925 + 10x Cortex-A725)	40 Kerne gesamt
KI-Leistung	bis 1 PFLOP FP4 (mit Sparsity)	bis 2 PFLOP FP4
Speicher	bis 4 TB NVMe	bis 8 TB
Netzwerk	ConnectX-7, 2x 200GbE (QSFP)	direkte 200GbE-Peer-Verbindung
Max. praktikables Modell	~70B-Klasse	~405B-Klasse

Ein einzelnes Gerät ist bereits eine leistungsfähige lokale Inferenz-Maschine. Der Grund für ein Paar ist der Speicher: 256 GB gebündelter Unified Memory sind die Schwelle, ab der wirklich große, frontier-nahe Open-Weight-Modelle auf Hardware nutzbar werden, die weniger Strom zieht als ein Gaming-PC. Die zwei ConnectX-7-NICs machen die Kopplung trivial, ein Switch ist nicht nötig.

Stückliste

2x NVIDIA DGX Spark (je 128 GB)
1x 200G-QSFP56-Passiv-DAC-Kabel, NVIDIA-Teilenummer Q56-200G-CU0-5 oder ein DGX-Spark-validiertes Äquivalent
(optional, später für 4 bis 8 Geräte) ein MikroTik CRS504 200GbE-Switch

Mehr braucht der Zwei-Geräte-Cluster nicht.

Schritt 1: Physische Verbindung

Stecken Sie ein Ende des QSFP-Kabels in einen ConnectX-7-Port des ersten Geräts und das andere Ende in den gleichen Port des zweiten Geräts (beide linken oder beide rechten Ports, von hinten betrachtet). Ein Kabel liefert volle Bandbreite. Ein zweites Kabel bringt nur etwas, wenn Sie allen vier Interfaces IP-Adressen zuweisen.

Schritt 2: Interface identifizieren

Finden Sie auf jedem Gerät das aktive ConnectX-7-Interface:

ibdev2netdev

Auf dem DGX Spark heißen die beiden Highspeed-Interfaces enp1s0f0np0 und enp1s0f1np1. Merken Sie sich, welches am verkabelten Port den Status Up zeigt, Sie referenzieren es in den Netzwerk- und NCCL-Schritten.

Schritt 3: Netzwerkkonfiguration (netplan)

Es gibt zwei Optionen. Link-local ist am schnellsten bei einem Kabel; statische IPs sind nötig, wenn Sie alle vier Interfaces für maximale Bandbreite verkabeln.

Option A, automatisches Link-local. Legen Sie /etc/netplan/40-cx7.yaml auf beiden Geräten an:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0f0np0:
      dhcp4: no
      link-local: [ ipv4 ]
    enp1s0f1np1:
      dhcp4: no
      link-local: [ ipv4 ]

Das vergibt automatisch IPv4-Link-local-Adressen im Bereich 169.254.x.x.

Option B, manuelle statische IPs. Auf Knoten 1, /etc/netplan/40-cx7.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0f0np0:
      dhcp4: no
      addresses: [192.168.100.10/24]

Auf Knoten 2 dieselbe Datei mit 192.168.100.11/24. Auf beiden anwenden:

sudo netplan apply

Bestätigen Sie die Verbindung mit einem Ping über das neue Interface, bevor es weitergeht.

Schritt 4: Passwortloses SSH

Verteilte Inferenz braucht schlüsselbasiertes SSH zwischen den Geräten. Verwenden Sie auf beiden denselben Benutzernamen. Erzeugen Sie einen dedizierten Schlüssel und kopieren ihn auf den anderen Knoten:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_shared -N ""
ssh-copy-id -i ~/.ssh/id_ed25519_shared.pub <user>@192.168.100.11

NVIDIAs Helfer discover-sparks.sh automatisiert das: Er findet andere Sparks auf der Verbindung per avahi-browse -r -t ssh.tcp, verteilt den gemeinsamen Schlüssel und schreibt die ~/.ssh/config-Einträge. Prüfen Sie, dass ssh 192.168.100.11 ohne Passwortabfrage verbindet.

Schritt 5: NCCL über die Verbindung prüfen

Bevor Sie ein echtes Modell starten, bestätigen Sie, dass NCCL Daten über die 200GbE-Verbindung bewegt. Setzen Sie die Interface-Variablen (Ihr Up-Interface einsetzen) und starten Sie einen All-Gather-Benchmark aus der nccl-tests-Suite:

export NCCL_SOCKET_IFNAME=enp1s0f1np1
export UCX_NET_DEVICES=enp1s0f1np1
export OMPI_MCA_btl_tcp_if_include=enp1s0f1np1

mpirun -np 2 -H 192.168.100.10,192.168.100.11 \
  all_gather_perf -b 8 -e 256M -f 2 -g 1

Ein gesunder Lauf zeigt eine Bus-Bandbreite, die mit wachsender Nachrichtengröße Richtung Link-Rate steigt. Ist die Bandbreite niedrig, haben Sie fast sicher das falsche NCCLSOCKETIFNAME gesetzt.

Schritt 6: Verteilte Inferenz mit vLLM und Ray

Der übliche Serving-Stack ist vLLM mit Ray-Backend. Starten Sie Ray auf dem Head-Knoten, dann den Worker:

# Auf Knoten 1 (Head):
ray start --head --port=6379

# Auf Knoten 2 (Worker):
ray start --address=192.168.100.10:6379

Anschließend vLLM auf dem Head-Knoten mit Tensor-Parallelität über beide Geräte starten:

vllm serve Qwen/Qwen3.6-35B-A3B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --distributed-executor-backend ray \
  --max-model-len 8192 \
  --reasoning-parser qwen3 \
  --gpu-memory-utilization 0.7

Für ein größeres Modell, das die vollen 256 GB braucht, erhöhen Sie --max-model-len und --gpu-memory-utilization (0,85 ist eine gängige Obergrenze). Der Quell-Guide nutzt zusätzlich --max-num-seqs 4, um die Parallelität bei speicherhungrigen Modellen zu begrenzen. Der OpenAI-kompatible Endpunkt läuft dann auf Port 8000.

Empfohlene Modelle

Die folgenden Empfehlungen stammen aus dem ursprünglichen Community-Guide auf X und sind Community-Angaben. Behandeln Sie die Durchsatzwerte als Richtwerte, sie schwanken je nach Quantisierung und Prompt-Länge.

Einzelner DGX Spark (128 GB):

Qwen 3.6 35B (NVFP4), bis 256K Kontext, rund 110 Tokens/Sek.
DeepSeek V4 Flash (REAP)
Nemotron Super (NVIDIA-optimiert)

Zwei-Geräte-Cluster (256 GB):

DeepSeek V4 Flash, bis 1M Kontext, rund 40 bis 45 Tokens/Sek. in einer Session
Step-3.7-Flash mit Bildeingabe-Unterstützung

Skalierung über zwei Geräte hinaus

Der Ansatz mit einem Kabel und ohne Switch gilt nur für den Zwei-Geräte-Fall. Für vier bis acht Geräte ist ein MikroTik CRS504 200GbE-Switch die dokumentierte Option, mit minimalem Bandbreitenverlust. NVIDIA veröffentlicht eigene Playbooks für Drei-Spark- und geswitchte Multi-Spark-Topologien (unten verlinkt).

Warum das für KMU in der EU zählt

Ein lokaler DGX-Spark-Cluster nimmt eine ganze Kategorie an Compliance-Risiko heraus. Die Inferenz läuft auf Ihrer Hardware, also:

Keine Drittlandübermittlung nach Art. 44 DSGVO, keine Daten verlassen das Haus
Volle Nachvollziehbarkeit im Sinne der Betreiberpflichten des EU AI Act (Art. 26), jede Anfrage lässt sich intern protokollieren und aufbewahren
Kein Anbieter-Training auf Ihren Eingaben, keine Cloud-Speicherung außerhalb Ihrer Kontrolle

Nach unserer Lesart des EU AI Act senkt der On-premise-Betrieb von General-Purpose-Modellen den Dokumentationsaufwand spürbar gegenüber Cloud-API-Integrationen. Das ist keine Rechtsberatung, prüfen Sie Ihre konkrete Einstufung nach Anhang III.

Freshlab tritt dabei als Partner auf, nicht als Lieferant, mit mehr als 25 Jahren Wurzeln in der pharmazeutischen Lohnherstellung und in ERP-Projekten sowie deutschsprachigen Wurzeln in Bayern. Wir wissen, was eine regulierte, dokumentenlastige Umgebung von lokaler KI verlangt.

Fazit

Zwei DGX Spark, ein QSFP-Kabel und die sechs Schritte oben ergeben einen lokalen 256-GB-Inferenz-Cluster, der frontier-nahe Open-Weight-Modelle bedient, ohne dass etwas Ihr Netz verlässt. Für ein reguliertes europäisches KMU ist diese Kombination aus Leistung und Datensouveränität mit keinem Cloud-Angebot leicht zu erreichen.

Pilotprojekt starten →, Freshlab installiert und konfiguriert lokale KI-Infrastruktur, inklusive DGX-Spark-Cluster und Modell-Deployment, für KMU in der EU.

Quellen

Konkrete Interface-Namen, IP-Bereiche und Modell-Verfügbarkeit können je nach Firmware-Stand abweichen. Folgen Sie für die Installation den verlinkten offiziellen NVIDIA-Playbooks als verbindlicher Referenz und nutzen Sie diese Anleitung als Orientierung.

Häufige Fragen

Wie viele DGX Spark brauche ich für ein wirklich großes Modell lokal?

Zwei. Ein einzelner DGX Spark hat 128 GB Unified Memory und deckt mittelgroße Modelle gut ab. Zwei Geräte, über ihre ConnectX-7-200GbE-Ports verbunden, bündeln 256 GB. Das reicht für Modelle bis rund 405 Milliarden Parameter, je nach Quantisierung.

Brauche ich einen Switch, um zwei DGX Spark zu verbinden?

Nein. Für einen Zwei-Geräte-Cluster genügt ein einziges 200G-QSFP56-Kabel direkt zwischen den beiden ConnectX-7-Ports und liefert volle Bandbreite. Ein Switch (etwa ein MikroTik CRS504) wird erst ab vier Geräten nötig.

Welcher Inferenz-Stack läuft über beide Geräte?

Üblich ist vLLM mit Ray-Backend. NCCL übernimmt die GPU-beschleunigten Collective-Operationen über die 200GbE-Verbindung, und vLLM wird mit Tensor-Parallel-Size 2 und dem Ray-Executor gestartet.

Ist ein lokaler DGX-Spark-Cluster DSGVO- und EU-AI-Act-konform?

Lokale Inferenz hält alle Daten auf der eigenen Hardware. Es gibt also keine Drittlandübermittlung nach Art. 44 DSGVO und volle Nachvollziehbarkeit im Sinne der Betreiberpflichten des EU AI Act. Das ist ein Hauptgrund, warum europäische KMU on-premise statt Cloud-API wählen. Keine Rechtsberatung, prüfen Sie Ihre konkrete Einstufung.

Kann Freshlab das für uns einrichten?

Ja. Freshlab installiert und konfiguriert lokale KI-Infrastruktur für KMU in der EU, inklusive DGX-Spark-Cluster, Modell-Deployment und Integration in Ihre Systeme. Ein Pilotprojekt deckt das erste Scoping kostenfrei ab.