先看证据
把机制串起来
MoE把模型参数拆成许多“专家”，每个词只激活少数几个专家，因此总参数可以很大，但单词计算量较低。注意力则负责让词互相读取信息；全注意力能看完整上下文，但缓存和计算会随上下文长度快速增长，滑动窗口注意力只看附近词，成本更稳定。混合注意力就是把两者交替组合，在保留远距离信息通道的同时控制长上下文开销。
每个MoE层用sigmoid路由器给384个路由专家打分，每个token选择Top 6，并额外始终经过1个共享专家；因此容量很大，但单token只执行少量专家。Exact Quantile Balancing与Load-Error Injection用于避免热门专家拥堵，否则稀疏计算会被最慢或最满的专家拖住。50个Transformer块中，每第五层使用无位置编码的全注意力，其余40层只读取前512个token并使用RoPE；全注意力层提供跨窗口的信息交换，滑窗层控制局部计算
['单张B200/B300/H200可部署FP8；也支持2张H100 SXM5', '用vLLM并启用Kolibri专用推理与工具调用解析器', '适合英德长文档、政企内网和受监管场景', '不宜据材料直接视为通用能力SOTA或低延迟保证']
它解决的不是参数规模，而是部署账单
Aleph Alpha发布的Kolibri（Kolibri-1）是一款面向英语和德语的开放权重混合专家语言模型，目标用户包括公共管理、工业和航空航天等受监管行业。模型总参数为78.1B，但每个token只激活3.46B参数，约占总量的4.4%；它提供最长1,048,576个token的上下文，并允许调用方按请求设置推理力度。权重采用Apache 2.0许可，FP8检查点约78GB，可在单张B200、B300或H200上运行，也可以使用两张H100 SXM5，通过vLLM和专用的推理、工具调用解析器提供服务。
这组规格改变了比较模型的方式。传统上，参数规模往往同时暗示显存需求、计算成本和能力上限，但MoE模型把“存下多少参数”和“每个token实际计算多少参数”拆开了。Kolibri保留了一个大模型的专家容量，却试图让单次生成接近3.46B活跃参数的计算负担。对主权部署团队来说，关键问题因此不再只是能否训练或调用一个更大的模型，而是能否把它放进已有的GPU采购、数据边界和服务运维体系。
稀疏专家让容量与计算解耦
Kolibri的稀疏性不是简单地随机跳过网络层。模型共有50个Transformer block，每个MoE层会为输入token评估384个路由专家，选择其中6个，同时始终启用1个共享专家。路由器使用sigmoid机制，专家负载则通过Exact Quantile Balancing和Load-Error Injection进行平衡。这样做的目标，是让不同token获得更有针对性的参数子集，同时避免少数专家过载、其他专家闲置。
这种结构带来的收益和代价是绑定在一起的。收益是每个token的有效计算量下降，且模型仍保留较大的专家总容量。代价则是服务系统必须处理路由、专家调度和负载均衡，实际吞吐不能只用“3.46B活跃参数”推算。不同请求的token分布会触发不同专家组合，批处理和并行策略也会影响结果。因此，Kolibri更像一个需要配套运行时的系统，而不是把一个78.1B稠密模型简单压缩后的权重文件。
这也是为什么发布材料特别强调vLLM支持和专用解析器。对希望自建服务的团队而言，模型文件能加载只是部署的起点，专家路由的通信、KV缓存、推理模式和工具调用协议都必须进入压测范围。开放权重降低了模型访问门槛，却没有把系统工程从模型之外抹掉。
百万上下文靠的是注意力分层
Kolibri的长上下文设计并不是让每一层都对一百万个token做完整注意力。模型使用48个查询头和4个KV头的分组查询注意力，其中每第五个block使用不带位置编码的全注意力，另外40个block使用带RoPE的滑动窗口，只关注前方512个token。滑动窗口层的KV缓存保持固定大小，只有10个全注意力层会随上下文长度增长。
这个架构把长上下文成本限制在一部分网络层中。发布材料称，在匹配计算量的条件下，这种混合结构支持的序列长度可以达到全注意力模型的4倍。它解释了Kolibri为什么能够把一百万token作为接口能力，并让超长文档、长期会话或大规模检索结果进入同一个上下文窗口。
但“能接受一百万token”和“能可靠利用一百万token”不是同一个命题。材料给出了缓存增长和序列长度的架构解释，却没有提供独立的长上下文质量验证。技术负责人需要把上下文窗口视为资源上限，而不是自动获得的检索、记忆或推理能力，尤其要验证关键信息位于不同位置时的召回和引用稳定性。
德语优化把tokenizer变成产品决策
Kolibri的语言取舍也落实在tokenizer，而不只是训练数据声明。它使用128,000词表和UniBPE：合并过程类似BPE，但用Unigram loss为候选合并评分。在德语网页文本上，Kolibri达到每token 4.90 bytes，而GPT-5 tokenizer为4.35 bytes，材料将其解释为token数量减少11.2%；在英语上，Kolibri为4.58 bytes，GPT-5为4.67 bytes。交互说明还称，Kolibri在德语中有65%的token边界落在词素边界上，GPT-5 tokenizer为47%。
这些数字体现的是具体的工程目标：德语复杂形态结构不应被低效切分，否则同一份文档会消耗更多token，也会抬高长上下文和推理成本。Aleph Alpha在训练中加入了超过2T个经过整理或合成的德语token，预训练覆盖20T token，随后进行3.44T token的中期训练，并用201B token完成长上下文阶段。训练使用768张NVIDIA B200，长上下文阶段的序列长度达到262,144。
但语言效率并不等于语言能力的完整证明。更少的token可能改善成本和上下文容量，却不能单独说明专业术语、方言、跨语言检索或德英混合输入的质量。对于欧洲本地化部署，评估集应按业务语言和文档形态建立，而不能只看一个平均token化指标。
主权部署的价值要用验证成本来换
Kolibri的训练和治理叙事与部署目标是一致的。Aleph Alpha表示，德国团队端到端控制了数据、架构、训练基础设施、后训练和评估，训练基础设施位于德国和芬兰。数据管线会在训练前删除个人数据，设计目标对齐EU General-Purpose AI Code of Practice、EU AI Act和GDPR，公司也是该守则的签署方。后训练结合了监督微调、MergeMix和基于超过120万个内部任务的强化学习，Merlin-Arthur协议则训练模型在检索上下文不足以支持答案时拒答。
这使Kolibri适合被看作受监管场景的候选基础模型，而不是一份“合规即插即用”的保证。Apache 2.0和单卡级别的FP8部署有助于组织保留数据和服务控制权，但合规部署仍涉及数据治理、日志、访问控制、工具调用边界和领域评估。尤其是按请求设定推理力度，意味着团队可以在延迟、成本和答案质量之间做业务分层，但也需要明确哪些任务允许低推理，哪些任务必须提高预算或触发人工复核。
因此，采用判断应当非常具体：如果团队主要处理英语和德语、需要本地运行、希望拥有开放权重，并且有能力验证MoE运行时和长上下文质量，Kolibri值得进入候选清单。若业务依赖多语言覆盖、需要独立的安全与性能基准，或无法承担专家路由和工具调用的系统集成，那么“单卡可部署”不足以构成采购理由。