DeepSeek V4 Flash 0731 on DGX Station and a 2× DGX Spark cluster (vLLM)

DeepSeek released the official version of its Flash model on 31 July 2026: 284 billion total parameters, 13 billion active per token, one million tokens of context, mixed FP4 + FP8 weights, and a fused DSpark module. This article covers what is required to run it locally on a DGX Spark, a two-DGX-Spark cluster, and a DGX Station GB300, with vLLM 0.25 or higher.

By QDNA · Published on 2 August 2026 · Updated on 7 September 2026 · 11 min read

Updated on September 2, 2026: Same-day re-read: the published V4 Flash 0731 weights weigh 167 GB (48 files, Hugging Face API), not 83.4 GB, and V4 Pro 865 GB, not 470; the NGC tag and MiaAI-Lab throughputs are taken from the playbook and repository of the day; Mac Studio prices move to the M5 Ultra (apple.com/fr) and the unpublished MI300X price is removed; two claims attributed to NVIDIA without a source (Llama 405B warning, 189.85 Gb/s RoCE reading) are removed.

Name verification: V4 Flash 0731 is real

The name circulated in several professional channels before being confirmed. The official repository deepseek-ai/DeepSeek-V4-Flash-0731 has been on Hugging Face since 31 July 2026 at 07:30 UTC, and the deepseek-v4-flash API alias has pointed to it since the 1 August 2026 announcement on the DeepSeek site.

It is the official version of Flash, replacing the April 2026 preview and embedding the DSpark module, a speculative decoder fused into the same checkpoint. Reports of "R2" circulating in the specialised press do not correspond, as of today, to any official DeepSeek repository.

The current generalist landscape fits a tight timeline: V3.2 stable on 1 December 2025, V4 Preview (Flash + Pro) on 24 April 2026, V4 Flash 0731 on 31 July 2026. V4 Pro remains in preview and has not received a 0731 revision. This article is hardware-focused: V4 Flash 0731 is interesting because it is compact for its category (13 billion active over 284 billion), which opens the door to deployments on reasonable desktop hardware, provided you accept the total weight to load and monitor the KV cache in long contexts.

Verified model specifications

The official config.json of the 0731 repository describes a mixture of 256 routed experts plus one shared expert, six experts selected per token, forty-three layers, and a next-token prediction layer fed by DSpark. The announced maximum context reaches 1,048,576 tokens via a YaRN ×16 scaling applied to a native 64K window.

For high and max reasoning modes, DeepSeek recommends an output window of up to 384K tokens, and the official vLLM recipe requires at least 393,216 tokens of context for Think Max.

Weights are released in a mixed FP4 + FP8 format, where MoE experts are stored in FP4, the majority of other parameters in FP8 by 128×128 blocks, with dynamic activations and BF16 compute. The 0731 repository contains 48 safetensors shards for a total of 166.9 GB read through the Hugging Face API on 2 September 2026, i.e. 4.7 bits per parameter on average (166.9 × 8 / 284); the 2 August version gave 83.4 GB and 2.35 bits, half of that, a tensor-element count having been taken for a byte count. This is the basis to keep for memory sizing: 84 GB just for weights, before the KV cache, runtime buffers, and throughput headroom.

No community quantisation (GGUF, AWQ, GPTQ) is official for 0731; you must load the mixed safetensors as-is. DeepSeek does not publish a full BF16 checkpoint for this revision either. The associated technical report, DeepSeek V4: Towards Highly Efficient Million-Token Context Intelligence, is referenced as arXiv 2606.19348. Main innovations are the hybrid CSA + HCA attention (Compressed Sparse Attention then Heavily Compressed Attention), the mHC connections (Manifold-Constrained Hyper-Connections) and the Muon optimiser for training; declared efficiency at 1M context is 27% of V3.2 single-token inference FLOPs and 10% of V3.2 KV cache.

Official performance as published by DeepSeek

DeepSeek publishes mainly agentic benchmarks for the 0731 revision, and the values below are official but declarative; the model is evaluated at max effort, temperature 1, top_p 0.95 with a harness that was announced but not yet published at the time of the model card. Two DSBench suites remain internal.

The tone stays cautious: according to the benchmarks published by DeepSeek, and not "proven better".

