Kolibri, explained: Aleph Alpha's open model computes like a 3B model but needs memory like a 78B one

Aleph Alpha is a German AI company. On 3 October 2026, the Day of German Unity, it released Kolibri. Its announcement says: "On the Day of German Reunification, we are releasing our new model: Kolibri."

Kolibri is an open-weight language model. Weights are the numbers a model learned during training. Open-weight means you can download them and run the model on your own machines.

That is not the same as open source. Aleph Alpha describes its training data but does not release it, and the model card says the Apache 2.0 license covers "the weights and configuration files published in this repository" and "does not extend to underlying code, model architecture, parameter settings or any training method".

A few basic facts, all from the model card. It has 78.1 billion parameters; a parameter is one of those learned numbers. It speaks only German and English.

It was trained to read 262,144 tokens at once. A token is a piece of text the model reads or writes, often part of a word, and that limit is called the context length. Aleph Alpha says it validated up to 1,048,576 tokens, while recommending at most 262,144 for complex tasks.

Its knowledge stops at 18 June 2026, and the main training stage ran on 768 NVIDIA B200 GPUs for 21 days.

Why build it this way? A normal, dense model runs every parameter for every token. If most of what the model knows is not needed for the next word, you pay to compute things you throw away.

Kolibri is a mixture-of-experts model, usually shortened to MoE. In each of its 50 layers sit 384 small sub-networks called experts, plus one shared expert.

A small part called the router looks at each token and sends it to the 6 experts it scores highest, and the shared expert runs for every token. So each token passes through 7 experts per layer, not 385.

That is where the figure of about 3.46 billion active parameters comes from, out of 78.1 billion, or 4.4%. The tech report notes that the active count excludes the embeddings, the table that turns tokens into numbers.

The catch is memory. The router can pick any expert for the next token, so every expert has to be loaded and ready. Think of a hospital with 384 specialists on call: each patient sees only six, but all 384 must be in the building.

This is the point most people get wrong about MoE models, and it decides where Kolibri can run. Compute per token behaves like a 3.46B model. Memory behaves like a 78.1B model.

Data residency comes first. Data residency means rules about which country or building your data may be stored and processed in. A bank, a hospital or a government office often cannot send documents to a foreign API. With open weights, the model runs on your own GPUs and the text never leaves.

Then cost. With an API you pay per token. On your own GPUs you pay for the machines whether they are busy or not, so the number to work out is your cost per million tokens: what the GPUs cost per hour, divided by the tokens they produce per hour, times one million.

MoE helps here once the memory is paid for: only 3.46 billion parameters work per token, so one server can produce a lot of tokens across many users at once. It does not help a single user on a small machine, because the memory bill is the same either way.

Long documents get cheaper too. In 40 of Kolibri's 50 layers, attention only looks back over the previous 512 tokens, and every fifth layer, 10 in all, can see the whole document. So the KV cache grows on 10 layers instead of 50.

Then the license and the hardware. Apache 2.0 lets you use, change and sell products built on the weights as long as you keep the license notice, but the card limits it to the weights and config files, so have a lawyer read it before you build a product on it. On hardware, plan for at least one H200, B200 or B300, or two 80 GB A100s or H100s, for the FP8 version, plus memory for the KV cache.

Look elsewhere if you have only one consumer GPU or a laptop, if you need many languages, if you want answers from the model's own memory without retrieval (its closed-book scores are its weakest), or if your main job is agentic coding on real repositories.

If you want to read these numbers yourself before picking a model, our lesson "Reading a Model Name: What 27B, FP8, A3B and Instruct Actually Mean" explains total versus active parameters and what each precision costs in memory, and "LLM Inference Optimization: Serving More Tokens Per GPU" covers the KV cache and batching that decide your cost per token.