colibri 用纯 C 做 MoE 分层推理：热专家上 GPU，冷专家从 NVMe 流式读

colibri 是个 47.3k 星标的开源项目，C 语言写成，面向前沿 MoE 模型做分层推理：热专家放 GPU（CUDA 或 Vulkan），温专家留在内存，冷专家从 NVMe 流式加载。

它解决的问题很具体

MoE 模型总参数动辄几千亿，但每次推理只激活一小部分专家。显存装不下全部权重，这是硬约束。

传统做法是整模型量化压缩到显存能装下，代价是精度损失。colibri 换了思路：不动精度，动数据位置。按访问频率把专家分成三级，用存储层级换显存容量。

为什么用 C

这类引擎的性能瓶颈在数据搬运与调度，内存布局、DMA、异步 IO 都要贴着硬件写。C 没有 GC、没有运行时开销，能精确控制每一块内存的归属。

代价是可维护性与生态。这类项目通常只有少数核心作者能改。

这条路的天花板

NVMe 的顺序读带宽不错，随机读延迟在几十微秒级。一旦专家切换频繁，每次推理都要等 IO，吞吐会被拖垮。所以冷热分级的准确性决定一切，判断错了就是灾难。

适合谁

想在现有硬件上跑超大 MoE、又不想牺牲精度的团队。不适合高并发在线服务，IO 抖动会直接反映到 P99 延迟上。

对比思路

同类的还有把专家放主机内存、用 PCIe 搬运的方案，延迟更低但容量受限。选哪条，取决于你的模型激活模式是集中还是分散。先去测一下真实请求的专家命中分布，再决定。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

冷热专家分级的准确性决定一切，判断错了就是灾难。NVMe 随机读几十微秒，专家切换一频繁，P99 延迟直接爆。适合离线批处理，不适合在线高并发。

不动精度动数据位置，这个思路比一味量化干净。三级分层的关键在预判，热专家判定错了就是一次 NVMe 随机读，延迟直接上毫秒级。纯 C 实现省掉了运行时开销，但也意味着调度策略要自己写死。想了解冷专家的预取是按 token 序列预测还是按路由概率提前拉。