LFM2.5-DSpark推理提速3.2倍：Liquid AI继续优化端侧模型部署

Liquid AI 近日公布了 LFM2.5-DSpark 的推理优化结果：在官方测试环境中，优化后的实现最高可将推理速度提升至原来的 3.2 倍。对端侧 AI 来说，这不是一次普通的性能调参，而是一次从模型权重、推理运行时到硬件适配的联合优化。

LFM2.5-DSpark 是面向 LFM2.5 系列端侧模型的高性能推理优化方案，目标是在不改变本地部署优势的前提下，降低生成延迟并提升设备上的有效吞吐。

这件事值得关注，是因为端侧模型真正的瓶颈往往不是“模型能不能加载”，而是加载之后是否足够快、足够省电、足够稳定。一个模型即使能在手机、笔记本或嵌入式设备上启动，如果首 token 要等待数秒、连续生成速度太慢，或者运行一段时间后出现明显降速，它就很难进入真实产品。

3.2 倍加速，究竟意味着什么

推理速度提升 3.2 倍，意味着相同硬件和任务条件下，单位时间内能够完成更多 token 的生成，或把同一段回答的等待时间压缩到原来的约 31.25%。

需要注意的是，“最高 3.2 倍”并不等于所有设备、所有输入长度和所有任务都会固定获得 3.2 倍加速。推理性能通常会受到以下因素影响：

• 输入提示词长度，以及上下文是否需要持续增长；
• 输出 token 数量和生成阶段的算子占比；
• CPU、GPU 或 NPU 的内存带宽；
• 量化格式、线程数和批处理策略；
• 操作系统、编译器和底层运行时的实现；
• 首 token 延迟与后续 token 解码速度的差异。

端侧推理一般可以拆成两个阶段。第一阶段是预填充，也就是把用户输入的提示词一次性送入模型；第二阶段是解码，也就是模型每次生成一个新 token，再把这个 token 放回上下文继续计算。聊天助手、代码补全和语音控制等场景，大量时间消耗在第二阶段。

这也是小模型优化难度高的原因。模型参数量小，并不代表每一步都天然高效。内存访问、张量布局、算子调度、线程同步和数据搬运，都可能让理论上的计算能力无法转化成真实速度。对于移动设备和笔记本而言，数据搬运有时比矩阵计算本身更容易成为瓶颈。

从这个角度看，LFM2.5-DSpark 的 3.2 倍并非简单地把硬件频率调高，而是试图减少推理路径中的无效开销。Liquid AI 发布的说明重点放在优化后的推理实现和端侧执行效率上，这与单纯发布一个更小的模型有所不同：前者优化的是“模型如何跑”，后者优化的是“模型本身有多大”。

LFM2.5为什么适合做端侧模型

端侧 AI 是指模型直接在用户设备本地完成推理，而不是把输入数据发送到远程服务器处理。 它带来的直接收益包括更低的网络依赖、更好的隐私控制和更稳定的交互延迟。

LFM2.5 是 Liquid AI 面向本地和边缘设备打造的模型家族，覆盖文本、视觉语言和音频等方向。相较于把云端大模型直接压缩后部署，LFM2.5 的设计目标从一开始就包含低内存占用、CPU 推理效率和多种硬件环境下的可部署性。

Liquid AI 此前公布的 LFM2.5-1.2B-Thinking，是一款参数规模约 12 亿、面向本地推理的思考模型。官方定位是让推理能力进入资源受限设备，并将运行内存控制在 1GB 以内的级别。这里的关键不只是“模型更小”，还包括模型架构、权重格式和推理引擎之间是否匹配。

在端侧场景中，1GB 级别的内存要求和 4GB、8GB 级别的内存要求，产品意义完全不同。前者更有机会进入普通笔记本、开发板、手机甚至部分嵌入式设备；后者则往往只能在高端设备上运行，还要和系统、应用及缓存共享资源。

LFM2.5 系列另一个重要特点，是强调对主流本地推理生态的支持。Liquid AI 公开资料提到，该系列面向 llama.cpp、MLX、vLLM 等推理工具链，并覆盖 Apple、AMD、Qualcomm 和 NVIDIA 等硬件平台。对于开发者而言，这意味着模型是否可用，不再只取决于权重文件能否下载，还取决于是否有成熟的转换、量化和运行路径。

