LFM2.5-DSpark 推理速度提升高达 3.2 倍

判断

端侧或单卡部署 LFM2.5 的人，现在要按内存预算而非精度来决定挂不挂 DSpark：约 300M 参数的 draft 模型换 2.27x 到 2.67x 吞吐，代价是一小块常驻显存，而 8B-A1B 端侧只多 18%。

依据

LiquidAI 的 Leonie Monigatti、Fernando Fernandes Neto 等作者在 Hugging Face 发文，为 LFM2.5-1.2B-Instruct、LFM2.5-2.6B、LFM2.5-8B-A1B 发布 DSpark draft model checkpoint。机制上，LLM 推理的 decode 阶段受显存带宽限制（memory-bound），延迟主要来自把权重从 DRAM 搬进 SRAM，而不是算力；speculative decoding（投机解码）先用轻量 draft 模型猜若干 token，再由 target 模型一次前向全部验证，把同一份权重加载成本摊到多个 token 上。DSpark 由三部分组成：DFlash 式并行骨干、一个 Markov 链形式的轻量顺序头（补相邻 token 依赖，抬高后位接受率）、以及按置信度剪掉低置信后缀的 verifier。draft 模型各约 300M 参数、5 层、block size 9，训练时按接受率而非 loss 挑 epoch。作者给出的对照：H100 上平均 2.67x（323 → 864 tok/s），M4 Max 上平均 2.27x（61 → 139 tok/s），2.6B 在多工具场景延迟平均降 57%；但 8B-A1B 端侧平均只提升 18%，作者把它归因于 llama.cpp 的 Metal 后端 MoE 实现，以及验证 k 个 token 会激活更多专家。