github一周涨11k⭐️！25GB 内存跑 744B GLM-5.2 模型！

大家好这里是AIWritePaper官方账号~

如果一台机器没有高端 GPU，只有约 25GB 可用内存，它能运行 7440 亿参数的大模型吗？

按照常规部署思路，答案几乎一定是否定的。开源项目 Colibrì 换了一个切入点：它利用混合专家模型（MoE）的稀疏激活特性，把大部分专家权重留在磁盘上，用到时再流式读取。整个模型无须同时挤进内存。

最终效果是：GLM-5.2 这类 744B MoE 模型，可以在消费级机器上启动并完成推理。生成速度很慢，“磁盘、内存与显存统一分层”的实现思路仍值得研究。

• 标识：JustVugg/colibri
• 链接：https://github.com/JustVugg/colibri
• 分类：trending
• Stars⭐️：11951
• 周增：+11564⭐️
• 语言：C
• 许可：Apache-2.0
• 最近提交：2026-07-14
• 简介：Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 🐦

一、Colibrì 是什么？

Colibrì 是一个面向超大 MoE 模型的轻量推理运行时。它的核心推理引擎用纯 C 编写，运行阶段无需 Python 和 BLAS；没有 GPU 也能启动完整推理流程。

项目当前以 GLM-5.2 为主要目标模型，其关键数据如下：

指标	典型值
模型总参数量	744B
每个 token 激活参数量	约 40B
int4 模型磁盘占用	约 370GB
稠密部分常驻内存	约 9.9GB
对话时峰值内存	约 20GB（自动限制）
模型加载时间	约 30 秒
冷缓存生成速度	约 0.05～0.1 token/s

它与 vLLM、llama.cpp、高性能 GPU 集群面对的需求不同。Colibrì 关心的是容量极限：硬件资源明显不足时，能否保留模型精度和路由语义，让完整模型真正运行起来？

二、核心思路：把磁盘纳入模型内存层级

MoE 模型的参数总量很大，每次推理只激活其中少量专家。GLM-5.2 每个 token 大约激活 40B 参数，其中会随路由结果变化的专家权重约为 11GB。

Colibrì 据此把权重分成两类：

1. 注意力层、共享专家、嵌入层等稠密部分，以 int4 形式常驻内存，约占 9.9GB。
2. 21,504 个路由专家保存在磁盘上，总计约 370GB；每层实际需要哪些专家，就按需读取哪些专家。

实际运行时形成了四级存储结构：

过去，模型权重主要由显存和内存承担。Colibrì 把操作系统页缓存和磁盘也纳入运行时调度，由四层存储共同承接模型权重。

三、为什么它真的能跑起来？

1. MoE 稀疏路由

GLM-5.2 使用 DeepSeek-V3 风格的 Sigmoid 路由器。每处理一个 token，路由器从每层 256 个专家中选择 8 个，其余专家不参与这一步计算。

Colibrì 因而不需要一次读入全部专家权重，只需加载当前路径上被选中的专家。

2. 压缩 MLA KV Cache

GLM-5.2 使用 MLA（Multi-head Latent Attention），拥有 64 个头且没有 GQA。若按常规方式保存 KV Cache，单个 token 需要保存 32,768 个浮点数。

Colibrì 利用 q/kv-LoRA 压缩表示，将其降到每 token 576 个浮点数，缩小约 57 倍。项目给出的实际 KV Cache 开销约为每 token 182KB。

如果没有这一层压缩，即使专家权重能够从磁盘流式读取，上下文增长带来的 KV Cache 也会迅速吃光内存。

3. DSA 稀疏注意力

项目实现了 GLM-5.2 的 Lightning Indexer，每层只选择 top-2048 个因果键参与注意力计算。官方仓库说明，该实现通过了与稠密注意力逐 token 对齐的验证。

4. Batch-union MoE

在提示词预填充和 MTP 验证阶段，同一个 batch 内可能有多个位置命中同一个专家。Colibrì 会合并这些请求，让每个唯一专家只从磁盘读取一次，再应用到所有相关位置，减少重复 I/O。

5. 专家缓存与预读

项目为每层维护 LRU 专家缓存，并利用操作系统页缓存作为额外缓存层。计算当前专家时，异步预读下一批专家；还可以通过实验性的PILOT=1，根据当前层状态预测下一层路由并提前读取。

四、从论文看懂 Colibrì 的技术来源

Colibrì 用一个很小的运行时组合了近几年 MoE 架构和低资源推理中的多项成果。要看懂这套组合，可以顺着四个问题往下追：模型为何能够稀疏运行，KV Cache 如何压缩，磁盘怎样参与推理，以及串行生成次数能否减少。

1. Switch Transformer：让总参数量与单 token 计算量脱钩

