Kolibri：激活参数之外的部署账本

10 月 3 日，Aleph Alpha 发布面向德语和英语的开放权重混合专家模型 Kolibri，采用 Apache 2.0 许可。模型卡列出 78B 总参数与每个 token 激活 3.46B 参数。这两个数字描述同一模型的不同部分；较小的数字不意味着下载或部署的模型只有 3.46B。 [1] [2]

公开 Reddit 讨论里，有人询问个人设备能否运行，也有人关心百万 token 上下文。它们指向一个有用的采购问题：宣传数字究竟描述哪一种资源？我们的判断是，部署需要分别考虑逐 token 计算、权重驻留和请求状态三份预算，不能用其中一项代替另外两项。

FP8 模型卡标注约 78 GB 的权重占用，另行发布的 BF16 版本标注约 156 GB。这是发布方对权重的估计，不是“内存刚好这么大就能服务目标业务”的承诺。精度改变存储预算，稀疏性则关乎每个 token 选中哪些计算。 [2] [3]

模型卡明确说明，即使每次只激活部分参数，整个模型仍需保存在内存中。一个 token 没用到的专家，下一个可能用到。因此容量规划还要留出请求缓存、运行缓冲和运行余量；不能按激活比例把总参数折算成所需内存。 [2]

卸载部分权重或进一步量化，可能带来其他部署选择，但可设想的方案不等于已测试的配置。数据搬运、精度变化和不同计算内核，都可能影响延迟或质量。消费级设备方案应当作为有独立验收条件的实验，不能从激活参数量推导出兼容保证。

Kolibri 模型卡区分了 262,144 token 的原生训练长度与扩展验证到 1,048,576 token 的能力。对于复杂任务，以及对延迟和吞吐敏感的服务，它建议不超过 262,144。技术报告的长上下文部分也说明，超过训练长度后的退化与任务有关。扩展上限、使用建议与业务证据应当一起看。 [2] [4]

假设团队要让多人同时查询长文档。能接收一个超长请求，不能证明服务器能同时处理多少个这样的请求。请求状态争用内存，输入处理争用计算。应拿真实文档测首个答案等待、完成耗时与同时到来的需求，不能把最大上下文直接变成服务承诺。

这并不降低长上下文的价值。把相关证据放在一起，可能减少信息切碎后的损失。问题是，多保留的材料是否足够改善任务，值得其资源开销。可以比较精简的相关输入与完整文档，并检查答案及支撑它的原文段落是否正确。

Aleph Alpha 的报告在一台八张 B200 的节点上，用合成提示测试服务吞吐，搜索可用的并行布局，在接近 KV 缓存并发容量的条件下测量，并报告测得最快的解码布局。它还按各 tokenizer 的每 token 字节数估计文本吞吐。这些条件是理解质量与成本比较的必要背景。 [4]

高并发解码吞吐，对繁忙服务或大量生成任务有参考价值，却不能直接回答单个用户查询文档需要多久。输入处理、排队、推理长度与结果检查，都影响实际体验。报告也注明，其比较假设 FP8 服务保留基线模型的评测分数；不能把这个假设当成所有精度都等效的结论。 [4]

反过来，权重占用较大也不能证明经济性差。有足够合适的任务持续运行时，稀疏模型可能高效利用已驻留的容量。应该比较预期负载下每单位成本完成了多少合格任务，并计入低负载时段，不能只凭某一个参数数字宣布胜负。

公开推理仓库提供 vLLM 插件，包含 Kolibri 专用架构、推理及工具调用解析器。README 在此次核验时说明，每个版本支持一个 vLLM 次版本，当前为 0.29。开放权重让团队拿到模型，却不能证明任意推理应用或已安装版本都能直接运行它。 [5]

把模型修订、精度、插件与运行时版本、上下文边界、解析器设置记在一起，再测试推理与最终正文的分离、工具参数解析、长输入处理和请求中断。客户端能接受响应格式，只是集成成功的一部分。这份规格也能让后续升级和回退更容易判断。

对德语或英语文档团队，应先挑有代表性的请求，独立对照材料核验答案；对开发团队，应带上真实工具结构和应用必须处理的输出；对基础设施负责人，应比较业务高峰与空闲期。双语定位是评测相关语言任务的理由，不是它在两种语言的所有任务都更强的证明。

小规模试验先回答三个问题：结果质量是否过线，目标机器能否持续支撑所需负载，团队能否维护这套推理软件。比较其他方案时，应使用相同文档、输出要求与验收规则，并把重试和被拒收的结果计入成本。

Kolibri 的价值，在于公开材料让团队可以检查这些取舍。3.46B 激活量描述了稀疏计算，较大的权重与请求状态仍是实际部署负担。这次变化带来一个可以围绕明确任务测试的新选项，并没有证明内存约束、运行维护或独立结果检查已经消失。