2026 年 7 月 10 日，Hacker News 上一篇题为「Show HN: Getting GLM 5.2 running on my slow computer」的帖子获得了 707 分和 170 条评论。作者 vforno（GitHub 用户 JustVugg）分享了一个大胆的实验：在一台只有 12 核 CPU、25 GB 内存、WSL2 环境的笔记本电脑上，成功运行了 Z.ai 发布的 744B 参数 GLM 5.2 模型。
这个项目的名字叫 Colibri（蜂鸟），一个纯 C 语言编写、零运行时依赖的推理引擎。它的设计哲学简单而务实：不追求高吞吐，只关心「能不能跑起来」。
为什么这件事值得关注
大型语言模型的推理长期被高性能 GPU 集群垄断。一台消费级机器想要加载一个 744B 参数的模型，听起来像是硬件常识的反面。GLM 5.2 的完整 FP8 权重大约 756 GB，即便经过 int4 量化也有约 370 GB——这个数字远超任何消费级内存。
Colibri 破解这个问题的方式，得益于 GLM 5.2 本身的架构特性：它是一个 Mixture-of-Experts（MoE）模型。虽然总参数量达到 744B，但每个 token 实际激活的参数只有约 40B。更关键的是，在这些激活参数中，只有约 11 GB 的部分会在 token 之间发生变化——也就是被路由器选中的专家（routed experts）。
vforno 抓住了这个不对称性。
架构设计：分层存储的推理策略
Colibri 将模型分成两部分处理，每一部分采用不同的存储和加载策略。
第一部分是密集层（dense part），包括注意力机制、共享专家（shared experts）和嵌入层，总计约 17B 参数。这些参数每个 token 都需要使用，不适合从磁盘按需读取。Colibri 将其量化为 int4 精度后常驻内存，占用约 9.9 GB RAM。
第二部分是路由专家（routed experts），共 21,504 个（75 个 MoE 层 × 每层 256 个专家 + MTP 头），每个专家在 int4 下约 19 MB，总计约 370 GB。这些专家存储在本地 NVMe 固态硬盘上，推理时按需流式加载。Colibri 使用逐层 LRU 缓存来保留最近使用的专家，操作系统自身的页缓存（page cache）作为免费的二级缓存层。此外还支持将热点专家锁定（pin）在内存中，避免被驱逐。
这套分层架构的本质是用磁盘 I/O 换取内存占用。Colibri 的 README 中写道：「This is not fast. It is a 744B frontier-class model answering correctly on a machine that costs less than one H100 fan.」这句话点出了核心权衡：用时间换可行性。
纯 C 引擎的技术栈
Colibri 的推理核心是一个约 2,400 行的 C 文件（c/glm.c），加上少量头文件。运行时不需要 BLAS、不需要 Python、不需要 GPU（可选 CUDA 后端正在实验中）。它实现了一套完整的 GLM 5.2 前向推理管线：
-
MLA 注意力机制（Multi-head Latent Attention）：
q/kv的低秩分解（LoRA）实现，搭配交错的部分 RoPE 位置编码。压缩后的 KV 缓存每个 token 仅需 576 个浮点数——相比原生 32,768 个浮点数缩小了约 57 倍。GLM 5.2 拥有 64 个注意力头且不使用 GQA，这个压缩对内存控制至关重要。 -
MTP 推测解码（Multi-Token Prediction）：GLM 5.2 内置的多 token 预测头（第 78 层）用于草拟后续 token，主模型在一次批量前向中验证。该头需要
int8精度——社区实测表明int4下草稿接受率仅 0–4%，而int8下可达 39–59%，每次验证平均产出 2.2–2.8 个 token。Colibri 通过拒绝采样保证推测解码的无损性。 -
DSA 稀疏注意力（Dynamic Sparse Attention）：GLM 5.2 的闪电索引器（lightning indexer），每层选择 top-2048 个因果键。Colibri 从 FP8 仓库的
out-idx-*权重中自动检测索引器层，提取约 189 MB 的索引数据。经验证，强制保留所有键时输出与密集注意力逐 token 一致。 -
整数点积内核：
Q8_0风格的int8激活值搭配 AVX2maddubs指令，int8矩阵乘法实测 119 GFLOP/s，比浮点快 1.4–2.5 倍；int4批量推理快约 1.8 倍。单行int4保持f32路径，因为实测更慢——Colibri 会根据张量形状自动选择路径。 -
RAM 安全性：启动时从
MemAvailable自动计算专家缓存大小，包含峰值预估（工作集、KV 缓存、MTP 行、重建缓冲区），防止内核 OOM-killer 触发。 -
离线 FP8→int4 转换器：一次下载一个分片（约 5 GB），解量化（128×128 块缩放），重新量化到引擎容器格式后删除原始分片。756 GB 的 FP8 检查点无需整体存储在磁盘上，且支持断点续传。
实测性能数据
vforno 的开发环境是 WSL2，12 核 CPU，25 GB 内存，通过 VHDX 挂载的 NVMe 固态硬盘。基准数据如下：
| 指标 | 数值 |
|---|---|
| 磁盘上的 int4 模型 | ~370 GB |
| 常驻内存（密集层，int4） | 9.9 GB |
| 加载时间 | ~30 秒 |
| 聊天时峰值 RSS | ~20 GB（自动上限） |
| 冷解码的磁盘读取 | ~11 GB/token（75 层 × 8 专家） |
| VHDX 随机读取上限 | ~1 GB/s → 冷启动约 0.05–0.1 tok/s |
| MTP 推测解码（int8 头） | 2.2–2.8 tok/前向 |
冷启动约 0.05–0.1 tok/s 意味着一个 100 token 的回复需要约 15–30 分钟。但随着缓存预热、热点专家锁定和 MTP 推测解码生效，有效延迟会明显下降。
社区贡献的基准测试提供了更多数据点：
- Intel Core Ultra 7 270K Plus（24 线程，WSL2，24 GB RAM）：默认配置 0.07 tok/s，启用
--topp 0.7后 0.11 tok/s。 - Apple M5 Max（18 核，128 GB 统一内存，内置 SSD）：关闭 MTP 时 1.06 tok/s，磁盘 O_DIRECT 读取速度 14.2 GB/s。这个数据说明在较好的硬件上，瓶颈从磁盘转向内存预算和内核。
- Ryzen AI 9 HX 370（Framework 13，128 GB，WD SN850X NVMe）：使用
int8MTP 头、32 槽缓存和 46.7 GB 自动学习的热点锁定后，达到 0.37 tok/s，专家命中率 66%，MTP 接受率 52%。
这些数据揭示了一个核心规律：在小内存机器上，RAM 容量——而非磁盘速度——是真正的瓶颈。2026 年 7 月 10 日的更新中，Colibri 修复了专家缓存不会自动利用多余内存的问题（此前 128 GB 的机器也只使用 8 专家/层的缓存）。
渐进式热身：学习型缓存
Colibri 实现了一个学习型缓存机制。引擎在每次对话轮次后将路由到的专家记录到 .coli_usage 文件中，下次启动时自动将最热门的专家锁定在空闲内存中。项目 README 对此有一句传神的描述：「colibrì literally gets faster the more you use it.」
此外，实验性的路由前瞻预取（PILOT=1）利用一个可测量的特性：下一层的路由有 71.6% 可以从当前层的注意力后状态预测。一个专用的 I/O 线程在当前层计算时预取下一层可能需要的专家。在当前开发机器上磁盘已接近 80% 饱和，效果中性；但在计算和 I/O 更平衡的机器上，这可以带来实际的重叠收益。
KV 缓存持久化（.coli_kv）也让对话可以在引擎重启后无缝恢复。压缩后的 MLA KV 缓存每次对话轮次追加约 182 KB/token，崩溃安全。关闭聊天窗口，第二天再打开——模型仍然记得整个对话，零重填前缀。
HN 社区的讨论焦点
HN 评论区的讨论围绕几个核心主题展开。
速度与实用性的边界。多位评论者指出 0.05–0.1 tok/s 对于交互式使用基本不可行，但有人提出 overnight 批处理场景：「如果你给模型一个项目让它 overnight 跑，6–8 小时后回来看结果，即使 0.1 tok/s 也能产出有用的东西。」也有人引用 Claude Cowork 的使用体验，表示低延迟并非所有场景的必需。
硬件成本路线图。一条评论线程估算：在当前（2026 年中）市场，约 $6,000–10,000 可以买到一台二手双路 Xeon 服务器，配备 768 GB–1 TB 内存。有些评论者对 CPU-only 推理的前景持怀疑态度，认为在 $10,000 预算下，本地编码模型的性价比远不如云服务。但也有观点指出，法律事务所、医学研究实验室和影视 CGI 公司对本地部署有刚性需求——涉及成本考量、数据主权和合规要求等多个维度。
AI 生成文本的识别。一条有趣的高赞评论注意到 Colibri README 中大量使用 “honest”（honest numbers, honest caveat, honest peak projection），认为这已成为 Claude 生成文本的新口癖——类似此前广为流传的某种固定对比句式。这引发了关于 AI 辅助写作的元讨论：即便项目本身是严肃的技术工作，AI 协作的痕迹仍然可辨。
意义与局限
Colibri 不会让消费级硬件上的 LLM 推理变得「快」。它的价值在于定义了一个下限：在 $500 级别的笔记本电脑上，一个 744B 参数的前沿模型可以正确回答问题。这是一种存在性证明而非实用性主张。
项目的局限也明确记录在案。最关键的缺失是 int4 量化的质量基准——由于开发机器磁盘速度限制，完整的 MMLU/HellaSwag/ARC 评测需要接近一整天，尚未完成。vforno 在 README 中写道：「This is the single most valuable thing a faster machine can contribute.」社区目前正在补上这块拼图。
另一个限制是并发能力。Colibri 的 API 服务器（coli serve）当前一次只服务一个生成请求，后续请求排队而非加载多个模型副本。工具调用、图像/音频输入、自定义停止序列等功能返回显式错误而非静默忽略。这是有意为之的设计取舍，而非功能缺陷。
后续方向
Colibri 的路线图取决于社区贡献者的硬件。更好的机器可以直接转化为更快的引擎：真实的 NVMe 扩展数据、更大的热点缓存、int2/int3 质量扫描。README 中提供了一个预测表：
- 原生 Linux + PCIe4 NVMe（3–5 GB/s 随机），32 GB 内存：约 0.5–1 tok/s
- PCIe5 NVMe 或双 NVMe RAID0（8–12 GB/s），64 GB 内存（锁定约 40 GB 热点专家）：约 2–4 tok/s
- 128–256 GB 内存（热点专家缓存命中），12 核：约 2–4 tok/s，受限于矩阵乘法
- 相同内存 + 24–32 核或 AVX-512/VNNI 内核：约 5–15 tok/s，达到交互可用水平
这些预测尚未经过实测验证。vforno 欢迎任何拥有更好硬件的人提交真实数据。
参考链接
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。