Kolibri 1 is a 78B model—not a 3B download

Aleph Alpha released Kolibri 1’s open weights on October 3, 2026: the model has 78.1 billion parameters in total, though it activates about 3.46 billion per token. That active count describes the work done for a token, not a 3B-parameter checkpoint you can download instead of the rest. For the published BF16 version—a 16-bit format for storing the weights— its model card puts the weight memory footprint at roughly 156 GB before KV cache and other serving overhead.

Those numbers make Kolibri interesting for a specific sort of deployment, not a laptop-scale release. The same model card calls 262,144 tokens its native trained context and says Aleph Alpha has validated an extension to 1,048,576 tokens. If you are deciding whether to host it yourself, the two useful questions are therefore not “Is this a 3B model?” and “Does it say 1M?” They are: Where will the full weights live, and what work will you ask the model to do beyond its trained length?

Why 3.46B active parameters still means 78.1B weights

Imagine a team evaluating an English-and-German assistant on its own infrastructure. The team sees “3B active” in the release announcement and starts with the GPU budget it would set aside for a small dense model. That would be the wrong procurement question. This is a hypothetical selection mistake, not a deployment we observed.

Kolibri 1 is a mixture-of-experts model. Instead of running every specialized expert on each token, it routes work to a subset. The BF16 model card gives the exact counts: 78,103,074,560 parameters total, and 3,457,573,120 active per token. The published config lists 50 layers, 384 experts and six routed experts selected per token; the card describes a shared expert as well. The activation figure is a measure of the per-token compute path, not an inventory of what the serving machine has to hold.

Think of the routing as choosing which part of an available collection to use for this token. Not every expert does the work every time, but that does not erase the experts the next token might need. The distinction is useful without pretending compute translates directly into a published tokens-per-second figure. The weights remain a large deployment object. Downloadability means the full published weights are available; it does not mean a “3B download” exists for this BF16 model.

Aleph Alpha positions that trade-off as lower serving compute while retaining greater model capacity. In its announcement, it compares Kolibri with its earlier Kolibri Origin and other models. The announcement’s comparison table marks Kolibri Origin as having no public release; Origin is a development comparator, not a second newly downloadable model. The design story here is real enough to examine, but an architecture diagram cannot tell a buyer their actual latency or bill.

The BF16 weights need about 156 GB before KV cache

The BF16 card’s hardware requirements specify approximately 156 GB of model memory for the weights. That is consistent with the rough arithmetic of 78.1 billion weights at two bytes each in BF16. It is a precision-specific weight figure, not a measured end-to-end process memory reading and not a claim about another format. Loading, routing, runtime buffers and the KV cache—the stored attention information used while processing live requests—must be budgeted separately. Longer contexts and concurrency make the KV-cache question especially important; the weight figure by itself cannot tell you how many simultaneous users fit.

The publisher lists these as minimum configurations, not a guarantee that each yields the same speed: four A100 80 GB cards, four H100 SXM5 cards, two H200 cards, one B200, or one B300. Its recommended list is four H100 SXM5, two H200, two B200, or one B300. The named GPU variants and capacities matter. Do not turn a list of supported configurations into “any four GPUs” or infer that all of them offer interchangeable throughput. A host still has to check the server stack, memory headroom, intended context lengths and concurrent workload.

This is why 3.46B active does not imply a commodity single-GPU installation. The attention and expert choices aim to reduce computation after you have a place for the complete BF16 model. A different precision or a separately published quantized artifact would require its own memory and quality assessment; the 156 GB in this article belongs to the BF16 repository, not to every future Kolibri variant. We have not loaded these weights or independently tested any of the GPU combinations.

There is a meaningful upside to open weights for a team with the hardware: it can evaluate a deployment on infrastructure it controls rather than treating the provider’s hosted endpoint as its only option. But “can run on our servers” is not the same as “cheap to serve,” and neither statement tells you whether the assistant meets a particular team’s latency, safety or regulatory threshold.

Kolibri 1 was trained to 256K; 1M is a validated extension

Context-length headlines often compress three distinct things: the sequences used in training, the serving configuration and the quality observed when a much longer input arrives. Kolibri’s model card lays out the sequence: 16,384 tokens in pre-training, 65,536 in mid-training and 262,144 in its final long-context training stage. It calls 262,144 the native length. The BF16 config agrees, setting max_position_embeddings to 262144.

The card then says Aleph Alpha validated quality and serving efficiency up to 1,048,576 tokens by extending beyond that trained length. This is a vendor-reported validation, not our million-token test. It is still more concrete than an unexplained “1M context” badge, but it must not be rewritten as “trained on 1M tokens.” For latency- or throughput-sensitive deployments and complex tasks, the publisher itself recommends at most 262,144 tokens.

