摘要： Andrey Mikhaylov 的開源 TurboFieldfare 用 Swift 與 Metal 讓 Gemma 4 26B-A4B 的專家權重逐 token 從 SSD 串流，只常駐約2GB記憶體。在8GB M2 MacBook Air 上實測每秒5.1到6.3個token，代價是約14.3GB儲存空間與隨機讀取延遲。這種 MoE 設計把可跑大型本地模型的記憶體門檻明顯降低。
7 月 29 日，以 iOS 與 Metal 為主要工作領域的工程師 Andrey Mikhaylov 在 Show HN 發表了 TurboFieldfare。這套推理引擎完全以手寫 Swift 與 Metal 實作、採 Apache 2.0 開源授權，任何 Apple Silicon Mac 都能靠它跑起 Gemma 4 26B-A4B，記憶體佔用約 2GB——統一記憶體僅有 8GB 的機型同樣在列。該討論串累積 919 分、留言三百多則。專案名取自作者最鍾愛的白眉鶇（fieldfare）；README 也開門見山地交代兩件事：與 Google 沒有任何關係，而且它不是 MLX 或 llama.cpp 的包裝。
26B 何以能壓進 2GB
答案要回到 Gemma 4 26B-A4B 的 MoE 架構：參數總量約 26B，但每一個 token 只會動用其中約 3.88B。TurboFieldfare 的取捨毫不迂迴——整個模型自始至終都不進記憶體。真正常駐下來的僅有共用核心（約 1.35GB）與 FP16 KV cache。每生成一個 token，先由 router 挑出 top-8 專家，再以有界並行的 pread 把這些權重自 SSD 讀入，放進 16 格 LFU 快取，供後續 token 重複取用。
量化的精度分配刻意不齊頭：嵌入、注意力與專家權重以 MLX affine 4-bit（group 64）存放，router 則守在 8-bit。prefill 每批最多切到 128 個 token，一次專家讀取便能服務好幾列。KV cache 的擺法同樣取決於層型：25 層滑動窗口用環狀儲存，5 層全注意力用線性儲存。
實測數字：8GB Air 上每秒 5 到 6 個 token
跑出來的實測值如下：8GB M2 MacBook Air 每秒解碼 5.1 到 6.3 個 token，換到 24GB M5 Pro 則是每秒 31 到 35 個。這一切得用儲存空間來換——文字模型大約要佔 14.3GB。安裝時，位元組範圍會從 Hugging Face 上釘選的 revision 直接串流下來，一邊下載一邊重排成 .gturbo 佈局，磁碟上不會暫存一份完整 checkpoint。純文字模式 M1 就能跑；想加裝 1.1GB 的選配視覺包，機型得是 M2 以上。macOS 26 與 Metal 4 是這套系統的需求底線。
此外，專案裡還躺著 103 場留下審計紀錄的實驗。真要說它歷經多少輪調整，這個數字恐怕比任何效能宣稱都更有說服力。
這條路線為何值得留意
RAM 在多數本地推理框架眼中是一道無法跨越的牆：模型塞不下，就是跑不動。TurboFieldfare 偏要繞路，把 SSD 拉進記憶體階層，用隨機讀取延遲換回 RAM，再靠 MoE 的稀疏性讓這樁交易還能成立。HN 上得票最高的一則留言正好戳中要害：「為什麼每次都要把整個模型塞進記憶體？」下面的回覆也夠坦白——某個 token 究竟該讀取哪些知識，至今仍是無人解開的研究題，MoE 頂多算是部分解答。
產品團隊可以從中帶走兩點。第一，8GB 入門機再度成為站得住腳的目標裝置，端側 AI 的硬體門檻因此又降了一階。第二，這筆工程取捨沒什麼好藏的：從口袋裡掏出的是儲存空間與隨機讀取延遲，換回來的是記憶體。這筆帳划不划算，取決於你的產品要的是「跑得動」還是「跑得快」。