推理优化教程

2.1 万 Star 的“硬盘炼金术”：25GB 内存，真的跑起了 7440 亿参数模型（GLM-5.2 ）

yiwan-cat2026-08-01 23:40

最近 GitHub 上冒出一个很反常识的项目：colibri。

它不训练模型，也不做新的量化算法榜单，而是干了一件更直接的事：让原本需要服务器级硬件的超大 MoE 模型，在普通电脑上真正完成推理。

最出圈的案例，是把 744B（7440 亿）参数的 GLM-5.2 放到一台只有约 25GB 内存的消费级电脑上运行。没有足以装下整个模型的 GPU，也不要求数百 GB 内存。模型权重主要待在 NVMe 硬盘里，需要哪个专家，就临时把哪个专家读进来。

先说结论：它确实能跑，但“能跑”和“好用”是两回事。

25GB 开发机的冷启动解码速度只有约 0.05～0.1 token/s，更多是在证明技术路线可行；如果想让它承担日常任务，128GB 内存或 GPU 才是更现实的起点。真正有意思的，也不是“低配电脑秒变 AI 服务器”，而是 colibri 把硬盘、内存和显存重新组织成了一套统一的推理系统。

项目地址：https://github.com/JustVugg/colibri

这到底是个什么项目？

colibri 是一个面向 MoE 大模型的本地推理引擎。核心引擎使用纯 C 编写，不依赖 BLAS，运行时不需要 Python，也不强制要求 GPU；Python 主要用于启动器、模型转换工具和 OpenAI 兼容 API 网关。

它的设计目标可以浓缩成一句话：

高速内存不够，可以慢；但不能因此偷偷改变模型的路由逻辑和精度策略。

项目最初围绕 GLM-5.2 构建，如今同一套前端已经扩展到 GLM-5.2、Inkling、Kimi K3 和 OLMoE 等模型家族。其中 Kimi K3 的引擎与 tokenizer 已通过回归验证，但截至本文写作时，官方仍把它标为预览状态：完整的 2.8T 模型快照需要约 1.6TB 存储，尚未完成一次公开的全模型端到端生成验证。

也就是说，colibri 不是一句“什么大模型都能低配运行”的营销口号。哪些模型已经跑通、哪些仍处于预览，官方区分得很清楚。

7440 亿参数，为什么不必全部塞进内存？

关键在 GLM-5.2 的 MoE，也就是“混合专家”结构。

它虽然共有约 744B 参数，但生成一个 token 时，并不会让全部参数一起参与计算。路由器会从每层 256 个专家中选出 8 个，因此每个 token 实际激活的参数约为 40B，只占总参数量的约 5.4%。

更重要的是，相邻 token 之间真正发生变化的专家权重只有约 11GB。colibri 抓住的就是这点：既然大多数专家此刻都不会被用到，就没必要让它们一直占着昂贵的高速内存。

它把模型拆成两部分：

注意力、共享专家和嵌入层等稠密部分，约 17B 参数，int4 后约 9.9GB，常驻内存；
19,456 个路由专家留在磁盘上的约 370GB 模型容器中，按路由结果流式加载。

这不是把 370GB 模型“压缩成 25GB”，而是把完整模型的存放位置从单一内存，改成了 NVMe、RAM、VRAM 三层共同承担。

它把硬盘、内存和显存当成同一套系统

传统推理框架通常先问：“模型能不能装进显存或内存？”

colibri 换了个问法：“每个专家应该住在哪一层？”

如果只有 25GB 内存，大部分专家就从硬盘现读，速度很慢，但仍能完成推理；如果有 128GB 内存，更多热门专家可以常驻 RAM；如果有多张 GPU，最常用的专家可以进一步放进 VRAM，减少磁盘读取。

硬件没有决定“能不能运行同一个模型”，而是决定每个专家住在哪里，以及每秒能生成多少 token。

每生成一个 token，colibri 做了什么？

官方把每层的处理过程概括成五步：Route、Union、Place、Overlap、Learn。

图　colibri 官方源工程图：路由、合并、放置、读算重叠与使用历史学习。

第一步，路由器给 256 个专家打分，只保留 top-8。

第二步，如果当前批次中多个位置选中了同一个专家，先求并集。同一个专家只从硬盘读一次，避免重复 I/O。

第三步，检查专家的位置。命中 VRAM 或 RAM 就立即计算；没有命中，才从 NVMe 流式读取。

