DeepSeek近日公开了DSpark技术报告及DeepSpec代码库，引发AI领域对推理优化的新讨论。此次发布的DSpark并非新模型，而是为DeepSeek-V4底座模型新增的服务端推测解码模块，旨在提升模型上线后的响应速度与成本效率。
根据技术报告，DSpark已部署于DeepSeek-V4线上服务系统。在真实用户流量测试中，相比上一代推测生成方案MTP-1，V4-Flash的每用户生成速度提升60%至85%，V4-Pro提升57%至78%。但需注意的是，这一速度提升主要针对生成阶段，即模型输出token的环节，长提示词预处理、检索、工具调用等环节仍会影响整体响应时间。
AI行业正从训练成本竞争转向推理成本优化。模型训练如同一次性工程，而推理则像持续消耗的“水电费”——只要用户发起请求，模型就需消耗算力。大模型服务的核心指标逐渐聚焦于速度与单位token成本，API定价通常按输入输出token分别计费，企业内部分拆模型、缓存、路由等成本项时，推理效率直接影响商业化可行性。
技术突破体现在草稿生成策略的优化。现有方案分为自回归与并行两类：前者通过前文预测后文，延迟随草稿长度增加；后者一次性生成整段候选，但各位置独立预测导致接受率下降。DSpark采用“半自回归生成”，先并行提出候选，再通过轻量顺序层修正后续token的条件关系，兼顾速度与连贯性。系统会根据候选置信度与当前负载动态调整验证长度——GPU空闲时多验证，负载高时聚焦高概率候选，避免算力浪费。
DSpark并非完全独立的技术路线，而是对现有推测解码方案的集成与创新。SpecInfer早在2023年将小模型预测与并行验证引入服务系统；Medusa于2024年提出多解码头预测后续token；EAGLE系列通过动态草稿树提升接受率。推理框架如vLLM、SGLang也已将推测解码作为降低延迟的工具。DSpark的独特性在于同时解决草稿生成、连贯性保持、负载适配等生产问题，技术指标从“模型能力提升”转向“每用户生成速度”“匹配吞吐”等服务侧词汇。
与DeepSeek-V4同步开源的DeepSpec代码库，提供了训练与评估推测解码草稿模型的完整流程，并公开了Qwen3、Gemma等模型的相关检查点。但项目文档明确提示，复现需满足严格条件：默认Qwen3-4B配置下目标模型缓存接近38TB，训练脚本假设单节点8张GPU，对齐论文结果需完全一致的训练设置，特定领域还需额外微调草稿模型。这意味着，线上服务中的速度提升数据源于DeepSeek自身的硬件规模与流量分布，开源内容更多是方法论而非环境复现。
社区讨论聚焦于技术边界与复现难度。AI研究者Ravid Shwartz Ziv指出，DSpark通过置信度判断头与负载感知调度器，在并行与自回归草稿器间取得平衡，且保持无损特性。工程师Rafael Caricio在双DGX Spark GB10上运行V4-Flash的DSpark模式，单流解码速度达60 tok/s，约为MTP-1的1.5倍，但同时提到长上下文场景下草稿接受率显著下降。Tech2Wild的现场数据也显示，结果高度依赖硬件型号、框架版本、上下文长度等变量，换环境后差异可能极大。
推理优化正成为AI公司竞争的新维度。当模型能力差距缩小，如何以更低成本、更快速度交付服务成为关键。DSpark的价值在于证明，同等能力下可减少推理算力浪费——这延续了DeepSeek一贯的低成本高效路线。从模型训练到API定价，外界关注的焦点已从参数规模转向成本效率。
开源模型生态同样受益。过去，开源模型常被视为“便宜选项”，但实际部署时显存、吞吐、延迟等成本问题凸显。DeepSpec公开Qwen3、Gemma等检查点，表明推理优化已突破单一模型范畴。尽管迁移效果取决于社区适配、框架支持与硬件兼容性，但DSpark至少为开源推理降低成本提供了可行路径。当其他框架与硬件跟进，推测解码或从企业工程选择演变为行业通用手段。
