colibri 开源：纯 C 写的 MoE 分层推理引擎，25GB 内存跑起 744B 大模型

本地跑开源大模型，第一道坎几乎永远是显存。7440 亿参数的 GLM-5.2，光 int4 权重就有约 429GB，按传统玩法不堆几张高端显卡连想都不敢想。但 GitHub 上一个叫 colibri（意大利语"蜂鸟"）的项目偏不信这个邪——它在一台只有 12 个 CPU 核心、25GB 内存、没有独立显卡的笔记本上，把 GLM-5.2 这种 744B 的 MoE 大模型完整跑了出来。截至 11 月初，它已拿到约 4.7 万 star，是当日 GitHub Trending 上排名最高的项目之一。

作者与项目概况

colibri 由意大利开发者 Vincenzo Fornaro（GitHub ID：JustVugg）个人起步，采用 Apache-2.0 协议开源。仓库创建于 2026 年 7 月 1 日，首个 Release v1.0.0 于 7 月 19 日发布，最新版本 v2.1.0 于 10 月 31 日推出，近一个月保持高频迭代。它以"小巧引擎，庞大模型"为口号，用纯 C 实现、运行时零依赖——不需要 BLAS，也不需要 Python 环境，每个模型家族就是一个单独的 .c 文件，编译出来就是一个二进制。

核心思路：把存储层级当成一条内存来调度

真正让 colibri 与众不同的是它对 MoE 模型"专家"的分级放置。MoE 模型并非每次推理都唤醒全部专家，colibri 据此把专家分成三层：

  • 热专家放在 GPU（CUDA 或 Vulkan），负责高频调用；
  • 温专家放在系统内存（RAM）；
  • 冷专家留在 NVMe 硬盘上，用到时再流式加载进内存。

换句话说，它把 VRAM、内存和 NVMe 当成同一条存储层级来统一调度，让前沿 MoE 模型跑在"已有的硬件"上，而不是逼用户加显卡。引擎内部有一条五步专家流水线（route / union / place / overlap / learn），利用约 71.6% 的一层路由可预测性提前搬运权重，并坚守一条工程硬约束："慢内存只应该损失速度，绝不允许改变语义"——冷启动慢是真慢（可能每秒只有 0.05~0.1 个 token），但答案是对的。

实际能跑多大：744B 也能塞进 25GB

官方给出的示例里，GLM-5.2 的 744B MoE 用 int4 量化后，常驻内存约 9.9GB，32 秒即可就绪，随后就能在终端里对话。仓库已内置 13 个引擎：10 个给语言模型（覆盖 GLM-5.2/5.3、Kimi K3、DeepSeek V4 Flash 与 V4.1 Flash、MiMo-V2.6 Flash、Qwen3.6/3.8 等，也能直接读 GGUF 文件），1 个画图（Qwen-Image-2.1），2 个做决策（Laya、GLiNER2.5-Decide）。CPU、任意 Vulkan GPU、英伟达 CUDA 显卡都能跑，文档还带中文版，一个模型家族对应一个引擎文件，结构比大框架好读。

先把账算清，再谈下载

colibri 最务实的一点是"先把门槛写在明处"。它的一键脚本会先检测机器的内存、磁盘、CPU 与显卡，再推荐一个装得下的模型，确认能塞下才下载权重。官方口径：8GB 是最低线，16GB 以上更好，最小模型也要 22GB 空闲磁盘；常驻部分加专家缓存必须真正塞进内存，装之前先按脚本推荐来，别硬上大模型。本地跑的好处是权重与对话完全不走云端，离线环境也能用，代价是首次下载与磁盘占用都实在——所服务的模型权重从 137GB（DeepSeek V4 Flash）到 1.6TB（Kimi K3）不等。

谁适合，要注意什么

colibri 适合想在本地、离线跑开源大模型的开发者与 AI 爱好者。它走的是"纯 C 单文件引擎、自己编译自己调"的路线，和那些"开箱即用桌面应用 + API 兼容"的方案（如 FreeToken）形成互补：喜欢掌控底层、不想要臃肿依赖的选前者，想要界面的选后者。需要注意，项目目前仍有约 150~170 个 open issue，其中包含 Windows 上 CUDA 文件与构建的求助，装机前最好先看自己平台的说明。

在"引擎几百 KB、模型几百 GB"的现实里，colibri 用最朴素的方式降低了本地大模型的下限：它不承诺快，但承诺"你手上的机器，就能跑得起来"。