💡 一句话总结：开源推理引擎 Colibrì（纯 C、零依赖、不强制 GPU）证明了一件事------MoE 大模型不需要"被装进内存"，只需要"被放置"。25GB 内存的笔记本真的能跑 744B 的 GLM-5.2，代价是冷启动时每秒 0.05 个 token 的龟速；值不值，取决于你要什么。
导语：你的显卡，配不上最新的模型了吗
本地跑大模型的人，这两年都被同一个魔咒困着：模型参数每几个月翻一茬，显卡显存却纹丝不动。744B 的模型？先看看你有没有 8 张 5090。于是大多数人的选择是退而求其次------跑个几十 B 的"小杯"。
GitHub 上有个叫 Colibrì（蜂鸟）的项目偏不信这个邪，它的自我介绍相当嚣张："Tiny engine, immense model"------引擎极小，模型极大。25GB 内存的笔记本，无 GPU，跑 744B 的 GLM-5.2；32GB 内存挑战 2.8T 参数的 Kimi K3。项目靠这套思路在 GitHub 攒下了数万 Star（量子位报道称 32k，仓库快照在 25k~26k，不同时点口径有出入）。
它到底是真黑科技还是行为艺术？把 README 和社区实测翻完之后，这篇给你讲明白。
想直接上手？
- 🐦 GitHub 仓库：JustVugg/colibri
- 📖 项目主页（含 Dashboard 演示）：justvugg.github.io/colibri
- 📰 中文报道：量子位：笔记本跑7000亿参数GLM
🧠 核心思路：模型不需要被装下，只需要被放置
先补一个背景：为什么 744B 的模型有可能塞不进内存还能跑？
因为 GLM-5.2 这类模型用的是 MoE 架构（混合专家：总参数量巨大，但每个 token 只有一小部分"专家"被激活上场）。GLM-5.2 总参数 744B，每个 token 实际只激活约 40B------也就是说，95% 的参数在任何一个瞬间都是闲置的。
传统思路是"先把模型全装进显存/内存，再开始算"。Colibrì 把这个顺序倒了过来：
- 常驻层：attention、embedding、共享专家这些每次都要用的部分（约 17B 参数），int4 量化后只占 9.9GB，住在内存里；
- 硬盘层：剩下 19,456 个路由专家（int4 后约 370GB），全部躺 NVMe SSD 上。Router（路由器）点名谁，才去硬盘上读谁；
- 加速层：有 GPU 的话，VRAM 成为第三层，最热的专家往上放。
作者管这个叫"权重的 JIT"------就像 JIT 编译器不提前编译整个程序、只处理真正运行的热点代码，Colibrì 也不把 744B 参数看作必须驻留的整体，而是一堆按需调度的数据。
这里有一条硬原则值得单独说：专家放在哪里，只决定速度，不改变模型本身。Router 的选择和权重精度不因存储层级而变------内存小就慢，但不会偷偷少算几个专家。这保证了"跑得慢"和"跑得对"是两件事，前面所有数字都要放在这个前提下看。
⚡ 快与慢：不吹不黑的性能阶梯
SSD 当显存，第一反应肯定是：读盘不得读到怀疑人生？答案是：会，也不会------取决于你给它什么硬件。
官方实测的性能阶梯长这样：
- 🐢 25GB 开发机（项目起点）：冷缓存 0.05~0.1 token/s------确实"跑是能跑，有亿点慢"；
- 💻 128GB 纯 CPU 桌面：暖机后约 1.8 token/s------已经能正常对话；
- 🎮 单张 5070 Ti 笔记本：1.07 token/s（GPU 常驻管线）；
- 🚀 6 张 RTX 5090 全驻留：5.8~6.8 token/s------硬盘彻底退出解码路径。
那它是怎么把 0.05 拉到 1.8 的？三板斧，每板都有实测数字：
- LRU 缓存 + 学习型 pin：最近用过的专家留在内存，跑得越久越知道哪些专家是"常客"，主动钉住------引擎会越用越快；
- 提前一层预取：相邻层的专家路由有强相关，实测可预测性 71.6%。这一层在算的时候，后台已经在读下一层可能要的专家，计算和 I/O 重叠起来；
- 双 SSD 分条：两块盘各放一份模型副本，实测解码提速 37.5%；O_DIRECT 绕过页缓存再榨 34%。
还有个容易被忽略的细节：MLA 注意力的 KV 状态被压到原来的 1/57，并且跨重启保温------对话重开时零重新预填充，字节级和不断线时一致。
该怎么判读这些数字：tok/s（每秒生成的 token 数）对话场景 1 以上就可用，写作/长输出场景 3 以上才舒服。所以 Colibrì 的甜区是"大内存 CPU 机器"或"少量 GPU + 大 SSD"------恰恰是游戏本和普通工作站的范围。
🗺️ 支持范围：从 7B 到 2.8T 的九个家族
不只 GLM。目前 Colibrì 支持九个模型家族，每个家族一个 C 文件、共用同一套 coli chat / serve / web 前端：
- OLMoE（7B）：8GB 内存就能跑，硬盘只要 7GB------入门玩具；
- GLM-5.2/5.3（744B）：372~419GB 硬盘，内存 16GB 起步；
- DeepSeek V4 Flash （284B）/ V4.1 Flash（552B，带视觉）：官方检查点直接加载，不用转换；
- Inkling（Thinking Machines，975B）：469GB 硬盘；
- Kimi K3（月之暗面，2.8T 总参/104B 激活）：权重约 1.6TB，但内存只要 32GB 起步，同样不强制 GPU。
🔥 社区怎么说：工程诚实度加分，吞吐天花板存疑
这个项目在 Hacker News 和 GitHub Discussions 上的口碑有个鲜明特点：大家夸的不是快，而是诚实。README 里每个优化都标注"实测到什么、还差什么实验、什么时候会失效"，连负面结论都带 issue 编号（比如 int4 的 MTP 草稿头接受率会崩到 0~4%，所以默认必须 int8）。作者的原话是："一个控制良好的失败，比一个无法解释的快数字更有价值。"
社区的实际使用反馈也相当扎实------issue 区里全是真实硬件报告：Intel 265K + 128GB DDR5 + 双 NVMe 的 O_DIRECT 实测、RTX 5070 Ti 笔记本 1.07 tok/s、双 5090 平台......这种"人人可复现"的气氛在开源推理项目里不多见。
争议点也有两个。一是和 llama.cpp 的性能对照 ：Discussions 里专门有帖子讨论"SSD 流式场景 llama.cpp 是不是更快"，这个对比还在进行中，Colibrì 的差异化在于语义保证和调度自由度，而非绝对速度。二是学习型缓存的过拟合风险：pin 住的热点专家可能只适配你最近的工作负载，换个任务收益归零------作者自己也把它列为开放假设，邀请社区做跨会话对照实验。
另外提个坑：早期第三方转换的 per-row int4 容器质量差约 9 个百分点，还引发过 think 模式死循环（issue #455），官方现在推荐 gs64 容器 + int8 MTP 头。下载模型时认准 README 指定的版本，别拿错容器怪引擎。
🐦 把话说明白
回到开头那个问题：行为艺术还是真黑科技？答案取决于你站在哪------
它站得住 的部分：语义不变的前提下，存储层级真的可以当调度资源用，25GB 内存跑 744B 是可复现的事实，九个模型家族的覆盖面也是实打实的。它有争议 的部分：绝对速度打不过把模型装进内存的传统方案，冷缓存体验劝退，学习型缓存的收益边界未定。它没解决的部分：372GB~1.6TB 的模型下载对普通人是硬门槛，项目无 SLA，生产使用要自己扛验证责任。
不过话说回来，Colibrì 真正的价值可能不在"让你今天就用它干活"，而在它验证了一个方向：当 MoE 把激活参数压到总量的 5%，"模型能否本地跑"的决定权正在从显卡厂商手里，转移到存储和调度工程师手里。2026 年开源社区的重心，正明显从"训练更强的模型"外溢到"让已有的前沿模型在更多硬件上跑起来"------这只蜂鸟，就是推理侧最好的注脚。
参考来源
- JustVugg/colibri（GitHub 仓库，一手来源）--- https://github.com/JustVugg/colibri
- Colibrì 项目主页（官方）--- https://justvugg.github.io/colibri/
- 量子位（权威中文科技媒体）--- https://www.qbitai.com/2026/09/497624.html
- Show HN: Getting GLM 5.2 running on my slow computer（社区讨论）--- https://news.ycombinator.com/item?id=48842459
- Lumabri：P2P 集群衍生项目（社区）--- https://news.ycombinator.com/item?id=49293523
- GitHub Discussions（性能对照与实测）--- https://github.com/JustVugg/colibri/discussions