nvidia/DeepSeek-V4-Pro-0813-nvfp4-DSpark

Model Overview

Description:

The NVIDIA DeepSeek-V4-Pro-0813-nvfp4-DSpark model is the fully NVFP4-quantized version of DeepSeek AI's DeepSeek-V4-Pro-0813 model, an autoregressive Mixture-of-Experts language model that uses an optimized Transformer architecture with hybrid attention (Compressed Sparse Attention and Heavily Compressed Attention) and Manifold-Constrained Hyper-Connections. DeepSeek-V4-Pro-0813 is the official DeepSeek-V4-Pro release with enhanced agentic capabilities, and includes DeepSeek's DSpark speculative decoding module in the same checkpoint. For more information, refer to the DeepSeek-V4-Pro-0813 model card. The NVIDIA DeepSeek-V4-Pro-0813-nvfp4-DSpark model is quantized with Model Optimizer.

Note: DeepSeek-V4-Pro-0813-nvfp4-DSpark is not a new model. It is nvidia/DeepSeek-V4-Pro-0813-NVFP4 with the DSpark draft head quantized as well: that release leaves the draft head in its source MXFP4 format, so target and draft carry different expert formats in one checkpoint. Here the draft experts are losslessly cast to NVFP4 so a single, self-consistent checkpoint serves as both target and draft model. The backbone weights are bit-identical to the NVFP4 release.

This model is ready for commercial or non-commercial use.

Third-Party Community Consideration

This model is not owned or developed by NVIDIA. This model has been developed and built to a third-party’s requirements for this application and use case; see link to Non-NVIDIA (DeepSeek-V4-Pro-0813) Model Card.

License/Terms of Use:

MIT

Deployment Geography:

Global

Use Case:

DeepSeek V4 is well-suited for advanced reasoning, agentic AI applications, tool use scenarios, and complex problem-solving in domains such as mathematics, software engineering, and enterprise AI assistants.

Release Date:

Hugging Face 09/09/2026 via https://huggingface.co/nvidia/DeepSeek-V4-Pro-0813-nvfp4-DSpark

References

Nvidia Model Optimizer: https://github.com/NVIDIA/Model-Optimizer

Model Architecture:

Architecture Type: Transformers
Network Architecture: DeepseekV4ForCausalLM — Mixture-of-Experts (MoE) with Hybrid Attention (Compressed Sparse Attention + Heavily Compressed Attention)
Number of Model Parameters: 1.65T in total and 49B activated
This model was developed based on DeepSeek-V4-Pro-0813

Input:

Input Type(s): Text
Input Format(s): String
Input Parameters: One-Dimensional (1D): Sequences
Other Properties Related to Input: Supports multi-turn conversations with system prompts, user messages, and assistant responses. Maximum context length of 1 million tokens. Uses a custom encoding pipeline (encoding_dsv4) with reasoning effort levels (low, high, max).

Output:

Output Type(s): Text
Output Format: String
Output Parameters: One-Dimensional (1D): Sequences
Other Properties Related to Output: Supports structured JSON output, function/tool calling, and reasoning content when enabled.

Our AI models are designed and/or optimized to run on NVIDIA GPU-accelerated systems. By leveraging NVIDIA’s hardware (e.g. GPU cores) and software frameworks (e.g., CUDA libraries), the model achieves faster training and inference times compared to CPU-only solutions.

Software Integration:

Supported Runtime Engine(s):

• SGLang
  
• vLLM
  

Supported Hardware Microarchitecture Compatibility:

• NVIDIA Blackwell B200
  

Preferred Operating System(s):

• Linux
  

The integration of foundation and fine-tuned models into AI systems requires additional testing using use-case-specific data to ensure safe and effective deployment. Following the V-model methodology, iterative testing and validation at both unit and system levels are essential to mitigate risks, meet technical and functional requirements, and ensure compliance with safety and ethical standards before deployment.

Model Version(s):

The model is DeepSeek-V4-Pro-0813 NVFP4 quantized with nvidia-modelopt v0.47.0rc1, with the DSpark draft head additionally cast from MXFP4 to NVFP4

Training and Evaluation Datasets:

Calibration Dataset:

Link: cnn_dailymail, Nemotron-Post-Training-Dataset-v2
Data Collection Method by dataset: Automated.
Labeling Method by dataset: Automated.
Properties: The cnn_dailymail dataset is an English-language dataset containing just over 300k unique news articles as written by journalists at CNN and the Daily Mail. The Nemotron-Post-Training-Dataset-v2 is a post-training dataset curated by NVIDIA containing multi-turn conversations across diverse topics.

Training Dataset:

Data Modality: Undisclosed
Data Collection Method by dataset: Undisclosed
Labeling Method by dataset: Undisclosed
Properties: Undisclosed

Evaluation Dataset:

Datasets: GPQA Diamond, AA-LCR, τ²-Bench Telecom, SciCode, IFBench, Terminal-Bench Hard; MT-Bench, SPEED-Bench (speculative decoding acceptance)
Data Collection Method by dataset: Hybrid: Automated, Manually-Collected
Labeling Method by dataset: Hybrid: Manually-Labeled, Automated
Properties: We evaluated the model on reasoning, long-context recall, agentic tool-use, coding, and instruction-following benchmarks: GPQA Diamond contains 448 graduate-level multiple-choice questions written by domain experts in biology, physics, and chemistry. AA-LCR (Artificial Analysis Long Context Recall) evaluates a model's ability to accurately retrieve and recall information from long input contexts. τ²-Bench Telecom evaluates agentic tool-use and policy-adherence capabilities in dual-control telecom customer-service scenarios where the model interacts with a simulated user and external tools to resolve account issues. SciCode evaluates scientific coding capabilities. IFBench is a benchmark for evaluating instruction-following capabilities across diverse and structured task constraints. Terminal-Bench Hard evaluates agentic software-engineering capability in a real terminal environment, where the model must plan and execute shell commands to complete tasks end to end.

Inference:

Acceleration Engine: SGLang (accuracy benchmarks), vLLM (speculative decoding benchmarks)
Test Hardware: NVIDIA Blackwell B200 (accuracy), NVIDIA Blackwell B300 (speculative decoding)

DSpark Speculative Decoding

This model is ready for inference with vLLM in DSpark speculative decoding mode, where a semi-autoregressive draft backbone proposes a block of candidate tokens, a lightweight Markov head injects intra-block token dependency, and a confidence head predicts per-position acceptance probability for scheduled verification. Compared with a purely parallel drafter, DSpark is designed to improve accepted length while preserving the latency benefits of block drafting. The longest accepted candidate sequence is selected so that more than one token is returned per generation step; the average number of tokens returned per step is reported below as the acceptance length.

The DSpark draft head in this checkpoint is the one DeepSeek ships inside deepseek-ai/DeepSeek-V4-Pro-0813 — the 0813 release folds DSpark into the base checkpoint, so there is no separate -DSpark repository. It was not trained by NVIDIA and no additional draft training or distillation was performed; NVIDIA's contribution is the quantization and packaging. For more details on DSpark, refer to: https://github.com/deepseek-ai/DeepSpec

Post Training Quantization

This model was obtained by quantizing the weights and activations of DeepSeek-V4-Pro-0813 to NVFP4 data type, ready for inference with SGLang and vLLM. Only the weights and activations of the linear operators within transformer blocks in MoE are quantized. Unlike nvidia/DeepSeek-V4-Pro-0813-NVFP4, which carries DeepSeek's DSpark speculative-decoding heads through unquantized, this checkpoint also casts the routed experts of the three DSpark draft layers from their native MXFP4 to NVFP4. The cast is bit-exact (100.0000% of blocks lossless), so target and draft share one self-consistent quantization config.

Quantization Recipe

The recipe is in the Model Optimizer repository under examples/deepseek/deepseek_v4 (ptq.py, quantize_to_nvfp4.py). It runs in three stages:

1. Reshard the source checkpoint to the model-parallel layout (CPU only), using DeepSeek's own convert.py:

python convert.py \
    --hf-ckpt-path  <DeepSeek-V4-Pro-0813> \
    --save-path     <mp8_checkpoint> \
    --n-experts     384 \
    --model-parallel 8 \
    --expert-dtype  fp4

