登上GitHub趋势榜！纯C推理引擎让25GB内存也能运行GLM-5.2

744B 参数的大模型，通常需要什么样的机器才能跑起来？

多张高端 GPU、大容量显存，或者直接把模型交给云端推理服务，基本已经成了默认答案。

但最近 GitHub 上有个项目，走了另一条很不一样的路线。

它不想把整个模型都塞进显存，甚至也不要求模型完整驻留在内存，而是直接把 NVMe SSD、RAM 和 VRAM 看成同一个分层推理空间。

项目叫 colibri。

它最初由 GitHub 用户 JustVugg 以单人项目形式启动，仓库创建于 2026 年 7 月 1 日。短短两个多月，已经拿下 35.2K Stars。

它最吸引人的地方，是已经让 GLM-5.2 这样的 744B MoE 模型在只有 25GB RAM 的机器上真正运行起来。

而现在，它支持的模型范围还在继续扩大，包括 GLM-5.2/5.3、GLM-5.3-Flash、Inkling、DeepSeek V4 Flash、Qwen3.8-Flash-Next、Qwen3.6、OLMoE，甚至还有总参数达到 2.8T 的 Kimi K3。

核心推理引擎使用纯 C 实现，没有 BLAS 等 engine dependency，也不强制要求 GPU。

真正有意思的是，colibri 并不是靠把一个 744B 模型“压缩成几十 GB”来实现这一点。

它改变的是模型权重必须常驻内存这件事。

为什么一个 744B 模型，能够在 25GB 内存的机器上启动，关键在于 MoE。

GLM-5.2 虽然总参数达到 744B，但一次生成 Token 时，并不会把所有参数都参与计算。

按照 colibri 给出的数据，每个 Token 实际激活约 40B 参数，只占模型总参数的约 5.4%。

其中真正随着 Router 选择不断变化的 routed experts，对应的数据量大约只有 11GB。

既然绝大部分专家这一刻根本用不到，为什么还一定要提前把它们全部放进昂贵的 RAM 或 VRAM。

colibri 的做法是把模型拆成两类。

相对固定的 Dense 部分，包括 Attention、Shared Experts 和 Embedding 等，大约 17B 参数，以 int4 形式常驻 RAM，实际约占 9.9GB。

剩下规模庞大的 Routed Experts 则完全换一种处理方式。

GLM-5.2 中一共有 19,456 个 Routed Experts。按照 int4 存储，每个专家约 19MB，整体在磁盘上大约需要 370GB。

这些专家不再全部加载到内存。

它们可以直接待在 NVMe SSD 上，等 Router 真正选择到某个专家时，再按需读取。

所以 colibri 真正做的，是把 VRAM、RAM、NVMe SSD 统一成一个权重存储层级。

最快、最常访问的专家可以放进 VRAM。

经常命中的专家可以留在 RAM。

大量暂时没有被调用的专家继续待在 SSD。

硬件资源不足时，并不是直接告诉你“模型放不下”，而是让更多权重下沉到速度更慢的层级。

项目把这套思路类比成给模型权重做 JIT。

传统 JIT 不会提前编译程序所有路径，而是观察真正执行的部分，再优化热点代码。

colibri 也不会要求 744B 参数全部成为常驻状态，而是根据 Router 的实际选择，把当前真正需要的权重提前搬到更快的存储层。

系统会记录 Expert Routing Heat，通过 Per-layer LRU、Pinned Hot-store 等机制保存热门专家，还可以提前一个 Layer 做 Prefetch，尽量把 SSD 读取时间藏在计算过程里。

换句话说，权重从“必须常驻的模型状态”，变成了可以动态调度的数据。

更直观的是，colibri 甚至把这 19,456 个专家做成了一个实时可视化页面。

不同颜色代表专家当前位于哪个存储层级，亮度代表 Routing Heat，被当前 Token 选中的专家还会实时闪烁。

这里必须把一个很容易被标题忽略的问题说清楚。

25GB RAM 能跑，不代表 25GB RAM 跑得快。

