JustVugg/colibri 源：https://github.com/JustVugg/colibri 微型引擎，庞大模型。 在配备约25 GB RAM的消费级机器上运行 GLM-5.2 (744B参数MoE) —— 纯C语言实现，零依赖，通过从磁盘流式加载专家。

$ ./coli chat 🐦 colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · 流式CPU ✓ 32秒就绪 · 常驻内存9.9 GB › ciao! ◆ Ciao! 😊 今天有什么可以帮您？

思路

一个744B的混合专家模型每次只激活约40B参数——其中仅有约11B的参数因token而异（路由到的专家）。因此：

• 密集部分（注意力、共享专家、嵌入——约17B参数）以int4格式常驻RAM（约9.9 GB）；
• 21,504个路由专家（75个MoE层 × 256个专家 + MTP头部，每个约19 MB，int4格式）存储在磁盘上（约370 GB），按需流式加载，并配备每层LRU缓存、可选的固定热存储，以及OS页缓存作为免费L2。

引擎是一个单一的C文件（c/glm.c，约1,300行）加少量头文件。无BLAS，运行时无Python，无GPU。

已实现的功能

• 忠实的GLM-5.2 (glm_moe_dsa) 前向 —— 已通过transformers oracle验证token精确性（在具有实际架构的微型随机模型上，教师强制32/32，贪婪解码20/20）。
• MLA注意力（q/kv-LoRA，交错部分RoPE）带压缩KV缓存：每个token 576个float，而非32,768个（缩小57倍——GLM-5.2有64个头，且无GQA）。
• 类似DeepSeek-V3的sigmoid路由器（noaux_tc, routed_scaling_factor）、共享专家、前3层密集层。
• 原生MTP推测解码 —— GLM-5.2自身的多token预测头（第78层）草拟token，主模型在单次批量前向中验证。该头必须为int8（转换器默认如此）：int4时草稿接受率降至0–4%，推测永远不生效；int8时接受率为39–59%，每个前向2.2–2.8个token（社区测量，#8 (https://github.com/JustVugg/colibri/issues/8)）。无损——并且通过拒绝采样在采样时保持无损。来自同一测量的诚实说明：在冷缓存上，每个验证过的草稿会路由到额外的专家（约660 → 约1100次专家加载/token），因此推测在缓存/固定预热前可能净时间损失——适应性保护和DRAFT=0就是为此存在。
• 真实采样 —— 温度 + nucleus，默认值针对int4现实调优（0.7 / 0.90；官方1.0 / 0.95会从尾部采样量化噪声）。
• 整数点积内核（Q8_0风格int8激活，AVX2 maddubs）：int8矩阵乘法快1.4–2.5倍（测得119 GFLOP/s），int4批量快1.8倍——按形状测量决定路由（int4单行保持f32：测得较慢）。
• MLA权重吸收（DeepSeek技巧）用于解码：无需逐token的k/v重建——查询吸收kv_b，上下文在注意力之后投影。已验证精确：在所有地方强制吸收时，TF 32/32和生成20/20均通过。
• 异步专家预读：当一块专家正在被乘法运算时，内核已经在读取下一块（WILLNEED）。
• 量化内核：int8 / 打包int4 / 打包int2，逐行缩放，AVX2，使用时反量化。打包已验证与int8容器位一致。
• DSA稀疏注意力：进行中 —— 闪电索引权重（从FP8仓库提取的约108 GB，--indexer转换器模式）正在下载；索引器前向即将完成。在此之前，对于≤2048个token的上下文，注意力是密集且精确的。
• 批量联合MoE：在预填充（和MTP验证）中，每个批次的唯一专家读取一次，并应用于所有路由到它的位置。
• C语言字节级BPE分词器（GPT-2风格，带Unicode属性正则，320k合并）。
• RAM安全：专家缓存根据启动时的MemAvailable自动调整大小——诚实的峰值投影（工作集、KV、MTP行、重建缓冲区），确保内核OOM杀手永远不会触发。
• 离线FP8→int4转换器（c/convert_fp8_to_int4.py）：一次下载一个分片（约5 GB），反量化（128×128块缩放），重新量化为引擎容器，删除分片——756 GB的FP8检查点无需一次性存在于磁盘上。可恢复。

诚实数字（WSL2，12核，25 GB RAM，VHDX上的NVMe）

这不快。这是一个744B前沿级别的模型在价格低于一枚H100风扇的机器上正确回答。热缓存、固定热专家和MTP大大降低了有效响应延迟；剩下的由磁盘物理决定。

SSD磨损警告

冷启动对随机读取负担较重（~11 GB/token）。读取本身是安全的，但OS页缓存可能产生写入。大量使用可能加速廉价SSD的磨损。请谨慎使用并监控硬盘健康状况。

下载模型

一个预转换的GLM-5.2 int4模型（用于colibrì）可在Hugging Face上获取：https://huggingface.co/jlnsrk/GLM-5.2-colibri-int4

下载该仓库并将COLI_MODEL指向其目录： bash COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat 这完全跳过了FP8→int4转换步骤。感谢DatPat的帮助！

快速开始

``bash cd c ./setup.sh # 检查gcc/OpenMP，构建，自测

一个命令即可完成模型侧所有操作：逐分片下载GLM-5.2-FP8

（无需一次性拥有完整的756 GB），转换为int4容器，然后

转换MTP头部用于推测解码。任何点都可恢复。

转换（仅需）需要安装Python：pip install torch safetensors huggingface_hub numpy

./coli convert –model /nvme/glm52_i4 # 约需400 GB空闲空间，在真实的ext4/NVMe路径上

聊天 — RAM预算、专家缓存和MTP均自动检测：

COLI_MODEL=/nvme/glm52_i4 ./coli chat ``

