LFM2.5-24B-A2B-DSpark 与 LFM2.5-24B-A2B：你真的应该挂载草稿模型吗？

一句话给出结论：LFM2.5-24B-A2B-DSpark 是一个 3.277 亿参数的文件，把它放在 LFM2.5-24B-A2B 旁边，就能让这个 24B 模型以更快的速度产出同类输出。它不是该模型的替代方案，也不是让你用来取代它的东西。这两个名字引出的唯一真正问题是个工程问题——你是把草稿模型接入部署，还是不用它——而答案与其说取决于 Liquid AI 宣传的主打加速比，不如说取决于两个没人宣传的数字：草稿在你的流量上能被接受多少 token，以及你已经在运行多高的并发。像这次发布这样的版本背后，有记录的 AI 故障和智能体事件都收录在 OrcaRouter AI Incident Archive 中，每条记录都附有自己的来源、严重程度、置信度等级和争议标记。

Liquid AI 尚未发布关于草稿模型的发布帖。该仓库于 2026-10-19 公开，包含权重、一份基准测试 CSV 以及 SGLang 启动参数，而目标模型自己的模型卡仍将草稿模型标注为“即将推出”，Liquid 的推测解码文档页面也只列出了 1.2B、2.6B、8B 和 VL-3B 目标模型。因此，这是将一个已发布产物与一个已发布模型进行比较，内容依据仓库而非新闻稿写成——这意味着下文的每一项性能数字均为厂商报告，且均未经独立复现。

起草工具实际会改变什么，又不会改变什么

这套机制值得花三十秒解释，因为它决定了其余一切。解码一个 token 是受内存带宽限制的：GPU 大部分时间都花在把权重流式传入 SRAM 上，而不是做算术运算。投机解码正是利用这一点：先让一个小模型一次猜出接下来的若干个 token，再让真正的模型在一次前向传播中检查整个猜测。如果猜得准，你就能以大约一个 token 的成本产出九个 token。如果猜得不准，目标模型会保留自己的 token，而你只多付了一点额外成本。

变化的是：每秒 token 数，以及 GPU 利用率的形态。不变的是：模型的权重、上下文窗口、工具调用行为，或者其在销售地区的价格。LFM2.5-24B-A2B 保持 24.0B 总参数、每 token 2.45B 激活参数，40 层分布于门控短卷积和分组查询注意力，每个块 64 个专家并采用 top-4 路由，上下文为 131,072 token，词表为 128,000 token。草稿模型增加了五个注意力层、一个秩为 256 的 Markov 头和一个置信头，并复用目标模型的嵌入和 LM 头，而不是自带这些组件。

有一条注意事项在两个版本之间发生了变化，值得提一句。八月，Liquid 的 DSpark 文章称，生成的序列“从构造上就与基线贪心解码完全相同”。而 24B 草稿模型的模型卡则说，批量验证与普通解码之间的浮点差异“可能产生不同的文本，包括在贪心采样下”。两种说法都站得住脚——第一种在精确算术下成立——但如果你的评测框架逐字节比较输出，那就要预期它会发现这一点。

账簿的成本方面

草稿模型并非没有代价。它在 GPU 上以 BF16 占用 655 MB（或在 CPU 上以 F16 GGUF 占用 664 MB），与目标模型位于同一内存池中，并且它提出的每一步都需要对一整块 token 进行一次验证前向传播，而不是只对一个 token 进行。在 MoE 目标模型上，最后这一点比听起来更昂贵：验证九个 token 比解码一个 token 激活更多专家，因此每个被验证 token 所搬运的字节数会增加，而不是减少。Liquid 正是将此列为其 8B 草稿模型在 M4 Max 上尽管接受率很高、却只带来 1.18× 提升的原因。

相比之下，节省的量足以用 GPU 小时来衡量。使用厂商自己的 B300 数据，这些数据来自 benchmarks/b300-fp8.csv，而所做的不过是将十亿个输出 token 除以观测到的吞吐量：

• MATH-500，并发数为 1——单独运行时为 324 tok/s（每十亿 token 消耗 857 GPU 小时），使用草稿模型时为 853 tok/s（326 GPU 小时）。计算时间缩减至原来的 1/2.63。

• MATH-500，并发数 256 —— 单独运行时为 15,423 tok/s（18.0 GPU-hours），而搭配草稿模型时为 27,579 tok/s（10.1 GPU-hours）。削减到 1.79 倍。

• GSM8K，并发 256——单独运行时为 4,491 tok/s（61.9 GPU 小时），而配合草稿模型时则为 9,660 tok/s（28.8 GPU 小时）。缩减了 2.15 倍。

• LiveCodeBench，并发 256——单独运行时为 18,812 tok/s（14.8 GPU 小时），而使用草稿模型时为 25,231 tok/s（11.0 GPU 小时）。仅带来 1.34× 的缩减，是表格中最弱的一项。

这些是将吞吐量比率换算成时间、而不是换算成金额的结果，因为金额取决于你每 GPU 小时支付多少费用，而本文不会凭空编造一个费率。但无论费率如何，排序都成立：在低并发下，为推理和代码生成流量接上草稿模型，相当于每十小时省下两到三个小时；在高并发下，价值大约只有前者的三分之一。如果你的 24B 部署是工作站上的单用户智能体，那么理由很充分。如果它是已经饱和的批处理端点，那么这种收益确实存在，但比 2.4× 这个标题所暗示的要小得多。

