JustVugg/colibri was #3 on GitHub’s daily Trending repositories page when checked on September 16, 2026. GitHub showed 1,532 stars today, 34,895 total stars, and 3,666 forks. The repository’s primary language was C. Those figures explain the attention snapshot; they do not prove that the engine will be fast or convenient on your machine.

Colibri’s useful idea is simple to state: a sparse Mixture-of-Experts (MoE) model can contain far more parameters than it activates for each token. Instead of demanding that every weight fit in VRAM or RAM, Colibri treats storage, system memory, and graphics memory as tiers. The routed expert weights can live on NVMe and be brought into faster memory when the model’s router asks for them.

What makes the project different

The README describes Colibri as a pure-C engine with zero engine dependencies. Its current roster includes model families ranging from OLMoE at 7B parameters to Kimi K3 at 2.8T, with several intermediate models such as GLM-5.2/5.3, DeepSeek V4 Flash, Qwen3.6, and Qwen3.8-Flash-Next. Treat that roster as a moving project snapshot: model support, formats, and commands can change on the default branch.

The important distinction is not simply “large model, small computer.” Colibri separates the relatively stable dense portion from routed experts. The README’s GLM-5.2 example describes about 9.9 GB of dense int4 state resident in RAM, while 19,456 routed experts occupy roughly 370 GB on disk and are streamed as needed. The exact figures are model-specific, and the project presents them as part of its current measurements and design documentation rather than as a universal hardware recipe.

This makes Colibri a different kind of local-AI tool. It is designed to make an oversized MoE model run at all, even when storage I/O becomes the limiting factor. If you want a compact model for everyday chat, a runtime that keeps the entire model in memory may still be the better fit. If you are studying model routing, storage-aware inference, or the boundary between a workstation and a cloud-sized model, Colibri offers a particularly concrete experiment.

How the memory hierarchy works

Think of the engine as a just-in-time loader for model weights:

1. The model router identifies the experts needed for the next token.
2. Colibri forms a batched union of the routed experts for a layer.
3. The runtime checks its faster tiers and reads missing experts from NVMe.
4. CPU, CUDA, Metal, and NUMA-aware paths can overlap movement and compute when the hardware makes that worthwhile.
5. Routing history can guide caching and prefetching, but the README explicitly treats those policies as experiments rather than guaranteed wins.

That last point matters. Colibri’s documentation says placement should change speed, not model semantics or precision. It also warns that learned hot-expert placement can overfit a prompt and that lookahead can lose on some hosts. This is a healthier way to read performance claims: the project exposes hypotheses and asks contributors to publish negative results, hardware details, cache state, commands, throughput, time to first token, expert hit rate, and bytes read.

The engine also documents optional multi-SSD operation. With a complete model copy on a second drive, read-only expert traffic can be split across both devices. The README gives a 9 GB/s plus 3 GB/s example that reads about 33% faster than the fast drive alone, while also warning that the result depends on the actual drives and workload. A mirror is validated at startup, and a read failure can fall back to the primary drive. That is a useful systems technique, not a guarantee that every two-drive setup will improve decoding.

A careful first run

The repository publishes prebuilt archives and a source build path. The release page currently lists v1.11.0, published September 13, 2026, with Linux x86_64, macOS arm64, and Windows x86_64 archives. For a reproducible trial, download the archive for your platform, verify its checksum using the release’s SHA256SUMS.txt, and read the repository’s current model-conversion and usage notes before fetching weights.

The documented command surface is deliberately small:

./coli info
./coli doctor --model /path/to/model
./coli plan --model /path/to/model
./coli chat --model /path/to/model
./coli serve --model /path/to/model

Start with info, then doctor and plan. They help distinguish an unsupported or incomplete model directory from a performance problem. Use chat for an interactive test, serve for an API-style process, and web when you want the project’s dashboard. Do not begin by assuming the headline 744B example is the right test: the README says smaller supported families such as OLMoE and Qwen3.6 require much less storage and memory.

Before committing a large download, check three constraints:

• Storage: a 744B model may need hundreds of gigabytes, even when only a fraction is active per token.
• Memory: dense state and caches still need RAM; the model being sparse does not make the whole workload lightweight.
• Latency: cold reads from disk can make a technically successful run feel unusable. A GPU or second SSD may reduce waiting, but only measurement on your machine answers that question.

The project is Apache-2.0 licensed, but that license covers the repository code, not automatically every model checkpoint, dataset, or dependency you pair with it. Keep those terms separate. For a broader look at how local tools and agent workflows fit into a personal setup, our guide to building a personal knowledge base is a useful companion; for a very different layer around AI coding tools, see ECC on GitHub Trending.

Who should try it?

Colibri is a good fit for an engineer or researcher who wants to explore sparse models beyond the capacity of a normal GPU, measure storage-aware inference, or inspect a small systems-oriented C codebase. It is less suitable as an always-on production service until you have validated model compatibility, latency, error handling, and the project’s fast-moving release cadence on your own hardware.

The most useful experiment is modest: choose a model you can store, run the documented readiness checks, record cold and warm timings, and change one variable at a time. Compare a single SSD with the optional mirror, or compare CPU-only execution with a configured GPU tier. Keep the logs and model version. A result that says “this was slower” is still valuable if another reader can reproduce it.

Bottom line

Colibri is trending because it turns an intimidating systems problem into a tangible local experiment. Its core contribution is a storage-aware execution model for sparse MoE weights: route only what is needed, stage it through a hierarchy, and measure the complete path. That can open a new class of experiments on ordinary workstations, but it does not erase disk capacity, memory pressure, or latency. Start with the smaller model and the project’s own checks, then decide whether the trade-off is useful for your hardware.

Sources

• GitHub daily Trending repositories
• JustVugg/colibri repository
• Colibri README
• Colibri Apache License 2.0
• Colibri v1.11.0 release
• Colibri official project documentation
• Oflight’s independent Colibri overview

Hero image: Original illustration generated for Lejnel.com; no third-party assets used.

Frequently Asked Questions

What is Colibri?

Colibri is a pure-C inference engine and research platform for sparse Mixture-of-Experts models. Its memory strategy treats VRAM, RAM, and NVMe storage as one hierarchy and loads routed experts on demand.

Can Colibri run a large model without a GPU?

Yes, the project documents a CPU-only route. A GPU can add a faster VRAM tier, but the practical memory and storage requirements vary substantially by model.

Is Colibri a replacement for Ollama or llama.cpp?

Not generally. Colibri is specialized for MoE models that may not fit in fast memory, while Ollama and llama.cpp are broader runtimes whose usual workflows keep a model resident in available memory or VRAM.

What license does Colibri use?

The repository includes the Apache License 2.0. Read the license and the repository's current dependency and model terms before redistributing a complete application or model package.