colibrì : 1300 行 C 代码，25GB 笔记本，跑起 7440 亿参数大模型, 用纯 C 和 Claude 做了件所有人说不可能的事 | SSP Github Daily

每日开源 · 第 091 期 · 2026-07-12 早间篇

1300 行 C 代码，25GB 笔记本，跑起 7440 亿参数大模型

一个意大利开发者用纯 C 和 Claude 做了件所有人说不可能的事

**免责声明：**本工具依赖境外公开数据源（Hugging Face 模型权重、GitHub 开源代码），部分平台在中国大陆需合规网络环境访问。本文仅作技术研究分享，不构成任何投资或使用建议。

一、开篇

2026 年 7 月 6 日，GitHub 上出现了一个叫colibrì的项目。名字来自意大利语的"蜂鸟"——一种体重不过几克、每天访问上千朵花的小鸟。

它的作者叫JustVugg，一个之前几乎没有公开项目记录的开发者。他用10 天时间、约 1300 行纯 C 代码，在一台 12 核 CPU + 25GB 内存的普通笔记本上，成功运行了智谱 GLM-5.2——一个 744B 参数的 MoE 旗舰模型。

没有 GPU，没有 BLAS，没有 Python 运行时。零外部依赖。整个推理引擎就一个文件：glm.c。

他最诚实的一句话写在 README 里：“This is not fast.”冷启动只有 0.05 tok/s。你发一句话，它回一个字，你去倒杯咖啡回来，它正在回第二个字。

但它确实跑起来了。不是 demo，不是 mock。是完整的 744B 参数推理，输出和官方模型逐 token 对齐验证，32/32 完全通过。

一个在 25GB 笔记本上正确回答问题的 744B 前沿模型——2026 年 7 月 6 日之前，没有人做到过。

二、项目速览

项目名：colibrì

GitHub：JustVugg/colibri

Stars：2.8k+ 🔥 本周 Trending

语言：纯 C（运行时），Python（仅转换工具）

协议：Apache 2.0（模型权重 MIT）

模型：GLM-5.2（744B MoE），支持 OLMoE

最低硬件：16GB RAM + 370GB NVMe + AVX2 CPU

关键成就：25GB 笔记本跑 744B 模型，逐 token 验证通过

三、它能解决什么问题？

当下的 AI 基础设施叙事很简单：**大模型 = 大 GPU = 大钱。**跑一个 744B 参数的 GLM-5.2，正常需要一机房 H100 显卡——每张售价 3 万美金，光散热风扇就得配好几个。对于普通开发者来说，百亿甚至千亿级的前沿模型，永远是 API 那头的东西。

colibrì 在挑战这个预设。

它的核心洞察出奇简单：**MoE 模型虽然大，但每次推理只用一小部分。**GLM-5.2 有 744B 总参数，可每个 token 实际激活的只有约 40B——其中 17B 是 attention 和共享专家（每次都用），真正随 token 变化的路由专家只有约11GB。

那你为什么不把这 11GB 按需从 NVMe 固态硬盘读出来，而不是强行把全部 370GB 权重都塞进显存？

colibrì 的解法：

**1****Dense 部分常驻内存：**attention 层、共享专家、embedding（约 17B 参数），int4 量化后仅占 9.9GB

**2****路由专家躺磁盘：**21,504 个路由专家（75 层 × 256 experts + MTP head），约 370GB，按需流式加载

**3****LRU 缓存 + 学习热图：**频繁使用的专家自动 pin 在内存，越用越快

**4****OS page cache 做免费 L2：**被读过的专家页面留在系统缓存里，后续命中不再触发磁盘 IO

**必须指出的边界条件：这套方案只在 MoE 架构下成立。**对于 Dense 模型（比如 Llama 系列），每个 token 都要激活全部参数，磁盘流式加载会退化为"读全部权重"，速度只会更慢。colibrì 的成功，本质上是MoE 激活稀疏性的一次"结构性套利"。

四、核心亮点：1300 行 C 里的硬核技术栈

