LBS-27B 与 Granite 4.2 30B 对比：以稠密设计应对并不存在的规格

IBM 对 Granite 4.2 30B做出了一个刻意的选择：让模型保持稠密。六十四层，一个宽度为 32,768 的前馈块，每个 token 都要读取每一个参数。在同类规模的大多数实验室都转向混合专家路由的一年里，IBM 却发布了一个直通式 30B，并据此定价。这个决定是把它与 LBS-27B进行比较的合适视角，因为我们对 inclusionAI 这个新仓库所知道的一切只是一个名称和一份许可证——而这个名称必须回答的第一个问题是：它描述的究竟是一个稠密模型，还是一个稀疏模型。

Granite 4.2 30B 拥有完整的公开记录：权重自 2026 年 8 月起公开，采用 Apache-2.0 许可证，模型卡包含十九行基准测试结果，并有文档化的工具调用栈。LBS-27B 有一个创建于 2026 年 10 月 26 日的仓库，其中包含一个 .gitattributes 文件和一个 28 字节的 README；该 README 声明采用 Apache-2.0，除此之外别无内容。这不是两个模型之间的比较。这是将一个模型与一份尚未写出的规范进行比较，而有用的输出是一份清单，列出该规范需要包含的具体内容。

IBM 实际交付了什么

Granite 4.2 30B 是一个拥有 300 亿参数的稠密解码器——Hugging Face 在 BF16 下列出为 29B——共 64 层，隐藏大小为 4,096，在分组查询注意力下具有 32 个注意力头和 8 个键值头。词表为 100,352 个 token，原生上下文为 131,072，IBM 记录了到 512K 的长上下文扩展。它仅支持文本。模型卡列出了十二种测试语言：英语、德语、西班牙语、法语、日语、葡萄牙语、阿拉伯语、捷克语、意大利语、韩语、荷兰语和中文。

这是一个普通 2026 年意义上的推理模型。模型卡描述了完整思考、非思考和低努力模式，其中推理内容包裹在 think 标签中。它基于 Granite 4.1 30B Base 微调而来，以 Apache-2.0 许可发布，IBM 将发布日期定为 2026 年 8 月 25 日。

稠密并不是技术上的短板。它是一种取舍。稠密模型对每个 token 的计算和内存行为都可预测，没有可能把 token 路由错的路由器，无需设计专家并行分片，而且微调体验符合大多数团队的预期。作为交换，与同等总规模的稀疏模型相比，它的每 token 服务成本更高。IBM 正在向那些宁愿要一个平淡稳妥的部署、也不愿要一个廉价部署的企业推销这种取舍。

一个带有形状的基准配置文件

Granite 的卡片异常完整，因此可以看出该模型在哪些方面强、哪些方面不强。以上均为厂商报告，尚未经独立复现。

• 数学——AIME25 89.17 和 HMMT February 2025 89.17。这些是卡片上最突出的数字，远高于一年前 30B 模型的表现。

• 知识与科学——GPQA 66.41、MMLU-Pro 77.60、MMLU-ProX lite 66.64、SciCode 38.76。表现称职，但并非领先水平。AIME 得分接近 90，而 GPQA 得分处于 60 多分中段，这一差距正体现了这个模型的特点：它更擅长处理结构化问题，而不太擅长在广泛领域知识中进行回忆或推理。

• 软件工程 — SWE-Bench Verified 57，SWE-Bench Pro 33.29，SWE-Bench Multilingual 41.89，Terminal-Bench 2.1 29.24，LiveCodeBench v6 75.77。从 LiveCodeBench 到 Terminal-Bench 的落差很大，而这一点很重要：竞赛编程能力并不等同于在真实终端中完成一项多步骤任务的能力。

• 长上下文——RULER 64K 89.96 和 RULER 128K 81.38。这是参数卡上最令人安心的一组数据，因为它衡量的是整个窗口内的检索能力，而不是假定大上下文就一定可用。从 64K 到 128K 下降七个百分点，是一条平缓的坡度。

• 指令遵循与聊天 — IFBench 77.17，Arena-Hard-V2 67.93，tau3 平均 62.00，BFCL v4 61.39。

诚实的解读是：Granite 4.2 30B 是一个扎实但并不均衡的模型：在竞赛数学和长上下文检索方面表现出色，在广泛知识方面表现平平，在智能体软件工作方面处于中游。这是一款有明确定位的产品，而非泛泛之作。

工具调用正是 IBM 所提出的论点

IBM 使用的说法是“推理增强的工具调用”——模型在调用工具之前会先推理要调用哪个工具以及为什么。其实现细节务实而不猎奇：OpenAI 风格的函数定义、名为 qwen3_coder 的 vLLM 工具解析器、SGLang 自动解析到同一解析器，以及与 OpenCode、Pi 和 OpenHands 的集成。

这是否优于其他选择是一个实证问题，而模型卡自身的数据也喜忧参半。BFCL v4 的 61.39 和 tau3 的 62.00 算得上可观，但并非占优；在这些排行榜上领先的模型通常规模更大。Granite 所提供的是有文档记录、可复现的工具调用路径，宽松的许可，以及稠密模型的服务配置——这往往正是企业智能体项目实际需要的，胜过排行榜上的桂冠。

