Aleph Alpha Kolibri 已开放权重，但德国尚未选定其公共部门 AI

Aleph Alpha 于 10 月 3 日发布 Kolibri，提供开放权重、781 亿参数，定位直接瞄准受监管机构。Aleph Alpha Kolibri 的发布，为德国机构带来了一款可在本地部署的模型，围绕德语、文档依据支撑和基础设施控制而构建。

这场竞争并不只是德国与美国 AI 公司之间的对垒，而是开放权重、自托管部署与托管式专有服务之间的取舍：后者承诺更快落地，却让机构对底层模型的控制权更少。

这一差别也澄清了一个常见误解。德国政府并未发布 Kolibri，也没有将其选定为国家级公共部门模型。Aleph Alpha 是一家德国私营公司，它面向包括公共行政机构、工业企业和航空航天运营商在内的组织发布了该模型。

这一时机之所以重要，是因为德国已经在建设多条政府 AI 路径。联邦机构正在测试共享平台、开源组件、专项评估和主权云服务。SAP 与 OpenAI 则正分别筹备面向德国公共机构的托管服务。

因此，Kolibri 是一名竞争者，而非胜出者。其开放权重和部署灵活性为公共采购方增加了一个选项，但是否采用仍将取决于独立评估、集成工作和采购决策。

Aleph Alpha Kolibri 带来了哪些变化

Kolibri 将 Aleph Alpha 的主权论述转化为一款可下载的模型，机构可依据 Apache 2.0 许可检查、托管并适配它。

Aleph Alpha 将 Kolibri 描述为一款英德混合专家模型 Transformer。混合专家模型会让每项输入经过选定的内部组件，而不是为每个 token 激活全部参数。

该公司表示，该模型共包含 781 亿个参数。每个处理的 token 约激活 34.6 亿个参数，从而降低一次性使用全部模型参数所需的计算需求。

其权重可通过公司的模型仓库以 BF16 格式获取。Aleph Alpha 还发布了 FP8 版本，该版本采用较低数值精度，以降低推理过程中的内存需求。

Apache 2.0 许可允许广泛的商业使用、修改和再分发。这使 Kolibri 比仅提供 API 的模型更易获得，后者的行为、托管环境和未来可用性始终由单一提供方控制。

不过，开放权重并不总是意味着完全开源。模型权重允许组织运行并修改已经训练完成的系统，而完整可复现性还需要训练代码、数据细节、评估方法和足够的计算资源。

Aleph Alpha 已披露有关 Kolibri 架构和训练的大量技术信息。但下载权重并不能让外部团队重建每一项训练决策，也无法独立验证每个数据来源。

这一细微差别在政府采购中很重要。一个机构可以获得模型的运营控制权，却未必能完整了解每项能力或失效模式是如何形成的。

Kolibri 支持最高 1,048,576 个 token 的上下文窗口。上下文窗口是模型在一次交互中能够考虑的材料数量，包括指令、文档和先前消息。

该模型先以较短长度训练，随后进行长上下文适配。Aleph Alpha 表示，其主要预训练阶段使用了 16,384 个 token 的序列，之后又进行了 65,536 和 262,144 个 token 的训练阶段。

一百万 token 的界面上限，并不保证模型能在一百万 token 范围内保持可靠推理。当相关证据埋没在重复、冲突或结构松散的材料中时，长上下文准确性可能会下降。

不过，这一能力瞄准了一个明确的公共部门问题。政府工作常涉及冗长的案卷、法规、通信记录、会议纪要和佐证材料，而这些内容难以舒适地纳入较小的上下文范围。

Kolibri 还支持工具调用和多种推理强度设置。这些功能可帮助模型与受控数据库或软件系统交互，前提是外围应用会验证权限和输出结果。

此次发布比泛泛而谈欧洲 AI 主权更具实质性。机构如今可以下载一款明确的模型，使用本地文档测试它，并将其部署要求与托管式替代方案进行比较。

