Colibri（项目写作 Colibrì）是一套开源本地推理引擎。它受到关注的原因很具体：大型 MoE 模型的全部权重装不进快内存时，能否保留一部分常驻数据，把路由选中的专家从磁盘按需搬进来？项目围绕 SSD、RAM 与 VRAM 的分层调度实现这一思路。

图 1: 依据项目 README 绘制的机制示意，具体放置策略取决于模型和后端。

为什么模型很大，快内存却可以少一些

MoE 在一次计算中只调用部分专家；总参数和每个 token 实际调用的参数并不是同一个数。Colibri 利用这个特点，让常用数据进入快内存，其他专家留在 SSD，通过缓存与预取减少重复读取。项目 README 把 RAM、VRAM、NVMe 视为同一套权重的不同存储层，强调存储位置影响速度。

这里容易产生两个误会。第一，按需读取不等于把全部模型压缩到几 GB：原始或转换后的文件仍须有地方存放。第二，激活参数少不等于硬盘等待可以忽略：冷缓存、专家频繁切换、上下文增长时，响应时间需要另算。想理解量化和缓存，可以结合模型量化与上下文窗口阅读。

“纯 C、零依赖”应该怎么理解

核心推理引擎使用 C，但官方快速开始的发布包还包含启动器和 API 辅助程序。按项目文档，使用这些入口仍需要 Python 3；从源码构建还要有编译器和 OpenMP。不能把引擎的运行依赖描述直接理解成整套安装完全不需要环境。

首次体验更适合使用项目 Releases 中与操作系统匹配的包。想调整后端或检查源码再选择编译。模型支持范围以对应版本和每个模型的文档为准，不要下载任意一个 GGUF 文件后就认定引擎能直接加载。Colibri 的模型容器与常见桌面应用的下载格式也不能混为一谈。

官方快速开始以 GLM-5.2 的 int4 容器为例，列出约 372 GB 的模型文件，并建议为该例准备约 380 GB 可用磁盘空间。这个数字属于特定容器，不是所有模型的统一要求；首次转换、保存另一份副本或者换模型，都可能增加占用。

我们的建议是先核对三件事：目标版本支持哪种模型格式、下载与临时文件需要多少空间、SSD 是否还有余量。磁盘上放得下和能稳定持续读取也要分开。若你只有容量不大的系统盘，先试 LM Studio 或 Ollama 中能常驻内存的模型，通常更容易看清自己的实际需求。

图 2: 先确定完整模型和部署条件，再投入下载时间。

以下命令来自当前 README，路径只是示例，须替换为已经下载好的支持模型目录；不同发布包的入口位置以对应文档为准：

python3 coli info
python3 coli doctor --model /path/to/model
python3 coli plan --model /path/to/model
python3 coli chat --model /path/to/model

这些是读者的操作建议，并非本站执行过的记录。不要为追求一次漂亮的速度数，同时更换量化、后端和缓存策略；变化太多时，无法知道哪一个调整产生作用。

项目性能文档公布了不同机器与缓存状态下的结果，也给出了记录硬件、提交版本、模型、命令和质量检查的测量协议。那些结果是项目或社区报告，不能作为对你的机器的速度承诺。

建议把验收分成四项：能否加载、第一次回答要等多久、后续交互是否连贯、结果是否满足任务。只看 tokens/s 会遗漏长提示词读取时间；只看缓存热起来后的数字，会遗漏首次打开的等待。反过来，某个简单问答答对，也不能证明它适合代码修改、工具调用和长文检索。

图 3: 每层都通过，才算对具体工作有用；示意图没有性能排名。

官方 API 文档提供兼容 OpenAI 风格的接口说明，但不同引擎的功能并不完全一致；接入某个 agent 前，应核对模型模板、工具调用、并发与流式输出的对应支持。接口外形兼容，不代表模型的工具调用质量与其他产品相同。

仓库采用 Apache 2.0 许可；模型权重有独立条款，需要分别核对。程序不收费也不代表部署没有成本，SSD、设备、电力和维护都是投入。使用本地引擎可以把推理安排在自己的设备上，但如果外层应用继续联网搜索、调用云端规划器或上传日志，整个工作流仍可能传出数据。

如果你已经有可用硬件，愿意记录日志、控制变量，并想研究大型 MoE 的存储和计算取舍，Colibri 值得作为实验对象。它提供的是另一种部署路径，使用价值要由你的任务和设备共同决定。

若目标只是每天写邮件、整理几份材料或偶尔辅助编码，先选能在现有内存中运行的模型。预算有限时，也可以保留云端处理难题，把简单任务放本地。有关成本与验收方法，继续看本地模型替代订阅指南；想混用本地与云端模型，看混合 AI 编程指南。