All 20 Dependencies

Every package Colibri depends on, ranked by repo health score.

Colibri is an inference engine, written entirely in C with zero runtime dependencies, built to run GLM-5.2 — a 744-billion-parameter mixture-of-experts model — on a machine with as little as 25GB of RAM. It does this by treating VRAM, RAM, and disk as a single managed memory hierarchy: the dense, always-needed part of the model (attention, shared experts, embeddings) stays resident in RAM at low precision, while the tens of thousands of routed experts live on disk and are streamed in on demand, based on which ones the router actually selects for a given token.

The core idea is explicitly compared to a just-in-time compiler: rather than compiling or loading an entire program up front, a JIT watches what actually executes and optimizes the hot paths. Colibri makes the analogous bet about model weights — they are not resident state to be held everywhere, but data to be staged across a heterogeneous storage hierarchy exactly when the router proves it needs them. A self-learning cache tracks which experts a given workload routes to and pins the hottest ones automatically, a lookahead thread prefetches upcoming experts by exploiting measurable structure in routing behavior, and a dual-drive mirroring scheme can pool the read bandwidth of two SSDs instead of only using the faster one.

On top of the engine sit multiple interfaces: a `coli` CLI with chat, one-shot run, serve, benchmarking, and diagnostic subcommands, an OpenAI-API-compatible HTTP server for dropping the model behind existing client code, and a React/TypeScript web dashboard that visualizes live token metrics, hardware tier usage, and the model's tens of thousands of experts as an interactive 3D map of routing activity. The project backs its from-scratch reimplementation of a novel attention and MoE architecture with a rigorous validation discipline — every change must reproduce a reference implementation's output token-for-token before merging.

Colibri spans a wide hardware range with the same codebase: on a small machine everything streams from disk at a modest but working pace, while on a large multi-GPU workstation the entire expert set can be pinned resident in VRAM, removing disk from the decode path entirely. Its explicit goal is to let a curious individual open up and modify a frontier-scale model on hardware they already own, rather than only being able to rent access to one behind an API.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search