27k star 的纯 C 推理引擎：把 744B MoE 模型塞进普通电脑，到底靠不靠谱？

GitHub 趋势 · 第 22 期

#GitHub趋势#MoE推理#本地优先#纯C零依赖

colibrì 不打算替代 llama.cpp 或 vLLM。它把 MoE 看成「权重是数据，不是常驻状态」：把 VRAM、RAM、磁盘当成同一层推理层级（AI memory multitiering），让 GLM-5.2（744B）、Kimi K3（2.8T）这种 frontier 模型能跑在你手头的硬件上——可能慢，但保证语义不变。Apache 2.0、单文件 C 引擎、零运行时依赖，是给「想看清每个专家到底走了哪条路」的人准备的。

frontier MoE 模型，普通开发者够不着

GLM-5.2 / Kimi K3 这类 frontier MoE 模型动辄 744B ~ 2.8T 参数，全量加载要几十张 H100。普通开发者的选项只剩租 API 被锁在云端、或接受量化损失自己跑；想本地玩大模型，就得自己面对「权重怎么放、专家怎么调度、磁盘读取怎么不拖后腿」这一整套系统难题——大部分框架默认假设你有足够 VRAM，否则直接罢工。

项目是什么

JustVugg/colibri 是一个用纯 C + 零运行时依赖写的 MoE 推理引擎，目标是「让任何 MoE 都能在你已有的硬件上跑起来」。每个模型族对应一个 .c 文件（GLM-5.2、GLM-5.3-Flash、Inkling、Kimi K3、DeepSeek V4 Flash、Qwen3.8-Flash-Next、Qwen3.6、OLMoE），共用同一套 CLI（coli chat / coli serve / coli web），引擎自己读 safetensors 容器，不依赖 BLAS，不依赖 Python，CUDA/Metal/Vulkan 三套 GPU 后端按需打开。

它的核心思路只有一句话：「MoE 不需要「装进」快内存，而是被「摆放」到分层存储上」——dense 部分（注意力和共享专家）常驻 RAM，被路由的 19 456 个专家（每个 ~19 MB）按 LRU + 已学习热度 + 一层 lookahead 在 NVMe / RAM / VRAM 之间流动，磁盘路径上 read/compute 重叠、双 SSD 条带化、O_DIRECT 可选打开。作者直接叫它「a JIT, but for weights」：编译期 JIT 不会把整个程序都编好，colibrì 也不会把整个模型都加载好，它盯着你的路由热度，让真正会被命中的专家先上。

核心能力

能力	做法（README 原文逐字）
内存分层	VRAM / RAM / NVMe 当成同一层级摆放权重；快内存不够只会降速，不改语义
权重 JIT	每层 LRU + 已学习热度 pin + 一层 lookahead prefetch，越用越快
I/O 与计算重叠	async I/O 池（PIPE=1）边读边算，batch-union 合并专家，路由器 71.6% 一层可预测
异构执行	CPU / CUDA / Metal / Vulkan / NUMA 共用一套 runtime，按机器自动组合
双 SSD 镜像	`COLI_MODEL` + `COLI_MODEL_MIRROR` 两盘同时读，权重哈希分流，校验丢盘可降级
57× KV 压缩	MLA KV state 576 floats/token vs 32 768，`.coli_kv` 跨重启保留，暖启动零 prefill
诚实的投机解码	MTP / grammar drafts 实测后再开，DeepSeek V4 默认 `V4_DRAFT=0 V4_MTP=0`
本地集群	`coli cluster coordinator/worker` 把 Mac 们拼成一层「外置 FFN 计算池」，token 不重复 round-trip

上手

下面的命令都来自 README 原文，按平台挑一种即可。

# 1. 拿程序（自己 100 KB 量级）
mkdir colibri && tar xzf colibri-v1.8.0-linux-x86_64.tar.gz -C colibri && cd colibri
python3 coli info                              # 引擎就位 ✓

# 或源码构建（gcc/clang + OpenMP）
git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh                                    # 体检 + 编译 + 自测

# 2. 拿模型（GLM-5.2 int4-gs64 with int8 MTP，约 372 GB）
# 必须用 gs64 镜像，老的 per-row int4 会触发 think-mode 死循环与 EOS 饥饿
# 模型来源：huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp

# 3. 跑起来（同一个 CLI 适配 8 个模型族，coli 从 config.json 自动挑引擎）
COLI_MODEL=/nvme/glm52_i4 ./coli chat         # TUI
COLI_MODEL=/nvme/glm52_i4 ./coli plan         # 看 VRAM/RAM/磁盘 各放多少
COLI_MODEL=/nvme/glm52_i4 ./coli doctor --deep
COLI_MODEL=/nvme/glm52_i4 ./coli tune         # 跑一遍测最快配置
./coli web  --model /nvme/glm52_i4            # API + 仪表盘，开浏览器
./coli serve --model /nvme/glm52_i4           # 同上，不开浏览器

支持 8 个模型族的硬件门槛差异很大（取自 README 表格）：OLMoE 7B 只要 8 GB 内存；GLM-5.2 / Qwen3.6 需 16~24 GB；Kimi K3 要 32 GB+ 和 ~1.6 TB 磁盘；Vulkan 后端对 AMD RX 580 这种被 ROCm 抛弃的卡也兼容——所以「GPU 不是必需，但有永远更快」。

我的判断

适合谁：想在 M-series Mac / 工作站上真跑 frontier MoE、又不想把代码和数据全交给云端 API 的工程师；做推理系统研究的实验室——项目自带「测量优先，工程化诚实」的研究纪律（团队原话：「a well-controlled failure is more valuable here than an unexplained fast number」）；以及想做本地企业级问答、又预算买不到几张 H100 的中小团队。

不适合谁：追求「点一下就跑出高 tok/s」的人；想直接对话 ChatGPT 那种用户体验的产品用户——CLI 友好归友好，没 Web 体验打磨；以及把数字当成承诺看的人：作者明说「no SLA on speed, hard guarantee on semantics」。

坑：① 必须用 gs64 容器 + int8 MTP 头；老的 per-row int4 镜像会触发 think-mode 死循环（int4 → 0% draft acceptance）；② DeepSeek V4 的 V4_DRAFT/V4_MTP 默认 OFF——官方实测「rejected-suffix replay」开销盖过了 draft 节省，不要凭感觉打开；③ O_DIRECT 是 NVMe 加速选项不是保险，QLC / 虚拟盘反而会变慢，先测再开；④ 主作者 JustVugg 单人主导（bus factor 小），2 057 个 commit 都是核心维护；⑤ 已经非常拥挤——和 llama.cpp / vLLM / kTransformers 同台打擂，定位是「互补的实验平台」，不是「我比它们快」；⑥ 25 GB 笔记本上是 0.05~0.1 tok/s 冷启动，「能跑」和「能用」之间还有距离。

地址：github.com/JustVugg/colibri

总 star：27,300（今日 +157）｜许可证：Apache 2.0（引擎，可商用；GLM-5.2 权重由 Z.ai 以 MIT 释出）

抓取时间：2026-09-10 21:20（北京时间）｜活跃：v1.10.2（2026-09-06）｜ 2 057 commits｜单文件 c/colibri.c 主引擎

你手头的硬件现在能跑哪个 MoE？欢迎在评论区报硬件 + 实测 tok/s。下期预告：diegosouzapw/OmniRoute（自称 352 个 provider、150+ 免费端的 MIT AI 网关）或 rohitg00/ai-engineering-from-scratch（53k star 的 AI 工程实战学习库）。

#GitHub趋势#MoE推理#本地优先#纯C零依赖