TurboFieldfare：在 M 系列 Mac 上使用 2 GB RAM 运行 Gemma 4 26B

TurboFieldfare 通过将活动内存占用降低至约 2 GB，使 Gemma 4 26B-A4B 模型能够在任何 Apple Silicon Mac 上运行，包括仅配备 8 GB RAM 的基础型号。它的实现方式是仅在内存中保留共享核心和 KV 缓存，同时实时从 SSD 流式传输所需的 MoE（Mixture of Experts）权重。

基于 SSD 的专家流式架构

TurboFieldfare 通过为路由专家实现自定义流式机制，避免了将整个 14.3 GB 模型加载到 RAM 中的需求。

内存管理与 I/O

在每个 transformer 层，引擎使用常驻权重计算 attention 和 router。CPU 利用 router 的前 8 名专家 ID 对 16 槽 LFU（Least Frequently Used）缓存进行调度。如果所需专家不在缓存中，引擎会执行受限的并行 pread 调用，将它们加载到 Metal 可见的缓冲区中。为最大化效率，Metal 在 SSD 读取进行时并行计算常驻的共享专家分支。

权重量化与布局

为了进一步降低内存占用，引擎使用了特定的量化格式：

Weights（权重）： MLX affine 4 位（group 64），用于 embeddings、attention、shared-experts 和 routed-experts。
Router（路由器）： 8 位量化。
KV Cache（键值缓存）： FP16 存储，采用滑动窗口方式用于 25 层，线性存储用于 5 层全注意力层。

性能基准

吞吐量会因硬件代数和可用系统 RAM 的不同而显著变化，这会影响操作系统页面缓存保持专家常驻的能力。

硬件	测得解码速度
M2 MacBook Air (8 GB RAM)	5.1–6.3 tok/s
M4 Mac mini (16 GB RAM)	≅5 tok/s
M5 Pro (24 GB RAM)	31–35 tok/s
M4 Max (64 GB RAM)	≅48 tok/s

内存更大的用户（例如 64 GB）报告显著更高的速度，因为操作系统页面缓存可以将整个 12 GB 的 packed_experts 集合常驻内存，从而有效消除 SSD 延迟。

实现与工具

TurboFieldfare 是一个针对特定模型的运行时，使用 Swift 6.2 和 Metal 4 编写，而非像 llama.cpp 或 MLX 那样的通用框架包装器。它提供了多种交互接口：

Native Mac App（原生 Mac 应用）： 一个基于 SwiftUI/AppKit 的应用，用于模型安装和聊天。
CLI（命令行界面）： 用于指令聊天和原始补全的命令行界面。
OpenAI-Compatible Server（兼容 OpenAI 的服务器）： 一个回环服务器，支持 Chat Completions 和函数工具。
Streaming Installer（流式安装器）： 一个工具，通过 range requests 将 Hugging Face 检查点直接重新打包为 .gturbo 格式，避免在磁盘上存储完整的源检查点。

技术要求

运行 TurboFieldfare 需要以下环境：

硬件： Apple Silicon Mac（arm64）。
操作系统： macOS 26，配合 Metal 4。
开发工具： Xcode 26 和 Swift 6.2 或更高版本。
存储空间： 大约 14.3 GB 的可用空间用于模型安装。

社区洞察与分析

用户之间的技术讨论突出了关于 SSD 流式传输用于 LLM 的可行性的几个关键点：

与 mmap 的比较： 虽然 llama.cpp 可以通过 mmap 在低 RAM 环境下运行大型模型，但 TurboFieldfare 专门将 SSD 读取与推理活动同步，以最小化延迟。
SSD 磨损： 用户提出了持续读取权重对 SSD 使用寿命的影响问题，尽管源材料中未提供具体的退化数据。
硬件演进： 从 M2 到 M5 的性能跃升表明，内存带宽的提升和更快的 SSD 正在使本地推理大型模型变得日益可行。

"26B 在 2GB 中运行相当于把整个公寓装进储物柜，还能有空间走动的工程等价。"