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分类trendingStars⭐️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 激活参数量约 40Bint4 模型磁盘占用约 370GB稠密部分常驻内存约 9.9GB对话时峰值内存约 20GB自动限制模型加载时间约 30 秒冷缓存生成速度约 0.050.1 token/s它与 vLLM、llama.cpp、高性能 GPU 集群面对的需求不同。Colibrì 关心的是容量极限硬件资源明显不足时能否保留模型精度和路由语义让完整模型真正运行起来二、核心思路把磁盘纳入模型内存层级MoE 模型的参数总量很大每次推理只激活其中少量专家。GLM-5.2 每个 token 大约激活 40B 参数其中会随路由结果变化的专家权重约为 11GB。Colibrì 据此把权重分成两类注意力层、共享专家、嵌入层等稠密部分以 int4 形式常驻内存约占 9.9GB。21,504 个路由专家保存在磁盘上总计约 370GB每层实际需要哪些专家就按需读取哪些专家。实际运行时形成了四级存储结构过去模型权重主要由显存和内存承担。Colibrì 把操作系统页缓存和磁盘也纳入运行时调度由四层存储共同承接模型权重。三、为什么它真的能跑起来1. MoE 稀疏路由GLM-5.2 使用 DeepSeek-V3 风格的 Sigmoid 路由器。每处理一个 token路由器从每层 256 个专家中选择 8 个其余专家不参与这一步计算。Colibrì 因而不需要一次读入全部专家权重只需加载当前路径上被选中的专家。2. 压缩 MLA KV CacheGLM-5.2 使用 MLAMulti-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 专家缓存并利用操作系统页缓存作为额外缓存层。计算当前专家时异步预读下一批专家还可以通过实验性的PILOT1根据当前层状态预测下一层路由并提前读取。四、从论文看懂 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-V2MLA 控制不断增长的 KV CacheDeepSeek-V2https://arxiv.org/abs/2405.04434这篇论文提出了 Multi-head Latent AttentionMLA。传统多头注意力会为每个历史 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 PredictionMTP作为训练目标。前者通过调整专家偏置来改善负载分配避免过强的辅助损失干扰模型主目标后者让模型在训练时学习预测后续多个 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 AttentionDSA的训练与结构说明轻量索引器先对历史 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 验证多个 tokenFast Inference from Transformers via Speculative Decodinghttps://arxiv.org/abs/2211.17192Leviathan、Kalman 和 Matias 在这篇论文中提出了一种“先草拟、后验证”的解码方法较便宜的草稿模型先生成多个候选 token目标模型再用一次并行前向计算验证这段候选。自回归模型原本需要“生成一个 token—再次运行模型—再生成一个 token”的严格串行流程。推测解码保留了目标模型单次前向的成本。草稿接受率足够高时一次目标模型计算可以确认多个 tokenforward 次数随之下降。Colibrì 使用 GLM-5.2 自身的 MTP 头作为草稿器还加入了 GBNF 语法草稿。对 JSON 中确定的大括号、引号和键名等片段语法约束往往比神经草稿更准确。所有候选仍需主模型验证这项机制只减少解码时间不会绕过模型改写输出内容。8. 把这些论文串起来把上述研究沿着一次推理过程排列可以得到 Colibrì 的技术链路“25GB 内存运行 744B”来自多项技术的叠加。参数激活、注意力访问和专家工作集都有稀疏性推测解码又减少了自回归验证次数。少了其中任何一环容量或速度都会碰到新的瓶颈。五、性能真相冷缓存速度只有 0.050.1 token/sColibrì 最值得肯定的一点是项目没有回避物理限制。在冷缓存状态下一个 token 大约需要从磁盘读取 11GB 专家权重。如果设备随机读取上限约为 1GB/s再叠加分散 I/O 与计算成本实际速度只有约 0.050.1 token/s。落到实际使用中会出现几个直接结果初次运行或工作负载频繁变化时体验会非常慢持续处理相似任务后热点专家进入内存或页缓存速度才会改善它更适合架构研究、正确性验证和“先让模型跑起来”不适合替代在线推理服务NVMe SSD 基本是必需品机械硬盘不具备实用性。项目还支持把热点专家固定在更快的内存层级并提供可选的 CUDA 与 Metal 后端。加入 GPU 后权重依旧采用分层放置完整模型仍然无需常驻显存。六、MTP 推测解码为什么必须关注精度GLM-5.2 自带 Multi-Token PredictionMTP头Colibrì 可以用它生成草稿 token再由主模型批量验证。官方仓库给出的社区测量结果是int8 MTP 头接受率约为 39%59%每次 forward 可得到约 2.22.8 个 token若把 MTP 头也量化为 int4接受率会跌到 0%4%推测解码基本失效。因此下载预转换模型时不能只看主体权重是否为 int4还要确认三个 MTP 输出文件使用的是 int8 版本。量化整数内核会因 batch 形状不同产生微小舍入差异。开启 MTP、GPU 专家层或批量预填充后贪心解码结果可能无法与单 token 路径逐字节一致。业务要求严格复现时可以关闭推测解码并固定内核与 GPU 路径DRAFT0 IDOT0 COLI_CUDA0 ./coli chat七、结构化输出还有一条巧妙的加速路径除了 MTPColibrì 还支持 GBNF 语法引导的推测草稿GRAMMARschema.gbnf ./coli chat在 JSON、NDJSON、函数调用等任务中大括号、引号、固定键名和枚举值往往是确定的。如果某个位置只允许一个合法字节语法本身就能提供草稿理论接受率接近 1。这些草稿仍会交给主模型验证。错误或不同步的语法会导致草稿被拒绝最终输出不会被静默篡改。对于结构化提取场景这种方式比单纯依赖小模型草稿更有针对性。八、安装与运行安装命令适用于 Linux、macOS 或 WSL2。x86 处理器需要 AVX2Apple Silicon 也受支持。项目目前已经提供 Windows 11 原生 MinGW-w64 构建方式。1. 克隆并构建git clone https://github.com/JustVugg/colibri.git cd colibri/c ./setup.shsetup.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 doctorplan用于检查磁盘、内存和可选显存的放置计划doctor会以只读方式检查模型目录、配置、权重头、可用内存、CUDA 链接和预算安全性不会真正启动推理。4. 开始对话COLI_MODEL/nvme/glm52_i4 ./coli chat也可以让程序自动应用规划好的分层方案COLI_MODEL/nvme/glm52_i4 ./coli chat --auto-tier5. 启动 OpenAI 兼容接口COLI_MODEL/nvme/glm52_i4 \ COLI_API_KEYlocal-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ì 官方仓库与 READMEGitHub - 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 SparsityDeepSeek-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 ModelDeepSeek-AI. (2024). DeepSeek-V3 Technical Report. [2412.19437] DeepSeek-V3 Technical ReportDeepSeek-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 ModelsZhipu AI. (2026). GLM-5: From Vibe Coding to Agentic Engineering. [2602.15763] GLM-5: from Vibe Coding to Agentic EngineeringSheng, 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 GPUXue, 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 CacheLeviathan, Y., Kalman, M., Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML 2023. [2211.17192] Fast Inference from Transformers via Speculative Decoding