Kolibri：Aleph Alpha 的 78B 开放权重模型究竟是什么

Kolibri是来自 Aleph Alpha 的开放权重语言模型，这家海德堡实验室多年来一直主张，欧洲机构需要能在自有硬件上运行的模型。它是一个 780 亿参数的专家混合系统，每个 token 激活约 34.6 亿参数，只读写德语和英语，不涉及其他语言，并具备经过验证的 1,048,576 token 上下文窗口。权重存放在 Hugging Face 上一个名为Aleph-Alpha/Kolibri-1的仓库中，采用 Apache 2.0 许可。同一批发布材料还介绍了 Kolibri Origin，这是一个 306 亿参数的前代模型，经过训练并在内部验证，但从未发布。如果你只搜索这个名称并来到这里，那就是简短答案；本页其余部分就是它背后的规格说明，每个数字都注明其发布来源。

该模型于2026年10月3日发布——Aleph Alpha 自己于10月5日发自海德堡的新闻稿称，Kolibri 自10月3日起已可用，模型卡也标注了同一日期。这里给出这个日期是为了定位该模型，而不是为了发布它。以下内容是长期适用的版本：模型是什么，不是什么，哪些数字来自 Aleph Alpha，以及截至今天，哪些数字根本没有任何来源。

Kolibri、Kolibri-1、Kolibri Origin：三个名称，一次发布

命名是读者首先必须弄清楚的事，因为厂商将其中两个名称互换使用，而第三个则完全属于另一回事。

• Kolibri——该模型是 Aleph Alpha 在所有书面材料中使用的名称：产品页面、公告、技术报告。这是一个德语单词，厂商就是这样拼写的，首字母 K 大写，不带后缀。

• Kolibri-1——在仓库层面是同一个模型。Hugging Face 仓库是 Aleph-Alpha/Kolibri-1，而厂商发布的 serving 命令是 vllm serve Aleph-Alpha/Kolibri-1。这是一个版本标识符，而不是第二个模型，这两个字符串解析为相同的权重。

• Kolibri Origin——另一个模型，而且不是你能下载的那个。它是拥有 306 亿参数、32.7 亿激活参数的前代模型，于 2026 年 6 月完成预训练，曾用于验证训练流程，且从未公开发布。Aleph Alpha 将 Kolibri 的大多数基准测试行报告为与它配对的对照列，这就是为什么这个名字几乎出现在每一张关于 Kolibri 的表格中。如果你在找权重，这不是你要找的那个。

并不存在单独的“Kolibri 2”，也没有以其他名称发布的、针对聊天调优的变体，更没有量化过的官方发行版。下载索引里任何其他顶着这个名字的东西都是第三方转换版本，而厂商自己的资料中并未记录过这样的版本。

规模：78B 这个数字是对的，而决定一切的是第二个数字

一个关于“Kolibri 78B”的疑问一直在流传，而厂商对此予以确认，而非加以纠正。根据随权重一同发布的模型卡：总参数为 78,103,074,560 个，其中每个 token 激活 3,457,573,120 个。这大约是 22.6 比 1 的稀疏比。

这种区分并非吹毛求疵。总参数量决定模型需要多少内存；活跃参数量决定每个 token 需要多少计算量。一个总参数量为 78B、活跃参数量为 3.46B 的模型，是一个体量极大的产物，但在推理时，按每个 token 计算，它的行为却像一个小模型——这正是 Aleph Alpha 能为这种规模的东西给出双 GPU 部署下限的原因。任何关于 Kolibri 的概述，如果只告诉你 78B 而不提活跃参数量，就漏掉了决定账单的部分。

与其自身谱系相比的规模：Kolibri Origin 总参数量为 30.6B，其中激活参数为 3.27B。Kolibri 将总参数量大致翻了一倍，而激活参数量却几乎没有变化，这说明的是单位服务成本所能承载的容量，而非原始速度。

架构与许可：权重究竟是什么，以及 Apache 2.0 在这里实际覆盖了什么

Kolibri 是一个 50 层的混合专家 Transformer，完全不含稠密前馈层。每一层都会路由到 384 个专家，每个 token 激活其中 6 个，外加 1 个共享专家；专家的中间维度为 512，模型维度为 2,560。注意力是混合式的：大多数层使用 512 个 token 的滑动窗口，只有每第五层才使用完整注意力。Aleph Alpha 的架构文章直白地指出了其后果——与 Kolibri Origin 相比，在 16K 上下文下，纯注意力运算所占比例从 51% 下降到 27%，完整注意力层的数量也大约降至五分之一。

