DeepSeek DSpark 提出混合推测解码架构，推理加速最高85%
DSpark 将并行和顺序推测解码结合，通过在线自适应调度进一步优化，实现端到端推理加速。
大模型推理的瓶颈在于显存带宽，而非算力。连续批处理和推测解码利用这一特性提速。DSpark 混合了并行草稿（DFlash）和顺序修正（Eagle），并用在线调度动态调整验证长度，在已有优化基础上再提速60%-85%。
正文摘录
梁文锋署名的 DSpark，看懂这 10 个点就够了 Fireworks AI 联合创始人兼 CTO、PyTorch 核心维护者 Dmytro Dzhulgakov 将整篇论文梳理成 10 个概念，从最底层的 GPU 访存特性讲到最上层的在线自适应调度。 相关基础思路前人已有提出，难能可贵的是其将各类技术融合为一套自适应完整系统，实现了端到端的显著性能优化。 Karpathy 曾指出，大模型推理的瓶颈不是浮点运算，而是 显存带宽 ——GPU 大部分时间花在把模型权重从显存搬到计算核心上。 这就是 连续批处理：把多个请求的 token 塞进同一个 batch，让每一次显存读取都物尽其用。 理解了这一点，就明白为什么推测解码能奏效：它的本质就是把“猜出来的多个候选 token”打包成一个 batch 送给大模型验证，而验证 batch 的成本远低于逐个生成的成本。 大模型生成是自回归的，第 N+1 个 token 依赖第 N 个 token 的结果，没法直接并行。 但有一种绕路的办法：如果你能「猜」出接下来几个 token 是什么，就可以把猜出来的候选序列一次性喂给大模型做批量验证。 验证通过拒绝采样：系统逐个检查候选 token，接受最长的正确前缀，在第一个分歧点重新采样一个 token。 猜的环节用小模型可以很快，验的环节进行批量验证可以很高效，所以最终每一步都能往前跳好几个 token。 比如用 Qwen 0.8B 给 Qwen 397B 探路：小模型跑得快，生成好候选序列，大模型只需要做一次前向传播来验证。 这个设计把推理过程分成了两个角色：速度型选手——草稿器负责猜，力量型选手——目标模型负责判。 如果草稿器自己跑得太慢，或者一次猜了 16 个 token 但只有前 3 个被接受，那这笔帐就不划算了。