DeepSeek V4 Flash auf zwei DGX-Spark-Nodes im Produktivbetrieb

ArtikelElite Test EngineeringAnleitung

Ein Erfahrungsbericht dokumentiert das Aufsetzen des Modells DeepSeek-V4-Flash (284B MoE) über zwei DGX-Spark-Nodes mit Grace-Blackwell-Architektur mittels Ray und vLLM. Neben Hardware-Eigenheiten wie Unified Memory und NCCL-Bugs zeigt der Bericht, wie Multi-Token Prediction die Geschwindigkeit um 45 Prozent steigerte.

Das Wichtigste

  1. NVFP4-Quantisierung scheiterte an fehlenden SM121-Kerneln in vLLM; genutzt wurde stattdessen der native FP8-Checkpoint (159,6 GB) mit Tensor-Parallelismus (TP=2).
  2. NCCL-Deadlocks über QSFP/ConnectX-7 erforderten NCCL_IB_DISABLE=1 (TCP über QSFP), während der Ray-Memory-Monitor für Unified Memory deaktiviert werden musste.
  3. CUDA-Graph-Captures beschädigten Cross-Node-Replays und erzeugten fehlerhafte Ausgaben; Abhilfe schaffte vorerst --enforce-eager.
  4. FP8 als KV-Cache-Format ist durch die MLA-Architektur des Modells zwingend vorgegeben; die Blockgröße musste beim Standard 16 verbleiben.
  5. Durch die Aktivierung nativer MTP-Draft-Heads (Speculative Decoding mit Tiefe 2) stieg der Durchsatz von 17–18 auf 25,3 Tokens pro Sekunde.

Warum das relevant ist

Große Mixture-of-Experts-Modelle wie DeepSeek-V4-Flash lokal auf kompakter DGX-Hardware zu betreiben, stößt noch auf viele Treiber-, Framework- und Kernel-Kinderkrankheiten. Der Bericht liefert konkrete Workarounds für vLLM, Ray und NCCL auf Nvidias Grace-Blackwell-Systemen (SM121).

Einordnung

Der Praxistest deckt typische Reibungspunkte aktueller Hardware-Generationen auf: Die Kombination aus Unified Memory (Grace Blackwell) und verteilten Frameworks verwirrt Tools wie Ray, während Nvidias eigene NCCL-Treiber auf RDMA-Links blockieren. Dass CUDA-Graphs für fehlerfreie Ausgaben komplett deaktiviert werden müssen (--enforce-eager), bedeutet Performance-Verluste. Dennoch kompensiert das im Modell integrierte Multi-Token-Prediction-Verfahren (MTP) diesen Nachteil spürbar: Mit einer Akzeptanzrate von über 85 Prozent bei Tiefe 1 liefert spekulatives Decoding ohne separates Draft-Modell einen signifikanten Durchsatzgewinn auf minimaler Cluster-Größe.

Gefunden in

Zusammenfassung von KI erstellt (Gemini 3.8 Flash, 27. September 2026). Sie kann Fehler enthalten – maßgeblich ist die Originalquelle.

Inhaltlich ähnlich, ermittelt über die KI-Suche.

  • Video

    Video:EliteTestEngineering

    DeepSeek V4 Flash auf Cluster aus DGX Spark und Acer GN100 im Test

    EliteTestEngineering demonstriert den Betrieb von DeepSeek V4 Flash auf einem Two-Node-Cluster aus einem DGX Spark und einem Acer GN100. Das MoE-Modell erreicht dabei Inferenzgeschwindigkeiten von 10 bis 16,5 Tokens pro Sekunde, stößt jedoch bei wachsendem Kontext schnell an Speichergrenzen.

    KI & AI· Demo

  • Repository:MiaAI-Lab/DeepSeek-v4-Flash-One-DGX-Spark

    DeepSeek-v4-Flash auf einer einzelnen DGX Spark betreiben

    Ein Open-Source-Launcher und Docker-Setup, mit dem DeepSeek V4 Flash 0731 (EXL3) auf einer einzelnen NVIDIA DGX Spark mit 128 GiB Unified Memory ausgeführt werden kann.

    328SternePython

    KI & AI· Tool

  • X-Post:Mia

    Inkling-Small auf zwei NVIDIA DGX Spark mit 1M Kontext

    Mia (@MiaAI_lab) berichtet über den Betrieb von Inkling-Small auf zwei NVIDIA DGX Spark mit einem Kontextfenster von einer Million Tokens via SGLang und dspark Speculative Drafts.

    106Lesezeichen9536Aufrufe

    KI & AI· Ankündigung

  • Repository:MiaAI-Lab/GLM-5.3-Flash-EXL3-2x-DGX-Sparks

    GLM-5.3 Flash EXL3 auf 2x NVIDIA DGX Spark Kits

    Das GitHub-Repository von Mia's AI Lab bietet eine optimierte vLLM-Serving-Konfiguration für GLM-5.3-Flash mit 4-bpw-EXL3-Quantisierung auf zwei NVIDIA GB10 Systemen.

    431SternePython

    KI & AI· Tool

Lassen Sie uns über Ihr Projekt sprechen

Standorte

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Wien
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Dieser Inhalt wurde teilweise mithilfe von KI erstellt.