腾讯优图DSpine开源：并行草稿逐层接力，SGLang吞吐最高提升4.01倍

在大型语言模型（LLM）的无损推理加速里，推测解码（Speculative Decoding）已经是工业界的常规配置。EAGLE-3 这类自回归草稿模型预测确实准，可每多猜一个 token，就得多跑一步串行前向；DFlash 则借了扩散语言模型的思路，把草稿生成彻底改成并行——骨干网络一次前向就能同时吐出整块候选 token，起草耗时因此被大幅压缩。

不过并行起草一直卡在一个核心矛盾上：算后一个位置的时候，它压根不知道前一个位置最后会挑哪个词。

这种“盲猜”会带来严重的多模态碰撞和后缀衰减（Suffix Decay）。每个位置单看概率都说得通，拼到一块却前后打架。目标大模型是按从左到右的严格前缀顺序验证的，中间某个位置衔接不上被拒，后面已经算好的草稿 token 就全部作废。

为了补上并行草稿的因果依赖，DeepSeek 近期提出的 DSpark，以及 Domino、DFlash2 等工作都拿出了改进方案。问题是现有做法要么把依赖注入放到骨干网络算完之后（比如 Domino、DSpark 的轻量串行头），后继位置在特征形成阶段感知不到前驱倾向；要么在骨干内部直接混合相邻隐状态（比如 DFlash2 的局部卷积），把上下文信息和预测信号搅在一起。

腾讯优图实验室、上海交通大学和厦门大学的研究团队针对这一瓶颈提出了 DSpine（Draft in Parallel, Condition Through Depth）。

DSpine 的核心思路可以概括成八个字：同时起草，逐层接力。它不等前一个位置最终定下离散 token，而是从草稿网络第 1 层起，就把前驱位置“正在形成中的预测特征”提取到统一的词元嵌入空间，逐层注入给紧邻的后继；到网络末端选词时，再用转移缓存（Transition Cache）并行预计算相邻候选组合分数，靠已确定的前驱 token 完成条件修正。

• 论文标题：Draft in Parallel, Condition Through Depth: Adjacent Causal Injection for Speculative Decoding

• 论文链接：https://arxiv.org/abs/2609.36173

• 开源代码：https://github.com/tencent/dspine

• 模型权重：https://huggingface.co/collections/tencent/dspine

• 项目主页：https://dspine-project.github.io

在 Qwen3-4B 和 Qwen3-8B 的接受长度评测以及 SGLang 服务吞吐评测中，DSpine 在所有数据、并发场景中都拿到 SOTA：对比 DSpark，SGLang 服务吞吐平均提升 19.0%（8B）和 20.1%（4B）；对比最强基线 DFlash2，平均提升 11.1%（8B）；相对标准自回归解码，最高实现 4.01 倍加速。

团队还新训练了面向 Agent 专项优化的 Qwen3.8-27B DSpine 草稿模型。在开源 SWE-bench Pro、τ²-bench 以及真实办公场景 WorkBuddy Bench（Code / Web / Office）的评测中，开启思考模式下，平均接受长度最高达 5.63，解码吞吐在并发 8 条件下最高达自回归的 3.84 倍。

眼下 DSpine 已经落地服务于腾讯 WorkBuddy 线上推理业务，推理代码和开源模型权重（七大基准平均接受长度高达 7.83）都已全面开放。

图 1 DSpine：同时起草，逐层接力。图中为 DSpine 与主流投机方案对比，接受长度为 Qwen3-8B 在七个基准上的平均接受长度。

一、两个关键实验洞察：前词线索何时出现？何时注入最有效？

并行草稿为什么“各说各话”？拿中文续写举个直观的例子：共同上文是“门口有一……”，位置 1 候选有“只”、“辆”，位置 2 候选有“猫”、“车”。“一只猫”和“一辆车”都是高频自然续写，可两个位置若在一次前向里各自独立选词，很容易拼出“门口有一辆猫”这种荒谬组合。

要让位置 2 知道位置 1 想选“辆”还是“只”，真得等 5 层骨干网络全部算完、位置 1 吐出最终 token 吗？

研究团队对并行草稿模型的中间层做了逐层探针与干预实验，得到两个直接驱动 DSpine 设计的实证发现：

• 1. 靠前位置的预测信号在浅层就已浮现：同样的浅层网络深度下，块内靠前位置的 token 预测准确率远高于靠后位置。也就是说，后继位置的预测还在慢慢成形时，前驱位置在浅层就已经有了可读出的预测线索，完全能在最终选定 token 之前把信息传给下游。

