一个26B参数的大模型，常规部署要占用十几GB内存。开源项目TurboFieldfare把这个数字压到了约2GB，让Gemma 4 26B-A4B能在最低8GB内存的Apple Silicon Mac上跑起来。项目作者是一名做图像、视频和设备端AI的iOS/Metal工程师，代码放在GitHub上，目前有351颗星。
它靠的不是把模型整体变小，而是把大部分权重留在SSD上，GPU算到哪一层，才现读那一层要用的专家。这条路证明了"用存储I/O换内存空间"可行，但项目绑定单一模型、要求特定系统版本，不能当成对所有26B模型通用的省内存方案。
TurboFieldfare怎么让26B模型只占2GB内存
TurboFieldfare不把14.3GB的完整模型一次性读进内存。真正常驻的，是1.35GB共享核心加上FP16 KV缓存，两者加起来约2GB。占大头的路由专家权重平时留在SSD上，按每层路由器算出的结果现读现用。
这里有个容易被忽略的细节：14.3GB的安装体积换算下来，平均每个参数不到4.4比特。这说明模型存储时大概率已经做了低精度量化，跟FP16原始体积没法比。SSD流式加载解决的是"要不要常驻内存"，量化解决的是"文件本身有多大"，这是两件事，不是二选一。
具体到每一层：GPU先用常驻权重算attention和路由，CPU拿路由器给出的前8个专家ID，去查16槽位的缓存。缺的部分并行从SSD读进Metal可见内存。
这段I/O等待的同时，GPU顺手把常驻的共享专家分支算完，两边结果再合并输出。处理输入prompt时还会按最多128 token分块，让一次读到的专家能服务多行，减少重复读盘。
省下来的不是模型体积，是常驻内存。存储读写换来了运行门槛的降低。
门槛卡在系统版本和单一模型上
安装完整模型仍要14.3GB存储空间，首次下载约15GB。系统要求是macOS 26配Metal 4，还要Swift 6.2以上、arm64架构。官方验证过的机型是8GB的M2 MacBook Air，不是随便一台M系列Mac都跑通过。当前版本只做文本推理，没有工具调用、图片、音频，项目文档也写明这是独立个人项目，与Google无关。
| 适合 | 不适合 | |
|---|---|---|
| 硬件 | 8GB以上Apple Silicon Mac，存储留有15GB以上空余 | Intel Mac、旧macOS版本 |
| 需求 | 想验证低内存能不能跑通26B模型 | 需要图片、音频、工具调用等多模态能力 |
| 用途 | 个人本地试用、技术验证 | 生产环境、多模型切换 |
跟MLX、llama.cpp比，省内存的代价是速度
作者自测的解码速度，8GB M2 MacBook Air上是5.1-6.3 token/s，24GB M5 Pro上是31-35 token/s。这是项目作者自己跑出来的数据，不是第三方基准测试，提示词长度、系统页面缓存状态都会影响结果，不能直接套用到别的设备上。
省内存的账，最终记在了存储和等待时间上。
拿它跟MLX、llama.cpp这类通用运行时比会更清楚问题所在。要在这类框架里跑同体量的26B模型，通常得把大部分权重装进内存，这也是过去同规模模型很少能在8GB内存Mac上跑起来的原因。
| 方案 | 内存占用方式 | 支持模型范围 |
|---|---|---|
| MLX / llama.cpp常规部署 | 权重基本整体入内存，10GB以上起步 | 通用，换模型即可跑 |
| TurboFieldfare | 常驻约2GB，专家权重按需从SSD读 | 目前只认Gemma 4 26B-A4B这一个checkpoint |
TurboFieldfare换了个思路，不做通用封装，而是专门为这一个checkpoint写运行时和Metal kernel。换来了低内存占用，代价是认死一个模型，换个checkpoint这套代码就用不上了。
对开发者来说，这更适合当一次技术验证：8GB Mac能不能塞下26B模型，能，但要拿存储空间、系统版本和一部分速度去换。想要多模型切换或稳定高吞吐的团队，这套方案目前替代不了MLX、llama.cpp这类通用框架，没必要迁移。
项目作者接下来打算把这套思路搬到iPhone和iPad上，再测测16GB M4 Mac mini之类的机型。这批数据出来之后，才能看清这套方案能不能走出Gemma这一个模型的范围。