LFM2.5-24B-A2B-DSpark 已在 Hugging Face 上线——只是 Liquid AI 尚未宣布

Liquid AI 最大模型的模型卡仍称其投机解码草稿模型为即将推出。该草稿模型并不会推出。LFM2.5-24B-A2B-DSpark自 2026-10-19 起就有公开仓库，拥有 655 MB 的 BF16 检查点、完整的基准测试表、次日晚上发布的 GGUF sidecar 文件，以及写入其模型卡的 SGLang 启动标志。它唯独没有的是公告。LFM2.5-24B-A2B——它旨在加速的 24B 专家混合模型——于 2026-10-13 获得了博客文章、带日期的发布、价格表和 playground 链接。它的草稿模型只得到了一个仓库和一张模型卡，而 Liquid AI 自己关于投机解码的文档页面仍只将 1.2B、2.6B、8B 和 VL-3B 目标列为支持。像此次发布这样的产品发布背后，有记录的 AI 故障和智能体事件，均收录于OrcaRouter AI Incident Archive，其中每条记录都带有自己的来源、严重程度、置信度等级和争议标记。

这个差距正是本文的关键所在，值得精确说明它意味着什么、又不意味着什么。一个权重开放、基准测试可基于模型旁边的 CSV 复现、推理路径已合并到上游的仓库，是真正的发布，而非泄露。但供应商并未以文字形式确认任何相关内容，没有第三方对其进行测量，模型卡中的数字也是同一团队在他们选定的同一硬件上测得的数字。本文区分两者：仓库确立了什么，以及什么仍只是声明。

仓库里实际有什么？

检查点足够小，以至于仅凭文件列表本身就能提供不少信息。整个内容就是一个 model.safetensors，大小为 655,421,522 字节——BF16 格式的 327.7M 参数——外加一个配置文件、一份许可证和一个 benchmarks 目录。没有别的东西。这里没有分词器、没有嵌入矩阵，也没有 LM 头，因为该架构在加载时会从目标模型复用这三者。这就是设计思路：草稿模型只需要知道如何猜测目标模型词表中的下一个 token 块，而不需要知道如何表示世界。

该配置证实了 8 月 DSpark 文章所描述的结构。五个全注意力层，隐藏大小为 2,048，中间大小为 6,144，采用 SiLU/SwiGLU；分组查询注意力，32 个头和 8 个 KV 头，头维度为 64；一个秩为 256 的 Markov 头和一个单独的置信度头；块大小为 9；词表大小为 128,000；最大位置嵌入为 131,072，与目标模型的上下文窗口完全一致。这个草稿模型特有的字段是target_layer_ids: [2, 10, 18, 26, 34]，对照num_target_layers: 40——也就是 24B 模型中草稿模型读取其隐藏状态作为上下文的五个层。正是这些索引，使得为一个 LFM2.5 模型训练的草稿模型无法简单地直接用于另一个模型。

许可证是 lfm1.0，与系列中其他成员相同的自定义许可证；对于计划再分发捆绑的 target-plus-drafter 产物而非内部使用的人来说，这一点值得注意。

基准测试表，作为供应商表来解读

该卡公布了八个数据集在并发 1、32 和 256 下的吞吐量，测试环境为单块 NVIDIA B300，采用 FP8 目标、BF16 KV 缓存以及温度 0。benchmarks/b300-fp8.csv，如果你想自己核对算术的话

• 八个数据集的算术平均值——并发度为 1 时为 2.38×，并发度为 32 时为 2.69×，并发度为 256 时为 1.71×。

• 最佳单个单元格——MBPP 在并发 32 时达到 3.28×，MATH-500 紧随其后，为 3.04×。

• 最差的单个单元格——LiveCodeBench 在并发 256 时为 1.34×，AIME 在 256 时为 1.36×。

• 每步接受的 token 数——平均为 5.16，而由区块大小加上目标的奖励 token 所设定的上限为 10。

• 最高接受率——MBPP 为每步 6.70 个 token；最低——LiveCodeBench 为 4.02。

关于那张表，有两件事比标题本身更有意思。第一件事是，平均加速比更高：并发 32 时达到 2.69×，而并发 1 时是 2.38×——这与通常的推测解码叙事相反，通常批处理会吞噬收益。第二，它在 256 时崩了。在 256 个并发请求下，仅目标模型在那块 GPU 上针对 MATH-500 就已经每秒生成约 15,000 个 token，而草稿模型的贡献降到 1.79×。只读“2.4×”的服务团队会把集群规模定错；对于批处理端点，真正重要的数字是 1.71×，而且即便这个数字也是 B300 上的数字，其并发特征大多数部署都不会匹配。

