闻乐 发自 凹非寺 量子位 | 公众号 QbitAI

25GB 笔记本硬跑 744B GLM-5.2，32GB 内存挑战 2.8T Kimi K3 ——

甚至都不用 GPU。

GitHub 现在最火热的大模型开源小蜂鸟 Colibr ì，纯 C 实现、零引擎依赖的分层推理框架，已经狂揽 32k Star。

它最早是冲着 GLM-5.2 来的。

正常情况下，744B 的总参数规模已经让普通消费级电脑望而却步，但 Colibr ì 的办法可以说是相当简单粗暴：

内存装不下，那就别全装进去。

模型里暂时用不到的部分，直接扔在 SSD 里；等推理真的需要哪个专家，再现场从硬盘把它捞出来。

于是，GLM-5.2 经过 int4 处理后大约 372GB 的权重，可以在最低 16GB、推荐 24GB 左右 RAM 的机器上运行，GPU 甚至不是必需品。

作者最初验证它的开发机，也只有 12 核 CPU+25GB RAM。

现在，Colibr ì 已经不满足于 744B 了。

它目前已经覆盖 9 个模型家族，从 GLM-5.2/5.3、DeepSeek V4 Flash、Qwen，一路支持到了 975B 的 Inkling，以及 2.8T 参数的 Kimi K3。

虽然后者需要大约 1.6TB 硬盘空间，但 RAM 要求只要 32GB 起步。

744B 模型，内存里只放 9.9GB

Colibr ì 能这么玩，首先得感谢这两年越来越流行的 MoE 架构。

以 GLM-5.2 为例。虽然整个模型足足有 744B 参数，但 MoE 并不会在生成每个 token 时把 744B 参数全部计算一遍。

它会先通过 Router 判断：这个 token 该交给哪些 " 专家 " 处理？然后只激活其中一小部分。

GLM-5.2 总参数 744B，但每个 token 实际激活的参数大约只有 40B，这就留下了一个很大的操作空间：

既然绝大多数专家当前根本用不上，为什么非得把它们一直放在昂贵的高速内存里？

于是 Colibr ì 干脆把模型拆成了常驻和临时调用两部分。

Attention、Embedding、共享专家这些每次推理都要用到的 Dense 部分，大约 17B 参数，int4 之后只占约 9.9GB，直接常驻 RAM。

真正占地方的是后面庞大的路由专家。

GLM-5.2 有 19456 个路由专家，int4 之后整体仍然要占大约 370GB。

这么大权重，普通电脑的内存显然塞不下。

Colibr ì 索性把它们全部放到 NVMe SSD。

模型开始生成 token 之后，Router 先选出当前真正需要参与计算的专家；Colibr ì 再检查它们是否已经在高速内存中，没有命中的部分，才临时从 SSD 读取。

算完这层，再继续处理下一层。

以前运行大模型的思路大致是先想办法把模型装进显存 / 内存，再开始计算。

Colibr ì 相当于把这事儿倒过来了，需要什么，我再加载什么。

作者 JustVugg 把这种方式类比成了一个针对模型权重的 JIT。

传统 JIT 不会提前编译整个程序，而是观察哪些代码真的在运行，再处理热点路径。

Colibr ì 的思路也类似。

不把 744B 参数看作必须始终驻留在内存中的整体，而是将它变成一堆可以根据 Router 结果，在 SSD、RAM 和 VRAM 之间动态调度的数据。

SSD 也成 " 显存 " 了

当然，如果每生成一个 token 都从 SSD 里现找专家，那电脑估计得读盘读到怀疑人生，速度恐怕也相当感人。

事实上，在 Colibr ì 最早那台 12 核 CPU+25GB RAM 的开发机上，GLM-5.2 冷缓存时确实只有大约 0.05～0.1 token/s。

跑是能跑，但有亿点慢……

所以，Colibr ì 接下来花心思的地方就是：

怎么尽可能少去 SSD 里捞专家，如何让 SSD、RAM 和 VRAM 协同工作。

它把 VRAM、RAM 和 NVMe SSD 组织成了一套分层的模型内存系统。

基本原则很好理解，越常用的专家，住得越近。

已经待在 VRAM 或者 RAM 里的专家，直接计算；

最近刚刚使用过的专家，会尽可能继续留在 RAM 缓存里；

