AI 模型与平台更新推理加速

Liquid AI 的 DSpark 通过高达 3.2 倍的吞吐量加速 LFM2.5——输出结果不变

Liquid AI 发布了 LFM2.5-1.2B-Instruct、2.6B 和 8B-A1B 的 DSpark 草稿检查点，新增了推测解码，实现了显著加速：GPU 上最高达 3.18 倍，设备端最高达 2.87 倍，内存开销极小且保持贪心输出一致。llama.cpp 和 SGLang 的首日支持使其成为边缘和智能代理工作负载的实用升级方案。

NexusAi 研究团队2026年8月25日2.1K 次阅读8 分钟阅读

Liquid AI 的 DSpark 通过高达 3.2 倍的吞吐量加速 LFM2.5——输出结果不变

AI 简报

Liquid AI 的 DSpark 以草稿检查点形式发布，覆盖三款 LFM2.5 模型，新增推测解码路径，在保持贪心输出不变的同时提升解码吞吐量——H100 上最高达 3.18 倍，MacBook 上最高达 2.87 倍，内存开销极小。DSpark 结合并行骨干、轻量级顺序头和置信度调度验证器，提高接受率并摊销多标记权重负载。llama.cpp 和 SGLang 的首日支持让团队能快速在 GPU 和设备端评估。结论是：较小的指令调优模型现在能实现聊天、编码和智能代理循环（尤其是函数调用）的“交互式”速度，无需重新训练或牺牲贪心模式下的输出确定性。

Liquid AI 正在发布 LFM2.5-1.2B-Instruct、2.6B 和 8B-A1B 的 DSpark 草稿检查点，向解码路径添加了推测解码。其主张很直接：单个 H100 上吞吐量最高提升 3.18 倍，设备端最高提升 2.87 倍，同时保持贪心输出与基线完全一致。这种一致性至关重要——DSpark 会验证每个提议的标记——因此团队可以在不影响既定评估基准的情况下采用加速方案。借助 SGLang 和 llama.cpp 的首日支持，这一方案不仅是实验室演示，而是可以立即在常见推理框架中运行。其影响在需要即时响应的小模型场景中最为明显：本地聊天、代码助手和智能代理函数调用，DSpark 也显著降低了延迟。

为什么现在能实现？大型语言模型解码通常受限于内存：反复从 DRAM 拉取大规模权重成为延迟瓶颈。DSpark 通过使用紧凑的草稿器提出多个标记，然后让目标模型一次性验证这些标记，从而摊销权重访问流量。其方案结合了 DFlash 风格的并行骨干网络和轻量级马尔可夫头以增加标记间依赖性，以及一个基于置信度调度的验证器来剪枝低置信度后缀。Liquid AI 的草稿器约 3 亿参数，训练目标是提高接受率而非单纯降低损失，从而每次验证推送更多被接受的标记。结果是每个输出标记的内存往返次数减少，带来更高吞吐量且不改变贪心输出。

性能在不同上下文中表现不一。对于小型密集模型（1.2B–2.6B），DSpark 在 GPU 上稳定实现 2–3 倍提升，设备端也有显著加速，达到交互式使用的“即时感”门槛。8B-A1B MoE 模型在 GPU 上表现出强劲提升，但设备端提升较小，原因是当前 Metal MoE 的效率和跨多个专家验证多个标记的成本。尽管如此，DSpark 提升笔记本电脑上的标记处理速度，使本地助手和智能代理更实用。在智能代理流程中，Liquid AI 报告函数调用延迟平均降低超过一半——这对以工具为主的场景尤为重要，因为响应时间瓶颈主要在此。

在操作层面，DSpark 是低摩擦升级：在 SGLang 中将草稿附加到目标模型，或使用支持 DSpark 的 llama.cpp 构建，然后监控接受率和 draft_n/draft_n_accepted 以验证效果。建议从匹配目标 LFM2.5 模型的草稿器和适中的块大小开始，根据领域文本调优以稳定接受率。由于推测解码在贪心模式下是精确的，您的评估工具和基准测试保持一致。生产环境中，需端到端验证智能代理性能，特别是工具延迟和函数调用节奏，因为 DSpark 的实际投资回报率在多步工具调用主导响应时间的场景中最大。