自八月份以来发生了变化的那句话

当 Liquid AI 于 2026-08-20 为 1.2B、2.6B 和 8B-A1B 目标模型发布 DSpark 草稿模型时，其博客文章提出了一个强有力的主张：由于目标模型会校验每一个提议的 token，并用自身的选择替换被拒绝的 token，“因此，所生成的序列在构造上就与基线贪心解码完全相同。”8B 草稿模型的模型卡也重申了这一精神，承诺“完全相同的输出”。

24B 草稿模型的模型卡并没有这么说。它说的是，目标模型会验证每一个提议的 token，然后写道：“批量验证与普通解码之间的浮点差异可能会产生不同的文本，包括在贪心采样下也是如此。”它还补充说，这些测量评估的是性能，而不是任务准确率。

这是一种更谨慎的表述，而且它才是正确的。批量验证不会像顺序解码那样，以相同的顺序执行相同的浮点运算，因此位级一致性只是一种在精确算术中成立、但在真实硬件上并不总是成立的假设。较新的说明卡这样写，而较旧的说明卡没有这样写；这一事实要么是文档更正，要么是在训练这个草稿模型期间发现的——仓库没有说明是哪一种，Liquid 也没有发布解释。其实际含义范围有限但确实存在：如果你的回归测试套件对模型输出进行逐字节比对，加入这个草稿模型可能会触发比对失败，而这是算术本身的特性，而不是草稿模型的缺陷。

为什么起草者比它自己的模型晚了六天到达

时间线值得梳理，因为它比任何关于策略的猜测都更能解释这种沉默。

• 2026-08-20 — Liquid 发布 DSpark 系列：面向 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 的草稿模型。目前尚无 24B 目标模型。

• 2026-08-31 — SGLang 合并了 PR #31041，新增对 LFM2 与 LFM2-MoE DSpark 投机解码的支持。24B 所需的 MoE 路径正是在此落地，比它将要服务的模型早了一个半月。

• 2026-10-13 — LFM2.5-24B-A2B 随一篇博客文章和一个价格一同发布。同一天，SGLang 合并了 PR #43939，使服务器能够直接复用 Hugging Face 的 LFM2-MoE 配置。

• 2026-10-19 — LFM2.5-24B-A2B-DSpark 仓库出现，包含权重和基准测试。

• 2026-10-20 — GGUF 附属文件上线：一个用于 llama.cpp 的 664 MB 的单个 F16 文件。

• 2026-10-21 — 目标模型卡新增一行草稿模型。它仍显示 即将推出。

读一下这串顺序，最可能的解释就是最无聊的那个。基础设施先于产物发布；产物在训练完成后发布；公告是一项尚未进行的营销任务。仓库中没有任何迹象表明这是一次刻意低调的发布——模型卡是完整的，基准测试连协议都记录在案，SGLang 和 llama.cpp 的调用方式也完整写出。这里的“安静”意味着尚未公布，而不是被隐藏。

什么是尚不可知的

这篇文章坦诚的边界是一份简短的清单，其中每一项都是真正的缺口，而不是形式上的点缀。

没有独立测量。 没有 Artificial Analysis 条目，没有第三方验收运行，也没有对吞吐量表格的复现。截至 2026-10-21，该仓库显示七次下载和一个赞。本文中的每一项加速都是厂商的，基于厂商选定的 GPU、厂商选定的目标精度。

没有发布公告，也就没有定调。我们不知道 Liquid 是打算把它作为面向 24B 的生产推荐，还是作为研究产物。模型卡的语调——完整的发布标识、模型家族表、联系链接——暗示是前者，但这只是推断。

没有价格，因为不可能有价格。草稿模型并不是一个对外提供服务的模型。它没有按每百万 token 计费的价格，也永远不会作为可调用的端点出现在模型目录中。它的成本，是它在目标模型旁边所占用的 655 MB 显存或统一内存，再加上以块为单位而非以单个 token 为单位进行验证所带来的额外算力开销。

没有 Apple 芯片的数值。这是最大的缺口，下一节将解释为什么它比其他缺口更重要。

缺失的 Mac 编号才是耐人寻味的遗漏

