LFM2.5-8B-A1B-DSpark 对比 LFM2.5-2.6B-Base：速度部分与原材料

如果按每个检查点独立能做什么来给LFM2.5系列排序，LFM2.5-8B-A1B-DSpark和LFM2.5-2.6B-Base落在序列的两端——而两端都无法回答问题。前者是一个327.7M参数的草稿模型，存在的唯一目的是让Liquid AI的边缘混合专家模型更快地生成token。后者是一个2.69B参数的原始预训练检查点，存在的唯一目的是被微调成其他东西。两者都于2026年8月根据Liquid的LFM Open License v1.0发布，都在Hugging Face上只需一次下载即可获取，而且都非常容易被误下载——因为它们的名字听起来像是同一事物的两个版本。

名字本身就是陷阱。“DSpark”听起来像是该系列光彩夺目的新旗舰，而“Base”听起来像是你直接就能跑起来的普通默认版本。但这两种印象都不属实。DSpark 检查点无法单独回答任何问题——它只是为 LFM2.5-8B-A1B 提出 token 以供验证。Base 同样无法回答任何问题，但原因恰好相反——它是一个未调优的基础模型，能预测文本，却从未经过后训练成为对话或智能体模型。这不是竞争关系，而是一条流水线：一个检查点位于服务栈的最末端，另一个位于训练流程的最开端。

两个同名而非同一工作的检查点

LFM2.5-8B-A1B-DSpark（2026年8月20日发布）是一个推测解码草稿模型：一个五层仅注意力网络，每步生成九个候选token的块，以及一个基于目标模型128,000词表上的马尔可夫头。你将它加载到LFM2.5-8B-A1B旁边——那是一个总参数83亿、激活参数约15亿的MoE模型，于5月28日发布——草稿模型猜测接下来几个token，目标模型则通过一次前向传播验证整个块，并保留它能接受的部分。由于目标模型会检查每个token，在贪婪解码下，输出与单独运行LFM2.5-8B-A1B完全相同：用Liquid的话说，“构造上无损”。草稿模型是速度部件，而非大脑。它随LFM2.5-1.2B-Instruct和LFM2.5-2.6B的兄弟草稿模型一同发布，每个都提供Safetensors和GGUF格式，并在SGLang和llama.cpp中获得了发布当天即支持。

LFM2.5-2.6B-Base（发布于2026年8月4日）是流水线的另一端：一个2.69B参数的基座模型，采用混合30层堆栈——22个双门控短卷积块加上8个分组查询注意力块——在约34万亿个token上进行了预训练，并通过中期训练阶段将上下文扩展至128K。它没有聊天模板，没有指令微调，也没有已发布的基准测试结果，而且Liquid自己的模型卡片仅推荐将其用于大规模微调。它的全部意义在于作为原材料，通过一个四阶段的后训练流水线——两轮SFT、教师特化、在线策略蒸馏，然后是智能体强化学习——转化为工具调用智能体LFM2.5-2.6B。同一家族，同一许可证，同一下载页面。职责却完全不同。

并排：七个维度，两项工作

因为这两个检查点承担不同的任务，公正的比较需要厘清双方的角色：

• 它是什么 — LFM2.5-8B-A1B-DSpark 是一个 0.3B 的投机解码草稿模型；LFM2.5-2.6B-Base 是一个 2.69B 的原始预训练基础模型。

• 运行搭配 — DSpark 草稿模型与 LFM2.5-8B-A1B MoE 配对使用（总参数 8.3B，每 token 激活约 1.5B）；Base 模型可独立运行，但仅作为未经微调的文本预测。

• 独立使用 — DSpark 本身不会产生任何内容；它仅加速目标。Base 能生成文本，但没有有用的产品行为 — 不遵循指令、不调用工具、没有聊天模板。

• 输出质量 — DSpark 继承了目标模型的精确贪心输出，因为每个提议的标记都经过验证；而 Base 模型在设计上没有任何已发布的任务基准测试结果。

• 速度 — DSpark 为其目标（产品）带来了厂商实测的平均 2.54 倍加速（在 H100 上；在 MATH500 上最高 3.18 倍）和 1.18 倍加速（在 M4 Max 上），但均未经复现；Base 则完全没有关于推理速度的声称。

• 内存占用 — DSpark 在目标模型之外仅增加约0.3GB的草稿权重；Base 则为完整的 2.69B 模型，可在 2.5GB 以下运行，是该系列中最小且真正实用的基础模型。

• 格式与可用性 — DSpark 提供 Safetensors 和 GGUF 格式，首发即支持 SGLang 和 llama.cpp；Base 提供 Safetensors 以及 GGUF、ONNX 和 MLX 格式，并支持 Transformers、vLLM、SGLang、llama.cpp 和 MLX 运行。目前两者均未由任何推理提供商提供服务——均为自托管检查点。

这场对决中唯一的数字来自一个实验室

这里的所有量化数据都来自单一供应商的测量，是在草案发布当天进行的，尚未被独立复现——请将其视为有前景的结果，而非已验证的事实。Liquid 在批量大小为 1、温度为 0 的条件下，分别在一张 80GB H100 上以 BF16 精度配合 SGLang，以及在一台 M4 Max MacBook Pro 上以 FP16 精度配合 llama.cpp 的实验性 Metal 内核运行 GGUF 模型，对 LFM2.5-8B-A1B-DSpark 进行了测量。在 H100 上，该组合平均加速 2.54 倍（418 → 1,074 tokens/秒），在 MATH500 上取得了最佳单项结果 3.18 倍（428 → 1,362 tok/s），平均接受率约为 10 个候选 token 中接受 7 个。在 M4 Max 上，同一组合平均仅加速 1.18 倍（90 → 106 tok/s）——这正是 Liquid 自己指出的端侧边缘情况，因为在当前的 MoE Metal 后端中，验证一个块会激活更多专家，并导致更多权重流量在内存总线上传输。

