Kolibri 对决 Granite 4.2 3B：一场 78B 稀疏性押注，以及那个拒绝玩同一场游戏的 3B 模型

把 Kolibri和 Granite 4.2 3B摆在一起对比，第一个诚实的观察就是：这不是一场公平的较量，而且不平的方向和你想的正好相反。Kolibri 是 Aleph Alpha 的 78.1 亿参数混合专家模型，于 2026 年 10 月 3 日发布，每个 token 激活 34.6 亿参数。Granite 4.2 3B 是 IBM 约 30 亿参数的稠密推理模型，其权重于 2026 年 8 月 7 日上线 Hugging Face，模型卡与技术博客随后于 8 月 25 日发布。以总参数量计，一个是另一个的 26 倍。之所以它们会出现在同一个决策里，是因为两者都采用 Apache 2.0 许可，都只支持文本，都以自托管为设计前提，也都瞄准了同一类买家：一支希望在自有硬件上实现文档智能、并且要有足以通过采购审查的出处证明的团队。有意思的问题不是哪一个更好，而是那 26 倍的参数预算究竟买到了什么，又需要付出什么代价来承载它。

这种不匹配，直白地说

Granite 4.2 3B 是一个独立稠密模型，基于 Granite-4.1-3B-Base 后训练而来，属于 IBM 截至8月已发布的 Granite 4.2 系列。它有 40 层，采用分组查询注意力，原生上下文为 128K，IBM 在第五个预训练阶段将其扩展到 512K，并提供三种按查询区分的思考模式：默认的完整思考、低投入路径和不思考路径。IBM 的模型卡异常坦率地说明了 3B 不是什么。与它的 8B 和 30B 同系列模型不同，它刻意跳过了在 SWE-agent、终端和搜索环境中训练的专用智能体强化学习模块，因此 IBM 完全没有为它列出 SWE-bench 数据，而是将该模型定位为推理专家，而非智能体。

Kolibri 在每一个维度上都反其道而行。五十层，每一层都是混合专家架构，每层 384 个专家，其中 1 个共享专家、6 个路由专家，稀疏比约为 22.6:1。其上下文原生为 262,144 个 token，经验证可扩展至 1,048,576，而模型卡建议对延迟敏感的工作负载保持在 262,144 或以下。四档推理强度级别。Hermes 风格的工具调用，其 vLLM 解析器与权重发布在同一个仓库中。在 FP8 下占用约 78 GB，模型卡给出的最低配置为两张 A100 80 GB、两张 H100 SXM5、一张 H200、一张 B200 或一张 B300。

• 参数 — Kolibri：总计 78,103,074,560，每个 token 激活 3,457,573,120。Granite 4.2 3B：约 3B 稠密参数，每个 token 均激活全部参数。

• 上下文 — Kolibri：16,384 训练，65,536 中等训练，262,144 原生，1,048,576 已验证。Granite 4.2 3B：原生 128K，扩展至 512K。

• 思考模式 — Kolibri：无、低、中、高，通过聊天模板设置。Granite 4.2 3B：完整、低投入和不思考，按每次查询。

• 工具调用 — Kolibri：Hermes 风格，并随附了现成的解析器。Granite 4.2 3B：支持，但未走上其更大规模同系列模型所接受的智能体强化学习训练路径。

• 语言 — Kolibri：德语和英语，有意为之，别无其他。Granite 4.2 3B：英语优先，背后有 IBM 更广泛的多语言训练作为支撑。

• 占用空间 — Kolibri：FP8 下约 78 GB，至少需要两块 GPU。Granite 4.2 3B：bfloat16 下大约 6–8 GB，量化后不到 2 GB，笔记本级。

• 许可 — 两者均为 Apache 2.0，均不附带“可接受使用”附加条款，也没有月活跃用户门槛。

• 服务 — Kolibri：aleph-alpha-inference vLLM 插件或已发布的容器镜像。Granite 4.2 3B：vLLM、SGLang、Transformers、GGUF 和 Ollama，均在 granite4.2:3b 下。

多出的 750 亿参数能换来什么

有三件事，而这其中哪些是已确立的、哪些只是声称的，值得精确区分。

第一点是德语。这是两个模型之间最鲜明的真实差异，而且它并不是基准测试表格里的一行。Aleph Alpha 围绕一个德英双语语料库构建了 Kolibri，目标是在一次 20 万亿 token 的预训练中让德语约占 20%，最终得到了一个 2.4 万亿 token 的德语池，其中 80% 由该实验室自己策展或生成。模型卡解释了为什么这需要付出努力：去重后的公开德语数据集只提供了 3900 亿 token，差了一个数量级，因此该实验室专门为德语重新调整了 Common Crawl 过滤器，并将现有德语文档改写成百科全书条目、对话和段落。过滤器的细节是值得记住的那一点。标准的语言数据流水线会丢弃包含太多长单词的文档，而德语行政文本的平均词长经常超过英语的界限——因此默认设置会悄悄删除公共行政写作所用的语域。IBM 并不是为那个语料库构建 Granite 的。Granite 4.2 3B 能处理德语；但它并不是围绕德语法律和行政语域设计的，也没有任何排行榜会告诉你这一差异。