第四步，把读取和计算重叠起来。常驻专家正在计算时，异步 I/O 池已经开始读取缺失专家；前瞻线程还会预测下一层可能用到的专家。官方报告称，提前一层预测路由的可预测率达到 71.6%，但也明确提醒：预取并不保证在所有机器上都能提速。

第五步，记录这轮对话使用了哪些专家，更新热门集合。重复负载下，常用专家会逐渐被固定到更快的层级，因此项目所说的“越用越快”并不是模型变聪明了，而是缓存越来越了解你的负载。

真正厉害的不是“硬盘当内存”，而是尽量不等硬盘

只把专家扔进硬盘并不难，难的是不能让 CPU 或 GPU 一直停下来等盘。

colibri 为此做了几件很工程化的事：

每个专家的三组矩阵连续存放，尽量用一次 pread 读完；
默认开启有界异步 I/O 管线，让读取与常驻专家计算重叠；
批量推理时先合并专家集合，避免同一专家反复读取；
支持 O_DIRECT，在适合的磁盘上绕开页缓存；
支持双 SSD 镜像或分片，把独立磁盘带宽叠加起来；
通过学习型固定区保存高频专家，而不是只靠普通 LRU。

不过 colibri 的态度很克制。它把很多优化称作“待验证的假设”，而不是无条件成立的性能承诺。例如，路由历史可能对某类 prompt 过拟合；双 SSD 理论上增加带宽，但仍要看磁盘是否位于独立控制器；强 CPU 与低专家驻留率也可能让 GPU 流水线收益消失。

这反而是我认为项目最可靠的地方：它不只展示最快数字，也公开哪些优化可能负收益。

网页面板把 MoE 的内部活动摊开给你看

运行 ./coli web 后，colibri 会同时启动 OpenAI 兼容 API 和网页控制台。页面不仅能聊天，还会显示 token 速度、首 token 延迟、任务队列、VRAM/RAM/磁盘占用，以及每轮时间究竟花在矩阵乘、注意力还是磁盘读取上。

图 1　colibri 官方源工程图：Web 控制台。图中的 4.0 tok/s 来自 6×RTX 5090 全专家驻留环境，不能代表普通电脑速度。

Brain 页面更像一张实时“专家皮层图”。GLM-5.2 的 19,456 个专家被画成密集网格：颜色表示专家位于 VRAM、RAM 还是磁盘，亮度表示历史路由热度，本轮命中的专家会短暂闪白。

图 2　colibri 官方源工程图：Brain 页面可视化专家层级与路由热度。

Atlas 页面则把 13,260 个已分析专家投影成一个可旋转的 3D 星系。官方数据中，1,041 个可复现的专门专家会围绕诗歌、法律、中文、SQL、Python 等主题形成聚集。

图 3　colibri 官方源工程图：Atlas 页面展示基于实测路由亲和度形成的专家主题图谱。

对普通用户来说，这两个页面很好看；对研究 MoE 的人来说，它们更有价值，因为你终于可以在不租用整套数据中心硬件的情况下，直接观察模型到底把不同内容路由给了哪些专家。

KV 缓存也被压到了硬盘里

大模型长对话不只消耗权重内存，KV cache 同样会持续增长。

GLM-5.2 使用 MLA 注意力后，colibri 为每个 token 保存 576 个浮点数，而不是 32,768 个，状态规模缩小约 57 倍。压缩后的 KV 状态还能持久化为 .coli_kv 文件。

因此，机器重启后可以恢复已有会话，不必从头重新 prefill；官方称恢复后的结果与不中断会话逐字节一致。这里压缩的是推理状态，并不是把模型偷偷换成更小的版本。

投机解码能加速，但别把它当免费午餐

GLM-5.2 自带 MTP head，可以先草拟 token，再由主模型一次前向验证多个候选。条件合适时，一次 forward 能接受约 2.2～2.8 个 token。

但这个功能有两个容易踩的坑。

第一，MTP head 必须保留 int8。使用 int4 时，草稿接受率可能掉到 0～4%，等于白白增加计算。

第二，接受率高也不等于端到端一定更快。官方记录过一次 expert hit 约 85% 时，开启 MTP 反而慢了 32%。所以 colibri 会把投机解码当成需要实测的选项；如果你的硬件与缓存状态不合适，直接设置 DRAFT=0 关闭更合理。

到底能跑多快？

图 4　colibri 官方源工程图：同一 int4 模型容器在不同硬件上的实测解码速度。

