Kolibri vs MiniCPM5-2B：780 亿参数对决 2.5，以及为什么小模型并非廉价之选

把 Kolibri与 MiniCPM5-2B放在一起，直觉上的解读是：这是一场规模对比，而那个 25 亿参数的模型是更经济的选择。这种解读是错的，而且错得很有启发性。Kolibri 是 Aleph Alpha 的 781 亿参数混合专家模型，于 2026 年 10 月 3 日发布，每个 token 激活 34.6 亿参数，FP8 占用约 78 GB，最低服务配置为两张 A100 80 GB 显卡。MiniCPM5-2B 则是 ModelBest 与 OpenBMB 的 25.2 亿参数稠密模型，于 2026 年 7 月 19 日在世界人工智能大会上亮相，权重于 9 月 6 日上线 Hugging Face。按参数量算，MiniCPM5-2B 小了三十一倍。但它同样是需要你在信任它之前先备好一笔评估预算的那个模型，因为它被引用最多的那些数字都是厂商自行跑出、且未经复现的——而这恰恰与“小模型”通常所暗示的风险相反。

两者都已悄然发布；其中只有一个是最近发布的。

它们有着相似的起源故事，年龄却相差悬殊，而年龄很重要。Aleph Alpha 的 Kolibri 代码仓库创建于 2026 年 10 月 2 日，声明的发布日为 10 月 3 日，厂商自己的新闻编辑室公告也在那天上午发出，恰逢德国统一日。通用 AI 媒体当天大多漏掉了这条消息，“静默发布”的说法正由此而来，但一张模型卡、一份技术报告和一篇厂商博文并不算悄无声息的投放。MiniCPM5-2B 才确实更安静：WAIC 上的公告是 5 月发布？不——是大会上对一项宣传和规格的揭幕，而真正的权重直到 9 月 6 日才出现，发布时没有举办任何发布活动，同时还有 GGUF、MLX、GPTQ、base、SFT 和 draft 检查点以及其背后的训练语料库。

从发布公告到权重放出之间隔了五周，这一点值得记住，因为正是它导致这个模型流传着两套不同的数字。七月的材料鼓吹的是 512K token 的上下文窗口，而实际发布的配置设的是 131,072。真正算数的是最终放出的那个产物。

每个模型的实际用途

Kolibri 是为德语和英语文档工作而构建的，而 Aleph Alpha 格外具体地说明了为什么这需要真正的工程投入。小型代理模型实验把训练组合中的德语比例目标设定在约 20%，对于一次 20 万亿 token 的训练来说，这意味着要找到 4 万亿个德语 token。经过去重和过滤的开放德语数据集只提供了 3900 亿个——差了整整一个数量级——于是实验室专门针对德语重新调整了 Common Crawl 过滤器，产出了 1.3 万亿个独特的原生 token，并把现有德语文档改写成百科全书条目、对话和段落，又得到约 1 万亿个，这成为最大的单一德语来源。前身 Kolibri Origin 所使用的翻译，在 Kolibri 中被弃用了。过滤器这个细节值得记住：标准语言数据流水线会丢弃包含过多长词的文档，而德语行政文体在平均词长上常常超过英语的上限，因此默认设置会悄无声息地删掉公共行政写作所用的语域。

MiniCPM5-2B 是为另一端——端侧智能体——而打造的。模型卡描述了一个稠密 Transformer：总参数量 25.2 亿，非嵌入参数 19.8 亿，42 层，隐藏维度 2048，采用分组查询注意力，包含 16 个查询头和 2 个 KV 头，并采用标准的 LlamaForCausalLM 架构，没有自定义内核。其训练流程偏向智能体化：2000 亿规模的智能体中期训练、大规模智能体 SFT 数据集、智能体 RL 对齐，以及最后的 On-Policy Distillation 阶段——将十六个 RL 专家模型合并回一个小型稠密网络。它支持 XML 风格的工具调用，并内置 SGLang 解析器；其发布的配置将上下文窗口设为 131,072 个 token。

• 参数 — Kolibri：78,103,074,560 总计，3,457,573,120 激活，22.6:1 稀疏度。MiniCPM5-2B：2,516,756,480 总计，1.98B 非嵌入，稠密。

• 已发布 — Kolibri：2026年10月3日。MiniCPM5-2B：2026年7月19日宣布，2026年9月6日发布权重。

• 上下文 —— Kolibri：16,384 已训练，65,536 中期训练，262,144 原生，1,048,576 已验证。MiniCPM5-2B：已发布配置中为 131,072；7 月的 512K 声明并不包含在内。

