闻乐 发自 凹非寺 量子位 | 公众号 QbitAI
25GB 笔记本硬跑 744B GLM-5.2，32GB 内存挑战 2.8T Kimi K3 ——
甚至都不用 GPU。
GitHub 现在最火热的大模型开源小蜂鸟 Colibr ì，纯 C 实现、零引擎依赖的分层推理框架，已经狂揽 32k Star。
正常情况下，744B 的总参数规模已经让普通消费级电脑望而却步，但 Colibr ì 的办法可以说是相当简单粗暴：
内存装不下，那就别全装进去。
模型里暂时用不到的部分，直接扔在 SSD 里；等推理真的需要哪个专家，再现场从硬盘把它捞出来。
于是，GLM-5.2 经过 int4 处理后大约 372GB 的权重，可以在最低 16GB、推荐 24GB 左右 RAM 的机器上运行，GPU 甚至不是必需品。
作者最初验证它的开发机，也只有 12 核 CPU+25GB RAM。
它目前已经覆盖 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，这就留下了一个很大的操作空间：
既然绝大多数专家当前根本用不上，为什么非得把它们一直放在昂贵的高速内存里？
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，Colibr ì 支持放置第二份模型副本，把专家读取任务分摊到不同硬盘上，并行利用两块盘的带宽。
这么一套操作下来，它更像是给 MoE 模型做了一套权重分级调度系统。
如果有 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。
里面能实时看到 Token 生成速度、不同阶段耗时，以及当前有多少专家待在 VRAM、RAM 和磁盘。
哪个专家刚刚被 Router 点名、当前住在哪一层存储、调用热度如何，都能直接看到。
每个模型单独一套 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。
作者还欢迎大家踊跃参与实验，寻找更高效方案。
Colibr ì 是只胃口不小的蜂鸟。
项目地址：https://github.com/JustVugg/colibri
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
