Colibri 让消费级硬件跑起 GLM-5.2，代价是什么？

Colibri 确实能在约 25 GB RAM 的机器上执行 GLM-5.2。但这台机器不会因此变成“本地 Claude”。开发者实测的冷缓存速度只有 0.05-0.1 token/s，也就是每 10-20 秒生成一个 token，而且还没算 prompt 处理。100 个 token 的短回答大约要 17-33 分钟。

技术成果本身是真的。Colibri 让一台根本无法在 RAM 或 VRAM 中容纳完整模型的电脑，执行一个 7440 亿参数的 Mixture-of-Experts 模型。它把 NVMe、系统内存和可选的显存当成同一套分层内存。代价很直接：磁盘提供容量，读取延迟由每个 token 支付。

本文基于 2026 年 7 月 14 日的项目状态。Colibri 变化很快，因此我们把已测结果、社区结果和未来估算分开。

Colibri 到底是什么？

Colibri（项目写作 Colibrì）是一个主要用 C 编写的推理 runtime，目标是在存储、RAM 和可选 VRAM 之间运行超大型稀疏 MoE。上游目前针对 GLM-5.2 特有的 glm_moe_dsa 架构。仓库里还有用于较小验证与量化实验的 OLMoE engine，但这不代表它是任意 frontier model 的通用 loader。项目包含 CLI、本地 Web UI、converter、benchmark、OpenAI-compatible 文本 API，以及实验性的 CPU、CUDA 和 Metal 路径。

Colibri runtime 使用 Apache 2.0；GLM-5.2 权重使用 MIT，商业使用相对宽松。但准确说，GLM-5.2 是 open-weight：公开权重和许可证不等于训练数据与完整训练过程可复现。

Colibri 并没有把整个模型压进 25 GB。完整 int4 checkpoint 仍在磁盘上；总会用到的部分留在内存，router 选中的专家按需读取。这一差别就是整个项目的核心。

为什么选择 GLM-5.2？

Z.ai 把 GLM-5.2 描述为 744B-A40B：总参数约 7440 亿，每 token 激活约 400 亿。官方声称 100 万 token context、Terminal-Bench 2.1 得分 81.0、SWE-bench Pro 得分 62.1；这些是厂商数据，不是中立证明。Artificial Analysis 在发布时把 GLM-5.2 排为其 open-weight Intelligence Index 第一，所以称它为 frontier-class open weight 有依据，但不代表每个 workload 都胜过闭源模型。

不能把托管版或全精度 benchmark 直接套到 Colibri int4。Colibri 首次小规模质量测试在 HellaSwag、ARC、MMLU 每项仅 40 题时得到 62.5% mean normalized accuracy。样本太小，评估方法不适合理模型，也没有干净的 full precision 对 int4 A/B。Colibri 对“能够执行”的证明远强于对“质量保持”的证明。

744B 模型如何在 25 GB RAM 中执行？

1. 稠密层常驻：attention、embedding、shared expert 等每次都会用到的 int4 权重约占 9.9 GB。
2. 路由专家留在 NVMe：MoE 层和 MTP head 合计 21,504 个专家 block，每个约 19 MB。
3. 逐 token 路由：GLM-5.2 在每个 MoE 层为当前 token 选择八个专家。
4. 缓存命中复用：逐层 LRU、学习得到的 pinned hot store、操作系统 page cache 与可选 VRAM 保存热门专家。
5. 尽量重叠：在常驻专家计算时 prefetch 冷专家，然后汇总结果。

冷缓存数学正好解释速度：75 个 MoE 层 × 8 个专家 × 约 19 MB，等于每 token 约读取 11.4 GB 专家数据。开发者约 1 GB/s 的存储路径仅磁盘就要 11 秒，理论上限约 0.09 tok/s，与 0.05-0.1 tok/s 实测吻合。

真实速度有多快？

下表来自项目社区数据，我们没有复测。100 token 时间按 100 / tok_s 换算，不含 prompt prefill、排队和隐藏推理。

长 prompt 或冷缓存的首 token 时间可能更差。六张 5090 的结果不能推导出一张游戏卡有 6 tok/s。项目对单张 RTX 5090 的干净重测接近零收益，因为 CPU 已能追平专家矩阵乘，瓶颈仍是存储。常见对话目标是 20-30 tok/s；Colibri 已发布的最好单请求结果仍低于这一范围。

真正决定性能的因素

1. RAM 与缓存命中率

24-32 GB 中，稠密权重、KV、scratch 和系统占用后几乎没有专家缓存。一个 24 GB 测试即使 direct read 达 2.74 GB/s，命中率也只有 3-4%，速度 0.07 tok/s。128 GB 则能 pin 数十 GB 的 workload 热门专家。重复工作负载比随机提问收益更大；代码任务学到的热专家未必适合法律研究。

2. 真实随机读取，而非包装盒数字

Colibri 在 370 GB 中并行读取分散的约 19 MB block。应该运行项目的 direct-I/O iobench 冷 shard，而不是引用 SSD 最大顺序读。同一 Ryzen 从 1.51 GB/s Gen3 QLC 换到 8.81 GB/s Gen5 后，生成速度只从 0.10 提升到 0.28 tok/s：磁盘快 5.8 倍，token 只快 2.9 倍，因为瓶颈转向 matrix multiplication。

3. CPU、内存带宽与推测解码

