Tencent has released an auxiliary model that generates candidate answers at multiple positions simultaneously, along with code to run it. Developers can now test whether drafting candidates for the main model to verify speeds up generation.

1. Weights and inference code are available

The GitHub guide dates the DSpine inference code and weights release to October 2026, and the paper to September that year. It gives release dates only by month. The Hugging Face model repository was created on October 16.

The currently supported main model is Qwen3-8B. Training code and a draft model for Qwen3.8-27B remain future plans. This release therefore focuses on inference with published weights rather than training new draft models.

The model card and code repository guide specify the Apache 2.0 license. Developers can review both the public weights and the execution code.

2. Parallel candidates incorporate context across positions

In speculative decoding, an auxiliary model proposes tokens, the pieces of an answer, for the main model to verify. Rather than writing the final answer itself, the auxiliary model prepares a draft for the main model to check.

DSpine computes candidates at each position in parallel while passing prediction features from the preceding position through each draft-model layer. It captures positional dependencies through network layers, not just token order.

3. Match the server version and connect the public weights

The code is distributed as a plugin for the SGLang inference server. The installation guide requires Python 3.10 or later and a CUDA environment. Below is the installation example from GitHub.

git clone https://github.com/tencent/dspine.git
cd dspine
python -m pip install -e .

The dependency is pinned to SGLang 0.5.20. The package configuration inherits server internals and states it was developed and tested on this exact release. Check compatibility before assuming an existing server only needs extra settings.

After installation, the server example specifies both the main model and public draft weights. It proposes 16 draft tokens at a time and uses bfloat16. These are example settings, not values presented as optimal for every environment.

4. Distinguish longer accepted drafts from speed gains

The reported metric is acceptance length: the length of the draft accepted by the main model. The target is Qwen3-8B. All three methods compared below were reportedly retrained on Open-PerfectBlend under the same settings.

Sampling temperature controls randomness when selecting output candidates. At temperature 1, average acceptance length across 7 tasks was 6.98 for DSpine and 6.65 for DSpark. At temperature 0, the figures were 7.83 and 7.44, respectively.

DFlash2 averaged 6.53 at temperature 1 and 7.55 at temperature 0. The new method had a higher average acceptance length than both alternatives at each temperature. Results at different temperatures should not be ranked against each other.

The Hugging Face guide says the server example settings were used to measure acceptance length and throughput in the paper. The saved materials omit throughput figures and test hardware. Acceptance length alone cannot establish speed gains.

5. Weigh longer drafts against the extra model's costs

The expected benefit is accepting longer drafts per verification. Loading and running draft weights alongside the main model also adds storage, memory, and compute costs. The repository lists 1,237,763,840 parameters for the draft weights.

This release provides a way to test parallel drafts; adoption depends on measuring whether the benefits of longer drafts outweigh the extra resource costs.