每日开源 · 第 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ìGitHubJustVugg/colibriStars2.8k 本周 Trending语言纯 C运行时Python仅转换工具协议Apache 2.0模型权重 MIT模型GLM-5.2744B 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 开源的 MLAMulti-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 层自带一个 MTPMulti-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**调采样参数后**topp0.7 → 命中率 11% →0.11 tok/s57%**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 官方推荐 temperature1.0、topp0.95。但 int4 量化会引入尾部噪声。colibrì 实测后改为 0.7/0.90牺牲极小多样性换稳定输出。**int4 单行不用 AVX2**批量 int4 乘法用 AVX2 指令确实快 1.8×。但单行batch1场景实测发现 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 11MinGW-w64 原生CPUgcc OpenMP AVX2推荐 12 核以上内存最低 16GB推荐 25GB引擎自动调整预算存储约 370-400GB 本地 NVMeext4/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 chatOpenAI 兼容 APIcolibrì 内置了一个 OpenAI 兼容的 HTTP 服务器可以用任何支持 OpenAI API 的客户端访问# 启动 API 服务 COLI_MODEL/nvme/glm52_i4 COLI_API_KEYlocal-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关键调优参数topp0.7— 自适应 expert top-p减少 30-40% 磁盘读取实测提速 1.6×MTP1— 启用多 token 推测解码需 int8 MTP head加速 2-3×THINK1— 启用 GLM-5.2 推理块Chain-of-ThoughtAUTOPIN0— 禁用学习缓存首次冷启动可设为 0后续开启–repin N— 每 N 个 token 自适应重新分配热专家到 RAM/VRAMGRAMMARfile.gbnf— 语法强制草稿结构化输出JSON/函数调用场景接受率接近 1.0COLI_CUDA1— 启用实验性 CUDA 后端可选KVSAVE0— 禁用 KV-cache 持久化节省磁盘写入DSA0— 禁用 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 基准测试 # 运行 SNAPD:\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 64GBpin ~40GB 热专家**预测 2-4 tok/s** 128-256GB 12核热缓存**预测 2-4 tok/smatmul 瓶颈** 同上 24-32核 或 AVX-512/VNNI 指令集**预测 5-15 tok/s可达交互级**速度天梯的关键变量内存大小 磁盘带宽 CPU 核数。**小 RAM 机器的瓶颈不是磁盘而是内存上限本身——引擎的 RAM 安全保护机制会自动限制缓存大小。社区实验中9950X PCIe 5.0 NVMe8.81GB/s的瓶颈已经从 66% 磁盘转移到了 57% matmul 计算——这意味着硬件升级的边际效应是有拐点的。七、它不适合什么场景❌生产环境实时对话— 速度远不及云端 APIGPU 推理快 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 更方便欢迎在评论区聊聊你的看法。 相关链接 GitHubJustVugg/colibri 预转换模型Hugging Face int4 参考项目antirez/ds4Redis 作者的同领域探索 HN 讨论730 points, 180 comments—— 每日开源 · 第 091 期 · 2026-07-12 早间篇 ——每天一个值得深读的开源项目。本工具依赖境外公开数据源部分平台在中国大陆需合规网络环境。