744B 模型需要 1.5TB 显存——有人用 25GB 内存就跑起来了，但每秒只吐 0.05 个字

专家流式加载
发布于 2026-07-15 10:38:25 5 次浏览

744B 模型需要 1.5TB 显存——有人用 25GB 内存就跑起来了，但每秒只吐 0.05 个字

GLM-5.2，744B 参数，MoE 架构。FP16 精度需要约 1.5TB 显存。int4 量化后约 370GB。一张 RTX 5090 有 32GB 显存。

370GB > 32GB。结论很清楚：消费级硬件跑不了。

2026 年 7 月 1 日，一个叫 JustVugg 的开发者开源了 Colibrì——一个 2400 行纯 C 的推理引擎，在 25GB 内存的笔记本上跑起了 GLM-5.2。两周内 Star 数从 0 涨到 13,561。

但"跑起来了"和"能用"之间，隔着 0.05 tokens/s 的速度。

MoE 的漏洞：744B 参数，每次只用 40B

Colibrì 能跑起来的前提，藏在 MoE 架构本身。

GLM-5.2 有 75 个 MoE 层，每层 256 个专家，总共 19,456 个路由专家。但每生成一个 token，路由器只从每层挑 8 个专家参与计算。实际激活参数约 40B——只有总参数的 5.4%。

这意味着 94.6% 的参数在任何一个 token 的计算中都是闲置的。它们必须存在于模型中（因为不同的 token 会激活不同的专家），但它们不需要同时存在于内存中。

Colibrì 的核心洞察：既然 94.6% 的参数是闲置的，为什么要把它们放在昂贵的内存里？放在硬盘上，需要时再读，不行吗？

三层存储：显存→内存→硬盘

Colibrì 把模型参数分成三个层级：

层级 存放内容 大小 访问速度
GPU 显存 最热专家（可选 CUDA tier） 按显存大小动态分配 最快
系统内存 常驻参数 + LRU 热点专家缓存 9.9GB 常驻 + 缓存 中等
NVMe 硬盘 21,504 个路由专家（370GB） 370GB 最慢

常驻内存的部分（9.9GB）包括：注意力层、共享专家、词嵌入——这些每个 token 都要用，不能放硬盘。

路由专家全部放在硬盘上。当路由器选中某个专家时，引擎从硬盘读取它（约 19MB/专家），用完后放回 LRU 缓存。如果缓存命中，直接从内存读取；如果缓存未命中，就要等硬盘 I/O。

这就是速度瓶颈的根源：硬盘 I/O。

速度真相：从 0.05 到 4 tok/s

Colibrì 的 README 列出了不同硬件的实测数据：

硬件 内存 SSD 速度 冷启动 热缓存 瓶颈
WSL2 12核 25GB 25GB ~1 GB/s 0.05 tok/s ~0.1 tok/s 硬盘 I/O
M5 Max 128GB 128GB 快 SSD — ~1 tok/s 内存带宽
Ryzen 9800X3D + 5090 70GB 10.5 GB/s PCIe 5.0 — 0.52 tok/s 硬盘 I/O
DGX Spark (10×X925) 121GB 统一 5.58 GB/s 0.21 0.50 tok/s 计算
6×RTX 5090 192GB 显存 — — 4 tok/s 计算

关键发现：

  1. 冷启动极慢：25GB 内存的开发机上，冷缓存只有 0.05 tok/s——生成一个 100 字的回复需要约 33 分钟
  2. 热缓存也不快：即使缓存命中，0.1 tok/s 意味着 100 字需要 17 分钟
  3. 6×5090 才到 4 tok/s：这已经不是"消费级硬件"了——6 张 5090 约 18 万人民币
  4. Ryzen + 5090 反而比 DGX Spark 慢：因为 PCIe 5.0 SSD 的 I/O 吞吐是瓶颈，不是计算

0.05 tok/s 是什么概念？ 你打完一句话，去泡杯咖啡，回来它还没写完第一行。

为什么 llama.cpp 的 mmap 不行

你可能会问：llama.cpp 也有内存映射（mmap），为什么不能做同样的事？

