- 引言 — 用 25GB 内存的笔记本跑 744B 模型？
- 核心技巧 — MoE 稀疏性 + 磁盘流式加载
- 让它变得可以忍受的那些装置
- 诚实的部分 — 那么它到底有多快
- 结语 — 在"能跑"与"好用"之间
- 参考资料
引言 — 用 25GB 内存的笔记本跑 744B 模型？
colibrì 是一个以在普通消费级 PC 上运行 GLM-5.2 为目标的推理引擎。按 colibrì 的说法，GLM-5.2 是一个总参数 744B（7,440 亿）的 MoE 模型。通常这种规模需要多张 GPU 和数百 GB 的 VRAM。而 colibrì 却在一台 12 核 CPU、25GB 内存的机器上把它跑起来。纯 C 写成、约 1,300 行，运行时依赖为零 — 既没有 BLAS，也没有 Python。
当然，这不是免费的。项目所标榜的目标本身就不是速度。概括起来就是"让 GLM-5.2 在 12 核笔记本、25GB 内存上给出正确的答案，哪怕速度要以每段落几分钟来计"。本文诚实地审视 colibrì 实际做了什么、靠什么样的技巧让它成为可能，以及它到底有多实用。
核心技巧 — MoE 稀疏性 + 磁盘流式加载
两个事实咬合在一起。
第一，GLM-5.2 是 MoE。生成一个 token 时，激活的不是全部 744B，而只有约 40B。参数被细分成一个个"专家（expert）"，每个 token 由路由器只挑选与输入匹配的少数几个来用。在 colibrì 的构建中，路由专家共有 21,504 个（75 个 MoE 层 × 256 个），用 int4 表示时每个约 19MB。
第二，正因如此，没必要把全部都放进内存。colibrì 把模型一分为二。
- 密集（dense）部分 — 注意力、共享专家、嵌入，约 17B。压缩成 int4 后，只把 9.9GB 常驻内存。
- 路由专家 — 约 370GB（int4 容器）。放在 NVMe SSD 上，每个 token 只读取需要的部分。
也就是"庞大的模型，小巧的引擎"。每个 token 的瓶颈不是计算，而是磁盘读取 — 冷启动状态下，每个 token 要从 SSD 读约 11GB（75 层 × 8 个专家）。这个磁盘带宽决定了速度的上限。
让它变得可以忍受的那些装置
磁盘流式加载本质上就是慢的。colibrì 有意思的地方，在于它啃掉这份慢的那些办法。
- 学习缓存（learning cache） — 每一轮都把实际使用中哪些专家被频繁调用记录到
.coli_usage，下次启动时把那些"热"专家预先固定（pin）到空余的内存里。也就是说用得越多越快，还能用--repin在会话中做实时的重新分配。 - MTP 投机解码 — 用 GLM-5.2 的 multi-token prediction 头预先抛出多个 token，再一次性验证。以 int8 头计，每次 forward 有 2.2–2.8 个 token，实测接受率 39–59%。若把头降到 int4，接受率会崩到 0–4%，所以只把这个头保持在 int8。
- 压缩 KV 缓存 — 每个 token 只用 576 个 float，比原来的 32,768 小 57 倍。即便重启引擎，对话也能以 warm 的状态延续。
- 异步预读与批次合并 — 在乘一个块的同时预读下一个块，同一批次里相同的专家只读一次。
量化是这一切的底座。int4 容器配 per-row 缩放，在 AVX2 内核里 dequant-on-use。量化综述文章里讲过的"减少比特数来换取内存和带宽"这场仗，在这里原封不动地延续为"减少要从磁盘读取的字节数"。
真要跑起来，硬件下限如下，入口模式共有四种。
# 硬件下限 (依据 README)
OS: Linux 或 WSL2 CPU: AVX2, 12 核以上
RAM: 16GB 以上 (缓存自动上限, 峰值约 20GB)
Disk: 约 370GB 本地 NVMe (ext4) — 不支持网络挂载
# 运行模式
./coli chat # 交互式 CLI
./coli serve # OpenAI 兼容 API (仅文本)
./coli bench # MMLU / HellaSwag / ARC
./coli plan # 只读取头部的 dry run, 零分配
诚实的部分 — 那么它到底有多快
慢。冷启动状态约 0.05–0.1 tok/s — 实际上 10~20 秒才蹦一个词。光是加载就要约 30 秒。社区上报的实测数据随硬件而异：M5 Max（128GB）1.06 tok/s，Framework 13（128GB + 学习固定）0.37 tok/s，装了 PCIe5 NVMe 的 9950X 0.28 tok/s。就算最好的情况，也不过每秒一个 token 出头。
这不是一个交互式工具。一个段落要花上几分钟。那么，什么时候用它呢？
- 云不可用或被禁止的场合 — 离线、气隙（air-gap）、受监管的环境。
- 隐私是绝对前提时 — 数据绝不能离开这台机器的情况。
- 不想买硬件、只想试一试时 — 想在一台老旧台式机上亲眼确认 744B 模型的输出。
如果你需要生产级的吞吐量，答案很明确：老老实实分配 GPU。colibrì 本来也没打算取代它 — 你可以用 ./coli serve 开一个 OpenAI 兼容 API，但那种速度撑不起真实的服务流量。
结语 — 在"能跑"与"好用"之间
colibrì 真正有意思的地方不是速度，而是它得以成立这件事本身。曾被认为"没有 GPU 就不可能"的规模，如今靠 MoE 稀疏性 + 磁盘流式加载 + 聪明的缓存，在一台 25GB 内存的机器上好歹能给出答案。"能跑"和"好用"确实是两码事，但只有先证明了"能跑"，"好用"才会随后跟上。
本地推理的民主化大多是按这个顺序到来的 — 先是"疯是疯了点，但真能跑"，然后花上几年变成"现在真的挺实用"。llama.cpp 当初也正是这样起步的。colibrì 如今走到了哪一步，上面那些数字诚实地给出了答案。即便如此，想象每段落几分钟变成每句几秒的那一天，也并不算太难。