笔记本跑7000亿参数GLM！无GPU也行? SSD当显存用火爆GitHub

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 笔记本跑7000亿参数GLM！无GPU也行? SSD当显存用火爆GitHub 田, 晏林 2026-09-26 17:01:00 来源： 量子位 GitHub现在最火热的大模型开源小蜂鸟Colibrì是个啥？ 闻乐 发自 凹非寺 量子位 | 公众号 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的模型。 Colibrì已经提供Linux、macOS和Windows的预编译版本，不想折腾编译的话，下载对应版本解压即可； 想从源码开始，也只需要gcc或clang配合OpenMP。 项目已经提供预转换好的GLM-5.2 int4模型，也可以从FP8原始模型自行转换。模型放好之后，一条coli chat就能直接进入对话。 想更直观一点，则可以直接打开Web Dashboard。