Skip to main content
Sie können deepseek-ai/DeepSeek-V4-Flash-0731 selbst hosten; es handelt sich dabei um die offizielle Version, die die V4 Flash-Vorschau ablöst. Die Entscheidung hängt jedoch von weiteren Faktoren ab als nur vom verfügbaren Gesamtspeicher. Das mit 284B bezeichnete Zielmodell verarbeitet 13B Parameter pro Token. Dank des mitgelieferten DSpark-Entwurfskopfs erhöht sich die Gesamtzahl der Parameter auf etwa 304B. Für die veröffentlichten Bereitstellungsformate sind zudem rund 162 bis 167 GB an Speicherplatz erforderlich – abzüglich des KV-Caches, temporärer Puffer sowie des Betriebssystems. Die nachfolgend aufgeführten 3 Konfigurationen erfüllen diese Mindestanforderungen. Allerdings weisen sie nicht dasselbe Maß an Softwarereife auf. Die praktische Empfehlung lautet: Beginnen Sie mit einem 32K–128K-Kontext, stellen Sie eine stabile Generierung sowie korrekte Werkzeugaufrufe sicher und ermitteln Sie anschließend die tatsächliche Cache-Kapazität. Betrachten Sie 384K und 1M als eigenständige technische Ziele. Das Modell bietet zwar einen Kontextraum von 1M Tokens an; das bedeutet jedoch nicht, dass jede lokale Konfiguration einen nutzbaren 1M-Token-Cache bereitstellen kann.

Welche Konfigurationen eignen sich, und wie zuverlässig sind sie?

Verifiziert bedeutet, dass die genannte Software oder der Modell-Quellcode den exakten Pfad dokumentiert. Community-Validierung erforderlich bedeutet, dass die Leistungsfähigkeit sowie ein eng verwandter Laufzeitpfad beschrieben sind, doch diese spezifische Kombination aus Checkpoint und Hardware wurde bisher nicht öffentlich nachgebildet. Von der Community getestet bedeutet, dass Nutzer diese Methode bereits beschrieben haben; Sie müssen sie jedoch auf Ihren eigenen Versionen erneut nachvollziehen. Experimentell bedeutet, dass das Upstream-Projekt selbst warnt, dass dieser Ansatz noch nicht für den Produktivbetrieb geeignet ist.

Beginnen Sie mit der Berechnung des Speicherbedarfs.

Die offizielle Modell-Dokumentation erläutert das 284B-Zielmodell, die 13B aktiven Parameter pro Token sowie das zugehörige DSpark-Spekulativ-Decoding-Modul. Die aktuelle Hardware-Matrix von SGLang umfasst rund 304B Parameter für den gesamten 0731-Checkpoint. Diese Zahl erklärt zwar die Rechenkosten, sagt jedoch nichts darüber aus, wie viel Modellzustand physisch im Speicher vorhanden sein muss.
Als konkrete herunterladbare Variante bietet Unsloth eine verlustfreie GGUF-Version mit etwa 162 GB Umfang an. Andere Bereitstellungsformate erreichen nach Einbeziehung der zusammengeführten Gewichte und Metadaten nahezu 167 GB. Dieser Wert stellt lediglich die untere Grenze dar und ist keine konkrete Empfehlung für die Deployment-Planung.
Man sollte nicht davon ausgehen, dass 192 GB tatsächlich als 192 GB für V4 Flash zur Verfügung stehen. Zwei GPUs mit jeweils 96 GB erfüllen zwar die Mindestanforderungen für die Modellgewichte, doch bleibt nur wenig Platz für den KV-Cache sowie weitere Laufzeit-Allokationen. Selbst wenn das Modell erfolgreich geladen wird, ist eine nutzbare Deployment-Konfiguration noch nicht gewährleistet.

2× RTX PRO 6000 Blackwell

NVIDIA lists the RTX PRO 6000 Blackwell with 96 GB of GDDR7 memory and 1,792 GB/s memory bandwidth per card in its product specifications. Two cards give 192 GB of VRAM, enough to hold the published weight formats in principle. SGLang documents tensor parallelism of 2 for the earlier Flash checkpoint in its DeepSeek V4 guide. Its 0731 validation list covers larger 4–8 GPU configurations, not this exact 2-GPU setup. Call this path Community validation required, not verified.

Empfohlener Ablauf

  1. Stellen Sie sicher, dass beide GPUs vom gewählten Laufzeit-Environment erkannt werden.
  2. Beginnen Sie zunächst mit einem 32K großen Kontext-Limit sowie jeweils nur einem 1 Anfrage gleichzeitig.
  3. Erhöhen Sie das Limit erst auf Werte nahe 128K, nachdem Sie den VRAM-Verbrauch, die Latenz bis zum ersten Token sowie die Stabilität der Ausführung gemessen haben.
  4. Falls Sie 384K oder 1M benötigen, sollten Sie die Größe des KV-Caches anhand gemessener Nutzungsdaten festlegen, anstatt die Gewichte manuell von der Gesamt-VRAM-Menge abzuziehen.
