大模型推理太慢？端侧设备跑不动？现在，这些痛点迎来了硬核解法。近日，Liquid AI 联手 Hugging Face 丢出了一枚“提速炸弹”——正式发布 LFM2.5 系列（涵盖 1.2B-Instruct、2.6B 及 8B-A1B 三款核心模型）的 DSpark 草稿模型检查点。

这项新技术的杀手锏在于：通过引入全新的投机解码路径，在绝对不牺牲模型输出质量的前提下，让推理吞吐量实现了跨越式增长。

性能狂飙：端侧体验迎来“质变”

在实际跑分中，DSpark 草稿模型交出了一份极其亮眼的答卷。数据显示，在 GPU 环境下，整体推理吞吐量最高飙升了 3.18 倍；即便是在算力受限的端侧设备上，最高增幅也达到了 2.87 倍。

更令人兴奋的是它在端侧智能体（Agent）场景下的表现。以 LFM2.5-2.6B 为例，其函数调用的平均延迟大幅缩减了 57%。如果你使用的是搭载 M4 Max 芯片的 MacBook Pro 作为测试平台，本地推理速度最高能飙到每秒 139 个 token。这意味着，在本地流畅运行复杂的智能体应用门槛被大幅拉低，其丝滑体验甚至能硬刚部分云端专有模型。

技术解密：DSpark 是如何打破速度瓶颈的？

要理解 DSpark 的魔力，得先看看传统大模型推理的“堵点”在哪。通常情况下，推理阶段的延迟主要卡在内存带宽上——模型权重从 DRAM 流式搬运到 SRAM 的过程极其耗时。

“投机解码”就是为了疏通这个堵点而生的。它就像写作时的“草稿与精修”：先让一个轻量级的草稿模型快速生成“候选词”，再让目标大模型在单次前向传播中进行统一“批改验证”，从而把加载权重的成本有效摊薄。

而 DSpark 在现有方案上进行了深度融合，祭出了三大核心组件：
1. 并行主干网络：借鉴了类 DFlash 的设计风格，以目标模型的上下文特征为条件，在一次前向传播中就能为所有草稿 token 批量生成隐藏状态。
2. 顺序头（Markov 头）：通过模拟相邻 token 间的马尔可夫链来增强依赖关系，巧妙提升了后续位置的接受率。
3. 置信度调度验证器：像个精明的质检员，实时预测每个 token 的存活概率。一旦发现验证成本高于节省的成本，就会果断剪除低置信度的后缀。

在架构和训练上，开发团队也做到了极致精简。草稿模型吸收了包含 SFT、对话、代码及函数调用在内的大规模多样化混合数据。经过严格的消融实验，最终打磨出一个仅包含注意力机制（attention-only）的轻量架构。它仅有 5 层和 9 个块，总参数量被精准控制在 3 亿左右。

质量零妥协，生态开箱即用

提速虽爽，但大家最关心的往往是“会不会变笨”。得益于投机解码的严谨机制，在贪心解码模式下，草稿 token 必须与目标模型的分布严丝合缝才会被放行，一旦被拒绝就会被目标模型自身的 token 取代。因此，最终生成的输出序列在结构上与基线贪心解码完全一致，各项基准测试的准确率做到了零折损。

对于开发者而言，DSpark 的生态友好度也直接拉满。发布首日，它就无缝接入了主流推理框架：
– SGLang：提供专属的集成与启动配置，完美支持在加速器上运行。
– llama.cpp：获得官方构建支持，只需通过命令行即可轻松加载相应的 GGUF 权重与草稿模型文件。

目前，相关的 Safetensors 和 GGUF 格式检查点已在 Hugging Face 平台全面开源。从云端的大规模加速器到边缘侧设备，DSpark 正在为开发者的广泛部署提供强有力的弹药。大模型推理的“狂飙”时代，或许才刚刚开始。