Tencent’s DSpine Just Made 27B Model Inference 3x Faster, But There’s a Catch
The LLM inference arms race just got a new player, and it’s not the one everyone expected. While the industry obsesses over bigger GPUs and fancier quantization schemes, Tencent quietly dropped something on Hugging Face that makes the Qwen3.8-27B model scream, at roughly 3x the throughput of vanilla autoregressive decoding.
But before you rush to swap out your entire inference stack, let’s dig into what DSpine actually does, where the numbers hold up, and the one scenario where it’s actually slower than the competition.
The “Draft in Parallel” Trick That Breaks the Autoregressive Bottleneck
Here’s the fundamental problem with LLM inference: transformers generate tokens one at a time, and each token requires running the entire network. For a 27B parameter model, that’s a lot of compute per token. Coding agents make it worse, they generate long outputs, chain multiple tool calls, and keep context windows wide open.
Speculative decoding solves this with a simple premise: have a small, cheap draft model guess several tokens at once, then let the big model verify them in a single pass. The big model only rejects the guesses that don’t match its own distribution. Output quality stays identical, you’re just skipping compute.
Most drafters work autoregressively, stepping forward one token at a time. DSpine does something different. Instead of sequential generation, it drafts tokens in parallel blocks, with each layer passing predicted predecessor features to adjacent positions. The dependencies get carried through the network’s depth rather than through time, hence the paper’s title, “Draft in Parallel, Condition Through Depth.”
This checkpoint is a five-layer draft model with about 2.03B parameters (roughly 4GB in BF16), a block size of 16, and an 8,192-token sliding window. The code is Apache 2.0 licensed on GitHub, which means you can actually use this thing without legal gymnastics.

The Numbers That Matter: 3.19x on SWE-bench Pro
All benchmarks below are vendor figures, measured with SGLang 0.5.22, BF16, FlashAttention 3, and concurrency 8. Caveats aside, the numbers are impressive:
| Benchmark | AR Baseline | DFlash2 | DSpine | DSpine Speedup |
|---|---|---|---|---|
| WorkBuddy Code | 193.00 | 550.40 (2.85×) | 613.55 (3.18×) | 3.18× |
| WorkBuddy Web | 252.26 | 734.04 (2.91×) | 840.14 (3.33×) | 3.33× |
| WorkBuddy Office | 215.05 | 662.34 (3.08×) | 763.83 (3.55×) | 3.55× |
| SWE-bench Pro | 248.17 | 711.60 (2.87×) | 791.30 (3.19×) | 3.19× |
| τ²-bench | 340.39 | 871.98 (2.56×) | 978.39 (2.87×) | 2.87× |
The best case: WorkBuddy Office at low reasoning hits 3.84x (805.53 tokens/s vs. 210.03 autoregressive). That’s not incremental, that’s the kind of gain that changes GPU provisioning decisions.
DSpine also beats DFlash2 across every acceptance length benchmark. On GSM8K with greedy decoding, DSpine achieves an acceptance length of 7.20 versus DFlash2’s 5.69. On SWE-bench Pro at xhigh reasoning, it’s 4.77 vs. 4.00.
For context on the speculative decoding breakthroughs happening elsewhere, DeepSeek’s DSpark was already pushing the envelope. DSpine builds on that lineage, its dynamic verification references DSpark, with ReplaySSM enabled.
The Reality Check: Where DSpine Slows Down
Here’s where things get interesting. The developer behind MegaCapybara, a local inference engine, ran preliminary tests on an RTX 5090 with Q5-quantized weights. The results:
No-think coding: 420 t/s with DFlash2, 800 t/s with DSpine, nearly 2x improvement
Reasoning mode: 320 t/s with DFlash2, 280 t/s with DSpine, DSpine is slower
The reasoning hit comes from the first 1-2 tokens being less accurate than DFlash2. Qwen3.8-27B loves to reason, it’s baked into the model’s behavior. Losing 40 tokens per second on reasoning-heavy workloads is a hefty hit when the model is generating chain-of-thought by default.
The developer notes this could be trainable, a few extra days of training on the draft model might recover the reasoning speed. But as of right now, the tradeoff is real.
Is This Even a Fair Comparison?
The most important caveat: DSpine drafts 16 tokens per block. DFlash2 drafts 8. That’s not an apples-to-apples comparison, DSpine has twice the speculative budget, which naturally leads to longer acceptance lengths. The vendor figures are solid, but there’s no third-party reproduction yet.
Each agent benchmark subset also replays only 20 conversations. That’s a small sample. And the “SWE-bench Pro replay” methodology replays recorded tool-decision prefixes, which is great for reproducibility but doesn’t perfectly capture live agent behavior.
The NVIDIA developer forums already have DGX Spark users asking about real-world token-per-second gains, configuration stability with SGLang, and thermal management under sustained loads, the questions you actually care about when running this in production.
Getting DSpine Running
If you want to try it yourself, the setup is straightforward:
git clone https://github.com/Tencent/DSpine.git
cd DSpine
pip install -e .
Then serve with SGLang:
sglang serve \
--model-path Qwen/Qwen3.8-27B \
--speculative-algorithm DSPINE \
--speculative-draft-model-path /path/to/Qwen3.8-27B-DSpine-b16 \
--speculative-num-draft-tokens 16 \
--dtype bfloat16 \
--attention-backend fa3 \
--speculative-draft-attention-backend fa3 \
--linear-attn-backend triton \
--enable-linear-replayssm-spec \
--mamba-ssm-dtype float32 \
--mamba-radix-cache-strategy extra_buffer \
--max-mamba-cache-size 64 \
--mem-fraction-static 0.80 \
--context-length 131072 \
--max-running-requests 8 \
--cuda-graph-max-bs-decode 8 \
--min-free-slots-delay 1 \
--sampling-backend flashinfer \
--reasoning-parser qwen3 \
--tool-call-parser qwen3_coder \
--trust-remote-code
The draft model adds about 4GB of VRAM. If you’re already running Qwen3.8-27B near your memory ceiling, that’s a meaningful cost. But for teams with headroom, the throughput gain could offset the added memory.
The Bigger Picture: Speculative Decoding Is the New Frontier
Tencent releasing this under Apache 2.0 while DFlash and similar parallel drafters gain traction signals something: the efficiency battle in LLMs has shifted from model architecture to inference-time tricks. Anyone still running vanilla autoregressive decoding on open-weight models is leaving 3x throughput on the table.
This matters for Qwen3.8-27B model optimizations on consumer hardware too. If you can get 800 t/s on a single 5090, the math on local AI changes. And as edge AI and efficient inference continues to push toward smaller footprints, techniques like DSpine become the bridge between “technically runs” and “actually usable.”
The Verdict
DSpine is a genuine leap forward for coding and agent workloads. The vendor figures hold up across every benchmark category, and the early community tests, while preliminary, corroborate the gains on code generation. The reasoning-mode regression is a real concern, but it’s fixable with more training on the draft model.
The skepticism is warranted though. No third-party reproduction exists yet. The 16-token block size difference muddies the comparison. And agent replays aren’t the same as live, messy production traffic. Run your own benchmarks with your own agent logs before committing.
Speculative decoding is rapidly becoming table stakes for serious LLM deployment. If you’re still serving Qwen3.8-27B with plain autoregressive decoding, you’re leaving 3x speed on the table, and somewhere, someone just replaced you with a smaller GPU cluster.