如果 LBS-27B 面向的是同一类买家，那么这将是它首先受到评判的领域。一个无法可靠调用工具的模型，无论其 MMLU 分数如何，都不适合承担智能体工作；而工具调用评估恰恰是那种在模型完成之前不会出现在代码仓库中的内容。

页面中 LBS-27B 的那一侧

可说的很少，重要的是准确地把它说出来，而不是用推断来填充空白。

• 该仓库存在。它创建于 2026 年 10 月 26 日 05:36 UTC，此后未再被修改。

• 它包含两个文件：一个 1,519 字节的 .gitattributes 和一个 28 字节的 README。该 README 仅包含许可证前置元数据：license: apache-2.0。

• 没有权重、没有配置、没有分词器、没有模型卡，也没有评估数据。下载量未被追踪，点赞数为零。我们没有发现任何公告、论文或公开讨论。

• “27B”是仓库名称的一部分。仓库中没有任何内容能证实它代表参数量，也没有任何信息表明该模型是稠密模型还是稀疏模型。

最后一点并非小缺口。稠密和稀疏的 27B 模型是不同产品，具有不同的服务经济性、不同的微调行为和不同的故障模式。在配置文件存在之前，Granite 对比中只有一侧是完全明确的，另一侧则是空的。

比较，逐维度进行

• 参数 — Granite 4.2 30B 是 30B 稠密模型（BF16 下列为 29B）；LBS-27B 是未经核实的 27B 模型，未披露架构。

• 层数与宽度——Granite 为 64 层、隐藏维度 4,096；LBS 未知。

• 上下文 — 原生 131,072，以及 Granite 有文档记录的 512K 扩展；LBS 未知。

• 模态——Granite 仅支持文本；LBS 尚不明确，以仅文本作为合理的基准情况。

• 语言 — Granite 测试了十二种语言；LBS 未知。

• 推理模式 — Granite 支持完整、非思考与低投入模式；LBS 未知。

• 工具调用——Granite 有文档记录的函数调用路径，BFCL v4 为 61.39，tau3 为 62.00；LBS 方面未发布任何内容。

• 许可证 — Granite 采用 Apache-2.0；LBS 声明采用 Apache-2.0，可在权重发布前更改。

• 可用性 — Granite 权重目前可供下载并支持自托管；LBS 则没有任何可下载的内容。

上下文长度是两者最可能出现分歧的地方

Granite 原生 128K 窗口并支持扩展至 512K，这是一项有意设计的企业级特性，而 RULER 分数表明它并非只是营销：128K 下达到 81.38 是一个可用的结果。对于合同审查、日志分析、代码库检索和长审计轨迹而言，这种组合——有文档记录的扩展路径，加上接近窗口顶部的检索证据——比一个背后没有证据的更大数字更有价值。

如果 LBS-27B 以 256K 或 512K 窗口发布，真正有趣的问题不会是数字本身，而是 inclusionAI 是否会公布该窗口远端位置上的检索评测结果。窗口只是一种容量声明；RULER 风格的结果则是能力声明，而在实践中，这两者往往相去甚远。

部署、许可授权以及路由器的定位

两个模型均声明采用 Apache-2.0 许可证，这对商业使用而言是最宽松的结果，也是 Granite 在无法接受自定义许可证的团队中广受欢迎的原因。Granite 4.2 30B 不在 OrcaRouter 上，LBS-27B 也不在；如果你想要 Granite，就自行下载并部署服务，或使用托管平台。

这种自托管部署正是混合架构能发挥作用的场景。在日常流量上用自己的硬件运行 Granite——分类、抽取和工具调用这类流量，一个稠密的 30B 模型就绰绰有余——再把真正困难的案例路由到托管的前沿模型。OrcaRouter 在有后半部分就很有用：一个 API 密钥即可访问 200 多个模型，当某个提供商性能下降时会自动故障转移，还有一套路由 DSL，让你把这种分工表达为策略，而不是写在三个服务里的代码。我们按提供商列表价格原价透传，0% 加价，因此账单中托管侧的费用就是提供商给出的数字，而不是我们加上利润后的价格。

我们要说明的是，本次对比中的两款模型均无法通过我们获取。事实并非如此，若对比页面暗示可以获取，那比毫无用处更糟。

什么才能定论这场比较

三件实物就能让这一页从规格推演变成一场真正的较量。

第一个是一个config.json，带有专家字段，它确定了是稠密还是稀疏，并给出活跃参数数量。如果 LBS-27B 是稀疏且活跃参数较少，它将在服务成本上低于 Granite，比较就变成价格与质量的权衡。如果它是稠密的，那就是直接替代的问题，IBM 的工具链成熟度就成为决胜因素。

第二项是在指定版本的评测框架上进行的工具调用评测。Granite 的 BFCL v4 和 tau3 成绩并不亮眼，这意味着新模型不必表现亮眼就能超越它们——它需要的是在同一评测框架上接受测量。

第三点是 128K 或更长上下文下的长上下文检索证据。Granite 的 RULER 数值是其在企业相关性方面最有力的主张，也是应当要求挑战者达到的数值。

对于今天就要做决策的企业买家而言，Granite 4.2 30B 是一个已知量：它拥有宽松的许可证、有文档记录的工具栈，以及许多基础设施团队偏好的密集服务配置。LBS-27B 则只是一个名字，外加一行许可证信息。两者之间的差距并不是对 inclusionAI 工程能力的评判，而仅仅是已发布模型与被保留模型之间的区别。