Von der Community getestet – früherer Flash TP=2-Baseline. Passen Sie die Upstream-Modell-ID sowie die Parameter exakt an die in der SGLang-Anleitung angegebene Version an. Dies stellt lediglich ein Ausgangsmuster dar, kein offizielles 0731-Validierungsverfahren:
Bevor Sie den Befehl ausführen, vergleichen Sie die Argumentbezeichnungen sowie die unterstützten Quantisierungsmethoden mit Ihrer installierten SGLang-Version. Der Checkpoint, der Container, die Treiber sowie die Topologie der Workstation beeinflussen maßgeblich, ob TP=2 erfolgreich funktioniert.

2× DGX Spark

Each DGX Spark has 128 GB of LPDDR5x unified memory and 273 GB/s memory bandwidth. NVIDIA documents a ConnectX-7 clustering path for 2 systems in its Spark stacking guide, and lists the hardware details in its DGX Spark overview. This gives 256 GB of aggregate memory, which is meaningfully less tight than 192 GB for weight plus cache capacity. Es handelt sich weiterhin um eine netzwerkbasierte verteilte Laufzeitumgebung. NVIDIA dokumentiert lediglich die Cluster-Infrastruktur, nicht ein offizielles 0731-DeepSeek-Verfahren. Berichte der Community zu 2 Spark-Systemen beziehen sich auf frühere Flash-Checkpoints. Nach dem Umstieg auf 0731 sollten Sie die Modellladung, die Generierung, die Tool-Aufrufe sowie die Ausdauer der Anfragen erneut überprüfen.

Empfohlene Topologie

Nur der Head-Node benötigt den Tokios-Connector. Dieser muss auf den lokalen OpenAI-kompatiblen /v1-Endpunkt des Head-Nodes verweisen, nicht direkt auf die Worker oder das Cluster-Netzwerk. Von der Community getestet – Ausgangsmuster für Dual-Spark-Systeme. Zuerst müssen Sie die 2-Spark-Netzwerkkonfiguration gemäß NVIDIA-Anleitung einrichten. Anschließend nutzen Sie ein verteiltes Laufzeitverfahren, das explizit Ihre installierte Version unterstützt, und starten ab dem Kontext 32K. Geben Sie keinesfalls einen Preview-Checkpoint-Befehl als offizielles 0731-Verfahren aus.
NVIDIA bezeichnet die Hochgeschwindigkeitsverbindung als ConnectX-7-Cluster-Link. Dies ersetzt jedoch keinesfalls einen NVLink-ähnlichen Speicherpool für einzelne Grafikkarten: Die Laufzeitumgebung teilt die Aufgaben weiterhin auf und kommuniziert zwischen den Knoten. Messen Sie Durchsatz und Latenz unter verschiedenen Prompt-Größen.

2× Strix Halo

AMD lists the Ryzen AI Max+ 395 with up to 128 GB of unified memory in its processor specifications. Two fully provisioned systems have enough aggregate capacity for the 162 GB GGUF weight release. Das Problem liegt in der verteilten Servingschicht. Der verfügbare Weg ist der llama.cpp RPC. In dessen Upstream-RPC-README wird RPC als reines Konzeptbeispiel bezeichnet; zudem wird vor seiner Instabilität und mangelnden Sicherheit gewarnt. Folglich handelt es sich hier um eine experimentelle Demonstration der Kapazitäten, keinesfalls um eine produktionsreife Architektur. Experimentell – Aufbau des llama.cpp RPC. Starten Sie den RPC-Arbeitsprozess ausschließlich in einem privaten, vertrauenswürdigen Netzwerk. Da sich die exakten Binärnamen sowie Parameter bei verschiedenen llama.cpp-Versionen unterscheiden, orientieren Sie sich bitte an der Upstream-README für die Befehle, die zu Ihrer Revision passen.
Richten Sie keinesfalls einen RPC-Listener im öffentlichen Internet ein. Bezeichnen Sie den RPC-Weg nicht als produktionsreif, nur weil das Modell erfolgreich geladen werden kann. Für einen stabilen Produktivdienst empfiehlt sich stattdessen eine Laufzeitumgebung mit dokumentiertem Modell für verteiltes Serven.

Offizielle Referenzwerte, anhand derer Sie Vergleiche anstellen können