与同尺寸模型相比，优势在“运行效率”

端侧模型的竞争不应只看参数量和离线跑分，还要看单位内存、单位功耗和单位时间能够完成多少有效任务。

以本地推理模型为例，LFM2.5-1.2B-Thinking 的直接竞品可以包括 Qwen3-1.7B 和 Granite-4.0-H-1B 等规模相近的模型。不同模型在知识覆盖、推理能力、工具调用和多语言表现上各有侧重，但部署体验往往由另外几项指标决定：加载速度、常驻内存、每秒生成 token 数，以及长时间运行时的稳定性。

| 模型或实现 | 规模定位 | 端侧部署重点 | 已公开信息 | 适合场景 | |---|---:|---|---|---| | LFM2.5-1.2B-Thinking-DSpark | 约 1.2B | 低内存与高效解码 | 官方公布最高 3.2 倍推理加速 | 本地推理、轻量 Agent、离线助手 | | LFM2.5-1.2B-Thinking | 约 1.2B | 本地思考能力 | 面向 1GB 以内级别的端侧运行 | 笔记本、移动设备、边缘设备 | | Qwen3-1.7B | 约 1.7B | 通用语言与推理 | 需要结合具体量化和运行时测试 | 本地聊天、代码与知识问答 | | Granite-4.0-H-1B | 约 1B | 混合架构与轻量部署 | 适用于资源受限环境的模型路线 | 企业端侧、嵌入式任务 |

表格中的“3.2 倍”是 LFM2.5-DSpark 在官方给定测试条件下的最高加速结果，不能直接理解成对所有竞品的绝对性能领先。不同模型如果采用不同量化格式、不同上下文长度或不同线程配置，最终结果可能出现明显变化。

但 Liquid AI 的路线仍然有明确优势：它把注意力放在推理链路的每一个环节，而不是只用更大的参数规模换取能力。对于本地 Agent 来说，这种方向尤其重要。Agent 往往不是只生成一次回答，而是要循环执行“理解任务、调用工具、读取结果、继续决策”的多个步骤。单次生成快 20% 可能不明显，连续运行十几轮后，累计等待时间就会直接影响可用性。

对本地 Agent意味着什么

本地 Agent 是能够在用户设备上完成感知、决策和工具执行的智能体，模型推理速度决定了它能否承担高频、连续的交互任务。

一个本地 Agent 可能需要执行以下流程：读取剪贴板内容、判断用户意图、检索本地文件、调用系统功能，再把结果整理成回复。每一步都可能触发一次或多次模型推理。对于远程模型，这些步骤还会叠加网络往返延迟；对于本地模型，主要成本则转移到设备算力、内存和功耗上。

LFM2.5-DSpark 的加速有望改善三类体验。

第一是交互响应。短指令、文本改写、邮件摘要和本地搜索等任务，用户通常更在意“马上得到结果”，而不是模型能否回答极复杂的问题。推理速度提高后，端侧助手更接近系统功能，而不是一个需要等待的聊天窗口。

第二是连续任务。代码补全、文档处理和工作流自动化通常会生成较长输出，也可能重复调用模型。解码阶段的效率越高，任务完成时间越短，设备持续高负载的时间也越少。

第三是隐私敏感任务。医疗记录、企业文档、私人照片和本地密码管理等场景，数据不出设备本身就是重要价值。过去开发者常在隐私和速度之间做选择，如今更高效的端侧实现可以减少这种冲突。

当然，速度提升并不能自动解决端侧 AI 的全部问题。设备温度、后台资源竞争、电池消耗、模型更新、上下文管理和安全隔离，仍然需要产品团队单独处理。一个在实验室中跑得很快的模型，放进真实手机应用后还要面对系统调度、内存回收和不同芯片驱动版本。

DSpark更像一层部署能力，而非单独的“更强模型”

模型能力和推理效率是两个不同维度：前者决定答案质量，后者决定用户愿不愿意等待。

从目前公开信息看，LFM2.5-DSpark 的核心卖点是推理速度优化，而不是宣布一个全新的通用模型能力。它不会因为解码更快，就自动拥有更多知识、更强的复杂数学能力或更高的代码正确率。开发者在评估时，应该把“模型质量基准”和“运行效率基准”分开看。

