DeepSeek V4 Flash auf 2× DGX Spark: FP8-Cluster mit 200K Kontext — der komplette Recipe

DeepSeek V4 Flash auf zwei DGX Spark: Der Cluster-Recipe mit echten Zahlen

TL;DR: Mit zwei DGX Spark (GB10, je 128 GB Unified Memory) und einer direkten 200G-QSFP56-Verbindung lässt sich das offizielle DeepSeek-V4-Flash-Modell in nativer FP8-Quantisierung mit 200K Kontextfenster betreiben — ohne Ray, mit Tensor-Parallelismus (TP=2) und spekulativem Decoding (MTP). Der NVIDIA-Forum-Thread dazu hat 28.100 Views und 318 Likes — eines der meistdiskutierten Community-Setups des Jahres. Für den Mittelstand ist das derzeit die günstigste Brücke zu einem 284B-Parameter-Modell mit großem Kontext, vollständig on-premise.

Alle Messwerte stammen aus dem verifizierten Community-Bericht vom NVIDIA Developer Forum (Stand: August 2026). Werte können je nach Firmware- und Softwarestand abweichen.

Warum dieses Setup für Mittelständler relevant ist

Das offizielle DeepSeek-V4-Flash-Modell in FP8 belegt rund 149 GB (46 Shards) — das passt in keinen einzelnen Spark (128 GB Unified Memory) und erst recht nicht in herkömmliche Arbeitsplatz-GPUs. Bisher galt für große Open-Weight-Modelle daher: Cloud, GPU-Server mit mehreren Karten oder gleich H100-Klasse.

Zwei Dinge machen den 2×-Spark-Cluster für den Mittelstand attraktiv:

Der Haken vorab: Das Setup ist kein "Plug & Play". Es baut auf noch nicht gemergten Community-Forks von vLLM auf und erfordert Netzwerk- und Docker-Erfahrung. Wer das nicht einplanen will, bleibt bei einem einzelnen Spark mit 70B-Modellen — die Cluster-Einordnung hilft bei der Entscheidung.

Das Netzwerk: 200G statt 10GbE

Der bestehende Cluster-Beitrag empfiehlt für Kubernetes-Setups 10GbE und Pipeline-Parallelismus. Für DeepSeek V4 Flash mit TP=2 ist das anders — hier wird die direkte Hochgeschwindigkeits-Verbindung der Sparks genutzt:

• 2× DGX Spark (GB10), je 128 GB Unified Memory
• Direktes QSFP56-200G-Kabel zwischen beiden Geräten (RoCE/NCCL über den CX-7-Netzwerkadapter)
• Link-Local-Adressierung (kein Switch nötig)
• Kein Ray: TP=2 mit --distributed-executor-backend mp und --nnodes 2

Tensor-Parallelismus über 200G-RoCE funktioniert hier gut — das ist der entscheidende Unterschied zu 10GbE-Setups, wo nur Pipeline-Parallelismus sinnvoll ist.

Der komplette Recipe

1. vLLM-Image bauen (der kritische Schritt)

