# Day 1 Deployment of DeepSeek-V4-Pro-0813: 17,000 tok/s on Real Traffic, and the Top of a Three-Way Race [B300 x8 Benchmark]

> Source: <https://blog.us.fixstars.com/deepseek-v4-pro-0813-day1-b300-benchmark/>
> Published: 2026-08-17 16:36:11+00:00

At 21:30 JST on August 13, 2026, DeepSeek published the model weights for [DeepSeek-V4-Pro-0813](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-0813), the GA release of V4-Pro. It arrives about four months after the Preview build went up in April.

At Fixstars this is the third installment of our Day 1 deployment series, following [Kimi-K3](https://blog.us.fixstars.com/deploying-kimi-k3-on-day-0-can-a-2-8t-model-run-on-a-single-node-of-nvidia-b300-x8/) and [Qwen3.8-2.4T-A95B](https://blog.us.fixstars.com/day-1-with-qwen3-8-2-4t-a95b-twice-kimi-k3s-throughput-on-one-8x-b300-node/). The day after release we deployed it to a single-node NVIDIA B300 x8 machine and ran the same benchmarks under the same conditions. (In this series, “Day 1 deployment” means we finished the work within 24 hours of release. The weights went up at 21:30 on the 13th, and we had deployment and benchmarking done before the 14th was out.) It is the first time all three of these enormous open-weight models have been in the same room, on the same hardware, under the same load.

To spoil the ending: **17,478 tok/s** throughput on our real coding-agent dataset. That is roughly **1.9x Qwen3.8**, the model we described last time as flat-out fast.

## What DeepSeek-V4-Pro is

DeepSeek-V4-Pro is DeepSeek’s flagship MoE model. The headline specs:

| Item | Spec |
|---|---|
| Total parameters | 1.6T |
| Active parameters | 49B |
| Architecture | MoE + hybrid attention (CSA / HCA, an evolution of DSA) |
| Precision of published weights | Mixed MXFP4 + FP8 (measured footprint approx. 0.88TB) |
| Context length | 1M tokens (max output 384K) |
| Multimodal | No (text only) |
| Speculative decoding | DSpark draft bundled in the checkpoint |
| Inference modes | Hybrid: non-thinking / high / max |
| License | MIT |

Architecturally, the interesting part is the pairing of **Compressed Sparse Attention (CSA)** and **Heavily Compressed Attention (HCA)**, both developments of DeepSeek Sparse Attention (DSA). Per-token compression and sparsification cut compute and memory dramatically at long context, and as you will see below, the effect on KV cache capacity is dramatic.

Of the three models in this series, V4-Pro is the smallest on both total (1.6T) and active (49B) parameters. For reference, at the time of writing the Artificial Analysis Intelligence Index puts V4-Pro at 53, short of Kimi-K3 (60) and Qwen3.8 (58). Modest on intelligence benchmarks, but a design that goes all in on inference efficiency. How that plays out under load is what we are here to find out.

One more thing worth flagging: Kimi-K3 (native vision via MoonViT-V2) and Qwen3.8 (text, image, and video input) are both multimodal. V4-Pro is text only. If your use case involves images, it is off the list from the start, and that is a clear weakness to keep in mind.

License matters too. Kimi-K3 and Qwen3.8 both ship under bespoke licenses (the Kimi K3 License and the Qwen3.8-Max License respectively); V4-Pro is plain MIT. If your bar is getting legal to sign off on commercial use, it is the easiest of the three by some margin.

## Test environment

| Item | Detail |
|---|---|
| GPU | NVIDIA B300 SXM6 x8 (single node) |
| GPU memory | 275.04 GB x8 (as reported by nvidia-smi) |
| Inference engine | SGLang v0.5.17 (lmsysorg/sglang:latest image) |
| Parallelism | TP=8 |
| Speculative decoding | DSPARK (draft bundled in the checkpoint) |
| KV cache | FP8 (e4m3) |

## A dress rehearsal on the Preview weights

This Day 1 had something the previous two did not. V4-Pro’s [Preview weights (with DSpark bundled)](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark) had been public since April, so the day before the official release we were able to run the entire deployment-and-benchmark pass against Preview.

The 0813 GA release ships config files identical to Preview’s; only the weights changed. So once the official weights landed, swapping `--model-path`

and restarting was all it took to go straight to measurement on an already-validated setup. Publishing a Preview early and then updating only the weights at GA is a wonderful pattern if you are the one doing the Day 1 deploy.

…or so we thought while the download was running. It did not go that smoothly. More on that below.

One note: the [SGLang cookbook’s DeepSeek-V4 page](https://docs.sglang.io/cookbook/autoregressive/DeepSeek/DeepSeek-V4) does not document how to launch the DSpark-bundled build, so we assembled the options by feel. They worked on the first try.

## Memory footprint: room to spare this time

The previous two rounds were both about how to cram 2TB-class weights into a 2.2TB node. Not this time. V4-Pro’s published weights are mixed precision, MXFP4 for the MoE layers and FP8 for everything else, and the measured footprint is 104.27GB for the model plus 5.88GB for the DSpark draft per GPU, about **0.88TB** across all eight. That is under 60% of Kimi-K3 (1.57TB) or Qwen3.8 (1.48TB), and it fits on B300 x8 with plenty of headroom.

Like Kimi-K3, it is a native low-precision release, so there is no extra quantization step and no dependence on third-party quantized weights. And every gigabyte we do not spend on weights goes straight to KV cache.

## Deployment

### The snag: the weights were broken at release

We started downloading the weights (about 893GB) right after the 21:30 release and finished in roughly 30 minutes. Launching with our validated config, every rank threw an exception and crashed just before weight loading completed.

```
KeyError: 'model.layers.0.self_attn.compressor.wkv_gate.weight'
```

A weight key the model config expects was not present in the checkpoint. In other words, the freshly published weight files themselves were broken, missing tensors. Since the config was already proven against Preview, this was not on our side.

A few hours later [a large fix commit](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-0813/commit/09d796d25191dd7579987f5c76c1bae6e86dbedc) landed in the Hugging Face repo and the weights were replaced. After a re-download (about 19 minutes) everything loaded cleanly, and all the results below use the fixed weights.

Even with a dress rehearsal on Preview, the actual release artifact can still be broken. No matter how much you prepare, something happens on the day. That is Day 1 deployment. We got lucky that the weights are small (about 0.9TB) and the re-download only cost 19 minutes; on a 2TB-class model that alone would have burned hours.

### Launch command

```
docker run --gpus all \
--shm-size 32g \
-p 30000:30000 \
-v ${HF_HOME}:/root/.cache/huggingface \
--ipc=host \
lmsysorg/sglang:latest \
sglang serve \
--trust-remote-code \
--model-path deepseek-ai/DeepSeek-V4-Pro-0813 \
--tp 8 \
--moe-runner-backend flashinfer_mxfp4 \
--speculative-algorithm DSPARK \
--chunked-prefill-size 8192 \
--disable-flashinfer-autotune \
--swa-full-tokens-ratio 0.1 \
--mem-fraction-static 0.90 \
--host 0.0.0.0 \
--port 30000 \
--reasoning-parser deepseek-v4 \
--tool-call-parser deepseekv4 \
--enable-metrics --enable-cache-report --enable-mfu-metrics --enable-return-routed-experts
```

The DSpark draft is bundled in the checkpoint, so there is no need to pass a draft model path; SGLang picks it up from the same `--model-path`

automatically. The metrics flags at the end are new as of this round. Last time we forgot them and ended up with nothing but benchmark-side logs. Server-side cache hit rate and MFU are genuinely useful for this kind of work, so turn them on from the start.

### Startup time: about 30 minutes, the fastest in the series

Total time to a serving endpoint was about 29.5 minutes, of which weight loading accounted for roughly 19.1 minutes for the model and 2.3 minutes for the DSpark draft. Against Kimi-K3’s ~89 minutes and Qwen3.8’s ~65 minutes that is a large cut, and it comes straight from the smaller weights (about 0.88TB). When you are iterating on tuning options, a restart you do not dread makes a real difference.

### GPU memory breakdown and KV cache

Memory after startup (per rank, TP0 as representative):

| Item | Size (GB) | Notes |
|---|---|---|
| Total GPU memory | 275.04 | B300 SXM6 |
| Model weights (main) | 104.27 | DeepseekV4ForCausalLM, mixed MXFP4 + FP8 |
| Model weights (DSpark draft) | 5.88 | DeepseekV4ForCausalLMDSpark |
| KV cache and assorted pools | approx. 128.7 | FP8 (e4m3), 13.1KB per token in full-attention terms |
| Everything else (CUDA graph / NCCL / context, etc.) | remainder |

Reflecting the CSA / HCA hybrid, the cache is split across several pools:

| Pool | Capacity | Purpose |
|---|---|---|
| full | 9,890,048 tokens | Equivalent to ordinary attention. The headline context-capacity figure |
| SWA | 988,928 tokens | Sliding-window portion |
| Compressed cache (c4 / c128) | 2,472,512 / 77,266 | For compressed attention |

Effective context capacity works out to about **9.89M tokens**, roughly 19x what we had with Kimi-K3 (about 0.53M) and about 6.4x Qwen3.8 (about 1.54M). That is nine concurrent 1M-context requests. The combined effect of compressed attention, FP8 KV, and small weights shows up plainly in the numbers.

## Benchmark results

Same two workloads as before, measuring throughput and latency.

### Internal coding-agent dataset (max-duration 300, multi-turn)

| Concurrency | Success | Fail | out_tput (tok/s) | total_tput (tok/s) | TTFT med (ms) | ITL med (ms) |
|---|---|---|---|---|---|---|
| 1 | 51 | 0 | 405.5 | 2,584.5 | 255 | 12.1 |
| 2 | 98 | 0 | 691.1 | 4,476.8 | 261 | 13.2 |
| 4 | 166 | 0 | 971.2 | 7,955.0 | 267 | 15.6 |
| 10 | 296 | 0 | 1,694.5 | 12,250.4 | 273 | 21.1 |
| 20 | 415 | 0 | 2,302.7 | 15,488.8 | 280 | 25.8 |
| 30 | 477 | 0 | 2,436.5 | 15,049.1 | 296 | 32.2 |
| 40 | 550 | 0 | 2,820.0 | 16,875.4 | 297 | 35.7 |
| 50 | 591 | 0 | 3,016.4 | 17,477.9 | 312 | 40.2 |

### Random (ISL=8K, OSL=1K, num-prompts 200)

| Concurrency | Success | Fail | out_tput (tok/s) | total_tput (tok/s) | TTFT med (ms) | ITL med (ms) |
|---|---|---|---|---|---|---|
| 10 | 200 | 0 | 678.8 | 6,109.0 | 530 | 21.0 |
| 20 | 200 | 0 | 938.9 | 8,449.8 | 544 | 26.0 |
| 30 | 200 | 0 | 1,024.4 | 9,220.0 | 563 | 32.4 |
| 40 | 200 | 0 | 1,130.0 | 10,169.7 | 573 | 35.9 |
| 50 | 200 | 0 | 1,201.1 | 10,809.5 | 513 | 40.7 |

### Throughput scaling

Left: total throughput on the real dataset. Right: Random. Measured figures for Kimi-K3 and Qwen3.8 on the same hardware under the same load are plotted alongside. On real data V4-Pro is fastest throughout; on Random it is roughly level with Qwen3.8.

### Preview vs. GA: +88% from a weight update alone

Here is the comparison against the Preview build (DeepSeek-V4-Pro-DSpark) we measured the day before. Configuration identical; the only difference is the weights.

| Concurrency (real data) | Preview total (tok/s) | 0813 total (tok/s) | Delta |
|---|---|---|---|
| 10 | 11,351.8 | 12,250.4 | +7.9% |
| 20 | 9,955.1 | 15,488.8 | +55.6% |
| 30 | 10,620.5 | 15,049.1 | +41.7% |
| 40 | 14,926.8 | 16,875.4 | +13.1% |
| 50 | 9,318.3 | 17,477.9 | +87.6% |

Up to +88% in the high-concurrency region of the real-data workload. The odd dip at concurrency 40 we saw on Preview is gone, and from concurrency 20 upward the curve is close to monotonic. Random, meanwhile, came in about 3.6% below Preview, which is to say essentially unchanged. No difference on synthetic load, a large gain on real data. The “substantially improved agentic performance” the model card advertises turns out to be visible from the throughput side as well, as a shift in the output distribution from post-training (including a better accept rate for the DSpark draft).

### Bonus experiment: what happens if you bolt DSpark onto Qwen3.8?

If part of DeepSeek’s speed comes from speculative decoding via the bundled DSpark, then adding a DSpark draft ([RadixArk/Qwen3.8-2.4T-A95B-DSpark](https://huggingface.co/RadixArk/Qwen3.8-2.4T-A95B-DSpark)) to Qwen3.8 ought to make it faster too. Right? We measured it. It made things worse.

| Workload | Change in total tput with DSpark |
|---|---|
| Random (all concurrency levels) | -7.5% to -10.5%; ITL worse across the board |
| Real data (concurrency 50) | -16.5% |

DSpark does nothing for Qwen3.8; it actively hurts. Our read is that on long, reasoning-heavy outputs the accept rate of a bolted-on draft never climbs high enough to pay for the overhead of running it. Same DSpark, but a draft trained alongside the model (DeepSeek) and a draft assembled after the fact (Qwen) are not remotely the same proposition. Speculative decoding is not a switch you flip to go faster.

## Observations

The 17,478 tok/s peak is about 1.9x Qwen3.8 and about 4.5x Kimi-K3. Even at concurrency 1 it is 2,585 vs. 1,249 tok/s, a 2x gap, and median ITL is the lowest of the three models across the entire range. The default concurrency limit is a generous 256, and median TTFT stayed at a stable 312 ms even at concurrency 50 (Qwen3.8, capped at 48 by NEXTN, jumped to 1.6 seconds there).

On Random, a synthetic load weighted toward prefill, it lands at 10,810 tok/s, slightly behind Qwen3.8’s 11,833. Decode is where the small 49B active set and the bundled DSpark dominate; prefill is a wash. The clean way to put it is that which model wins depends on your workload’s decode/prefill ratio.

## Coding evaluation (subjective)

As usual we had it build our A* pathfinding visualizer through OpenCode (default harness). Same prompt as previous rounds (full text in [the last post](https://zenn.dev/fixstars/articles/qwen38-24t-a95b-day1-benchmark)).

It took 2 minutes 33 seconds and about 54K tokens of context. Everything worked on the first try, and it met the implementation requirements too: a hand-rolled binary heap for the priority queue, comments documenting the tie-breaking rule. Nothing as fatal as the play-button bug we found in V4-Flash last time (calling Set’s `size`

property as a method, a beginner-level JavaScript mistake).

There was still one frustrating miss. The prompt asks for the comparison to be laid out as two side-by-side panes; no matter how wide you make the window, the generated version stacks them vertically. Reading the code, the cause is immediately obvious: the panel container is `id="boards"`

, but the flex CSS that puts them side by side is written against `.boards`

, a class selector that never matches anything. The search algorithm itself is correct, and a one-character slip is all that stands between it and the intended UI. It has the same “never checked the final result” flavor as V4-Flash’s `size()`

bug.

Subjectively, the result is clean and holds together, but Kimi-K3’s output still has the edge on UI polish and information density, and that impression has not changed. To be honest, though, at this scale of task every model now clears the requirements and the differences are getting hard to see. Three articles in, the single-HTML implementation exercise is running out of road as a yardstick for raw model ability. We want to design a qualitative evaluation around longer, multi-file agent tasks before the next installment.

## Discussion

**The smallest model in the series was the fastest on real data.** That is the conclusion. At 1.6T total, 49B active, and 0.88TB of measured weights, it is the lightest of the three, and it took the top spot on nearly every operational metric that matters for on-prem: 30-minute startup, 9.89M tokens of KV cache, 17.5K tok/s on real data. The design bets, compressed attention (CSA / HCA) and a bundled DSpark, show up directly in the numbers.

That does not make this a simple “V4-Pro wins” story. It trails Kimi-K3 (60) and Qwen3.8 (58) on the Artificial Analysis Intelligence Index at 53, and on the subjective A* task Kimi-K3’s output still felt better. It is also the only one of the three without multimodal support, which rules it out for anything involving image input. Sorting it out: if output quality or multimodality is your top priority, Kimi-K3; if you want a balance of quality and speed, Qwen3.8; if text-only is fine and you are building an agent platform for many concurrent users where throughput and context capacity come first, V4-Pro. And V4-Pro adds the MIT license on top, which makes the legal review easy.

From a Day 1 deployment standpoint, DeepSeek’s release pattern, publishing a Preview first and then updating only the weights at GA with the same configuration, is worth noting. Being able to validate your setup in advance compresses the time from public release to first measurement enormously. That said, the weights were broken at release this time and we waited several hours for the fix. A dress rehearsal removes your own uncertainty; it does nothing about the vendor’s. Meanwhile, the fact that swapping weights alone moved real-data throughput by up to +88% is a good argument for re-measuring against your own workload every time a model updates.

## Summary

We completed deployment and benchmarking of DeepSeek-V4-Pro-0813 on a single-node NVIDIA B300 x8 machine the day after release. The native mixed-precision distribution (about 0.88TB) fits on one node with no additional quantization, and at roughly 30-minute startup, 9.89M tokens of KV cache, and 17,478 tok/s on the real coding-agent dataset, it rewrote most of the operational numbers from the same-conditions comparison we have been running against Kimi-K3 and Qwen3.8. It gives ground to those two on intelligence benchmarks and on the quality of the code it writes, which leaves a healthy three-way race in which the choice comes down to what you are optimizing for.

This round of testing is not just a new-model speed report; it feeds directly into our products.

Fixstars offers ** Fixstars Vega**, an on-premises AI appliance that pairs open-weight LLMs with our own performance-engineering harness. We evaluate the latest open-weight models for Vega on an ongoing basis, and this DeepSeek-V4-Pro work, following Kimi-K3 and Qwen3.8, is part of that effort.

The goal for Vega is simple: from the day a new model is published, you can use it safely in your own on-premises environment. If you are interested in applying AI to embedded software development, take a look at the [product page](https://www.fixstars.com/en/products-services/vega).

## References

[DeepSeek-V4-Pro-0813 (Hugging Face)](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-0813)/[Preview build (DSpark bundled)](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark)[DeepSeek-V4 collection (Hugging Face)](https://huggingface.co/collections/deepseek-ai/deepseek-v4)[SGLang cookbook: DeepSeek-V4](https://docs.sglang.io/cookbook/autoregressive/DeepSeek/DeepSeek-V4)[Artificial Analysis: DeepSeek V4 Pro](https://artificialanalysis.ai/models/deepseek-v4-pro)[Part 1: Day 0 deployment of Kimi-K3](https://blog.us.fixstars.com/deploying-kimi-k3-on-day-0-can-a-2-8t-model-run-on-a-single-node-of-nvidia-b300-x8/)[Part 2: Day 1 deployment of Qwen3.8-2.4T-A95B](https://blog.us.fixstars.com/day-1-with-qwen3-8-2-4t-a95b-twice-kimi-k3s-throughput-on-one-8x-b300-node/)

*This article was originally published in Japanese on the Fixstars Tech Blog: DeepSeek-V4-Pro-0813をDay1デプロイ! 実データ17,000 tok/s、三つ巴の頂点へ【B300 x8 検証速報】*