colibri 最早使用的开发机只有 12 核 CPU、25GB RAM 和 NVMe。

GLM-5.2 在这台机器上确实能够正确完成推理，但冷启动状态下的 Decode 速度只有大约 0.05—0.1 tok/s。

项目文档自己也写得很直接，这并不快。

真正的意义在于，它证明了“744B 模型必须完整塞进高端显存或超大内存”并不是唯一方案。

而当硬件资源增加以后，colibri 不需要换另一套推理架构。

它只是不断把专家从 SSD 往 RAM、再往 VRAM 上搬。

同一个引擎，硬件资源决定的是 权重放在哪一层，以及最终能跑多快。

一个很典型的实验发生在 6×RTX 5090 的机器上。

测试机器拥有 6 张 32GB RTX 5090、双路 Intel Xeon Silver 4510、251GB RAM 和本地 NVMe。

当 colibri 最终把全部 19,456 个专家完整放进 VRAM + RAM 后，Decode 阶段已经不再需要访问磁盘。

其中约 9343 个专家进入 GPU，10113 个专家放在 RAM，Decode 磁盘等待时间降到 0 秒。

最终在固定 96 Token Greedy Benchmark 上达到 6.28 tok/s，256 Token 测试进一步达到 6.84 tok/s。

这里最值得看的不是单独一个 6.84 tok/s。

而是从 25GB 小机器到六张 RTX 5090，colibri 使用的仍然是同一种模型放置逻辑。

在小机器上，大量 Expert 从 SSD Streaming。

RAM 多一些，就把 Hot Experts 留在内存。

有 GPU，就继续把高频 Expert 推进 VRAM。

资源足够时，整个 Routed Expert Set 都能驻留在 VRAM + RAM 中，磁盘自动退出 Decode Critical Path。

这也是它和普通“CPU 跑大模型”项目比较不一样的地方。

它解决的不是单一硬件配置，而是在尝试构建一套跨 SSD、RAM、CPU、GPU 的统一 MoE 推理层级。

目前项目还支持双 SSD Streaming、CUDA、Metal、NUMA、Expert Prefetch、Routing History、Hot Expert Pinning 等机制。

模型支持范围也从最初的 GLM-5.2 继续扩展。

其中 Kimi K3 总参数达到 2.8T。

也就是说，colibri 现在研究的问题已经不只是“怎么在小机器上跑一个 744B 模型”。

当模型总参数越来越大，但每次真正参与计算的参数依然有限时，能不能把“模型必须装进内存”这个前提彻底拆掉。

当然，内存省了不代表存储也省了。

以 GLM-5.2 为例，官方推荐的 colibri int4 Container 仍然大约需要 372GB 磁盘空间。

所以 25GB 指的是 RAM 门槛，不是“整个 744B 模型只有 25GB”。

这个区别很重要。

过去部署大模型时，一个最直观的问题是，我的显存或者内存，能不能装下这个模型？

colibri 尝试把这个问题换掉。

对于 MoE 来说，如果每个 Token 真正使用的只是总参数中的一小部分，那么更重要的问题可能不是：

整个模型能不能常驻。

下一步需要哪些权重，这些权重现在应该位于 SSD、RAM 还是 VRAM。

这也是 colibri 最有意思的地方。

它并没有声称 25GB 消费级机器可以替代多 GPU 服务器，项目甚至很明确地公开了 0.05—0.1 tok/s 这样的低速结果。

但它证明了一种新的推理思路：

总参数规模和高速内存容量，不一定必须继续一一绑定 。

模型越来越大之后，除了继续买更多显存，另一条路可能就是让模型权重真正流动起来。

哪些专家应该常驻，哪些可以缓存，哪些应该提前预取，哪些只需要在被 Router 选中时才从 SSD 读取。

过去大家优化的是 Kernel 和算力。

colibri 更进一步，把权重本身放在哪里、什么时候搬、怎么搬也变成了推理系统的一部分。

对于越来越大的 MoE 模型来说，这条路线值得继续看。