• 2. 前驱位置的意义不止于“内容”本身，“越早注入”带来的好处同样明显：即便更早的历史上下文毫无差错，只要把紧邻前驱替换成存在偏差的草稿预测，后继预测的准确率仍会平均下滑 31.8 个百分点。换句话说，全局上下文再准确，也顶不上紧邻前词给出的直接约束。另有数据支撑这一点：注入相同的可靠前驱特征时，选择在浅层提前注入，准确率平均比延后注入高出 14.8 个百分点。

结论很明确：相邻位置的因果依赖不该拖到骨干网络结束再做“事后补救”，而应从第 1 层起就进入后继位置的表征计算。

二、DSpine 方法解析：把因果链折进网络深度

基于上述洞察，DSpine 在保持单次前向、同层全位置并行更新的前提下，用四项核心设计把因果依赖构建在网络深度（Depth）之上。

图 2 DSpine 整体架构：草稿网络把前驱预测特征逐层传递给后继，到最终选词环节才使用已经确定的前驱 token；同一层内部的更新依然是并行进行的。图源：DSpine 论文。

1. 统一传递空间（Unified Transfer Space）：只传“选词倾向”，不传混杂隐状态

直接把前驱位置的 Transformer 隐状态传给后继，隐状态里混杂了大量上下文聚集信息，后继位置很难从中剥离出“前驱到底想选哪个词”；可要在中间层直接做词表解码，十几万词表的计算开销又让人接受不了。

DSpine 的思路，是借目标大模型冻结的 LM Head 输出嵌入矩阵，搭出一个统一的传递空间：先对 LM Head 做归一化与 PCA 白化，去掉所有 token 共享的共性分量、留下核心主方向，从而得到紧凑词元表。到了骨干网络内部，每一层都把隐状态经轻量投影变成预测特征；末端选词时，已经定下来的离散前驱 token 直接查表，映射成对应的词元向量。这样一来，「预测中的特征」和「已选定的 token」落在同一个几何空间里，代数形式也完全一致，DSpine 便能用同一套注入通路，把层间特征传递和末端条件解码接在一起。

2. 逐层门控相邻注入（Adjacent Causal Injection）：同层之内并行，跨层之间接力

草稿网络每一层 Transformer 之后，位置 t 会收到紧邻前驱 t-1 的预测特征，再结合自身特征算出个门控（Gate），自己决定吸收多少前驱信息、写回残差流多少。并行性为什么保得住？每一层内部，所有位置读到的都是本层更新前的特征，整块位置在同一层里完全并行。前驱位置在第 l 层给出的线索，则进入后继位置第 l+1 层的计算，再一步步往后传。因果依赖链就这么顺着网络深度逐层铺开，串行骨干步数一步也不用加。

3. 逐层输出嵌入监督：全词表 CE 为何不能用？

DSpine 在每层注入之后，直接拿真实目标 token 的紧凑嵌入来算余弦方向对齐损失（Directional Alignment Loss），为的是逼浅层早点形成清晰的预测特征，并跟末端注入的真实 token 嵌入对上。

消融实验里有个挺反直觉的结果：中间层要是直接上全词表交叉熵（Token CE）监督，接受长度不涨反跌，多项基准上甚至掉到无监督的 DFlash 基线以下。原因不难理解，硬让中间层隐状态直接做全词表分类，会挤占、干扰后面层要用的上下文表征计算；DSpine 只对低维投影的方向加余弦约束，预测线索在浅层就清楚浮出来，完整隐状态 meanwhile 仍能自由服务上下文建模。

4. 末层条件解码与转移缓存（Transition Cache）：串行选词改成并行查表

骨干算完后，每个位置先挑出初始 Top-K 候选集。接下来从左往右正式选词：前驱位置一旦定下具体 token，DSpine 就把最后一层注入模块的输入从预测特征换成真实词向量，直接修正后继位置的候选得分（Last-Write Refinement）。

问题是，每定一个前驱才算一次后继得分，就退化成串行矩阵运算了。DSpine 为此引入转移缓存（Transition Cache）：末层修正只依赖紧邻前驱的候选 token，于是模型在选词开始前，一次性并行算出所有相邻位置候选组合的条件得分矩阵。之后从左到右选词，只要在缓存表里极速查表，逐位置的串行矩阵乘法开销就彻底没了。

三、实验结果：28 组接受长度与 40 组服务吞吐全部第一

