DGX Spark Cluster: 2× GB10 mit Kubernetes für 140B+ Modelle

DGX Spark Cluster: 2× GB10 mit Kubernetes für 140B+ Modelle

Ein DGX Spark betreibt 70B-Modelle — aber was, wenn Sie 140B+ Modelle, mehrere parallele Workloads oder hohen Durchsatz brauchen? Dann verbinden Sie zwei Sparks zu einem Cluster. Die Community macht das bereits: DeepSeek-V4 über zwei Spark-Knoten ist eines der meistdiskutierten Setups im NVIDIA-Forum.

Dieser Beitrag zeigt, wie ein 2×-GB10-Cluster aufgebaut wird — Netzwerk, Kubernetes, Modell-Verteilung und die ehrliche Grenze dessen, was zwei Sparks wirklich leisten.

Was bringt ein 2×-Spark-Cluster?

Die Kernfrage ist ehrlich zu beantworten: Zwei Sparks verdoppeln den Durchsatz und erlauben größere Modelle — aber sie sind kein Ersatz für einen GPU-Cluster mit A100/H100. Für 70B-Workloads mit hoher Auslastung ist ein einzelner Spark oft die wirtschaftlichere Wahl.

Netzwerk: Der Flaschenhals

Der Spark hat 1× 10GbE — das ist der limitierende Faktor im Cluster. Modelle zwischen den Knoten zu verteilen heißt: Gewichte über das Netzwerk schicken.

Was zu beachten ist:

• 10GbE-Switch (nicht direkt verbinden): Für 2 Knoten reicht ein kleiner 10GbE-Switch ab ca. 150 EUR
• Direkte Verbindung (2 Knoten): Ethernet-Kabel reicht, aber ohne Switch keine Erweiterung
• Latenz: Für Tensor-Parallelismus ist 10GbE zu langsam — hier wird Pipeline-Parallelismus genutzt (Modell-Layer auf beide Knoten verteilt)

Kubernetes-Setup Schritt für Schritt

Schritt 1: Beide Sparks vorbereiten

# Auf beiden Knoten: Docker + Kubernetes installieren
sudo apt update && sudo apt install -y docker.io kubeadm kubelet kubectl

Schritt 2: Cluster initialisieren (Knoten 1 = Control-Plane)

sudo kubeadm init --pod-network-cidr=10.244.0.0/16
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Schritt 3: Worker beitreten (Knoten 2)

# Den kubeadm-join-Befehl vom Init-Output kopieren und ausführen
sudo kubeadm join <knoten1-ip>:6443 --token <token> --discovery-token-ca-cert-hash <hash>

Schritt 4: Pod-Netzwerk (Flannel oder Calico)

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Schritt 5: GPU-Label für Scheduling

kubectl label node spark-1 nvidia.com/gpu=gb10
kubectl label node spark-2 nvidia.com/gpu=gb10

Modelle im Cluster verteilen

Option A: Ollama im Cluster (einfach, ohne Orchestrierung)

Jeder Spark betreibt sein eigenes Ollama, der Client routet:

# Auf beiden Knoten: Ollama starten
ollama serve --host 0.0.0.0:11434

# Knoten 1: Sprachmodell, Knoten 2: Embeddings/RAG
# → Client nutzt die passende API je nach Workload

Das ist kein echtes Cluster, aber für die meisten Mittelstands-Szenarien (RAG + Generation auf getrennten Knoten) völlig ausreichend.

Option B: vLLM mit Pipeline-Parallelismus (echtes Cluster)

Für ein 140B-Modell über zwei Knoten:

# vLLM auf beiden Knoten mit Tensor-Parallelism über das Netzwerk
python -m vllm.entrypoints.openai.api_server \
  --model <140B-modell> \
  --tensor-parallel-size 2 \
  --pipeline-parallel-size 2

Wichtig: Bei 10GbE ist Pipeline-Parallelismus (Layer aufteilen) dem Tensor-Parallelismus (Gewichte aufteilen) vorzuziehen — die Kommunikationslast ist geringer. Die vLLM-Konfiguration erklärt die Parameter im Detail.

Option C: NVIDIA NIM / Triton (Enterprise)

Für den produktiven Betrieb mit Monitoring und Slots-Verwaltung bieten sich NVIDIA NIM-Container auf Kubernetes an — der Triton-Inference-Server-Guide zeigt das Muster.

Achtung Sackgassen

1. "Zwei Sparks = doppelte Leistung" stimmt nicht linear. Durch Netzwerk-Overhead und Verteilungsverluste erreichen 2 Sparks realistisch ca. 1,6-1,8× den Durchsatz — nicht 2×.

2. 10GbE ist der Flaschenhals. Für Modelle über 200B oder Echtzeit-Inferenz reicht die Bandbreite nicht. Wer echte Multi-GPU-Leistung braucht, landet bei H100/A100-Systemen mit NVLink.

3. Der zweite Spark ist teuer. 3.200 EUR für Redundanz ist viel. Erst wenn 140B-Modelle oder dauerhafte Parallel-Workloads real gebraucht werden, amortisiert sich der zweite Knoten — die ROI-Rechnung hilft bei der Entscheidung.

Kosten im Überblick

Vergleich: Ein einzelner H100 kostet 25.000+ EUR. Für den Mittelstand ist der 2×-Spark-Cluster damit die günstigste Brücke zu 140B-Workloads.

Entscheidungsmatrix

Fazit: Der Cluster ist die Mittelstands-Brücke zu 140B

Ein 2×-GB10-Cluster ist 2026 die wirtschaftlichste Möglichkeit, Modelle über 100B lokal zu betreiben: ca. 6.500 EUR statt 25.000+ EUR für eine Datacenter-GPU. Mit Kubernetes, Pipeline-Parallelismus und sauberem Netzwerk-Setup entsteht daraus ein produktionsfähiges System.

Die Grenze ist das 10GbE-Netzwerk: Für echten Datacenter-Durchsatz reicht es nicht. Aber für 140B-Modelle, parallele Abteilungs-Workloads und lokale Datenhoheit ist der Cluster die richtige Antwort.

Sie wollen einen Spark-Cluster oder eine Einzelknoten-Konfiguration aufsetzen und brauchen Unterstützung bei Architektur und Setup? Sprechen Sie uns an, und wir planen gemeinsam Ihre lokale KI-Infrastruktur.

Häufige Fragen

Brauche ich Kubernetes für einen 2×-Spark-Cluster?

Für einfache Szenarien (jeder Knoten ein eigenes Ollama) nicht. Für echtes Cluster-Verhalten — ein Modell über beide Knoten, zentrales Scheduling — ja. Kubernetes ist der Standard dafür.

Wie schnell ist ein 140B-Modell über zwei Sparks?

Deutlich langsamer als ein 70B-Modell auf einem Spark. Realistisch 5-10 Token/s bei Pipeline-Parallelismus über 10GbE. Für RAG und Batch-Verarbeitung ok, für Echtzeit-Chat grenzwertig.

Kann ich mehr als zwei Sparks verbinden?

Ja, Kubernetes skaliert auf beliebig viele Knoten. Der Flaschenhals bleibt das 10GbE-Netzwerk — ab 4+ Knoten lohnt sich ein Managed-Switch mit größerem Backbone.

Lohnt sich ein zweiter Spark nur für Redundanz?

Nein. 3.200 EUR für reine Redundanz ist unwirtschaftlich. Der zweite Spark lohnt sich erst bei 140B-Modellen oder dauerhaft parallelen Workloads — die TCO-Rechnung zeigt die Grenze.