DSpark: DeepSeek and Peking University Open-Source Inference Acceleration Tech with Up to 85% Speed Boost

What Is DSpark: No Model Changes, Just Faster

DeepSeek recently teamed up 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), plus a companion open-source framework called DSpec.

The first thing to clarify is this: DSpark is not a new model. The model's inherent capabilities haven't changed at all. It's more like an "acceleration plugin" attached to V4, designed specifically to make the LLM generate text faster. To use a vivid analogy—it's still the same brain, just with a quicker tongue.

The core figure the team cites is this: under the same server 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 LLMs are slow.

Why LLM Inference Is Slow: Moving Data Costs More Than Computing

LLMs generate text "one word at a time"—the technical term is autoregressive. It computes the next word, appends it to the existing sentence, then computes the next word, and so on in a loop.

The problem is that for every single word it produces, it has to move the entire model—hundreds of billions of parameters—from GPU memory in full. The key insight here is: the real reason for the slowness isn't insufficient compute, but that this data movement is too time-consuming.

The cost of one round trip is fixed, yet you only get a single word out of it. It's like flipping through the entire warehouse from top to bottom just to fetch one item each time—the effort of moving far exceeds the actual work. The result is that the expensive compute units on the GPU spend most of their time simply waiting for data.

Speculative Decoding: One Data Trip, Multiple Words

Since getting just one word per round trip is so wasteful, could we get several words per trip instead? This is the core idea of Speculative Decoding, and also the underlying logic behind DSpark's inference acceleration.

Here's how it works: a small, fast "draft model" guesses several upcoming words all at once, then the full-size LLM checks all these candidate words 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 LLM, checking a string of words takes about the same effort as generating a single word—both require one data trip and one computation. So being able to greenlight several words at once is pure profit.
• Output quality is unchanged: Because the LLM has the final say, it only accepts words it would have approved anyway. The final output is identical to generating word by word honestly—just faster.

Here's an analogy: the drafter quickly writes out the next few words, the reviewer glances over them, greenlights the correct ones all at once, and crosses out everything from the first wrong word onward. This is much faster than having the reviewer write everything from scratch, so overall speed goes up.

The Longstanding Problem: Prone to Failure Under High Concurrency

Speculative decoding sounds great, but it has an unavoidable pain point: it works excellently when a single user is using it and the machine isn't busy, but once many users access it simultaneously (high concurrency), it can easily backfire.

The reason is that checking candidate words itself consumes GPU compute. When the machine is already at full load, those trailing words that are likely to be rejected waste precious compute, crowding out resources that should serve other users. On balance, it can actually end up slower.

The solution DeepSeek previously used in production was called MTP, which reliably guesses one word at a time—but the speedup is limited. What DSpark aims to solve is exactly how to "guess many words without causing trouble" in real production environments where many users are online at once.

DSpark's Three Core Designs

Design One: Semi-Autoregressive Draft Model

Guessing words has two extremes. Purely parallel guessing—several words generated simultaneously—is fast, but these words don't reference each other, so they tend to be incoherent and get accepted less often. Purely sequential guessing—one after another—is accurate, but slows things down again.

DSpark takes a middle path in two steps: first, a parallel backbone network lays out draft candidates for all positions in one shot—this step is fast; then a lightweight sequential module adds contextual dependencies to each word one by one, letting the words in the same batch "compare notes" with each other. This preserves the speed of parallelism while guessing more accurately than pure parallelism, so more words end up being accepted.

Design Two: Confidence Scoring Mechanism

When generating each candidate word, the draft model also assigns a score, predicting the probability that the word will ultimately be accepted by the LLM. This lets the system clearly know which words are reliable and which are likely to be rejected, providing a data basis for subsequent compute scheduling.

Design Three: Load-Aware Adaptive Scheduler

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

Put simply: when the GPU is idle, guess more and accept more; when the GPU is busy, guess less and don't cause trouble. It's precisely this adaptive load mechanism that allows DSpark to reliably deliver inference speedups even in high-concurrency scenarios.

How Well Does It Work: Multiple Benchmark Comparisons

The core official 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 benchmark comparisons using the Qwen3 series models as a baseline:

• The average number of words DSpark can accept per pass is about 30.9% higher than the industry-common EAGLE-3;
• About 16.3% higher 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 inherent 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: A Deep Dive Into the DSpec Framework

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

First, two enhanced model weights—DeepSeek V4 Flash DSpark and DeepSeek V4 Pro DSpark. Essentially, these are the original base models with the DSpark module preinstalled, released on Hugging Face.

Second, the full-stack open-source framework DSpec, hosted on GitHub. You can think of it as a toolbox dedicated to producing draft models: it comes with training code, evaluation scripts, and ready-made weights for three speculative decoding solutions—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 an inference acceleration plugin that gives DeepSeek V4 a quicker tongue, while DSpec is the toolbox that fully open-sources this speedup method—all backed by joint research between 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 LLM inference efficiency, this adaptive load-scheduling approach, along with a toolbox for side-by-side comparison of three solutions, offers significant value for reproduction and reference.