AREX Feed Article
Liquid AI 放出约 300M 参数 DSpark 草稿模型，LFM2.5 自测吞吐最高 3.18 倍
8 月 20 日，Liquid AI 在 发布 DSpark 推测解码草稿模型：为 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 三款模型各训练了一个约 300M 参数的草稿模型，checkpoint 以 Safetensors 与 GGUF 两种格式上传。官方自测称，在单张 H100 上吞吐最高提升 3.18 倍（LFM2.5-8B-A1B 的 MATH500 从 428 提到 1362 tok/s），在 M4 Max MacBook Pro 上最高 2.87 倍（LFM2.5-1.2B-Instruct 的 HumanEval 从 136 提到 389 tok/s），且贪心解码的输出与基线逐 token 一致，pass@1 与 exact match 基准分不变。
这些数字全部出自 Liquid AI 自己的测试（博客注明了 H100 用 SGLang + BF16、M4 Max 用 llama.cpp + Metal + FP16 的完整配置），不是独立复现的结果。官方同步宣布 llama.cpp 与 SGLang 的 day-one 支持，但两项集成的落地进度并不相同：llama.cpp 的集成 PR 已在当天合并，SGLang 的 PR #31041 截至 8 月 21 日核查时仍是 open 状态，Metal 侧的数字则来自一个尚未合入上游的实验内核。
草稿模型怎么把解码拖快
大模型解码阶段受内存带宽限制：延迟主要花在把权重从 DRAM 搬进 SRAM，而不是计算本身。推测解码用轻量草稿模型一次前向提出一整块候选 token，目标模型再用一次前向全部验证，权重加载成本被整块 token 摊薄。DSpark 在其中组合了三样东西：DFlash 式的并行骨干（以目标模型的上下文特征为条件，一次前向产出整块 draft token 的 hidden state）、一个马尔可夫链顺序头（给相邻 token 之间补上依赖，抬高靠后位置的接受率）、以及一个置信度调度验证器（预测每个 token 的存活概率，验证成本超过收益时剪掉低置信后缀）。
第一版草稿是纯 attention 的简化模型，5 层、block size 9。按官方给出的参数表，1.2B-Instruct 版 295.7M 参数，2.6B 与 8B-A1B 版各 327.7M；embedding 和 LM head 挂在目标模型上，不计入草稿。三个模型卡已同步上线：以 为例，5 层注意力骨干、hidden_size 2048、GQA 32 头/8 KV 头，外加 rank 256 的 Markov 头与置信度头，词表 128,000；词表为 65,536，同为 327.7M 参数。
训练数据混合了 SFT、chat、code 与 function-calling，每个模型跑 15 个 epoch，最终挑选接受率最高、而不是 loss 最低的 epoch 发布。Liquid AI 在 中写明，全部训练和消融都在 AMD 硬件上用自家训练框架完成。质量一致性是构造上保证的：贪心解码下草稿 token 只有与目标模型分布一致才被接受，被拒时由目标模型自己的 token 顶替，输出序列因此与基线逐 token 相同。
三张表：成绩单上的峰值与短板
五组数据集（MATH500、HumanEval、MBPP、GSM8K、MT-Bench）都在 block size 9、batch size 1、温度 0 下测得。LFM2.5-2.6B 平均提升 H100 上 2.67 倍（323→864 tok/s）、M4 Max 上 2.27 倍（61→139 tok/s），官方称 MacBook 上的吞吐已把交互体验推到"远超多数闭源云模型（约 140 tok/s，视数据集而定）"的水平。1.2B-Instruct 接受率方差大，提速随文本分布最多相差 52%，均值 H100 2.10 倍、M4 Max 2.54 倍。
8B-A1B 最特殊：接受率全场最高（MATH500 达 8.27/10），H100 平均 2.54 倍、单数据集最高 3.18 倍，但 M4 Max 上平均只有 1.18 倍（90→106 tok/s，约 +18%）。官方把原因归结为 llama.cpp 的 Metal 后端对 MoE 的实现仍不理想，加上验证 k 个 token 会激活更多专家、权重搬运比单步解码更重，并称这是后续工作，公布数字是为了透明。
峰值之外还有边界：官网博客的交互性实验显示，并发度提高后算术强度上升，DSpark 与基线的累积提速差距会收窄，2.6B 在 batch size 128 附近与基线趋同；这些实验跑在单张 H100 上，且未启用置信度调度验证器，官方称实验中它裁掉的 token 省下的算力抵不过损失，因此改用固定验证窗口。
端侧 agent 是目标：BFCL 多工具延迟平均降 57%
LFM2.5-2.6B 的定位，官方在博客里写得很直接：让这个最近发布的 2.6B 模型成为第一个可用的端侧 agentic 模型。agentic 工作负载里，模型每次调用工具前都要先推理，用户全程等待，这正是推测解码收益最大的环节。在 BFCL v3 数据集上（M4 Max、llama.cpp Metal、FP16、batch size 1、温度 0），多工具场景的平均延迟降低 57%，博客配图的标题给出端到端延迟从约 3.5 秒降到约 1.5 秒。
DSpark 从哪来：七月的论文与 DeepSeek-V4
DSpark 不是 Liquid AI 原创的方法。博客引用的方法论文 7 月 6 日挂上 ，作者为 Cheng 等 33 人；论文摘要称该方法已在 DeepSeek-V4 的 serving 系统中用真实流量部署验证，与生产基线 MTP-1 相比，在相同吞吐水平下单用户生成速度提高 60%–85%。Liquid AI 把 DSpark 配方适配到 LFM2.5 架构，并在官网博客中称这是 LFM 家族第一次公开发布推测解码草稿模型。官方称这是"开源权重"路线的一部分：模型可下载、可微调、可部署；草稿模型本身约 300M 参数，换来最高 3.18 倍的解码吞吐。
"Day-one 支持"的兑现：llama.cpp 已合并，SGLang 还挂着
按 8 月 21 日的核查，三项集成的状态各不相同。llama.cpp 的 （8 月 19 日开出）已于 8 月 20 日 14:36 UTC 合并进主干。合并当天就有用户踩坑：GitHub 用户 insraq 在 PR 下报告，用官方 GGUF（LiquidAI/LFM2.5-2.6B-DSpark-GGUF）在 Windows CUDA/Vulkan 上启动服务、发送 prompt 时崩溃（GGML_ASSERT "layer input tensor is null"）；PR 作者 tdakhran 回复说 insraq 的 llama-cli 构建早于该 PR、当时最新 release 尚未包含改动，建议从源码构建或等下一版；insraq 随后承认是自己没注意构建管线有积压，等构建就绪再测。
SGLang 一侧，（7 月 13 日开出）截至核查仍未合并，最近一次活动停留在 7 月 30 日，博客自己的使用说明也写明"SGLang 需要带 PR #31041 的构建"。Metal 侧同样有保留：博客注明 llama.cpp 的数字跑在实验性 Metal 内核上，对应的 （小 batch 解码的 Metal kernel 优化）仍为 open。想复现博客里 3.18 倍数字的读者，目前需要自己把 SGLang PR #31041 合进构建再编译：官方给出的 SGLang 启动命令依赖这个尚未合并的 PR。