Tencent's DSpine draft model makes Qwen3.8-27B up to 3.8x faster

What this is about

Tencent has published an unusual model on Hugging Face: Qwen3.8-27B-DSpine-b16. It isn't a chatbot. It's a helper model built to make the language model Qwen3.8-27B answer much faster. The technique behind it is called DSpine. It's described in a paper posted as an arXiv preprint (arXiv:2609.36173) titled "Draft in Parallel, Condition Through Depth: Adjacent Causal Injection for Speculative Decoding" by Haohui Zhang and colleagues. You'll find the weights at huggingface.co/tencent/Qwen3.8-27B-DSpine-b16 and the code at github.com/Tencent/DSpine. The release quickly got picked up on r/LocalLLaMA, where people asked: "3x faster decoding for 27B models?"

What speculative decoding is

Normally a language model writes its answer one token, or word fragment, at a time. For every single token, the entire large model has to run once. This is called autoregressive decoding (AR). It's slow, mostly because the GPU has to keep loading all of the model's weights from memory.

Speculative decoding tackles exactly that. Think of an assistant who drafts sentences that the boss only has to sign off on. A small, fast draft model guesses several upcoming tokens in advance. The large model then checks these suggestions in a single pass. That step is called verification. Every token the large model would have produced itself is accepted. From the first mismatch onward, the large model takes over again. Because the large model always has the final say, answer quality stays the same in principle. It just gets faster.

How much you gain depends on how many draft tokens get accepted on average, and how little time the drafting itself takes.

What DSpine does differently

Classic draft models also guess token by token, just with a smaller network. Newer methods like DFlash instead draft a whole block at once, in parallel. That's fast. The catch: each position in the block doesn't really "know" what sits at the position before it. So the drafted tokens fit together less well.

DSpine tries to get the best of both. According to the model card, it drafts tokens in parallel, but each layer of the network passes its predicted predecessor features to the neighboring position. That way, causal dependencies ("token B follows token A") are carried layer by layer through the depth of the network. Hence the paper's title: draft in parallel, condition through depth.

Key specs of the released checkpoint:

• five layers as a draft model for Qwen3.8-27B
• block size 16: it proposes 16 tokens at once. For comparison, DFlash2 officially uses 8.
• sliding window of 8,192 tokens: the draft model only looks at the last roughly 8,000 tokens of the text.
• dynamic verification modeled on the DSpark method, plus ReplaySSM. Judging by the launch parameters, Qwen3.8-27B apparently uses linear attention or state space (SSM) layers in part. When drafts are rejected, their internal state has to be rolled back correctly.

The numbers

Tencent measured with SGLang 0.5.22, in BF16, with FlashAttention 3 and eight concurrent requests. The first table isn't clearly labeled in the model card. Most likely it shows the average number of accepted tokens per verification step, where higher is better. Runs used greedy sampling (T=0) and random sampling (T=1, top_p 0.95, top_k 20), with up to 4,096 new tokens and the highest reasoning level ("xhigh").

DSpine helps most with math and code, meaning text with a highly predictable structure. In open-ended conversation (MT-Bench), its lead is small.

The agent tests are closer to real-world use. For each category, 20 recorded conversations, including every tool decision, were replayed in sequence, with prefix caching and up to 32,768 new tokens per request. The metric is throughput in tokens per second. The speedup over standard decoding is in parentheses.

At the "xhigh" reasoning level, DSpine lands between 2.87× (τ²-bench) and 3.55× (WorkBuddy Office). DFlash2 reaches 2.56× to 3.08× there. On average, DSpine squeezes out roughly another 10 to 25 percent over DFlash2. The often-quoted "4x faster" isn't quite reached in any test. The peak is 3.84×.

What you need to try it

This isn't one for your gaming PC. The reference setup runs the full Qwen3.8-27B in BF16, meaning full 16-bit precision. The weights alone take up roughly 54 GB of VRAM (video memory). On top of that come the draft model and the cache for up to 131,072 tokens of context. In practice, you'll need an 80 GB datacenter card such as an H100. The launch command also uses FlashAttention 3, which is built for Nvidia's newer datacenter GPUs (Hopper). Macs, CPU-only setups and Ollama aren't supported. There's no GGUF version, and Tencent says nothing about combining it with 4-bit variants. Installation runs via git clone, pip install -e . and a long sglang serve command with --speculative-algorithm DSPINE.

The bigger picture

DSpine is mainly interesting for operators running Qwen3.8-27B on their own servers, for example for coding agents or office automation. Getting a good three times as many tokens per second on the same hardware means noticeably lower costs and shorter waits, without worse answers. That holds as long as verification works correctly, anyway. For home users it matters indirectly: if the method makes its way into llama.cpp or similar tools, local models could benefit too. For now, though, it's tied to SGLang.

Caveats: all measurements come from Tencent. The WorkBuddy benchmarks appear to be Tencent's own test suites. The only comparison is with DFlash2, not other well-known methods like EAGLE. The gain depends heavily on the task and is much smaller for free-form conversation than for math. And the draft model only works with exactly one target model, Qwen3.8-27B. Other models would need their own draft model trained. The model card doesn't state a license.