LFM2.5-DSpark 最高 3.2 倍推理加速：端侧 Agent 的工具调用终于不用干等了吗

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

Hugging Face 在 2026 年 8 月 20 日发布 Liquid AI 团队的官方文章《Up to 3.2x Faster Inference with LFM2.5-DSpark》，介绍 LFM2.5 系列的 DSpark draft model checkpoints。它用一个约 3 亿参数的小型草稿模型先提出候选 token，再让目标模型批量验证；在保持贪心解码输出一致的前提下，官方测试报告了最高 3.18 倍 GPU 吞吐提升、最高 2.87 倍设备侧提升，并称 LFM2.5-2.6B 的多工具场景函数调用延迟平均下降 **57%**。

这对端侧 Agent 的意义很直接：瓶颈不一定要靠换更大的模型解决，推理过程本身也可以改成“先猜一小段，再一次验收”。但这不是无条件的三倍加速。草稿模型的接受率、任务分布、硬件后端、上下文长度和工具调用形态都会影响实际收益；生产接入仍要在目标设备和真实 Agent 回放集上验收。

发生了什么

主体来源是 Hugging Face 官方博客 Up to 3.2x Faster Inference with LFM2.5-DSpark，发布日期为 2026-08-20，作者来自 Liquid AI 团队及相关贡献者。

官方这次发布了三类 LFM2.5 模型的 DSpark 草稿模型检查点：

• LFM2.5-1.2B-Instruct；
• LFM2.5-2.6B；
• LFM2.5-8B-A1B。

文章给出的定位不是重新训练一个更大的目标模型，而是为目标模型增加 speculative decoding 路径。草稿模型大约 3 亿参数，官方提供 llama.cpp 与 SGLang 的支持，并把相关实现开源到上游。文中还强调，DSpark 的设计目标是不改变输出质量，而是减少目标模型逐 token 解码时反复搬运权重的等待。

下文中的模型名称、结构、速度、接受率和函数调用延迟属于官方文章事实；关于它们如何进入端侧 Agent，以及哪些场景值得采用，是我的工程判断。

技术细节

1. 为什么推理会被“搬权重”拖慢

大语言模型的生成阶段通常是 memory-bound。每生成一个新 token，模型都要读取大量权重并完成一次前向计算。很多时候，真正占时间的不是算力完全不够，而是权重不断从较慢的内存搬到更快的片上缓存。

普通解码像这样：

1
2

目标模型：生成 token 1 → 再生成 token 2 → 再生成 token 3 → ……
          每一步都要重复承担目标模型的权重读取成本

speculative decoding 则把流程改成：

1
2
3
4
5

轻量草稿模型：先提出 token 1、2、3、4、5
                         ↓
目标模型：一次前向检查这一串候选
                         ↓
接受正确候选，拒绝错误候选并从目标模型结果接管

只要一次目标模型前向能够确认多个候选 token，就能把重复的权重读取成本摊到更多输出上。它不是让目标模型“少做判断”，而是让一次判断同时验收更多位置。

2. DSpark 不是简单地换一个小模型猜词

官方把 DSpark 描述为三个组件的组合。

第一是类似 DFlash 的并行骨干网络。它接收目标模型的上下文特征，一次为多个草稿位置产生隐藏状态，而不是完全串行地逐个预测。

第二是轻量的顺序头。它把相邻 token 之间的依赖建模成类似 Markov chain 的关系，用来提高后面位置的接受率。前面猜得准，后面才有机会一起被目标模型接受；如果候选之间互不相关，批量验证就很难带来收益。

第三是带置信度调度的验证器。它预测每个 token 的存活概率，当继续验证低置信度后缀的成本可能超过收益时，及时剪掉这段候选。换句话说，DSpark 不只是“大胆多猜”，还要判断猜到哪里应该收手。

3. 草稿模型有多大，训练看什么指标

官方表格显示，三个草稿模型的主体由 5 层解码器、隐藏状态投影、Markov head、归一化与置信度 head 组成。LFM2.5-1.2B-Instruct 对应草稿模型约 295.7M 参数，LFM2.5-2.6B 和 LFM2.5-8B-A1B 对应约 327.7M 参数。

