腾讯优图DSpine：并行草稿也能逐层接力，SGLang吞吐最高提升

在大型语言模型（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）。

这套机制说白了就八个字：同时起草、逐层接力。草稿网络从第 1 层起，就把前一个位置“还在形成中的预测特征”提出来，映射进统一的词元嵌入空间，再一层一层传给紧挨着的后继位置，不再干等前一个位置把离散 token 最终敲定。等到了网络末端选词，则借助转移缓存（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 服务吞吐在 8B 上平均高出 19.0%，4B 上高出 20.1%；跟最强基线 DFlash2 比，8B 上平均提升 11.1%；对标准自回归解码，最高加速到 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 到底该选“辆”还是“只”，难道非得等 5 层骨干网络全部算完、位置 1 吐出最终 token 才能知道？

研究团队在并行草稿模型的中间层上做了逐层探针和干预实验，由此得到两个直接支撑 DSpine 设计的实证结果。其一，靠前位置的预测信号在浅层就已经浮出来了：网络深度相同的情况下，块内排在前面的位置，token 预测准确率明显高过排在后面的位置。换句话说，后继位置还在慢慢成形，前驱位置在浅层就已经有可读的预测线索，不必等到最终选定 token，就能把信息传给下游。

• 其二，紧邻前驱不光是“内容”要紧，“注入得早不早”同样影响很大。就算更早的历史上下文完全正确，只要紧邻前驱换成了有偏差的草稿预测，后继预测准确率平均会掉 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只对低维投影的方向做余弦约束，预测线索在浅层照样清晰浮现，完整隐状态则能自由服务于上下文建模。

第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大基准。

先看接受长度：28组评测全部排第一，采样模式下优势更明显。

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

测试覆盖两个模型、两种温度（温度 0 贪心与温度 1 采样）以及七大基准，共 28 组，DSpine 在每一组里都拿到了最长接受长度：

• 看 Qwen3-8B：温度 0 时，七基准平均接受长度 DFlash 是 3.77、DSpark 是 4.32、DFlash2 是 4.39，DSpine 提升到 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）并行预计算，耗时不到 DSpark 和 Domino 后置串行头的一半；

• 单轮总耗时上，DSpine 为 7.14 ms，DFlash2 为 7.19 ms，两者基本持平；但 DSpine 每轮能连续通过更多 token，算下来每生成一个有效 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 和通用业务负载上直接感受加速效果。