colibri：用 25GB 内存跑 744B 模型，纯 C 推理引擎的取舍
在 25GB RAM 消费机器上运行 GLM-5.2 (744B MoE)，纯 C，零 deps，专家从磁盘流式传输。微小的发动机，巨大的模型。
秒懂
- 它是什么？
- colibri 把 VRAM、内存和 NVMe 当作同一层存储层次，用流式专家加载在消费级硬件上运行 GLM-5.2 等巨型 MoE 模型。它不承诺速度，但承诺不悄悄改变模型语义。
- 适合谁用？
- 适合两类人：一是没有高端 GPU 但想本地运行前沿 MoE 模型的研究者，二是愿意为推理性能做底层实验的系统工程师。不适合追求开箱即用、对延迟有严格 SLA 的生产环境用户，因为项目明确声明没有速度保证，且 O_DIRECT 和双 SSD 条带等特性依赖具体硬件，效果需要自己验证。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 C（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个把存储当内存用的推理引擎
colibri 解决的是一个具体问题：前沿 MoE 模型的参数量从 744B 到 2.8T，远超消费级硬件的内存容量。传统推理引擎要么把全部权重塞进显存或内存，要么在缺页时表现糟糕。colibri 的做法是把 VRAM、RAM 和 NVMe 当作同一个多级存储层次，专家权重按需从磁盘流式加载。它用纯 C 编写，零运行时依赖，每个模型对应一个 C 文件，共用同一套 `coli chat`、`coli serve`、`coli web` 前端。项目的定位很明确：这是一个研究平台，不是开箱即用的产品。README 里直接写了没有速度 SLA，但有语义保证，默认策略绝不悄悄改变模型精度或路由语义。
JIT 权重加载：不是把所有专家都读进来
核心机制是所谓的 JIT for weights。系统根据实测的路由热度维护每层的 LRU 缓存，加上一个学习得到的固定热存储，以及提前一层的预取。这意味着每一层只加载被路由到的专家，而不是整个模型。对于 GLM-5.2 这种 744B 参数的模型，单次推理实际激活的参数远小于总量。README 给出的示例显示，模型在 32 秒内就绪，常驻内存仅 9.9GB，而总参数规模是 744B。这个数字说明大部分权重停留在磁盘上。但项目也诚实标注了局限：历史路由模式可能过拟合特定提示词，预取在某些主机上反而会拖慢速度。所以这些策略都是可测量的策略，不是承诺。
I/O 是引擎的一部分，不是外挂
colibri 没有把存储延迟当作免费资源。它实现了批量专家合并读取、读取与计算重叠、O_DIRECT 绕过页缓存，以及加权双 SSD 条带化。这些技术直接攻击流式路径的瓶颈。O_DIRECT 依赖具体驱动支持，项目明说这是 drive-dependent。双 SSD 条带化虽然已经实现并通过了带宽模型验证，但 README 承认还需要更多跨社区的真实端到端 A/B 测试。这里有个明显的取舍：把 I/O 优化做进引擎核心，换来的是对硬件特性的敏感。在一台普通单 SSD 笔记本上，这些优化可能毫无效果，甚至因为 O_DIRECT 的对齐要求而引入额外复杂度。
异构执行与压缩状态
同一套运行时同时支持 CPU、CUDA、Metal 和 NUMA 内存，专家可以部分或全部驻留在不同设备上。组合方式取决于机器的计算能力、带宽和驻留情况。另一个值得注意的设计是压缩 KV 缓存状态，项目声称能做到 57 倍更小的 MLA KV 状态，同时保持 token 精确的前向验证。这意味着优化不会改变模型输出。它还支持持久的对话上下文和 DSA（文档中没有展开说明具体含义）。这些是内存、延迟和正确性属性，不是笼统的吞吐量声明。项目刻意把正确性验证与性能优化绑定，防止优化过程中悄悄改变模型行为。
运行方式与前端
获取和运行方式很直接。从 releases 页面下载对应版本，然后执行 `./coli chat` 进入交互模式。README 给出的示例输出显示，启动后 32 秒内就绪，常驻内存 9.9GB，然后可以直接输入对话。前端有三个入口：`coli chat` 是命令行对话，`coli serve` 提供 API 服务，`coli web` 启动带仪表盘的网页界面。网页界面展示了实时 token 指标、每轮时间分解、VRAM/内存/磁盘层级条，以及一个实时的小型脑图。还有一个 Brain 页面显示全部 19,456 个专家，颜色代表存储层级，亮度代表路由热度，悬停可查看专家的话题亲和度。Atlas 页面则把 13,260 个已表征的专家按实测路由亲和度排列成三维星系，其中 1,041 个被复制的专家按话题聚类。
支持的模型与速度的现实
除了 GLM-5.2（744B），还支持 GLM-5.3-Flash（321B，带视觉）、Inkling（975B）、Kimi K3（2.8T）、DeepSeek V4 Flash（284B）、Qwen3.6（35B-A3B）和 OLMoE（7B）。每个模型一个 C 文件。速度方面，README 给出的一个例子是 744B 模型在 6 张 RTX 5090 上达到 4 tok/s，TTFT 1.6 秒，磁盘读取为 0，因为全部专家驻留在显存。注意这是全驻留场景的数字，不是流式场景。在 25GB 内存的消费级机器上，速度会显著更低，但 README 没有给出具体数字。项目明确说有限快速内存会降低速度，但不会改变模型语义。这个区别很重要：流式加载是功能性的，不是性能性的。
维护成本与许可证
项目采用 Apache-2.0 许可证，允许商用、修改和再分发，但需保留版权声明。维护节奏看起来活跃，v1.9.0 发布于 2026-08-28，v1.8.0 在 8 月 24 日，v1.7.0 在 8 月 20 日，大约每四天一个版本。这种节奏意味着 API 和配置可能频繁变动。升级成本需要自己承担，因为项目没有提供迁移指南的说明。作为研究平台，它鼓励用户修改代码并测量效果，而不是提供稳定的生产接口。如果你要部署到生产环境，需要自己锁定版本并维护补丁。项目的 Discord 和 GitHub issues 是获取帮助的渠道，但 README 没有说明社区响应时间。
替代方案与适用边界
与 llama.cpp 相比，colibri 的差异是根本性的。llama.cpp 同样用 C/C++ 实现，也支持 CPU 推理，但它的核心假设是模型权重需要能放进内存，通过 mmap 和分块加载来缓解，而不是把存储当作一等公民。colibri 的多级层次设计是围绕流式加载构建的，llama.cpp 的架构则是围绕内存驻留构建的。对于 7B 或 13B 这类小模型，llama.cpp 更成熟，生态更完整。colibri 的价值只在模型远超内存容量时才显现。另一个替代是 API 调用，但那就失去了本地推理的隐私和控制权。如果你的模型小于可用内存，colibri 的流式机制是多余的复杂度。如果你的模型大于内存且你接受降低速度换取可行性，colibri 是目前少有的选择。
编辑结论
适合两类人：一是没有高端 GPU 但想本地运行前沿 MoE 模型的研究者，二是愿意为推理性能做底层实验的系统工程师。不适合追求开箱即用、对延迟有严格 SLA 的生产环境用户，因为项目明确声明没有速度保证，且 O_DIRECT 和双 SSD 条带等特性依赖具体硬件，效果需要自己验证。采用前先确认三件事：你的存储设备是否支持 O_DIRECT 且性能达标，你的工作负载是否具有重复路由模式（否则 LRU 和预取优势不明显），以及你是否接受 int4 量化下的输出质量。Apache-2.0 许可允许商用和修改，但如果你要分发修改版本，需保留版权声明并注明改动。
社区笔记