DSpark and Gemma 4: What DeepSeek's Speedup Actually Means

Short answer: DeepSeek's DSpark is real, it's open-sourced, and DeepSeek has published research checkpoints showing it works with Gemma 4 12B — but the headline "60–85% faster" number is a DeepSeek-V4 production result, not a Gemma 4 one, and there's currently no way to drop DSpark into Ollama, LM Studio, or vLLM to speed up Gemma 4 today. Here's what's actually verified.

What DSpark Is

On June 27, 2026, DeepSeek-AI (with Peking University collaborators) published a paper called "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" and simultaneously open-sourced DeepSpec, the full training and evaluation codebase, on GitHub under an MIT license.

DSpark is a form of speculative decoding — a well-established trick for speeding up LLM generation without changing the model's actual output. A small "draft" model quickly guesses several tokens ahead, and the big model verifies them all in a single pass instead of generating one token at a time. When the draft guesses right, you get several tokens for the cost of one verification step. When it guesses wrong, you fall back to normal generation for that stretch. Because the verification step uses rejection sampling against the real model's probabilities, the output is lossless — statistically identical to what the full model would have generated on its own, just faster.

What DSpark adds on top of that basic idea, per the paper:

• A semi-autoregressive draft model. Instead of a purely parallel draft head (fast but each guessed token is blind to the others) or a purely sequential one (accurate but slow), DSpark pairs a parallel backbone with a small sequential "Markov head" that adds a little bit of token-to-token dependency within each draft block. This targets a known problem called "suffix decay," where the later tokens in a drafted block get progressively less reliable.
• Confidence-scheduled verification. Rather than always verifying a fixed number of draft tokens, a confidence head estimates how likely each drafted token is to survive verification, calibrated through a technique the authors call Sequential Temperature Scaling. A scheduler then decides how many tokens to verify based on current GPU load — checking more when the server is idle, fewer when it's busy — to keep total system throughput steady.

How This Relates to Gemma 4's Own Speculative Decoding

Here's a distinction worth being precise about, because it's easy to conflate the two: Gemma 4 12B already ships with its own official draft model for speculative decoding, independent of anything DeepSeek released. It's a small MTP (multi-token prediction) component included with the base model, and it already works today in llama.cpp, enabled with flags like --model-draft, --spec-type draft-mtp, and --n-gpu-layers-draft. That's Google's own lossless speed-up path for Gemma 4, and it's been usable since the 12B model's release in June 2026.

DSpark is a completely separate project from a different company, built as a general speculative-decoding technique rather than a Gemma-specific feature. The DSpark paper does not mention or benchmark against Gemma's stock MTP drafter at all — the two exist independently, and as of this writing there's no published comparison telling you which one is actually faster on a Gemma 4 12B setup.

What's Actually Released for Gemma 4

DeepSeek didn't just publish a paper about DeepSeek-V4 — the DeepSpec GitHub repo explicitly extends the benchmark to other open model families, and Gemma 4 12B is one of them. The repo's released-checkpoints table lists draft models trained against google/gemma-4-12B-it for three different algorithms:

Algorithm	Gemma 4 12B checkpoint
Eagle3 (baseline)	deepseek-ai/eagle3_gemma4_12b_ttt7
DFlash (baseline)	deepseek-ai/dflash_gemma4_12b_block7
DSpark	deepseek-ai/dspark_gemma4_12b_block7

This confirms DeepSeek trained and released an actual DSpark draft model targeting Gemma 4 12B — not just a claim that the technique "should" generalize. According to reporting on the paper's results (via VentureBeat), DSpark's gains over the Eagle3 and DFlash baselines — roughly 27–31% and 16–18% respectively on Qwen3 models — "hold" on Gemma4-12B as well, meaning the improvement isn't unique to DeepSeek's own architecture.

What this is not: a wall-clock speedup number for Gemma 4, comparable to the V4 production figures. What's measured for Gemma (and Qwen3) is "accepted length" — the average number of draft tokens accepted per verification round, an internal speculative-decoding research metric — evaluated offline across benchmark tasks like GSM8K, MATH, HumanEval, MBPP, LiveCodeBench, MT-Bench, and Arena-Hard. A higher accepted length generally translates to faster real-world generation, but DeepSeek did not publish an end-to-end "Gemma 4 12B was X% faster" claim the way it did for V4-Flash and V4-Pro. Treat any specific percentage you see applied to Gemma as an extrapolation, not a stated result.

