Show HN：开源引擎可在任意 M 系列 Mac 上用 2 GB RAM 运行 Gemma 4 26B

概览与目标

• 该引擎通过直接从 SSD 流式读取专家而不是加载完整的 14 GB 权重，在 M 系列 Mac 上本地运行 Gemma 4 26B MoE，使用约 2 GB RAM。
• 目标：面向 Apple 笔记本/台式机的低内存、日常任务使用，以速度换取更小占用和离线隐私。

性能与硬件依赖

• 报告的速度：
  • 在 8 GB RAM 的 M1/M2 Air/Neo 上约 ~4–6 tok/s。
  • 基础 SSD 的 M4 mini 约 ~5 tok/s；M1 Max Studio 约 ~12 tok/s。
  • M5 MacBook Pro 约 ~31–35 tok/s；64 GB M4 Max 约 ~48 tok/s。
• 这么大的差异主要归因于：
  • SSD 速度（M5/M4 Max 的 SSD 可达 3–7 GB/s，而普通设备约 ~2 GB/s）。
  • 内存带宽和系统级缓存。
  • 操作系统页缓存：更多 RAM 能让大部分专家权重留在缓存中，显著减少真实磁盘读取。
• 在强内存压力下，速度会下降，但会逐步退化，而不是直接崩溃。

技术方案（MoE + SSD 流式读取）

• 利用 MoE 稀疏性：每个 token 只激活少数专家。
• 实现了显式的专家缓存（默认约 16 个槽位；更多槽位会消耗更多 RAM，但可提升速度）。
  • 缓存命中率约 60–70%；可在 1–2 个 token 之间部分复用。
• 关键改动：将专家读取从 mmap 改为并行 pread：
  • 基准测试显示，每个 3.36 MB 专家约 ~10 ms 对比 ~2.8–3 ms；在 8 GB M2 上速度约从 ~0.5 tok/s 提升到 ~4 tok/s。
• 尽可能将 SSD 读取与 GPU 计算重叠，以隐藏延迟。
• 在 M2 上每个 token 从 SSD 读取约 ~250–320 MB（I/O 阶段约 ~3 GB/s）。

与其他引擎/模型的对比

• 在 M5 上使用 MLX 运行完全驻留内存的 Gemma 4：约 ~75 tok/s，但占用约 ~14 GB RAM。
• 该引擎：在同级机器上仅用约 ~2 GB RAM，速度约 ~31–35 tok/s。
• 讨论认为，基于 mmap 的卸载方式的 llama.cpp 也能压到 2 GB，但会更慢。
• 还提到了其他 SSD 流式 MoE 引擎（Colibri、Flash-MoE、DwarfStar、MoEspresso），通常面向更大模型和更高端、内存更大的 Mac。

平台范围与限制

• 仅限 Mac：依赖 Metal 和统一内存；移植到 Windows/Linux 或离散 GPU 需要重新设计（CUDA/Vulkan）。
• 目前专注于 Gemma 4 MoE；Qwen 3.6 MoE 也可能可用，但架构更复杂。
• 该实现不适合稠密模型或扩散模型。
• 极大的 MoE（例如 Kimi K3）理论上也可通过类似思路运行，但在 16–64 GB 机器上由于每个 token 的 I/O 过于极端，实际上几乎不可用。

实用性、质疑与用户体验

• 热情：许多人认为这对消费级 Mac 上的本地推理是重大进步；“26B 只用 2 GB” 的工程实现令人印象深刻；适合离线、隐私友好场景。
• 质疑：
  • 有些人认为 5–30 tok/s 相比云端模型仍然太慢，不适合严肃编码或交互工作。
  • 另一些人指出，高质量本地编码助手仍然需要大 GPU 或前沿级模型。
• 有人认为 Gemma 在通用任务和多语言基础能力上表现不错，但编码能力弱于 Qwen；不过对某些生产场景来说仍“足够好”。

未来方向与研究想法

• 讨论中提出的想法：
  • 当可用 RAM 更多时使用更大的专家缓存。
  • 随着 SSD 和 RAM 增长，把同样的流式方法应用到更大的 MoE 模型。
  • 使用类似 MTP 的头进行推测性专家预取；但有人反驳说这很难，因为专家路由是按层进行的，并依赖前面层的输出。
• 还提到 Apple 新的基础模型使用按提示级别加载专家，这与之相关但并不相同。

元话题：安全性与“LLM 腔”

• 一位评论者用 LLM 对仓库做了快速安全审查；其他人则争论“AI 说它安全了”这类说法的价值与风险。
• README 里的 LLM 润色写作风格引发了长串讨论：
  • 有些人不喜欢可辨识的“LLM 腔”措辞；另一些人则为使用工具润色语言的非母语作者辩护。
  • 多位参与者形成的共识是：代码和实验比完美文笔更重要。