放置而非塞入：Colibri 用纯 C 让 744B MoE 模型在 16GB 内存上跑

放置而非塞入：Colibri 用纯 C 让 744B MoE 模型在 16GB 内存上跑

项目：JustVugg/colibri

Stars：960（2026-09-13 首次上榜）

语言：C

许可证：MIT

一个场景

你想在笔记本上跑 GLM-5.2——744B 参数的 MoE 模型。传统方案告诉你：你需要 8 张 H100，大约 640GB 显存。你没有 8 张 H100，你有一台 16GB 内存的 MacBook。

Colibri 说：够了。

它把 744B 模型的密集部分（注意力、共享专家、嵌入层）常驻在 16GB 内存里，把路由专家（routed experts）放在磁盘上，按需读取。每次生成一个 token，模型只激活约 40B 参数，其中只有约 11GB 在 token 间变化——这就是需要从磁盘读取的部分。

结果：744B 模型在你的笔记本上跑起来了。不是最快，但能跑。

核心洞察：大在磁盘，小在每个 token

Colibri 的全部设计基于一个观察：MoE 模型在磁盘上巨大，但在每个 token 上很小。

GLM-5.2 有 744B 参数，但每个 token 只使用约 40B。这 40B 里，约 29B 是密集部分（每个 token 都用），约 11B 是路由专家（不同 token 用不同的专家）。

这意味着：你不需要把 744B 全放进内存。你需要把 29B 密集部分常驻内存，把 11B 变化的专家从磁盘按需读取。11GB 的随机读取，在 NVMe SSD 上大约需要 1-2 秒——不够快做实时交互，但够做批量推理。

Colibri 的核心做法就是：把模型放置在合适的存储层级上，而不是强行塞进某一层。

三层存储架构

Colibri 实际上用了三层存储：

RAM（最快）：放密集部分——注意力权重、共享专家、嵌入层、LayerNorm。这些每个 token 都要用，必须最快。GLM-5.2 的密集部分约 29B 参数，int4 量化后约 15GB，16GB 内存刚好够。

GPU 显存（如果有）：放最热的专家。Colibri 会统计哪些专家被频繁调用，把它们缓存到 GPU。如果没有 GPU，这部分就空着，全部走 RAM + 磁盘。

磁盘（最慢，但最大）：放所有路由专家。744B 模型的专家部分约 700GB+，存在磁盘上。Colibri 用一个学习型缓存（learning cache）管理：记录你的使用模式，预读你可能需要的专家。

这个架构和操作系统的虚拟内存页面调度惊人相似——热数据在 RAM，冷数据在磁盘，按需换页。区别是 Colibri 换的不是内存页，而是神经网络的专家模块。

学习型缓存：不是 LRU，是"懂你"

Colibri 的磁盘缓存不是简单的 LRU（最近最少使用）策略。它是一个学习型缓存——会记录你的使用模式，预测接下来需要哪些专家。

为什么需要学习型缓存？因为 MoE 模型的专家调用有局部性：在编程任务中，代码生成相关的专家会被频繁调用；在数学推理中，逻辑相关的专家会被频繁调用。如果你在做同一类任务，很多专家会反复使用。

Colibri 的缓存会学习这种模式。你用了一段时间后，缓存命中率会上升，磁盘读取会减少，推理速度会变快。这和 CPU 的分支预测器思路一样——预测对了就快，预测错了就慢，但总体比不预测好。

纯 C，零依赖，一个文件一个模型族

Colibri 最让人惊讶的技术选择是：纯 C，零外部依赖，一个 .c 文件对应一个模型族。

这不是怀旧，是工程选择。Colibri 的作者解释了为什么选 C：

1. 可测量性：C 代码的行为是透明的——没有隐藏的内存分配、没有 GC 暂停、没有 JIT 编译延迟。你测到什么就是什么。这对优化很重要——你不能优化你看不见的东西。

