Colibrì: 在消费级硬件上运行 GLM-5.2 744B MoE

Colibrì 使能够在仅有约 25 GB RAM 的消费级硬件上运行具有 744B 参数的 GLM-5.2 Mixture-of-Experts (MoE) 模型。它通过仅将模型的密集部分保留在内存中，并根据需要从磁盘流式传输路由专家（routed experts）来实现这一目标。

架构：流式 MoE 与内存管理

Colibrì 利用了 Mixture-of-Experts 模型的架构特性，即每个 token 仅激活总参数的一小部分。对于 GLM-5.2，虽然模型拥有 744B 参数，但每个 token 仅激活约 40B 参数，且在 token 之间仅有 11 GB 的参数（即路由专家）会发生变化。

Resident RAM：密集组件——包括 attention、shared experts 和 embeddings（约 17B 参数）——以 int4 量化格式存储并保留在 RAM 中，占用约 9.9 GB。
Disk Storage：21,504 个路由专家（int4 量化下每个约 19 MB）存储在磁盘上，总计约 370 GB。

为了减轻磁盘 I/O 的延迟，Colibrì 实施了多种优化策略：

LRU Cache：通过每层 Least Recently Used (LRU) 缓存来管理专家在 RAM 中的驻留情况。
Async Readahead：引擎使用 WILLNEED 在 CPU 处理当前数据块时预读下一个专家数据块。
Learning Cache：引擎将专家路由模式记录在 .coli_usage 文件中，从而允许在启动时自动将最频繁使用的“热”专家固定在剩余的 RAM 中。
OS Page Cache：引擎利用操作系统页面缓存作为第二层缓存机制。

Colibrì 使用纯 C 编写（glm.c 中约 1,300 行代码），零依赖，避免了使用 BLAS、Python（运行时）和 GPU 加速。

MLA Attention：实现了带有压缩 KV-cache 的 Multi-head Latent Attention (MLA)，将每个 token 的内存需求从 32,768 个 float 降低到 576 个 float（降低了 57 倍）。
MTP Speculative Decoding：使用 GLM-5.2 原生的 Multi-Token Prediction (MTP) head。当该 head 被量化为 int8 时，其接受率可达 39–59%，从而在每次前向传播中实现 2.2–2.8 个 token 的生成速度。
Integer-Dot Kernels：利用 AVX2 maddubs 进行 int8 矩阵乘法，速度比标准实现快 1.4–2.5 倍。
Weight Absorption：在解码过程中采用 DeepSeek 风格的 MLA 权重吸收技术，以消除每个 token 的 k/v 重构过程。
Quantization：支持 int8、packed int4 和 packed int2 内核，具有逐行缩放（per-row scales）和使用时解量化（dequantization-on-use）功能。

性能主要受限于磁盘读取速度（即“磁盘瓶颈”）。一个冷启动 token 需要约 11 GB 的专家读取量。

由于冷启动涉及大量的随机读取（约 11 GB/token），且操作系统页面缓存可能会产生写入，高强度使用可能会加速消费级 SSD 的磨损。建议用户监控驱动器健康状况。

虽然该架构在针对 transformers oracle 的 token 级别精确度验证上是合格的，但由于在消费级硬件上进行完整运行所需的时间极长，目前尚未对 744B 模型 int4 量化的具体精度损失进行全面基准测试。

用户间的讨论突出了流式方法的概念性卓越与实际局限性：

"在小内存机器上，限制因素是 RAM 容量，而非磁盘，... --topp 0.7 单独就带来了 1.6 倍的端到端速度提升。"

一些用户质疑低于 1 token/s 的速度在实际应用中的效用，而另一些人则认为对于长时间运行的异步任务，这种速度仍然是可行的。社区的技术建议包括使用 RAID0 NVMe 阵列来增加带宽，或利用 Intel Optane 内存来弥补 SSD 与 RAM 速度之间的差距。