colibri：用 C 写的 MoE 推理引擎，把磁盘当内存用

744B 到 2.8T 参数的 MoE 模型，权重文件动辄几百 GB。常规做法有两条：租多卡云实例，或者把整模型塞进几百 GB 内存加若干张加速卡。前者按小时计费，数据要出域；后者一次性投入高，显存一满还容易卡在加载阶段。colibri 押的是第三条路，把磁盘也算进推理层级，模型不必整个装进内存。

colibri 是用 C 写的 MoE 推理引擎，把显存、内存、磁盘当成一套放置层级，从磁盘流式加载量化专家，为自有机器的开发者提供本地对话与 HTTP 服务。

仓库里九个模型家族各自对应一个 C 文件，共用同一套命令行前端。跑起来之后有三条入口：终端里的 coli chat、对外提供接口的 coli serve，以及浏览器里的 coli web 仪表盘。仪表盘上的 Brain 页画的是 GLM-5.2 实测出来的专家图谱，13,260 个被表征的专家分成十个区域，覆盖 Python、SQL、数学、诗歌、法律、中文等方向；Profiling 页记录每一轮各阶段的时间去向，带最近 30 轮的趋势。

许可证是 Apache-2.0，主要语言 C，仓库地址是 https://github.com/JustVugg/colibri。截至 2026-09-29 抓取时，Star 数 38158，Fork 4162，Watcher 302，开放 Issue 86。最新版本 v1.12.1 发布于 2026-09-25。

在这之前，跑 MoE 大模型卡在哪

显存是第一道门槛。744B 的 GLM-5.2 即使用 int4 量化，权重体量仍然远超单张消费卡的容量；把 2.8T 的 Kimi K3 或 975B 的 Inkling 摆进来，门槛还要再往上走一档。按常规加载方式，权重必须常驻在计算单元能直接访问的内存里，这也是这类模型长期停留在云端的原因。

租多卡云实例解决了硬件问题，账单按小时走，模型和数据离开自己的机器，底层推理代码也改不动。另一条路是买大内存主机把整个模型装进 RAM 再跑，事实表里 512GB 内存的机器就是这个用法，这台机器基本上被一个模型占满。

速度仍然受限于专家字节数除以有效带宽。issue 里把 decode 环节称为「带宽墙」，v1.5.0 那次回退就是例子：在 128GB 单 GPU 主机上，新版本留下约 60GB RAM 未用，专家命中率掉 13 个点，解码比 v1.4.0 慢 18%。

换成 colibri 之后

1. 把模型转成引擎能读的容器。coli convert 负责这一步。v1.10.2 修过一个缺陷，它产出的 GLM-5.3-Flash 容器一度被引擎拒绝，原因是套用了 GLM-5.2 的配置。
2. 指定模型目录与内存预算启动对话。事实表里给出的命令是 ./coli chat --model /PATH/glm52_int4/ --ram 800 --auto-tier。引擎默认走每层 LRU、固定热存储加提前一层预取，按路由热度决定哪些专家留在内存、哪些留在盘上。
3. 需要接口时换成 coli serve，需要在浏览器里看状态时用 coli web。仪表盘会实时显示每个专家的存储层级，一轮里被路由到的专家会闪白。
4. 只想要一个封闭答案时切到 Brio 模式。给它一份文档和一组允许的答案，它只读每个答案的概率，不生成 token，并报告一个表示不确定程度的熵值。README 的示例里，request changes 的概率是 99.9%，熵 0.005，读入 4 个 token，生成 0 个。

README 里的启动输出是这样的：

$ ./coli chat
  🐦 colibri v1.12.1 — GLM-5.2 · 744B MoE · int4 · streaming CPU
  ✓ ready in 32s · resident 9.9 GB
  › ciao!
  ◆ Ciao! 😊 Come posso aiutarti oggi?

常驻内存 9.9 GB 就能把 744B 模型跑起来，其余权重留在盘上按需读取，这是层级设计最直接的体现。

怎么接进现有流程

输入侧要准备的是量化后的模型容器，放在磁盘上。引擎按层读取，容器的落盘位置和盘的类型直接影响解码速度。issue 里把 O_DIRECT 描述为依赖驱动器的特性，双 SSD 加权条带也还在等更广的端到端对比。

输出侧有三条：终端交互、HTTP 服务、浏览器仪表盘。推理过程本身可观测，Profiling 页给出每一轮各阶段的时间占比，Brain 页给出实测的专家路由图谱，用的是真实运行的测量结果。

构建方面，仓库根目录有 Makefile、docker/ 目录和 flake.nix，另有一份 pyproject.toml 说明 Python 侧有打包配置。仓库里没有说明需要额外的定时任务或调度组件来维持它运行。

它替代不了的部分

官方对速度没有承诺。README 写明「no SLA on speed, and a hard guarantee on semantics」，内存不够只允许降低速度，不允许悄悄改变模型精度或路由语义。需要稳定吞吐承诺的线上服务，这条前提就不成立。

它省下的主要是显存，磁盘和内存仍然不能太小。模型容器要落在大容量磁盘上，DeepSeek V4.1 Flash 的 552B 版本在盘上占 510GB；内存压得太低，频繁换入换出会拖垮解码速度。

路由预测是可测策略，不是保证。历史热度可能过拟合，提前一层的预取在某些主机上会亏，仓库把它们留着当可测量项，而不是默认必胜。

项目自我定位是推理引擎加开放研究平台。默认策略不为了好看改数值，实验要经过可控的端到端 A/B 才被采纳，所以新特性落地偏慢。

同类项目对比

这三个项目的层次不一样。目标是开箱就能问本地文档，AnythingLLM 的起点更靠前；要的是本地多模态推理服务，LocalAI 已经有现成的接口层。colibri 需要先备好模型容器、理解内存分层与放置参数，上手门槛明显高于这两个，它的位置在数据不出域的前提下把超大 MoE 跑起来，并把推理过程摊开给你看。

值不值得换

下面三种情况，换过去是划算的：手上已有一台内存 512GB 级别、带大容量 NVMe 的主机，想让 744B 级模型在本地常驻；关心推理过程本身，需要看专家路由、各阶段耗时和封闭问答的概率输出；接受「速度没有承诺、语义有保证」这个前提，把可观测性和可修改性排在吞吐之前。

需要按 SLA 承诺吞吐和延迟的线上服务，不要换。colibri 给不出这个承诺，这类场景更适合云端推理服务或专门的推理框架。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。