TurboFieldfare：8GB Mac 本地跑 Gemma 4 26B-A4B 的 Swift + Metal 运行时
Gemma 4 26B-A4B 是 260 亿参数的大模型，按常规做法完整加载进内存需要 16GB 以上；TurboFieldfare 用约 2GB 内存预算把它跑在 8GB 的 Apple Silicon Mac 上。它的做法是把内存门槛从「装下全部参数」挪到「装下常驻核心」：只常驻共享核心与 KV 缓存，其余专家权重按需从 SSD 流式加载。项目 README 实测：8GB M2 MacBook Air 每秒生成 5.1–6.3 个 token，24GB M5 Pro 每秒 31–35 个 token。本文讲清楚它靠什么机制做到这一点、实测多快、以及上手前需要知道的边界。
传统方式加载 26B 模型的内存瓶颈
TurboFieldfare 当前 6.3k star、389 fork，最新版本 0.5.0 于 2026-08-23 发布。把模型完整加载进内存是主流推理运行时的做法。26B 参数以 FP16 存储约需 52GB，4-bit 量化后仍需 13–16GB（仅为量化权重，推理还要另计 KV 缓存与运行时开销），8GB 内存的 MacBook Air 装不下。Gemma 4 26B-A4B 属于**混合专家（MoE）**架构：单次推理并不激活全部参数，每生成一个 token 只使用约 3.88B 活跃参数——路由器从 128 个专家中选出 8 个，加上 1 个共享专家参与计算。这意味着「完整加载所有专家」本身就是浪费：多数专家在多数时刻并不参与计算。
TurboFieldfare 把内存压到约 2GB 的三件事
TurboFieldfare 是作者 Andrey Mikhaylov 用 Swift + Metal 手写的专用运行时，不是 MLX 或 llama.cpp 的封装，目标平台只有 Apple Silicon（arm64）。它把 2GB 预算拆成三部分：
- 常驻部分尽量小：共享的 1.35GB 核心权重（共享专家与注意力等公共部分）与 FP16 的 4K KV 缓存（注意力计算中的键值缓存）常驻内存；权重采用 MLX affine 4-bit 量化（按 64 元素分组缩放的量化）、路由器 8-bit。KV 缓存按层分区存储：25 个滑动窗口层用环形存储、5 个全注意力层用线性存储；
- 专家按需从 SSD 流式加载：每一层，Metal 先计算注意力与路由器，CPU 拿着路由器选出的 top-8 专家 ID 对照本层 16 槽 LFU（最久未使用淘汰）专家缓存，未命中的专家用并行
pread调用从 SSD 读入 Metal 可见缓冲区，读盘期间 GPU 并行计算常驻的共享专家分支，最后合并两者的输出； - 预填充分块：prompt 预填充按最多 128 token 分块执行，让一次取入的专家服务多行计算（即 chunked prefill），首次 token 延迟跟内存占用的折中由此控制。
上面的机制合计下来的常驻内存约 2GB，构成是：共享核心 1.35GB + FP16 4K KV 缓存与运行时开销；专家权重不占这 2GB，仅在需要时经临时缓冲从 SSD 读入——这就是「给 26B 模型 2GB 预算」的完整对账。
安装器遵循同样的有界内存原则：从 Hugging Face 固定 revision 以范围请求边下载边重打包为 .gturbo 布局，全程不落地完整 checkpoint，首次传输约 15GB，装完约 14.3GB，支持断点续传与安装校验。
实测速度：两档参考值
项目在 README 给出两组测量值，均为解码速度参考（受 prompt 长度、生成长度、页缓存状态与硬件影响，不是上限）：
- 8GB M2 MacBook Air：5.1–6.3 tok/s；首次 token 延迟明显（prompt 预填充按分块执行，交互式聊天等待感较强），适合查询、批量文本处理等场景；
- 24GB M5 Pro：31–35 tok/s，接近可用作交互式聊天。
项目文档还维护社区基准指引，任何 M 系列机型都可以按统一口径上报测量结果。
上手条件与三种使用方式
运行前提（全部满足才有意义）：Apple Silicon Mac（arm64 only）、macOS 26 + Metal 4、Xcode 26 与 Swift 6.2 及以上、约 15GB 空闲存储、首次安装需要网络。8GB M2 MacBook Air 是项目验证基准机；M1 只能纯文本推理（图像输入需 M2 或更新芯片）。
TurboFieldfare 以 Swift 包形式提供六个产物，三套主要使用方式共用同一个模型目录（同一时间只能有一个进程占用模型）：
- Mac 原生 App（TurboFieldfareMac）：
swift build -c release后运行.build/release/TurboFieldfareMac，界面内完成下载、加载、生成，右侧面板可调采样参数、上下文长度与专家缓存槽数； - 命令行 CLI（TurboFieldfareCLI）：支持指令聊天（
--messages-file传入 JSON 消息数组）与原始补全，生成文本输出到 stdout，统计信息输出到 stderr，--quiet可关闭统计脚注；采样、上下文长度、重复惩罚等常用参数均可通过命令行选项控制（完整清单见--help）； - OpenAI 兼容本地 Server（TurboFieldfareServer）：监听
http://127.0.0.1:8080/v1，支持 Chat Completions、流式输出与 function tools 声明，客户端负责授权并执行模型产出的工具调用。现有 OpenAI SDK 代码改一个 base URL 即可接入；服务器只应留在 loopback，没有远程鉴权与 TLS。
可选视觉塔：以 companion pack 形式安装（另占约 1.1GB，需 M2 或更新的芯片），装好后 App、CLI、Server 均接受图像输入；含图像的 prompt 一律分块预填充，要求至少 16 个专家缓存槽，手动调低槽数会无法使用图像输入。不装则三者统一提示图像不可用，纯文本能力不受影响。
适用的边界
TurboFieldfare 是单模型专用运行时，只跑 Gemma 4 26B-A4B 指令微调版这一个固定 checkpoint，不能换其他权重；当前范围是文本（加图像需另装视觉塔），音频与视频不支持。SSD 流式专家会给硬盘带来持续的读取流量，重度 24/7 服务化使用需评估 SSD 寿命与能耗，笔记本上跑几百 token 的场景影响可忽略。仓库源码与文档为 Apache-2.0，模型权重不随仓库提供，由安装器另行下载，权重适用 Google 自身的许可条款。
对低内存本地推理的意义
TurboFieldfare 给出的路线是：MoE 模型 + 专家按需加载 + SSD 流式，在 8GB 基础款 MacBook Air 上跑通了 26B 级别模型。把事实收拢成一句：MoE 把内存门槛从「装下全部参数」挪到了「装下常驻核心」，SSD 吞吐替代内存容量成为新的先决条件。代价是范围和平台上的取舍——它只服务 Gemma 4 26B-A4B 与 Apple Silicon：如果你手里恰好是 8GB M 系列 Mac、刚好需要这个模型，它是当前可行性已经过验证的直接选择；如果需要一个能换任意权重的通用运行时，它并不合适。