• 资源占用 — Kolibri：FP8 下约 78 GB；最低需要两块 A100 80 GB、两块 H100 SXM5、一块 H200、一块 B200 或一块 B300。MiniCPM5-2B：单个 BF16 分片，笔记本级。

• 语言 — Kolibri：德语和英语，设计如此，别无其他。MiniCPM5-2B：英语和中文，所有已发布的评估套件均为英语。

• 工具调用 — Kolibri：Hermes 风格，随附 vLLM 解析器。MiniCPM5-2B：XML 风格，配备 SGLang 解析器。

• 许可证 — 两者均为 Apache 2.0，且均不附带可接受使用附加条款。

记分牌，以及它们背后的数据来源

对于这一组合，任何地方——无论是哪家厂商的资料里——都没有直接对比的数字，而我们也不会用两套不同的测试装置拼凑出一个数字，然后称之为对比。双方各自公布的内容值得仔细区分开来，因为这两组数字所承载的证据分量截然不同。

Kolibri 的数据来自 Aleph Alpha 自己的十四模型对比表，该表在同一个测试框架上运行，其中 Kolibri 的推理努力程度设为高：英语平均分为 75.5，德语平均分为 70.8。该表并没有美化其评测对象——Qwen3.8 27B 在同一两项平均分上得分 80.2 和 79.9，并在 GPQA Diamond、LiveCodeBench v6、SWE-Bench Verified 以及两个长上下文基准上领先，同时激活的参数量约为 Kolibri 的八分之一。厂商对这一差距的表述是质量与每 GPU 每秒解码 token 数之间的帕累托前沿，所比较的模型无一能超越。这是一个服务经济学论据，而非能力论据，并且没有第三方对此进行过测量：Artificial Analysis 上没有 Kolibri 的条目，也没有对该测试框架的复现。

MiniCPM5-2B 的数字来自它自己的模型卡：在一个由厂商挑选的对比集合上，内部平均分为 53.9；AIME 2025/2026 为 86.5；MATH-500 为 94.6；以及在 SWE-bench Verified 上由厂商自行跑出的 46.4——对于一个 25 亿参数的稠密模型来说，如果这一成绩能经受住独立测试，那将相当了不起。在那张模型卡上，IBM 的 Granite 4.2 3B 为 42.7，而 MiniCPM5-2B 为 53.9——同一家厂商在同一套由它自己选择的测试集上运行这两个模型。测试集不同，测试框架不同，厂商也不同。这一切都不能作为对这对组合的定论。

MiniCPM5-2B 真正有价值的地方在于它的公开披露。OpenBMB 在发布权重的同时一并放出了 UltraData 训练语料——Ultra-FineWeb、UltraX、UltraData-Code、UltraData-Math，以及智能体 SFT 和 RL 数据集——全部采用 Apache 2.0 许可，这就把一个黑箱变成了一份你可以检视、并可在自己领域继续训练的配方。该模型还通过 ModelBest 的 FlagOS 社区实现了对九大芯片家族的零日适配，从华为昇腾到 NVIDIA 和 ARM，这是一份部署层面的声明，而非基准测试层面的。相比之下，IBM 公布了 Granite 4.2 3B 的权重和一份详尽的构建技术说明，却没有公布其训练数据；Aleph Alpha 公布了 Kolibri 的数据流水线和能耗核算——20 万亿预训练 token，9.5×10² MWh，其中包含数据中心间接开销，但不含监督微调和强化学习——却也没有公布语料本身。

尺寸差距实际体现在哪里

将这两者并列比较最有用的方式，是放在决定实际部署的两个维度上：房间里必须有什么，以及当模型出错时会发生什么。

在硬件上，MiniCPM5-2B 胜出，而且优势明显。一个 25.2 亿参数的稠密模型只需一个 BF16 分片，就能在笔记本电脑、边缘设备或单块消费级 GPU 上运行，而 FlagOS 对九大芯片家族的支持意味着它能运行在完全不是 NVIDIA 加速器的硬件上。Kolibri 的最低门槛是两块 A100 80 GB 显卡或一块 B200，约 78 GB 的 FP8 权重，通过 aleph-alpha-inference vLLM 插件或已发布的容器来提供服务。对于智能座舱或手机相关的工作负载，2B 是两者中唯一符合条件的一个，而 Kolibri 从来就不是为在这一领域竞争而设计的。