该分词器是一个德英双语构建版本，词汇量为 128,000 个词元，采用该实验室称为 UniBPE 的方法训练。刻意只涵盖两种语言：供应商将这一范围定位为深度优先于广度，并且直言不讳地这么说，而不是把两种得到充分支持的语言包装成一项多语言成就。

许可证是 Apache 2.0，而模型卡对其边界的规定异常精确。用模型卡自己的措辞来说，该许可证“仅适用于本仓库中发布的权重和配置文件”——它不延伸至底层代码、架构定义、参数设置或训练方法。因此，对部署团队而言，实际立场是这样的：权重是真正开放的，可商用，没有可接受使用附加条款，没有月活跃用户阈值，也没有单独的商业条款，但该许可证并不构成对 Aleph Alpha 训练配方或其推理代码的授权。如果你的法律审查问，这是否是 OSI 意义上的开源，那么诚实的答案是：它是在 OSI 认可许可证下、带有明确范围限制的开放权重，而这两者并非同一种主张。

上下文窗口和最大输出

Aleph Alpha 将上下文窗口分为两个层级发布，这一区分值得保留。

• 已验证的最大值 — 1,048,576 个token，产品页面和模型卡片上均有说明。

• 原生支持并推荐 — 262,144 个令牌。该卡片建议为了部署效率和复杂任务，保持在此数值或以下；厂商页面则将 256K 称为实际工作数值。

• 训练进程 — 在 16,384 个 token 上进行预训练，在 65,536 token 的视野下进行中期训练，然后扩展到 262,144 作为训练长度。

达到完整的百万并不是默认就能获得的配置。服务配方需要显式的最大模型长度标志以及位置嵌入覆盖，厂商对此有文档说明。请把 1M 理解为有文档化流程验证过的上限，而把 262 理解为应围绕其设计生产工作负载的数字。

最大输出长度未公布。产品页面、模型卡和公告均未说明生成上限。如果某项部署依赖硬性输出限制，那么这应询问 Aleph Alpha，或取决于你自己的服务配置——发布材料并未对此作出解答。

模态：仅文本，而且这是一条刻意设定的边界

Kolibri 是一个文本输入、文本输出的模型。其模型卡片的 pipeline 标签是文本生成，它将模型描述为处理文本输入并生成文本输出，并指出训练语料仅包含文本。没有视觉编码器，没有音频通路，没有图像生成，除了文本形态的工具调用之外，也没有任何有文档记录的工具结果模态。

这正是厂商措辞与读者预期最常出现分歧的地方，所以值得直说：Kolibri 的名称、它的规模或其同系列型号，都不应让你以为它接受图像。它并不接受。它的两种语言是德语和英语，而且它不是为处理第三种语言而构建的——无论某个演示用它做什么，法语或西班牙语请求都超出了设计目标。

它确实具备的是工具调用——Hermes 风格，解析器与权重一同发布在同一个仓库中——以及四个推理强度等级，无、低、中、高，通过聊天模板进行设置。两者都是有文档记载的行为，而非社区发现。

Aleph Alpha 所声称的，以及其他任何人所测量到的

两个类别，而且它们的大小并不相同。

厂商报告，来自 Aleph Alpha 自己的测试框架，由 Aleph Alpha 运行，由 Aleph Alpha 发布：Kolibri 在英语和德语的质量与服务成本权衡中位于帕累托前沿；它可媲美活跃参数量最高达其四倍的模型，厂商用 Nemotron 3 Super（一个 120B-A12B 模型）来举例说明这一说法；它专精于德语、推理、数学和智能体任务，在工具使用方面表现强劲（Tau2-Bench 电信 94.7%，零售 69.9%，航空 76.7%；BFCL v4 总体 61.4%），推理方面也很突出（GPQA Diamond 英语 84.3%，AIME 2025 英语 96.9%）。同一张表中的德语数据——GPQA Diamond 81.3%、AIME 2025 87.5%、AIME 2026 90%——来自相同基准的德语版本。

经独立测算，截至2026年10月13日：无。Artificial Analysis没有收录Kolibri，其服务商列表中也没有Aleph Alpha这一行；模型卡本身说明该模型未由Hugging Face上的任何推理服务商部署；尽管评测框架的代码在该实验室自己的仓库中公开，却没有任何第三方发布过对厂商评测框架的复现。这项评测很详尽，但它只是一家实验室的评测。在Heidelberg以外的人跑通之前，请把上文中的每一个百分比都当作厂商的说法。

厂商材料中的一个数字值得特别留意，而不是仅作重复。Aleph Alpha 的产品页面显示，Kolibri 的 AA-Omniscience 指数为 33.6%。该指数是 Artificial Analysis 构建的指标，而 Artificial Analysis 目前未发布任何 Kolibri 条目。这个数字是 Aleph Alpha 自行运行他人指数所得的结果，发布它是正当的，但将其解读为独立评分则是不正当的。在指数所有者公布自己的数字之前，它只是一个由厂商报告的数字。

