LBS-27B 与 LFM2.5 24B A2B：激活参数之问

最重要的数字在LFM2.5 24B A2B中并不是 24，而是 2.45——模型每处理一个 token 实际读取的参数为 24.5 亿。正因如此，Liquid AI 才能宣称在 Apple M5 Max 上达到每秒 184 个输出 token，同时模型拥有 240 亿参数的知识，也正因如此，该公司将其定位为端侧智能体，而非数据中心的主力。同样的数字在LBS-27B中缺失，而这种缺失正是目前无法定论这项比较的原因：没有活跃参数数量，就无法将 inclusionAI 的模型放到 LFM2.5 所定义的效率曲线上。

LFM2.5 24B A2B 自 2026 年 10 月 13 日起即可下载，配有模型卡、十六行基准测试数据，以及一份大多数企业都需要仔细阅读的许可证。LBS-27B 是一个创建于 2026 年 10 月 26 日的仓库，其中包含一个标准的 .gitattributes 文件和一个 28 字节的 README，声明采用 Apache-2.0。没有权重、没有配置、没有模型卡、没有公告。因此，接下来是一场比较：一方是规格完整的效率型方案，另一方是一个尚未说明自己属于何种模型的名称。

Liquid 优化的目标是什么

LFM2.5 24B A2B 是一个混合专家解码器，包含 64 个专家并采用 top-4 路由，具有 40 层、2,048 的隐藏维度和 128,000 个 token 的词表。其激活参数为 24.5 亿。它支持 131,072 个 token 的上下文，相比上一代的 32K 有大幅提升，并且它在 33 万亿个 token 上进行了预训练，大约是 LFM2 所用 17 万亿的两倍。

词表的变化是一个值得注意的细节。从 65K 扩展到 128K tokens 代价高昂——这意味着要重新训练嵌入层和输出层——而这样做的常见原因是非拉丁文字。卡片列出了十六种语言：英语、阿拉伯语、中文、法语、德语、意大利语、日语、韩语、葡萄牙语、西班牙语、越南语、泰语、印尼语、印地语、俄语和波兰语。更大的词表使这些语言在每个词上的成本更低，并且通常在长尾部分表现更好。

它也是一个纯推理模型。Liquid 的后训练流水线依次执行监督微调、教师专业化、非智能体蒸馏与智能体蒸馏，然后在 OpenClaw、Hermes Agent、Pi 和 OpenCode 等框架内进行智能体强化学习。该模型在回答前会生成思维链；模型卡上没有记录单独的“快速、无思考”模式。

一份刻意设计成尖峰状的基准测试配置

Liquid 自己给出的数据——我们并未复现——描述了一个在端侧智能体擅长的事情上表现出色、但在知识工作者所需的事情上表现不佳的模型。这种形态并非偶然；这正是设计使然。

• 指令遵循 — IFEval 96.75，IFBench 74.69，Multi-IF 84.38。这是卡片上最强的一组指标，也是对于必须遵守工具 schema 的智能体而言最重要的一组。

• 工具使用 — ToolSandbox 80.71，PinchBench 83.18，BFCL v4 65.01，AutomationBench 27.69。表现不错，但在不同评测框架之间并不均衡。

• 智能体式浏览与计算机使用 — LiveClaw 48.09，WebArena Verified 26.75，tau3-Bench Banking 8.04。银行业务这一结果是异常值：在一个其他智能体模型处理得好得多的任务套件上，得分仅为个位数。这提醒人们，“智能体式”并不是一种单一能力。

• 软件工程——在 OpenCode 下，SWE-Bench Verified 为 51.00，SciCode 为 32.71。处于中游水平。

• 数学 — MATH-500 96.04。就这个规模而言表现很强。

• 知识——GPQA Diamond 74.42，HLE 7.40，AA-Omniscience −24.90。负的 Omniscience 分数在这里是诚实的信号：在一个会惩罚自信错误答案的基准测试上，该模型失大于得。Liquid 自身的定位也承认这一点——该模型旨在与检索配合使用，而不是被当作百科全书来信赖。

综合来看，这些结果说明该模型能胜任指令遵循和工具调用，但知识储备相对薄弱。对于本地代理这类读取你的文件、调用你的 API 的场景，这是正确的取舍；但对于研究助手，则是错误的选择。

效率主张及其附加说明

Liquid 报告称，在 Apple M5 Max 上使用约 15GB 内存时达到每秒 184 个 token，在 Ryzen AI Max+ 395 上达到每秒 114 个 token。这些是特定硬件上的厂商数据，并非通用基准，并且会随量化和批大小而变化。方向仍然有意义：一个拥有 24B 参数、其中 2.45B 活跃的模型，能以稠密 24B 模型无法做到的方式在笔记本电脑上运行。

代价是内存带宽。稀疏模型仍然必须在内存中保存全部 240 亿个参数——节省的是每个 token 的计算量，而不是存储。这就是为什么 15GB 这个数字与吞吐量同样重要：它大致相当于对完整权重集进行 4 位量化，并设定了硬件下限。

LBS-27B 必须安置在哪里

这次对比的一切都取决于两个字段，而这两个字段在 LBS-27B 仓库中尚不存在：专家数量和激活参数量。