核心要点

贪心输出一致且速度显著提升

DSpark 验证每个提议标记，确保贪心解码输出与基线一致，同时在 GPU 上实现最高 3.2 倍吞吐量，设备端也有强劲提升，适合对正确性和响应速度均有要求的场景。

边缘和智能代理工作负载首当其冲受益

较小的密集 LFM2.5 模型在本地达到交互式速度，多工具智能代理流程中函数调用延迟平均降低超过一半，显著缩短响应时间。

快速采用，智能衡量

附加 DSpark 草稿器，跟踪接受率和 draft_n_accepted，评估每美元标记数和端到端延迟。MoE 设备端加速较弱，需等待 Metal 内核和调度成熟。

Liquid AI 刚发布的内容及其重要性

DSpark 为三款 LFM2.5 模型提供草稿检查点，实现推测解码，在不改变贪心输出的前提下提升吞吐量。无论是云端还是边缘设备，提升都非常显著：H100 上最高达 3.18 倍，MacBook 级设备上最高达 2.87 倍，且额外内存开销极小。借助 SGLang 和 llama.cpp 的首日支持，DSpark 不仅是研究实验，而是接近生产的解决方案。对于注重响应速度和成本的创始人及平台团队，这使得较小模型能在编码、聊天和智能代理循环中达到交互式速度，减少了仅为降低延迟而扩展到更大模型的压力。

DSpark 如何提升吞吐量同时保持贪心一致性

推测解码通过轻量级草稿器提出多个标记，并在目标模型上一次性验证，解决了受内存限制的解码瓶颈。DSpark 结合了并行骨干处理所有草稿标记、顺序马尔可夫头提升后位标记接受率，以及基于置信度调度的验证器剪枝低置信度后缀，推动每次验证接受更多标记。Liquid AI 训练了约 3 亿参数的草稿器，优化接受率而非仅仅降低损失。在贪心解码下，拒绝的提议由目标模型自身选择替代，确保输出与基线一致。最终效果是每个输出标记的内存往返次数减少，令吞吐量提升且输出不变。

最受益场景：GPU 与设备端，以及 MoE 的注意事项

对于 1–3B 的密集模型，DSpark 在 GPU 上常规实现 2–3 倍吞吐量提升，现代笔记本设备上也有 2 倍以上加速，足以改善聊天和编码体验并加速智能代理循环。8B-A1B MoE 变体的设备端加速较小，原因在于当前 Metal 后端效率及跨多个专家验证多个标记的成本。如果您的工作负载依赖大量工具调用，函数调用延迟平均降低 57% 的优势尤为显著。总结：针对交互式用户体验或成本敏感的中小模型，推荐使用 DSpark；MoE 设备端加速存在但需谨慎预期，等待内核和后端支持成熟。

集成指南：从实验室到生产的信心保障

通过在 SGLang 中将目标 LFM2.5 模型与对应草稿器配对，或使用支持 DSpark 的 llama.cpp 构建来采用 DSpark。建议从默认草稿块大小开始，利用接受率和每次响应的 draft_n 与 draft_n_accepted 指标验证收益。在真实流量混合（聊天、编码、数学和工具使用）中评估，避免过拟合单一语料。设备端部署时，结合所选量化和上下文长度评估内存余量。生产环境中，关注端到端智能代理延迟和每美元标记数，而非仅仅是原始标记速率，以全面捕捉 DSpark 对函数调用响应时间和用户感知响应性的影响。

限制、风险及后续关注点

DSpark 的贪心输出一致性不适用于非贪心设置；温度采样或核采样会改变接受动态，可能重新引入漂移，因此在需要一致性时请使用确定性解码。对于 MoE 模型，验证多个标记可能激活更多专家，导致内存带宽饱和，抑制设备端加速，直到内核改进。草稿器带来少量内存开销，请与上下文长度和 KV 缓存一并预算。最后，持续关注 SGLang 和 llama.cpp 的上游支持；随着内核和调度优化，尤其是在 Metal 上，MoE 设备端差距有望缩小。