打开c/glm.c，你会发现这不是一个极简框架——它是一个完整的推理引擎，包含注意力计算、MoE 路由、量化反量化、分词器、采样器。每一项单独拿出来都能写一篇论文。

亮点一：MLA 权重吸收 — KV 缓存压缩 57 倍

GLM-5.2 使用 DeepSeek 开源的 MLA（Multi-head Latent Attention）。传统 attention 每个 token 要在 KV cache 里囤 32,768 个浮点数——序列越长，内存越炸。

colibrì 做了三件事：

**q/kv-LoRA 低秩分解：**将 KV 表示压缩为 576 个浮点数/ token，体积缩到原来的 1/57

**交错局部 RoPE：**partial RoPE 只在压缩后的空间里做旋转位置编码

**kv_b 权重吸收：**解码时 query 直接吸收 kv_b 投影矩阵，不逐 token 重建 k/v 张量——零额外开销

这套操作经过严苛验证：teacher-forcing 模式 32/32 token 完全匹配，greedy 模式 20/20 完全匹配，没有一丝精度损失。很多大厂官方实现都不敢用同样标准检验自己。

亮点二：MTP 推测解码 — int8 救了草稿头

GLM-5.2 第 78 层自带一个 MTP（Multi-Token Prediction）头，可以一次预测接下来的 token，再由主模型批量验证。colibrì 把它用在了推测解码上。

但刚上手时遇到了一个致命问题：默认 int4 量化的 MTP head 草稿接受率直接跌到0-4%——推测机制形同虚设。

作者把 MTP head 单独拉到 int8 精度——接受率瞬间飙到39-59%，每次前向传播稳定产出2.2-2.8 个有效 token。全程通过 rejection sampling 保持无损，相当于从 0.05 tok/s 直接乘 2-3 倍。

**⚠️ 冷缓存陷阱：**缓存冰冷时，每个验证通过的草稿都会触发额外专家路由（660→1100 loads/token），推测解码反而变慢。引擎内置了自适应保护——接受率低于 50% 自动关闭。

亮点三：学习型缓存 — 越用越快

colibrì 有一个独特的"肌肉记忆"：每次对话结束，引擎会把各专家的实际路由频率写入.coli_usage文件。下次启动时自动把最热的专家 pin 在内存里。

**使用次数越多→热缓存越多→磁盘 IO 越少→速度越快。**从社区数据看效果惊人：

**冷启动：**WSL2 + 25GB RAM + 1GB/s NVMe → 专家命中率 3-4% →0.07 tok/s

**调采样参数后：**topp=0.7 → 命中率 11% →0.11 tok/s（+57%）

**M5 Max + 128GB：**14.2GB/s 磁盘 + 学习 pin 23% 命中率 →1.06 tok/s

**Ryzen AI 9 HX 370：**128GB + PCIe4 NVMe + 46.7GB 学习 pin → 命中率 66% →0.37 tok/s（冷启后 5 轮的实测）

**9950X + PCIe 5.0 NVMe：**8.81GB/s + 学习 pin → 命中率 57%，瓶颈从 66% 磁盘翻转为57% matmul 计算→0.28 tok/s

注意最后一个数据特别有意思：当磁盘带宽上了 5GB/s 以后，瓶颈从 IO 转移到了CPU 矩阵乘法。硬件升级的边际效应不是线性的——这是个漂亮的小型系统工程发现。

亮点四：数据驱动的"认怂式"优化

colibrì 里有很多反直觉的决定，每一个都是实测出来的：

**采样参数不照搬官方：**GLM-5.2 官方推荐 temperature=1.0、topp=0.95。但 int4 量化会引入尾部噪声。colibrì 实测后改为 0.7/0.90，牺牲极小多样性换稳定输出。

**int4 单行不用 AVX2：**批量 int4 乘法用 AVX2 指令确实快 1.8×。但单行（batch=1）场景，实测发现 f32 反而更快——于是老老实实退回去。

**topp 不只是质量参数：**把 topp 从默认调到 0.7，专家命中率从 3-4% 飙升到 11%，速度近乎翻倍。采样策略影响着磁盘 IO 模式，这个发现是反直觉的。

