colibrì：把 744B 模型当数据流流到 25GB 的笔记本上跑——纯 C 写的 MoE 推理引擎

作者

看到 colibrì（意大利语的”蜂鸟”）这个名字的时候，我第一反应是又一个小巧的轻量推理工具。点进去才发现这个项目做的事情完全不是那么回事——它是一个纯 C 写的、零依赖的 MoE 推理引擎，目标是在 25 GB 的笔记本 RAM 上跑 744B 参数的 GLM-5.2。整个引擎单文件，glm.c 加几个头文件，没有 BLAS、没有 Python runtime、没有 GPU 也能跑。

我装了个 Mac mini M4（16 GB），平时跑不动什么 70B 以上的模型，官方文档里恰好列了 Metal 后端的实测数据——M4 Max 是 0.42 tok/s，M5 Max 加 47 GB 学习缓存能到 2.06 tok/s。这件事最打动我的是它处理”跑不动“这件事的思路：不要求模型塞进显存/内存，而是把模型当成要按需搬到计算边的数据流。这条思路可以聊的太多。

dash

官方 Web 控制台：744B 模型在 6× RTX 5090 上跑，4.0 tok/s、TTFT 1.6 s、disk 0（专家全驻留）

它的核心判断：MoE 模型不需要”装得下”

思路其实很直观。一个 744B 的 MoE 模型（GLM-5.2 是 75 层 MoE × 256 路由专家 + MTP 头），每个 token 真正激活的只有约 40B 参数，而真正会在 token 之间换进换出的部分只有约 11 GB（路由专家）。也就是说 99% 的权重在大部分时间里是”死的”。

sparse

每 token 实际激活的只有 ~5.4% 参数

colibrì 干脆把这个观察做成了设计：

  • dense 部分（attention + shared experts + embeddings，约 17B 参数）常驻 RAM，int4 后 ~9.9 GB；
  • 19,456 个路由专家（每个 ~19 MB int4，共 ~370 GB）住在 SSD 上，按需流式读取；
  • 外加一层可选的 VRAM 显存 tier，给有 GPU 的主机当热缓存。

官方把这套机制类比成 “权重的 JIT”——传统编译器不会把整个程序全部编译完，它盯着热点路径，”just in time”地把正在跑的代码编译到机器码。colibrì 同样的判断下到参数空间：参数不是常驻状态，而是要按需跨 VRAM / RAM / NVMe 三层缓存分阶段搬运的数据。路由是可测量的结构，结构就可缓存——你跑得越多，最常被路由到的那批专家就被你跑热了。

tiers

三层 memory hierarchy：VRAM / RAM / NVMe，同一组权重只决定速度，不决定语义

几个关键工程动作

光有分层不够，磁盘访问的延迟是几百微秒级别，CPU 一算就是几十毫秒，常规做法等一次 I/O 就慢死了。colibrì 的几个解法：

  • Batch union：同一批 batch 里只对去重后的 expert 读一次，每个 expert 的三个矩阵（gate / up / down）相邻存，一次 pread 读完；
  • PIPE / PILOT 双流水线：异步 I/O 池在算的同时预取下一批缺失的 expert；同时路由是可预测的，官方实测”71.6% 一层可预测“，所以可以一层提前预取；
  • 学习缓存：每个 turn 把路由到的 expert 写进 .coli_usage，引擎自动 pin 最热的几个，越用越快；
  • Dual-SSD：expert 只读，所以把模型完整复制到第二块盘，按带宽比哈希分流到两块盘上各读各的，9 GB/s + 3 GB/s 的组合官方实测比单盘快 ~33%。可以”部分镜像”，第二块盘放不下全模型也行——它会按已学到的路由历史挑最热的 shard 放上去；
  • KV 压缩 57×：MLA attention 的 KV state 每 token 只用 576 个 float（不是 32768），并且写到 .coli_kv，对话重开零 prefill，逐字节相同于不中断的会话。

在我机器上能跑多快？

官方发布的同引擎、同 int4 模型在不同硬件上的实测速度（greedy decode）：

ladder

同一个引擎，同一个 int4 模型——只换硬件，区别只是专家住哪里

换句话说，一块 SSD + 25 GB RAM 也能跑得动 744B，只是 0.05–0.1 tok/s 这种”打字员都比你快”的水平。Mac 这边 Metal 后端是实验性的，文档里给的数据是：

  • M4 Max（128 GB, 热缓存, MTP on）：CPU 0.30 → Metal 0.42 tok/s（~1.4×）。打开 DIRECT=1 再快一些，对比这台机器的冷启动 ~3×。
  • M5 Max（带 46.9 GB 学习缓存）：2.06 tok/s。

16 GB Mac 想跑 int4 GLM-5.2 dense 部分（~9.9 GB）就装不下，所以官方文档对 Apple Silicon 这一档写的是”experimental”。但 7B 的 OLMoE、Inkling 在更小 RAM 上有专门的 dense 量化工具——文档里明确写了”Inkling 在 RAM 紧张的主机上要先把 dense 部分 int4 量化到 15.3 GB 才行，且 trade-off 都写在文档里”。这种把局限直接写出来、不做模糊承诺的态度，是这个项目让我觉得很舒服的一点。

