LFM2.5-24B-A2B-DSpark 对比 LFM2.5-8B-A1B-DSpark：同一个 328M 文件，两种截然不同的押注

下载其中任一文件，得到的都是 655,421,522 字节。LFM2.5-24B-A2B-DSpark 和 LFM2.5-8B-A1B-DSpark在字节层面大小完全相同，共享五层骨干、相同的秩为 256 的马尔可夫头、相同的块大小 9 和相同的 128,000 个 token 的词表——而且两者都无法回答哪怕一个提示，因为二者都是推测解码草稿模型，存在的唯一目的就是为目标模型猜测 token。它们的区别不在自身规格。而在于它们各自针对哪个目标模型训练，以及有多少证据表明这一招在目标模型上奏效。其中一个在发布帖中公布了 GPU 和 MacBook 实测数据；另一个只有一张 GPU 表格，没有任何公告。因此，在两者之间做选择根本不是模型之间的比较——而是两种押注之间的比较，而且只有其中一种已经兑现。像此次发布这类发布背后，有记录在案的 AI 故障和智能体事件，均收录在OrcaRouter AI Incident Archive中，每条记录都自带来源、严重程度、置信度等级和争议标记。

文件是孪生的；作业则不是。

并排阅读这两个config.json文件，几乎每个字段都匹配：隐藏大小为 2,048，中间大小为 6,144，SiLU 激活，32 个注意力头分布在 8 个 KV 头上，头维度为 64，五个全注意力层，块大小为 9，enable_confidence_head: true，一个秩为 256 的普通马尔可夫头。参数数量完全相同，这就是为什么 safetensors 文件逐字节一致。

有三个字段存在差异，而每一个都至关重要。

• 目标层抽取点 — 8B 草稿模型从 24 层目标模型的第 2、6、10、14 和 18 层读取隐藏状态；24B 草稿模型从 40 层目标模型的第 2、10、18、26 和 34 层读取隐藏状态。正是这一字段导致这些文件不可互换。

• 最大位置数——8B 草稿模型为 128,000，而 24B 为 131,072，与其各自目标模型的上下文窗口保持一致。

• RoPE theta —— 5,000,000 对 10,000,000，由目标模型的位置编码设定，而不是由草稿模型的任何因素决定。

最后一对是最清晰的证据，说明这些检查点是按每个目标模型分别训练的，而不是从一个共同基座扩展出来的。草稿模型没有独立的身份：它的输入分布就是目标模型隐藏状态的样子，而一旦目标模型的架构和训练发生变化，这些隐藏状态也会改变。把 8B 草稿模型指向 24B 模型，仅层索引就会让它错乱；即便层索引能对上，它被训练去预测的 logits 也对不上。

每一个实际上在加速的究竟是什么

这些目标之间的差异远不止“8B 与 24B”的命名所暗示的那样，而且对于任何认为更大模型在设备端负担更重的人来说，这种差异恰恰相反。

• 总参数与激活参数——LFM2.5-8B-A1B 的总参数为 8.3B，每个 token 激活 1.5B；LFM2.5-24B-A2B 的总参数为 24.0B，激活参数为 2.45B。

• 深度 — 24 层（18 个门控卷积加 6 个 GQA），对比 40 层（30 个卷积加 10 个 GQA）。

• 上下文 — 128,000 个 token，而总上限为 131,072。

• 训练预算——38T 个 token，对比 36T，因此较小模型相对于较大模型并未训练不足。

• 路由——8B 使用 64 专家 MoE，采用 top-4 路由，与 24B 相同，因此两者都要承受会损害验证的专家激活惩罚。

两者都是先思考再作答的推理模型，这一点在这里比参数量更重要。投机解码最大的弱点是长且无约束的输出，而思维链恰恰就是如此。厂商的表格也说明了这一点：两个版本中接受率最高的几行都是 MBPP 和 MT-Bench 这类短答案基准，最低的则是模型必须自行构造长解题路径的那些。

证据差距才是真正的区别。

从这里开始，这两个版本就不再具有可比性。8B 草稿模型于 2026-08-20 作为完整系列发布的一部分推出，并在两台差异极大的机器上进行了测量：一台是通过 SGLang 以 BF16 运行的单张 H100 80 GB；另一台是 M4 Max MacBook Pro，通过 llama.cpp 运行 FP16 GGUF 权重，并使用实验性 Metal 内核。它在 H100 上平均达到 2.54×，在 MATH-500 上峰值达到 3.18×；而在 MacBook 上仅达到 1.18×——在五个数据集上平均为每秒 90 至 106 个 token。

24B 草稿模型只有一行硬件配置：单块 NVIDIA B300，搭配 FP8 目标模型、BF16 KV 缓存，temperature 为 0。在八个数据集上，并发为 1 时平均达到 2.38×，并发为 32 时达到 2.69×，并发为 256 时达到 1.71×；在 MBPP 上、并发为 32 时达到 3.28× 的峰值。没有 Mac 行，没有 H100 行，也没有任何公告文章来解释这一省略。

对于整个卖点都押在端侧智能体上的模型——Liquid 为 24B 发布的文章以 Apple M5 Max 上每秒 184 个 token 打头——缺失的 MacBook 数字是这次发布中最关键的一个空白。8B 的结果说明了这个数字为什么可能很小：验证一个 token 块比解码单个 token 会激活更多专家，因此 MoE 目标每接受一个 token 就要移动更多权重。而接受率本身并不是预测指标：8B 草稿模型每步平均接受的 token 数更多，超过 24B 的规格卡所报告的数据（五个数据集上为 6.95，而八个数据集上为 5.16），但在 MacBook 上仍然只实现了 1.18×。这正是值得记住的一点——在 8B 上，高接受率并没有挽救端侧吞吐量。假设 24B 表现不同，是一个背后没有数字支撑的赌注。