**异步预读用 fadvise：**当前专家在做矩阵乘法时，引擎已经通过 posix_fadvise(WILLNEED) 通知内核"下一批数据马上用"，把 IO 等待藏在计算背后。

亮点五：一人一 AI 十天，1300 行 C 的极限

colibrì 的 commit 历史显示：**7 月 1 日首次提交，7 月 6 日发布初始引擎，10 天，36 个 commit。**每个重要 commit 的 Co-Authored-By 都写着：Claude Fable 5。

对比一下：llama.cpp 由 Georgi Gerganov 写了两年多才到今天这个规模。colibrì 用了 10 天。当然，llama.cpp 是通用框架，支持几十种模型；colibrì 是专用引擎，只服务 GLM-5.2。

但 10 天 vs 2 年，这个时间压缩比本身就说明了 AI 辅助编程正在改变什么。不是"快了 20%"那种量变，是**“一个人能做到原来需要一个团队才能做到的事情”**那种质变。

Redis 作者 antirez 也在做类似的事——他的 ds4 项目有一个 GLM-5.2 分支。而 JustVugg 在 HN 上说：“Antirez is the number one!” 两位独立开发者，殊途同归地探索同一个命题：MoE 稀疏性能否让消费级硬件跑前沿模型？

五、上手指南

环境要求

操作系统：Linux / WSL2 / macOS / Windows 11（MinGW-w64 原生）

CPU：gcc + OpenMP + AVX2，推荐 12 核以上

内存：最低 16GB，推荐 25GB+（引擎自动调整预算）

存储：约 370-400GB 本地 NVMe（ext4/NTFS，绝不可用网络/9p 挂载）

Python：仅离线转换需要（torch, safetensors, huggingface_hub, numpy）

快速开始

# 1. 克隆仓库 git clone https://github.com/JustVugg/colibri.git cd colibri/c # 2. 构建引擎（检查 gcc/OpenMP，编译，自测） ./setup.sh # 3. 下载并转换模型（一条命令，可断点续传） # 注意：需要约 400GB 可用空间 pip install torch safetensors huggingface_hub numpy ./coli convert --model /nvme/glm52_i4 # 4. 或直接下载预转换好的 int4 模型（更快） # https://huggingface.co/jlnsrk/GLM-5.2-colibri-int4 # 5. 启动聊天 COLI_MODEL=/nvme/glm52_i4 ./coli chat

OpenAI 兼容 API

colibrì 内置了一个 OpenAI 兼容的 HTTP 服务器，可以用任何支持 OpenAI API 的客户端访问：

# 启动 API 服务 COLI_MODEL=/nvme/glm52_i4 COLI_API_KEY=local-secret \ ./coli serve --host 127.0.0.1 --port 8000 \ --model-id glm-5.2-colibri # 用 curl 测试 curl http://127.0.0.1:8000/v1/chat/completions \ -H 'Authorization: Bearer local-secret' \ -H 'Content-Type: application/json' \ -d '{ "model": "glm-5.2-colibri", "messages": [{"role": "user", "content": "Hello"}], "stream": true }' # 启用 GLM-5.2 的推理思考模式 # 请求中加入 "enable_thinking": true

关键调优参数

topp=0.7— 自适应 expert top-p，减少 30-40% 磁盘读取，实测提速 1.6×

MTP=1— 启用多 token 推测解码（需 int8 MTP head），加速 2-3×

THINK=1— 启用 GLM-5.2 推理块（Chain-of-Thought）

AUTOPIN=0— 禁用学习缓存（首次冷启动可设为 0，后续开启）

–repin N— 每 N 个 token 自适应重新分配热专家到 RAM/VRAM

GRAMMAR=file.gbnf— 语法强制草稿，结构化输出（JSON/函数调用）场景接受率接近 1.0

COLI_CUDA=1— 启用实验性 CUDA 后端（可选）

KVSAVE=0— 禁用 KV-cache 持久化（节省磁盘写入）

DSA=0— 禁用 DSA 稀疏注意力（降低计算量但可能影响长文质量）

