Colibri – 让你的电脑上可以跑GLM5.2大模型

2026 年，大模型用户的格局大概是这样：用 ChatGPT/Claude 的不用操心硬件，用 Ollama 跑 7B-70B 的有一张消费级显卡。但 744B 参数的模型？那是大厂机房的事，跟个人用户没关系。

Colibri 说：不一定。

它用纯 C 写了一个 MoE（混合专家）推理引擎，零运行时依赖，能让 GLM-5.2（744B 参数）在 25GB RAM 的消费级机器上运行。不是云端集群，不是 A100，是你手头那台 32GB 内存的台式机或者笔记本。

当然速度跟 GPU 集群没法比 ——25GB 机器上冷启动约 0.05-0.1 tok/s，6× RTX 5090 上跑 5.8-6.8 tok/s。但”能跑”和”不能跑”之间的差距，比”跑得快”和”跑得慢”之间的差距大得多。

客户端：Win+Mac+Linux

核心思路：把参数当数据，不是当状态

传统大模型推理有一个默认假设：模型必须全部装入内存/显存才能推理。 这个假设成立的前提是显存够大。对于 744B 参数的模型（即使是 int4 量化的版本也接近 400GB），一台机器显然装不下，所以用户只能选择：

• 不跑（放弃）
• 买更多 GPU（成本高）
• 用 API（数据上云）

Colibri 的解法是：不把参数常驻内存，而是按需从磁盘流式加载。

这听起来像很简单——把模型放磁盘，用到哪层读哪层。但实际上 MoE 模型的推理路径不是线性的：每一层有数千个专家，路由器会从中间选出 2-3 个最相关的专家来处理当前的 token。如果每次都要从磁盘随机读取几个专家权重，磁盘 I/O 的延迟会让推理变成龟速。

Colibri 的创新在于解决了”随机读取 + 实时推理”这对矛盾。它用了几层优化：

PILOT 预取。 路由器在推理当前层时，可以超前一层预测下一层可能激活哪些专家。实验表明预测准确率达 71.6%。提前把预测的专家从磁盘加载到缓存，下一层实际需要的时候就不用等磁盘了。

批量去重。 如果是批量推理（同时处理多个 token），同一层可能激活相同的专家。Colibri 对同一专家只从磁盘加载一次，所有用到这个专家的 token 共享。

异步 I/O 池（PIPE）。 计算当前专家的同时，后台异步加载缺失的专家。I/O 和计算流水线化，不互相等待。

LRU 缓存 + 学习型热存储。 每层维护最近使用专家的缓存。同时记录了用户工作负载中使用频率最高的专家，自动”固定”在内存中——比如你一直在问编程问题，跟代码相关的专家就会常驻内存。

双 SSD 镜像。 在两个 SSD 上存储模型副本，聚合读取带宽。两块普通 NVMe SSD 同时读，带宽翻倍。

所有优化叠加下来，在 128GB CPU 桌面上预热后可以达到约 1.8 tok/s——不快，但能用了。

工程实现上的几点观察

纯 C 实现，零依赖。 整个引擎核心是一个单文件 glm.c，加上几个运行时头文件。不需要 CUDA（可选后端）、不需要 Python（启动器是 Python，但引擎本身不依赖）、不需要任何第三方库。这在 2026 年的大模型推理项目里几乎是绝无仅有的——主流的 llama.cpp 是 C++，vLLM 是 Python，TensorRT 是 C++ + CUDA。纯 C 意味着：

• 编译只需要 GCC/Clang + OpenMP
• 可移植性极强（支持 Linux/macOS/Windows）
• 二进制体积极小（跟依赖一个”Web 框架”不是一个量级的概念）

完整的工具链。 虽然引擎是 C，但项目提供了完整的 Python 工具链：CLI（./coli chat）、OpenAI 兼容 API 服务（./coli serve）、Web 仪表板（./coli web，实时 token 指标、专家热力图、3D 专家图谱）、Tauri v2 桌面应用。C 引擎做性能敏感的部分，Python/JS 做用户交互的部分——分工清晰。

模型权重开源。 GLM-5.2 的 int4 量化权重（约 372GB）在 Hugging Face 上以 MIT 许可证发布。这是整件事情能成立的另一个关键——”能跑 744B 模型”的引擎有了，模型本身也是开源的，用户可以合法下载和部署。

跟同类对比

这个品类目前最知名的项目是 llama.cpp——同样是本地推理引擎，C++ 实现，社区庞大。但 llama.cpp 的设计目标是”在本地硬件上跑尽可能多的模型”，它的前提假设仍然是”模型装入内存/显存”。对于超大规模的 MoE 模型，llama.cpp 的内存需求跟模型参数直接相关——744B 的模型即使量化也需要 200GB+ 内存。

Colibri 直接把这个假设打破了：内存不需要装下全部参数，只需要装下当前推理路径需要的部分。 这不是优化，是架构路径的不同选择。

代价也很明显：速度。llama.cpp 在 70B 模型上能做到 10+ tok/s（单卡 4090），Colibri 的 1.8 tok/s 在 CPU 上大约只是前者的五分之一。但对于一个”如果你不这么做完全不可能跑”的模型来说，1.8 tok/s 是可用的。

适用场景

如果你手上有普通的 PC 硬件，想跑一下 744B 的 GLM-5.2——Colibri 是目前唯一的选择。1.8 tok/s 的速度不快，但足以做对话、文档分析、代码生成这类不需要实时响应的任务。

模型的存储需要约 372GB（int4 量化），需要一块够大的 NVMe SSD。建议使用双 SSD 镜像配置以获得更好的读取带宽。

注意： 项目非常年轻（v1.1.1，2026 年 7 月才发布 v1.0.0），API 和接口还在快速变化中。同时只支持 GLM-5.2 和 OLMoE 等有限型号，计划支持 Kimi K2、Qwen3 MoE 和 MiniMax。

Colibri 让我想到了 llama.cpp 刚出现时的感觉——让”不可能在本地跑”的东西变成”虽然慢但能跑”。如果说 llama.cpp 把大模型的部署门槛从数据中心降到了桌面，Colibri 则把这个门槛降到了”只要有磁盘空间”。

纯 C 写、零依赖、25GB 内存跑 744B 模型——这个成就在工程上很硬核。如果你好奇千亿参数模型在这个笔记本上能跑成什么样，Colibri 是现在最好的入口。

GitHub: https://github.com/JustVugg/colibri
模型权重: https://huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp
文档: https://justvugg.github.io/colibri