第二点是能经受真实文档考验的长上下文。Granite 的 512K 上限确实很大，但这两个模型达到它的方式不同，而 Kolibri 的位置设计是更常规的长上下文方案。把 IBM 的 RULER 数据——4.2 系列已发布材料中 64K 时的 67.52 和 128K 时的 55.30——视为对检索质量到 128K 时衰减程度的诚实披露，并记住 Kolibri 根本没有同等的已发布衰减曲线。

第三点是原始推理余量，而在这方面，诚实的答案是“并不像参数比例所暗示的那么多”。Kolibri 的训练流程为它换来了一次 20 万亿 token 的预训练：在 768 块 NVIDIA B200 上跑了 21 天，而 Aleph Alpha 自己的对比表——在推理强度设为高时的 Kolibri——在一项十四模型对比中，英语平均分为 75.5，德语平均分为 70.8，其中它在大多数行上都输给了阿里巴巴的一款 270 亿参数稠密模型。Granite 4.2 3B 的核心数据则来自它自己：AIME 2025 为 78.33，GPQA 为 54.80，LiveCodeBench v6 为 69.71，MMLU-Pro 为 67.84，全部由 IBM 报告且未经复现。不同的测试套件、不同的评测框架、不同的厂商。这一组合在任何地方都没有同一评测框架下的可比数字，而我们不会去编造一个。

各自真正胜出的地方

如果你的限制在于机器本身，就运行 Granite 4.2 3B。它在 bfloat16 下占用 6–8 GB，量化后不到 2 GB，能装进笔记本电脑、单张工作站 GPU，或一台永远见不到两块 H100 的气隙边缘设备。它可通过包括 Ollama 和 GGUF 在内的五种不同运行时提供服务；当部署目标是别人的笔记本电脑，而不是你自己的机架时，这一点很重要。而它的模型卡格外可信，正是因为 IBM 写下了它省略了什么。一个不愿为 3B 模型宣称 SWE-bench 结果的厂商，就是在告诉你这个模型止步于何处。

如果语料才是关键，而且硬件条件具备，那就运行 Kolibri。一个拥有德语合同、技术文档或行政申报文件、现有双 GPU 节点，并且要求权重绝不离开本机构的团队，正是这个版本所针对的对象。262,144 token 的原生窗口、FP8 KV 缓存、四档努力级别以及 Hermes 工具调用路径，都指向文档工作流，而非聊天。双语分词器也是同一论据的一部分：Aleph Alpha 报告称，在德语网页文本上平均每 token 4.90 字节，而 GPT-5 为 4.35，Kimi K3 为 3.28，这些均由厂商在自家语料上测得；而每 token 字符数更多是直接的推理成本效应，而不是一项得分。如果这一点成立，它会在你处理的每一页上不断累积放大。

没人宣传的不对称性在于数据。IBM 公布了 Granite 4.2 3B 的权重，以及关于该模型如何构建的详细技术说明，但没有公布训练数据。Aleph Alpha 在公布 Kolibri 权重的同时，还公布了流程、数据来源和能耗数字——20 万亿预训练 token，9.5×10² MWh，其中包括数据中心开销，不包括监督微调和强化学习。对于一个必须回答“这个模型的文本来自哪里”的团队来说，这种差异绝不是表面功夫。

两者的路由现实

目前，这两款模型都不在任何托管目录中。Kolibri 完全没有厂商 API SKU——发布内容只有权重和一份技术报告——而 Granite 4.2 3B 以适用于五种运行时栈的权重形式发布，IBM 并未提供托管端点。两者都是自托管方案，对大多数团队来说，实际问题不是采用哪一个，而是工作负载是否值得拥有其中任何一个。

这正是路由层即便对自身并不承载的模型也能体现价值的地方。我们把两个模型名的各种拼写都拿去检索了 OrcaRouter 的目录，Kolibri 和 Granite 4.2 3B 都不在其中，所以我们不会假装它们存在。OrcaRouter 确实能给你的，是在你做出硬件决定之前，用低成本的方式弄清楚这个决定是否站得住脚：把一条测试路径指向一个已经在路由中的小型混合专家档位——Gemma 4 26B-A4B 变体，每百万输入 token 0.06 美元、每百万输出 0.33 美元，上下文窗口 262,144 token——然后看看你的德语文档工作负载是否真的需要 Kolibri 所提供的东西，只需一个 OpenAI 兼容密钥，按提供商的标价，没有任何加价。如果需要，你就是带着证据去买 GPU，而不是凭直觉。如果不需要，你就省下了一笔硬件订单。

裁决，以及什么会改变它

这不是一场有胜负的对决。Kolibri 和 Granite 4.2 3B 在不同的价位上回答不同的问题，唯一诚实的排名方式是按约束条件来排：如果约束条件是硬件，那么两者之中只有 Granite 4.2 3B 合格。如果约束条件是在本地进行德国监管语体文档工作，那么 Granite 4.2 3B 从来就不在候选之列，而 Kolibri 是更有意思的产物——一个货真价实的 78B 开放权重发布，Apache 2.0 许可，数据管线和分词器与权重一同公开。

有两件事能让这场比较有定论。让 Kolibri 在一项德语文档问答任务上独立跑一遍，就能检验该版本发布时真正想证明的说法，因为目前没有任何排行榜在衡量这一点。而对 Granite 4.2 3B 的推理成绩做一次独立复现，则能告诉你：在你那部分从来就不需要 780 亿参数的工作负载上，一台笔记本级别的机器能否站得住脚。在这两者之一落地之前，按约束条件来选，而不是按参数规模来选。