Part of the mechanism is selective attention. The announcement’s architecture section says ten of the 50 layers attend across the full context and 40 use a much narrower sliding window. The model card attributes its extension behavior to how positional encoding is applied in those local-attention layers. This design helps explain the claimed serving behavior; it does not make a million-token request free, nor does it mean a model necessarily retrieves and reasons equally well across every document placed inside that window.

Serving beyond 262,144 requires an explicit configuration change. The publisher gives both flags, not just a new advertised maximum:

--max-model-len 1048576 --hf-overrides '{"max_position_embeddings": 1048576}'

That line is an addition to the server command, not a tested instruction to turn on 1M for every workload. A team processing lengthy document sets should start with a task-specific evaluation near its actual input sizes: answer correctness, evidence retention, elapsed time and memory at expected concurrency. The model card’s validation is a reason to investigate the extension, not a substitute for that decision. Even if the full prompt fits, downstream truncation, retrieval choices and human review can remain the application’s bottlenecks.

The text itself also matters. Aleph Alpha illustrates its English/German tokenizer with words such as Bundessozialgerichtes and silkworm, showing how they split into tokens. These are selected publisher examples, not a guarantee that every German document uses fewer tokens. For a fixed context budget, count your actual documents rather than translating a token limit into a universal page count.

Serving Kolibri 1 takes a version-bound vLLM plugin

Having the weights is only one step. Aleph Alpha’s inference-plugin README says its package registers the Kolibri1ForCausalLM implementation with vLLM and provides kolibri1 parsers for reasoning and tool calls. The README currently ties each plugin release to one vLLM minor version, listed as 0.29. Installation normally brings in its supported vLLM version; the README also describes --no-deps when adding the plugin to an already compatible vLLM installation. Before changing an existing serving environment, verify the repository’s current compatibility statement rather than assuming the plugin works with an arbitrary installed release. Pin the verified plugin and vLLM versions for a reproducible pilot; the broad installation range below is the publisher’s starting example, not a production lockfile.

For the BF16 repository, the publisher gives this command (shown for orientation, not as evidence of a successful run here):

pip install 'aleph-alpha-inference>=1'

vllm serve Aleph-Alpha/Kolibri-1-BF16 \
  --reasoning-parser kolibri1 \
  --tool-call-parser kolibri1 \
  --enable-auto-tool-choice

The repository README’s example for the default Aleph-Alpha/Kolibri-1 artifact includes --kv-cache-dtype fp8, but it explicitly tells users to drop that flag for BF16. Do not copy the default example unchanged and label it a BF16 recipe. If you want the longer context, add the two extension flags from the previous section, then size and test the intended workload. No inference speed, tool reliability or long-context accuracy is implied by a command being documented.

The card describes English and German text use, reasoning settings and tool calls, with people reviewing outputs before action in consequential workflows. The plugin makes a supported serving path available; it does not validate generated function arguments or approve an autonomous action. The calling application remains responsible for tool permissions and output checks. That distinction matters especially if the proposed use is document search, structured extraction or decision support rather than a casual chat demo.

Open weights are useful; they are not a compliance certificate

There is a more ambitious part of the release announcement. Aleph Alpha describes a sovereign supply chain, German and Finnish training infrastructure, deployment freedom, and performance in regulated workflows. It reports favorable quality-versus-throughput comparisons in its selected evaluation set and improvements on internal customer-proxy tests. Those are publisher claims under publisher-selected methods, not independent reproduction and not proof of outcomes in a real customer’s production workflow. The model card’s evaluation notes set out the harness and scoring assumptions; readers considering a migration should inspect those alongside their own workload.

The rights boundary is narrower than “the whole system is open source.” The BF16 card’s license terms apply Apache 2.0 to the weights and configuration files published in that repository. The card expressly excludes artifacts outside the repository, including underlying code and training methods. The inference plugin has its own Apache-2.0 license. The existence of those grants does not, by itself, establish what rights someone has to every part of the training stack or settle the rules for a downstream regulated application.

A sovereign deployment is a configuration and governance question as well as a model-provenance question: who operates the GPUs, where prompts and logs flow, who can invoke tools, how outputs are checked and which laws apply to the intended use. The model card’s risks and intended-use sections themselves call for additional guardrails in high-stakes settings and for applicable legal requirements to be met. We have not audited Aleph Alpha’s supply chain or assessed anyone’s compliance. Open weights can make local control possible; they cannot certify a particular deployment in advance.

The actionable verdict is deliberately narrower than the marketing frame. Evaluate Kolibri 1 as a 78.1B-weight, 3.46B-active MoE if you have the specified BF16-class hardware and a real English/German use case. Start at its trained 262,144-token context; treat 1,048,576 as a vendor-validated extension to test against your own tasks, not a native training guarantee. The weights are available, but the sensible next step is a pilot that measures memory headroom, latency and cost per completed task at your target context and concurrency. Minimum hardware is a starting constraint, not a production-capacity forecast.