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

Colibrì的核心思路是把运行大模型的顺序倒过来：不再先想办法把整个模型装进显存或内存再计算，而是需要哪个专家，再现场从SSD加载哪个。作者JustVugg把这套方式类比为针对模型权重的JIT——不提前编译整个程序，而是观察哪些代码真的在跑，再处理热点路径。

这套做法能成立，前提是MoE架构。以GLM-5.2为例，总参数744B，但每个token实际激活的参数大约只有40B；Router先判断该交给哪些专家，再只激活其中一小部分。既然绝大多数专家当前用不上，就没必要让它们一直占着高速内存。

于是模型被拆成两部分：Attention、Embedding、共享专家等每次推理都要用到的Dense部分约17B参数，int4之后只占约9.9GB，常驻RAM；真正占地方的是19456个路由专家，int4之后整体仍约370GB，全部放到NVMe SSD。按来源说法，GLM-5.2经int4处理后约372GB权重，可在最低16GB、推荐24GB左右RAM的机器上运行，GPU甚至不是必需品。

如果每生成一个token都要从SSD现找专家，速度会非常难看。在Colibrì最早那台12核CPU+25GB RAM的开发机上，GLM-5.2冷缓存时确实只有大约0.05～0.1 token/s——跑是能跑，但慢到几乎不可用。

因此项目把优化重点放在“怎么尽可能少去SSD捞专家”。它把VRAM、RAM和NVMe SSD组织成分层内存系统，原则是越常用的专家住得越近：已在VRAM或RAM的直接计算，最近用过的尽量留在RAM缓存，真正不常用的才留在SSD。LRU缓存让最近被调用的专家优先留在RAM；运行中还会记录各专家使用次数，高频专家获得更高缓存优先级。

更进一步，它不等Router点完名再行动。根据项目测试，相邻层之间的专家路由存在明显相关性，提前一层预测专家的可预测性达到71.6%，于是当前层还在计算时，后台就可以提前读取下一层可能需要的专家，把计算与SSD I/O尽可能重叠。效果上，128GB RAM的纯CPU桌面机可缓存更多专家，速度约1.8 token/s；若堆到6张RTX 5090让全部专家常驻高速存储层，解码速度可达5.8～6.8 token/s。

Colibrì有一条重要设计原则：专家放在哪里，只决定速度，不改变模型本身。一个专家无论已待在VRAM里，还是临时从SSD读取，Router的选择都不会因此改变，使用的权重精度也完全相同；它不会因为机器内存少就偷偷少算几个专家或换一套路由。开发者把这套思路称为AI memory multitiering（AI内存多层化）。

工程上还有可叠加的手段：如果机器里有两块SSD，Colibrì支持放置第二份模型副本，把专家读取任务分摊到不同硬盘，并行利用两块盘的带宽。上手门槛也不高——以GLM-5.2为例，需要几百KB的Colibrì程序和约372GB的模型；项目提供Linux、macOS和Windows预编译版本，从源码构建只需gcc或clang配合OpenMP，一条coli chat即可进入对话，Web Dashboard可实时查看token生成速度、各阶段耗时以及专家分布在VRAM、RAM和磁盘的情况。

需要明确的是，上述速度数字与71.6%可预测性均来自项目方自述或来源转述，属于source_claim，尚无第三方独立验证；不同硬件、模型与缓存状态下实际表现可能差异很大。

Colibrì最早是冲着GLM-5.2来的，如今已覆盖9个模型家族。小尺寸的有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激活参数。

按来源给出的配置，Kimi K3的权重需要约1.6TB存储空间，但RAM从32GB+就能起跑，同样不强制要求GPU。每个模型单独一套C适配文件，底层IO、缓存、tokenizer等公共组件复用同一个核心。作者也欢迎社区参与实验，寻找更高效方案。

这些模型清单与配置要求同样来自来源转述，属于source_claim；其中Kimi K3的1.6TB存储与32GB RAM起步要求，未见第一方独立确认。