这也决定了它的实际适用边界。对于复杂代码生成、长链路规划、专业研究和需要大量外部知识的任务，1B 级别模型仍然很难全面替代更大的云端模型。它更适合那些任务边界清晰、输入输出可控、响应频率高、隐私要求强的场景。

例如，设备端可以用 LFM2.5-DSpark 做意图识别、文本分类、短内容改写、结构化信息提取和轻量工具编排；遇到需要深度推理或大规模知识检索的请求，再交给更大的模型处理。这样的分层架构比“所有请求都交给一个模型”更符合真实产品的成本和延迟要求。

开发者现在该怎么评估

评估端侧模型时，开发者应优先使用目标设备和目标工作负载测试，而不是只参考发布方给出的最高数字。

建议至少记录以下指标：

• 首 token 延迟：用户发出请求后多久看到第一段有效输出；
• 解码速度：稳定生成阶段的 token/秒；
• 峰值内存：模型加载、长上下文和并发任务下的最大占用；
• 功耗与温度：连续运行 5 分钟、10 分钟后的降频情况；
• 长上下文表现：输入从 512 token 增长到 4K、8K 后速度变化；
• 任务质量：准确率、格式遵循、工具调用成功率和拒答行为。

尤其要区分“短提示词速度”和“长上下文速度”。一款模型可能在短输入上非常快，但随着上下文增长，内存访问和缓存开销会让速度快速下降。对代码助手、会议纪要和本地知识库来说，后者往往更接近真实使用情况。

还要确认 DSpark 优化是否覆盖你的目标平台。Apple 芯片、AMD Ryzen AI NPU、Qualcomm NPU 和普通 x86 CPU 的执行路径并不相同。相同权重在不同后端上的表现可能差异很大，量化方式也会改变内存占用和输出质量。对于商业产品，建议把模型版本、量化格式、运行时版本和硬件型号一起锁定，避免后续升级造成性能回退。

Liquid AI在下一阶段面对的挑战

端侧模型的下一场竞争，将从“谁能运行”转向“谁能在真实设备上长期稳定运行”。

Liquid AI 已经证明，围绕 LFM2.5 做专门的推理优化，仍然存在可观的性能空间。最高 3.2 倍的结果说明，模型权重之外，运行时、编译优化和硬件后端同样能够改变产品体验。

但要把这种优势转化成广泛采用，还需要解决三个问题。第一，性能结果能否在更多设备上复现；第二，优化后的实现是否足够容易接入现有本地推理工作流；第三，加速是否会牺牲输出质量、长上下文能力或量化兼容性。

如果这些问题能够得到验证，LFM2.5-DSpark 的价值就不只是一次基准测试，而是为小模型部署提供了一条更现实的路径：让模型保持较低的内存门槛，同时通过专门的推理实现把等待时间压下来。

截至 2026 年 8 月 20 日，端侧 AI 仍处在从演示走向常驻功能的阶段。LFM2.5-DSpark 没有试图用更大的模型去复制云端体验，而是从速度、内存和设备适配这些工程问题入手。对开发者来说，这可能比又一个参数规模更大的模型更值得跟踪。因为在本地设备上，真正决定产品能否落地的，往往不是模型在排行榜上多领先几分，而是用户点击之后能否足够快地得到结果。

结论

LFM2.5-DSpark 的核心更新可以概括为三点：最高推理加速 3.2 倍、继续围绕 LFM2.5 的端侧部署效率做优化，以及把小模型用于本地 Agent 的可行性进一步提高。

它不是对大模型的全面替代，也不是只看一个数字就能下结论的“性能神话”。但在本地助手、离线文本处理、隐私敏感应用和高频 Agent 工作流中，速度和内存效率本身就是产品能力。Liquid AI 正在押注的，正是这一点：未来的 AI 不只存在于数据中心，也需要在用户手边的设备上快速、稳定地工作。

参考来源

• Hugging Face：Up to 3.2x Faster Inference with LFM2.5-DSpark：Liquid AI 公布 LFM2.5-DSpark 推理加速结果、测试说明及相关部署信息。