TurboFieldfare：把 Gemma 4 26B-A4B 塞進 2 GB 記憶體的 Swift 與 Metal 實作
Gemma 4 26B-A4B inference in ~2 GB of RAM on any M-series MacBook
秒懂
- 它是什麼？
- TurboFieldfare 是一個針對 Apple Silicon 撰寫的 Swift 與 Metal 推論引擎，專門執行 Gemma 4 26B-A4B，號稱只需約 2 GB 記憶體。它跳過 MLX 與 llama.cpp，直接以 SSD 串流專家權重，讓 8 GB Mac 也能跑 26B 模型。
- 適合誰用？
- TurboFieldfare 適合那些擁有 8 GB 記憶體、且非要用 Gemma 4 26B-A4B 不可的 Apple Silicon 使用者。它不適合尋求通用模型支援的人，因為它只綁定單一模型，而且要求 macOS 26 與 Metal 4，舊系統完全不適用。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 8 天前。
- 用什麼語言寫的？
- 主要是 Swift（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
記憶體昂貴之後的選擇
TurboFieldfare 的出發點很直接：記憶體很貴，而 26B 參數的模型通常需要 14.3 GB 的權重常駐。作者選擇不把整個模型載入，而是讓共用核心與 KV cache 留在記憶體，其餘專家權重從 SSD 串流。這個做法讓 8 GB 的 M2 MacBook Air 也能跑 Gemma 4 26B-A4B。目標使用者很明確：手邊只有低記憶體 Apple Silicon Mac，卻想跑大型語言模型的人。它跟 MLX 或 llama.cpp 那種通用包裝不同，TurboFieldfare 是針對單一模型打造的 runtime，這既是優勢也是限制。
專家串流與 2 GB 預算的運作機制
模型採用 MLX affine 4-bit 量化，group 大小 64，router 用 8-bit，共用與路由專家都是 4-bit。關鍵是記憶體配置：共用 1.35 GB 核心與 FP16 KV cache 常駐，專家權重則依 token 需求從 SSD 讀取。這意味著每次產生一個 token，都可能觸發磁碟 I/O。文件提到 M2 量測 decode 速度是每秒 5.1 到 6.3 token，M5 Pro 則可達 31 到 35 token。這個差距反映了 SSD 頻寬與記憶體頻寬的影響。頁面快取狀態、提示詞長度與生成長度都會改變實際吞吐量，所以這些數字只能當參考，不是保證。
Swift 6.2 與 Metal 4 的實作細節
整個 runtime 以 Swift 6.2 撰寫，使用 Metal 4，只支援 arm64。Swift Package 暴露六個產品，包括核心函式庫、Mac app、decode service、CLI、OpenAI 相容伺服器與 repack 工具。其中 TurboFieldfareRepack 負責串流安裝與驗證，TurboFieldfareDecodeService 是單次執行的本地模型與 Metal 擁有者。這種設計把模型持有權集中，避免多個程序同時存取同一個 .gturbo 目錄。文件明確說，同一時間只能有一個 model-owning 產品在跑，這對使用者是個需要注意的約束。Metal 4 與 macOS 26 的要求很硬，舊系統完全不支援。
安裝與首次啟動的真實流程
安裝方式直接從原始碼建置。先 git clone，然後在目錄內執行 swift build -c release，最後執行 .build/release/TurboFieldfareMac。首次執行時，Swift Package Manager 會下載並建置 tokenizer 所需的套件。開啟 app 之後，要選 Download，讓它抓取並重新打包固定的模型，檔案約 15 GB。完成後選 Load Model，輸入提示詞就能生成。CLI 與伺服器共用同一個 .gturbo 目錄，但伺服器是實驗性質，只監聽 loopback。需要特別注意，建置必須包含完整套件，否則 Mac app 與其 sibling decode service 可能不會同時存在。
影像支援的條件與代價
影像透過 vision tower 處理，它是一個 companion pack，需要額外安裝，檔案約 1.1 GB。安裝一次之後，app、CLI 與伺服器都能接受圖片。若不安裝，它們會明確告訴你影像支援不可用，而文字 runtime 不受影響。這裡有個硬限制：影像 tower 需要 M2 或更新的 Apple Silicon，M1 只能跑純文字。文件在系統設計章節詳細說明 tower 在 8 GB 機器上的執行成本，但那些細節不在 README 摘要中。對 8 GB 使用者來說，影像支援可能讓記憶體壓力增加，實際表現需要參閱 SYSTEM_DESIGN.md 才能確認。
限制：單一模型綁定與工具執行缺位
TurboFieldfare 不是通用推論框架，它只跑 Gemma 4 26B-A4B。如果你想換模型，就得找其他工具。另外，app 與 CLI 不支援工具執行，只處理使用者與模型訊息，加上選用的系統提示。loopback 伺服器接受 function-tool 宣告，並回傳模型產生的工具呼叫，但實際執行仍由客戶端授權。音訊與影片完全不支援。這些限制意味著它適合特定工作負載，例如本機指令聊天或原始補全，而不是需要複雜代理流程的場合。生成預設溫度是 0.2，Top-K 64，Top-P 0.95，設為 0 可得到貪婪輸出，但文件也提醒模型可能重複自己或給出錯誤答案，重要結果需要人工檢查。
替代方案：MLX 與 llama.cpp 的對比
最直接的替代是 Apple 的 MLX 框架或 llama.cpp，兩者都支援多種模型與量化格式。但 TurboFieldfare 的設計哲學不同：它不做通用包裝，而是針對 Gemma 4 26B-A4B 的架構最佳化，特別是專家串流這部分。MLX 或 llama.cpp 通常會把整個模型載入記憶體，或依賴統一記憶體架構，但較少看到針對 SSD 串流專家權重的細緻控制。TurboFieldfare 的實驗記錄提到 103 個量測結果，涵蓋 kernel、快取、I/O、prefill 與 decode，這種深度最佳化在通用框架中難以複製。代價是靈活性：你被綁在單一模型，而 MLX 或 llama.cpp 可以隨時切換模型。若你的需求是多模型測試，TurboFieldfare 是錯的工具；若你只要跑這一個模型且記憶體吃緊，它才有意義。
維護成本與授權考量
專案授權是 Apache-2.0，這代表你可以自由使用、修改與再散佈，但需要注意商標與專利條款，這不是法律建議。最後一次 push 是 2026 年 9 月，版本 0.8.0 剛釋出，顯示開發仍活躍。升級成本方面，因為是原始碼建置，每次更新都需要重新 swift build，而且 macOS 26 與 Xcode 26 的要求意味著你必須保持在最新系統，這對不喜歡追更新的使用者是個負擔。文件提到 .gturbo 模型目錄格式，但沒有說明不同版本之間是否相容，這點需要實際測試。實驗記錄有 103 個結果，但那些是開發者的量測，不是官方保證，升級後可能需要重新驗證效能。
編輯結論
TurboFieldfare 適合那些擁有 8 GB 記憶體、且非要用 Gemma 4 26B-A4B 不可的 Apple Silicon 使用者。它不適合尋求通用模型支援的人，因為它只綁定單一模型，而且要求 macOS 26 與 Metal 4，舊系統完全不適用。若你手上是 M1，文字推論可用，但影像塔需要 M2 以上，這點要事先確認。開始之前，你必須驗證 SSD 剩餘空間至少有 14.3 GB，並且網路連線穩定，因為首次安裝會下載並重新打包約 15 GB 的模型。另外要記住，只有一個產品能同時持有模型，CLI、伺服器與 Mac app 之間不能並行。若你能接受這些邊界，它可能是目前少數能在低記憶體 Mac 上跑 26B 模型的實際方案。
社群筆記