DeepSeek 联合北大发布投机解码框架 DSpark，开源全栈代码库 DeepSpec
DeepSeek 开源投机解码全栈库 DeepSpec（仓库可证实），DSpark 技术报告称无损提速 57%-85%、已上线 V4——但提速口径各源不一，以官方报告为准。
据 X 用户 @0xLogicrw 与 @danielhanchen 转述（以官方技术报告为准），DeepSeek 联合北京大学发布了投机采样加速框架 DSpark 的技术报告，并开源全栈代码库 DeepSpec，DSpark 据称已部署于 DeepSeek-V4 线上业务。转述给出的提速口径是：在输出无损前提下，Flash 版单用户生成速度提升 60%-85%、Pro 版提升 57%-78%，超过原 MTP-1 基线；但同一事件另一口径（@danielhanchen）说的是吞吐提升 51% 到 400%——两套数字差异极大，必须以官方报告与开源代码实测为准。
可以独立证实的部分是：DeepSeek 官方 GitHub 上的 deepseek-ai/DeepSpec 仓库确已公开（MIT 许可证，约 1.8k stars，Python 占比约 98%），自述为「训练与评估投机解码算法的全栈代码库」，README 列出 DSpark / DFlash / Eagle3 三种草稿模型（draft model），目标模型支持 Qwen3（4B/8B/14B） 与 Gemma，并提供从下载提示词、生成目标答案到基准评估的完整 Python 工具链。换句话说，“开源了 DeepSpec、其中含 DSpark”这件事是实的；而提速幅度、与北大联合署名、上线 V4 这些更具体的说法，目前只见于 X 转述。
发生了什么
可证实：DeepSpec 是一套投机解码的全栈开源工具链
抛开提速数字，先看能被官方仓库证实的硬事实。deepseek-ai/DeepSpec 把”做一套投机解码加速”拆成三个阶段，做成了可复现的工程流水线：
- 数据准备（Data Preparation）——下载提示词、用目标模型重新生成答案、构建 target cache（README 提示，按 Qwen3-4B 的默认配置，target cache 体量可达约 38 TB，是个重资产工程）。
- 训练（Training）——
bash scripts/train/train.sh，默认假设单节点 8 GPU。 - 评估（Evaluation）——
bash scripts/eval/eval.sh，内置 gsm8k、math500、aime25、humaneval、mbpp、livecodebench、mt-bench、alpaca、arena-hard-v2 等一整套主流基准。
README 同时致谢了 SpecForge（提供整体训练框架与 Eagle3 实现）与 DFlash（提供 DFlash 草稿模型的设计与训练配方）。这说明 DeepSpec 不是从零造轮子，而是把社区已有的投机解码方法（Eagle3、DFlash）和自家的 DSpark 收进同一个评测/训练框架里——它的价值更像是”投机解码的统一基准与训练台”，而不只是单点放出一个新算法。
据 X 转述（待核实）：DSpark 的四段式架构与提速
接下来是只来自 X 转述、官方 README 并未描述的部分。据 @0xLogicrw，DSpark 的技术路线分四步：
- DFlash 并行主干生成隐藏状态——先用 DFlash 在一次前向里并行起草，产出隐藏状态；
- 轻量马尔可夫头（查表 + 一次矩阵乘）串行注入相邻词关联——在并行草稿之上，用一个极轻的头串行补上相邻 token 的依赖；
- 置信度预测头——预测草稿的可信度，指导验证；
- 异步零开销调度——避免在高并发场景下吞吐崩塌。
这套架构在技术方向上说得通，但具体设计（尤其”马尔可夫头""置信度头""异步调度”）目前无官方原文佐证，需查仓库内的 DSpark_paper.pdf 正文核实。下文”为何重要”会用 DFlash、EAGLE、MTP 等真实方法做技术合理性旁证——旁证不等于已核实 DSpark 原文。
关键数据 / 技术细节
提速数字：两套口径，差异悬殊（均待官方核实）
这是本则最需要警惕的地方。同一事件，两个 X 账号给出的提速幅度对不上：
| 口径来源 | 测的是什么 | 提速幅度 | 对照基线 | 可靠性 |
|---|---|---|---|---|
| @0xLogicrw | Flash 版单用户生成速度 | 60%-85% | 原 MTP-1 | X 转述，待核实 |
| @0xLogicrw | Pro 版单用户生成速度 | 57%-78% | 原 MTP-1 | X 转述，待核实 |
| @danielhanchen | 吞吐（throughput） | 51%-400% | 未明示 | X 转述，待核实 |
两套数字跨度差了一个量级（85% vs 400%），最可能的解释是测的对象不同：一个是单用户生成速度（latency 侧），一个是高并发吞吐（throughput 侧）——投机解码在低并发下提速明显、高并发下常因验证开销而收益衰减，两个场景给出迥异数字并不奇怪。但在官方报告披露精确口径前，任何一个数字都不应被当成定论引用。
把 DSpark 放进投机解码的方法谱系
DSpark 不是凭空出现，它站在一条清晰的技术演进线上。下表把可证实的同类方法的提速口径列出来，作为理解 DSpark 数字的参照系（注意：这些是各方法在各自论文/各自基线下的数字，不可与 DSpark 直接横比）：
| 方法 | 核心思想 | 提速（自身口径） | 来源 |
|---|---|---|---|
| Speculative Decoding（奠基） | 小草稿模型并行起草 + 大模型并行验证，输出分布不变 | 2x-3x（T5-XXL） | arXiv 2211.17192 |
| Medusa | 主模型上加多解码头并行预测，免独立草稿模型 | 2.2x-3.6x | arXiv 2401.10774 |
| EAGLE | 在特征层做自回归 + 超前一步 token 降低不确定性 | 2.7x-3.5x（LLaMA2-70B） | arXiv 2401.15077 |
| DFlash | 轻量块扩散模型单次前向并行起草，以目标模型上下文特征为条件 | >6x 无损，比 EAGLE-3 高最多 2.5x | arXiv 2602.06036 |
| DeepSeek-V3 MTP | D 个串行模块预测 D 个未来 token，保持因果链，可复用于投机解码 | （MTP-1 为 D=1 基线） | arXiv 2412.19437 |
| DSpark（DeepSpec 收录） | DFlash 主干 + 马尔可夫头 + 置信度头 + 异步调度（据 X 转述） | 57%-85% / 51%-400%（口径不一，待核实） | X 转述 + DeepSpec 仓库 |
这里有个容易混淆的点要点破：DSpark 转述里说的”超过原 MTP-1 基线”，MTP-1 指 DeepSeek-V3 报告中预测深度 D=1（即只额外预测 1 个 token）的多 token 预测模块。DSpark 比的不是”朴素逐 token 解码”，而是”已经用 MTP 做过一轮投机加速”之后的基线——这意味着 57%-85% 是在一个本就不慢的起点上再加速，含金量比”相对朴素自回归提速 85%“要高，但也更难直接和 DFlash 的”>6x（相对朴素基线）“对齐比较。口径不统一，正是横比的最大陷阱。
扩展：投机解码为什么能"无损"加速（背景）
投机解码的精髓不在”快”，而在”快且不改变输出”。Leviathan 等人（arXiv 2211.17192）的核心洞察是：困难的语言建模任务里常包含可被小模型较好近似的简单子任务，于是用小草稿模型并行猜若干个 token，再让大模型并行验证——验证通过的直接采纳，验证不过的回退重算。配合一种特殊的采样方法，最终输出分布与标准逐 token 解码完全一致（“identical outputs / without changing the distribution”），所以叫”无损（lossless）”。
后续路线的分歧主要在”草稿从哪来”：Medusa 在主模型上加多个解码头免去独立草稿模型；EAGLE 发现”在特征层而非 token 层做自回归更简单”，并用”超前一步的 token 序列”压低特征不确定性、提高草稿接受率；DFlash 则改用轻量块扩散模型一次前向并行起草。DSpark 转述里的”DFlash 主干 + 马尔可夫头注入相邻词关联”，方向上正是这条”复用主模型特征 + 补相邻 token 依赖以提高接受率”的主线。
为何重要
第一，这是 DeepSeek”压低推理成本”打法在加速层的又一次落子，且选择了开源。 DeepSeek 的品牌叙事一直是”同等性能、更低成本”，过去靠 MLA、MoE、FP8 训练、DeepGEMM/DeepEP/FlashMLA 这些工程化武器压成本。投机解码是直接砍推理时延与单卡吞吐成本的利器，把它沉淀成开源全栈库 DeepSpec、还附上一整套标准基准，等于把”怎么训一个好用的投机解码草稿模型”这件过去藏在各家推理团队内部的活儿公开化、可复现化。对国产模型生态，这降低了复现门槛；对 DeepSeek 自己，开源是放大影响力、吸引社区帮它打磨的惯用手法。
第二，投机解码正在从”论文技巧”变成”线上标配”。 从 2022 年 Leviathan 的 2-3x，到 Medusa/EAGLE 的 2.2-3.5x，再到 DFlash 的 >6x，方法侧的接受率和加速比一路走高；DeepSeek-V3 报告里早已写明 MTP 模块”可复用于投机解码降低延迟”。如果 DSpark 确如转述已上线 DeepSeek-V4，那它就是”头部厂商把投机解码做进旗舰线上业务”的又一个公开案例。这件事的行业含义，不在于某个具体的提速百分比，而在于它再次确认：无损加速已经是大模型推理工程绕不开的标准动作。
第三，“统一基准”的价值可能被低估。 DeepSpec 把 Eagle3、DFlash、DSpark 收进同一套训练/评估框架，内置 gsm8k/humaneval/livecodebench 等基准——这意味着研究者第一次能在同一口径下比较不同投机解码算法。投机解码领域长期苦于”各家用各家的基线、各报各的加速比”（本则两套提速数字打架就是缩影），一个被广泛采用的统一评测台，对整个领域的意义未必小于又一个 +10% 的新算法。
这则新闻最值得记住的，是它把”开源动作”和”营销数字”摊在了同一张桌子上，而两者的可信度并不一样。仓库是实的： deepseek-ai/DeepSpec 你现在就能 clone，README 白纸黑字写着 DSpark/DFlash/Eagle3、支持 Qwen3 与 Gemma、附带一整套基准——这部分没有任何想象空间。数字是虚的： “提速 57%-85%""已上线 V4""与北大联合”全部只来自两条 X 推文，而且两条推文自己就打架——一个说单用户生成快 60%-85%，一个说吞吐快 51%-400%。当一手素材内部都对不齐时，正确的姿势不是挑一个好看的数字写进标题，而是把分歧本身当成事实呈现出来。我们因此把本则的整体置信度压到 medium、把提速相关的 claim 标成 low——不是因为 DeepSeek 不可信，而是因为”X 转述”这个信源等级本就配不上”精确战报”的待遇。
往深一层看，真正有信息量的细节是那句”超过原 MTP-1 基线”。这说明 DSpark 比的不是朴素逐 token 解码，而是 DeepSeek-V3 早就用上的 MTP 投机加速之后的起点——在一个本就不慢的基线上再榨出 57%-85%，工程含金量其实比”相对裸模型快 6 倍”更高，因为越接近物理极限，每一个百分点越贵。但这也正是它没法和 DFlash 的”>6x”直接横比的原因：基线不同、口径不同、测的对象（latency vs throughput）不同。投机解码这个领域最大的认知陷阱，从来不是”谁更快”，而是”大家根本没在同一把尺子上量”——讽刺的是，DeepSpec 这套统一基准框架，恰恰是解这个陷阱的解药，结果它自己的发布却栽在了同一个坑里（两套口径满天飞）。
至于”已部署 DeepSeek-V4”，如果属实，分量不轻：它意味着这不是一篇刷榜论文，而是扛过了旗舰线上业务高并发考验的生产级方案，那句”异步零开销调度避免吞吐崩塌”才有了着力点。但”如果属实”四个字现在还摘不掉——V4 本身都还没有对应的官方发布页可查。所以这则新闻的正确读法是：把”DeepSeek 开源了一套投机解码全栈库”当成已发生的事实记下来，把”它有多快、用在哪”当成一个等待官方报告兑现的悬念。 在 DSpark_paper.pdf 正文和 V4 官方说明出来之前，谁把那串百分比当结论引用，谁就是在替别人的推文背书。
接下来看什么
- 官方报告与精确口径：DeepSeek 是否放出 DSpark 技术报告正文（或仓库内
DSpark_paper.pdf的可读版），讲清 Flash/Pro 版到底测的是单用户生成还是吞吐、相对哪条 baseline——这是给 57%-85% / 51%-400% 两套数字盖棺的唯一办法。 - 两套数字谁对：@0xLogicrw 的 57%-85% 与 @danielhanchen 的 51%-400%，差异是否就是”单用户生成 vs 高并发吞吐”。在官方裁定前，引用任何一个都该带”待核实”。
- 架构细节核实：
马尔可夫头（查表+一次矩阵乘）``置信度预测头``异步零开销调度在论文/代码里的真实定义，是否如转述所言能避免高并发吞吐崩塌——README 目前并未描述这些。 - 生态采用：DeepSpec 的 star/fork 曲线、第三方在 Qwen3/Gemma 之外模型上的复现结果，以及它和 vLLM、SGLang、SpecForge 等推理栈的集成进度（目前仓库仅 3 个 commit，生态尚早）。
- 署名与上线：是否真与北京大学联合署名、合作分工如何；DeepSeek-V4 是否有独立发布以及与 DSpark 的官方关联说明。