Colibrì 的 README 和 Devsplainers 的视频都解释了这个问题：

llama.cpp 的 mmap 是按页（4KB）映射的，它不知道哪些页包含当前需要的专家。 当路由器选中第 37 层的第 142 号专家时，mmap 需要触发一次 page fault，操作系统从硬盘读入包含该专家的页。但一个专家约 19MB，跨多个页，每次推理需要读 8 个专家 × 75 层 = 600 次 page fault。

Colibrì 的做法不同：它知道路由器的选择，所以可以精确地预读（readahead）下一个需要的专家。 在当前层的专家正在计算时，I/O 线程已经在读取下一层的专家（WILLNEED 提示）。这种"计算与 I/O 重叠"是 mmap 做不到的——mmap 是被动的，只有 page fault 发生时才读。

此外，Colibrì 还有一个实验性的 Router-lookahead prefetch（PILOT=1）：下一层的路由结果有 71.6% 的概率可以从当前层的注意力状态预测出来。这意味着在当前层计算完成之前，下一层需要的专家可能已经在从硬盘读取了。

2400 行 C 代码里藏了多少黑科技

Colibrì 的核心代码只有一个文件：c/glm.c，约 2400 行。但里面塞了大量工程优化：

1. MLA 注意力 + 压缩 KV cache

GLM-5.2 用了 Multi-head Latent Attention（MLA），KV cache 压缩到 576 floats/token（原始 32,768，压缩 57×）。这意味着即使 262K 上下文，KV cache 也不会爆内存。

2. MTP 投机解码——但 int4 下基本废了

GLM-5.2 有原生的 Multi-Token Prediction（MTP）头，可以一次预测多个 token。但 README 诚实地说：int4 量化下 MTP 接受率只有 0-4%，投机基本不生效。 必须用 int8 量化 MTP 头才能达到 39-59% 接受率。而 int8 意味着更多内存占用。

更诚实的发现：即使 MTP 生效，冷缓存下每个验证的 draft 会触发额外的专家加载（660→1100 expert-loads/token），投机反而更慢——直到缓存热起来。

3. Grammar-forced 投机

