Show HN：让 GLM 5.2 在我的慢电脑上运行起来

原文 ↗ Hacker News 讨论 ↗

项目概念与黑客精神

  • 该工具通过积极地从 NVMe 流式读取权重，而不是把所有内容都放在 RAM 中，从而在“慢”/消费级硬件上运行非常大的 GLM 5.2 MoE 模型。
  • 许多评论赞赏其极简、几乎像是混淆过的实现，以及“把东西跑在它们本不该运行的地方”的整体精神。
  • 不少人提到自己也在做类似实验（自定义流式引擎、基于 mmap 的 runner、Medusa/MTP、Rust 移植），并将其视为更广泛趋势的一部分。

性能与实用性

  • 在低端硬件上报告的速度（≈0.05–0.1 tok/s）被一些人认为对于交互式使用太慢，不过也有人觉得即使 1 tok/s 对于过夜或批处理工作负载也可以接受。
  • 大家对高端 CPU、大内存服务器和 GPU 的基准测试很感兴趣；有些人预计，如果 RAM 足够，标准的 llama.cpp 方案可能会比 SSD 流式读取更快。
  • 讨论中还出现了与其他项目（llama.cpp、flash-moe、hypura、fastllm）的比较，并提出一个未解问题：这种方法是否真的比已经使用 mmap 和量化的成熟引擎更快。

硬件、可负担性与替代方案

  • 关于“普通人”是否买得起 24GB 以上 RAM 和大容量 NVMe 硬盘存在争论，尤其是在内存价格上涨的背景下。
  • 建议包括使用二手机架式服务器配 512GB–1TB RAM、Mac Studio 级机器，或者直接在云端运行 GLM 5.2，通常更实际。
  • 多位用户探讨了 RAID0/并行 SSD、CPU/GPU 混合方案，以及利用 Apple Silicon 上统一内存的想法。

SSD 磨损、交换与安全性

  • README 警告可能存在 SSD 磨损；这引发了对带焊死 SSD 的笔记本电脑的担忧，以及使用外接“烧录盘”的提议。
  • 对风险来源的解释不一：有人将其归因于 swap 和 page cache 驱逐（“spilling”）；也有人强调应用本身只做读取，警告只是保守估计。
  • 讨论的缓解措施包括：禁用 swap、调低 swappiness、只读分区或镜像。大量读取究竟会造成多大磨损，仍不算完全清楚。

面向慢模型的接口与工作流

  • 几位评论者认为聊天 UI 并不适合非常慢的本地模型，转而建议采用工单/任务系统。
  • 设想包括把任务分派给工作代理的编排器，以及通过电子邮件和工单队列进行简单集成，把模型当作一个缓慢但可靠的队友来使用。

MoE 与架构相关问题

  • 有人询问是否能在集群中通过 MPI 分布专家；回答是理论上可行，但在小型集群上网络延迟很可能成为主导因素。
  • 关闭除一个专家外的所有专家被认为是可行的，但会严重降低质量；更推荐改用更小的稠密模型。