如果 LBS-27B 是稀疏模型，激活参数量大约在 2B 到 4B 之间，那它就正好落在 LFM2.5 的地盘上——以小型模型的算力提供 27B 级的知识库——此时比较就变成了单位激活参数质量的直接比拼。如果它是稠密模型，那就是完全不同的产品：一个服务端模型，算力可预测，而内存占用会让大多数笔记本电脑无法胜任。如果它是稀疏模型且激活参数量很大，它就介于两者之间，竞争的是质量而非效率。

无法从仓库中推断出是哪一个。名称写的是 27B，README 写的是 Apache-2.0，而文件树没有提供其他信息。我们找不到 inclusionAI 发布的模型卡、博客文章或论文。

就所能进行的比较而言

• 总参数量——LFM2.5 24B A2B 为 24.0B；LBS-27B 为未经核实的 27B。

• 活跃参数——LFM2.5 为 2.45B；LBS-27B 未知，而这是决定性的未知因素。

• 架构 — LFM2.5 采用 64 个专家、top-4 路由和 40 层；LBS-27B 未知。

• 上下文 — LFM2.5 为 131,072 个 token；LBS-27B 未知。

• 模态 — LFM2.5 仅支持文本；LBS-27B 未知。

• 语言 — LFM2.5 列出了十六种；LBS-27B 未知。

• 推理——对于 LFM2.5，默认采用思维链，且没有文档记载的无思考模式；LBS-27B 未知。

• 许可证——LFM 1.0 许可证，适用于 LFM2.5：年收入超过 1000 万美元即需商业许可证；LBS-27B 声明采用 Apache-2.0。

• 已发布的评估——LFM2.5 有十六行由供应商报告的数据；LBS-27B 则没有。

许可证是一个采购问题，而不是脚注。

这是空仓库已经让 LBS-27B 占据优势的唯一一个维度。LFM 1.0 许可证并非 OSI 意义上的开源：年收入超过 1000 万美元的公司需要先获得单独的商业许可证，才能部署它。对于个人开发者或低于该门槛的初创公司来说，这不成问题。对于中型公司来说，这意味着一轮法律审查、一场谈判和一项预算条目。

LBS-27B 在其 README 中声明采用 Apache-2.0。这是一种宽松许可证，带有明确的专利授权且没有收入门槛；如果该声明能延续到权重发布阶段，就会省去整个采购步骤。这是 LBS-27B 目前在此项比较中拥有的唯一具体优势，值得明确指出，因为它是真实的——在仓库创建时作出的许可证声明是弱证据，但并非毫无价值。

设备端与 API：两款不同的产品

LFM2.5 24B A2B 专为在数据所在之处运行而打造。其卖点是隐私和延迟：一款在笔记本电脑或工作站上运行的模型，从不向第三方发送请求，其工具调用能力足以驱动本地自动化。4 位内存占用和 131K 上下文正是为这项任务量身定制。

LBS-27B 尚未说明其用途。如果 inclusionAI 发布的是面向服务器端服务的模型，那么端侧部署的论据就不适用，这两个模型是互补而非替代关系。如果它发布的是具备本地部署方案的小激活 MoE，那么比较就是直接的，而 Liquid 在端侧工具链上领先两代的优势——支持 llama.cpp、MLX、ONNX 和 vLLM，外加有文档记录的智能体运行框架——将成为决胜因素。

框架支持是这其中被低估的一环。一个第一天没能进入 llama.cpp 或 MLX 的模型，实际上就称不上是端侧模型，无论它的激活参数量是多少。

在不为未经验证的模型押注的情况下对其进行测试

LBS-27B 和 LFM2.5 24B A2B 目前都不在 OrcaRouter 上，因此两者都没有托管端点，我们也不会暗示并非如此。这里提到该平台，是因为随之而来的评估问题：如果你想知道一个新的小激活模型能否替代你当前的模型，你需要用你自己的流量来运行两者，而不是在排行榜上。

OrcaRouter 的路由 DSL让你可以将一定比例的请求发送到候选模型，同时将现有模型保留为默认；自动故障转移意味着超时或出错的候选模型会降级到已知模型，而不是让请求失败。对于单个模型不够用的难题，模型融合让一组模型共同作答并返回合并结果——当任务知识密集、而便宜模型的弱点恰恰是你要测试的内容时，这很有用。200 多个模型的目录和 0% 加价在这里没那么重要，更重要的是能够在你自己的输入上进行比较，而无需第二次集成。

这是生成此页面所缺失的证据的一种方法。它不能替代模型本身的存在。

三位读者，三种答案

如果你正在构建一个设备端智能体，并且需要某种今天就能在笔记本电脑上运行的东西，那么 LFM2.5 24B A2B 是一个值得认真考虑的候选：指令遵循能力强，在多种评测框架上的工具调用表现良好，具备 131K 上下文，并且有文档说明如何接入常见的本地运行时。请先检查许可证门槛，并且不要指望它在没有检索的情况下掌握事实。

如果你正在挑选一个服务端 27B，并且需要宽松许可证，那么 LBS-27B 值得关注，正是因为它已经声明了 Apache-2.0。但目前没有任何可供评估的内容，而许可证声明并不等于模型。

如果你是一家营收超过1000万美元、采购流程严格的企业，那么许可证上的差异可能比本文中任何一行基准测试结果都更重要。LFM2.5的自定义许可证是一项实实在在的成本；LBS-27B的Apache-2.0则是一项实实在在的优势，前提是它能一直保留到正式发布。

能改变这三个答案的数字是激活参数量。在它出现之前，诚实的立场是：一个模型有的是效率叙事，另一个有的是一个仓库。