Sober reading: 0731 beats Flash Preview and even Pro Preview on every test in this table, beats GLM 5.2, but stays generally behind Opus 4.8. For academic benchmarks (MMLU-Pro, GPQA, LiveCodeBench, SWE-bench), the values published by DeepSeek concern the V4 Preview family and are not systematically re-published for 0731: write "not published for 0731" rather than fabricate a number.

The hardware trio: DGX Spark, 2× Spark cluster, DGX Station

The DGX Spark is a 1.2 kg Arm64 mini-system built on the Grace Blackwell GB10 superchip, and it combines a 20-core Arm CPU (10× Cortex-X925 plus 10× Cortex-A725) and a Blackwell GPU, all in 128 GB of coherent LPDDR5X memory at 273 GB/s.

NVIDIA advertises up to 1 PFLOP FP4 with 2:1 sparsity, and StorageReview measures in real matrix 99.8 TFLOPS BF16 and 207.7 TFLOPS FP8 per MAMF matmul. The integrated ConnectX-7 network runs at 200 Gb/s, plus an RJ-45 10 GbE. SoC TDP is 140 W with a 240 W supply, the 4 TB self-encrypting NVMe M.2 SSD ships by default, and DGX OS, an Ubuntu arm64 distribution, is the official operating system.

To link two DGX Sparks a single QSFP cable is enough, with no switch required, and NVIDIA documents this direct link at full ConnectX-7 bandwidth, in RoCE/RDMA. vLLM then splits weights in tensor parallel 2 (TP=2), Ray launches a worker per Spark, and NCCL transports collectives over the ConnectX-7 link, but this is not NVLink between boxes: the theoretical 25 GB/s network bandwidth is almost eleven times narrower than the 273 GB/s of local memory and adds latency to each collective. NVIDIA rates up to four linked DGX Sparks for models up to 700 billion parameters (product page re-read on 2 September 2026); the 2 August version attributed to NVIDIA a warning about Llama 405B that the playbook does not contain.

DGX Station GB300 is another order of magnitude, and the final NVIDIA spec sheet is authoritative: 252 GB of HBM3e at 7.1 TB/s on the GPU side, plus 496 GB of LPDDR5X at 396 GB/s on the CPU side, all linked by NVLink-C2C at 900 GB/s for a coherent pool of 748 GB. Announced performance is 20 PFLOPS FP4 with sparsity, 10 PFLOPS FP8/FP6 with sparsity, 5 PFLOPS FP16/BF16 with sparsity, and 80 TFLOPS FP32. The ConnectX-8 SuperNIC scales to 800 Gb/s over two QSFP112 400 Gb/s ports. The machine supports 7 MIG instances and draws 1,600 W at system load. Watch out, though, because the March 2025 press release announced 784 GB while the current final spec sheet stands at 748 GB.

Hardware comparison table and budget

Before writing the ticket, the right reflex is to compare the DGX trio to the CUDA x86 (RTX 5090), Apple Silicon (Mac Studio M5 Ultra) and server accelerator (AMD MI300X) alternatives. The figures below are in EUR incl. and excl.

VAT for the DGX Spark (idealo.fr, 2 September 2026) and the Mac Studio (apple.com/fr, 2 September 2026), in USD or GBP ex-tax for the rest, public or observed 2026 prices; memory bandwidth is the decisive criterion during decoding, as detailed in our prefill/decode article.

A few words of buying advice are in order here. For over 32 GB and CUDA simplicity, a Spark works as long as the model fits in 128 GB under aggressive quantisation; it trades bandwidth for capacity and power frugality, while the 2× Spark cluster works for models that exceed a single Spark (Llama 3 70B BF16, V4 Flash 0731 via TP=2), but latency increases at each network collective. The RTX 5090 crushes decoding bandwidth (1,792 GB/s) but caps at 32 GB, which makes it a strong fit for compact models. Mac Studio M5 Ultra reaches 512 GB (option announced for late October 2026, price not published), but MLX/llama.cpp replaces vLLM CUDA and decoding throughput stays memory-bound. DGX Station targets enterprise production with BF16/HBM, MIG, and giant models.

Note: NVIDIA does not publish a firm worldwide MSRP for the Station; quotes going through the OEMs ASUS, Dell, Exxact, Gigabyte, HP, MSI and Supermicro. The reseller pi3g lists, on a page updated on 27 August 2026, €93,000 to €110,500 excl. VAT depending on the OEM, including the Exxact Valence configuration at €95,000 excl. VAT used in every calculation on the site; in the UK, the ASUS ExpertCenter Pro ET900N G3 is listed at £98,000 ex-VAT / £117,600 incl. VAT at Scan, and at $99,999 ex-VAT at SHI in the United States. Orders opened in 2026 with deliveries over the following months, and for France you should request an OEM quote and confirm availability, VAT, and delivery date.