从官方与社区公开结果看：

硬件	GLM-5.2 解码速度
25GB 开发机，冷启动、主要从硬盘流式加载	0.05～0.1 tok/s
RTX 5070 Ti + 32GB 内存	约 1.07 tok/s
128GB 内存、纯 CPU 台式机，热缓存	约 1.8 tok/s
NVIDIA DGX Spark（GB10，121GB 统一内存）	约 3.3 tok/s
6×RTX 5090，专家全驻留	最高约 6.8 tok/s

所以“25GB 内存运行 744B 模型”是真的，但一分钟可能只生成 3～6 个 token。它适合证明可行性、研究路由和做不着急的离线任务，并不适合作为流畅聊天方案。

如果想达到相对可用的体验，我会把 128GB 内存或带大显存的 GPU 看作更现实的起点；如果只是 25GB 内存，NVMe 的随机读取性能、散热和耐心都很重要。

快速开始：注意旧教程里的模型地址已经过时

最省事的方式是从 Releases 下载 Linux、macOS 或 Windows 的预编译包。也可以从源码构建：

git clone https://github.com/JustVugg/colibri
cd colibri/c
./setup.sh

接下来准备 GLM-5.2 模型。官方当前推荐的是带 int8 MTP head 的 gs64 int4 容器，约 372GB：

mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp

一些较早文章使用的 mateogrgic/... 或 jlnsrk/... per-row int4 镜像已经不再是官方推荐项。README 给出的受控测试显示，旧镜像质量低约 9 个百分点，并可能引发 think-mode 循环或无法正常终止。照着旧教程部署时，这一点尤其要注意。

模型就位后，可以先检查资源规划，再启动聊天或服务：

COLI_MODEL=/nvme/glm52_i4 ./coli plan
COLI_MODEL=/nvme/glm52_i4 ./coli doctor
COLI_MODEL=/nvme/glm52_i4 ./coli chat

./coli web --model /nvme/glm52_i4
./coli serve --model /nvme/glm52_i4

serve 提供 OpenAI 兼容接口，支持自定义 OpenAI endpoint 的客户端可以把它当成本地后端。Windows 下则使用类似下面的写法：

python coli chat --model D:\glm52_i4

这个项目适合谁？

第一类，是研究 MoE 推理系统的人。

你可以直接观察专家路由、缓存热度、磁盘读取和分层放置，不必先准备一台能完整装下 744B 模型的机器。

第二类，是对数据本地化有强需求的团队。

合同、代码、内部文档不希望经过第三方 API 时，colibri 提供了一条完全本地的技术路线。当然，“本地”不代表“经济”：372GB 模型、NVMe、内存与电力成本仍要算清楚。

第三类，是愿意用速度换硬件门槛的玩家。

它允许你先用已有设备验证完整模型，再决定是否升级内存、增加 GPU 或布置第二块 SSD。

如果你只是想要一个开箱即用、响应迅速的聊天助手，colibri 目前并不是最省事的选择。运行小得多的稠密模型，往往会得到更好的交互体验。

我的看法

colibri 最值得关注的，不是“25GB 内存挑战 744B”这个标题，而是它提出了一种很朴素、却很有生命力的系统观：

模型不必全部住在最快的地方；只要知道下一刻需要什么，并让数据移动与计算尽量重叠，低配硬件也能参与前沿模型推理。

它没有消灭 744B 模型的计算量，也没有让 370GB 权重凭空消失。25GB 机器只是把昂贵的容量问题，转换成了漫长的 I/O 等待问题。这个交换并不神奇，却是真实、透明、可复现的。

从 25GB 笔记本到 6 张 RTX 5090，同一个模型、同一套引擎，硬件只改变专家住在哪一层。更难得的是，项目愿意公开负结果：预取可能倒退、投机解码可能变慢、学习缓存可能过拟合、旧量化容器存在质量损失。

这也是我愿意推荐它的原因。

它不是在告诉所有人“以后不需要 GPU 了”，而是在证明：前沿模型的硬件门槛，不一定只能靠堆更多显存来解决。

资料来源

colibri 官方仓库：https://github.com/JustVugg/colibri
官方中文 README：https://github.com/JustVugg/colibri/blob/main/README.zh-CN.md
官方 Benchmark：https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md
官方快速开始：https://github.com/JustVugg/colibri/blob/main/docs/quickstart.md
官方 Releases：https://github.com/JustVugg/colibri/releases