研究团队拿 Qwen3-4B 和 Qwen3-8B 做了系统对比，对手是 DFlash、Domino、DSpark、DFlash2 与 DSpine，评测覆盖数学（GSM8K、MATH-500）、代码（HumanEval、MBPP、LiveCodeBench）和对话（MT-Bench、Arena-Hard）共 7 大基准。

1. 接受长度：28 组评测全拿第一，采样模式下优势更大

图 3 七项基准上的接受长度对比。DSpine 在两个模型、两种温度下均全面领先。图源：DSpine 论文。

两个模型、两种温度（温度 0 贪心与温度 1 采样）、七大基准，凑成 28 组测试，DSpine 每一组都拿到最长接受长度：

• Qwen3-8B：温度 0 下，七基准平均接受长度从 DFlash 的 3.77、DSpark 的 4.32、DFlash2 的 4.39 显著提升至 4.82（在数学推理 GSM8K 和 MATH-500 上分别达到 5.67 和 5.49）；温度 1 下，平均接受长度从 DSpark 的 3.92 提升至 4.42，相对提升达 12.8%。

• Qwen3-4B：温度 0 和温度 1 下平均接受长度分别达到 4.75 和 4.38，采样模式下比最强基线领先 10.1%。

2. SGLang 端到端服务吞吐：较 DSpark 平均提速约 20%，最高 4.01 倍加速

主流推理引擎 SGLang 上的高并发端到端实测，覆盖 GSM8K、MATH-500、HumanEval、MBPP 四大任务与 2~32 五档并发度，两个模型合计 40 组服务测试，DSpine 照样全部第一：图 4 不同任务与并发下的 SGLang 服务吞吐对比。图源：DSpine 论文。

• 对 DSpark：Qwen3-8B 平均服务吞吐提升 19.0%（最高提升 22.1%），Qwen3-4B 平均提升 20.1%（最高提升 22.5%）。

• 对 DFlash 与 DFlash2：Qwen3-8B 上，DSpine 平均吞吐较 DFlash 提升 23.3%，较最强基线 DFlash2 提升 11.1%；Qwen3-4B 较 DFlash2 平均提升 6.5%。

• 对原生自回归（AR）解码：Qwen3-8B 端到端吞吐最高加速 4.01 倍，Qwen3-4B 最高达 3.80 倍。

3. 耗时拆解：5 层注入只多花 0.15ms，条件选词速度超过 DSpark 串行头一倍

加了逐层注入、又加了末层条件选词，DSpine 的吞吐为何还能大幅刷新？SGLang 单轮解码的模块级耗时拆解给出了答案。配合算子融合与 CUDA Graph，全部 5 层注入模块每轮合计只增加 0.15 毫秒。末层条件解码这块，靠转移缓存（Transition Cache）做并行预计算，DSpine 的耗时不到 DSpark 和 Domino 后置串行头的一半。

• 算总账，DSpine 单轮总耗时 7.14 ms，DFlash2 是 7.19 ms，两者基本持平。差别在于每轮能连续通过的 token 更多，于是 DSpine 每生成一个有效 token 的平均解码耗时比 DFlash2 低了 10.9%。

• 四、面向 Agent 专项进化：Qwen3.8-27B 实测全面提升

• 大模型从单轮对话走向长程 Agent 之后，深度思考、代码编写、多轮工具调用的负担都更重，推理加速的需求也随之抬高。团队因此在 Qwen3.8-27B 上训练了专为 Agent 场景优化的 DSpine 草稿权重，和官方开源的 DFlash2 权重正面对比。

评测覆盖开源 SWE-bench Pro、τ²-bench 以及真实办公场景 WorkBuddy Bench（Code / Web / Office），每个基准都设 low / xhigh 两档思考强度。

图5 Qwen3.8-27B 在五大 Agent 基准、两档思考强度下的平均接受长度对比。

图6 Qwen3.8-27B 端到端吞吐（tokens/s）及加速比。

DSpine 平均接受长度提升到 5.13，WorkBuddy Office（low）最高达到 5.63。解码吞吐较开源 DFlash2 平均最高提升 21.2%，相对原生自回归最高实现 3.84 倍加速。真实办公六组的平均接受长度提升了 26.1%。

团队还同步开源了面向生产环境的 Qwen3-8B 和 Qwen3.8-27B 草稿权重，推理实现封装成轻量插件，可无缝接入 SGLang。

目前 DSpine 已正式落地，服务于腾讯 WorkBuddy 线上推理业务。开发者挂载 DSpine 插件只需几行命令，就能在自己的 Agent 与通用业务负载下直接体验加速效果。