这才是真正的变化。Aleph Alpha 将其长期以来关于欧洲机构需要更大 AI 基础设施控制权的主张，落实为一项技术规格明确的产品。

Kolibri 为何瞄准德国公共部门工作

Aleph Alpha 围绕这样一种主张打造 Kolibri：德国机构需要的不只是套上本地托管外壳、以英语为先的模型。

该公司表示，德语占主要预训练语料混合的 21.3%。这相当于在 20 万亿 token 的预训练阶段中，约有 4.3 万亿个德语 token。

英语约占 62%，代码约占 14%。Aleph Alpha 表示，德语和英语的知识截止日期均为 2026 年 6 月 18 日。

该公司并非通过大规模翻译英文网络内容来实现其德语目标。它表示，翻译内容只占其更广泛数据工作的一小部分。

相反，Aleph Alpha 为德语网络材料开发了筛选器，并基于德语源文档生成新的德语表述。该公司认为，面向英语的筛选器可能会错误剔除德国行政写作中常见的较长单词和句子结构。

这种方法处理的不只是词汇问题。政府文件包含法律引用、机构角色、程序性语言和文化假设，直译可能会扭曲这些内容。

Aleph Alpha 还训练了一套双语 tokenizer。tokenizer 会将文本切分成模型处理的单元，从而影响模型处理复合词和专业术语的效率。

该公司表示，其 tokenizer 将德语复合词切分为比数个竞争性 tokenizer 更有意义的片段。若这一发现能在真实工作负载中成立，机构便可用更少的 token 和更低的推理成本处理德语文件。

这些说法仍需独立测试。token 压缩虽有价值，却不能证明法律准确性、事实可靠性，或模型区分相似行政程序的能力。

Aleph Alpha 最具相关性的行为主张涉及依据支撑。依据支撑要求模型以提供的证据为基础作答，而非仅依赖训练中习得的模式。

Kolibri 的训练包含了“拒绝回答才是正确选择”的示例。该公司的 Merlin-Arthur 方法会构造对抗性文档对，其中包括已移除回答所需证据的版本。

当支持信息存在时，模型必须回答；当信息缺失时，模型必须弃答。Aleph Alpha 表示，这有助于解决模型训练中的一个常见激励问题：猜测的得分可能高于承认不确定性。

这种行为在福利部门、监管机构或法务部门中会很重要。当员工使用 AI 汇总证据或起草正式函件时，缺乏依据的回答可能比没有回答更危险。

该公司报告称，在一项内部评估中，Kolibri 有 44% 的项目会选择弃答而非错误作答。较早的 Kolibri Origin 模型据称这一比例为 15%。

这些数字来自 Aleph Alpha 自身的测试。在独立评估者使用具有代表性的政府任务复现结果之前，它们应被视为产品主张。

这一区别尤为重要，因为 Aleph Alpha 还创建了多个客户代理基准。在其德国公共部门代理基准上，该公司报告 Kolibri Origin 的得分从 0.54 提升至 Kolibri 的 0.75。

客户代理基准在不暴露机密客户数据的情况下模拟目标工作负载。它可以指导模型开发，但采购方若看不到任务构成和评分规则，便无法充分评估其相关性。

德国正在为这一评估问题发展一条更独立的路径。Bundesdruckerei 的MÖVE benchmark使用德国行政文件、法律文本、安全考量、可持续性和民主价值观评估语言模型。

其研究始于九个德语测试数据集和七项评估标准。该项目还正与德国联邦信息安全办公室及 Fraunhofer AISEC 共同开发安全评估。

这项工作表明，以德国为重点的训练语料配比只是开端。公共采购方还需要有关幻觉、信息泄露、能源消耗、政治语境，以及特定工作流表现的证据。

Aleph Alpha Kolibri 挑战托管云路线

核心竞争在于机构控制权与运营便利性之间的平衡，而不是一款德国模型与一个美国聊天机器人的对抗。

自托管的 Kolibri 部署可将提示词、检索到的文件和生成输出保留在客户选择的基础设施内。它也可以减少对远程推理提供商的依赖。

