GitHub Today +960 stars，Colibrì 想把 744B MoE 放进你的磁盘和内存

北京时间 9 月 14 日清晨，JustVugg/colibri 在 GitHub Trending Today 显示 +960 stars，仓库累计 29,584 stars。同一天，项目发布 v1.11.0。前者是 Trending 页面当时的 Today 窗口，后者是仓库累计 star，不能相减或混写成“日增总量”。GitHub API 可以复核当前仓库数据。

colibri 的传播钩子很直接：它声称用一个纯 C 推理引擎，让 744B 级别的 MoE 模型在已有硬件上运行。但我更想把它当成一个系统问题来读 - 当每个 token 只会用到很小一部分专家参数时，模型究竟必须“装进”显存，还是只需要让将被路由到的权重及时抵达计算单元？期望对大家有所帮助。

不是把 744B 全塞进内存

Colibrì 目前支持 GLM、Kimi、DeepSeek、Qwen 与 OLMoE 等多个 MoE 家族。它的主路径以 README 所列的 744B GLM-5.2 为例：注意力、共享专家和嵌入等稠密部分以 int4 常驻 RAM，约 9.9 GB；75 层中被路由到的专家留在磁盘上的约 370 GB 容器里，按需读取。项目给出的计数是 19,456 个可路由专家，每个约 19 MB。项目说明 把这套思路称为“权重的 JIT”。

它把 VRAM、RAM、NVMe 看成同一份权重的三个放置层。路由器先决定本 token 要调用哪些专家，运行时再用逐层 LRU、热门专家固定区和提前一层预取，尽量让下一步所需权重已在更快的层级。放置改变的是等待时间，不应悄悄改变路由结果或模型精度。这是一个很重要的边界：许多“本地跑大模型”的演示，真正换掉的是量化精度、模型版本或激活策略；Colibrì 把这些与 I/O 优化分开记录。

flowchart LR
  R[MoE router] --> H{专家已在何处？}
  H -->|VRAM| G[直接计算]
  H -->|RAM| G
  H -->|NVMe| P[读取、预取与缓存]
  P --> G
  G --> U[更新热门专家记录]
  U --> H

项目的代码体积小并不代表安装成本小。运行时核心是 C，但模型容器仍要数百 GB，README 的快速开始也要求下载对应模型。对大模型而言，瓶颈从“能否装下全部权重”转成了磁盘带宽、可用 RAM、CPU 内核和缓存命中率。

为什么这次跑到榜前

这不是一个今天才创建的空仓库。GitHub API 显示它创建于 2026 年 7 月 1 日；9 月 13 日仍有多条合并与修复提交，且 v1.11.0 在当天 13:44 UTC 发布。最近版本加入了 GLM-5.3 相关的路由用量遥测与初始化修复，持续开发和 Today 的 +960 信号叠在一起，才构成这次值得关注的时点，而不是只看 2.9 万累计 star。

另一个背景是 MoE 模型的参数口径越来越容易造成误会。744B 是模型总参数，而一个 token 并不会计算完 744B。Colibrì README 给出的示例是：每个 token 大约激活 40B 参数，变化的被路由专家数据约 11 GB。这个稀疏性让“从慢层取一小部分”成为可探索的工程路径，也解释了为什么缓存策略会直接影响体验。

它也没有把这件事包装成一个无条件的速度承诺。项目的 基准文档 写得相当克制：在原始 25 GB RAM 开发机上，冷启动解码只有约 0.05 - 0.1 token/s；在 128 GB CPU-only 台式机上，热缓存可到约 1.8 token/s；6 张 RTX 5090 且专家全常驻的实验记录为 5.8 - 6.8 token/s。它们是不同机器、不同驻留条件下的测量值，不能被压成一条“普通电脑都能流畅跑 744B”的结论。

它和常见本地推理工具有什么不同

多数本地推理工具首先解决的是“选一个能装进设备的模型”。Colibrì 反过来把 MoE 的稀疏路由当作第一性条件：模型可以比快速内存大得多，只要每一步读取的专家集合足够小，并且前一轮使用情况能帮助下轮缓存。

这带来几个具体取舍。双 SSD 不是把两个盘简单拼成一个目录，而是为同一模型做经校验的镜像，让不同专家读请求分配到独立控制器；CPU、CUDA、Metal 和 Vulkan 后端也可以按硬件组合。另一方面，缓存历史可能对单一提示词过拟合，预取也可能在某些机器上拖慢速度。README 和基准协议都要求记录硬件、commit、模型容器、缓存状态、TTFT、命中率和原始日志，再做单变量对照。贡献与实验入口 比“跑出一个好看的 token/s”更接近它的项目核心。

项目还给出了量化与质量的边界：int4 容器并不等于无损。其质量章节报告了受限评测设置下的分数和 OLMoE 的 fp16 与 int4 对比，并说明需要同时检查量化、吞吐和输出质量。打算用于事实敏感、生产或长任务的读者，应当把这部分当作起点，而不是跳过它只看硬件截图。

适合谁先试

有大容量 NVMe、至少几十 GB 可用内存，并且愿意测量缓存与 I/O 的开发者，最适合拿它做实验。若目标是以可控成本研究 MoE 在不同硬件层级上的行为，Colibrì 把许多原本藏在推理框架内部的变量暴露了出来。

反过来，如果你只需要稳定、低延迟地调用一个模型，或者设备没有存放数百 GB 容器的空间，先选择尺寸与硬件匹配的模型更实际。首次尝试前至少应核实四件事：目标模型的下载许可和磁盘容量、系统支持的后端、自己的 SSD 冷读带宽，以及项目所列基准与自己的任务是否相近。colibri 最有意思的地方不在于宣称“人人都有一台大模型服务器”，而在于把那条不舒服的内存边界变成可以测量、修改和讨论的工程问题。

---

• 仓库：github.com/JustVugg/colibri