2. 可移植性：C 编译器存在于每个平台。Windows、Linux、macOS、甚至树莓派，都有 C 编译器。零依赖意味着你不需要装 CUDA toolkit、不需要 Python 环境、不需要 vLLM 的复杂依赖树。

3. 单文件架构：每个模型族一个 .c 文件。GLM-5.2 的推理逻辑在一个文件里，DeepSeek V4 Flash 在另一个文件里。想理解某个模型怎么跑？读一个文件就够了。想优化某个模型？改一个文件就够了。

这个设计和 llama.cpp 的哲学一脉相承——C/C++ 单二进制方案对 Python 依赖地狱的最大优势。但 Colibri 比 llama.cpp 更激进：llama.cpp 用 C++，Colibri 用纯 C；llama.cpp 依赖一些标准库，Colibri 零依赖。

"放置"哲学

Colibri 反复强调一个概念：placement（放置）。

传统推理框架的思路是"fitting"（塞入）——模型有多大，就需要多大的内存/显存。放不下？买更大的卡。

Colibri 的思路是"placement"——模型的不同部分放在不同的存储层级上，根据访问频率和延迟需求分配。密集部分每个 token 都用，放 RAM；路由专家按需调用，放磁盘；最热的专家放 GPU。

这个思路不是 Colibri 发明的——操作系统的存储层级（L1/L2/L3 cache → RAM → SSD → HDD）就是这个思路。但 Colibri 是第一个把这个思路系统化应用到 MoE 推理上的开源项目。

关键设计原则是："权重放在哪里影响速度，不影响结果"。把专家从 GPU 移到磁盘，推理变慢，但输出不变。Colibri 的默认策略永远不会静默改变模型精度或路由语义——慢可以接受，但结果必须对。

13 个引擎，一个框架

Colibri 目前支持 13 个引擎：

10 个语言模型：GLM-5.2/5.3、GLM-5.3-Flash、Inkling、Kimi K3、DeepSeek V4 Flash、DeepSeek V4.1 Flash、MiMo-V2.6 Flash/Pro、Qwen3.8-Flash-Next、Qwen3.6（兼容 Qwen3-Coder 和 Qwen3.8-27B 稠密版）、OLMoE

1 个图像模型：Qwen-Image-2.1

2 个决策模型：Laya、GLiNER2.5-Decide（第三个 Clef 在 Qwen3.6 引擎上）

每个引擎是一个 .c 文件。新增模型族 = 新增一个 .c 文件。框架核心（缓存、路由、API 服务器）是共享的。

这个架构让 Colibri 能快速支持新模型——当一个新的 MoE 模型发布时，只需要写一个新引擎文件，不需要改框架。这和 PyTorch 的自定义算子注册思路类似，但更轻量。

OpenAI/Anthropic API 兼容

Colibri 启动后会暴露两个 API 端点：

• OpenAI 兼容：http://127.0.0.1:8000/v1
• Anthropic 兼容：http://127.0.0.1:8000

这个设计决策很聪明——它让 Colibri 能无缝接入现有 AI 生态。你的 Cursor、你的 LangChain、你的 AutoGen，都可以直接用 Colibri 做后端。

MCP 服务器

Colibri 还提供了一个 MCP 服务器（coli mcp），让 AI 助手能自动管理 Colibri：检测硬件、推荐模型、安装、启动、停止、检查状态。

这意味着 AI Agent 可以自己部署 AI 推理引擎。你告诉 Agent "帮我装一个本地 LLM"，Agent 通过 MCP 调用 Colibri 的工具，自动完成硬件检测、模型选择、安装、启动。这是"AI 管理 AI 基础设施"的一个实例。

一句话总结

Colibri 把 744B MoE 模型从"需要 8 张 H100"变成了"需要 16GB 内存 + 22GB 磁盘"。它不是靠压缩模型，是靠重新思考模型在存储层级上的放置方式——密集部分常驻内存，专家按需从磁盘读取。纯 C 实现、零依赖、一个文件一个模型族，让这个"放置哲学"变得透明可测量。