缓存命中后，瓶颈变成量化矩阵乘和 RAM 带宽。正确的 int8 MTP 文件获得 39-59% draft acceptance、每 forward 2.2-2.8 token；旧 int4 mirror 几乎没有接受。冷缓存下推测甚至可能更慢，因为每 token 的专家加载从约 660 增到 1,100。--topp 0.7 能减少读取，但它有损地限制 router，必须重新做质量 eval。

Colibri 会磨损 SSD 吗？

正常推理几乎不应消耗 SSD 的 TBW。每 token 约 11 GB 指读取，不是写入。NAND 耐久按 program/erase 写入衡量；Micron 的耐久文档认为读取造成的磨损可忽略。Colibri 专家流也是 read-only。

• 初次安装会集中写入：预转换模型下载约写 370 GB；从 756 GB FP8 转换时，下载、临时 shard 和输出合计会超过 1 TB host writes。
• swap 才是耐久陷阱：RAM 不足导致持续换页写入，同时性能崩溃。
• KV 持久化有少量写入：约 182 KB/token，加上 usage history。
• 持续读取会发热：Samsung 记录了高负载 thermal throttling。需要散热片、风道、SMART 温度和 swap 监控。

带散热和足够空闲空间的专用 1 TB 本地 NVMe，比把 370 GB 模型塞进装有系统的 500 GB 盘更稳妥。RAID 0 能提高带宽，也增加任一盘故障导致本地副本丢失的概率，只应保存可重新下载的模型。

加 GPU 就会快吗？

有时。Colibri 可以把热专家放在 NVIDIA VRAM、用 CUDA 跑稠密计算，并在 Apple Silicon 使用 Metal。但单张 16-32 GB GPU 只能装下 370 GB 中很小一部分。只有 hot tier 命中率高且 CPU 专家计算是瓶颈时才有效；若磁盘占主导，帮助很小。当前多 GPU 采用独立 device context 与经 host 的同步复制，没有 P2P/NCCL、expert sharding 或成熟 Tensor Core 库。在 profiling 证明瓶颈是专家矩阵乘之前，不要为了 Colibri 购买 GPU。

能否运行 DeepSeek、Qwen、Kimi 等模型？

不能直接换 model ID。上游不是通用 GGUF runtime。GLM-5.2 的 tokenizer、Multi-head Latent Attention、DeepSeek Sparse Attention、router、tensor layout、MTP head 和量化容器都有专门实现。其他架构需要新的代码、converter 和验证。

第三方 Colibri-Hy3 把思路移植到腾讯 295B、21B active 的 Hy3，新增 GQA、router 和 converter，并流式执行约 142 GB int4。它同时证明设计可移植，也证明支持新模型绝不是改一个名称。稠密模型每 token 几乎需要所有参数，收益会小很多。

100 万 token context 现实吗？

GLM-5.2 官方支持 100 万 token，不代表 25 GB 机器实用。Colibri server 默认 context 是 4,096；压缩 KV 持久化约 182 KB/token。100 万 token 仅 KV 就约 182 GB，还没算模型、scratch 与专家缓存。“模型支持”与“这台机器能在预算内服务”是两种结论。

OpenAI-compatible API 生产可用吗？

它适合接入测试：model discovery、chat 与 legacy completions、SSE streaming、usage 和基础 sampling。它不等同于生产 vLLM 或 SGLang。第一版只有文本；tools、图片/音频、custom stops、logprobs 和 token penalties 会报错。引擎一次执行一条序列，所以请求排队。最多 16 个 KV slot 隔离对话状态，但不是 continuous batching；认证只是共享本地 API key。

个人实验足够，客户系统则需要 load test、隔离、rate limit、可观测性、安全审查、故障恢复、模型 checksum、更新策略、eval gate 与 API fallback。我们的本地模型与 API 盈亏平衡框架覆盖运维成本；Colibri 的单序列吞吐让商业门槛尤其高。

谁应该在今天使用 Colibri？

Colibri 当前的商业价值是可行性工具：GLM-5.2 是否通过你的私有 workload？int4 保留多少质量？哪些专家变热？应该升级 RAM、NVMe 还是计算？这些证据能指导托管 API、managed endpoint 或正式自托管的后续选择。

购买硬件前如何测试 Colibri

1. 准备 30-100 个代表性 prompt 与明确的验收 rubric。
2. 使用带 int8 MTP head 的预转换 checkpoint，并核对文件大小。
3. 运行 coli doctor 与 coli plan，确认文件、平台、RAM 和 tier placement。
4. 用项目 direct-I/O benchmark 测冷 shard，不要抄 SSD 顺序读规格。
5. 记录首 token 时间、decode tok/s、专家命中率、peak RSS、质量与总任务时间。
6. 分别报告冷缓存与预热结果。
7. 一次只改变 RAM、NVMe、GPU expert budget 或 CPU flags 中的一项。
8. 把整机、电费、工程时间与托管 GLM-5.2 每个成功任务的成本比较。

离开实验室后要增加 eval gate 和 fallback。我们的 Twinsoft AI 案例与技术栈选择指南遵循同一原则：架构由实测约束决定，不由新奇程度决定。

来源与方法

Runtime 架构、需求、功能状态和速度来自 Colibri 仓库及其 issue 测量。模型架构、许可、context 与发布 benchmark 来自 Z.ai GLM-5 仓库和官方 model card。Artificial Analysis只作为独立能力信号，不用于 Colibri 速度。SSD 耐久与温度来自上文 Micron、Samsung 文档。所有事实于 2026 年 7 月 14 日核对。