你到底怎么运行它

没有可指向的托管端点。Kolibri 以权重加推理包的形式分发，调用它意味着你得自己运行。

• 安装 — pip install "aleph-alpha-inference>=1.0"，它会提供 Kolibri vLLM 插件，并固定其所支持的 vLLM 版本；或者也可以拉取容器镜像 ghcr.io/aleph-alpha/aleph-alpha-inference。

• Serve — 对 Aleph-Alpha/Kolibri-1 执行标准 vLLM 调用，并启用 FP8 KV 缓存、Kolibri 推理解析器、Kolibri 工具调用解析器以及自动工具选择。

• 内存——FP8 权重约为 78 GB。公布的最低配置为两张 A100 80 GB 显卡、两张 H100 SXM5、一张 H200、一张 B200 或一张 B300；推荐配置为两张 H100 SXM5、两张 H200、一张 B200 或一张 B300。

• 采样——温度 1.0，top-p 0.97，top-k 128，根据模型卡的建议。

• 接口 — 兼容 OpenAI，本地提供服务。现有的 chat-completions 代码可以指向它；reasoning effort 会通过聊天模板传递，工具调用则落在标准的 tools 字段中。

供应商自己的注册表单将“Modelltest API”作为一种申请类别提供，因此可以通过销售团队进行 API 洽谈。没有任何已发布的信息将其描述为可用、已定价或可自助使用。

发布材料中没有任何一处标明价格，因为根本没有什么可定价的：权重可以免费下载，而使用 Kolibri 的成本，就是你在它下面所配置的 GPU 的成本。Aleph Alpha 也没有为该模型公布任何速率限制、免费额度或试用层级——任何与此相反的说法，都只是从“available”这个词推断出来的，而不是来自厂商页面的既定事实。

OrcaRouter 上没有路由，以及诚实的替代方案

我们今天查了自己的目录：OrcaRouter 提供 207 个模型，其中并没有 Kolibri——无论用这个名字的哪种拼写，还是加上 Aleph Alpha 前缀，都找不到。这对读者来说很重要，因为他们真正的问题是"我能不能不买两块 H100 就调用它"，而答案是不能——在这里不行，在厂商自家基础设施上作为已发布的服务也不行。眼下，自行托管是运行 Kolibri 的唯一途径。

如果你需要的是今天下午就能调用的、同时具备德语和英语能力的专家混合模型，那么我们手头最接近的是 Gemma 4 26B A4B IT——一个开放权重的 MoE，每百万输入 token 收费 $0.06，每百万输出 token 收费 $0.33，上下文窗口为 262,144 个 token——与 Kolibri 推荐的工作数值属于同一上下文量级，而且是按 token 计费的单列项目，而不是 78 GB 显存外加一场采购沟通。OrcaRouter 对其承载的每一个模型都按提供商的标价路由，不额外加价，这是判断某项工作负载是否值得自购硬件的省钱办法。有两点我们要明说而非暗示：这是另一个模型，权重也不同，它无法替代 Kolibri 在德语预训练上的深度。这是一个可以租用的模型与一个必须自有的模型之间的诚实对比。

对于正在权衡主权部署的团队而言，还有第二个理由选择路由而非直接落地。如果某项工作负载目前由托管模型提供，而你正在考虑将其迁移到自托管的 Kolibri，那么真正有用的测试是让两者都跑你自己的流量，而不是去读两张基准测试表——而一个带有自动故障转移的路由端点，正是运行这项测试风险更低的地方，而不是你已经迁移过去的生产路径。

Kolibri 的立场

Aleph Alpha 发布了一份异常完整的模型说明——训练流水线、数据来源、分词器方法、能耗数字，以及一个曾构建后又弃用的前代模型——并以一份公司真正能够据以部署的许可证发布了权重。对于德国公共部门或工业领域的买家而言，其采购规则首先关注数据存放在哪里，这种组合本身就是产品，任何基准测试的一行成绩都无法替代它。

买家目前还无法做的是核实这些说法。没有独立评估，没有托管端点，也没有可用于与任何其他东西比较的价格，这意味着决策只能依赖厂商自己的数字加上一次自托管试用。这是一个真实的局限，但这并不是否定该模型的理由——它正是上文规格值得逐行细读、而非只扫一眼百分比的原因。如果你想了解 Kolibri 是什么，答案是：一个 78B 开放权重、纯文本、德英双语的 MoE，具有 1M token 上限和双 GPU 最低要求。它是否适合你的工作负载，只有你自己的评估才能回答。