训练数据覆盖 SFT、聊天、代码和函数调用数据。官方文章称，草稿模型在完整数据集上训练 15 个 epoch，选择接受率最高的 epoch，而不是单纯选择 loss 最低的 epoch。

这个选择很关键。草稿模型的任务不是独立回答得多漂亮，而是提出目标模型愿意接受的候选。对 Agent 来说，代码、结构化参数和函数调用 token 的分布与普通聊天不同；如果训练只覆盖自然语言，草稿模型可能在聊天 benchmark 上很快，却在工具参数附近频繁被拒绝。

4. 输出质量为什么可以保持一致

在贪心解码下，草稿 token 只有在与目标模型分布匹配时才会被接受；被拒绝的位置由目标模型自己的 token 替代。因此，官方文章指出，最终输出在构造上与目标模型的 baseline greedy 结果一致。

这里需要准确理解“保持质量”。它不是说所有采样设置下都完全没有差异，也不是说草稿模型可以替代目标模型。它描述的是特定验证路径下，错误猜测不会直接进入最终结果。草稿模型负责加速候选生成，目标模型仍然掌握最终决定权。

这也是 speculative decoding 比“直接用小模型替代大模型”更容易接受的原因：小模型的错误主要表现为少带来加速，而不是直接改变目标模型的答案。实际工程仍要确认温度、采样、停止条件、批处理和工具调用模式是否符合运行时实现。

5. 官方速度数字：最高 3.18 倍，但平均值更值得看

官方在 M4 Max MacBook Pro 上用 llama.cpp 与 Metal 测量端侧吞吐，在单张 H100 80 GB 上用 SGLang 测量 GPU 吞吐；两种配置都使用 block size 9、batch size 1、temperature 0，并在五个 benchmark 数据集上测试。

以 LFM2.5-2.6B 为例，官方表格给出的 H100 平均加速是 2.67 倍，从约 323 token/s 提升到 864 token/s；M4 Max 平均加速是 2.27 倍，从约 61 token/s 提升到 139 token/s。单个数据集的数字不同：H100 在 MATH500 上是 3.06 倍，在 MT-Bench 上是 2.87 倍；M4 Max 在 HumanEval 上是 2.63 倍，在 MT-Bench 上是 1.99 倍。

LFM2.5-1.2B-Instruct 的表现也有波动，官方称不同数据集的速度差异可以达到 52%。这恰好说明“最高 3.18 倍”不能被当成统一承诺，真正应该关注的是目标任务分布下的平均吞吐、p95 延迟和最差接受率。

此外，官方报告 LFM2.5-2.6B 在多工具场景中函数调用延迟平均下降 57%。这对 Agent 很有吸引力，但函数调用延迟不仅由 token 生成决定，还包括 schema、参数长度、工具返回和网络等待。生产测试要把模型生成时间与完整工具链时间分开测量。

对 Agent / 工程的影响

第一，端侧 Agent 可以优先优化“等待感”

端侧 Agent 最影响体验的往往不是最终答案质量，而是用户按下按钮后要等多久才看到第一段可用结果。DSpark 主要改善的是 decode throughput，因此特别适合短指令解析、代码补全、工具参数生成和多轮交互中的连续输出。

一个稳妥的路由形态是：

1
2
3
4
5
6
7
8
9

用户请求
   ↓
本地 LFM2.5 + DSpark：快速生成候选与工具参数
   ↓
目标模型验证与结构化解析
   ↓
规则校验：权限、字段、范围、幂等性
   ↓
工具执行 / 需要时升级远端模型

对于纯本地、低风险、边界清晰的任务，这能明显改善交互感；对于复杂规划和高风险操作，速度提升不能替代校验器与人工确认。

第二，工具调用是 DSpark 的好试验场，也是难点

函数调用输出通常包含固定字段、枚举值、嵌套参数和结束标记。它们的 token 分布比普通聊天更规律，理论上适合草稿模型学习；但一旦 schema 变化、参数很长或工具返回插入上下文，接受率也可能明显下降。

