借助 LFM2.5-DSpark 实现高达 3.2 倍的推理加速

判断

部署 LFM2.5-2.6B 做端侧 function-calling 的团队，可以按延迟降 57%、精度不变把 DSpark 默认打开；但 1.2B 必须先按自家文本分布重测，8B-A1B 先别开。

依据

LiquidAI 团队在 Hugging Face 发布了 LFM2.5 三个模型的 DSpark 草稿模型 checkpoint：1.2B-Instruct、2.6B、8B-A1B。机制是投机解码（speculative decoding）：轻量草稿模型先一次前向吐出候选 token，目标模型再一口气验证全部候选，把权重的 DRAM→SRAM 搬运成本摊到多个 token 上——解码阶段本来就是 memory-bound，瓶颈在搬权重而不在算。三个草稿模型都在 300M 参数上下（295.7M 和 327.7M），显存只多这一点。质量上，贪心解码下草稿 token 必须匹配目标分布才被接受，被拒就换目标模型自己的 token，输出序列与基线逐字相同。速度：2.6B 在 H100 均值 323 → 864 tok/s（2.67x），M4 Max 61 → 139 tok/s（2.27x）；1.2B 在 M4 Max 均值 138 → 350 tok/s（2.54x）。代价落在接受率上：块大小是 9，均值只接受 4.81 个，1.2B 因文本分布不同加速比能差 52%；8B-A1B 接受率更高，端侧却只快 18%，材料把原因归给 llama.cpp 的 Metal 后端 MoE 实现。