如果你在2026年用过任何大语言模型的对话服务，一定体验过那种「等它一个字一个字往外蹦」的焦躁。这种延迟的根源在于自回归生成的结构性代价——每生成一个token，模型就要跑一次完整的前向传播。你问了一个30字的问题，它要用300字回答，背后就是三百轮计算。
6月27日，DeepSeek联合北京大学在GitHub上开源了一套名为DSpark的推理加速框架，目标正是这个问题。随DSpark一并发布的还有DeepSpec——一个用于训练和评估推测解码草稿模型的完整工具包。论文、训练代码、评估脚本和模型检查点全部以MIT协议公开。在Hacker News上，这条消息迅速登上首页第一，当天上午即收获209分和37条评论。
DSpark的全称是Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation，核心思路仍然依托推测解码：用一个轻量的草稿模型快速生成若干候选token，再由完整模型通过单次并行前向传播进行批量验证，接受其中符合目标分布的前缀。这套范式本身并不新鲜，但DSpark在候选生成和验证调度两个环节各自引入了一项关键改进。
半自回归：并行与串行的折中
推测解码领域长期存在两派路线。自回归式草稿模型（如Eagle3）逐token串行生成候选序列，依赖关系建模能力强、接受率高，但生成延迟随候选长度线性增长，部署中只能使用短候选块和浅层网络。并行式草稿模型（如DFlash）在一个前向传播内一次性产出全部候选token，生成延迟几乎与候选长度无关，理论上看更长候选块也不怕。
但并行路线的代价同样明显：每个位置在生成时无法依赖块内前面已采样的token，导致随着候选位置后移，不同语义路径相互冲突、接受率迅速衰减。长候选块的后缀token往往在验证阶段被大量拒绝，反而浪费了目标模型的计算资源。
DSpark的方案是合二为一。它在并行主干网络（基于DFlash改进）之上叠加了一个轻量级的顺序模块。主干网一次性产出所有候选位置的隐藏状态和基础logits，随后由顺序模块逐token注入前缀依赖信息。顺序模块提供两种实现：仅依赖前一个token的马尔可夫头，以及通过循环状态累积完整前缀信息的RNN头。
实验结果表明，两层Transformer深度的DSpark即可在所有测试领域上超越五层DFlash的接受长度。IT之家引用的技术报告数据进一步显示：以Qwen3-4B为目标模型时，DSpark相比Eagle3将平均每轮接受长度提升约30.9%，相比DFlash提升约16.3%。少量自回归依赖的引入，在参数效率上优于单纯堆叠并行层。
置信度调度：不给浪费算力的token买单
候选生成的质量解决了第一个瓶颈，但还有一个工程问题：即使草稿模型产出高质量的候选块，验证阶段仍然需要目标模型为每一批候选token执行前向传播。在并发请求较多的生产环境中，固定长度的验证策略意味着目标模型的算力会被大量分配到高拒绝风险的尾部token上。
DSpark引入的置信度调度验证机制就是为了应对这个问题。模型在每个候选位置输出一个置信度分数，预测该token在给定前面所有token均被接受的条件下的存活概率。训练完成后，研究团队在验证集上通过逐位置温度缩放对置信度进行校准，使其与经验接受率对齐。
在此基础上，硬件感知前缀调度器将验证长度选择建模为全局吞吐量最大化问题：给定一批并发请求及其各位置置信度，结合预先实测的引擎吞吐量曲线，为每个请求动态决定验证多长的候选前缀。调度器异步运行，与零开销调度和连续CUDA-graph重放兼容，将调度延迟隐藏在正常执行中。
在离线基准测试中，研究团队选取了Qwen3系列（4B/8B/14B）和Gemma4-12B作为目标模型，覆盖数学推理、代码生成和日常对话三类任务。生产部署方面，DSpark已集成到DeepSeek-V4-Flash和DeepSeek-V4-Pro预览版服务引擎中。在线生产环境下，相比此前采用的单token基线MTP-1，DSpark在同等吞吐量水平下将单用户生成速度提升了60%至85%。
具体而言：在V4-Flash引擎上，当系统保证单用户生成速度不低于80 tok/s时，DSpark的聚合吞吐量比基线提升51%；当SLA收紧至120 tok/s时，基线已接近运行边界，DSpark实现了标称661%的吞吐量优势。在V4-Pro引擎上，对应不同SLA的吞吐量提升幅度为52%至406%。
DeepSpec：一整套训练设施
与很多开源发布只放模型权重和推理代码不同，DeepSeek这次开源的DeepSpec是一个完整的三阶段训练管线。第一阶段数据准备：下载提示数据、运行目标模型生成答案、构建目标缓存（默认Qwen3-4B配置的缓存可达约38TB）。第二阶段训练：通过train.sh启动，在每张可见GPU上运行训练worker，算法和目标模型通过config_path指定。第三阶段评估：在GSM8K、MATH500、AIME25、HumanEval、MBPP、LiveCodeBench、MT-Bench和Arena-Hard等基准上测量推测解码的接受率。
DeepSpec默认支持三种草稿模型：DSpark、DFlash和Eagle3。研究者和工程师可以在这个基础设施上训练自定义的草稿模型，而不需要从零搭建推测解码的加速组件。DeepSpec默认假设单节点8 GPU配置，同时也支持通过环境变量调整GPU数量。
训练阶段还包含两项系统优化：并行训练时仅传递目标模型的隐藏状态而非完整词表logits，将通信复杂度从O(V)降至O(d)；采用锚点定长序列打包策略，将训练序列中随机采样的多个预测块压缩为密集批次，避免传统填充带来的计算和内存开销。
开源之外的叙事
这件事在HN社区激起的讨论，相当一部分与技术本身无关。最高赞评论直言：「DeepSeek continues to not only push the boundaries but also publish these incredible papers explaining how they achieved their gains — something the American labs no longer do unfortunately.」这种对比情绪贯穿了整个讨论线程。
一种反复出现的解释是：美国AI公司背负着巨额投资回报压力，需要在封闭中寻找竞争壁垒；中国的实验室目前仍处于追赶位置，开源既是协作策略，也是一种建立生态影响力的方式。有评论者也指出，这种状态带来的实用主义利好是真实的：「Self-serving motives are more reliable than altruistic ones.」
技术层面的解读则更具体。DSpark所属的推测解码路线，近半年来进展迅速——LMSys在6月中旬刚发布了DFlash与SGLang Spec V2引擎的联合评测，而DeepSeek的DSpark在此基础上引入了半自回归折中与置信度调度，在工程落地上又推了一步。一位熟悉vLLM生态的评论者还补充指出，DeepSeek在Lookahead Sparse Attention上同样做了大量工作，通过大幅削减内存消耗来进一步压缩推理成本。
DSpark也存在局限。即使后缀token最终被调度器截断，并行主干仍需为所有请求生成完整的初始候选块。对于接受率本身较低的复杂查询，这部分草稿计算开销无法回收。此外，DeepSpec当前主要面向Qwen3和Gemma系列作为目标模型，扩展到更多模型族还需要社区贡献。
DeepSeek此次开源，恰与同一天GPT-5.6受美国政府审批制的新闻构成对照。一边是推土机式的工程开放，一边是许可证闸门的收拢。无论背后的战略动机如何，DSpark和DeepSpec确实降低了推测解码的落地门槛，让任何团队都可以在自己的模型上训练定制草稿模型。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。