LFM2.5-8B-A1B-DSpark 对比 Qwen3-8B：为模型加速的草稿，对抗人人都在跑的 8B

Liquid AI 于2026年8月20日发布了LFM2.5-8B-A1B-DSpark草稿检查点——这是一个拥有3.277亿参数的投机解码辅助模型，能够让LFM2.5-8B-A1B边缘MoE在单块H100上的生成速度最高提升3.18倍。在诚实地进行这场对比之前，有一个事实必须摆在桌面上：DSpark检查点并不是一个可以调用的模型，它只能加速另一个模型。因此，这次发布真正推动的部署问题，正是大多数团队全年都在权衡的那个——LFM2.5-8B-A1B还是Qwen3-8B，两个同为8B级别的开放权重模型，却正处于各自生命周期的截然不同的阶段。

这里的框架比平时更重要，因为双方不是同一类事物。Qwen3-8B 是一个完整、可部署的模型，你今天就可以自行托管或购买其 token。LFM2.5-8B-A1B 也是一个完整、可部署的模型——DSpark 草稿是它的附加组件，而不是它的一个版本。草稿承诺的一切都是供应商测量的，并且只有一天之新；关于仓库和格式的一切都只是放在那里供人核查。这篇文章将这两类事物分开处理。

首先，单词“DSpark”在本句中不是名词。

推测解码让一个廉价的草稿模型跑在真正模型前面：草稿模型猜出接下来的一小批词元，目标模型用一次前向传递验证整个块，并保留双方一致的部分。当猜测准确时，只需一次权重加载的开销就能推进多个词元，因此吞吐量提升，且完全不动目标模型的权重——由于目标模型会逐一检查每个被提议的词元，在贪婪解码下，输出与单独运行LFM2.5-8B-A1B完全一致。Liquid称之为“构造上无损”，这正是草稿模型可以安全附加的根本原因。

Liquid 的 LFM2.5-8B-A1B-DSpark 是一款刻意做小的草稿模型：仅五层注意力层，每步生成九个提议 token，并在目标模型 128,000 token 词表上带有一个马尔可夫头。它在聊天、代码和函数调用数据的混合集上训练了 15 个 epoch，检查点按接受率而非损失来挑选。它是该供应商当天发布的三个草稿模型之一，另外两个是 LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B，均提供 Safetensors 与 GGUF 格式，并首发即支持 SGLang 和 llama.cpp。同样重要的是，对于任何拿它与 8B 级模型做对比的读者来说：它不由任何推理服务提供商托管，也没有按 token 计费的价格。它只存在于你自己的投机解码栈中。

实际部署的两个模型

抛开草稿模型，真正的对比在于它所加速的模型与现有模型之间。两者都是开放权重，规模大致在8B级别，而相似之处也就到此为止：

• 架构 — LFM2.5-8B-A1B 是稀疏 MoE，总参数 8.3B，但每个 token 仅激活约 1.5B 参数；Qwen3-8B 是稠密 8.2B 模型，每个 token 都会激活全部参数。

• 发布 — LFM2.5-8B-A1B 于 2026 年 5 月 28 日发布；Qwen3-8B 于 2025 年 4 月发布，已有一年多历史，在一些服务平台上已被弃用。

• 上下文 — {{1}}LFM2.5-8B-A1B{{/1}} 原生支持 128K 上下文，词表大小为 128K token；{{2}}Qwen3-8B{{/2}} 原生支持 32K，可通过 {{3}}YaRN{{/3}} 扩展到约 128K。

• 推理 — LFM2.5-8B-A1B 是一种推理模型，会显式输出思维链；Qwen3-8B 则根据请求在思考与非思考模式之间切换。

• 智能 — 根据Artificial Analysis的数据，LFM2.5-8B-A1B的Intelligence Index得分为8，Qwen3-8B得分为8–8.3，均低于同类开放权重模型的中位数9；两者都不是前沿大脑，但也都坦承这一点。

• 速度——根据 Artificial Analysis 的数据，LFM2.5-8B-A1B 在各提供商处的输出速度约为每秒 340 个 token；Qwen3-8B 约为每秒 37–40 个 token，属于同类中速度最慢的之一。

• 许可证 — LFM2.5-8B-A1B 受 Liquid 的 LFM 开源许可证 v1.0 约束；Qwen3-8B 采用 Apache-2.0。

速度就是不再难分伯仲之处。

{{1}}8B 级开放权重模型讨论转向的最大单一原因是单位内存的速度。{{/2}}Qwen3-8B 是一个稠密模型：它生成的每个 token 都会将全部 8.2B 权重流经内存总线，这正是它相对于自身规模而言速度偏慢、且需要真正显存的原因。{{/3}}LFM2.5-8B-A1B 让每个 token 仅路由经过约 1.5B 激活参数，这正是其整个设计要点——一种在设备端运行、保持快速且小巧的 MoE。{{/4}}Liquid 自己的说法更进一步：在 M5 Max CPU 上、内存占用低于 6GB 的情况下，约每秒 253 个 token，此为厂商报告数据。{{/5}}就可部署模型的原始吞吐量而言，draft 模型在这个环节甚至无关紧要——在加入推测解码之前，MoE 就已经比稠密 8B 快了好几倍。

