Colibri 是一个纯 C 语言编写的 GLM-5.2 推理引擎，零外部依赖，目标是在 25GB 内存的消费级设备上运行 744B 参数的 MoE 模型。核心思路是利用 MoE 架构的特性——每次推理只激活一小部分 expert——将 idle expert 保存在磁盘上，按需流式读入内存，突破传统显存/内存限制。
从部署角度看，Colibri 提供了一条不一样的路径：不需要 GPU 集群、不需要量化裁剪、不需要 512GB 系统内存，一台 25GB RAM 的普通笔记本就能运行 GLM-5.2 推理。磁盘流式读入的延迟当然比纯显存推理高，但对开发调试、离线 batch、原型验证这类场景来说，这个权衡是划算的。
（配图：Colibri 项目的 GitHub README 截图，展示纯 C 实现的推理引擎运行 GLM-5.2 的效果）
技术亮点：
- 纯 C 实现，零外部依赖——不需要 Python、PyTorch、CUDA 运行时
- mmap-based expert lazy loading，只在推理需要时从磁盘读入特定 expert
- MoE expert 调度优化，利用 expert locality 减少磁盘 I/O 次数
- 支持 GLM-5.2 完整推理流程，无需额外转换步骤
对部署团队的意义不只是在笔记本上跑大模型。纯 C + 零依赖意味着边缘设备（树莓派、NAS、工控机）上也能部署；磁盘流式读入意味着模型规模不受物理内存限制，只受磁盘容量约束。当一个 744B 的 MoE 模型能以这种形式在消费级硬件上运行时，API 推理服务的定价压力会越来越大。
内容来源
Colibri 项目 GitHub：JustVugg/colibri（当前 1780 star）
HN 讨论帖：Show HN: Getting GLM 5.2 running on my slow computer（800+ points）
GLM-5.2 官方发布：Zhipu AI 开源 MIT 协议的 GLM-5.2
这个 Colibri 的思路很有意思——expert 级别的磁盘流式读入，粒度比 llama.cpp 的层级别 offloading 更细。如果有 benchmark 对比就好了。
2 个赞
744B 参数、MoE 架构、纯 C 推理，这三个标签放一起就很说明问题：推理优化已经从框架层卷到内存管理层了。Colibri 的核心思路是让磁盘当 VRAM 用，虽然延迟比纯显存推理高，但对没有 GPU 集群的团队来说，这是目前接触前沿模型的唯一现实路径。
1 个赞
关键看 expert 交换的频率。MoE 推理时每个 token 激活的 expert 数量是有限的，Colibri 只在需要时才从磁盘读入特定 expert。如果 locality 好、缓存命中率高，实际延迟可能比想象的能接受。有个 benchmark 数据就更好了。
1 个赞
和 llama.cpp 的对比很有意思。llama.cpp 走的是 mmap 映射 + CPU 推理路线，对 MoE 模型的支持主要是 offloading 到系统内存。Colibri 用纯 C 从头写、零依赖，内存 footprint 更激进。一个 744B 的 MoE 能在 25GB 设备上跑，说明它在 expert 调度层面做了不少优化。
这个方向如果成熟了，对 API 定价的冲击会很大。现在 GLM-5.2 通过 API 调用的价格大约是 $0.90/M token，自建推理（哪怕是用 Colibri 这样偏慢的方案）的边际成本基本只有电费。问题在于throughput——单机磁盘流式推理的 QPS 肯定远低于集群推理，能不能承载生产流量是个问号。
刚看了下 Colibri 的实现，它用 mmap 做 expert 的 lazy loading，每个 expert 约 1-2GB。GLM-5.2 有 744B 参数、约 280 个 expert，每次推理只激活其中 3-4 个。所以理论峰值显存需求其实只要 6-8GB，但 idle 的 expert 可以放磁盘。这个思路和 Apple 的 Unified Memory 异曲同工——都是让大模型跑在内存/磁盘的交换层上，只是 Colibri 把粒度做到了 expert 级别。
部署场景：适合开发调试、离线推理、批处理任务。不适合在线服务。但对创业团队来说，先用 Colibri 在本机验证模型效果、做 prompt 工程，确认方向后再上集群推理，这个工作流是成立的。零依赖 + 纯 C 也意味着在边缘设备（树莓派、NAS、工控机）上部署的可能性。