DSpark 把推测解码拉进「半自回归 + 置信度调度」时代:DeepSeek 联合北大在生产环境跑出 60%-85% 端到端提速 6 月 27 日,DeepSeek 联合北京大学发布推测解码新框架 DSpark(Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation),创始人梁文锋位列作者。这不是又一次「主模型权重升级」,而是一次针对 LLM 在线推理系统瓶颈的工程级突围:在生产 V4-Flash/V4-Pro 引擎上,相比已服役的 MTP-1 基线,DSpark 在相同吞吐下让单用户生成速度提升 60%-85%,并在 120 TPS 这类高交互 SLA 下把系统可用吞吐抬升 6.6 倍。 DSpark 的解法分两层。草稿端,主体沿用并行 backbone,尾部接一个轻量 sequential block(Markov 头或 RNN 头),把 block 内的局部依赖补回来,既保住并行 drafter 的吞吐,又压住 suffix decay。验证端,confidence head 估计每位置的前缀存活概率,再叠加感知硬件队列的 scheduler,动态决定本次该验证多长,把 target 算力优先投向最可能接受的 token。 实验层面,论文在 Qwen3-{4B,8B,14B} 与 Gemma4-12B 上对齐训练数据与草稿层数,把 DSpark 与 Eagle3(自回归)、DFlash(并行)同台比较:Qwen3-4B/8B/14B 上,macro-average accepted length 在 Eagle3 基础上提升 30.9%/26.7%/30.0%,在 DFlash 基础上提升 16.3%/18.4%/18.3%。三组基准(数学、代码、日常对话)整体上移,不是单一任务偏科。 更值得关注的是生产部署:80 tok/s/user 的中等 SLA 下,DSpark 让 V4-Flash 聚合吞吐提升 51%;120 tok/s/user 的严格 SLA 下,基线 MTP-1 已逼近并发极限,DSpark 仍跑出 6.6 倍可用吞吐。换言之,DSpark 把「延迟-吞吐」这条 Pareto 边界整体外推,让过去「为保交互延迟只能压低并发」的高敏感场景第一次成为默认可选项。 配套开源的 DeepSpec 是另一看点:把 DSpark、DFlash、Eagle3 三种 drafter 的训练/评估代码统一到同一全栈仓库,MIT 协议,同步在 Hugging Face 释放了 Qwen3 与 Gemma4 系列的 12 个训练好的草稿 checkpoint——下游团队可以直接拿去域适配,这才是 DSpark 变成「行业基础设施」的关键一步。