当机构处理人事记录、法律文件、安全敏感材料或尚未公开的政策文件时，这一选项尤为重要。将此类内容发送至外部服务，可能引入合同、司法管辖和运营层面的问题。

本地部署还允许组织控制模型更新。一个部门可以评估某个版本、记录其行为，并决定何时替换它。

API 客户通常对这一生命周期的控制更少。提供商可以改变模型行为、淘汰版本、调整使用政策或修改技术限制。

但托管服务确实解决了实际问题。它们提供维护完善的基础设施、用户管理、监控、支持和容量，无需每个公共机构都组建专门的机器学习运维团队。

德国正在与开放模型并行推进这一路线。SAP 和 OpenAI 宣布推出OpenAI for Germany，这是一项面向政府、行政机构和研究机构的主权服务。

该服务采用围绕德国要求设计的本地合作伙伴和基础设施安排。它提供了另一种主权定义：以合同控制、境内运营和托管服务为核心。

Kolibri 对控制权的定义更为直接。客户可以下载模型并选择其运行地点，从而减少对单一托管推理端点的依赖。

两种模式都无法消除外部依赖。自托管仍需要芯片、系统软件、安全更新、熟练的运维人员，以及与政府身份系统的可靠集成。

Aleph Alpha 使用 768 块 Nvidia B200 GPU 训练 Kolibri。该公司表示，主要预训练运行持续了 21 天，期间遭遇了 38 次计划外中断。

据报道，训练流水线在无需人工干预的情况下从这些中断中恢复。但这一工程成果并不能说明一个小型市政机构能否高效运行训练完成后的模型。

推理所需资源远低于训练，但并非毫无成本。机构必须针对预期流量、长提示词、并发量和响应时间要求配置硬件。

Kolibri 的稀疏架构旨在改善这一成本结构。每个 token 仅激活部分参数，使大型模型能够以低于同等规模稠密模型的计算成本运行。

Aleph Alpha 表示，Kolibri 可在两张 H100 GPU 上处理 18 个并发请求，每个请求的上下文长度为 256,000 个 token。其规模更大的、拥有 1,230 亿参数的实验性设计，据报道在相同测试条件下只能处理三个请求。

这是公司自行开展的测试，并非采购保证。生产环境中的性能取决于量化、批处理、软件配置、提示词长度、输出长度和服务等级要求。

公共机构所需的不只是推理能力。它们还需要文档连接器、访问控制、日志记录、检索系统、人工审核、档案管理，以及处理错误输出的流程。

德国联邦 AI 平台体现了这一更广泛的技术栈。数字部表示，KIPITZ 服务已支持文档摘要、翻译、起草、改写和对话式交互。

KIPITZ 被规划为一个云无关平台。该部门表示，面向特定应用的开源语言模型有助于避免供应商锁定，并支持数字主权。

Kolibri 可能契合这一架构方向，但尚无公开声明证实其已被选用于 KIPITZ。与政策目标兼容，并不能证明已作出采购决定。

这正是标题所述主张需要保持克制的地方。Aleph Alpha 已发布一款面向公共部门使用的模型，而德国仍在评估多条技术和商业路径。

开放权重并不能解决信任问题

Kolibri 让机构对部署拥有更多控制权，但控制权并不会自动带来准确性、安全性或问责性。

Kolibri 最有力的优势在于可检查性与本地运行的结合。机构可以保留一个模型版本、在私有环境中测试，并将敏感检索数据保留在自己选择的环境中。

最有力的反对意见则是，这些自由将更多责任转移给部署机构。必须有人负责保护服务栈、配置访问权限、监控输出并调查故障。

政府部署还面临对可靠性的严格定义。一个在数学和代码任务上表现良好的模型，仍可能误读法定例外条款，或混淆联邦与州级机构之间的职责。

独立的公共部门研究进一步印证了这一警告。一项 2026 年的德国评估研究考察了来自 13 家提供商的 39 个开放权重模型和专有模型。