对照阅读这两张表

这些头条比率并非同口径的可比数据，不应相互相减。不同的 GPU、不同的目标精度、不同的数据集组合、不同的并发扫描范围。但有两种规律在口径不一致的情况下依然成立。

首先，上限相似。8B 在 H100 上的最佳单元格是在批大小为 1 时于 MATH-500 上达到 3.18×；24B 在 B300 上的最佳单元格是在并发度为 32 时于 MBPP 上达到 3.28×。这种设计的草稿模型无论服务于哪个目标模型，都会落在相同的 1.5×–3.3× 区间内，这正是当草稿模型架构保持不变、只有权重变化时你会预期到的情况。

第二，而且更有用的是，下限正是各目标出现差异的地方。8B 最弱的 H100 单元是 GSM8K，为 1.29×；24B 在并发 256 下最弱的 B300 单元是 LiveCodeBench，为 1.34×，AIME 为 1.36×。两个版本都没有出现推测解码完全免费的情况，而且两者都出现了几乎不值得为此占用内存的情况。

这两张卡片之间还有一处文档改动，很容易被忽略，值得标出来。8 月的材料说，贪婪解码下的输出“按构造”与基线完全相同；8B 卡片承诺“输出完全一致”。24B 卡片则警告，批量验证与普通解码之间的浮点差异可能产生不同的文本，包括在贪婪采样下。后一张卡片更为谨慎；如果你在 CI 中运行字节级输出差异比较，那么这两者都值得被视为可能并不完全相同，而不是相信较早的承诺。

哪一个与你相关，取决于你的目标，而不是你的预算。

没有任何场景会让团队基于优劣在这两者之间择一。你运行 24B，是因为需要 24B 模型的能力，并且机器能承载它——GGUF 格式下 Q4_K_M 量化占 14.5 GB，或 FP8 服务配置下用单块 B300。你运行 8B，是因为 8.3B 总参数、1.5B 激活参数才适合边缘设备或笔记本电脑，而 drafter 能挽回一部分因缩小模型而牺牲的解码速度。drafter 是上述第一项决策的附属品，而这项决策几乎总是早在推测解码进入讨论之前，就基于内存和质量做出了。

唯一真正需要做选择的情况是评估阶段。如果你在测试 DSpark 是否值得引入你的技术栈，那么 8B 组合是成本更低的实验：它能装进一块 H100，有 Mac 上的数据可供你对照自己的笔记本电脑验证，而且厂商已经记录了它在设备端的故障模式。24B 组合则是更有意思的生产实验，也是文档记录更少的那一个。

对两者中的任何一个而言，决定结果的是接受计数器，而不是厂商表格。SGLang 会按请求公开投机解码的接受率；llama.cpp 会报告 draft_n 和 draft_n_accepted 在每个响应的计时信息中。用你自己的提示词运行十分钟再做除法。如果接受率接近该显卡的平均值，草稿模型就是划算的；如果处于低端，你就是在为验证轮次买单，应当将其分离——而且这一结论在两个检查点上都成立，因为机制是相同的。

这两个检查点都不是你可以调用的模型

这正是容易让人误解的地方：人们在模型目录里看到这些名字，就以为它们是菜单上的选项。它们并不是端点。两个草稿模型都没有每百万 token 的价格，都不会出现在 API 列表中，也永远不会被提供模型的平台路由到——因为正确的配对方式是服务器端配置，而不是请求参数。

Liquid AI 自己出售 24B 目标模型的价格是每百万输入 token 0.10 美元、缓存命中 0.05 美元、每百万输出 1.00 美元，而该价格背后运行的任何投机解码对调用方来说都不可见。这就是如今市场的常态形态：有意思的工程发生在服务栈内部，而到达开发者手中的只是一个费率和每秒 token 数。路由平台的价值正体现在这一层之上的比较——把一个候选模型放到它必须击败的模型旁边。OrcaRouter 用一个端点覆盖 200 多个模型，且按供应商标价 0% 加价，因此当某个厂商的费率变化时，你看到的费率当天就会随之变动；而故障转移则能让候选模型在你评估它期间不至于成为单点故障。LFM2.5 系列目前不在其中，因此自托管并附带其草稿模型的 8B 或 24B 仍属于本地部署；值得拿来与它对比测试的模型——智能体侧的 Qwen3.6-35B-A3B、效率侧的 Gemma 4 26B-A4B——正是我们提供路由的那些。

DSpark 发布一年来所确立的成果

这个系列现在涵盖四个文本目标和一个视觉目标，规模从 1.2B 到 24B，全部共享同一套草稿模型配方：约 3 亿参数、五个注意力层、block 9，并在目标模型自身的隐藏状态上训练。这种一致性才是真正的发现。Liquid 已将投机解码从按模型定制的研究项目转变为制造步骤——同一个草稿模型，重新适配后，在每个新模型发布后几天内即可交付。这一步在你的硬件上是否值得采用，是一个关于你的流量的问题；而答案因工作负载而异的程度，远大于因你下载这两个文件中的哪一个而异的程度。

24B 版本的发布为这一图景增添的并不是更好的比率。这是草稿模型首次在没有附带说明文档的情况下发布——也是厂商自己的模型卡首次用直白的语言告诉你，输出最终可能并非逐位一致。