Colibrì：用 SSD 当显存，笔记本也能跑 744B 大模型

一款名为 Colibrì 的开源项目近期在 GitHub 上迅速走红，已收获超过 32k Star。它以纯 C 编写、零外部引擎依赖，通过把 MoE 模型中暂时用不到的路由专家卸载到 NVMe SSD，实现「内存装不下，就别全装进去」的本地大模型推理方案。

核心思路：按需加载专家

Colibrì 最初是为运行 GLM-5.2 而设计。GLM-5.2 总参数达 744B，但 MoE 架构下每个 token 实际激活的参数量大约只有 40B，这为分层调度提供了空间。

项目把模型拆成两部分：

常驻部分：Attention、Embedding、共享专家等 Dense 模块，int4 后约 9.9GB，常驻 RAM；
临时调用部分：19456 个路由专家，int4 后约 370GB，整体放在 NVMe SSD。

推理过程中，Router 决定哪些专家参与计算；Colibrì 先检查它们是否已在高速缓存，未命中的部分才临时从 SSD 读取。这一思路被作者类比为「针对模型权重的 JIT」。

分层缓存与预取

如果每个 token 都从 SSD 读取，速度会非常难看。Colibrì 在作者那台 12 核 CPU + 25GB RAM 的开发机上，冷缓存状态下生成速度仅约 0.05–0.1 token/s。为此，项目构建了一套 VRAM / RAM / NVMe SSD 的分层内存系统，原则是「越常用的专家，住得越近」。

关键优化包括：

LRU 缓存：最近被调用的专家优先保留在 RAM；
使用频次统计：高频专家获得更高优先级，倾向于留在更快存储层；
跨层预取：项目测试显示相邻层专家路由的可预测性达 71.6%，Colibrì 会在当前层计算时后台预读下一层可能需要的专家，使 I/O 与计算重叠；
多盘并行：若机器装有两块 SSD，可放置第二份模型副本，分摊读取带宽。

这一整套设计被作者称为「AI memory multitiering，AI 内存多层化」。一个重要原则是：专家放在哪里只影响速度，不改变模型本身，Router 决策和权重精度均保持一致。

覆盖模型与性能

Colibrì 目前覆盖 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。

不同硬件下的解码速度大致如下：

12 核 CPU + 25GB RAM 冷缓存：约 0.05–0.1 token/s；
128GB RAM 纯 CPU 桌面机：约 1.8 token/s；
6 张 RTX 5090 全专家常驻高速层：约 5.8–6.8 token/s。

以 Kimi K3 为例，权重约占 1.6TB 硬盘空间，但 RAM 仅需 32GB 起步，同样不强制要求 GPU。

上手与可视化

Colibrì 提供 Linux、macOS、Windows 预编译版本，源码编译只需 gcc/clang 加 OpenMP。以 GLM-5.2 为例，准备好项目程序和约 372GB int4 模型后，执行 coli chat 即可对话。

Web Dashboard 可实时查看 Token 生成速度、各阶段耗时，以及当前有多少专家驻留在 VRAM、RAM、磁盘。项目还专门做了一个「Brain」页面，将 GLM-5.2 的 19456 个专家全部可视化，可以直观看到每个专家被 Router 点名的情况、所处存储层和调用热度。

「Tiny engine, immense model」，Colibrì 想做一只胃口不小的蜂鸟，让前沿大模型不必非得跑在机房里的专业服务器上。