2. Collect activation ranges (amax) on the routed experts:

torchrun --nproc-per-node 8 deepseek_v4/ptq.py \
    --model_path  <mp8_checkpoint> \
    --config      <DeepSeek-V4-Pro-0813>/inference/config.json \
    --calib_size  512 \
    --calib_seq   4096 \
    --output_path <amax_dump>

Calibration uses the script's default datasets — cnn_dailymail and Nemotron-Post-Training-Dataset-v2 — at 512 samples each (1024 total). --calib_seq 4096 sets the tokenizer truncation cap; it is the setting that mattered most for this model, since the default of 512 does not cover long-context activation ranges.

The command above uses ptq.py's built-in quantization config. The same config also ships as a declarative recipe, selectable with --recipe:

torchrun --nproc-per-node 8 deepseek_v4/ptq.py \
    --recipe models/deepseek-ai/DeepSeek-V4-Pro-0813/ptq/nvfp4_experts_only \
    ...

The recipe YAML is pinned by a test to match the built-in default, so either path yields the same quantizer configuration.

3. Export the NVFP4 checkpoint:

python deepseek_v4/quantize_to_nvfp4.py \
    --amax_path   <amax_dump> \
    --source_ckpt <DeepSeek-V4-Pro-0813> \
    --output_ckpt <output> \
    --cast_mxfp4_to_nvfp4 \
    --device cuda

--cast_mxfp4_to_nvfp4 matters for this model in particular. DeepSeek-V4 already ships its routed experts in MXFP4 (E2M1 nibbles with one E8M0 scale per 32 elements). NVFP4 reuses the same E2M1 nibble grid but stores an E4M3 scale per 16 elements, so the weight bits are carried over unchanged — a lossless bit-cast — and only the block scales are rewritten. The activation amax from stage 2 is therefore the only calibrated quantity that survives into the artifact, and the checkpoint is slightly larger than its source (scale bytes double while weight bytes stay the same).

Usage

Deploy with SGLang

python3 -m sglang.launch_server \
    --model-path nvidia/DeepSeek-V4-Pro-0813-nvfp4-DSpark \
    --tp 8 \
    --trust-remote-code \
    --tool-call-parser deepseekv4 \
    --reasoning-parser deepseek-v4

Speculative decoding was validated on vLLM (see below); it was not exercised on SGLang for this checkpoint.

Deploy with vLLM

Serving this checkpoint requires a vLLM build that provides both the NVFP4 MoE backend and DSpark speculative decoding. The speculative-decoding results below were produced on a vLLM nightly build (2026-07-18); they have not been re-verified against a tagged release, so no exact version floor is claimed here.

vllm serve nvidia/DeepSeek-V4-Pro-0813-nvfp4-DSpark \
    --served-model-name DeepSeek-V4-Pro-0813-nvfp4-DSpark \
    --tensor-parallel-size 8 \
    --enable-expert-parallel \
    --reasoning-parser deepseek_v4 \
    --max-model-len 400000 \
    --gpu-memory-utilization 0.9 \
    --kv-cache-dtype fp8 \
    --max-num-batched-tokens 8192 \
    --enable-chunked-prefill \
    --model-loader-extra-config '{"enable_multithread_load": true, "num_threads": 128}' \
    --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

Drop --speculative-config to serve without speculative decoding. num_speculative_tokens must be at least dspark_block_size (5); the value of 7 follows DeepSeek's guidance for DeepSeek-V4-Pro-0813 and is what the acceptance-length table below was measured with. DeepSeek-V4 ships no Jinja chat template (it uses encoding/encoding_dsv4.py); a chat_template.jinja for chat / non-thinking mode is included in this repository, validated character-exact against this release's encoder.

The acceptance-length numbers below were measured with CUDA graphs disabled (--enforce-eager). On the build used for those runs, DSpark with CUDA graphs enabled failed at startup inside FlashMLA while building a TMA descriptor; add --enforce-eager if you hit that.

