前段时间，腾讯开源了推理加速项目 DSpine，最近则把支持扩到了 Qwen3.8-27B。
它让小模型并行起草一段候选，再由大模型集中验证。DSpine 进一步处理了草稿的连贯性：前一个位置的预测会逐层传给后一个位置，让更多候选能连续通过验证。
这项研究由腾讯优图实验室、上海交通大学和厦门大学共同完成。论文 v1 于 9 月 28 日提交 arXiv，论文实验先围绕 Qwen3-4B 和 Qwen3-8B 展开。
10 月 16 日，团队上传了 Qwen3-8B 的配套草稿权重，同期开放推理代码，训练实现也通过 SpecForge 的公开 PR 提供。就在前天，项目再增加 Qwen3.8-27B 的草稿权重和推理支持。
WorkBuddy也在测试里
以最近支持的 Qwen3.8-27B 为例，腾讯用 WorkBuddy 的代码、网页和办公对话做了请求回放。低推理档下，三组吞吐分别达到普通解码的 2.71 倍、3.13 倍和 3.84 倍。
同一轮测试还包括 SWE-bench Pro 和 τ²-bench，具体数据如下：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
单位为 token/s，统计的是 8 路并发回放的合计输出吞吐。测试基于 SGLang 0.5.22、BF16 和 FlashAttention 3，每个子集取 20 段对话，按工具决策前缀依次回放，并开启前缀缓存。
提高到 xhigh 推理档，WorkBuddy Code、Web、Office 的加速比分别是 3.18 倍、3.33 倍和 3.55 倍。
腾讯也对比了 DFlash2。低推理档的 WorkBuddy Code 回放中，DFlash2 为 590.27 token/s，DSpine 为 686.23。这里 DSpine 的块大小为 16，官方 DFlash2 检查点为 8；DSpine 使用的服务配置还包含动态验证和 ReplaySSM。
DSpine怎样加速
DSpine 的核心设计叫 相邻因果注入（Adjacent Causal Injection）：草稿网络每算完一层，就把前一个位置的预测特征送给后一个位置。
并行生成草稿时，后面的位置还不知道前面最终会选哪个 token。候选单独看都合理，接在一起却可能不连贯。目标模型验证时只接收从头连续通过的部分，前面一处没接上，后面的候选就用不上了。
团队分析 DFlash 时发现，靠前的位置在浅层就已经形成了可读出的预测；把这份信息提前送给后继位置，有助于后面的候选在计算过程中及时调整。
DSpine 因而从第一层开始传递前驱信息。门控模块同时看前驱的预测和接收位置自身的特征，决定写入多少消息。下一层接着计算，再把更新后的预测向后传递。各位置在同一层仍然并行更新，依赖关系沿着网络深度逐步建立。
DSpine的整体结构
这也是论文标题 Draft in Parallel, Condition Through Depth 所说的：并行起草，通过深度建立条件关系。
为了传递“前面准备预测什么”，团队从目标模型的输出 embedding 出发，经过归一化、PCA 白化和降维，建立了一张统一的 token 表示表。
token 尚未选定时，用网络预测的低维特征；已经确定时，就查表取得它的表示。两者可以进入同一条注入通路。草稿块内部采用因果注意力，只看目标上下文和不晚于自己的位置，与消息传递方向保持一致。
论文图3b 相邻位置间的门控注入
为了让浅层尽早提供有用的预测，DSpine 给每层加入余弦监督，让传出的特征对齐正确 token 的表示。
训练初期，前驱预测还不可靠，团队会按一定概率换入正确 token 的表示，再逐渐撤掉这项帮助。目标模型、共享输入 embedding 和 LM head 在训练中保持冻结。
这次给 Qwen3.8-27B 配套的草稿器约 2B 参数、5 层网络，草稿侧使用 8,192 token 滑动窗口。b16 的 16 个位置，包含一个已知的起始 token 和 15 个候选位置。
选词之前先算好
草稿网络算完，每个位置还要真正选出 token。前驱一旦选定，就能用它的 token 表示替换原来的预测特征，重新做最后一层的消息写入，修正后继候选的分数。这一步叫 last-write refinement。
DSpine 先为每个位置保留 top-K 候选，再把相邻位置的候选组合提前算好。论文取 K=16，每对相邻位置对应一张 16×16 的分数表：前一个位置选了哪个，后面的候选分别得到多少分。
这些表组成 transition cache。真正从左到右选词时，沿表查结果就行，避免每选一步再做一次矩阵计算。
论文图4 并行预计算与顺序选择
候选生成和这一步修正一起训练，两路输出都结合正确 token 的交叉熵，以及草稿分布与目标分布之间的 L1 距离。
实现中，归一化、投影、门控和残差写入等小操作还被合并进融合 kernel，减少启动开销和中间张量搬运。
论文在 Qwen3-8B 上拆过耗时：DSpine 一轮约 7.14ms，DFlash2 约 7.19ms，五层注入合计增加的开销最多约 0.15ms。
七项基准的另一组贪心解码测量里，两者每轮平均推进量分别为 4.82 和 4.39 个 token，包含目标模型给出的修正或额外 token。这组实验用相同数据和训练预算训练草稿器，目标模型是 Qwen3-4B、Qwen3-8B；前面的 WorkBuddy 成绩来自后续发布的 27B 检查点。
验证也有成本
每轮验证得更宽，需要的计算也会增加，是否划算还要看能多接收多少候选。
Qwen3.8-27B 的 SGLang 实现为此加入了动态验证。草稿仍按块大小 16 生成，实际验证多宽则可以调整；8 路并发时，还能参考草稿置信度，在请求之间分配验证位置。
项目提供了 SPS 调优工具，用代表性的对话前缀测不同验证预算，保存与当前 GPU 绑定的配置。换硬件或工作负载，就重新测。
Qwen3.8-27B 的混合注意力还要处理递归状态：一整块候选验证完，最终可能只留下其中一段。ReplaySSM 负责配合验证后的状态提交，让下一轮从真正接受的前缀继续，缓存边界也随之对齐。
腾讯给出的 CUDA 部署示例基于 SGLang 0.5.22，使用单路张量并行、BF16、FA3 和 Triton 线性注意力后端；训练实现可以从项目链接的 SpecForge PR 获取。
最后
开发者 AJ 已经把这份草稿模型移植到自己的 llama.cpp 分支，并发布了 GGUF。
他用一张 24GB RTX 3090，搭配 Q4_K_M 版 Qwen3.8-27B 测试。更新后的模型卡里，短上下文代码任务达到 128.7 token/s，数学任务为 122.8 token/s；混合任务在贪心解码下，平均从 28.2 提高到 90.1 token/s。
上下文拉长后，速度也会变。以小说为上下文、再生成 256 个 token 时，DSpine 在约 8K 深度为 35.6 token/s，32K 深度为 31.1 token/s。
AJ公布的RTX 3090速度与上下文测试
Mac 这边，Abdur Rahim 把它接进了 mlx-dspark。在他的 M4 Pro 和 4-bit 千问上，调过草稿长度后的 DSpine，短提示加速比为 2.70 倍；DFlash 2 为 2.93 倍。到了 32K 上下文，两者分别为 1.96 倍和 2.13 倍。
这台 M4 Pro 验证 16 行的耗时，约为验证 8 行的 1.65 倍。完整块虽然有约 7.2 的平均接受长度，额外验证却吃掉了部分收益，Rahim 最后选了更短的草稿配置。
llama.cpp 用户目前需要 AJ 的 dspine 分支，Mac 上这份 27B 模型的社区接入可以看 mlx-dspark。腾讯仓库也有官方 MLX 入口，当前说明面向 Qwen3-8B 的全注意力模型。
AJ 提供的草稿 GGUF，Q4_K_M 文件约 1.26GB，需要与对应的 Qwen3.8-27B 目标模型一起加载。
参考链接
-
腾讯 DSpine 项目：https://github.com/Tencent/DSpine -
Qwen3.8-27B 配套草稿模型：https://huggingface.co/tencent/Qwen3.8-27B-DSpine-b16 -
DSpine 论文：https://arxiv.org/abs/2609.36173 -
AJ 的 GGUF 与测试记录：https://huggingface.co/aj9o9/Qwen3.8-27B-DSpine-b16-GGUF -
mlx-dspark：https://github.com/ARahim3/mlx-dspark