​​Switch Transformershttps://arxiv.org/abs/2101.03961Fedus、Zoph 和 Shazeer 在 这篇论文中系统展示了稀疏激活模型的扩展方式：路由器根据输入，只让少量专家参与一次前向计算，因此模型可以增加大量参数，而单个样本的计算量不必同比增长。

这给 Colibrì 提供了成立条件。744B 是 GLM-5.2 的总容量，每生成一个 token 时无须把全部 744B 参数从磁盘读一遍。运行时保留稠密公共部分，再加载当前路由选中的专家。

这里有一个容易混淆的边界。稀疏激活节省的是计算工作集，完整模型的存储成本依旧存在。所有专家保存在约 370GB 的模型文件中；进入快速内存的部分只包含公共权重、当前专家和缓存专家。

2. DeepSeek-V2：MLA 控制不断增长的 KV Cache

DeepSeek-V2https://arxiv.org/abs/2405.04434这篇论文提出了 Multi-head Latent Attention（MLA）。传统多头注意力会为每个历史 token 保存各头的 Key 和 Value；上下文越长，KV Cache 越大，而且解码阶段需要持续从内存读取这些数据。

MLA 使用低秩联合压缩，把 Key/Value 表示收进更小的潜在向量中。每个注意力头无需保留两份完整档案，只保存一份能够恢复所需信息的压缩底稿。

Colibrì 进一步使用权重吸收技巧，让查询端吸收相关投影，避免每次解码都把压缩表示完整重建。对 GLM-5.2 而言，它将每 token 的缓存从 32,768 个浮点数压到 576 个，约缩小 57 倍。这解决的是另一类容量问题：即使权重可以流式加载，也不能让 KV Cache 随上下文长度失控。

3. DeepSeek-V3：无辅助损失路由与 MTP 如何进入推理系统

DeepSeek-V3 技术报告https://arxiv.org/abs/2412.19437这篇论文提出了无辅助损失的负载均衡策略，并将 Multi-Token Prediction（MTP）作为训练目标。前者通过调整专家偏置来改善负载分配，避免过强的辅助损失干扰模型主目标；后者让模型在训练时学习预测后续多个 token。

在 Colibrì 中，这两项技术分别落在两个位置：

• 推理引擎需要精确复现模型的 Sigmoid 路由、专家选择和缩放语义，否则加载的专家会从根本上出错；
• GLM-5.2 自带的 MTP 头可以直接充当草稿模型，不必另外加载一个独立小模型。

这也解释了为什么 MTP 头的量化精度如此关键：草稿只要频繁猜错，主模型仍要执行验证，还会额外触发更多专家读取。在磁盘冷缓存下，错误草稿的 I/O 成本甚至可能抵消推测解码的收益。

4. DeepSeek-V3.2 与 GLM-5：稀疏注意力把“回看全部历史”改成“检索相关历史”

DeepSeek-V3.2https://arxiv.org/abs/2512.02556这篇论文给出了 DeepSeek Sparse Attention（DSA）的训练与结构说明：轻量索引器先对历史 Key 评分，再选出 top-k KV 条目执行真正的注意力计算。GLM-5 系列的技术报告则说明了 Lightning Indexer、Sparse Flash Attention 及 MLA 预处理融合在其架构中的工程实现。

稠密注意力要求每个新 token 都与全部历史 token 交互。DSA 会先做一次成本较低的相关性筛选，主要注意力计算只读取最重要的历史位置。这个过程接近“先查索引再读正文”，省去了每次查询都扫描整本书的开销。

Colibrì 复现了 GLM-5.2 的 top-2048 因果键选择。主要注意力计算量随之下降，索引器自身仍要完成评分和 top-k。实际加速通常低于理论 FLOPs 的缩减比例。

5. FlexGen：把 GPU、CPU 和磁盘视为一个统一内存层级

FlexGenhttps://arxiv.org/abs/2303.06865这篇论文研究了资源有限条件下的大模型推理。论文联合使用 GPU、CPU 和磁盘，并通过调度与量化协调容量、吞吐量和延迟。这样一来，完整模型无需同时装进显存也能执行推理。

Colibrì 与 FlexGen 的共同点，是都承认低速存储可以参与推理；区别在于 FlexGen 主要面向批处理吞吐量优化，而 Colibrì 利用 MoE 的专家稀疏性，让单用户、低 batch 解码只读取被路由命中的权重。

卸载仍然需要搬运数据。显存容量压力缓解后，I/O 调度随即成为主要矛盾。Colibrì 的冷缓存速度受 SSD 带宽支配，这个限制来自必须读取的专家权重规模，单靠代码优化无法抹平。

6. MoE-Infinity：专家复用为什么能让热缓存产生价值

