DSpark: 置信度调度的半自回归生成推测解码

TL;DR DSpark 采用半自回归草稿建模 token 间依赖，结合置信度调度按需截断验证，在并行投机解码中同时缓解接受率衰减与 batch 浪费，于 DeepSeek-V4 线上实现 60–85% 加速并拓展吞吐-延迟帕累托边界。

问题

当前LLM推理面临的核心瓶颈在于高并发服务 中的延迟与吞吐权衡。推测解码通过小模型草稿+大模型验证 加速推理，但现有并行草稿方法在效率上仍有不足。

现有方法局限：并行草稿模型（如Medusa、EAGLE）虽能单次前向生成多个token，但由于各token独立生成，缺乏token间依赖，导致序列尾部token接受率显著下降（后缀衰减）。而验证阶段往往将整个草稿块送入目标模型，即使其中大量token极可能被拒绝，这种验证浪费 在批处理中严重挤占资源，降低系统吞吐。

为何难/重要：在高并发实时服务中，单请求加速与系统吞吐存在尖锐矛盾。盲目延长草稿虽可能加速单请求，但被拒绝token的验证开销将导致吞吐崩塌。现有方法通常采用固定草稿长度或启发式早停，无法感知请求的置信度 与系统负载动态调整，难以兼顾尾延迟 与吞吐。业界迫切需要一种负载感知的自适应推测解码方案。

行业类比：就像视频会议系统根据网络带宽动态调整编码参数，而非固定使用最高码率，以同时保证流畅度和画质。

核心洞察

• **半自回归拖拽器用极低的自回归开销换取了并行生成的质量补全。** DSpark 在并行生成骨架之后插入轻量级顺序模块，仅输出少量自回归步，便为草稿序列引入了必要的块内 token 依赖。这不同于完全自回归的拖拽器（延迟高）或纯粹并行的拖拽器（后半段接受率急剧衰减），它以最小的延迟增量大幅提升了长序列的接受长度，揭示了“少量自回归”在推测解码中的高性价比设计空间。
• **置信度调度验证首次在请求级别动态截断验证长度，将系统吞吐纳入决策回路。** 传统推测解码对所有请求均验证固定长度草稿，忽略不同前缀的存活概率差异及验证失败对批处理资源的浪费。DSpark 通过标定后的置信度头估计每个请求的前缀存活概率，再结合推理引擎的吞吐量曲线，为每个请求在线计算最优验证长度。这一机制在真实高并发流量下避免了吞吐量陡降，有效移动了服务系统的帕累托前沿，对工程部署极具参考价值。

方法

DSpark 的输入是待续写的 prompt token 序列，输出是加速生成的后续 token。其方法核心分为两大模块：半自回归草稿生成 (Semi-Autoregressive Generation) 和 置信度调度验证 (Confidence-Scheduled Verification)。

半自回归草稿生成

该模块旨在突破传统并行草稿器块内 token 独立假设导致的后缀接受率衰减。它由两个子阶段串行构成：

• 并行骨干 (Parallel Backbone)：在一次前向传播中同时产生长度为 K 的候选 token 序列。由于缺乏顺序依赖，首位 token 质量高，但后续 token 与真实分布偏差递增。
• 轻量顺序模块 (Lightweight Sequential Module)：沿时间轴逐 token 引入局部的自回归依赖，用很小的计算开销修正骨干输出，有效抑制块内分布漂移，从而提升草稿整体被目标模型接受的概率。

置信度调度验证

该模块解决固定长块验证造成的算力浪费问题。其技术链路为：

1. 置信度头 (Confidence Head)：在草稿生成时，为每个候选 token 预测一个“存活概率” (即被目标模型接受的置信度)。训练后经过后验校准 (Post-hoc Calibration)，使预测更贴合真实接受率。
2. 硬件感知前缀调度器 (Hardware-Aware Prefix Scheduler)：以请求为单位，根据各 token 的存活概率和当前引擎的吞吐-延迟特性曲面，动态截断验证长度——只保留前缀中连续高置信的 token，舍弃大概率被拒绝的尾部 token。该调度策略直接以系统吞吐量最大化为目标，而非简单设定统计阈值。

最终，经截断的草稿块送入目标模型进行串行验证，仅通过校验的 token 被追加到输出序列，未通过的部分被丢弃并由目标模型自行补全。

与同类方法的关键差异：将并行草稿质量优化与系统级验证调度统一，既用轻量自回归缓解块内分布衰减，又用硬件感知的置信度截断策略主动规避无效计算，使加速收益从离线指标向高并发服务吞吐有效传导。

实验

实验设计

离线评估：在多个领域通用基准上，对比 DSpark 与当前最优的自回归 drafter 和并行 drafter（如 Medusa、EAGLE）的 accepted length，衡量草稿质量。 在线部署：将 DSpark 集成至 DeepSeek-V4 生产服务系统，在真实用户流量下运行，以该系统已有的 MTP-1 方案为基线，记录相同吞吐水平下的每用户生成速度、吞吐动态变化及服务帕累托前沿。

关键发现

