把2.8万亿参数塞进消费级显卡：colibri用纯C重写MoE推理的存储层级
把 2.8 万亿参数塞进消费级显卡：colibrì 用纯 C 重写 MoE 推理的存储层级
把 2.8 万亿参数塞进消费级显卡：colibrì 用纯 C 重写 MoE 推理的存储层级
项目：colibrì
仓库：https://github.com/JustVugg/colibri
语言：C（零依赖）
今日星标：+960
支持模型：GLM-5.2 (744B)、Kimi K3 (2.8T)、DeepSeek V4 Flash (552B) 等 9 个家族
一、场景开篇：你有 6 张 5090，想跑 744B 的 MoE
你手里有 6 张 RTX 5090，每张 32GB GDDR7。加起来 192GB VRAM，听起来不少。但 GLM-5.2 是 744B 参数的 MoE 模型，int4 量化后光权重就要 370GB。VRAM 装不下，怎么办？
传统答案有三个：买 H100 集群、用云 API、或者等模型变小。
colibrì 给了第四个答案：把 NVMe、RAM、VRAM 当成同一个推理层级的三个 tier，就像 CPU 的 L1/L2/L3/RAM 一样。权重不在 VRAM 里也没关系——它在 RAM 里、在 NVMe 里，只要路由预测得准，需要的时候流进来就行。
$ ./coli chat
🐦 colibri v1.11.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU
✓ ready in 32s · resident 9.9 GB
› ciao!
◆ Ciao! 😊 Come posso aiutarti oggi?
9.9 GB 常驻内存，跑 744B 模型。这不是魔法，这是存储层级重写。
二、核心洞察：MoE 的稀疏性让"装不下"变成"流得快"
MoE（Mixture of Experts）模型的关键特性是稀疏激活：每次推理只用到一小部分专家。GLM-5.2 有 19,456 个专家，但每个 token 只路由到其中几个。
传统推理引擎的思路是：把所有专家都加载到 VRAM。装不下？那就换更小的模型。
colibrì 的思路是：既然每次只用几个专家，为什么要把所有专家都放在 VRAM 里？
这就像图书馆。传统做法是把所有书都摆在桌上（VRAM），桌子摆不下就换大桌子。colibrì 的做法是：书架（NVMe）、推车（RAM）、桌面（VRAM）是同一个层级系统的三个 tier。你需要哪本书，我提前推到桌上。
关键问题是：怎么知道下一个 token 需要哪本书？
colibrì 的答案是 "JIT for weights"——给权重做即时编译：
- 路由热度追踪：记录每个专家被路由的频率和时序
- per-layer LRU：每层维护最近使用的专家缓存
- learned pinned hot-store：学习哪些专家是"热门"的，钉在快速存储
- one-layer-ahead prefetch：提前一层预测下一个需要的专家
三、I/O 是引擎的一部分，不是免费资源
大多数推理引擎把存储 I/O 当成黑盒——需要读就读，延迟是硬件的事。colibrì 不接受这个假设：
- Batched expert unions：把多个需要加载的专家合并成一次 I/O 请求
- Overlapped reads and compute：读专家和算 token 同时进行
O_DIRECT：绕过操作系统 page cache，直接从 NVMe 读到用户空间- Weighted dual-SSD striping：两个 SSD 并行读，带宽翻倍
这让我想起一个跨域同构：CPU 的缓存层级设计。L1 miss 打 L2，L2 miss 打 L3，L3 miss 打 RAM——每一层都有预取器、替换策略、一致性协议。colibrì 把这套思路搬到了 NVMe→RAM→VRAM 的链路上。
四、硬保证：不偷偷改你的模型
这是 colibrì 最让我欣赏的设计决策：
The default policy never silently changes model precision or router semantics. Insufficient fast memory may reduce speed; it must not quietly redefine the model.
很多推理引擎在显存不够时会偷偷降精度——fp16 降成 fp8，fp8 降成 int4，router 的 top-k 从 8 降成 2。模型还能跑，但输出已经不一样了。
colibrì 划了一条硬线：速度可以降，语义不能变。VRAM 不够？那就慢一点，从 NVME 流。但 router 选哪几个专家、用什么精度算——这些必须和原模型一致。
这是一个工程伦理选择。在"能跑就行"的 AI 圈子里，有人愿意为了速度牺牲正确性。colibrì 说：那是你的选择，但默认不这么做。
五、19,456 个专家的可视化：Brain 和 Atlas
colibrì 不只是命令行工具，它有一个 web dashboard（./coli web），其中两个页面特别有意思：
Brain 页面：把 19,456 个专家显示成一个"活体大脑皮层"。颜色代表存储 tier（VRAM/RAM/NVMe），亮度代表路由热度，当前 token 路由到的专家会闪白光。
Atlas 页面：把 13,260 个已特征化的专家显示成 3D 星系。位置不是学出来的 embedding，而是实测的路由亲和性——哪些专家经常一起被激活。1,041 个"复制专家"聚集成主题星团：诗歌、法律、中文、SQL……
这不是装饰。这是把 MoE 的黑盒打开。你第一次能看到：哦，原来 GLM-5.2 谈诗歌的时候激活的是这 200 个专家，谈 SQL 的时候是另外 80 个。路由模式从抽象的数字变成了可观察的结构。
六、纯 C、零依赖、一个文件一个模型
colibrì 的代码组织方式很反潮流：
- 纯 C：不是 C++，不是 Rust，不是 Zig
- 零依赖：不依赖 PyTorch、不依赖 llama.cpp、不依赖 CUDA toolkit
- 一个 C 文件一个模型家族：GLM-5.2 一个文件、Kimi K3 一个文件、DeepSeek V4 一个文件
ioctl。你要做 CPU/GPU overlap，C 让你直接管线程。为什么一个文件一个模型？因为每个 MoE 模型的路由机制、专家结构、注意力变体都不一样。强行抽象成统一框架（像 llama.cpp 那样）会引入不必要的复杂度。colibrì 选择复制 > 抽象——每个模型独立优化，共享的是基础设施（I/O、内存管理、CLI），不是模型逻辑。
这和最近"最小化回归"的工具趋势一致：tailcat、ripgrep、fd、bat——成熟工具的特征不是功能更多，而是能被压缩到更小的代码量。colibrì 把这个逻辑用在了推理引擎上。
七、开放研究平台，不是产品
colibrì 的 README 反复强调一个定位：这是一个研究平台，不是产品。
There is no SLA on speed, and a hard guarantee on semantics: experiments must earn their place through reproducible end-to-end measurements.
它列了一张"开放假设"表：
| 假设 | 当前证据 | 还需验证 |
|---|---|---|
| 路由历史比 LRU 更好 | learned pins 在重复负载上有效，但会过fit | 跨 session A/B 测试 |
| 多 SSD 能提升解码速度 | 带宽模型成立 | 独立控制器的真机对比 |
| 硬件感知规划器能自动找最优配置 | RAM/VRAM 预算和后端已检测 | 跨机型参数扫描 |
| 无损/有界表示能减少权重搬运 | 量化消融已有，正确性门控存在 | 质量+延迟+成本联合度量 |
八、为什么这件事重要
colibrì 解决的不是"怎么跑大模型"——云厂商已经解决了，用 H100 集群。它解决的是"怎么在自己硬件上跑大模型"。
这个区别很重要。云 API 是租用智能——你按 token 付费，模型在别人机器上，你看不到路由、看不到专家、改不了内核。colibrì 是持有智能——模型在你的 NVMe 上，你看着 19,456 个专家闪烁，你改 C 代码优化它。
当前沿模型从 700B 走向 2.8T（Kimi K3），消费级硬件的差距只会越来越大。云是唯一出路吗？colibrì 说不是。存储层级、I/O 优化、路由预测——这些系统层面的工作可以把"装不下"推后几个量级。
这不是" democratize AI"的口号。这是把推理引擎从"黑盒 API"变回"可读的 C 文件"。
九、一句话总结
colibrì 把 NVMe/RAM/VRAM 当成推理层级的三个 tier，用路由预测做 JIT 权重加载，在消费级硬件上跑 744B-2.8T 的 MoE 模型——纯 C、零依赖、语义不变。
它不是最快的引擎，但它是最诚实的引擎：不偷偷降精度，不假装确定，把假设摆在台面上。在一个"能跑就行"的圈子里，这种工程伦理比速度更稀缺。
仓库：https://github.com/JustVugg/colibri
网站：https://justvugg.github.io/colibri
Discord：https://discord.gg/RXV83nSZdk