Step-by-step vLLM recipe

The path recommended by NVIDIA is the NGC arm64 container (aarch64 SBSA variant), not an arbitrary pip install vllm on the host: the GB10 is an sm_121/121a GPU and standard CUDA x86_64 wheels do not target this architecture. DeepSeek V4 Flash 0731 requires vLLM 0.25.0 minimum, because of the DSpark module fused into the checkpoint.

The NGC tag of the month (NGC vLLM catalogue) varies; check the latest stable revision before deployment.

1× DGX Spark: OpenAI-compatible local API

Spark 1 exposes the vLLM API, and the Hugging Face cache must be mounted to avoid re-downloading the 167 GB on every restart.

docker run --rm -it \
  --gpus all --network host \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
    --trust-remote-code \
    --kv-cache-dtype fp8 \
    --block-size 256 \
    --enable-expert-parallel \
    --moe-backend deep_gemm_mega_moe \
    --attention-config '{"use_fp4_indexer_cache": true}' \
    --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

A few practical points are worth noting here, starting with the flags. The --kv-cache-dtype fp8 flag halves the KV cache footprint, which is critical at long context. --attention-config use_fp4_indexer_cache activates the FP4 indexer cache specific to the hybrid CSA + HCA attention. --speculative-config enables DSpark without a separate draft model, since the weights are fused. No manual --rope-scaling is needed, since YaRN ×16 is already written into config.json. For sampling, DeepSeek recommends temperature 1 and top_p 0.95 in agentic mode, top_p 1 outside the agentic scenario.

2× DGX Spark cluster: tensor parallel via Ray

Spark 1 starts the Ray head and exposes the API while Spark 2 joins the cluster as a Ray worker, the same NGC container running on both nodes. The Hugging Face cache must be present (or mounted via NFS) on both machines to avoid a re-download and ensure safetensors shards are identical.

# Spark 1 (head)
ray start --head --port=6379
docker run --rm -it --gpus all --network host \
  --add-host=spark2:<SPARK_2_IP> \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
    --trust-remote-code \
    --tensor-parallel-size 2 \
    --distributed-executor-backend ray \
    --kv-cache-dtype fp8 \
    --block-size 256 \
    --enable-expert-parallel \
    --moe-backend deep_gemm_mega_moe \
    --attention-config '{"use_fp4_indexer_cache": true}' \
    --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

# Spark 2 (worker)
ray start --address='spark1:6379'

Before launching vLLM, verify the RoCE fabric on both nodes with ib_write_bw and nccl-tests. If NCCL falls back to RJ-45/TCP instead of QSFP/RDMA, performance collapses, with a 10–20× penalty observed, and the smoke test becomes mandatory: a 200 Gb/s LinkX Berkeley cable must climb around 190 Gb/s actual.

DGX Station GB300: simple single-GPU variant

The Station behaves like a standard Blackwell server, so the same command works by removing tensor parallel and tuning the context window as needed:

docker run --rm -it --gpus all --network host \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
    --trust-remote-code \
    --tensor-parallel-size 1 \
    --kv-cache-dtype fp8 \
    --block-size 256 \
    --enable-expert-parallel \
    --moe-backend deep_gemm_mega_moe \
    --attention-config '{"use_fp4_indexer_cache": true}' \
    --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

On the Station, the 252 GB of HBM3e running at 7.1 TB/s accommodate the 167 GB of weights in HBM, leaving the full GPU bandwidth available for decoding, which makes it the preferred target to serve V4 Flash 0731 without quantisation compromises.

Real tokens/s benchmarks

A tok/s figure is comparable only when model, quantisation, input and output lengths, concurrency and engine are identical, and the figures below are aggregated output tokens unless noted, so C128 should not be confused with 924 tok/s per user.

DeepSeek's official docs publish no single tok/s number for V4 Flash 0731 : throughput strongly depends on hardware, batching, prefill length, and DSpark.

