DSpark: DeepSeek Partners with Peking University to Open-Source Inference Acceleration, Boosting Speed by Up to 85%

What Is DSpark: No Model Changes, Just More Speed

DeepSeek recently partnered with Peking University to open-source an inference acceleration technology called DSpark. Released alongside it are two enhanced model weights (DeepSeek V4 Flash DSpark and DeepSeek V4 Pro DSpark), as well as a companion open-source framework called DSpec.

The first thing to clarify: DSpark is not a new model. The model's own capabilities remain completely unchanged. It's more like an "acceleration plugin" attached to V4, designed specifically to make the large model generate text faster. To put it vividly—the brain is still the same brain, it's just gotten quicker on the draw.

The core figure released officially is: under the same service load, individual users receive their answers 57% to 85% faster than with the previous-generation solution. To understand where this speedup comes from, we first need to understand why large models are slow.

Why Is Large Model Inference Slow: Data Movement Costs More Than Computation

Large models generate text "one character at a time," a process technically called autoregression. It first computes the next character, appends it to the existing sentence, then computes the next one, and so on in a loop.

The problem is that for every character it produces, it has to fully move the entire model—hundreds of billions of parameters—out of memory. The key insight here is: the real reason for the slowness isn't insufficient compute power, but that this data movement takes too long.

The cost of one round of movement is fixed, yet you only get one character in return. It's like rummaging through an entire warehouse from top to bottom just to fetch a single item each time—the effort of moving things far outweighs the actual work. As a result, the expensive compute units on the GPU spend most of their time simply waiting for data.

Speculative Decoding: One Round of Movement, Multiple Characters

Since getting only one character per round of movement is so inefficient, could we get several characters per round instead? This is the core idea of Speculative Decoding, and it's the underlying logic of DSpark's inference acceleration.

Here's how it works: a small, fast "draft model" guesses several upcoming characters all at once, then the full large model checks all these candidate characters simultaneously in a single pass. Starting from the beginning, all consecutively correct guesses are accepted, and everything from the first wrong guess onward is discarded.

There are two key points here:

• Checking cost ≈ generation cost: For the large model, checking a string of characters takes about the same effort as generating a single character—both require one round of movement and one computation. So being able to approve several characters at once is pure profit.
• Output quality unchanged: Because the large model still makes the final call, it only accepts characters it would have approved anyway. The final output is completely identical to what would have been produced by honestly generating one character at a time—just faster.

Here's an analogy: the drafter quickly scribbles out the next few characters, the reviewer scans over them at a glance, approves the correct ones all at once, and crosses out everything from the first wrong character onward. This is much faster than the reviewer writing everything from scratch, so overall speed goes up.

The Perennial Problem: Prone to Failure Under High Concurrency

Speculative decoding sounds great, but there's an unavoidable pain point: it works excellently for single users when the machine isn't busy, but once many people access it simultaneously (high concurrency), it can easily backfire.

The reason is that checking candidate characters itself consumes GPU compute. When the machine is already at full load, those characters that come later and are likely to be rejected end up wasting precious compute power, crowding out resources that should serve other users—and the net result may actually be slower.

The solution DeepSeek previously used in production is called MTP, which reliably guesses one character at a time but offers limited speedup. What DSpark aims to solve is precisely how to "guess more without causing trouble" in a real production environment where many people use it simultaneously.

DSpark's Three Core Designs

Design One: Semi-Autoregressive Draft Model

There are two extremes to guessing characters. Purely parallel guessing—several characters generated simultaneously, which is fast, but these characters don't reference each other, making them prone to incoherence and less likely to be accepted. Purely sequential guessing—one after another, with high accuracy, but the speed drops back down again.

DSpark takes the middle path in two steps: first, a parallel backbone network lays out drafts for all candidate positions at once—this step is fast. Then, a lightweight sequential module fills in contextual dependencies for each character one by one, letting characters within the same batch "communicate" with each other. This preserves the speed of parallelism while guessing more accurately than pure parallel methods, ultimately getting more characters accepted.

Design Two: Confidence Scoring Mechanism

When the draft model generates each candidate character, it also assigns a score predicting the probability that the character will ultimately be accepted by the large model. This lets the system clearly know which characters are reliable and which will most likely be rejected, providing data to inform subsequent compute scheduling.

Design Three: Load-Aware Adaptive Scheduler

This is the key to how DSpark solves the high-concurrency challenge. The scheduler senses the GPU's current load status in real time, dynamically deciding how long a candidate sequence each request should verify, and prioritizes allocating the large model's compute to the highest-confidence characters.

Simply put: when the GPU is idle, guess and approve more; when the GPU is busy, guess fewer and don't cause trouble. It's precisely this adaptive load mechanism that allows DSpark to stably achieve inference speedups even in high-concurrency scenarios.

How Well Does It Work: Multiple Real-World Comparison Data Points

The official core data shows: compared to the previously deployed MTP solution, under the same throughput load, single-user generation speed improved by 57% to 85%.

In public comparison tests benchmarked against the Qwen3 series models:

• DSpark accepts on average about 30.9% more characters per pass than the industry-standard EAGLE-3;
• About 16.3% more than DeepSeek's own previous-generation solution DFlash;
• Overall inference speed improved by nearly 80%.

It's worth emphasizing again: throughout the entire acceleration process, the model's own capabilities remain completely unchanged—it's purely an engineering optimization at the inference engine level. DSpark is currently deployed on the preview versions of DeepSeek V4 Flash and V4 Pro.

What Was Open-Sourced This Time: The DSpec Framework Explained

The open-source release this time is quite substantial, mainly consisting of two parts:

First, two enhanced model weights—DeepSeek V4 Flash DSpark and DeepSeek V4 Pro DSpark. These are essentially the original base models with the DSpark module pre-installed, already released on Hugging Face.

Second, the DSpec full-stack open-source framework, hosted on GitHub. Think of it as a toolbox dedicated to producing draft models: it includes training code, evaluation scripts, and ready-made weights for three speculative decoding approaches—DSpark, DFlash, and EAGLE-3—making it easy for researchers to compare, reproduce, and even train their own inference acceleration modules. The target models currently supported are the Qwen3 and Gemma series.

Summary

To sum up this update in one sentence: DSpark is the inference acceleration plugin that makes DeepSeek V4 quicker on the draw, while DSpec is the toolbox that fully open-sources this speedup method—all backed by the joint research of DeepSeek and Peking University.

Its value lies not only in the 57%–85% speed improvement, but also in publicly releasing a complete solution to the engineering challenge of "speculative decoding under high concurrency." For developers and enterprises focused on large model inference efficiency, this adaptive load-scheduling approach, along with the toolbox for comparing three solutions side by side, offers significant value for reproduction and reference.