Das Setup basiert auf dem eugr/spark-vllm-docker-Recipe (PR #219) plus dem jasl/vLLM-Fork. Der wichtigste Punkt: den vLLM-Commit exakt pinnen — nur der gepinnte Commit hat die GB10-Validierung hinter sich, keine Branch-Aliase verwenden:

./build-and-copy.sh \
  --vllm-repo https://github.com/jasl/vllm.git \
  --vllm-ref dda4668b59567416f86956cfe7bbc1eab371a61e \
  --rebuild-vllm -t vllm-node-dsv4 -c

2. Inference-Server starten (vom Head-Node)

DOTENV_CONTAINER_NAME=vllm_ds4 nohup ./run-recipe.sh \
  deepseek-v4-flash --no-ray --tp 2 --name vllm_ds4 > ds4.log 2>&1 &

3. Die wichtigsten Flags des Recipes

Gemessene Leistung (Community-Bericht)

Die Zahlen stammen aus einem warmen, einzelnen Stream auf echter Hardware:

Die Schwachstelle: Long-Context-Cold-Prefill. Bei 32K Kontext ~53 s TTFT, bei 128K ~250 s. Für kurze Prompt-Abfragen unproblematisch, für riesige Kontexte (ganze Dokumente, große Codebasen) deutlich spürbar.

Gotchas, die Zeit kosten (aus dem Erfahrungsbericht)

1. NCCL-Pin im PR #219 beachten. Der "Pin NCCL"-Commit symlinkt die System-libnccl. Ohne den aktuellen PR-Stand funktioniert die Cross-Node-Initialisierung nicht.
2. build-and-copy.sh verhunzt den Worker-User (doppeltes user@). Workaround: docker save | ssh worker docker load über die Verbindung.
3. max_num_seqs=2 ist bei 200K Kontext Absicht (KV-Budget). Wer mehr Concurrency will, muss --max-model-len senken — validierte Profile: 65K bei 16 Seqs, 32K bei 36 Seqs.
4. CX-7-Link kann klemmen. Ein mlx5 ACCESS_REG-Timeout beim Teardown ließ sich nur mit einem sauberen Kaltstart beheben.
5. Bekanntes Folgeproblem: Bei MTP + CUDA-Graphs kann es auf 2× Spark zu intermittierender Token-Korruption kommen — der separate Thread dokumentiert Workarounds.

Open-Source-Verwaltung: DGX Manager

Für den produktiven Betrieb lohnt ein Blick auf DGX Manager — eine Open-Source-Control-Plane für Spark-Cluster:

• Web-Dashboard für Provisioning, Deployment und Inference-Load-Balancing
• vLLM (Recipe-basiert) und Ollama mit einem Klick
• Multi-Node-Inference über Ray (Tensor-/Pipeline-Parallelismus)
• Fein-Tuning (LoRA via DeepSpeed ZeRO-2/3, TRL+PEFT, Unsloth), inkl. Multi-Node-Training
• Live-GPU-Telemetrie (5-Sekunden-Auflösung), Benchmarking
• Zero-Cloud-Abhängigkeiten, heterogene Nodes (arm64 + amd64)

Das Tool ist noch in der Testphase (Feedback gesucht) — für PoCs aber schon jetzt einen Blick wert. Das GPU-Monitoring lässt sich damit gut ergänzen.

Kosten-Überblick

Zum Vergleich: DeepSeek V4 Flash auf klassischer GPU-Hardware braucht in 4-Bit-Quantisierung rund 170 GB Gewichte — realistisch vier Karten der 96-GB-Klasse, also etwa 48.000 EUR nur für GPUs. Der 2×-Spark-Cluster ist damit rund 4-5× günstiger für dasselbe Modell — bei 200K Kontext statt 1M.

Für wen sich das lohnt

Sinnvoll, wenn:

• Sie DeepSeek V4 Flash mit großem Kontext (bis 200K) vollständig on-premise brauchen (DSGVO, EU AI Act, Betriebsrat)
• Sie zwei Sparks ohnehin besitzen oder planen
• Ein 70B-Modell auf einem Spark nicht reicht und Sie die Setup-Arbeit einplanen

Eher nicht, wenn:

• Ein einzelner Spark mit Ollama Ihre 70B-Workloads abdeckt
• Sie 1M-Kontextfenster benötigen (der 2×-Spark-Recipe läuft bei 200K)
• Sie keine Docker-/Netzwerk-Erfahrung im Team haben — das Setup ist kein Kauf-Produkt

Fazit

Der 2×-DGX-Spark-Cluster mit DeepSeek V4 Flash (FP8, TP=2, MTP, 200K) ist derzeit die günstigste Möglichkeit, ein 284B-Modell mit großem Kontext komplett on-premise zu betreiben — für unter 11.000 EUR Gesamtkosten über drei Jahre. Die Community hat den Recipe verifiziert und dokumentiert; wer die Gotchas kennt (NCCL-Pin, KV-Budget, MTP-Korruption), spart sich deutlich Zeit. Es ist kein Plug & Play, aber die einzige Alternative auf diesem Preisniveau ist die Cloud — und die scheidet für viele Mittelständler aus Datenschutzgründen aus.