Windows 11 原生用户

# 安装 MinGW-w64 工具链 scoop install mingw-winlibs # 构建 cd c make glm.exe # GLM-5.2 引擎 make olmoe.exe # OLMoE 引擎 make iobench.exe # 磁盘 IO 基准测试 # 运行 SNAP=D:\glm52_i4 ./glm.exe 64 4 16 python coli chat --model D:\glm52_i4

六、性能全景与天花板

**🔴 当前基线（25GB 笔记本 + WSL2 VHDX ~1GB/s）：**0.05-0.1 tok/s 冷启动

**🟡 原生 Linux + PCIe4 NVMe + 32GB：**预测 0.5-1 tok/s

**🟢 PCIe5 NVMe 或 RAID0 + 64GB（pin ~40GB 热专家）：**预测 2-4 tok/s

**🟢 128-256GB + 12核（热缓存）：**预测 2-4 tok/s（matmul 瓶颈）

**🔵 同上 + 24-32核 或 AVX-512/VNNI 指令集：**预测 5-15 tok/s（可达交互级）

**速度天梯的关键变量：内存大小 > 磁盘带宽 > CPU 核数。**小 RAM 机器的瓶颈不是磁盘而是内存上限本身——引擎的 RAM 安全保护机制会自动限制缓存大小。社区实验中，9950X + PCIe 5.0 NVMe（8.81GB/s）的瓶颈已经从 66% 磁盘转移到了 57% matmul 计算——这意味着硬件升级的边际效应是有拐点的。

七、它不适合什么场景

❌生产环境实时对话— 速度远不及云端 API，GPU 推理快 1-2 个数量级

❌成本优化替换云 API— 云端免费额度按 token 算可能更便宜

❌Dense 模型推理— 非 MoE 模型无法从专家流式加载获益

❌多模态/工具调用— 当前仅支持纯文本，图像/音频/工具均不支持

但它为这些场景提供了独特价值：

✅离线批量推理— 完全本地，数据不离开机器，零 API 费用

✅学习与实验— 1300 行 C 代码，一个下午就能理解整个 MoE 推理系统的底层运作

✅概念验证— 证明了消费级硬件跑前沿模型的技术可行性

✅隐私敏感场景— 无网络依赖，无第三方数据泄露风险

✅Agent 离线集成— 作者正在开发 OpenCode 集成，让编码 Agent 在无网络环境下使用本地 744B 模型

八、今日总结

colibrì 不是一个实用性项目——没人会用 0.05 tok/s 做聊天机器人。但它回答了一个更深层的问题：“AI 能不能在消费级硬件上跑前沿模型？”答案是：能，只要模型的架构设计允许。

如果未来主流大模型继续向 MoE 架构收敛（这个趋势已经很明显了），那么"消费级硬件跑前沿模型"就不再是一个疯狂的实验，而是一个系统工程的优化问题。今天的 0.05 tok/s，明天可能就是 5 tok/s——需要的只是更快的 NVMe、更大的内存、更聪明的缓存策略。

colibrì 的终极意义也许不在于它跑得有多快，而在于它降低了"验证可能性"的门槛。当一个开发者用 10 天、1300 行 C、一个 AI 助手，就能做出"没有人认为可能"的东西——那意味着什么？

2026 年最值得关注的趋势，也许不是模型又变强了多少，而是人变强了多少。

📌 今日互动

如果你的笔记本有 32GB 内存 + PCIe4 NVMe，你愿意等 1 tok/s 的速度来本地跑一个 744B 模型吗？还是觉得云端 API 更方便？欢迎在评论区聊聊你的看法。

📎 相关链接

🔗 GitHub：JustVugg/colibri

🔗 预转换模型：Hugging Face int4

🔗 参考项目：antirez/ds4（Redis 作者的同领域探索）

🔗 HN 讨论：730+ points, 180+ comments

—— 每日开源 · 第 091 期 · 2026-07-12 早间篇 ——

每天一个值得深读的开源项目。本工具依赖境外公开数据源，部分平台在中国大陆需合规网络环境。