Speculative Decoding vLLM: DSpark Explained (DeepSeek, 2026)

The paper DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation describes DSpark, a confidence-scheduled speculative decoding method. Matching speculative decoding vLLM support reuses the existing SparseMLA attention backend rather than a new kernel. The headline claim, a 60-85% faster per-user generation speed, is real, but it is measured against DeepSeek's own MTP-1 production baseline, not against plain autoregressive decoding. That distinction is the whole story here: DSpark's actual contribution is changing what gets verified per request, not just what gets drafted, and the win it produces is fewer GPUs at a fixed latency target rather than a flat tokens/sec multiplier you can drop into every deployment.

TL;DR: What Does DSpark Change for Speculative Decoding in vLLM?

• What's new: DSpark, with checkpoints DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark on Hugging Face.
• The mechanism: confidence-scheduled verification sets a per-request verify length from each drafted token's estimated survival probability, instead of verifying the same fixed block for every request.
• The headline number: DSpark is 60-85% faster per user than MTP-1 (DeepSeek's prior production baseline) at matched throughput, measured under live DeepSeek-V4 traffic, not versus plain autoregressive decoding.
• In vLLM: enable it with --speculative-config '{"method":"dspark","num_speculative_tokens":7}'; it runs on the SparseMLA attention backend already in vLLM.
• Validated hardware: 8x B300, 8x H200 (800K context cap), 8x MI355X, and 8xGB200 NVL4 across two trays with data plus expert parallelism.
• Price: Spheron H200 SXM5, one of the GPUs DSpark was validated on, runs $5.49/hr on-demand and $2.85/hr spot as of 24 Sep 2026. Spheron also rents B300 GPUs, the other DSpark-validated node type, for side-by-side testing.

What DSpark Actually Changes: Confidence-Scheduled Verification

Every speculative decoding method splits work into two phases: a cheap drafter proposes several candidate tokens, then the expensive target model verifies them in one forward pass. The methods differ almost entirely in how the draft phase works and how much of it gets verified each step. DeepSeek's paper frames DSpark's contribution as the second half of that pair: confidence-scheduled verification dynamically sets a per-request verification length from each drafted token's estimated survival probability and the engine's current throughput profile, rather than verifying a fixed block length for every request.

That is a scheduling decision, not a drafting trick. DSpark is not just another draft-model speedup: a faster drafter buys you a higher acceptance ceiling on average, while a smarter verify schedule buys you closer-to-ceiling utilization on every individual request, including the ones a fixed-depth method wastes budget on or shortchanges.

The Semi-Autoregressive Drafter: A Block, Not a Token Chain

Underneath the scheduler sits a drafter that is neither purely parallel nor purely sequential. DeepSeek couples a parallel semi-autoregressive backbone with a lightweight sequential module to model intra-block token dependencies and mitigate the acceptance decay that pure parallel drafters suffer over longer blocks. Pure parallel block drafters (the kind block diffusion models use) generate every position in the block independently, which is fast but loses accuracy as the block gets longer because later positions can't see what earlier positions in the same block actually resolved to. DSpark's sequential module patches that dependency back in cheaply, without falling back to a fully autoregressive draft chain.

The published block size in DeepSeek's released checkpoints is 7 tokens, which is also vLLM's default num_speculative_tokens value for the DSpark method. That number is a ceiling, not a target: the confidence scheduler decides, per request, how much of that 7-token block is actually worth verifying this step.

How Confidence Scheduling Differs From EAGLE-3's Fixed Draft Depth and DFlash's Block Diffusion

It helps to place DSpark against the two speculative decoding methods this blog has already covered in depth, since both are still the more common production choice today.

EAGLE-3 drafts autoregressively: a lightweight head trained on the target model's fused internal features proposes tokens one at a time, and you set --num-speculative-tokens once at server launch. That number is fixed across every request the server handles, whether the request is a low-entropy completion or an unpredictable creative-writing continuation.

DFlash drafts a full block in one shot using a block diffusion model, and it verifies that whole block too. It is also a fixed-size scheme: the block width is set once, and every request gets the same verify pass regardless of how confident the draft actually was.

DSpark drafts a block, the same broad shape as DFlash, but it does not verify all of it uniformly. The confidence scheduler decides how many of the 7 drafted tokens to actually check this step, per request, based on their estimated survival probability. On a mixed workload, that means an easy, formulaic request (the paper uses GSM8K-style math prompts as an example) gets a longer verify window because its tokens are more predictable, while an open-ended, high-entropy request (poetry, in the paper's benchmark) gets a shorter one, because verifying further into an unpredictable block wastes compute on tokens likely to be rejected anyway. Neither EAGLE-3 nor DFlash makes that distinction; both spend the same fixed verify budget on both request types.

The 60-85% Number: What It Means Under Load vs in the Paper

The 60-85% figure is the number every summary of DSpark leads with, and it is also the number most likely to get misquoted. Here is what it actually says and doesn't say.

Per-User Speedup vs MTP-1, Not vs No Speculative Decoding

DeepSeek's reported result is that DSpark accelerates per-user generation speed by 60-85% versus the established production baseline (MTP-1) at matched throughput levels, measured under live DeepSeek-V4 user traffic. Two details in that sentence carry the whole caveat: the baseline is MTP-1, not plain autoregressive decoding, and the comparison holds throughput constant while measuring per-user latency, rather than reporting a raw aggregate tokens/sec multiplier.

MTP-1 is DeepSeek's own multi-token prediction setup, using one extra prediction head trained jointly with the base model to generate additional tokens per forward pass at no separate draft-model cost. Our MTP deployment guide covers why DeepSeek ships MTP heads by default: they already beat vanilla autoregressive decoding by roughly 2-3x with zero extra VRAM, because the heads are baked into the checkpoint rather than loaded as a second model. DSpark's 60-85% is stacked on top of that already-faster baseline. The compounded speedup over plain token-by-token decoding is therefore larger than 60-85% alone, but DeepSeek has not published that combined ratio, so resist the urge to multiply the two numbers together and quote the product as fact.

Aggregate Throughput Gains at Matched Latency Targets

"Matched throughput levels" is doing real work in that sentence. It means DeepSeek held the server's serving throughput constant across both configurations and measured what happened to the latency each individual user experienced, rather than comparing two servers running at their respective maximum throughput. That is the right comparison for a latency-SLA-bound production service, and it is also why a single flat "DSpark is Nx faster" number would be the wrong takeaway.

For a concrete sense of what DSpark's throughput actually looks like in a serving stack, SGLang's own integration reports 383.7 tokens per second at an accept length of roughly 5 tokens, running DeepSeek-V4-Pro with tensor-parallel size 8 on a B300 node at batch size 1. That is a single-request number, useful as a reference point for what the drafter's acceptance behavior looks like in practice, rather than a substitute for the matched-throughput comparison the paper itself reports.

What Changes at High Concurrency (and Why It's a Different Metric)

The behavior that actually differentiates DSpark from fixed-depth methods shows up once traffic mixes hard and easy requests in the same batch, which is exactly what a production server does and a single-request benchmark does not. SGLang's writeup on the integration measured the scheduler differentiating verify budget by task under mixed load: GSM8K-style requests get windows around 5.24 tokens versus roughly 2.91 for poetry-style requests, while holding 0.88-0.97 utilization against the full-block acceptance ceiling.

That 0.88-0.97 utilization figure is the number that matters at high concurrency, more than any single throughput multiplier. A fixed-depth scheme has to pick one verify width for every request type sharing the batch; pick it for the easy requests and you waste GPU cycles verifying tokens on hard requests that were never going to be accepted, pick it for the hard requests and you leave acceptance headroom on the table for the easy ones. DSpark's per-request scheduling keeps both ends of that mix close to their own acceptance ceiling simultaneously, which is a concurrency-scaling property, not a fixed multiplier you can extrapolate from a batch-size-1 number. It is also, per the paper, running under exactly this kind of mixed live traffic in production, since DSpark was deployed inside DeepSeek's own V4 production serving system under live user traffic, not just evaluated offline.

vLLM DSpark Setup: Turning It On and What to Expect on Your GPU Bill

Enabling DSpark in vLLM is a two-part decision: pick a checkpoint that already has the module attached, then pass a --speculative-config payload that tells vLLM which method and block width to use. Neither DeepSeek-V4-Pro-DSpark nor DeepSeek-V4-Flash-DSpark is a new base model; both are the base checkpoints with a speculative decoding module attached rather than new base models, so the accuracy profile of the underlying model is unchanged.

The --speculative-config Flag and the Checkpoints It Needs

The exact launch flag is `--speculative-config` with a JSON payload, for example `{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"probabilistic"}`. Practically, that means:

1. Pull deepseek-ai/DeepSeek-V4-Pro-DSpark (or the Flash variant) from Hugging Face instead of the plain V4-Pro checkpoint.
2. Pass --speculative-config with method: dspark and num_speculative_tokens: 7, matching the checkpoint's published block size.
3. Leave draft_sample_method at probabilistic unless you have a specific reason to force greedy drafting; the confidence scheduler expects probabilistic sampling to compute survival estimates.

Under the hood, vLLM's DSpark implementation reuses the existing SparseMLA attention backend instead of a custom kernel, captures the draft backbone and sampling loop in a single CUDA graph, and is compatible with prefix caching and FP8 KV cache. That matters operationally: if you already run DeepSeek-V4-Pro on vLLM with prefix caching and FP8 KV cache enabled, switching to the DSpark checkpoint doesn't force you to rework either of those settings. If you haven't deployed V4-Pro itself yet, our multi-node DeepSeek V4-Pro deployment guide covers the base hardware math (roughly 1,600 GB of FP8 weight at 1.6T total parameters) before you add DSpark on top of it. Because DeepSeek-V4 is a MoE model, DSpark's vLLM path also has to coexist with expert parallelism; our speculative decoding for MoE models guide covers the routing-divergence problem that any draft-verify scheme has to handle on a MoE target.

Hardware DSpark Was Actually Validated On (B300, H200, GB200 NVL4, MI355X)

DeepSeek's own recipe lists four validated configurations for DeepSeek-V4-Pro serving with DSpark on vLLM: B300 (8 GPUs, single node), H200 (8 GPUs, context capped at 800K tokens), MI355X (8 GPUs), and GB200 NVL4 (8 GPUs across 2 trays, multi-node with data plus expert parallelism). The H200 context cap is worth flagging on its own: at 800K tokens rather than V4-Pro's full 1M-token architectural limit, an 8x H200 node is running below the model's maximum context to leave enough KV cache headroom for the DSpark draft state alongside the target model's own cache. If your workload genuinely needs the full 1M-token window, that pushes you toward the 3-node H200 configuration our V4-Pro deployment guide covers, or toward B300/GB200 NVL4 where the higher per-GPU memory absorbs the extra draft-state overhead more comfortably.

None of the four validated configurations is a single consumer or entry-level datacenter GPU. This is multi-GPU serving hardware by design, since it's serving a 1.6T-parameter MoE model, not a property of DSpark itself; DSpark's Flash variant on a smaller checkpoint would have a correspondingly smaller footprint.

The GPU-Count Consequence: Fewer Nodes for the Same Per-User Latency Target

This is the part of DSpark's story that a flat "X% faster" headline doesn't capture: a per-user latency win at matched throughput doesn't show up as a bigger tokens/sec number on a chart, it shows up as needing fewer nodes to hit the same per-user latency SLA you were already targeting.

Concretely: if your SLA is "P50 token latency under X ms" and you're currently running MTP-1 on 3 nodes of 8x H200 to hit that target at your traffic volume, the question DSpark answers is whether the same SLA holds on 2 nodes once its confidence scheduler is keeping verify utilization at 0.88-0.97 instead of MTP-1's fixed-depth behavior. That's a capacity-planning question, and it is one you have to answer against your own traffic mix, not against DeepSeek's GSM8K-versus-poetry benchmark split, because the scheduler's benefit scales with how heterogeneous your actual request distribution is. A workload that's uniformly easy or uniformly hard sees less benefit from adaptive scheduling than one that mixes both, since a fixed-depth method already comes close to optimal on a uniform distribution.

That's also where testing this on rented hardware before committing to a fixed footprint pays off. Spot pricing on Spheron runs at a discount to on-demand rates on GPUs including H100 and H200, and per-minute billing after a short minimum commitment means an MTP-1-versus-DSpark A/B run on your own traffic sample, same checkpoint family, same node count, costs you an afternoon rather than a procurement cycle. Two honest limits worth stating up front: Spheron's marketplace gives you access to the instances themselves, not a managed multi-node orchestration layer, so wiring up the data-parallel and expert-parallel launch for an 8xGB200 NVL4 configuration is still on you. And the largest published DSpark gains are a production-scale, high-concurrency effect specific to DeepSeek's own live traffic mix; a benchmark run on a single rented node will reproduce the per-user and offline-benchmark numbers in this post, not DeepSeek's internal fleet-wide aggregate.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 24 Sep 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing for live rates.

DSpark's real contribution isn't a bigger multiplier than EAGLE-3 or DFlash on a leaderboard. It's a scheduler that spends verify budget where the drafted tokens are actually likely to survive, which turns into fewer GPUs for the same latency promise once your traffic is heterogeneous enough for that to matter. Measure your own acceptance and verify-length numbers against MTP-1 before you resize a cluster around any published percentage, including this one.

Benchmarking DSpark against your current MTP-1 or EAGLE-3 setup takes a real GPU, not a paper multiplier.

Check H200 availability on Spheron →