就可验证性而言，Kolibri 胜出的原因更为微妙。它被引用最多的说法——服务经济性——尚未经过检验，但其质量数据至少是针对十三个具名竞争对手、在同一套测试框架上公布的，并披露了各项设置，而厂商自己的表格在大多数行上都把赢面判给了对手。MiniCPM5-2B 的招牌数字来自厂商、跑在厂商自己的测试套件上，且未披露任何对比框架，同时该模型还背着一层额外的不确定性：它的检查点是数周前的，而非几天前的。两个模型都没有经过独立基准测试。差别在于：一家厂商白纸黑字写下的对比让自己的模型落败，另一家写下的对比则让自己的模型以大幅优势获胜。

这是有意为之，两者之间根本不存在竞争。Kolibri 专为在本地环境处理德语文档而生，其双语分词器据 Aleph Alpha 报告，在德语网页文本上平均每 token 4.90 字节，而 GPT-5 为 4.35、Kimi K3 为 3.28——这些数据均由厂商自行测量，反映的是每 token 成本上的差异，而非质量上的高下。MiniCPM5-2B 则是为在受限硬件上运行的中英文工具调用智能体而生。一个手握德语合同、又有合规要求的团队，并不会在这两者之间做选择。

路由现实，以及值得开展的实验

目前这两个模型都不在任何托管目录中，而且我们是逐一核实过两者，而不是凭空假设。Kolibri 没有厂商 API SKU——其发布物是权重、技术报告和一个容器镜像——它也不在 OrcaRouter 上：我们以厂商前缀和模型名称的所有拼写方式探查了目录，结果均返回“未找到”。MiniCPM5-2B 也没有来自 ModelBest 的托管端点，也不由我们提供路由。两者都属于自托管方案，我们宁愿明确说明这一点，也不愿暗示我们提供其中任何一个模型的服务。

真正有意思的地方在于这个实验。一个 25 亿参数的智能体模型和一个 780 亿参数的文档模型解决的是不同的问题，而要知道你的工作负载需要哪一个，唯一的办法就是让它同时跑这两个——这正是路由层存在的意义所在，即便它本身并不承载这两个模型。把一条测试路径指向自托管的 MiniCPM5-2B 构建版本，通过一个兼容 OpenAI 的端点接入，并带有自动故障转移，同时让生产环境继续留在经过验证的路由模型上，这样新的技术组合就算卡住或输出胡言乱语，也不会拖垮任何东西。你所对比的那些模型，其供应商标价均以零加价原样传递，因此这次 A/B 测试既便宜又可随时回退。而如果实验真正揭示的是，你的德语工作负载这两个自托管模型都不需要，那么同一把密钥还能访问一个已经接入路由的小型混合专家层级——即 Gemma 4 26B-A4B 变体，每百万输入 token 0.06 美元、每百万输出 token 0.33 美元，拥有 262,144 token 的上下文窗口，并支持文本、图像和视频输入——这是在买两块 GPU 之前把这件事搞清楚最便宜的办法。

哪一个，以及什么会改变答案？

如果约束条件是设备，就运行 MiniCPM5-2B。它有 25.2 亿参数，是两者中唯一能装进笔记本电脑、座舱或边缘盒子的模型；如果你的工作负载是英语或中文的交互式工具调用智能体，那么它就是为此而生的模型。先留出时间来复现它的数字——53.9 的平均分和 46.4 的 SWE-bench 成绩都是 ModelBest 单方面给出的，而训练语料的开源让这种复现真正可行，而不只是理论上的可能。

如果语料库是德语、硬件已经到位，而且权重不能离开本地，那就运行 Kolibri。262,144 token 的原生窗口、FP8 KV 缓存、四档推理强度以及 Hermes 工具调用，正是受监管文档工作所需要的形态，而 Apache 2.0 条款加上公开的数据流水线，则是能在采购审查中站得住脚的部分。

有两件事会比任何争论都更快地解决这个问题。对 MiniCPM5-2B 进行一次独立的 SWE-bench Verified 测试，将证实或推翻两张模型卡中任意一张所提出的那个最令人惊讶的说法。而对 Kolibri 在其推荐的双 H100 配置下进行独立的吞吐量测量——或者一个 Artificial Analysis 条目，而后者今天并不存在——将会把“780 亿参数”从一项规格变成一项成本，而这正是任何拿这一对比与硬件进行权衡的人真正在寻找的数字。在那之前，规模差距是真实存在的，用途差距更大，而那个看起来便宜的选项，才是承载着未经验证说法的那个。