在价格方面，两者都是开放权重，因此自行托管的成本等同于你硬件的成本。在托管服务的可用性上，对比则有些失衡：Qwen3-8B 可由阿里云的 API 提供服务，标价为每百万输入 token 0.18 美元、每百万输出 token 2.10 美元，同时也有众多第三方开源模型托管平台提供支持；LFM2.5-8B-A1B 没有值得一提的第一方托管 token 定价，而该草案则完全没有定价。这意味着，如今大多数团队实际运行 Liquid 边缘 MoE 的方式就是自行托管，在笔记本电脑、边缘设备或自有的 GPU 上运行——而这正是 DSpark 草案成为关键变量的场景。

这份草案实际上为这项决定带来了哪些改变

该草案仅在一个维度上带来变化：在你掌控的服务栈中，LFM2.5-8B-A1B 生成 token 的速度。它不会让模型更聪明，也不会改变其回答内容——贪心输出与单独使用目标模型时逐位相同。它真正发挥作用的地方是单请求吞吐量下的 GPU 服务：Liquid 在单个 H100 上跨五个基准测试测得的平均加速为 2.54×（418 → 1,074 token/秒），在 MATH500 上最佳达到 3.18×，批大小为 1，温度为 0。而在 Apple 芯片上则几乎没什么帮助：同一模型在 M4 Max 上平均仅为 1.18×（90 → 106 tok/s），因为在 llama.cpp 当前的 Metal MoE 后端中，验证一整块草稿 token 会激活更多专家，并产生更多权重数据移动——而这恰恰是投机解码本应摊薄的成本。以上均为发布当天的厂商数据，未经独立复现。

这种划分直接对应到一条决策规则上。如果你在自己拥有的 GPU 上部署 LFM2.5-8B-A1B，草稿模型就是一个实实在在的成本杠杆——同样的芯片每秒能多生成约 2.5 倍的 token，输出完全不变，而且你只需要一个包含 8 月 20 日 DSpark 集成的构建版本。如果你改为通过 API 调用该模型，加速收益归服务提供商所有，草稿模型对你而言无关紧要。而如果设备是笔记本电脑或手机，草稿模型对这个特定模型目前几乎不起作用；真正在端侧有优势的是面向稠密模型 LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 的同类草稿模型，提速分别为 2.54 倍和 2.27 倍。至于 Qwen3-8B，它完全不需要草稿模型——它只是一个更慢、更稠密的模型，部署时并不需要投机解码。

选择，Qwen3-8B问世一年之际

Qwen3-8B 是无聊但正确的默认选择：成熟、Apache-2.0 许可、支持 119 种语言、具备思考与非思考模式、被广泛部署，并且对于聊天、代码和结构化文本来说仍然是一个相当出色的通用模型。它的问题在于年龄和速度——这是一个已有 16 个月历史的稠密 8B 模型，在其同类中速度较慢，并且已在一些平台上被弃用。如果你今天正在启动一个全新项目，这是一个值得认真对待的维护信号。

LFM2.5-8B-A1B 是一次更新、更聚焦的押注：一款为边缘场景而生的 MoE 模型，专为在消费级硬件上快速进行工具调用和指令遵循而构建，并以 DSpark 草稿模型作为 GPU 自托管场景下可选的服务加速。它并非更聪明的模型——两者在 Artificial Analysis 上均低于开放权重中位数——但它的速度显著更快，每个 token 的内存占用仅为其一小部分，而这正是对端侧代理而言关键的权衡。它的局限性恰好是 Qwen3-8B 的镜像：发布更晚、没有第一方托管定价，以及一项推测性解码方案，其数字尚未被供应商之外的任何人复现。

无论采用哪种方式，底层的路由层都保持不变。目前，LFM2.5-8B-A1B 和 Qwen3-8B 都不在 OrcaRouter 的托管目录中，所以诚实的说法是路由器对模型组合的作用：一个 API 接入 200 多个托管模型，提供商目录价格以 0% 加价原样透传，因此供应商降价的当天就会在平台上生效；自动故障转移让你能够针对真实流量试用未经证实的新模型，而不是将生产链路押注在它身上；还有一套路由 DSL，可以为自行托管的模型提供前端入口，这正是自托管 LFM2.5-8B-A1B 技术栈与托管端点在同一密钥下共存的方式。

If you are building for a laptop or an edge box and care about tool-calling speed, LFM2.5-8B-A1B is the direction to test, and the draft is a free 2.5× on the GPU serving path when the time comes. If you want a generalist you can stop thinking about, Qwen3-8B still works — just know it is a model from early 2025 that the ecosystem is starting to rotate out. The one thing neither the draft nor the target changes is the honest state of the evidence: everything fast about the DSpark release is a single vendor's measurement from a single day, and independent benchmarks are the open item that decides how much of this you actually trust. --- Translation into Simplified Chinese: 如果你是在为笔记本电脑或边缘设备做构建，并且在意工具调用的速度，LFM2.5-8B-A1B 是值得测试的方向，等到时机成熟时，这个草稿模型在 GPU 服务路径上能带来免费的 2.5 倍加速。如果你想要一个省心的通用型模型，Qwen3-8B 仍然可用——只是要知道它是 2025 年初的模型，生态系统已经开始逐步将它替换掉。无论是草稿模型还是目标模型，都改变不了一个事实，那就是证据的真实状态：DSpark 发布中所有关于“快”的说法，都只是某一家厂商在某一天测出来的数据，而独立基准测试才是决定你到底该信多少的未决事项。