研究人员发现，没有任何单一模型在所有治理维度上领先。估算的能耗相差超过 60 倍，提供商透明度也存在显著差异。

欧洲来源并不保证模型更了解德国政治立场。表现最好的两款模型，在涵盖 64 个政党、4,788 个立场的测试中，准确率仅达到 0.671。

这些结果并未直接评估 Kolibri。它们说明，来源和营销标签不能替代针对具体任务的证据。

Aleph Alpha 表示，其构建 Kolibri 时考虑了欧盟 AI 法案、《通用 AI 行为准则》和 GDPR。这一表述描述的是设计意图，而非针对每种部署的全面认证。

法律义务取决于机构如何使用模型。起草助手、内部搜索工具、自动资格认定系统和面向公民的代理，可能承担截然不同的风险。

欧盟 AI 法案根据系统的角色及其潜在危害进行监管。一个合规的基础模型，并不会自动使围绕它构建的每个应用都合规。

机构还必须审查训练数据记录。Aleph Alpha 表示，其在过滤训练数据前处理了超过 200 万亿个原始 token。

其最终阶段包括 20 万亿个预训练 token、3.44 万亿个中期训练 token，以及约 2,000 亿个用于长上下文适配的 token。该公司称，总量接近 24 万亿个 token。

这一规模支持广泛的语言能力，但也使审计更加复杂。买方需要关于数据来源、版权保障、个人信息、过滤机制和已知缺口的清晰文档。

Apache 2.0 许可证适用于已发布的软件工件。它并未解答有关训练材料、下游数据保护或特定政府工作流合法性的所有问题。

对推理轨迹也需要保持同样谨慎。Aleph Alpha 表示，Kolibri 可以展示其得出答案的过程，但生成的推理文本未必是内部计算过程的忠实记录。

一段易读的解释仍可能为错误结论进行合理化包装。公共部门人员必须核查底层文件，不能将措辞流畅的轨迹视为证据。

长上下文还带来另一种风险。将整份案件档案放入单个提示词中，可能暴露无关的个人信息，也会使访问控制更难执行。

更安全的应用方式可能是仅为每位用户和每次请求检索获得授权的段落。这种设计需要受治理的AI 知识库、具备权限感知能力的检索机制，以及可追溯的引用。

Kolibri 的弃答训练直接针对无依据的回答，但外部测试必须衡量这种权衡的两面。过度拒答可能让系统更安全，却也失去实际效用。

评估人员应记录正确回答、无依据回答、有充分理由的拒答、不必要的拒答以及引用准确性。单一平均分数可能掩盖代价高昂的失败模式。

安全团队还必须测试提示词注入、数据提取、工具滥用和恶意文档。开放权重允许更深入的检查，但也让攻击者能够研究同一个模型。

实际问题并不是 Kolibri 在抽象意义上是否可信，而是一个有文档记录的 Kolibri 部署能否在某一明确流程和风险阈值内可靠运行。

德国的主权 AI 战略包含多个相互竞争的层次

Kolibri 进入的是一个公共部门市场：主权正通过模型、云基础设施、共享平台、标准和采购规则来实现。

德国政府体系并不是一个单一的技术买方。联邦各部委、各州、市政机构、公共企业和专业机构拥有不同的系统与法律责任。

适用于联邦文档平台的模型，未必适合市政公民服务。硬件能力、人员配置、采购周期和安全等级也各不相同。

这种碎片化为可复用的开放权重模型创造了机会。一个基础模型可以适配多个机构，而不要求每个组织都将数据交给同一家提供商。

它也会带来集成成本。除非共享标准让其保持一致，否则每次部署都可能形成不同的提示词、安全控制、文档索引和评估方法。

德国已经超越了孤立的聊天机器人实验。联邦政府正在开发 AI 平台、发布可复用模块，并在行政流程中测试代理系统。

其 Agentic AI Hub 已支持涉及规划、许可、会议转录和公共服务的试点项目。代理式系统能够调用工具并完成多步骤任务，因而同时提高了其价值与运营风险。