vLLM selects the NVFP4 MoE backend automatically; no backend environment variables are required. --model-loader-extra-config parallelises the checkpoint load, which otherwise dominates startup for a checkpoint this size. Tune --max-num-seqs to your own concurrency — it is a throughput knob and does not affect output.

An equivalent serving configuration was validated on 8xB200 (TP=8) with vllm/vllm-openai:v0.27.1 and v0.28.0 against nvidia/DeepSeek-V4-Pro-0813-NVFP4, running a full long-context evaluation (~115K-token prompts, ~128K total) with no errors. That run was contributed by NVIDIA ModelOpt QA and was performed on the NVFP4 release, not on this checkpoint; it is reported here because the backbone weights are bit-identical and only the DSpark draft head differs. It did not exercise speculative decoding.

Evaluation

The backbone weights of this checkpoint are bit-identical to nvidia/DeepSeek-V4-Pro-0813-NVFP4; only the DSpark draft head differs. Speculative decoding is verified against the target model and does not change its outputs, so the accuracy results measured for that checkpoint carry over and are reproduced below:

Precision	GPQA Diamond	AA-LCR	τ²-Bench Telecom	SciCode	IFBench	Terminal-Bench Hard
MXFP4 (source)	88.51	68.67	96.49	53.45	76.53	51.39
NVFP4	88.42	69.33	98.25	53.75	75.68	50.69

Baseline: DeepSeek-V4-Pro-0813, whose routed experts already ship in MXFP4. Both checkpoints are mixed precision and share the same FP8 attention and shared-expert projections, BF16 norms and embeddings; only the routed-expert format differs (MXFP4 → NVFP4). All scores measured on SGLang at temperature 1.0, top_p 1.0, max reasoning effort. GPQA Diamond, SciCode, τ²-Bench Telecom and Terminal-Bench Hard are single-run; IFBench is pooled over 4 runs per side; AA-LCR is the matched-configuration pair (2 runs per side).

Speculative Decoding Evaluation

Acceptance length is the average number of tokens returned per decoding step (1.0 means no speculation benefit). Measured on vLLM with this single checkpoint serving as both target and drafter, at temperature 0 in chat (non-thinking) mode, num_speculative_tokens=7, tensor-parallel 8 with expert parallelism, FP8 KV cache, CUDA graphs disabled (--enforce-eager), on a single 8xB300 node.

MT-Bench

Measured on MT-Bench.

Category	Acceptance Length
coding	5.366
math	5.479
extraction	4.823
reasoning	3.573
stem	3.037
writing	2.825
humanities	2.767
roleplay	2.488
Overall Average	3.795

SPEED-Bench is reported on two different splits, tabulated separately below. The qualitative split is everyday short- to medium-length prompts spanning eleven domains (coding, humanities, math, multilingual, QA, RAG, reasoning, roleplay, STEM, summarization, writing). The throughput-32k split is long-context prompts of roughly 32K tokens, grouped into low_entropy, mixed and high_entropy buckets. The two are not comparable to each other; each is its own workload.

SPEED-Bench — qualitative split

Category	Acceptance Length
coding	5.430
humanities	3.231
math	4.580
multilingual	4.165
qa	3.023
rag	3.853
reasoning	3.857
roleplay	2.211
stem	3.739
summarization	3.249
writing	2.912
Overall Average	3.659

SPEED-Bench — throughput-32k split (long context)

Category	Acceptance Length
low_entropy	4.613
mixed	4.388
high_entropy	2.693
Overall Average	3.898

Model Limitations:

The base model was trained on data that contains toxic language and societal biases originally crawled from the internet. Therefore, the model may amplify those biases and return toxic responses especially when prompted with toxic prompts. The model may generate answers that may be inaccurate, omit key information, or include irrelevant or redundant text producing socially unacceptable or undesirable text, even if the prompt itself does not include anything explicitly offensive.

Ethical Considerations

NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. Developers should work with their internal model team to ensure this model meets requirements for the relevant industry and use case and addresses unforeseen product misuse.

Users are responsible for model inputs and outputs. Users are responsible for ensuring safe integration of this model, including implementing guardrails as well as other safety mechanisms, prior to deployment.

Please report model quality, risk, security vulnerabilities or NVIDIA AI Concerns here.