就工作量而言，起草工具在哪些方面物有所值

供应商表格中八个数据集的差异并非噪声；它对应着不同的提示类型，而这种对应关系是本次发布中最有用的信息。接受长度从 MBPP 上每步 6.70 个 token，低至 LiveCodeBench 上的 4.02 个 token。得分高的数据集，正是模型输出受提示约束的那类：简短的单元测试风格函数、带有可检验路径的算术题、多项选择答案。得分低的数据集，则是模型必须自行构造冗长且不受约束解法的那类：竞赛编程题和 AIME 风格数学题。

这就是你要带入自己评估中的直觉。一个为智能体工作而售卖的 24B 推理模型，会把大部分输出 token 花在思维链里，这看起来更像 LiveCodeBench，而不是 MBPP。一个用于结构化抽取、基于 schema 的分类或固定工具调用格式的模型，则看起来更像那些高接受率的行。如果你的工作负载属于前者，预计会落在更接近区间下限 1.34× 的位置，而不是上限 3.28×。还没有人发布过这个草稿模型按工作负载划分的接受率，而模型卡上的八个数据集是最接近指南的东西。

与此形成对照的是：24B 是一个仅用于推理的模型。Liquid 表示它总是在回答前思考——聊天模板会自动插入 <think> 标签。对于推测来说，这是最糟糕的形态，因为推理片段恰好是漫长且接受率低的那一段。草稿模型仍然会有帮助；它在最终答案上帮助最大，而在耗时最长的部分上帮助最小。

如何在自己的硬件上，用一个下午就判断出来

你不必相信上述任何内容。两条推理路径都会暴露接受计数器，而这是唯一能决定 drafter 在你的流量上是否划算的数字。

在 SGLang 上，启动目标模型并挂接 drafter，块大小为 9，草稿 token 数为 10，然后读取服务器按请求报告的投机解码指标。供应商表中的接受率根据数据集不同介于 0.33 和 0.65 之间；如果某次运行的结果远低于对应行，说明 drafter 猜错了，你付出了验证成本却没有获得加速。在带有 F16 GGUF sidecar 的 llama.cpp 上，每次响应的计时会携带 draft_n 和 draft_n_accepted，可直接读取。将两者相除。

有两个操作细节，一旦漏掉就会让你多花一小时。SGLang 服务器需要包含 2026-08-31 合并的 LFM2-MoE DSpark 路径的构建版本——在任何更旧的版本上，草稿模型架构根本就是未知的。而且块大小是检查点的属性，不是可自由设置的参数：llama.cpp 会将 --spec-draft-n-max 限制为附属文件元数据中的值 9，因此要求 12 毫无意义。

这个比较无法回答的问题

关于“我是否该挂接草稿模型”存在一个与 GPU 毫无关系的版本，而这正是大多数团队实际面对的情况。如果你通过托管 API 调用 LFM2.5-24B-A2B，那么是否使用草稿模型就不是你能决定的了。服务栈要么挂接推测解码器，要么不挂接；你看到的是一个每秒 token 数和一个价格，而这两者都是在上游决定的。Liquid 自家的 Console 将 24B 列为每百万输入 token 0.10 美元、缓存输入 0.05 美元、每百万输出 1.00 美元——这个公布费率已经反映了他们所运行的任何解码路径，而且可能在没有通知的情况下发生变化。

这正是路由发挥帮助而非增加复杂性的接缝所在。托管调用和自托管部署与其说是相互竞争的两个方案，不如说是同一个成本旋钮的两种设置：如果你的用量能让 GPU 保持忙碌，自托管加上草稿模型可以最小化每 token 成本；而托管端点则最小化获得答案所需的工作量。OrcaRouter 是为后者而构建的——一把密钥覆盖200 多个模型，按提供商标价 0% 加价，因此供应商价格变化当天就会反映到我们这边，如果提供商服务降级会自动故障转移，还有路由 DSL 用于分流流量，而不是硬编码单个后端。我们目前不提供 LFM2.5 系列，所以对于这个特定模型，托管侧意味着 Liquid 自己的 API 或你自己的 GPU；值得进行的比较是针对我们确实提供的模型，例如Qwen3.6-35B-A3B——Liquid 在智能体任务上用以基准对比的模型——或Gemma 4 26B-A4B。

那么：要不要附上它？

如果你以适度并发自行托管 LFM2.5-24B-A2B，尤其是在处理结构化或抽取式输出时，并且目标模型旁边还有 655 MB 的余量，那就把它挂上。厂商的数据表明，这样做大致能让那里的解码时间减半或降至三分之一，而且下行风险有限：糟糕的草稿模型只会多付一次验证过程，而不会带来错误答案。

如果你的端点已经在数百这个量级上饱和、如果你的输出是长篇自由形式推理，或者如果你需要在拍板前拿到 Apple 芯片上的数字，那就别开启——这张卡上没有这些数字，而同系列中最接近的对应产品在 MacBook 上是以 1.18× 交付的。显然，如果你根本没有在运行这个模型，也别开启：drafter 是针对部署的一种优化，而在部署存在之前，没有什么可优化的。

能解决其余问题的，是一篇厂商帖子和一次 Mac 实测。截至 2026-10-21，两者都还不存在——对于一个权重已经可以下载的发布来说，这是一种奇怪的状态；而且，对任何愿意自己运行验收计数器的人来说，这是一个异常廉价的机会，可以成为榜单上第一个独立数字。