2026 年 6 月 27 日 · DeepSpec 已开源 · GitHub 1,832 Stars · 已部署 DeepSeek-V4 预览版
🔥 一、背景：大模型「生成慢」的根源
大语言模型生成文本时采用自回归方式——每生成一个 Token 都需要一次完整的前向传播，推理延迟随输出长度线性增长。这就是为什么 AI 对话一开始"想"半天才蹦出第一个字。
DSpark 要解决的是高并发生产环境中的推理效率瓶颈——当千万用户同时用 AI 时，模型能不能既快又稳？
⚡ 二、核心技术：半自回归 + 置信度调度
推测解码的基本原理
用一个轻量级小模型快速生成多个候选 Token → 大模型一次并行验证所有候选 → 接受符合分布的连续前缀 → 无损生成质量。
但由于验证阶段可并行计算，且严格保证了输出分布与原始模型一致，推测解码能在不损害生成质量的前提下大幅提升速度。
现有方案的两派困境
两派各有利弊，但都解决不了高并发场景下的核心矛盾。
DSpark 的两项创新
创新一：半自回归架构
核心思想： 取两派之长，弃两派之短。
实验结果： 两层 Transformer 深度的 DSpark 即可在所有测试领域上超过五层 DFlash 的接受长度——证明了少量自回归依赖在参数效率上的巨大优势。
创新二：置信度调度验证
DSpark 在每个候选位置输出一个置信度分数，预测该 Token 的"存活概率"。关键创新点：
置信度校准——训练后通过逐位置温度缩放，使置信度与经验接受率对齐
硬件感知前缀调度器——将验证长度选择建模为全局吞吐量最大化问题： - 给定一批并发请求及其各位置置信度 - 结合预先实测的引擎吞吐量曲线 - 动态决定为每个请求验证多长的候选前缀 - 优先将计算资源分配给全局存活概率最高的 Token
🔑 核心创新点： 不是"固定验证长度"，而是根据置信度动态分配验证资源——在高并发时自动缩短验证长度避免资源争用，低并发时拉长验证长度充分利用空闲算力。
📊 三、性能数据
离线基准测试
测试覆盖： 数学推理（GSM8K / MATH500 / AIME25）+ 代码生成（MBPP / HumanEval / LiveCodeBench）+ 日常对话（MT-Bench / Alpaca / Arena-Hard）
在线生产环境实测
DeepSeek-V4-Flash 引擎：
DeepSeek-V4-Pro 引擎：
单用户生成速度提升：57% 至 85%。
负载自适应行为
🧪 四、DSpark 的局限
🌍 五、与国际顶级方案的对比
与国际顶级模型的差距
🔮 六、未来方向
📌 七、总结
DSpark 是北京大学与 DeepSeek 联合推出的推测解码推理加速框架，以半自回归架构 + 置信度调度验证两项创新，在保证生成质量无损的前提下，实现了单用户推理速度 60%-85% 的提升，以及高并发场景下最高 661% 的吞吐量提升。
三个核心信号
🏆 半自回归取了「两派之长」——并行架构的带宽优势 + 自回归的依赖建模精度，DSpark 用 2 层 Transformer 打平 5 层并行方案
🏆 置信度调度是高并发场景的"杀手锏"——不再是固定的验证长度，而是根据系统负载动态分配算力
🏆 完整开源是最大的诚意——不仅发了论文，还开源了全部训练代码、评估脚本和模型权重。1,832 Stars 代表社区用脚投票
一句话总结
DSpark 不是在「更快」和「更好」之间做取舍——半自回归架构保证了候选质量，置信度调度保证了资源效率。当大模型推理加速从「单点突破」走向「系统优化」时，DSpark 交出了一份兼顾学术创新和工程落地的满分答卷。
原文链接
欢迎访问 小易撩挨踢