Liquid AI 为自家语言模型系列 LFM2.5 发布了一组名为 DSpark 的草稿模型。借助投机解码，在不改变模型输出文本的前提下，GPU 上的吞吐量最高提升 3.18 倍，MacBook 上最高提升 2.87 倍。权重已在 Hugging Face 上公开，llama.cpp 与 SGLang 在发布首日即提供支持。
投机解码究竟加速了什么
大语言模型逐个 token 输出文本时，瓶颈并不在算力，而在于把模型权重从内存搬到计算单元所花的时间。无论是英伟达 H100 这样的高端 GPU，还是 MacBook、手机这类终端设备，情况都一样。每产生一个 token 都要重新读一遍庞大的权重，计算单元大部分时间其实在等待。
投机解码的思路是把这段等待时间摊薄。先由一个小而轻的草稿模型预测接下来的若干 token，主模型再用一次前向计算集中核对。命中的部分批量采纳，从第一个不匹配处交回主模型继续。由于每读一次权重能确定更多 token，体感速度自然提升。
关键在于，贪心解码下的输出在原理上与原来完全一致。草稿 token 只有与目标模型的分布相符时才会被采纳，被拒绝的位置会替换成目标模型本应输出的 token。因此基准测试的准确率不会变化。可以把它理解成只买速度、不动质量的改进。
DSpark 增加的三个部件
DSpark 本身是 2026 年提出的方法，与 EAGLE-3、DFlash 属于同一脉络。其内部由三个部件组合而成。
第一个是并行主干，它接收来自目标模型的上下文特征，一次性为整块候选 token 输出隐藏状态和基础 logits。第二个是轻量的顺序头，把相邻 token 视为马尔可夫链，让每个位置的概率向与前一个已采样 token 相符的方向偏移。纯并行预测在靠后的位置命中率会明显下降，这个部件把依赖关系补了回来，从而提高采纳率。
第三个是按置信度调度的校验器。它用一个独立的头预测每个草稿 token 被采纳的概率，并剪掉那些核对成本高于收益的尾部 token。能够根据硬件余量动态调整校验长度，是工程实现上的巧思。
公开的草稿模型体量很小：5 层结构，块大小为 9，参数量各约 3 亿。Liquid AI 说明，训练与全部消融实验均在 AMD 硬件上、使用其自研训练框架完成。
提速幅度取决于草稿猜得准不准
具体数字会随目标模型和任务类型明显波动。测试环境为单张 H100 80GB 搭配 SGLang，以及搭载 M4 Max 的 MacBook Pro 搭配 llama.cpp 与 Metal，均为批量大小 1、温度 0。评测数据集包括 MATH500、GSM8K、HumanEval、MBPP 和 MT-Bench。
主力的 2.6B 模型在 GPU 与终端两侧均全面改善，在 MacBook 上的生成速度达到每秒 140 token 左右。这已经超过不少商用云端模型的响应水平，也让本地运行的理由变得更充分。
1.2B 模型属于不做推理链的类型，各数据集之间采纳率差异较大，提速幅度的波动可达 52%。8B-A1B 的情况更复杂：GPU 上平均提升 2.54 倍，终端侧却只有 18%。原因一方面在于 llama.cpp 的 Metal 后端目前对 MoE 的实现有限，另一方面是一次校验多个 token 会激活更多专家，权重搬运量随之上升。Liquid AI 如实公布了这组数字，并将其列为后续课题。
真正见效的是让人等待的场景
被点名受益最大的用途，是需要反复调用工具的智能体式任务。这类流程中，模型每次调用工具前都要先思考，而用户全程都在等。
在函数调用评测数据集 BFCL 上的测量显示，在各种多工具场景中，响应延迟平均缩短了 57%。等待时间能否减半，往往决定了终端上的智能体是否堪用。Liquid AI 希望把 2.6B 打造成首个可用的端侧智能体模型，放在这个背景下就说得通了。
如何在本地运行
草稿模型已在 Hugging Face 上以 Safetensors 格式和 GGUF 格式提供。GGUF 面向通过 llama.cpp 的终端推理，SGLang 则面向使用 GPU 的生产部署。相关集成均已合入上游仓库，无需追踪单独的分支。需要注意的是，Metal 部分的数据是基于实验性内核测得的，能否原样复现要看具体环境。
权重可以自由下载、微调和再分发，1.2B、2.6B、8B-A1B 三种规格可按精度与占用之间的取舍来选择。
总结
DSpark 是一组在不改变输出的前提下提升推理速度的草稿模型。GPU 最高 3.18 倍、MacBook 最高 2.87 倍是它给出的成绩，但提升幅度取决于草稿的命中率，采用 MoE 结构的 8B 模型在终端侧的收益目前仍然有限。即便如此，函数调用延迟平均缩短 57%这一结果，确实让本地运行的智能体离实用更近了一步。