我看到的几个坑（没踩实，但文档/issue 写得明明白白）

  • 别下错 int4 容器。Hugging Face 上有老版”per-row int4″（mateogrgic/...、jlnsrk/...），质量约差 9pp，是早期 think-mode 循环输出的根因。要用官方的 gs64 group-scaled + int8 MTP head 的那个。
  • MTP head 必须是 int8。int4 头在实测中草稿接受率会掉到 0–4%。检查方法：ls -l <model>/out-mtp-*，int8（正确）的文件大小是 3527131672 / 5366238584 / 1065950496。
  • MTP 不是银弹。在 expert hit rate 85% 附近，MTP 实测有 ~32% 的 regression，文档明确写了——投机解码在不热的时候是亏的，要 DRAFT=0 关掉。
  • DIRECT=1 不一定赢。O_DIRECT 在带 DRAM cache 的 NVMe 上是大赢（实测 +34% decode），但在 QLC、DRAM-less、虚拟盘上可能是中性甚至负值。要先试再留。
  • Metal 后端 prefill 的浮点精度。Decode 是 byte-identical 的，但 prefill 大 GEMM 在 GPU 上跑会换累加顺序，在 teacher-forced oracle 比较的极端 case 里可能挑不同的 top token。文档建议 COLI_METAL_GEMM_MIN=100000 把所有 GEMM 留在 CPU 上保持 bit-exact。
  • 镜像不是双写。COLI_MODEL_MIRROR 启动时校验大小和 safetensors header 一致；中途拔第二块盘会回退到主盘（一次警告，不崩）；镜像永远是只读的。
  • KV 压缩不影响 forward。forward pass 用 transformers oracle 验证（teacher-forcing 30–32/32），量化版本和原版在采样路径上 token-exact。

这项目值不值得装

如果你是 16 GB Mac mini 这种配置，答案是直接装模型的人不用纠结——目前 OLMoE（7B / 1B 激活）才是这一档的甜点，744B GLM-5.2 你跑不快也跑不满。但你可以装上这个引擎，看它的 Web 控制台 + Brain + Atlas 三页的”专家图谱“——Atlas 把 13260 个被测过路由行为的 expert 画成 3D 星系，位置是实测的路由亲和度、不是学出来的 embedding。鼠标 hover 能看每个 expert 的主题偏好。我看到 poetry、law、Chinese、SQL 这些聚类已经自动散开了。这是这个项目最迷人、最不像传统推理引擎的一面。

atlas

官方 Atlas 页：13,260 个被测过路由行为的专家，按实测路由亲和度散成 3D 星系，能看出 poetry、law、Chinese、SQL 等主题聚类

如果你是 128 GB 内存 + 一块 SSD 的桌面用户，答案是很值得——1.8 tok/s 的 GLM-5.2 跑 chat 是能用的，而且这是个能让你”用着跑”的项目：每条消息都会让你更热的那批 expert 进 RAM，越聊越快。

如果你是多 GPU 主机用户，v1.4.0 刚出的 Vulkan 后端把 7× AMD RX 580 这种官方已经放弃的卡都纳入了（ROCm 不支持），还能在 RDNA4 上和 ROCm 拼一下。Vulkan 不绑驱动，是这个项目的另一个有意思的赌注。

brain

官方 Brain 页：19,456 个专家当作成活的脑皮层，颜色是存储 tier、亮度是路由热度，每一轮路由到的专家会闪白

安装备忘

步骤极简：

# 1. 下载对应平台的 release，解压
mkdir colibri && tar xzf colibri-*.tar.gz -C colibri && cd colibri
python3 coli info

# 2. 下模型（372 GB int4 gs64 + int8 MTP 头）
# https://huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp

# 3. 跑
COLI_MODEL=/nvme/glm52_i4 ./coli chat
COLI_MODEL=/nvme/glm52_i4 ./coli web      # 起 API + Web 控制台

# Mac 加 Metal 后端
cd c && make colibri METAL=1
COLI_METAL=1 COLI_MODEL=/path/glm52_i4 ./coli chat --ram 96

License 是 Apache 2.0，模型权重遵循各自上游的协议（GLM-5.2 是 MIT）。

小结

我对这个项目的态度比预想更正面。三件事做得对：

  • 把假设标得清清楚楚。每条优化都附了证据 + “this is what we still need to test”，连 MTP 那个 32% regression 都写在显眼位置；
  • 把分阶段搬运的思路讲透了。从 dual SSD 到 partial mirror，从 RAM 紧张时降密到 KV 压缩，都是”约束先承认，再想办法绕”；
  • 把工具做成了研究平台。Atlas 那一页不是漂亮就完事——它是路由结构有可测规律的实证，”structure is cacheable”这个判断不能空口说，得画出来给读者看。

2026 年开源大模型真正进入”本地推理“这个话题时，硬件门槛已经不是”你有多少显存”，而是”你愿不愿意把存储 / 内存 / 显存当作一个分层的数据流”。colibrì 这个项目把这个思路执行到了我目前看到的最硬核的程度——而且它今天就能装、今天就能跑。

—— 等我那块 SSD 到货了再实测一次 M4 Mac 上的 Metal decode。

仓库：github.com/JustVugg/colibri ｜ 模型：huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp

发表评论