The Realistic Setup Today

If you were hoping to pip install your way to a faster Gemma 4 12B this week, the honest state of things is: not yet, at least not easily.

The DeepSpec repo the Gemma checkpoints live in is a research training-and-evaluation harness, not a serving stack:

• Its eval.py script measures acceptance metrics by spawning distributed workers across an 8-GPU node — built to reproduce the paper's benchmark table, not to run a chat session.
• The only inference engine mentioned anywhere in the repo is SGLang, and it's used solely to regenerate training data from the target model during data preparation — not to serve DSpark drafts to end users.
• There is no vLLM, SGLang, TensorRT-LLM, or llama.cpp integration for actually serving a Gemma 4 model with the DSpark drafter attached. DeepSeek's own production deployment (the one behind the 60–85% number) runs on DeepSeek's internal HAI-LLM framework, which isn't part of this open-source release.

So practically, if you're running Gemma 4 locally, the DSpark release today is a promising research signal — a public, MIT-licensed algorithm and a Gemma-specific draft checkpoint proving it generalizes — rather than a tool you can install. The thing that actually speeds up your Gemma 4 12B inference right now is Gemma's own stock MTP draft model in llama.cpp, which needs no DeepSeek components at all.

The Numbers, With Their Actual Scope

To keep these straight:

Claim	Applies to	Source
60–85% faster per-user generation	DeepSeek-V4-Flash, vs. DeepSeek's own MTP-1 baseline, in production	DeepSeek / reported by VentureBeat
57–78% faster per-user generation	DeepSeek-V4-Pro, same comparison	DeepSeek / reported by VentureBeat
+27–31% accepted length vs. Eagle3; +16–18% vs. DFlash	Qwen3-4B/8B/14B, offline benchmark eval	DeepSpec paper (arXiv 2607.05147)
Gains "hold" on Gemma4-12B	Gemma 4 12B, offline benchmark eval, same accepted-length metric	Reported summaries of the paper's Table 1

Everything in that last row is measured, not a production wall-clock claim — that distinction matters if you're deciding whether to wait for DSpark or just use what Gemma 4 already ships with. For context on where Gemma 4's quality and speed already stand on their own, see our Gemma 4 benchmarks breakdown.

FAQ

Does DSpark make Gemma 4 faster right now? Not through any packaged, ready-to-run tool. DeepSeek released a DSpark draft checkpoint trained against Gemma 4 12B and showed it beats research baselines on an offline acceptance-length metric, but there's no vLLM, SGLang, or llama.cpp integration that lets you actually serve Gemma 4 with DSpark attached today.

Is the 60–85% speedup number about Gemma 4? No. That figure is specifically for DeepSeek's own DeepSeek-V4-Flash and V4-Pro models, deployed in DeepSeek's production stack, compared against DeepSeek's prior MTP-1 decoding baseline. No equivalent end-to-end number has been published for Gemma 4.

Doesn't Gemma 4 already have speculative decoding? Yes — Gemma 4 12B ships with its own official MTP (multi-token prediction) draft model, usable today in llama.cpp with the --model-draft and --spec-type draft-mtp flags. That's a separate, already-working feature from Google, unrelated to DSpark.

What did DeepSeek actually release for Gemma users? A DSpark draft-model checkpoint (deepseek-ai/dspark_gemma4_12b_block7) trained against google/gemma-4-12B-it, plus the open-source DeepSpec training/eval code (MIT license) needed to reproduce or extend it. It's aimed at researchers building or benchmarking speculative-decoding drafters, not at end users looking for a drop-in speed boost.

Should I wait for DSpark support before optimizing my Gemma 4 setup? No — start with Gemma 4's documented hardware requirements and its built-in MTP speculative decoding, both of which work today. DSpark for Gemma is a real, generalizing research result worth watching, but it isn't yet something you can install and run.