On June 27, DeepSeek released the DSpark technical report and DeepSpec code base. The base model of DeepSeek-V4 has not changed. What is new is a server-side speculative decoding module: DSpark. DeepSeek puts it very bluntly on the HuggingFace model page: V4-Pro-DSpark and V4-Flash-DSpark are "not new models." These two pages point to the same model checkpoint, plus the service version after speculating on the decoded module.

This means that DSpark does not make the model suddenly smarter. It aims at how to spit out answers faster and cheaper after the model goes online.

The technical report stated that DSpark has been deployed in the online service system of DeepSeek-V4. Under real user traffic, compared with the previous MTP-1 production baseline, which is DeepSeek's previous generation online speculation generation solution, the per-user generation speed of V4-Flash is increased by 60% to 85%, and V4-Pro is increased by 57% to 78%, provided that the throughput conditions are matched.

The "fast" here also needs to be tempered.It mainly refers to the generation stage, that is, the speed at which the model continues to output tokens. It does not mean that the end-to-end response time of all user requests is 85% faster.Pre-population of long prompt words, retrieval, tool invocation, queuing and network delays will still affect how long users actually wait.

After the model is online, there is still an inference account

This thing is not as lively as a new model release, but it is closer to the reality that AI companies face every day:The cost does not end after the model is trained.

Chatbots, code assistants, agents, and search-based products continue to consume GPU time with every call. If the model is slower, users will have to wait longer; if inference is more expensive, it will be more difficult for manufacturers to open high-quality models to more scenarios.

The AI ​​industry has become more accustomed to discussing training costs in the past two years: how many GPUs a company needs to buy, how large a cluster it should build, and how much it will cost to train the next generation model. But after the model actually becomes a product, another type of cost will keep popping up: inference.

Training is like a big project, and reasoning is like a utility bill.As long as users are still asking questions, agents are still running tasks, and code assistants are still generating patches, the model will continue to consume computing power.

Large model services will eventually return to two indicators: speed and unit token cost. API pricing pages usually charge based on input tokens and output tokens, and companies will also split different models, caches, routes, and context lengths into cost items internally.

DSpark cannot be directly equated to price reduction, but if the same GPU cluster can allow users to get answers faster at similar throughput, it means that the same hardware can serve more users, or the same user experience can be provided with fewer cards.

"Guess first, then test"

The idea of ​​speculative decoding can be roughly understood as "guess first, then test".

When a large model generates text, it usually spits out token after token. After the previous token comes out, the next token will know what to pick up. This method is stable but slow. Speculative decoding will allow a lighter draft module to guess a candidate token in advance, and the target large model will be verified in batches. The correct guess is accepted directly, and the incorrect guess is corrected.

Small models cannot make decisions for large models. Which tokens are ultimately accepted are still verified by the target model; when implemented correctly, it changes the generation method and does not change the output distribution of the target model.The speedup comes from having large models validate candidates in batches, rather than incrementally.

What DSpark changed is how to generate a draft

The paper does not stop at the "guess first, then test" explanation. It focuses on how to generate drafts.

Existing draft strategies fall broadly into two categories. The autoregressive drafter is more stable because the later token will see the previous token, but as the draft becomes longer, the delay will also increase. The parallel drafter is faster and can guess an entire paragraph at once, but each position is guessed separately. The later tokens are easily disconnected from the previous ones, and the acceptance rate is more likely to decline as it goes later.

DSpark chooses to compromise.The key word in the title of the paper is "Semi-Autoregressive Generation". It first uses a parallel method to propose a candidate, and then uses a lightweight sequential layer to modify the conditional relationship of subsequent tokens. This not only retains the speed of parallel generation, but also allows subsequent candidates to see what has been guessed previously.

Another key point is how long the verification is.

The more candidate tokens you guess, the less you save. If you know that the second half is likely to be rejected and still hand it over to a large model for verification, you are spending GPU time on a low-value position.DSpark will look at the confidence of the candidate and the current system load to dynamically determine the verification length.If the GPU is empty, you can perform multiple tests; when the load is high, the computing power is reserved for the parts that are more likely to be accepted.

This is what the "Confidence-Scheduled" in the title of the paper is talking about.

DSpark stands on existing technical routes

DSpark stands after speculating on the existing decoding route, and is more like a public reference after DeepSeek pushes this technical route to online services.

SpecInfer put small model prediction, token tree and parallel verification into the large model service system as early as 2023; Medusa proposed adding multiple decoding heads to the model in 2024 to predict multiple subsequent tokens at once; the EAGLE series continues to improve the acceptance rate around draft models and dynamic draft trees. Inference frameworks such as vLLM, SGLang, and TensorRT-LLM have long regarded speculative decoding as an important tool for reducing latency.