真正不常用的专家，才继续待在 SSD 里，需要时再读取。

为此，Colibr ì 首先加入了 LRU 缓存。

最近被调用过的专家会优先留在 RAM 里，如果后面的 Token 又点中了同一个专家，就不需要重新跑一趟 SSD。

同时，Colibr ì 还会在运行过程中不断记录不同专家的使用次数。

跑得越久，它越清楚哪些专家是真正的 " 常客 "。

这些高频专家会获得更高的缓存优先级，被尽量留在速度更快的存储层。

而且 Colibr ì 还不满足于等 Router 点完名再行动，它甚至会提前猜下一层要找谁。

根据项目测试，相邻层之间的专家路由存在相当明显的相关性，提前一层预测专家的可预测性达到 71.6%。

于是当前这一层还在计算的时候，Colibr ì 就可以在后台提前读取下一层可能需要的专家。

一边算一边读，原本串行发生的计算和 SSD I/O 被尽可能重叠起来。

甚至 SSD 本身都还能继续堆料。

如果机器里正好有两块 SSD，Colibr ì 支持放置第二份模型副本，把专家读取任务分摊到不同硬盘上，并行利用两块盘的带宽。

这么一套操作下来，它更像是给 MoE 模型做了一套权重分级调度系统。

容量最大、最慢的 NVMe 负责兜底；RAM 负责缓存更多常用专家；

如果有 GPU，VRAM 则继续接住最适合放进高速内存的部分。

哪里快，就尽量把最常用的权重往哪里搬；哪里空间大，就负责装下剩下的模型。

开发者把这套思路称为 AI memory multitiering，AI 内存多层化。

这里有一条很重要的设计原则是，专家放在哪里，只决定速度，不改变模型本身。

一个专家无论已经待在 VRAM 里，还是临时从 SSD 里读取，Router 的选择都不会因此改变，使用的权重精度也完全相同。

Colibr ì 不会因为你的机器内存少，就偷偷少算几个专家或者换一套路由。

所以到了 128GB RAM 的纯 CPU 桌面机，可以缓存更多专家之后，速度能达到约 1.8 token/s；

如果一路堆到 6 张 RTX 5090，让全部专家常驻高速存储层，解码速度则可以来到 5.8～6.8 token/s。

跑前沿大模型，不一定非要用机房里的专业服务器。

快速上手

朋友们有兴趣也可以自己跑跑看。

以 GLM-5.2 为例，需要准备的东西其实只有两个：

几百 KB 的 Colibr ì 程序，以及大约 372GB 的模型。

想从源码开始，也只需要 gcc 或 clang 配合 OpenMP。

项目已经提供预转换好的 GLM-5.2 int4 模型，也可以从 FP8 原始模型自行转换。模型放好之后，一条 coli chat 就能直接进入对话。

想更直观一点，则可以直接打开 Web Dashboard。

里面能实时看到 Token 生成速度、不同阶段耗时，以及当前有多少专家待在 VRAM、RAM 和磁盘。

Colibr ì 还专门做了一个 "Brain" 页面，把 GLM-5.2 的 19456 个专家全部可视化出来：

哪个专家刚刚被 Router 点名、当前住在哪一层存储、调用热度如何，都能直接看到。

不只是 GLM-5.2，Colibr ì 目前支持的模型跨度很大，目前可运行九个模型。

每个模型单独一套 C 适配文件，但是底层 IO、缓存、tokenizer 等公共组件复用同一个核心。

小尺寸的有 Qwen3.8-Flash-Next、Qwen3.6 和 OLMoE；

接着 DeepSeek V4 Flash 是 284B；GLM-5.2/5.3 是 744B；GLM-5.3-Flash 是 321B；

Thinking Machines 的 Inkling 则来到了 975B；

最大的一位是 Moonshot 的 Kimi K3：2.8T 总参数、104B 激活参数。

这模型的权重需要大约 1.6TB 存储空间，但按照 Colibr ì 给出的配置，RAM 从 32GB+ 就能起跑，同样不强制要求 GPU。

作者还欢迎大家踊跃参与实验，寻找更高效方案。

Tiny engine, immense model，微小引擎，庞大模型。

Colibr ì 是只胃口不小的蜂鸟。

项目地址：https://github.com/JustVugg/colibri

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！