• 离线效果：DSpark 在所有测试域上均大幅提升 accepted length，超越自回归和纯并行 drafter，验证半自回归架构对后缀衰减的有效抑制。
• 在线加速：在匹配吞吐条件下，DSpark 将每用户生成速度提升 60% 至 85%，成功减少因盲目验证长序列导致的批量容量浪费。
• 帕累托前沿推移：通过在严格交互延迟约束下防止吞吐量崩塌，DSpark 解锁了此前不可达的性能层级，直接提升服务系统的吞吐-延迟上限。

与基线对比的深度解读

DSpark 的核心增益来自两个协同设计：

1. 半自回归生成：并行 backbone 生成初始 token 保持高吞吐，轻量级序列模块仅对块内后续位置建模依赖，以极低的计算开销换取后缀 token 接受率的显著提升，解决了纯并行 drafter 的“第 2 位置后接受率骤降”问题。
2. 置信度调度验证：置信度头在线估计每个请求的前缀存活概率，结合硬件感知的吞吐曲线动态截断验证长度。相比 MTP-1 等固定长度验证，该方法在高并发下能精准识别高风险 token，避免将稀缺的批处理容量消耗在几乎必然被拒绝的 token 上，从而使系统在负载波动时保持更稳定的吞吐。

从系统视角看，DSpark 并非简单的 token 生成加速，而是将算法优势转化为可靠的系统承载能力。它证明：在 LLM 服务中，面向负载的调度策略与草稿质量同样重要，仅提升离线 accept rate 而忽略验证阶段的资源分配，无法在高并发场景获得成比例的系统级收益。

行业影响

落地场景

DSpark 专为高并发、低延迟的 LLM 推理服务设计，可广泛应用于需要实时生成响应的产品线：

• 智能客服与对话系统：同时服务海量用户会话，要求生成速度快、资源利用率高，防止尾延迟恶化。
• 代码补全与编程助手：对延迟极度敏感，需在数十毫秒内返回多个 token 的建议，且请求频率高、波动大。
• 内容创作与实时翻译：在 C 端应用中保持流畅的输出体验，吞吐量直接影响用户留存。

商业价值

降本增效是核心驱动：

• 硬件成本：同等服务等级目标（SLO）下，DSpark 将每用户生成速度提升 60–85%，意味着单次推理功耗与服务器需求大幅下降，直接节省 GPU 租赁或采购开支。
• 用户体验与收入：更低的延迟和更高的吞吐韧性，让服务能够在突发流量下依然满足交互性约束，避免因延迟卡顿导致的用户流失，提升付费转化与日活。
• 技术壁垒：DSpark 将服务系统的帕累托前沿整体前移，实现过去无法达到的吞吐-延迟组合，为产品提供竞争护城河。

与现有工作流的集成

DSpark 可作为即插即用的推理加速层，无缝融入主流 LLM 推理栈：

• 适配现有引擎：可与自研框架（如 DeepSeek 的部署系统）或开源方案（vLLM、TGI）结合，只需替换草稿策略和验证调度逻辑。
• 训练友好：半自回归草稿模型和置信度头可轻量化训练，支持从目标模型蒸馏，无需大量额外标注数据，降低引入门槛。
• 动态调度 API：提供请求级的验证长度调节，方便上游平台根据实时负载与业务优先级灵活控制，与 Kubernetes 或自研调度器协同。

具体用例

• 电商平台全球客服：某电商在节日促销期间需处理百万级并发会话，利用 DSpark 在相同 GPU 集群上将客服机器人的响应速度提升 70%，成功扛住峰值流量且大幅降低资源扩容成本。
• 云端 IDE 代码补全：某开发者工具在免费策略下面临高并发推理压力，集成 DSpark 后，代码补全的 P99 延迟下降 40%，使得更多用户从 IDE 插件进入付费订阅。

局限

• **场景依赖与部署复杂度**：论文指出 DSpark 在高并发、严格延迟约束的场景下效益最显著，低负载或延迟预算宽松时增益边际递减，且顺序模块可能略微增加单请求延迟。部署依赖校准数据集拟合置信头，以及引擎特定的吞吐量剖面（throughput profiles），若服务环境动态变化，需配套在线校准与自适应剖析机制，否则通用性受限。目前该方法已在 DeepSeek-V4 上线，但在其他 LLM 架构上的泛化性尚未充分验证。
• **半自回归的延迟权衡**：DSpark 在 draft 阶段引入轻量顺序模块，缓解了并行 draft 的尾部衰减，但也带来了额外的序列依赖步骤。即使该模块设计极轻量，仍会增加 draft 推理的延迟开销，在短序列生成或极低延迟场景下可能抵消部分吞吐收益。论文虽分析了 drafter 深度与延迟的关系，但未给出极端低延迟（如每 token 服务时间 < 20ms）下的性能临界点，这值得进一步探索以明确适用边界。
• **系统对比覆盖有限**：离线评测对比了部分并行与自回归 drafter，但缺乏与更广泛推测解码策略（如基于树的验证、自适应 draft 长度、验证与 draft 并行等）的系统性消融。线上对比主要针对 DeepSeek 内部基准 MTP-1，缺少与业界主流推测解码框架（如 Medusa、Lookahead）在同等流量条件下的横向比较，这影响了对该方案相对优势的全面评估。