Nutzen Sie Beispiele von Herstellern sowie Laufzeitumgebungen, um Ihre Erwartungen zu formen; schließen Sie daraus jedoch nicht, dass kleinere Hardware-Systeme denselben Unterstützungsgrad bieten. Verifiziert – aktuelle 0731 vLLM-Referenz. Die offizielle Modelldokumentation verwendet 4× GB300, Experten-Parallelverarbeitung, FP8-KV-Cache sowie das integrierte DSpark-Modul:
Für agentenbasierte Workloads empfiehlt DeepSeek temperature = 1.0 sowie top_p = 0.95. Bitte halten Sie diese Sampling-Einstellungen getrennt von den Startparametern des Servers und testen Sie sie mithilfe Ihres Agenten-Frameworks.

Führen Sie die Validierung in folgender Reihenfolge durch

  1. Laden Sie den exakten Checkpoint herunter und notieren Sie dessen Revision.
  2. Laden Sie ihn anschließend mit 32K Kontext und 1 gleichzeitigen Anfragen.
  3. Senden Sie eine kurze Chat-Anfrage, eine lange Prompt-Anfrage sowie ggf. eine Tool-Aufrufanfrage, falls Ihre Workloads Tools erfordern.
  4. Dokumentieren Sie den Speicherverbrauch, die Latenz bis zum ersten Token, die Generierungsrate sowie eventuelle Fehler.
  5. Erhöhen Sie den Kontext auf 128K und wiederholen Sie die gleiche Workload-Sequenz.
  6. Erst danach sollten Sie 384K bzw. 1M unter Berücksichtigung des KV-Cache-Budgets sowie eines Rollback-Plans testen.
Diese Reihenfolge ermöglicht es, Probleme bezüglich der Gewichtsanpassung von Schwierigkeiten im Cache-Management, verteilten Kommunikationsproblemen sowie Fehlern bei der Tool-Formatierung zu trennen. Zudem verhindert sie, dass ein angekündigtes maximales Kontext-Limit lediglich als ungeprüftes Produktversprechen bleibt.

Stellen Sie den Head-Node mittels Tokios bereit

Tokios erfordert 1 einen stabilen OpenAI-kompatiblen Endpunkt für das Upstream-Modell. In einem Cluster handelt es sich dabei um den Kopfknoten, nicht um alle Arbeitsknoten.
1

Der Modell-Server auf dem Head-Node muss privat bleiben.

Stellen Sie sicher, dass der Server-Prozess auf dem Loopback-/v1-Endpunkt des Head-Node antwortet, beispielsweise unter http://127.0.0.1:8000/v1. Der Datenverkehr zwischen den Worker-Knoten sollte ausschließlich über das Cluster-Netzwerk erfolgen.
2

Richten Sie den 1-Connector auf dem Head-Node ein.

Öffnen Sie im Tokios dashboard das Menü Setup und wählen Sie Start pairing aus. Installieren und starten Sie anschließend tokios-connector auf dem Head-Node. Der Connector initiiert ausgehende Verbindungen; ein eingehender Port ist nicht nötig.
3

Konfigurieren Sie das Upstream-Modell auf dem Head-Node.

Geben Sie als BaseUrl des Connectors den lokalen /v1-Endpunkt des Head-Node an. Das vollständige Konfigurationsformat finden Sie unter Connector-Konfiguration.
4

Registrieren Sie die öffentliche Deployment-Instanz.

Erstellen Sie im Models eine Deployment-Instanz, etwa unter dem Namen deepseek-v4-flash. Weisen Sie ihr die Upstream-Modell-ID zu, die Ihr Head-Node-Server bereitstellt. Clients nutzen dabei den Deployment-Namen, nicht die ID von Hugging Face.
5

Erstellen Sie einen bereichsbegrenzten API-Schlüssel.

Erstellen Sie einen sk-tok-…-Schlüssel in Keys, der nach Wunsch auf deepseek-v4-flash beschränkt wird. Anschließend rufen Clients https://api.tokios.com/v1 auf.
Verifiziert – Tokios-API-Anfrage. Hier wird nach erfolgreicher Initialisierung des lokalen Clusters der dokumentierte OpenAI-kompatible Endpunkt von Tokios überprüft.
Der Befehl prüft nicht, ob ein bestimmter DeepSeek-Cluster einwandfrei funktioniert; führen Sie zunächst die lokalen Tests durch.

Übersicht über die DeepSeek-Produktfamilie

Vergleichen Sie V4 Flash mit R1 Distills sowie der V3-Reihe.

Fernzugriff auf vLLM

Bewahren Sie einen vLLM /v1-Endpunkt geheim und greifen Sie darauf über Tokios zu.

DGX Spark

Richten Sie einen DGX Spark mithilfe eines Connectors ein und nutzen Sie ihn.

RTX-Workstation

Wählen und konfigurieren Sie eine lokale Inferenzmaschine auf Basis von RTX.