DSpark - DeepSeek 联合北京大学开源的推测解码加速框架
来源:互联网
时间:2026-06-28 14:21:30
DSpark是什么
DSpark这个项目,是DeepSeek和北京大学联合搞出来的一个推测解码加速框架。简单来说,它要解决的是大模型自回归生成慢得像“挤牙膏”这个问题。它的设计思路很有意思:采用了一种半自回归的生成架构,用轻量级的Markov头来建模token之间的依赖关系,这样既能保持并行草稿生成的速度,又能保证生成的连贯性。同时,它还引入了一个置信度调度验证机制,可以根据系统当前的负载情况,动态地分配验证资源。这套方案已经在DeepSeek-V4-Flash/Pro的生产环境中跑起来了,效果相当亮眼:单用户的生成速度提升了57%到85%,吞吐量最高能提升400%。而且,整个项目是用MIT协议开源的,兼容Qwen、Gemma这些主流模型,算是为大模型的高效推理提供了一个非常实用的工程方案。

DSpark的主要功能
- :这个思路的关键在于,它保留了并行草稿模型的高速特性,但又在内部加了一个轻量级的Markov头(或者RNN头)来建模相邻token之间的依赖关系。这样一来,就很好地缓解了传统并行方案中容易出现的“后缀衰减”问题——也就是候选序列越往后越不连贯的毛病。
半自回归草稿生成
- :系统会给每个候选token输出一个置信度分数,实时估算这个token被目标模型接受的可能性有多大。这为后面的调度决策提供了重要的依据。
置信度分数预测
- :它会根据系统当前的并发负载、候选token的置信度分数以及引擎的吞吐曲线,动态决定每个请求到底要验证多长的token。说白了,就是系统空闲时多验证,繁忙时就把低置信度的请求精简掉,把资源用在刀刃上。
硬件感知前缀调度
- :这可不是停留在实验室里的方案。它已经集成到了DeepSeek-V4-Flash/Pro的线上服务中,在真实的高并发流量下,实现了单用户生成速度57%-85%的提升,聚合吞吐量更是最高提升了400%。
生产级推理加速
- :除了DeepSeek自家的模型,它也兼容Qwen(通义千问)、Gemma这些主流的开源大模型,应用范围很广。
多模型兼容支持
- :遵循MIT协议开源,代码、论文、训练脚本、模型检查点都完整开放,大大降低了开发者接入的门槛。
全栈开源
如何使用DSpark
部署和使用DSpark的流程很清晰,大致分这么几步:
- :先克隆DeepSpec的开源仓库,配置好运行环境,安装好所有依赖项。
克隆项目
- :下载目标模型(比如DeepSeek-V4、Qwen3或Gemma4)以及对应的DSpark草稿模型检查点。
下载模型
- :加载半自回归草稿模型,然后根据实际需求,选择使用Markov head还是RNN head作为顺序依赖模块。
按需选择依赖模块
- :启用置信度调度验证,并配置硬件感知前缀调度器,让它能够适应当前GPU集群的并发负载与吞吐曲线。
调度验证
- :将DSpark集成到现有的推理引擎中(比如vLLM或者自研的服务框架),用它来替代传统的MTP-1或标准自回归解码流程。
集成引擎
- :最后通过API或者命令行发起请求,系统会自动走完“草稿生成→置信度评估→动态验证→返回结果”的加速推理流程。
发起请求
DSpark的官网地址
- :https://github.com/deepseek-ai/DeepSpec
GitHub 地址
- :https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
Hugging Face
- :https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
技术论文
DSpark的核心优势
- :它保留了并行草稿模型的高吞吐优势,同时通过轻量级的Markov头(或RNN头)建模token间依赖,有效缓解了传统并行方案的后缀衰减问题。简单说,就是生成的草稿既快又好,前后更连贯,接受率更高。
半自回归架构,兼顾速度与连贯性
- :引入置信度分数预测与硬件感知前缀调度器,这种动态调度的策略,避免了在低置信度请求上浪费宝贵的batch capacity。
置信度动态调度,资源利用更智能
- :这个数字相当有说服力——已经部署于DeepSeek-V4-Flash/Pro线上服务,在真实高并发流量中实现单用户生成速度提升
生产级性能提升显著
,聚合吞吐量最高提升57%–85%
。400%
- :不仅支持DeepSeek自研模型,还兼容Qwen(通义千问)、Gemma等主流开源大模型,适用场景非常灵活。
广泛模型兼容性
- :以MIT协议开源完整代码、论文、训练脚本及模型检查点,开发者可以快速集成到vLLM或自己的推理引擎中。
全栈开源,接入门槛低
- :这一点很重要。基于推测解码机制,目标模型的输出分布保持不变,在显著提速的同时,完全不会牺牲生成内容的准确性与质量。
零质量损耗加速
DSpark的同类竞品对比
为了更直观地理解DSpark的定位,不妨把它和目前市面上两类有代表性的方案做个对比。一个是自回归草稿的代表Eagle3,一个是并行草稿的代表DFlash。
| 对比维度 | DSpark | Eagle3 | DFlash |
|---|---|---|---|
技术路线 | 半自回归生成 + 置信度调度验证 | 纯自回归草稿模型 | 纯并行草稿模型 |
草稿生成方式 | 并行块快速生成 + Markov/RNN 头建模块内依赖 | 逐 token 顺序生成草稿 | 一次性并行生成整段候选块 |
依赖建模能力 | 强 | 强 | 弱 |
验证策略 | 动态调度:根据置信度分数与系统负载实时调整验证长度 | 固定或启发式验证长度 | 通常固定验证整段候选块 |
速度 vs 一致性 | 兼顾 | 一致性高但草稿阶段本身较慢,候选越长越吃亏 | 速度快但后缀衰减严重,越往后接受率越低 |
生产环境适配 | 硬件感知前缀调度器,根据并发负载动态分配 batch capacity | 需额外优化以适配高并发调度 | 易浪费 batch capacity 验证低置信度 token |
典型性能表现 | 相比 Eagle3 平均接受长度提升 26.7%–30.9%16.3%–18.4% | 接受长度中等,短序列表现较好 | 接受长度初期高但快速衰减,长序列效率下降 |
从对比中能清楚看到,DSpark在技术路线上选择了中间地带,既吸收了并行草稿的速度优势,又通过顺序模块解决了它的“一致性”短板,同时在验证策略和生产环境适配方面做得很扎实。
DSpark的应用场景
基于这些特性,DSpark在不少实际场景中都能发挥价值:
- :高交互场景下,低延迟是关键。DSpark能显著提升单用户生成速度,直接改善对话的流畅度和用户体验。
实时聊天与对话系统
- :代码生成类任务的候选token接受率很高(平均accepted length能达到5.12),DSpark可以明显加速代码补全、自动纠错和多文件生成这类操作。
代码助手与编程工具
- :在多轮调用、工具链串联的复杂任务中,每轮响应延迟的减少都很宝贵,避免延迟随着轮次叠加而被放大。
多轮 Agent 工作流
- :数学类任务(GSM8K、MATH、AIME等)的候选接受率最高(平均5.57),对于推理步骤长、结构化强的解题场景,效果尤其突出。
数学推理与在线教育
- :通过硬件感知前缀调度器动态适配GPU负载,在真实高并发流量下实现吞吐量最高400%的提升,单位请求成本自然也就降下来了。
高并发云端 API 服务
- :兼容Qwen、Gemma等主流模型,而且是MIT协议开源,对于中小企业和开发者来说,把高效推理能力集成到自己的框架或vLLM引擎中,门槛很低。
开源模型本地部署