Aleph Alpha’s Kolibri: What We Know About the Open Model—and What Still Needs Verification

A promising launch, with details still to verify

Aleph Alpha presents Kolibri as an open-weight model with a particular focus on German and English, aimed at organisations that need control over where their AI systems run. The company has published a model page, an associated repository and its own technical report. These materials establish the product and its stated focus, but the information available here is not enough to confirm every specification that could determine whether the model is suitable for a particular deployment.

That distinction matters. A product page can describe how a model is positioned; a model card, files and configuration can help establish how it is distributed; and a reproducible evaluation can compare quality and costs under defined conditions. These are not interchangeable forms of evidence. In particular, describing Kolibri as “sovereign” does not, by itself, demonstrate that an organisation meets its legal obligations or that every component needed to run the model is available under the same terms.

Aleph Alpha describes Kolibri as a mixture-of-experts architecture, or MoE, and highlights its intended use for sensitive workloads. The information available does not establish that this architecture, by itself, leads to better results or lower costs in a real-world environment. That requires measurements using comparable tasks, hardware and configurations.

Parameters and context: figures attributed to the provider

Aleph Alpha describes Kolibri as an MoE model with around 78 billion parameters in total and roughly 3 billion active per token. These figures should be treated as information communicated by the company, not as independently verified results in the materials available here. More precise figures—78.1 billion total parameters and 3.46 billion active—have also been reported, but the verifiable materials at hand do not establish that level of precision. It would therefore be unwise to compare those exact figures with other models as though they had been validated against a consistent specification.

In an MoE architecture, the total number of parameters is not necessarily the number involved in processing each token. Some experts are activated for part of the input, while others are not used at that step. The active-parameter count can help estimate computation, but it does not, by itself, determine memory requirements. Those also depend on the weights that must be loaded, quantisation, input length, batch size and implementation.

The company also presents Kolibri as supporting a context of up to one million tokens. The available documentation does not establish the conditions behind that figure or the quality the model maintains near the limit. An advertised maximum context window is not a guarantee that the model will accurately retrieve all the information within it, nor does it say anything on its own about latency, cost or performance on long documents. For a practical evaluation, organisations should request the exact configuration and test their own documents and tasks.

Open weights do not automatically clarify the licence

The label “open weights” indicates that model weights are being published, but it does not automatically answer every legal and operational question. A responsible assessment should establish which licence applies to the weights, whether it covers redistribution and commercial use, and whether separate terms apply to the code, tokenisation data, inference tools or other files needed to run the model.

The available information does not confirm that Apache 2.0 covers every element required to run Kolibri. It would therefore be imprudent to state that the licence applies to the complete set of components or to assume that every intended use is authorised. The terms published alongside each specific model artefact and version should be checked, with legal advice where the use case requires it.

It is also worth defining what “open” means for a procurement or evaluation process. For some teams, being able to download the weights is enough for experimentation. Others will need clear rights to modify and redistribute them, use them in commercial products and retain specific versions. These are different requirements, and they should not be inferred from the label used in an announcement.

Hardware and deployment: do not assume a single GPU is enough

The ability to run a model on an organisation’s own infrastructure can be useful when it needs to govern access, data location or connectivity. Aleph Alpha describes platform deployment options, including on-premises and isolated deployments. That information is relevant when exploring installation architectures, but it is not a complete Kolibri specification and does not guarantee that any local configuration will meet an organisation’s requirements.

It has not been confirmed that Kolibri can run on a single B200 or H200 GPU at the quality and performance levels required, or under what quantisation, context length or batch size such a configuration would be possible. The availability of those accelerators also does not prove that a configuration is economically viable or suitable for production. Capacity planning requires reproducible instructions, measured memory consumption and tests on hardware equivalent to the intended setup.

An evaluation should cover more than whether the model can be made to load. Teams should measure latency, concurrency, cost per task, stability, behaviour with long inputs and storage requirements. They should also decide what happens if the hardware is unavailable, how the weights will be updated and what controls will record and limit access.

Sovereignty and regulation: control is not a compliance certificate

A sovereign deployment can describe greater control over where a system runs and who controls its infrastructure. Those capabilities may be valuable, but they do not automatically establish that a particular use complies with data-protection law, public-procurement rules, sector-specific obligations or internal security policies.

Compliance depends on the complete system and how it is used: the data being processed, the purpose, access controls, logging, human oversight, incident management, infrastructure provider and contractual terms, among other factors. Even when weights run on an organisation’s own servers, dependencies and data flows still need to be reviewed. And even if a platform offers an isolated deployment mode, its configuration and operation must be verified.

Aleph Alpha positions the offering for sensitive workloads and regulated sectors. That is a statement about the provider’s intended market, not an independent assessment proving suitability for every organisation or sector. The useful question is not just whether the model can be hosted locally, but what specific controls the complete solution provides and what evidence documents their effectiveness.

What is still needed for a meaningful comparison

The public information identified here does not provide enough reproducible results to compare Kolibri’s quality in German and English with that of other models. Nor does it allow a rigorous assessment of performance on long-context tasks or in regulated domains. That would require details of the evaluation sets, tested versions, inference parameters and results, as well as any limitations or failure cases.

Organisations considering the model can use its release as a starting point, not as a purchasing conclusion. First, they should define tasks and success criteria; then verify the version and terms of use; and finally run tests on representative infrastructure, with appropriate data and controls. For comparisons across providers, tasks should be held constant and configurations recorded: small differences in context, quantisation or prompts can change the result.

The cautious conclusion, based on the available evidence, is limited: Kolibri is presented as an MoE model focused on German and English and intended for sovereign deployments, and Aleph Alpha has published its own materials about the product. The more precise parameter counts, effective context, application of Apache 2.0 to every component, ability to run on a single B200 or H200, and demonstrated suitability for regulated environments still require specific verification. Keeping announced features separate from demonstrated results makes it possible to assess the product without turning the language of sovereignty into a guarantee that has not been established.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.