一句话看懂：Hugging Face 与 LiquidAI 联合发布 LFM2.5 系列专用的 DSpark 草稿模型，通过投机解码让大模型推理速度最高提升约 3.18 倍，且不改变输出质量，并已获得 llama.cpp 和 SGLang 的官方支持。
事件核心：发生了什么
8 月 20 日，LiquidAI 在 Hugging Face 博客发布 LFM2.5 家族三款模型的 DSpark 草稿模型检查点，覆盖 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这些草稿模型仅为约 3 亿参数的 attention-only 结构，通过 DSpark 投机解码方案，为原始模型增加一条并行解码路径。测试数据显示，在 H100 GPU 上吞吐量最高提升 3.18 倍，在 M4 Max MacBook 上最高提升约 2.87 倍；针对 LFM2.5-2.6B 的多工具调用场景，函数调用延迟平均降低 57%。该方案已在 llama.cpp 与 SGLang 中实现上游开源集成，开发者可即日使用。
为什么重要
大模型推理的 decode 阶段在传统架构中受限于内存带宽，而非算力，大量时间消耗在从 DRAM 读取权重到 SRAM 的过程中。DSpark 用轻量草稿模型一次生成多个候选 token，再由目标模型单次前向验证，将权重读取成本分摊到更多 token 上。相比此前的 EAGLE-3、DFlash 等方法，DSpark 结合了并行骨干、马尔可夫链顺序头和置信度调度验证器，在保持贪婪解码输出与基线完全一致的前提下换取 2 至 3 倍的速度提升。这种“质量不变、速度翻倍”的特性，让投机解码从实验室走向实际部署成为可能，也强化了开源小模型在边缘设备和端侧推理场景中的竞争力。
对用户/开发者/创作者的影响
对开发者而言，DSpark 草稿模型已可直接通过 llama.cpp 和 SGLang 调用，无需改动现有应用即可获得推理加速，尤其适合构建 Agent 类应用，因为函数调用的多轮交互延迟可得到显著压缩。对部署在 MacBook 等端侧设备的用户来说，LFM2.5-2.6B 在 M4 Max 上可达到约 139 tok/s 的平均速度，多个数据集上突破了 130 tok/s，已超越不少云端闭源模型的交互体验。对自建推理服务的团队来说，以约 3 亿参数换取 2 至 3 倍吞吐，意味着相同 GPU 资源下可服务更多请求，或可降低推理成本。但需要注意，加速效果因数据集分布差异较大——LFM2.5-1.2B-Instruct 在不同任务上的加速比波动最高达 52%，实际部署前建议先用目标数据集做基准测试。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
目前公开信息显示，DSpark 训练数据混合了 SFT、聊天、代码和函数调用数据，但训练细节只披露了 5 层解码器、9 的 block size 和 15 个 epoch 的选择策略，完整的消融实验和数据配比尚未发布，可关注后续技术报告。另外，草稿模型的加速效果高度依赖目标模型与草稿模型的分布匹配度，LFM2.5-8B-A1B 的端侧与 GPU 加速数据尚未在素材中完全展开，值得等待更完整的基准测试。最后，投机解码是否会成为主流推理优化方向，取决于各大推理框架（如 vLLM、TensorRT-LLM）是否跟进 DSpark 的集成进度，以及闭源模型厂商是否会在 API 服务中默认启用类似机制。