Kolibri 的工具调用能力使其适合这一环境。但它本身并不提供完整的代理系统、工作流权限或公共服务界面。

该模型还面临其他欧洲和开放权重替代方案的竞争。Mistral 模型具备欧洲背景和广泛的开发者采用度，而 OpenEuroLLM 正通过一个欧洲联盟开发多语言模型。

德国机构还可以评估来自 Meta、阿里巴巴 Qwen 团队、Nvidia 和其他提供商的模型。开放权重使切换成为可能，但迁移仍需要兼容性测试和应用改造。

Aleph Alpha 的优势在于专业化。它强调德国数据、受监管行业、本地基础设施、文档锚定以及对受控部署的支持。

其劣势则在于，必须在公司基准测试之外证明这些优势。规模更大的国际模型社区能够产出更多第三方评估、集成方案、优化成果和故障排查知识。

该模型的公开发布有助于缩小这一差距。研究人员和政府实验室现在可以测试相同的权重，而不必评估一项可能在不同运行之间发生变化的私有服务。

开放可用性也使批判性审查更加容易。独立团队可以检查偏见、拒答行为、安全弱点、德国法律知识和硬件要求。

这一过程可能会发现问题。这类发现并不意味着发布失败，但会为买方提供封闭产品评估可能永远无法揭示的证据。

这正是 Aleph Alpha Kolibri 在大规模采用之前的政策价值。它为德国提供了一个能够参与透明比较的本土模型，而不是完全依赖供应商演示。

主权 AI 仍将涉及外国组件。Kolibri 在 Nvidia 硬件上训练，而大多数部署栈依赖国际开发的芯片和软件。

因此，主权不可能意味着彻底的技术孤立。更实际的定义是：能够检查、运行、替换和治理关键组件，而不会由单一外国提供商控制每一层。

Kolibri 在模型层面强化了这一选择。德国仍需要兼容的基础设施、评估标准、专业人员和采购机制，才能将这一选择转化为可用的公共服务。

Kolibri 发布后值得关注的事项

接下来的证据应来自独立基准测试、具名部署和运行数据，而不是新一轮主权宣称。

第一个信号是 Kolibri 出现在 MÖVE 或可比的德国公共部门评估中。独立结果应测试法律语言、行政摘要、文档锚定、安全性、能耗和民主价值观。

强劲结果将支持 Aleph Alpha 的主张，即以德国为先的训练能够带来有意义的机构优势。较弱或好坏参半的结果，则会缩小该模型可信的使用场景。

第二个信号是具名的生产部署。试点固然重要，但生产系统必须在既定控制措施下，为真实员工、真实文件和可衡量工作负载提供服务。

最有价值的披露将说明工作流和人工审核流程，同时报告响应质量、拒答率、延迟、基础设施需求和运营责任。

成功的部署将表明，开放权重可以超越实验室访问阶段。反复试点却没有生产采用，则意味着集成或采购障碍仍未解决。

第三个信号是德国的托管式与自托管路径如何共存。SAP 和 OpenAI 将提供一条路径，而联邦平台和 Kolibri 等模型则支持另一条。

公共采购方未必会只选择一条路径。他们可能会将托管模型用于低风险的生产力任务，同时把本地可控模型用于敏感文档工作流。

这种混合结果会削弱任何简单的“国家冠军”叙事，却会强化一个更广泛的观点：公共机构需要可移植性，以及针对具体任务选择模型的能力。

读者也应关注模型仓库本身。社区优化、安全报告、部署方案和第三方评测，将揭示 Kolibri 周围是否会形成活跃的技术生态。

Aleph Alpha Kolibri 已是一项值得关注的发布，因为它将“主权”从政策口号转化为可下载的产物。然而，可下载的模型并不等于公共部门战略。

决定性问题在于，机构能否将这一产物转化为始终准确、安全、可负担且可问责的服务。请关注独立测试和具名部署案例，然后思考：哪条路径能让公共部门工作人员获得可验证的控制权，而不会造成他们难以长期承担的运营负担。