文章核心观点 - 公司在获得500亿融资后，迅速发布并开源了推测解码优化框架DSpark，重点在于工程落地层面的优化，而非模型版本迭代 [3] - 该框架旨在通过提升大模型推理速度来降低部署和服务的成本与门槛，解决产业真实痛点，标志着行业竞争焦点从单纯模型跑分转向“更快、更省算力”的落地效率 [14] 技术发布与落地验证 - DSpark框架已全面部署于公司自身的DeepSeek-V4-Flash和V4-Pro线上服务，替代了此前的MTP-1生产基线 [6] - 在同等系统总吞吐下，V4-Flash的单用户生成速度提升60%-85%，V4-Pro提升57%-78% [6] - 该框架已完成真实用户流量落地验证，并已兼容部署到阿里旗下的Qwen3-4B、8B、14B以及Gemma4-12B等国内外主流基座模型 [6][7] 技术原理与突破 - 推测解码是行业公认的解决大语言模型自回归生成延迟问题的路径，即用轻量级草稿模型快速生成候选token，再由大模型批量验证 [9] - 现有方案存在短板：自回归草稿模型（如Eagle3）草稿耗时随块长线性增长；并行草稿模型（如DFlash）存在生成质量瓶颈和系统效率瓶颈 [11][12] - DSpark提出两项互补机制解决瓶颈：一是半自回归生成架构，在并行主干中加入轻量级串行模块以提升依赖建模能力；二是置信度调度验证机制，根据实时吞吐动态决定最优验证长度 [13] - 实验表明，仅两层Transformer深度的DSpark即可在所有测试领域超过五层DFlash的接受长度 [13] 性能表现与优势 - 在Qwen3-4B/8B/14B模型上，DSpark的宏平均接受长度相对Eagle3提升30.9%、26.7%、30.0%；相对DFlash提升16.3%、18.4%、18.3% [8] - 该优势具备跨模型泛化能力，在Gemma4-12B目标模型上也取得了一致的性能增益 [8] - 性能提升存在领域差异：结构化任务（如数学推理、代码生成）的可接受长度天然更高，例如Qwen3-4B在数学任务上平均为5.57，代码任务为5.12；而开放式对话场景则明显偏低，仅3.49 [8] 开源生态与产业影响 - 随DSpark一同开源的DeepSpec是一个用于训练和评估推测解码草稿模型的全栈代码库，包含数据准备工具、草稿模型实现、训练代码和评估脚本，支持MIT许可 [3] - DeepSpec已内置DSpark、DFlash和Eagle3三种实现 [3] - 配套仓库、模型权重全部开源，使得缺乏底层算法团队的中小企业和ToB服务商无需投入巨额研发即可复用成熟推理优化方案，大幅降低大模型私有化部署和线上服务的落地门槛 [7] - 智能体、工业代码、金融舆情等场景的规模化落地速度有望因此加快 [7] 当前局限与未来方向 - 当前方案对于本身可预测性极低、接受率偏低的复杂查询，存在前置草稿算力无法回收的局限 [8] - 未来的优化方向可在草稿模型内部引入难度感知的早退出机制，使此类请求能够跳过完整块生成流程 [8]