运行时引擎是纯C语言——Python仅由一次性转换器使用。有用的旋钮（环境变量或标志）：--temp T token采样温度（默认0.7 + nucleus 0.90 —针对int4调优；0为贪婪），--topp 0.7 自适应专家top-p（磁盘减少30–40%），--ngen N 每个答案的最大token数（聊天中:piu可继续被截断的答案），AUTOPIN=0 禁用学习缓存的自动固定，THINK=1 启用GLM-5.2的推理块，DRAFT=n MTP草稿深度，TF=1 教师强制验证。

学习缓存：引擎会记录你的使用实际路由到的专家（模型旁边的.coli_usage，每轮更新），并在启动时自动将最热的专家固定在空闲RAM中。colibrì实际上用得越多越快。

有更好的机器？试试看——以下是预期

colibrì是在故意低配的硬件上构建的（12核，25 GB RAM，WSL2 VHDX后的NVMe，随机读取上限约1 GB/s）。这些约束中的每一个都是你的机器可以调高的旋钮。

引擎需要：Linux（或WSL2）、支持OpenMP的gcc、AVX2、≥16 GB RAM，以及存储在本地NVMe（ext4——绝不能是网络/9p挂载）上的约370 GB int4模型。

如何测试，按顺序：

``bash cd c && ./setup.sh # 构建 + 架构自测（期望32/32）

1) 按照引擎使用的方式测量你的磁盘（并行19 MB随机读取）：

gcc -O2 -fopenmp iobench.c -o iobench ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 0 # 缓冲式，8线程 ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 1 # O_DIRECT

2) 聊天；观察每轮统计行（tok/s，专家命中率，RSS）：

COLI_MODEL=/path/to/glm52_i4 ./coli chat

3) 记录专家使用情况，然后将最热的专家固定在空闲RAM中：

STATS=stats.txt ./coli chat PIN=stats.txt PIN_GB=20 ./coli chat # 根据你的空闲RAM调整PIN_GB

4) 质量基准（MMLU/HellaSwag/ARC）：

./coli bench ``

粗略预测（解码受磁盘限制：冷token需要约11.4 GB的专家读取；MTP推测大致将有效成本减半一旦缓存变热；RAM将冷读取转化为免费缓存命中）：

这些是估计值，不是测量结果——如果你在严肃硬件上运行colibrì，请提交issue并附上你的数字：来自更好机器的真实数据点正是该项目下一步所需的。

社区基准（实测）

来自真实机器的真实数字，默认构建（setup.sh，gcc 13），贪婪解码，--ngen 32，MTP启用：

要点：在24 GB RAM下，引擎自动将专家缓存限制为每层2个槽位，因此即使磁盘比开发机快2–2.7倍，解码仍保持冷状态——在小RAM机器上，RAM上限而非磁盘是限制因素，与上表预测完全一致；仅使用--topp 0.7就带来了1.6倍的端到端加速。M5 Max的数据点正好落在上表的第二行：744B模型在笔记本电脑SSD上约1 tok/s——而其14 GB/s的磁盘将瓶颈转移回RAM预算和内核。

质量基准——欢迎帮助

我们从未测量过int4量化在准确性上损失了多少——测试框架已构建并连接，但评分是每个答案选项一次前向，在开发机约1 GB/s的磁盘上，完整运行需要大半天。这是更快机器所能贡献的最有价值的单件事。 代码在此，已就绪；一个命令即可端到端运行（首次使用时会自动下载数据集）：

bash cd c ./coli bench # hellaswag, arc_challenge, mmlu — 每个40题 ./coli bench hellaswag --limit 200 # 单个任务，更多题目 ./coli bench mmlu arc_challenge --ram 100 # 选择任务，设置RAM预算

它会打印每个任务的准确率（对数似然评分，EleutherAI-harness风格）。已发布的GLM-5.2全精度在这些任务上的得分约为85–95%；如果我们的int4容器落在几个百分点内，则量化得到验证——如果没有，我们就知道要在混合/分组量化上投入精力。如果你有硬件运行此测试，请提交issue并附上数字——这是该项目缺少的测量数据。

支持项目

colibrì是一个单人项目，完全在一台12核、25 GB RAM的笔记本电脑上编写和测试——上述数字是我在家中能测量的上限。如果这个项目对你有用或有趣，并且你希望支持其开发（更好的测试硬件直接转化为更快的引擎，惠及所有人：真实的NVMe扩展数据、更大的固定缓存、在真实基准上的int2/int3质量扫描），你可以：

• ⭐ 给仓库加星并分享；
• 🐛 提交issue，附上你硬件的基准数字；
• 💬 通过GitHub issues联系我，如果你想赞助开发或捐赠硬件。

每一点贡献，从一个数据点到一块磁盘，都在提升上限。

仓库布局

c/glm.c 引擎（GLM-5.2前向、流式MoE、MTP、服务模式） c/st.h safetensors读取器：pread + fadvise，无mmap（RSS保持平坦） c/tok.h C语言字节级BPE分词器 c/coli CLI：chat / run / bench / convert / info c/iobench.c 并行磁盘微基准（测量引擎感知到的性能） c/convert_fp8_to_int4.py 磁盘安全的FP8→int4转换器 c/make_glm_oracle.py 用于验证的微型随机oracle生成器 c/olmoe.c 阶段A引擎（OLMoE），第一个验证目标

为什么叫“colibrì“

蜂鸟重几克，能悬停在空中，每天访问上千朵花。这个引擎让一个7440亿参数的巨物靠蜂鸟的口粮存活：25 GB RAM、12个CPU核心，以及大量的磁盘耐心。

许可证

Apache 2.0。GLM-5.2权重由Z.ai以MIT许可证发布。