24B 模型是作为端侧模型销售的。Liquid 的发布文章以在 Apple M5 Max 上每秒 184 个 token 开场，并称其专为端侧快速、私密的智能体而打造。相比之下，drafter 的规格卡只报告了 B300 的数字。对于 8 月的 8B drafter，Liquid 同时公布了 H100 和 M4 Max 的结果，并坦率说明了二者之间的差距：在 H100 上 2.54× 的平均加速，到了 MacBook 上变成 1.18×。其给出的原因是机制上的——验证 k 个 token 会比单次解码步骤激活更多专家，因此 MoE 目标每验证一个 token 要付出更多权重流量，而 llama.cpp 的 Metal 后端让情况更糟。

LFM2.5-24B-A2B 同样是混合专家模型：每个块有 64 个专家，采用 top-4 路由。同样的机制也适用，而 24B 是更大的模型，拥有更大的专家集合需要分页调取。这并不能证明端侧加速幅度很小——该草稿模型是专门针对这个目标模型训练的，而且接受率比 8B 最初的表现要好得多——但这确实意味着，笔记本电脑用户最需要的那个数字，恰恰是这张卡上没有包含的那个数字。任何认为 B300 的比例可以沿用到 Mac 上的假设，都应视为未经证实。

运行它，以及那个会让你踩坑的标志

在 GPU 上，已发布的方案是使用 SGLang，采用 FP8 目标模型并挂接草稿模型，块大小为 9，草稿 token 数为 10。安装的 SGLang 必须足够新，以包含来自 PR #31041 的 LFM2-MoE DSpark 路径以及来自 PR #43939 的配置复用；在较旧的构建上，服务器根本无法识别草稿模型架构。请注意，基准测试数据假设使用 FP8 目标模型——BF16 目标模型的表现会有所不同，而且不一定更好，因为草稿模型是针对目标 logits 的特定分布训练的。

在 CPU 和 Apple silicon 上，路径是使用 F16 GGUF 伴随模型的 llama.cpp。该伴随模型会从自身元数据中读取块大小，并将--spec-draft-n-max限制为该值，因此把草稿长度设为 12 并不会得到 12。逐响应计时会暴露draft_n 和 draft_n_accepted，这是在你自己的工作负载上需要关注的字段：如果你流量上的接受率远低于该卡片的 5.16 均值，那么草稿模型会让你多付出一次前向传递，却几乎换不来什么收益，而诚实的做法就是将其卸下。

如果你这周要选择模型，这意味着什么

对大多数团队来说，实际影响很小，因为草稿模型改变的是速度，而不是能力。LFM2.5-24B-A2B 才是负责回答提示的模型；草稿模型只改变你每秒能获得多少个回答。如果上周 24B 不在你的候选名单上，一个更快的版本也不会让它进入名单。

如果它曾出现在你的候选清单上，那么草稿模型会提升自托管方案的说服力，而对 API 方案毫无帮助。这个区别值得直说：推测解码检查点对任何调用托管端点的人来说都是不可见的，因为服务栈决定是否挂载它。你能在同等条件下比较的是模型本身与你原本会路由到的替代方案——如果你要拿它和类似 Qwen3.6-35B-A3B 这样的模型比较，也就是 Liquid 在八个智能体任务中的五个上作为基准对照的模型，OrcaRouter 用一个密钥承载这个比较对象，价格为 供应商标价的 0% 加价，并支持跨供应商自动故障转移。我们今天不提供 LFM2.5 系列，所以 24B 本身必须来自厂商自己的 API 或你自己的 GPU；我们提供的是比较的另一边，且无需第二份合同。

什么会改变这幅画面

三件事，按它们能多大程度推动叙事来排序。Liquid 的一篇博客文章能定下框架——这究竟是推荐的生产搭配，还是研究性发布。一份公开发布的 Mac 实测能坐实那个对 24B 的目标受众真正重要的说法。而在真实流量上做一次独立验收运行——而不是在 temperature 0 下跑八个基准数据集——才能告诉你：每步 5.16 个 token 这个数字，在面对这个模型实际所面向的那些杂乱、冗长、带工具调用的提示词时，是否还能站得住。

在此之前，仓库是公开的，权重可以下载，CSV 就摆在那里，而供应商自己的模型卡是你最不该去那里寻找相关消息的地方。对于一个发布而言，这是一种不寻常的状态——但它是真实存在的，而且不会因为没人写博客文章，这个产物就变得不那么真实。