2,617· 110 forks· Swift· Apache-2.0开发工具

8GB Mac 也能跑 260 亿参数大模型

drumih/turbo-fieldfare

用 2GB 内存在任意 M 系列 Mac 上运行 Gemma 4 26B 模型,通过专家流式加载突破内存墙

成熟度维护活跃,最近提交 0 天前,15 个 open issues,实验性项目持续优化中

项目体检

部署 · 源码编译部署,swift build -c release 构建原生 Mac App 和 CLI 工具,无默认端口(本地应用)

成本 · 开箱即用无需外部 Key,首次运行自动下载 14.3GB 模型,需 macOS 26+、Metal 4、Swift 6.2 及约 15GB 存储空间

技术 · Swift 6.2 + Metal 4,纯原生实现无第三方推理框架,自研 103 项优化实验的专家流式加载机制

许可 · Apache-2.0,可商用,需保留版权声明和许可副本

活跃 · 活跃维护中,0.3 版本发布于 2 天前,单人作者持续迭代,103 项实验记录显示高强度优化

解决什么

在 8GB 内存的 Mac 上运行 260 亿参数的大语言模型通常被认为不可能——完整模型需要 14.3GB 空间。TurboFieldfare 通过专家流式加载(expert streaming)技术,将内存占用压缩到约 2GB,让入门级 M 系列 Mac 也能本地运行 Gemma 4 26B-A4B 模型。它将模型的共享核心(1.35GB)和 KV 缓存常驻内存,每次生成 token 时仅从 SSD 按需加载对应的专家权重,绕过了传统推理引擎必须全量加载模型的限制。

为何火

HN 讨论获 899 点赞 333 评论,核心吸引力在于让低配 Mac 用户首次能跑大模型。社区震惊于 M2 8GB 机型能达到 5-6 tok/s 的可用速度,而 M5 Pro 24GB 机型更飙到 35 tok/s(接近 ChatGPT 响应速度)。技术上,作者公开了 103 项优化实验的完整记录,从 Metal 内核到 I/O 缓存的每个决策都有数据支撑,这种透明度在开源 AI 项目中罕见。项目用纯 Swift+Metal 实现,不依赖 MLX 或 llama.cpp,展示了苹果生态原生开发的性能潜力。

核心功能

  • 极低内存推理: 2GB 运行 26B 参数模型,支持 4K 上下文长度可调
  • 专家流式加载: MoE 架构按需从 SSD 加载专家,共享层常驻内存
  • 三种使用方式: 原生 Mac App(带 UI)、CLI 命令行、实验性 OpenAI 兼容服务器
  • 流式安装器: 首次运行自动从 Hugging Face 下载并转换模型,无需手动准备权重
  • 4-bit 量化: 使用 MLX affine 4-bit 量化(group 64)压缩模型,路由器保持 8-bit
  • 性能监控: 内置基准测试工具,支持社区贡献不同硬件的性能数据

安装

需要 macOS 26、Xcode 26、Swift 6.2 及约 15GB 存储空间:

git clone https://github.com/drumih/turbo-fieldfare.git
cd turbo-fieldfare
swift build -c release
.build/release/TurboFieldfareMac  # 启动 Mac App
# 或使用 CLI
.build/release/TurboFieldfareCLI --prompt "解释量子纠缠"

首次运行会自动下载模型(约 14.3GB),安装器采用流式转换避免占用双倍磁盘空间。中国大陆用户访问 Hugging Face 可能需要网络工具。

适合谁

  • 8GB Mac 用户: 入门级 M2 Air 也能跑 26B 模型,适合预算有限的学生和个人开发者
  • 隐私敏感场景: 完全本地推理,无需上传数据到云端
  • Swift/Metal 开发者: 103 项实验记录是学习苹果生态 AI 优化的教科书级资源
  • 不适合: 需要多模态(图像/音频)、工具调用执行、或追求极致速度(MLX 在高内存机器上更快)的用户

社区评价

HN 讨论热度极高,主要争议点集中在性能差异来源。M2(8GB)的 5-6 tok/s 与 M5 Pro(24GB)的 35 tok/s 差距引发激烈讨论:多数开发者认为是页面缓存(page cache)效应——M5 的 24GB 内存让 macOS 能缓存更多 SSD 读取,有用户实测在 M5 上施加内存压力后速度从 35 降至 27 tok/s,验证了这一假设。也有观点指出 M5 的内存带宽(比 M2 高 50%)和片上缓存(大 50%)也是关键因素。

正面评价集中在工程实现的透明度,有评论称"103 项实验记录比论文更有价值",作者对每个优化决策都给出了测量数据。负面担忧是单人维护的可持续性macOS 26 的高版本要求(目前仍是 beta 阶段)限制了用户基数。有开发者质疑"为何不用 MLX",作者回应称这是为了学习底层优化而非追求通用性。

选型对比

vs MLX: MLX 在高内存机器上更快(M5 上 75 tok/s vs TurboFieldfare 35 tok/s),但需要 14GB 内存全量加载。TurboFieldfare 牺牲 50% 速度换取 85% 内存节省,适合多任务场景或低配机型。

vs llama.cpp: llama.cpp 支持更多模型和平台,但在 8GB Mac 上跑 26B 模型会频繁 swap 导致卡顿。TurboFieldfare 的专家流式加载是针对 MoE 架构的专项优化,内存占用更可控。

vs Ollama: Ollama 易用性更好但不支持 Gemma 4 26B 在 8GB 机器上运行,通常推荐 7B 以下模型。TurboFieldfare 是目前唯一能在 8GB Mac 上流畅运行 26B 模型的开源方案。

已知坑

  1. 系统版本限制: 硬性要求 macOS 26(目前 beta),无法在 macOS 25 或更早版本运行
  2. 仅支持 Gemma 4 26B-A4B: 不是通用推理引擎,无法加载其他模型或 LoRA
  3. 页面缓存依赖: 实际速度受系统内存压力影响大,8GB 机器运行其他应用会显著降速
  4. 首次安装需梯子: 从 Hugging Face 下载模型在中国大陆可能失败,需提前准备网络环境
  5. 纯文本限制: 不支持图像、音频等多模态输入,工具调用仅在服务器模式返回声明不执行
  6. 单人项目风险: 目前仅 1 位贡献者,长期维护存在不确定性

安装方式:swift build