SGLang开源并行推测解码：吞吐最高4倍，因果依赖嵌入草稿网络

在大模型无损推理加速这条路上，推测解码已经是工业界的常规配置。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？

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

消融实验里有个挺反直觉的结果：中间层要是直接上全词表交叉熵（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 大基准。

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倍加速。

团队加了逐层注入和末层条件选词，吞吐为何还能大幅刷新？SGLang 单轮解码的模块级耗时拆解给出了答案。先看延迟：5 层注入在算子融合与 CUDA Graph 配合下，每轮合计只多花 0.15 毫秒。

• 末层条件解码这块，靠转移缓存（Transition Cache）的并行预计算预先把结果算好，DSpine 的耗时不到 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 与通用业务负载下直接体验加速效果。