github每日一库：JustVugg/colibri

在“本地跑大模型”这件事上，过去几年形成了一条默认路径：想要更大的模型，就得买更大的显存。40B 需要 24GB 卡，70B 需要双卡或量化，百亿参数以上的 MoE 在消费级硬件上几乎不被认真考虑。colibri 的出发点恰好站在这条路径的对面：它不问“怎么把模型塞进显存”，而是问“模型是不是非得完整地待在高速内存里”。答案是否定的，而它给出的实现方式，粗糙、直接，却意外地打开了一扇窗。

当 744B 模型住进 25GB 内存：colibri 如何用“分层”绕开显存墙
本地运行大模型，通常第一反应是买显卡。显存容量像一道无形的墙，把绝大多数人挡在了“前沿模型”的门外。JustVugg/colibri 做的事情不太一样：它用纯 C 写了一个推理引擎，让一台只有 25GB 内存、没有独立显卡的普通电脑，跑起了 744B 参数的 GLM-5.2 MoE 模型。Hacker News 上有人把它称为“黑客精神的终极示范”。但这个项目真正值得看的，不是“跑起来了”这个结果，而是它为什么能跑起来，以及为此放弃了什么。

前提：MoE 模型“大而不用全用”
colibri 能做到这件事，底层依赖一个被反复提及但常被忽略的事实：MoE（混合专家）模型虽然总参数量惊人，但每个 token 只激活其中很小一部分。GLM-5.2 有 744B 参数，每个 token 实际用到的约 40B，而在连续 token 之间真正发生变化的，只有约 11GB 的被路由专家。

这意味着模型的“大”和“每次计算所需的量”是两个可以分开看待的问题。colibri 的全部设计，都建立在这个分离之上。

核心机制：把模型“拆开放”，而不是“压进去”
传统推理引擎的目标是让整个模型尽可能待在最快的内存层级里。colibri 反过来，把 GPU 显存、系统内存和磁盘视为一个统一的分层体系，按“冷热”分配权重：

稠密部分（注意力、共享专家、嵌入）常驻内存，因为它们每个 token 都要用到；

路由专家留在磁盘上，由路由器在需要时读取，通过一个会学习你使用习惯的缓存来减少重复读取；

GPU 如果存在，只负责最热的专家和稠密层的计算，而不是承载整个模型。

用项目 README 的话说，模型“不必完整装进高速内存，而是需要被正确地放置”。这个“放置”策略，配合纯 C 实现和零依赖的设计，让安装本身也变得极简：8GB 内存、22GB 磁盘空间即可启动最小的模型，显卡是可选项。

代价：速度，以及“跑通”与“好用”之间的鸿沟
如果到这里就结束，故事会显得过于轻松。colibri 的社区讨论中有一个被坦诚面对的事实：它的实用场景是持续对话，而非一次性问答。一次性请求的体验“几乎无法接受”，只有在多轮对话中专家缓存“热”起来之后，才可能达到每秒一个 token 上下的水平。对一个习惯了 GPU 推理的人来说，这个速度几乎是不可用的。

但这恰恰是理解 colibri 价值的关键。它没有声称自己比 GPU 更快，也没有试图在通用推理场景中替代 llama.cpp 或 vLLM。Hacker News 上的一个判断相当准确：colibri 解决的是一个更窄的问题——某一类前沿 MoE 模型，能不能在内存受限的硬件上至少跑起来。“能不能跑”和“跑得好不好”是两个问题，colibri 只回答了第一个，但第一个问题在过去往往没有答案。

它真正改变的东西
colibri 在几个月内从一条 Hacker News 帖子涨到数万 Star，吸引的显然不是追求吞吐量的生产用户。它吸引的是另一类人：手头只有一台普通笔记本或旧工作站，但想亲手看看一个 744B 模型在自己的机器上生成第一个 token 的样子。

这个项目的意义不在于它有多快，而在于它把“显存墙”从一个物理定律变成了一道工程选择题。当你不再要求模型完整地待在显存里，而是允许它在 GPU、内存和磁盘之间流动，可运行的模型规模就不再由你买了什么显卡决定，而是由你愿意为每个 token 等待多久决定。这个交换不一定划算，但它是一种此前没有被认真摆上台面的交换。

对于想要尝试的人，colibri 的入门门槛低得有些反直觉：下载、运行启动脚本、回答一个问题、等待模型下载完成。剩下的，就是看你的磁盘读取速度，和你的耐心，哪一个先耗尽。