744B 参数的 MoE 模型，通常要什么硬件？至少一张 80GB 显存的旗舰卡，或者按小时计费的云 GPU 集群。colibri 偏不。这个 2026 年 7 月才上线的项目，用 25GB 内存的笔记本就把 GLM-5.2 跑起来了，代价只是速度慢到以分钟计。
项目名字来自意大利语”蜂鸟”，作者的自我定位是”Tiny engine, immense model”，微型引擎，庞大模型。蜂鸟几克重，一天却能拜访上千朵花；colibri 用不到 10GB 常驻内存，喂养一个 7440 亿参数的巨人。
它做的事一句话能说清：把 VRAM、RAM、NVMe 当成同一个权重池子的三层存储，专家参数按需从磁盘流式加载，模型不用装进内存，而是”住在”硬盘上。思路听起来简单，真正做成的人极少。
HN 上这个项目的 Show HN 帖拿到了 700 多分，顶评论只有一句：This is the hacker spirit（这就是黑客精神）。往下我会拆它凭什么配得上这句话，以及它离”能用”还有多远。
为什么值得关注
主流推理引擎的思路是”把模型塞进显存”，塞不下就量化，再不行就分片。colibri 换了个问法：为什么要全部驻留？GLM-5.2 是 MoE，744B 总参数里每 token 只激活约 40B，其中真正逐 token 变化的路由专家只有约 11GB。也就是说，绝大部分权重是”偶尔用到”的，不是”每步都要”的。
作者把这种设计叫 JIT for weights，类比代码的即时编译。稠密层、注意力、共享专家约 17B 参数，int4 量化后 9.9GB 常驻 RAM；19,456 个路由专家（每层约 19MB）放在磁盘上，路由器选到谁就加载谁。这套物理切分让”消费级硬件跑前沿模型”从口号变成了可验证的工程，也让 2.8T 参数的 Kimi K3 第一次有了个人电脑上的跑法。
纯 LRU 缓存会反复驱逐热点专家。colibri 记录路由历史到 .coli_usage，自动识别最热的专家固定在内存里，用久了推理会越来越快。这不是玄学，实测基于路由可预测性：提前一层预取，命中率 71.6%，预取延迟被路由器前置运行隐藏掉。
推测解码也做得很老实。原生 MTP（多 token 预测）头出草稿，主模型批量验证，配语法约束草稿，int8 头下接受率 39% 到 59%，每次前向多出 2.2 到 2.8 个 token。它”诚实”在 DRAFT=0 可以一键关掉，不像某些实现把推测算进基准里充数。
MLA KV 压缩 57 倍。576 floats/token 对 32,768，长上下文对话的内存压力降了一个数量级，KV 状态还能跨重启持久化到 .coli_kv，下次启动零重预填充。
这些技术拆开看，每一样都有人做过。colibri 的价值是把它们拧进一个零依赖的 C 引擎里，每模型家族一个 .c 文件，共享 safetensors 读取、量化解码、tiktoken 重实现，还保持了与 transformers oracle 逐 token 一致。
速度短板正在被 GPU 后端补上。Qwen3.6 的 CUDA 专家层实测从 1.44 到 10.05 tok/s，7 倍加速且与 CPU 输出逐位一致；DeepSeek V4 在 RTX 5080 加双 NVMe 上 prefill 快了 2.3 到 2.5 倍。Metal、Vulkan、HIP 后端让 Mac 和 AMD 用户也能用上异构加速，推理不再是纯 CPU 的独角戏。理论讲得再好，跑起来什么感觉？
上手什么感觉
跑起来比想象中直接。Release 页有 Linux/macOS/Windows 预编译包，解压即用；源码构建也就两步：
git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh
模型权重有三种来源，按难度从低到高排列：
-
Hugging Face 预转换容器，解压即用 -
官方分片自行转换，适合磁盘有限的人 -
直接下载原始 checkpoint，Kimi K3 和 DeepSeek V4 Flash 免转换
以 GLM-5.2 为例，启动对话只要一行：
COLI_MODEL=/nvme/glm52_i4 ./coli chat
命令体系相当完整：plan 看放置计划，doctor 做只读就绪检查，tune 测量并保存最快安全配置，web 启动 API 加仪表盘，serve 无头服务。想上双盘就加一个 COLI_MODEL_MIRROR 环境变量，带宽按两盘之和聚合。
常见卡点基本来自硬件而非软件：
-
冷启动极慢，25GB 内存机器只有 0.05 到 0.1 tok/s，第一条回复要等几分钟 -
NVMe 是硬门槛，机械盘或网络挂载盘直接瓶颈在 I/O -
磁盘占用按模型算，GLM-5.2 要 370GB，Kimi K3 更要 1.6TB -
SSD 磨损有真实担忧，README 给了明确警告，好在读多写少
如果你有 16GB 内存加一块 NVMe，从 Qwen3.6（约 20GB 权重）或 OLMoE（约 7GB）入手是风险最低的路径。硬件门槛摆在这，什么样的人真的需要它？
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 隐私敏感本地推理 | 开发者、企业 | 数据不出机器，无 API 调用 | 速度慢，只适合异步任务 |
| 离线编码助手 | 个人开发者 | 代码不离开本机，免订阅 | 0.3 到 2 tok/s，只够思考型任务 |
| 基准测试与研究 | 研究者 | 无云成本跑前沿模型 | 完整评测需要更快磁盘 |
| 边缘部署 | 现场工程师 | 无网络环境可用 | 需 370GB 以上存储 |
下面这些情况，就不建议碰它：
-
要交互式聊天速度 → 云 API 或小模型更现实，HN 上就有人说免费额度都比 1 token/分钟快 -
没有 NVMe 或 16GB 以下内存 → 基本不可用，这是物理限制 -
想微调、想跑非 MoE 模型 → colibri 是专用推理引擎，没有训练路径 -
生产吞吐要求 → 正经部署请用 GPU 集群，它从设计上就不是为吞吐而生
成本账也要算清楚。云上跑 GLM-5.2 级别模型按 token 计费，长对话、大批量任务一个月下来是实打实的账单；colibri 的固定成本是一次性的硬盘空间加电费，速度换成本。对预算敏感的个人开发者，这个交换未必不划算。项目本身值不值得聊，还得看社区靠不靠谱。
社区怎么样了
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 25,542（截至 2026-08-20） | 上线约 1.5 个月，月增超 1.4 万 |
| 核心维护者 | 1 人（JustVugg） | Bus Factor 高风险 |
| Open Issues | 92 | 增速快，响应活跃 |
| 协议 | Apache 2.0 | 商业友好 |
1,666 次提交，v1.7.0 已支持六个模型家族，8 月 20 日当天还在合 PR。这个更新节奏放在个人项目里相当夸张，README 提交记录里频繁出现 Claude 辅助开发的署名，一个人加 AI 撑起了主线。
HN 的热度是真实的。Show HN 帖从 453 分涨到 730 分以上、180 多条评论，顶评论是 This is the hacker spirit，作者回复：Thank you so much, it’s true! It all started with this spirit!（谢谢你，确实如此，一切始于这股精神）。有人把它和 Redis 作者 antirez 的 ds4 项目对比，作者直接承认灵感来源：Antirez is the number one!（antirez 是第一）。
务实派的质疑也在。一条高赞评论指出，对大多数项目来说，直接薅云厂商免费额度都比 1 token/分钟快。这话没错，但它忽略了一件事：colibri 真正在证明的，是存储层级参与推理这个方向，而不是跟云 API 比吞吐。
单人维护是最大的结构性风险。92 个 open issues 对全职团队都可能积压，何况是一个人加 AI 辅助。好在目前 Issue 响应速度没有拉胯，社区贡献者也进来了，Qwen3.6 引擎就是社区成员 kreuzzelg 的 PR 合进来的。聊完这些，就该说点得罪人的实话了。
我的真实看法
colibri 不是又一个 llama.cpp 的替代品，它是”存储层级参与推理”这个方向的实验证明。它证明了架构创新能抵消一部分算力差距，这件事比它本身能跑多快重要得多。
先说清楚它做不到什么。0.05 到 0.1 tok/s 的冷启动速度，意味着它是实验，不是产品。任何人拿它当日常聊天工具都会失望，这个期望管理必须做在前面。
但换个角度：一个意大利工程师，一台 12 核笔记本，25GB 内存，一个半月，做到了云厂商用整机柜 GPU 才能做到的事。744B 模型的推理，慢，但 token 级正确。这件事放在五年前是不可想象的。
还有一个很多人忽略的细节：每个模型家族是独立的 .c 文件，共享 st.h、quant.h、tok.h 这些单文件头，底层 bug 修一处，六个模型同时受益。这种工程结构是严肃系统的雏形，不是 demo 拼盘，跟那些”跑通就扔”的玩具项目有本质区别。
它和同类引擎的差异也值得单独说。kTransformers 做 GPU-CPU 异构放置，重心在显存不够时借 CPU 内存；llama.cpp 追求单机极致吞吐，模型必须整体驻留。colibri 把 NVMe 也拉进层级，用路由热力而不是简单 LRU 决定放置，解决的是同一类问题的更深一层。三者不是替代关系，是同一个方向上的不同深度。
技术上最让我服气的不是某个单一优化，而是”路由热力驱动”这个系统级思考：测路由热度决定专家放哪层，路由器提前一层跑，把预取延迟藏起来。这是把”磁盘慢”当成约束去设计，而不是事后补救。上面的流水线图就是这条链路的完整形态。
趋势判断：上升期无疑。v1.7.0 加入 Qwen3.6 和 OLMoE，模型家族从两个扩到六个；GPU 后端正在补齐速度短板，CUDA 专家层实测 7 倍加速，Metal、Vulkan、HIP 都在路上。当 2.8T 的 Kimi K3 都能在 32GB 内存机器上跑起来，这个项目的上限就远超”玩具”了。
风险也直说：单人维护、依赖 AI 辅助编码、核心性能数据大多来自作者自己的基准。第三方复现和社区 benchmark 还很少，需要时间验证。要把它放进生产链路，现在不是时候。
从提交节奏看，作者在一个半月里从 GLM-5.2 单模型扩到六个模型家族，还同步维护 Web 仪表盘、Tauri 桌面壳、Docker 镜像、Nix flake。个人项目铺这么多面，要么是极强的自律，要么是 AI 辅助把构建成本压到了历史最低。两种可能都有，对使用者来说结果都是好的。
说实话我到现在也没完全说服自己它”实用”。但这不妨碍它值得聊，值得关注，值得在硬件允许时亲手跑一次。
资源地址
值得跟，但有门槛
如果你的机器有 NVMe 加 16GB 以上内存，现在就可以从 Qwen3.6 或 OLMoE 入手：前者 20GB 权重就能体验完整 MoE 推理，后者 7GB 权重连 8GB 内存的机器都能跑。GLM-5.2 级别的体验，留给有 370GB 磁盘空间和耐心的人。动手前先跑一遍 ./coli doctor 做只读就绪检查，能省掉不少白等的时间。
如果你还在观望，盯两个指标：GPU 后端的成熟度，以及维护者数量是否从 1 变成 2 或更多。前者决定它能不能从”慢但正确”变成”可用”，后者决定它值不值得长期依赖，这两个信号在 Release notes 里都看得见。
我最后想说的是：colibri 最值钱的不是代码，是它证明了”装不下的模型”和”跑不动的硬件”之间，还隔着一层没人认真做的工程。蜂鸟很小，但它能悬停。