这是 Colibrì 最巧妙的优化：在 JSON/函数调用等结构化输出场景，语法本身就是一个"免费"的 draft 来源。当语法只允许一个合法字符时（比如 { 后面必然是 "），这个字符直接注入为已接受的 draft，接受率接近 100%。不需要 MTP 头，不需要查找表。

4. DSA 稀疏注意力

GLM-5.2 的 lightning indexer，每层只选 top-2048 的 key 做注意力。Colibrì 忠实实现了这个机制，从 FP8 权重中提取 indexer（约 189MB）。

5. KV cache 持久化

对话重启后不需要重新 prefill——KV cache 保存到 .coli_kv 文件（约 182KB/token），下次启动直接加载，零 prefill 时间。

6. 安全加固

最近的 commit 加了 DLL 劫持防护（绝对路径加载 coli_cuda.dll）和恶意模型文件防护（safetensors/JSON 解析器加固）。这在开源推理引擎中很少见——说明项目已经到了被实际部署的阶段。

竞品横评：5 种跑大模型的方式

方案 原理 最低硬件 速度 精度保证
Colibrì 专家硬盘流式加载 25GB RAM + NVMe 0.05-4 tok/s ✅ 不降精度
llama.cpp mmap 内存映射整模型 需装下整模型 取决于内存 ✅
vLLM offloading GPU↔CPU 卸载 多 GPU + 大内存 1-10 tok/s ✅
Cloud API 远程推理 任何设备 20-100 tok/s 取决于服务商
蒸馏/剪枝 缩小模型 消费级 GPU 10-50 tok/s ❌ 质量下降

Colibrì 的独特定位：唯一一个"不降精度、不蒸馏、不剪枝"就能在 25GB 内存跑 744B 模型的方案。 代价是速度。

代价清醒

0.05 tok/s 不是"慢"，是"不可用"。 冷缓存下生成 100 字需要 33 分钟。这不是对话，这是批处理。热缓存 0.1 tok/s 也只是"勉强能看"——100 字需要 17 分钟。

硬盘 I/O 是硬天花板。 NVMe SSD 的顺序读取约 3-7 GB/s，但专家加载是随机读取（每次 19MB，散布在 370GB 中）。即使 PCIe 5.0 SSD，随机 I/O 吞吐也远低于顺序。Colibrì 的所有优化（readahead、PILOT 预取、LRU 缓存）都在缓解这个瓶颈，但无法消除它。

51 个 Open Issue，大部分是性能问题。 Windows 磁盘 I/O 2 tok/s（目标 ≤2）、GPUDirect Storage 绕过 CPU-RAM 瓶颈、异步 I/O、AMX 加速——全是待办事项列表说明当前版本远未成熟。

MTP 投机在 int4 下基本废了。 官方数据：int4 接受率 0-4%。int8 才能到 39-59%，但 int8 意味着 MTP 头占更多内存。冷缓存下投机反而更慢（额外专家加载）。

int4 量化的非确定性。 README 诚实承认：量化后的整数内核是 shape-dependent 的，batched forward 和 single-token forward 的舍入不同，可能导致 argmax 翻转。MTP、CUDA tier、batched prefill 三种方式都可能触发这个敏感性。同一个 prompt，不同配置可能产生不同输出——但每个输出本身是正确的。

370GB 硬盘空间。 21,504 个专家 int4 量化后约 370GB。你需要一块足够大的 NVMe SSD，而且最好不是系统盘——系统盘的 I/O 会被其他进程抢占。

Windows 支持不完善。 Issue #257/#256 显示 Windows 的磁盘 I/O 性能远低于 Linux（2 tok/s vs Linux 上的更快速度）。WSL2 是目前 Windows 用户的推荐方案，但 WSL2 的 I/O 也有额外开销。

巴士因子约 3。 JustVugg 贡献 74 次，ZacharyZcR 22 次，woolcoxm 11 次。前三位贡献者占 85%+ 的 commit。如果 JustVugg 停止维护，项目可能停滞。

SSD 寿命不是问题。 Devsplainers 视频专门澄清：SSD 的磨损来自写入，不是读取。Colibrì 只读专家，不写（除了 KV cache），所以不会显著缩短 SSD 寿命。

判断

Colibrì 的核心贡献不是"让 744B 模型跑得快"——它跑得很慢。核心贡献是证明了"模型必须完整装入内存"这个前提是可以打破的。

MoE 架构的稀疏性（5.4% 激活率）创造了一个工程漏洞：94.6% 的参数是闲置的，可以放在更慢的存储层。Colibrì 用 2400 行 C 代码把这个漏洞变成了可运行的系统。

但"可运行"和"可用"之间，隔着硬盘 I/O 的物理天花板。NVMe SSD 的随机读取速度决定了 Colibrì 的速度上限——目前这个上限在消费级硬件上约 0.05-1 tok/s。要达到对话可用的 10+ tok/s，需要 6×5090 级别的硬件——而那个级别的硬件本来就能用传统方式跑模型。

Colibrì 的真正价值不在当下，而在方向：它定义了"存储层级推理"这个范式。 未来的 NVMe 速度会更快（PCIe 6.0）、MoE 模型的激活率可能更低（更稀疏）、Router-lookahead 预取可能更准。当这些变量改善时，Colibrì 的架构会自然变快——不需要重写。

如果你是研究者，Colibrì 的 expert streaming + readahead + PILOT 预取值得深入研读——这是"存储层级推理"的工程范本。如果你是普通用户，0.05 tok/s 不适合任何实际工作——用 Cloud API 更现实。如果你有 6×5090，Colibrì 可以让你在跑其他模型的同时，额外挂一个 744B 的 GLM-5.2 作为备用。

蜂鸟只有几克重，却能悬停、振翅、造访无数花朵。但蜂鸟的翅膀每秒要拍 80 次——Colibrì 的硬盘也在以类似的频率读取专家。区别在于：蜂鸟的翅膀不会卡在 page fault 上。

相关链接：

评论

暂无评论。

登录后可发表评论。

目录