On September 10, DeepSeek released V4.1 Flash — 552B total parameters, 16B active, fp4 experts over an fp8 dense trunk. Three days later, the open-source inference engine Colibri shipped v1.11.0 with its ninth model-family engine, which streams that 510 GB official checkpoint straight off an SSD into memory: zero format conversion, running on pure CPU.

First, the engine itself. Colibri is a MoE inference engine written in pure C — one .c file per model family, zero runtime dependencies: no BLAS, no Python at runtime, no GPU required. Its core idea treats VRAM, RAM and SSD as a single inference memory hierarchy: routed experts live on disk and are staged in only when routing proves they are needed. The repository currently sits at 31.1k stars, 2,230 commits, Apache 2.0, with nine families ranging from the 744B GLM-5.2/5.3 up to the 2.8T Kimi K3.

The V4.1 engine: 203 GB of memory that never enters RAM

The release notes are unusually dense. The 552B checkpoint occupies 510 GB on disk, of which 203 GB is a double n-gram memory called Engram — 384M rows that never enter RAM and are read from disk a few hundred bytes at a time. The dense trunk is fp8 (32x32 ue8m0 tiles) and the experts are fp4, with a layout byte-identical to the mxfp4 the Kimi K3 engine already reads — that is the technical foundation of "no conversion". The README's comparison: V4.1 Flash pays 4.5 GB of expert reads per token, against GLM-5.2's 12.7 GB. The 32-layer vision tower, tool calling in the checkpoint's own DSML format, and DSpark speculative decoding (3 stages, blocks of 5) are all implemented; CI holds the engine token-exact against a torch-only CPU reference the team had to write themselves — the vendor's own forward needs tilelang GPU kernels and cannot run on a CPU — with the vision tower matched to 5e-06.

From 78.7 to 25.1 seconds: failures documented too

Measured on the released checkpoint, cold, caches dropped before every run, same prompt and seed: a turn went from 78.7 s to 25.1 s (0.305 to 0.957 tok/s), via batched expert reads (READ_DEPTH, default 8, the measured knee), attention matrices read once per block of positions instead of once per token, and an expert-major MoE layout — every step bit-exact against what it replaced. A five-turn chat session runs at 1.14–1.58 tok/s. Slow? Yes. But the team also wrote down what failed: two schemes for hiding expert reads behind the matmuls were built, measured worse, and removed, with the numbers preserved in docs/deepseek-v41.md so the next attempt starts from them.

The second battlefield of open weights

The news here is not speed but ecosystem response: three days after the model dropped, a third-party pure-C engine reads the checkpoint natively. Together with WARP moving 313B GLM-5.3-Flash experts into NVMe in late August, and Cohere's single-file megakernel, these are three answers on the same track — the engine layer is becoming the battlefield where open weights actually land. APIs can raise prices, throttle, or shut down; holding a model on a machine with no GPU, instead of renting it, is a choice that engines provide.

So the next time a "landmark open release" lands, don't just read the benchmarks — check how fast an engine can run it. That is the real measure of what open weights are worth.

Reference: Colibri v1.11.0 Release Notes · Colibri README