因此评测不能只问“回复快了多少”，还要记录：完整工具调用成功率、参数格式错误率、被目标模型拒绝的候选比例、首次工具调用延迟、工具链总耗时，以及升级到远端模型的比例。

第三，模型运行时兼容性比模型文件更重要

官方提供 llama.cpp 和 SGLang 支持，这是降低试用门槛的好消息，但接入现有 Agent 还要确认模板、停止词、上下文长度、KV cache、Metal 或 CUDA 后端、并发限制和流式输出接口。

“能加载 checkpoint”只代表推理内核认识它，不代表它已经兼容你的 Agent harness。尤其是工具调用，必须验证运行时是否正确处理草稿 token、目标模型拒绝、结构化输出和流式事件边界。

第四，速度收益要用真实设备与真实任务回放确认

建议至少建立四组回放：普通聊天、中文信息抽取、代码任务和函数调用。每组同时测试 baseline、启用 DSpark 和在低接受率任务上的退化表现，记录首 token、持续吞吐、p50/p95 延迟、峰值内存、温度变化和工具动作成功率。

还要做持续运行测试。端侧设备可能因为温度升高降频，手机后台策略可能改变，长上下文会增加缓存压力。一次短 prompt 得到的 2 倍加速，不代表连续运行半小时仍然保持 2 倍。

我的判断

DSpark 值得试，但我不会把“最高 3.18 倍”直接写进生产 SLO。它最适合已经确定目标模型、拥有稳定任务分布，并且希望降低端侧生成等待的 Agent；如果任务经常改变 schema、需要高温度采样或草稿接受率很低，收益可能有限。

我的推荐是先在 LFM2.5-2.6B 上做本地函数调用回放：保留 baseline 作为对照，观察速度、参数正确率和完整工具链耗时；只有当收益稳定、失败可被确定性校验器拦住，再扩大到更复杂的多步任务。DSpark 的价值不是让小模型变成大模型，而是让大模型的每一次判断更少浪费在重复等待上。

Q&A

Q1：来源和发布日期是什么？

A：主体来源是 Hugging Face 官方博客 Up to 3.2x Faster Inference with LFM2.5-DSpark，发布日期为 2026-08-20，由 Liquid AI 团队发布。

Q2：DSpark 会改变目标模型的最终答案吗？

A：在官方描述的贪心验证路径中，草稿 token 只有与目标模型结果匹配时才会被接受，被拒绝的位置由目标模型接管，因此输出可以与 baseline greedy 保持一致。不同采样和运行时配置仍需自行验证。

Q3：最高 3.18 倍是否意味着所有设备都能三倍加速？

A：不是。官方报告的是特定模型、数据集、硬件和配置下的最高值；LFM2.5-2.6B 的平均值是 H100 2.67 倍、M4 Max 2.27 倍，数据集之间也存在差异。

Q4：为什么它对 Agent 工具调用有用？

A：工具调用输出通常有比较稳定的结构，草稿模型有机会提出更多可被目标模型一次验证的 token。官方称 LFM2.5-2.6B 多工具场景的函数调用延迟平均下降 57%，但真实工具链仍需测 schema、网络和执行耗时。

Q5：如何开始验证？

A：使用官方支持的 llama.cpp 或 SGLang，在目标设备上准备 baseline 与 DSpark 两套配置，回放中文抽取、代码和函数调用任务，比较首 token、持续吞吐、p95 延迟、参数错误率、峰值内存和长时间稳定性。

参考资料：

1. Up to 3.2x Faster Inference with LFM2.5-DSpark — Hugging Face Blog（2026-08-20，Liquid AI 官方文章）

字数自检：≥1500 个中文字符（不含 frontmatter）
隐私自检：未写入个人姓名、用户相关代号、内部网络细节、凭据或会话标识
封面 seed：2026-08-23-lfm25-dspark-edge-agent（唯一）
coverWidth/Height：1600 / 900
categories：ai_tech