MoE-Infinityhttps://arxiv.org/abs/2401.14361这篇论文专门研究个人设备上的 MoE 推理。论文发现，在单用户、batch size 为 1 的解码场景中，专家激活具有明显的稀疏性、偏斜性和时间局部性：少量专家会在同一请求中被反复使用。

这为 Colibrì 的分层 LRU、热点专家固定和路由预取提供了原理解释。如果专家选择完全随机，缓存几乎不会命中，磁盘流式方案只能一直承受冷读成本；正是激活局部性，才让持续对话逐渐从“读磁盘”转向“复用内存与页缓存”。

率。持续处理相近任务时，Colibrì 更容易吃到缓存收益；大量互不相关的一次性请求很难获得同样效果。

7. Speculative Decoding：为什么可以一次 forward 验证多个 token

Fast Inference from Transformers via Speculative Decodinghttps://arxiv.org/abs/2211.17192Leviathan、Kalman 和 Matias 在这篇论文中提出了一种“先草拟、后验证”的解码方法：较便宜的草稿模型先生成多个候选 token，目标模型再用一次并行前向计算验证这段候选。

自回归模型原本需要“生成一个 token—再次运行模型—再生成一个 token”的严格串行流程。推测解码保留了目标模型单次前向的成本。草稿接受率足够高时，一次目标模型计算可以确认多个 token，forward 次数随之下降。

Colibrì 使用 GLM-5.2 自身的 MTP 头作为草稿器，还加入了 GBNF 语法草稿。对 JSON 中确定的大括号、引号和键名等片段，语法约束往往比神经草稿更准确。所有候选仍需主模型验证，这项机制只减少解码时间，不会绕过模型改写输出内容。

8. 把这些论文串起来

把上述研究沿着一次推理过程排列，可以得到 Colibrì 的技术链路：“25GB 内存运行 744B”来自多项技术的叠加。参数激活、注意力访问和专家工作集都有稀疏性，推测解码又减少了自回归验证次数。少了其中任何一环，容量或速度都会碰到新的瓶颈。

五、性能真相：冷缓存速度只有 0.05～0.1 token/s

Colibrì 最值得肯定的一点，是项目没有回避物理限制。在冷缓存状态下，一个 token 大约需要从磁盘读取 11GB 专家权重。如果设备随机读取上限约为 1GB/s，再叠加分散 I/O 与计算成本，实际速度只有约 0.05～0.1 token/s。落到实际使用中，会出现几个直接结果：

• 初次运行或工作负载频繁变化时，体验会非常慢；
• 持续处理相似任务后，热点专家进入内存或页缓存，速度才会改善；
• 它更适合架构研究、正确性验证和“先让模型跑起来”，不适合替代在线推理服务；
• NVMe SSD 基本是必需品，机械硬盘不具备实用性。

项目还支持把热点专家固定在更快的内存层级，并提供可选的 CUDA 与 Metal 后端。加入 GPU 后，权重依旧采用分层放置；完整模型仍然无需常驻显存。

六、MTP 推测解码为什么必须关注精度？

GLM-5.2 自带 Multi-Token Prediction（MTP）头，Colibrì 可以用它生成草稿 token，再由主模型批量验证。官方仓库给出的社区测量结果是：

• int8 MTP 头接受率约为 39%～59%；
• 每次 forward 可得到约 2.2～2.8 个 token；
• 若把 MTP 头也量化为 int4，接受率会跌到 0%～4%，推测解码基本失效。

因此，下载预转换模型时不能只看主体权重是否为 int4，还要确认三个 MTP 输出文件使用的是 int8 版本。

量化整数内核会因 batch 形状不同产生微小舍入差异。开启 MTP、GPU 专家层或批量预填充后，贪心解码结果可能无法与单 token 路径逐字节一致。业务要求严格复现时，可以关闭推测解码，并固定内核与 GPU 路径：

DRAFT=0 IDOT=0 COLI_CUDA=0 ./coli chat

七、结构化输出还有一条巧妙的加速路径

除了 MTP，Colibrì 还支持 GBNF 语法引导的推测草稿：

GRAMMAR=schema.gbnf ./coli chat

在 JSON、NDJSON、函数调用等任务中，大括号、引号、固定键名和枚举值往往是确定的。如果某个位置只允许一个合法字节，语法本身就能提供草稿，理论接受率接近 1。

这些草稿仍会交给主模型验证。错误或不同步的语法会导致草稿被拒绝，最终输出不会被静默篡改。对于结构化提取场景，这种方式比单纯依赖小模型草稿更有针对性。

八、安装与运行

安装命令适用于 Linux、macOS 或 WSL2。x86 处理器需要 AVX2；Apple Silicon 也受支持。项目目前已经提供 Windows 11 原生 MinGW-w64 构建方式。

