TurboFieldfare: 2GB内存运行Gemma 4大模型
Show HN: Open-source engine running Gemma 4 26B in 2 GB RAM on any M-series Mac
内存太贵？我让260亿参数的Gemma 4 26B-A4B模型在仅2GB内存的Apple Silicon Mac上流畅运行。TurboFieldfare是一个基于Swift和Metal的定制运行时，它不将整个模型载入内存，而是将核心部分常驻，按需从SSD流式加载专家模块。无论是8GB内存的入门款MacBook Air还是高端机型，都能体验本地大模型推理。项目提供原生Mac应用、CLI和OpenAI兼容服务器，让开发者轻松在本地部署和测试。
内存变得昂贵，所以我给了一个260亿参数的模型仅2GB的预算。
HN 评论区
320- giancarlostoro
不错，我想这已经是第二次在 HN 上看到这个了。我一直好奇，为什么非要整个模型都塞进内存里？每次我都不在乎查尔斯国王是谁。总觉得我们早就掌握了如何拆分大文件并用极少的内存高效解析它们的方法。
前沿 AI 领域似乎聚集了一群在构建模型方面才华横溢的人，但一到规模和实用性问题，他们就甩手不管，全丢给搭建基础设施的人去头疼了。如果前沿 AI 公司能微调并优化他们的模型，使其不再占用所有可用 RAM，而是仅访问模型知识的 10% 以下，成本可能会大幅降低，我对此毫不意外。
- pwython
我的 M1 MBA 还在运行 macOS 15。要编译它，只需删除包含
opts.languageVersion = .version4_0
的两行代码，
或者用
if #available(macOS 26.0, *) {
opts.languageVersion = .version4_0
}
将它们包起来。
根据 git 注释，这样会错过 2.4 倍的预填充加速（因为它能带来 11.24 倍的注意力机制加速），但确实能跑起来。（在拥有 8 个 GPU 核心的 M1 MBA 上，我得到了 5-6 tok/s 的速度。）
- xenonite
我很好奇你的项目与纯 mmap 相比如何？
因为如果你真的愿意，llama.cpp 已经能在 2GB 内存中运行 26B 模型了（启用 mmap，禁用 repacking）。
看起来主要的区别在于，你的项目将 SSD 读取与推理活动同步了，这显然是为了将延迟降到最低而进行的调优？而操作系统根本不会在乎这些。
- tredre3
我有一个项目也快要能运行 DiffusionGemma 了。这两个项目或许能很好地配合。我在 36GB 的 M3 上能达到约 20 tok/s，我们很有可能互相借鉴更快的 kernel。
欢迎随时联系。
（目前在 https://github.com/mmastrac/diffgemma，但尚未达到可发布状态）
- mmastrac
> 测量结果是一个参考点，而非性能上限。
Claude 来过这里。
- woadwarrior01
大家是否把这类关于 CPU Mac 的帖子看作是
https://en.wikipedia.org/wiki/Reality_distortion_field
的一个例子？
我有一块 Nvidia 芯片，即便如此，我也觉得这些模型很快，但对当代 AI 来说并不实用。
我无法想象既慢又没用会是什么样子。
这让我想起了那位控制了美国 30% 人口思想的政客。
- ycui1986
现在有很多 SSD 流式引擎。但真正尝试一些硬核功能的却很少。
有一个功能确实能大幅提升速度。鉴于几乎所有主流模型都带有用于投机解码的 MTP head，同样的 MTP head 也可以用来投机预取驻留在 SSD 上的专家权重。如果能在 GPU 实际需要之前预加载专家权重，那么由 VRAM 缓存未命中带来的速度惩罚就会大大降低。
如果这项技术能证明能提升 token 生成速率，未来的模型也可以自带预训练头来预加载专家权重，甚至让训练过程也对此有所感知。
- nvch
在配备更快 SSD 的 M1 Max Mac Studio 上，12 tok/s 的速度和几乎即时的响应令人印象深刻——这让人对大型模型未来能直接从 SSD 而非内存中运行本地化运行充满希望。