Aleph Alpha 在 10 月 3 日开放了 Kolibri 1 的模型权重：总参数量 781 亿，但每个 token 实际激活约 34.6 亿参数。这个组合很容易让人产生一种错觉——它是不是可以像 30 多亿参数的模型一样部署？

答案是否定的。激活参数主要影响一次前向计算要做多少乘法，总参数则更接近模型权重需要占多少存储和显存。 Kolibri 用 MoE 把两本账拆开了：算的时候只走少量专家，但可供选择的全部专家仍然要放在机器上。

这也是阅读 MoE 模型规格时最重要的分界线。

78B 和 3.46B，是两本不同的账

Kolibri 有 50 层，每层都包含 384 个可路由专家。一个 token 到达某一层时，路由器只挑选其中 6 个专家，同时还会经过 1 个共享专家。按照模型卡给出的精确数字：

• 总参数：78,103,074,560；
• 单个 token 激活参数：3,457,573,120；
• 激活比例约为 4.43%。

可以把它想成一家有 384 个专科科室的大医院。每位患者只去其中 6 个专科，再经过一个所有人共用的综合门诊，所以单次诊疗不需要动员整家医院；但医院不能因为这一位患者没去其余科室，就把那些科室从楼里拆掉。下一个 token 可能会被分到完全不同的专家。

因此，3.46B 不能直接拿来估算模型文件大小，也不能据此判断一张消费级显卡是否装得下。它表达的是每个 token 的主要计算路径，而不是整套权重的体积。

路由器不是“选分数最高的六个”那么简单

Kolibri 推理插件公开了路由逻辑。简化后，它会先给每个专家的路由分数加上一个校正偏置，用校正后的分数选出前 6 个专家；真正混合专家输出时，权重又来自专家原始分数的 sigmoid 值。

下面是一个只有 4 个专家、每次选 2 个的最小示意。它不加载 Kolibri，也不代表模型质量，只复现了“校正分数负责入选、原始分数负责加权”这一段逻辑，可以直接用 Python 标准库运行：

from math import exp


def sigmoid(value):
    return 1 / (1 + exp(-value))


def route(logits, bias, top_k=2):
    ranked = sorted(
        range(len(logits)),
        key=lambda i: logits[i] + bias[i],
        reverse=True,
    )
    return [(i, sigmoid(logits[i])) for i in ranked[:top_k]]


logits = [2.0, 1.8, 0.5, -0.2]
bias = [0.0, -1.0, 2.0, 0.0]

print("selection scores:", [a + b for a, b in zip(logits, bias)])
print("selected expert and weight:", route(logits, bias))

total_parameters = 78_103_074_560
active_parameters = 3_457_573_120
print(f"active ratio: {active_parameters / total_parameters:.2%}")
print(f"BF16 weights: {total_parameters * 2 / 1e9:.1f} GB")

实际输出为：

selection scores: [2.0, 0.8, 2.5, -0.2]
selected expert and weight: [(2, 0.6224593312018546), (0, 0.8807970779778823)]
active ratio: 4.43%
BF16 weights: 156.2 GB

第二个专家的原始分数并不低，但校正偏置让第三个专家进入了本次计算。这样的偏置可以帮助系统调节专家负载，避免大量 token 长期挤向少数专家。它也说明“激活 6 个专家”不是固定切片：不同 token 的计算路径会变化。

省下的是矩阵乘法，不是整套权重

没有被选中的专家无需为当前 token 执行前向计算，这是 MoE 的主要计算优势。但推理服务不知道下一批 token 会调用谁，通常仍需让全部专家权重保持可用。

Kolibri 的两种官方权重格式把差异展示得很直观：

权重格式	权重体积约数	官方给出的最低硬件示例
FP8	78 GB	1×H200/B200/B300，或 2×A100/H100
BF16	156 GB	1×B200/B300、2×H200，或 4×A100/H100

这些是模型卡列出的最低配置，不等同于所有负载下都能获得理想吞吐。实际部署还要给 KV Cache、vLLM 运行时和并发请求留空间。尤其在长上下文场景里，权重只是一部分显存开销。

所以判断一个 MoE 模型能否部署，至少要同时看四项：总参数、权重精度、激活参数和推理框架。只报“3.46B active”，信息是不完整的。

100 万上下文，也不等于默认就该开满

Kolibri 的最大上下文长度写到 1,048,576 token，但官方模型卡同时建议：为了效率以及复杂任务的效果，优先把上下文控制在 262,144 token 以内。模型的长上下文训练先在 256K 上进行，再通过调整位置编码扩展并验证到 1M。

它还采用了混合注意力：50 层中，40 层只在 512 token 的滑动窗口里注意局部内容，每隔 5 层安排一次全局注意力，共 10 层。可以把它理解为大多数楼层只在本楼层传消息，隔几层再设置一个能看全楼的调度中心。这样能压低大部分注意力计算，但全局层和 KV Cache 的成本并不会消失。

“支持 1M”回答的是能力边界，“应该给每个请求 1M”则是成本与效果问题，两者不能画等号。

什么时候值得试，什么时候先别急

Kolibri 的定位比较明确：德语和英语任务、文档处理、RAG、工具调用，以及需要在自有基础设施上运行的代理工作流。官方推理插件适配 vLLM 0.29，并提供 OpenAI 兼容服务的启动方式。对于已经有数据中心 GPU、又在意德语能力和本地部署的团队，它值得进入评估清单。

但下面几种情况不适合仅凭参数表就做决定：

• 消费级单卡或笔记本部署。 即使只激活 3.46B，完整 FP8 权重仍约 78 GB；
• 把 1M 上下文当作常规输入。 官方推荐区间更保守，超长输入还会挤占并发空间；
• 无人复核的高风险业务。 模型卡明确提示输出可能错误或过时，应用层仍需做校验、权限控制和内容策略；
• 把厂商测试当成独立结论。 当前发布资料主要来自 Aleph Alpha，实际吞吐、工具调用稳定性和不同语言表现仍需在自己的任务上复测。

另外，Apache 2.0 覆盖 Hugging Face 仓库中的权重和配置，推理插件也采用 Apache 2.0；模型卡同时说明，权重许可不会自动延伸到背后的训练代码、架构方法或未随仓库发布的其他材料。做二次开发时，应按具体仓库核对许可范围。

用一张检查表读下一款 MoE

以后再看到“总参数很大、激活参数很小”的模型，可以按下面的顺序判断：

1. 总参数和精度决定权重文件大致有多大；
2. 每个 token 激活多少专家决定主要前向计算量，但不直接等于显存占用；
3. 路由和共享专家决定每个 token 实际经过哪些路径；
4. 局部与全局注意力的比例影响长上下文计算方式；
5. 原生训练长度与外推长度要分开看，最大值不等于推荐值；
6. 推理框架与最低硬件决定能不能真正把模型跑起来；
7. 基准是谁测的、怎么测的决定数字能否用于自己的决策。

Kolibri 的价值不只是多了一个开放权重模型。它把 MoE 时代最容易混淆的三件事摆在了一起：参数容量、单 token 计算量和实际部署成本。看清这三本账，比记住一个“78B-A3.46B”的型号更有用。

原始资料

• Aleph Alpha：Kolibri 1 发布说明
• Kolibri 1 FP8 模型卡
• Kolibri 1 BF16 模型卡
• Aleph Alpha 推理插件与 vLLM 用法
• Kolibri 路由实现（固定到本次核验的提交）