Colibrì 是一个用纯 C 编写的 Mixture-of-Experts 推理引擎，把显存、内存与磁盘当作统一的分层存储，按需从磁盘流式加载被路由到的专家权重，目标是让消费级与异构硬件也能运行超大 MoE 模型。
项目做什么
项目自述的目标是降低大模型推理对稀缺硬件的依赖：把权重存放位置从必须装进快速内存，改为在显存、内存与 NVMe 之间分层放置与调度，只让当前 token 真正激活的专家参与计算。同时它把自己定位为开放研究平台，用于测试模型格式、内存层级、存储 I/O、放置策略、调度、算子、推测解码以及 CPU/GPU 重叠等系统级想法，并强调以可复现的端到端测量而非微基准来决定方案取舍。以上定位来自 README 自述，第三方验证情况不明。
与同类方案相比
README 声称的优势集中在工程形态与资源占用上：引擎为单个 C 文件加少量头文件，运行时不需要 BLAS、Python 或 GPU，密集部分（注意力、共享专家、嵌入）常驻内存，约两万个路由专家留在磁盘按需读取。它还描述了按层 LRU、学习式热专家固定、提前一层预取、批量专家并集去重读取、异步 I/O 池、可选的 O_DIRECT 与双 SSD 分流，以及 CPU、CUDA、Metal、Vulkan、NUMA 等多后端共存。README 也给出了若干数字（如 4 tok/s、TTFT 1.6 秒、预取可预测性 71.6%、KV 压缩 57 倍），但这些均为项目自报，缺少独立复现，不宜直接当作既成结论。
设计与创新
较有辨识度的思路是把权重调度类比为编译器 JIT：不预先驻留全部参数，而是根据实测路由热度决定哪些专家进入哪一层级，并让路由器提前一层运行以便预取掩盖磁盘延迟。其次是坚持放置只影响速度、不改变语义，即不因快速内存不足而悄悄降低精度或改动路由。此外还有双 SSD 按实测带宽加权的确定性哈希分流、批量位置对同一专家只读一次、以及集群模式下把一层内路由批并集合并为单次 TCP 请求以减少往返。这些设计在 README 中有描述，但是否为同类项目首创、相较其他推理引擎有何量化优势，仅凭本 README 无法验证。
适用场景
README 描述的使用场景包括：在个人笔记本或单机工作站上以磁盘流式方式运行远大于内存的 MoE 模型；在拥有多张消费级显卡的主机上让专家部分或全部驻留显存并做 CPU/GPU 重叠；用双 SSD 或部分镜像盘提升解码时的读取带宽；把多台 Mac 组成本地集群，由协调节点保留 token 生成、路由与 KV 状态，工作节点执行被路由的 FFN；以及通过 Web 仪表盘观察每轮 token 指标、时间分解、层级占用与专家路由热度。此外它还面向希望改动代码、复现实验并提交正负结果的研究者。
谁会受益
对于想在自己已有硬件上持有并检查超大 MoE 模型、而不愿只通过 API 租用推理的开发者，这个项目提供了可读、可改的引擎实现与可视化面板，便于观察专家路由行为、测量层级占用与磁盘流量。它以单个 C 文件和极小依赖为卖点，降低了编译与部署门槛；配套的实验协议、镜像校验命令与集群模式，则为做受控 A/B 实验和分阶段优化提供了相对明确的入口。对研究系统方向（内存分层、预取、推测解码收益边界）的人，价值主要在于框架与测量方法，而非现成的高吞吐服务。
使用前需要注意
README 明确声明不对速度作 SLA，快速内存不足会降低速度；解码在多数机器上受磁盘带宽限制，O_DIRECT 依赖具体硬盘，QLC 或无缓存盘上可能无收益甚至变差。学习式热专家固定可能对提示过拟合，提前一层预取在部分主机上可能失效，MTP 推测解码在约 85% 专家命中率附近曾测得 32% 的损失。集群的稠密层分片和浏览器 WebGPU 工作节点仍是后续工作。README 中列出的模型族、版本号与全部性能数字均为项目自报，缺少独立复现；许可证、实际竞品对比与创新性同样无法从本 README 得到证实，需要查看仓库其他文件与第三方测量后再判断。
本文基于抓取时的项目 README 和仓库简介整理；功能、限制与文档可能随项目更新而变化。