核心观点 - 在获得500亿融资后，公司迅速联合北京大学发布并开源了推测解码优化框架DSpark及相关工具库DeepSpec，此举并非模型迭代，而是聚焦于工程落地层面的效率优化[1] - 该技术通过“半自回归生成架构”和“置信度调度验证机制”两项突破，有效解决了现有推测解码方案在生成质量和系统效率上的瓶颈，实现了显著的推理加速[7][8][9] - 该框架已成功部署于公司自有模型及阿里Qwen、谷歌Gemma等国内外主流基座模型，并经过真实用户流量验证，能大幅降低大模型私有化部署和线上服务的门槛，加速产业规模化落地[3][4][11] 技术发布与落地验证 - 公司于6月27日发布论文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，并开源了用于训练和评估推测解码草稿模型的全栈代码库DeepSpec，支持MIT许可[1] - 该框架已全面部署于DeepSeek-V4-Flash和V4-Pro的线上服务，替代了原有生产基线，在同等系统总吞吐下，V4-Flash单用户生成速度提升60%-85%，V4-Pro提升57%-78%[3] - 除自有模型外，DSpark也已部署到阿里Qwen3-4B/8B/14B及谷歌Gemma4-12B等模型上，并在数学推理、代码生成、日常对话三大评测领域验证了效果[3] 性能表现与数据优势 - 论文数据显示，DSpark在全部目标模型和评测领域下，性能稳定超越自回归基线Eagle3与并行基线DFlash[5] - 以Qwen3系列模型为例，DSpark的宏平均接受长度相比Eagle3提升26.7%至30.9%，相比DFlash提升16.3%至18.3%，该优势在Gemma4-12B模型上也取得了一致的性能增益[5] - 实验数据揭示了显著的领域差异效应：结构化任务（如数学推理、代码生成）的可接受长度天然更高，而开放式对话场景则明显偏低[6] 技术原理与突破 - 大语言模型自回归生成方式导致推理延迟随输出长度线性增长，推测解码是行业公认的解决路径，即用轻量级草稿模型快速生成候选token再由大模型批量验证[7] - 现有方案存在短板：自回归草稿模型（如Eagle3）草稿耗时随候选块长线性增长；并行草稿模型（如DFlash）虽能并行生成，但存在无法建模token依赖导致接受率衰减，以及系统效率瓶颈[8] - DSpark通过两项技术实现突破：1）半自回归生成架构，在保留并行高吞吐优势的同时加入轻量级串行模块注入前缀依赖信息，仅两层Transformer深度即可超过五层DFlash的接受长度；2）置信度调度验证机制，动态决定最优验证长度，优先将算力分配给预期回报最高的token[9] 行业影响与战略意义 - 公司在完成大额融资后并未单纯追求参数规模扩张，而是关注落地效率，直击产业在推理速度和算力成本方面的真实痛点[11] - DSpark框架及配套工具、模型权重的全面开源，使得缺乏底层算法团队的中小企业及ToB服务商无需投入巨额研发即可复用成熟的推理优化方案，大幅降低了大模型私有化部署和线上服务的门槛[4] - 在生成式AI从实验室走向商业化的周期里，“更快、更省算力”正在取代单纯的模型跑分，成为厂商竞争力的关键指标，该技术的发布有望加速智能体、工业代码、金融舆情等场景的规模化落地[11][4]

闻乐 发自 凹非寺 量子位 | 公众号 QbitAI 梁文锋署名的DeepSeek新论文 DSpark 你可能刷到过了—— 单用户速度提升85%、高并发场景有效吞吐翻4倍。 但你真的看懂了吗？ 别急，有人替你拆解了一遍。 Fireworks AI的联合创始人兼CTO、PyTorch核心维护者 Dmytro Dzhulgakov 将整篇论文梳理成了10个概念，从最底层的GPU访存特性讲 到最上层的在线自适应调度。 他认为： DeepSeek这套方案真正的精髓在于系统工程和模型协同设计 。 相关基础思路前人已有提出，难能可贵的是其将各类技术融合为一套自适应完整系统，实现了端到端的显著性能优化。 下面我们就顺着这10个概念过一遍DSpark。 10个概念理解DSpark 批处理解码（Batching in LLM Decoding） 想要搞懂大模型各类推理加速技术，首先要理解GPU一个非常特殊的运行特性： 让GPU同时解码10个token，其实只比解码1个token慢一点点。 卡帕西曾经讲过，原因在于大模型推理的瓶颈不是浮点运算，而是 显存带宽 ，GPU大部分时间花在把模型权重从显存搬到计算核心上。 搬一次也是搬， ...