Reading. On a single Spark, decoding is capped by the 273 GB/s of LPDDR5X bandwidth. This is consistent: autoregressive decoding re-reads weights at each token and becomes memory-bound. Moving to two Sparks in TP=2 degrades per-user latency (each token crosses the QSFP) but unlocks models that do not fit on a single machine and lets you parallelise multiple streams. The MiaAI-Lab recipe shows that a heavily patched 2× Spark setup reaches 95.9 tok/s median C1 and 340.5 tok/s aggregated C6 on V4 Flash 0731, with MTP_NUM_TOKENS=6 and the nvfp4_ds_mla KV cache. DGX Station, with its 7.1 TB/s of HBM3e, takes over when latency matters and the budget allows.

ARM64 and unified memory gotchas

DGX Spark and DGX Station share memory between CPU and GPU. This is not classic CPU offload as on an RTX, since CUDA addresses the unified pool, but 128 GB on a Spark is never 128 GB fully available to weights: DGX OS, page cache, Ray, Python, CUDA graphs, activations, and KV cache all use the same pool.

Several gotchas have been observed, each with its fix. First, nvidia-smi --query-gpu=memory.* may return N/A on unified memory, and NVIDIA recommends using raw nvidia-smi instead. Second, vLLM still reasons in "GPU memory utilization" budget, and UMA dynamic allocation can trigger OOM even when the weight size is apparently below 128 GB. a community recipe advises against this loader when weights approach the available memory. Fourth, Ray has been removed from some NGC images as a default dependency and must be installed in the container, a patch that the NVIDIA playbook documents.

The network fabric between two Sparks is the other sensitive point. Wrong interface, wrong HCA, or libnccl.so conflicts can stall loading or force TCP instead of RoCE/RDMA. The ib_write_bw test must approach the 200 Gb/s nominal; the 2 August version quoted "92.57 + 97.28 = 189.85 Gb/s" as an official reading, figures the NVIDIA playbook does not contain. If this is not the case, do not start vLLM: fix the HCA, IP, or MTU first. On the quantisation side, AWQ, Marlin, NVFP4, MXFP4, FlashInfer, and DeepGEMM did not all get sm_121 support at the same time; prefer the models explicitly listed in the playbook and the matching NGC image. On memory, NVIDIA recommends for troubleshooting to clear the buffer cache (sync; echo 3 | sudo tee /proc/sys/vm/drop_caches) and reduce context or number of sequences.

Conclusion: sovereignty, cost and break-even

DeepSeek V4 Flash 0731 closes the loop on local availability of a 284-billion MoE at the agentic frontier. Its 167 GB mixed FP4 + FP8 format makes the hardware target credible, whether a 2× DGX Spark cluster at €9,750 excl. VAT or a DGX Station GB300 at €95,000 excl.

VAT (pi3g, 27 August 2026), and vLLM 0.25+ with DSpark and the hybrid CSA + HCA attention makes execution actually supported. The NVIDIA NGC arm64 containers and the official playbook lift the main technical traps.

The right trade-off follows the business question, so for prototyping or single-workstation use on a compact model, a single DGX Spark is enough and remains the cheapest way in. To serve V4 Flash 0731 to several users on a contained budget, the 2× Spark cluster works but the 200 Gb/s link quickly becomes the bottleneck, at which point the Station takes over with its 7.1 TB/s of HBM3e. For agentic loads, the local KV cache makes repeated prefixes near-free, an economy that pay-per-token billing cannot match. Sovereignty forces local as soon as data is sensitive, regardless of cost, and that is the argument that tips the decision even when the cloud API looks cheaper in the moment. Our on-premises vs API analysis details the break-even calculation.

References

• DeepSeek V4 Flash 0731 : official Hugging Face repository
• DeepSeek documentation: the deepseek-v4-flash API alias serves model version DeepSeek-V4-Flash-0731
• DeepSeek V4 technical report : Towards Highly Efficient Million-Token Context Intelligence (arXiv 2606.19348)
• Official vLLM recipe : DeepSeek V4 Flash
• NVIDIA DGX Spark : product page and specifications
• NVIDIA DGX Station : final specifications
• NVIDIA DGX Spark Playbooks : official vLLM
• NVIDIA DGX Spark Playbooks : connect two Sparks
• StorageReview : DGX Spark review and real vLLM benchmarks
• MiaAI-Lab : DeepSeek V4 Flash on 2× DGX Spark recipe (scripts and artefacts)
• tonyd2wild : simpler 2× Spark recipe for V4 Flash
• VideoCardz : ASUS ExpertCenter Pro ET900N G3 pricing (DGX Station, UK)