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