DFlash and the Warp-Drive Trick for Faster LLM Inference

I run DeepSeek V4 Flash on my own hardware — no cloud API, no per-token bill. The tax I pay for that is decode speed, and this month I went looking for a way to lower it. That search led me to DFlash, a genuinely clever ICML 2026 paper out of UC San Diego, and to a physics analogy that turned out to explain the whole idea better than any diagram I could draw.

The Physics of Going Faster

Push a spacecraft toward light speed and the energy bill does not scale linearly. As velocity approaches c, the energy required to keep accelerating climbs toward infinity — you are pouring in more and more raw power for smaller and smaller gains. Every kilogram of reaction mass you burn buys you less speed than the kilogram before it.

Fiction's answer to that wall is the warp drive. Instead of accelerating the ship through spacetime, a warp field compresses spacetime ahead of the hull and expands it behind. The ship itself never locally exceeds light speed — space does the moving. It is not more thrust; it is a shortcut through the problem the raw-power approach can never solve.

Same Wall, Different Domain

Autoregressive decoding — the way every GPT-style model generates text by default — hits an analogous wall. Producing token N+1 requires a full forward pass through the model, which mostly means streaming the entire set of weights (or at least the active experts, for a mixture-of-experts model) out of GPU memory. That is memory-bandwidth-bound, not compute-bound: throwing more raw FLOPs at the problem barely moves the needle, because the bottleneck is how fast you can read weights off HBM, once per token, forever. More hardware buys you a shrinking slice of extra speed — the LLM-inference version of burning reaction mass for diminishing returns.

DFlash: Compress the Problem, Not the Ship

DFlash, from Zhijian Liu's Z Lab at UC San Diego, is the warp-drive move for this problem. Classic speculative decoding already tries to get around the wall: a small, fast "draft" model proposes several tokens, and the big "target" model verifies them all in one parallel pass, accepting the ones that match what it would have generated anyway. But the established approach to drafting — EAGLE and its predecessors — is still autoregressive: the draft model guesses tokens one at a time, blind to the target model's internal state, and plenty of guesses get rejected.

DFlash changes the drafting step itself. It uses a lightweight block diffusion model that proposes an entire block of candidate tokens in a single forward pass — not one at a time. Crucially, that draft model is conditioned on context features extracted directly from the target model, and those features are injected into the draft model's key-value cache across every layer. The draft is not guessing blind; it has a compressed view of what the target model is already "thinking," which is why its guesses land far more often. The ship (the target model) is not doing more work per token — the space around the problem (how the draft is generated) has been reshaped.

Straight From the Paper

I do not like citing a technique I have not actually read the paper for, so here is DFlash's abstract, verbatim, from Chen, Liang and Liu's DFlash: Block Diffusion for Flash Speculative Decoding (arXiv:2602.06036, presented at ICML 2026):

"Autoregressive large language models (LLMs) deliver strong performance but require inherently sequential decoding, leading to high inference latency and poor GPU utilization. Speculative decoding mitigates this bottleneck by using a fast draft model whose outputs are verified in parallel by the target LLM; however, existing methods still rely on autoregressive drafting, which remains sequential and limits practical speedups. Diffusion LLMs offer a promising alternative by enabling parallel generation, but current diffusion models typically underperform compared with autoregressive models. In this paper, we introduce DFlash, a speculative decoding framework that employs a lightweight block diffusion model for parallel drafting. By generating draft tokens in a single forward pass and conditioning the draft model on context features extracted from the target model, DFlash enables efficient drafting with high-quality outputs and higher acceptance rates. Experiments show that DFlash achieves over 6x lossless acceleration across a range of models and tasks, delivering up to 2.5x higher speedup than the state-of-the-art speculative decoding method EAGLE-3."

Full paper: arxiv.org/abs/2602.06036. Code: github.com/z-lab/dflash.

The Numbers

DFlash's own benchmarks, and they hold up:

"Lossless" is doing real work in that first line — this is not a quantization trade-off. The target model still verifies every token; DFlash only changes how fast good candidates arrive.

Where DFlash Runs Today

Notably absent from that list: Ollama. If your serving stack is Ollama, DFlash is not available to you yet — full stop.

The Cheaper Cousin: Multi-Token Prediction

Not every model needs a separate draft model. Several recent releases — DeepSeek V4, Gemma 4, Qwen3 — ship with native multi-token prediction (MTP) heads: small extra prediction layers trained alongside the main model that reuse its own hidden states to guess several tokens ahead. It is a lighter version of the same trick DFlash pulls: reuse computation you already paid for instead of paying for a full forward pass per token. No separate draft checkpoint required, but also a smaller win than a purpose-built block-diffusion drafter.

My Own Stack, Honestly

Here is where the research stopped being abstract. I run DeepSeek V4 Flash locally through a custom engine called ds4-server, and it turns out I already had a 3.6 GB MTP draft model downloaded — sitting on disk, unused. Enabling it is a three-flag change:

--mtp ~/ds4/gguf/DeepSeek-V4-Flash-MTP-Q4K-Q8_0-F32.gguf
--mtp-draft 2
--mtp-margin 3

The honest caveat, straight from the ds4 README: MTP is "experimental," provides "at most a slight speedup," and is "useful only for greedy decoding." Its draft state is not even persisted across KV disk-cache checkpoints — it resets every time a cached session reloads. Worth flipping on, since the model is already sitting there. Not worth expecting much from.

Ollama fares worse for my setup. I am on 0.20.7, which predates MTP support entirely — 0.30+ is required, and even then, only for models with embedded MTP heads like Gemma 4 or Qwen3. A GitHub PR proposing separate-draft-model support for Ollama was rejected; the ADAPTER field in a Modelfile is for LoRA adapters, not draft models. There is no path to loading DeepSeek V4's separate MTP GGUF through Ollama today.

DFlash itself is a non-starter on my current stack for two independent reasons: ds4-server is a custom inference engine with no DFlash support, and there is no DFlash checkpoint published for DeepSeek V4 Flash yet — the z-lab/dflash collection covers Qwen, Kimi, Llama, Gemma and gpt-oss, not DeepSeek. Getting there would mean moving to vLLM or SGLang, a real infrastructure decision, not a config flag.

Why This Matters for SAP and Enterprise AI

Sovereign, on-premise AI has a latency floor. Below roughly 30 tokens per second, an interactive copilot stops feeling usable — no matter how private the underlying data stays. That floor is exactly what speculative decoding, MTP and DFlash alike, is built to push back. The interesting part for consulting work is that the win is not really about which model you pick. It is about which serving engine you commit to. Ollama, vLLM and SGLang each unlock a different subset of these techniques, and that choice — made early, often for convenience — quietly caps how fast a local deployment can ever get.

Conclusion

The warp-drive framing stuck with me because it is accurate, not just cute: DFlash does not throw more compute at the problem, it restructures the problem so less compute is needed per token. That is the difference between chasing diminishing returns and finding an actual shortcut. My own hardware is not there yet — MTP is a modest, already-available win; DFlash is the one I am watching, waiting for a DeepSeek V4 Flash checkpoint and a reason to move to vLLM or SGLang. If you are running large models on-premise and decode speed is your bottleneck, this is worth the half-day of reading.