🐥 *TurboFieldfare：用 2 GB 内存在任意 M 系列 Mac 上运行 Gemma 4 26B*
一套纯 Swift + Metal 自研推理引擎，把 14.3 GB 的 MoE 大模型装进约 2 GB 内存，让 8 GB 的 MacBook Air 也能本地跑 26B 模型
✨ 特点
- 2 GB 内存跑 26B 模型：利用 Gemma 4 26B-A4B 的混合专家架构，每个 token 只激活约 3.88B 参数，常驻内存仅保留共享核心与 KV 缓存，其余专家权重按需从 SSD 流式读取。
- 不是 MLX 或 llama.cpp 的封装，针对 Gemma 4 的层结构从零编写的运行时，自研全部 Metal kernel（量化 GEMV、注意力、MoE、采样与融合算子）
- 同一份 .gturbo 模型可供原生 Mac 应用、命令行工具和本地 OpenAI 兼容服务器三种方式使用，服务器支持流式输出、函数工具调用和提示词前缀复用
- 从 Hugging Face 按字节区间边下边重打包，全程不落完整源文件，约 15 GB 传输量直接生成带哈希校验的本地模型
- 可选视觉扩展包：额外安装 1.1 GB 的视觉塔即可让应用、命令行和服务器统一支持图片输入（需 M2 及以上）
-
103 个公开实验记录：仓库完整记录了 kernel、缓存、I/O、预填充等方向上成功与失败的全部实验
⚙️ 机制
TurboFieldfare 的核心思路是「让不该进内存的权重留在 SSD 上」。运行时常驻约 1.35 GB 共享核心（注意力、路由器、词嵌入和共享专家）加 FP16 KV 缓存（4K 上下文约 305 MiB）；每层 128 个路由专家（共 30 层、约 12.9 GB）留在磁盘，由路由器每 token 选出 top-8，先查询该层 16 槽 LFU 缓存，未命中的用有界并行 pread 读入 Metal 可见缓冲区，同时 GPU 并行计算常驻的共享专家分支，I/O 与计算相互掩盖。预填充按最多 128 token 分块，让一次读取的专家服务多行计算。作者实测显式 pread 比 mmap 被动缺页快得多：冷读单个 3.36 MB 专家 2.8 ms 对 10 ms，整体吞吐 4 tok/s 对 0.5 tok/s；约 41% 的专家会在下一个 token 复用，16 槽缓存命中率约 67%。
主要依赖：仅 3 个外部包。swift-transformers（分词）、swift-nio（服务器）、SwiftMath（公式渲染），其余全部自研。
实测性能：8 GB M2 MacBook Air 解码 5.1–6.3 tok/s，24 GB M5 Pro 达 31–35 tok/s（同机 mlx-lm 为 76–82 tok/s，但需要 8–10 GB 常驻内存与约 15 GB GPU 分配）。差距主要来自 M5 三倍于 M4 的 SSD 读取带宽。运行要求 macOS 26、Metal 4、Swift 6.2，仅支持 Apple Silicon。
👨🏻💻 使用场景
- 8 GB 入门款 Mac 用户跑大模型：最便宜的 M2 MacBook Air 也能本地运行 26B 级模型做草稿撰写、摘要和问答，不用为了本地推理专门升级 32 GB 以上的机器
- 开发者接入本地 OpenAI 接口：服务器监听本机 8080 端口，把 OpenCode 或任意 OpenAI SDK 的 base URL 指过来，即可零 API 成本地调试提示词、函数工具调用等流程
- 保护隐私的离线办公：模型装好后完全离线运行，处理合同、病历、内部文档等敏感材料时数据不出本机
- 端侧推理工程学习：实验记录加系统设计文档完整展示了 mmap 与 pread 的取舍、专家缓存策略、I/O 与 GPU 重叠等决策过程，适合想学 Metal 推理优化的工程师
- 多任务并行的轻量后台:推理只占 2 GB 内存，可以边开着浏览器、IDE 和设计软件边让模型在后台生成，不会挤爆内存
🖊 作者背景
Andrey Mikhaylov – Senior iOS & Metal 工程师
- Lapse（伦敦社交相机应用，总融资 $42.3M）：资深 iOS、Metal 与相机工程师（2024 至今）。负责月处理约 1 亿资产的媒体管线，自建 Metal 实时照片视频管线，吞吐为原 Core Image 方案 10 倍
- Prisma Labs（Prisma、Lensa 开发商）：资深 iOS 与 Metal 工程师、视频团队技术负责人（2021–2024）。构建端侧实时人脸修饰管线，老设备上 17 ms/帧
项目名取自他最喜欢的鸟，田鸫（fieldfare）。
频道:@NewlearnerChannel