这场对决中的Base一侧完全没有数字可言，而这种缺失本身就是它的规格。LFM2.5-2.6B-Base是预训练而非后训练的模型；它从未针对聊天、工具使用或智能体行为进行评估，因为没有人打算以那种方式使用它。它有意义的数字在于架构层面：2.69B参数、128K上下文、支持16种语言的分词器、运行所需不到2.5GB。你不会去基准测试一个基础模型；你基准测试的是你将它微调而成的结果。

在做出任何决定之前，有一个家族式的讽刺值得一提。本文所讨论的草稿——即 8B-A1B 的那个——恰恰是在笔记本电脑上提升最少的（1.18×），而 2.6B 家族对应的草稿，它加速的正是这个 Base 的后训练兄弟版本，在 M4 Max 上平均达到 2.27×，多工具函数调用延迟降低 57%。如果目标设备是手机或笔记本电脑而非 GPU 机箱，那么速度优势的故事就在 2.6B 这条路径上。

那么你要下载哪一个？

你从来不必在这两者之间直接做选择，因为它们并非替代选项——但你必须清楚自己正在做的是哪一项工作：

如果你在自己拥有的 GPU 上部署 LFM2.5-8B-A1B，并希望从同样的硬件中获得更多 tokens/s，那么 LFM2.5-8B-A1B-DSpark 是一个可逆的附加方案：使用 8 月 20 日的 DSpark 集成来构建 SGLang 或 llama.cpp，在启动命令中指定 draft 模型，保持贪心解码，块大小会自动从 draft 的配置中读取。好处是吞吐量大约提升 2.5 倍，且输出完全不变；代价是增加 0.3GB 的额外权重，并且需要包含这些 PR 的新版本构建。移除这两个投机标志，你就回到了普通的原版模型。

如果你想构建自己的专用模型——领域模型、自定义语言助手、基于专有数据的微调——LFM2.5-2.6B-Base 是开放权重生态系统中成本最低的严肃起点之一：2.6B 参数、小于 2.5GB、128K 上下文、多语言分词器。DSpark 检查点完全无法帮助你做到这一点，因为它不是基础模型。

如果你真正想要的是 Liquid 的端侧智能体——工具调用、多步骤任务——那么这两个都不是你想要的。你想要的是后训练过的 LFM2.5-2.6B，之后你可以自行决定是否挂上它自己的草稿模型。Base 是给想自行训练的人准备的原材料；8B-A1B 草稿模型是给已经部署 MoE 的人准备的加速组件。错误的做法是：因为想要更快的智能体而下载 Base，或者因为想要训练的基础而下载草稿模型。

这两者的连接之处——以及路由器的用武之地

这两个检查点都属于自托管方案。草稿是服务层的一个附属组件，只存在于你自己的 SGLang 或 llama.cpp 技术栈中；基础版本则是训练产物。两者都不会出现在任何托管目录中，也没有按 token 计的标价。这在实践中意味着，无论走哪条路径，最终都会和你已经在调用的托管模型放在一起运行——而路由层存在的意义，正是把这套混合管道收拢起来。

在服务端，草稿模型的经济账简单而实在：同一块 GPU 每秒生成的 token 数量提升到原来的 2.5 倍，意味着相同工作负载下耗时降为原来的 1/2.5，所需 GPU 数量也大约降到原来的 1/2.5，而且质量没有任何变化。但这一杠杆只有在你掌握推理服务时才存在。一旦你通过 API 调用 8B-A1B，提速带来的收益就被服务商拿走了——所以这时候真正重要的就变成了 API 侧的对比：服务商收多少钱，以及他们宣布降价当天，你这边是否就能同步享受到。这正是直通路由器的意义所在：一个 API 接入 200 多个模型，服务商目录价按 0% 加价直通，厂商一降价，你这边立即生效；同时具备自动故障转移，某家服务商的延迟尖峰不会变成你的延迟。你还可以通过同一个端点接入自己托管的 LFM 技术栈，这样就能用真实流量试跑一个全新的草稿模型，而不必把一条生产路径押在它身上。

LFM2.5-8B-A1B-DSpark 与 LFM2.5-2.6B-Base 同属一个家族，却承担着截然相反的职责：前者是装在边缘 MoE 上的加速部件，后者是 2.6B 智能体成长所依托的未调优大脑。两者都无法独立运行。如果你已经在 GPU 上部署了某个 MoE，可以选择起草模型来为其加速；如果你想把 2.6B 基础模型微调成自己的东西，可以选择 Base 版本；但如果你想要的是一个开箱即用的智能体，那就两个都别选——因为这两个检查点的唯一共同点就是：单独拿出任何一个，都做不了你能用的事。

常见问题

我可以单独运行LFM2.5-8B-A1B-DSpark吗？

不。它是一个草稿模型，没有独立输出——它提出候选词元，由 LFM2.5-8B-A1B 目标模型进行验证，因此它只存在于基于 8 月 20 日 SGLang 或 llama.cpp 集成构建的投机解码服务栈中。单独下载它，你得不到任何可以查询的东西。

LFM2.5-2.6B-Base 是在设备上作为智能体运行的检查点吗？

并非原样使用。Base 是未经指令微调、也没有聊天模板的原始预训练基础模型。作为 Liquid 端侧智能体运行的模型是经过后训练的 LFM2.5-2.6B，它由 Base 通过四阶段后训练流程生成——而且，如果你想要更快，还可以搭配 LFM2.5-2.6B-DSpark 草稿模型。