News · 2026-08-02

llama.cpp shipped DSpark for DeepSeek V4 Flash, and almost everyone called it the wrong name

llama.cpp release b10228 merged support for DeepSeek V4 Flash's embedded speculative-decoding head, giving local runners a path to the same acceleration DeepSeek uses in its own hosted stack. The head in the current 0731 checkpoint is called DSpark, not MTP, and the distinction is not pedantic: the two are different components that shipped in different checkpoints, and much of the coverage told people to enable the one their model does not contain.

Key facts

• What landed: pull request #25784 in llama.cpp release b10228, plus converter pull request #26452 that can split the embedded draft tensors into a separate GGUF.
• The correction: the older V4 Flash preview embedded MTP with DSpark supplied separately; the new 0731 checkpoint embeds DSpark and no MTP.
• Measured effect: roughly 2x decode throughput for one user on a large multi-GPU rig, and a slowdown for another on a 24 GB card with CPU offload.
• Primary source: the llama.cpp pull request discussion, where the author and a project maintainer disentangle the two heads.

For most of the past week, running DeepSeek's newest model locally meant leaving speed on the table. DeepSeek's hosted stack and the vLLM and SGLang serving engines could use the model's built-in draft head; llama.cpp, which is what most people actually run on a desktop, could not. That gap closed with b10228.

Then the naming problem started. Multi-token prediction, usually shortened to MTP, is the label the community attached to the merge, and it stuck. In the pull request thread the port's author and a llama.cpp maintainer take the trouble to separate the two components explicitly: the earlier V4 Flash preview shipped with MTP baked into the weights and DSpark offered as a standalone draft checkpoint, while the 0731 release inverted that, embedding DSpark and shipping no MTP at all. So "MTP support landed" is a true statement about the runtime and a misleading instruction for anyone running the model people are actually downloading. The thing to enable is DSpark.

What DSpark does is speculative decoding, a trick that has become standard in fast serving stacks. A small, cheap drafter guesses the next several tokens. The full model then checks all of those guesses in a single parallel pass instead of one sequential step per token, keeping the guesses that survive and discarding the rest. Done correctly, the output distribution is mathematically identical to running the big model alone. The saving comes from replacing several slow trips through a huge model with one.

DSpark's specific contribution is a fix for what DeepSeek's paper calls suffix decay. In a naive parallel drafter, every guessed token is produced without knowing what the other guesses were, so the fourth or fifth token in a draft block is essentially guessing blind and almost never survives verification. DSpark adds a lightweight sequential head that lets later draft tokens condition on the earlier ones, plus a confidence scheduler that stops verifying a suffix once it looks doomed. The analogy is a junior colleague drafting a paragraph: if each sentence is written without reading the previous one, the paragraph falls apart by the end, and no amount of parallelism fixes it.

The results in the thread are genuinely split, and that split is the useful part. One user reported roughly doubling decode throughput on a very large multi-GPU configuration. Another, running a 24 GB card with layers offloaded to system memory, got measurably slower. That is not a bug so much as the shape of the trade. Speculative decoding spends extra arithmetic to buy fewer sequential passes, which is a win when you have compute to spare and the model is stalling on memory. When you are already starved for memory bandwidth and paying overhead to launch many small graph operations, the extra work costs more than the saved trips. The port's author separately flags excess graph splits as unfinished work, which is exactly the kind of overhead that hurts small configurations most.

It is worth noting that none of this was a bottleneck on the hosted path. DeepSeek's own 0731 model card documents DSpark working directly in vLLM and SGLang with a seven-token speculative block and no separate draft checkpoint required. The local ecosystem was the one catching up.

The broader shift this exposes is that speculative decoding has quietly become a packaging decision rather than a serving optimisation. Labs increasingly ship the drafter inside the released checkpoint, which means a runtime has to know which auxiliary head is in the box before it can use it. That is a new class of compatibility problem, and it will not be the last time a release note and a checkpoint disagree about what is inside. It sits alongside the other V4 Flash edge people found this week: quantizing the model's KV cache in llama.cpp changes which tokens it picks.

The honest caveat is that nobody has published an acceptance-rate table by hardware class. Until someone characterises which configurations gain and which lose, the only reliable advice is to measure it on your own machine, with your own workload, before assuming the headline applies to you.

Primary source, verified: read the paper →

Ground Truth. (2026, August 2). llama.cpp shipped DSpark for DeepSeek V4 Flash, and almost everyone called it the wrong name. Ground Truth. https://groundtruth.day/news/llama-cpp-shipped-dspark-for-deepseek-v4-flash-not-mtp.html

@misc{groundtruth:llama-cpp-shipped-dspark-for-deepseek-v4-flash-not-mtp,
  title  = {llama.cpp shipped DSpark for DeepSeek V4 Flash, and almost everyone called it the wrong name},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/llama-cpp-shipped-dspark-for-deepseek-v4-flash-not-mtp.html}
}

Topics: deepseek · llama-cpp · speculative-decoding · local-ai · inference · open-weight-models