1. 克隆并构建

git clone https://github.com/JustVugg/colibri.git cd colibri/c ./setup.sh

setup.sh会检查编译环境、构建程序并执行自检。推理运行阶段使用纯 C；只有一次性的 FP8 转 int4 流程需要 Python 及相关库。

2. 准备模型

可以下载已经转换好的、带 int8 MTP 头的模型，也可以让 Colibrì 分片下载 FP8 权重并逐片转换：

./coli convert --model /nvme/glm52_i4

转换过程支持断点恢复，也无须让完整的 756GB FP8 检查点同时存在。实际操作仍建议准备约 400GB 可用的 NVMe 空间。

3. 运行前检查

COLI_MODEL=/nvme/glm52_i4 ./coli plan COLI_MODEL=/nvme/glm52_i4 ./coli doctor

plan用于检查磁盘、内存和可选显存的放置计划；doctor会以只读方式检查模型目录、配置、权重头、可用内存、CUDA 链接和预算安全性，不会真正启动推理。

4. 开始对话

COLI_MODEL=/nvme/glm52_i4 ./coli chat

也可以让程序自动应用规划好的分层方案：

COLI_MODEL=/nvme/glm52_i4 ./coli chat --auto-tier

5. 启动 OpenAI 兼容接口

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

当前接口以文本生成为主。一个模型进程同一时间只执行一条序列，并发请求进入队列，共用已经加载的模型进程。

九、适合什么场景？

Colibrì 比较适合以下用途：

• 研究 MoE 路由、专家缓存和磁盘流式加载；
• 在没有大规模 GPU 集群时验证完整 744B 模型行为；
• 测试 MLA、DSA、MTP 等架构细节；
• 处理对延迟不敏感的本地研究任务；
• 利用 GBNF 研究 JSON、函数调用等结构化输出；
• 评估显存、内存和磁盘统一分层的系统设计。

以下需求更适合选择常规 GPU 推理框架：

• 对首 token 延迟有严格要求的在线服务；
• 高频、低延迟的交互式应用；
• 缺少 NVMe 空间或内存预算非常紧张的设备；
• 希望安装后立即获得 GPU 推理速度的普通用户。

十、从 Colibrì 能学到什么？

“25GB 内存运行 744B 模型”负责吸引注意力，真正可复用的内容来自三个工程思路：

模型参数总量与每一步必须驻留的参数量之间存在很大差距。架构足够稀疏时，运行时就可以围绕真实工作集重新安排权重。

磁盘也能进入推理内存层级，代价会直接体现在延迟上。缓存、预读、热点统计和批量合并因此成了决定体验的关键环节。

量化同样需要看端到端效果。MTP 头从 int8 降到 int4 后，文件体积变小，接受率几乎归零，整体速度随之下降。只比较单个文件或算子的大小，很容易得出错误结论。

总结

Colibrì 在普通电脑上的生成速度依旧很慢。它完成的推进是让 744B 模型从容量上可运行，再通过缓存逐步改善连续对话体验。

磁盘的物理极限依然存在。Colibrì 依靠 MoE 稀疏性、压缩 KV Cache、专家缓存、异步预读和推测解码，把必须跨越的数据量压到可管理范围。

关注 LLM Infra 的读者可以跳过“无需 GPU”这句口号，直接看它对容量问题的处理：完整权重留在分层存储中，运行时只调度当前真正需要的数据。

项目地址：GitHub - JustVugg/colibri: Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 🐦 · GitHub

参考资料：

• Colibrì 官方仓库与 README：GitHub - JustVugg/colibri: Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 🐦 · GitHub
• 原始整理页面：JustVugg/colibri · 上手攻略 · 研究库
• Fedus, W., Zoph, B., & Shazeer, N. (2022). Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR, 23(120), 1–39. [2101.03961] Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity
• DeepSeek-AI. (2024). DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model. [2405.04434] DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
• DeepSeek-AI. (2024). DeepSeek-V3 Technical Report. [2412.19437] DeepSeek-V3 Technical Report
• DeepSeek-AI. (2025). DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models. [2512.02556] DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models
• Zhipu AI. (2026). GLM-5: From Vibe Coding to Agentic Engineering. [2602.15763] GLM-5: from Vibe Coding to Agentic Engineering
• Sheng, Y., et al. (2023). FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU. ICML 2023. [2303.06865] FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU
• Xue, L., et al. (2024). MoE-Infinity: Efficient MoE Inference on Personal Machines. [2401.14361] MoE-Infinity: Efficient MoE Inference on Personal Machines with Sparsity-Aware Expert Cache
• Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML 2023. [2211.17192] Fast Inference from Transformers via Speculative Decoding