The advantage of DSpark is that it handles several production issues together: how to generate drafts, how to keep candidates consistent, how the verification length changes with load, and how much speed can be improved under real online traffic.

Keywords that appear repeatedly in the paper have also shifted from "model capability improvement" to service-side terms such as per-user generation speed, matched throughput, and service level agreement (SLA).

This also explains why you can't just pick the largest number to look at. There are indeed high throughput data such as 661% and 406% in the paper, but they come from more stringent per-user speed targets: under that setting, the old baseline itself is already close to the boundary of service capabilities, and DSpark's relative advantage will be amplified.

What can really illustrate the normal benefits is the previous set of numbers: matching throughput, real traffic distribution, and the comparison object is MTP-1.

What can DeepSpec reproduce?

DeepSeek also open sourced DeepSpec. This is a code library for training and evaluating speculative decoding draft models. It includes data preparation, training and evaluation processes, and also releases relevant checkpoints on Qwen3, Gemma and other models.

but,Open source does not mean "download and reproduce".The project documentation indicates that under the default Qwen3-4B configuration, the target model cache may be close to 38TB; the default training script assumes 8 GPUs on a single node; if the paper results are to be aligned, the training settings must be strictly consistent, and additional fine-tuning of the draft model is required in specific areas.

The outside world can verify part of the method, and can also transplant DeepSpec to other open source models, but the set of speed improvement figures in the DeepSeek-V4 online service still comes from DeepSeek's own hardware scale, traffic distribution and production system scheduling.

Open source is the method, not the environment.

The community is most concerned about recurring boundaries

The discussion on

AI researcher Ravid ShwartzZiv summarizes DSpark as a compromise between two types of drafters: the parallel drafter is fast, but the acceptance rate decays along the candidate block; the autoregressive drafter is stable, but the delay increases with the length of the draft. He specifically mentioned two components added to DSpark: the confidence judgment head and the load-aware scheduler, and added a key boundary: "Like all speculative decoding, it is lossless."

Engineers are more concerned about whether it can run. vLLM contributor Rafael Caricio said that he ran the DSpark mode of DeepSeek-V4-Flash on dual DGX Spark GB10, and the single-stream decoding was about 60 tok/s, which is about 1.5 times that of MTP-1.

He also mentioned that the real code session exposed problems that the synthetic benchmarks could not see: the bottleneck is not just the speed of the computing core, but the draft acceptance rate will drop significantly under long context.

Tech2Wild also provided on-site data in a similar direction, showing that V4-Flash-DSpark has been trial-run in a specific vLLM environment. However, such results are highly dependent on the hardware model, framework patch version, context length and concurrency settings. The results may be completely different in another environment.

There are also people who specifically remind you of the boundaries. AcingAI pointed out on

This reminds us that part of the advantage of DSpark comes from load-aware scheduling, and the scheduling effect naturally depends on the traffic scale and hardware configuration of the production environment.

Same power, less computing power

In a report on June 28, the South China Morning Post looked at DSpark in terms of inference bottlenecks, chip pressure and user waiting time. This perspective is closer to product reality than "What model did DeepSeek release again?"

AI companies will continue to compare model capabilities, but when the capability gap is narrowed, who can deliver the same capabilities faster and cheaper will also become part of the competition.

Companies like DeepSeek especially need to make this clear. DeepSeek has always regarded low cost and high efficiency as an important entry point for the outside world to understand it. From the model training narrative to the API price, what attracts the most attention is not whether it has a larger parameter scale, but whether it can make the same capabilities cheaper.

DSpark continues this line: it does not prove that V4 is suddenly smarter, it proves that V4 can waste less reasoning computing power when serving users.

If we broaden our perspective a little further, inference optimization will also affect the open source model ecology. The open source model used to be considered "cheap", but when it is actually deployed, graphics memory, throughput, concurrency, latency and operation and maintenance complexity will all become costs.

If a model can be open source, it only means that everyone can get it; whether it can serve a large number of users cheaply depends on whether the inference stack can keep up.

DeepSpec released Qwen3, Gemma and other checkpoints, indicating that this matter does not stop with DeepSeek-V4 itself. The extent of migration depends on the actual progress of community adaptation, framework support and hardware compatibility; but judging from the current public information, DeepSeek has taken this route out of its own model.

The value of DSpark lies here.It adds a layer of inference service tools to V4 that is closer to the production system, rather than just a new capability label.

What’s worth watching next is not only how fast DeepSeek can run, but also how many people can pass this route. DeepSpec has released checkpoints and training processes, and it is speculated that decoding is changing from a company's engineering choice to a common means of open source inference to reduce costs.That’s assuming other frameworks and hardware can keep up.