本文首发于黑粉科技公众号
14.3GB模型，运行真只占2GB？
完整模型没有消失。真正发生的是：常驻核心留在内存，专家权重留在固态硬盘，需要时再换进有限槽位。
2026-08-01 · 黑粉科技 · M5 Pro本机复现实验
26B模型运行时只占约2GB，听起来像是M芯片突然违反了物理规律。真正把模型装下来以后，外置BigDisk却少了14,291,915,755字节。两个数字都是真的，只是它们测量的不是同一件事。
完整模型安装占多少磁盘，回答的是“总共有多少权重”；进程物理footprint，回答的是“当前有多少东西驻留在工作内存”。TurboFieldfare没有把14.3GB压成2GB，而是把大部分专家权重留在固态硬盘，只把公共核心、键值缓存和有限复用槽维持在内存。
// 2GB不是模型大小，也不是最低机器内存；它是特定配置和工作负载下的运行时物理占用。
▍🎯 完整模型到底有多大
我从头编译TurboFieldfare，把目标模型安装到外置BigDisk，再运行项目自带的强校验。结果是37个文件，总计14,291,915,755字节。公共模型文件是1,353,771,068字节；30层专家文件每层429,916,160字节，合计约12.01GiB。
账目 | 本机结果 | 运行时角色 |
完整文本模型 | 14,291,915,755 bytes | 保存在磁盘 |
公共核心 | 1,353,771,068 bytes | 常驻内存 |
专家文件 | 30层，约12.01GiB | 按路由结果从SSD读取 |
4K FP16 KV缓存 | 约305MiB | 随上下文使用 |
※ 字节数来自本机manifest与验证回执；缓存口径来自官方系统设计。
模型采用混合专家结构。总参数约26B，但每生成一个token，只激活一部分专家。运行时根据路由结果读取当前需要的专家，把它们放进每层16个复用槽；没有被选中的专家继续留在固态硬盘。省下的是常驻内存，不是模型总量。
▍🔍 测试不是问三句话就报速度
三组测试严格复用项目公开的real-generation-v1协议：4096上下文、温度0.2、Top-K 64、Top-P 0.95，每题使用固定随机种子。每一题先完整预热一次，预热结果丢弃；随后启动新的TurboFieldfareCLI进程进行正式测量。预热和正式轮不共用同一个进程。
测试机器是18核Apple M5 Pro、64GB内存、macOS 26.5.2。测试开始时系统可用内存约94%，机器接通交流电，模型放在外置BigDisk。这个环境能证明完整链路、回答质量和M5 Pro上的速度，不能偷换成8GB机器的同速结论。
▍⚡ 三道题分别测到了什么
短解释：能不能同时讲机制和边界
第一题要求解释沿海湿地怎样降低洪水损失，并指出两个限制。输入61个token，生成497个，解码速度40.499 tok/s。回答列出摩擦、波浪衰减与蓄水三个机制，又说明水太深或湿地空间不足时保护会下降，最后把“降低风险”和“完全防护”明确分开。
设计评审：能不能发现真实工程风险
第二题给出一段存在并发问题的缓存设计。输入430个token，生成721个，速度38.074 tok/s。回答找到了缓冲区被异步覆盖、多个请求重复读取同一文件、payload没有上限，以及数据仍在写入却被统计成命中的问题，并提出有界缓存、单任务去重、引用计数和状态锁。
长文综合：上下文变长以后还能不能抓住重点
第三题的测试输入达到3015个token，要求从一组项目资料中提炼核心资源约束。模型生成610个token，速度降到34.357 tok/s，但正确区分了1.35GB常驻核心与SSD专家流送，也说明预填充可以批量复用专家，而逐词生成一次只处理一个token，更容易受到I/O等待影响。
三道题的停止原因全部是endOfTurn，不是碰到token上限。对应的测试输入、标准输出、标准错误输出、机器信息和哈希都保存在运行目录中。速度下降也有清楚趋势：输入从61增加到3015个token，解码从40.499降到34.357 tok/s。三组回答都自然结束。
▍💰 约2GB是怎样测出来的
独立内存轮使用ps每0.5秒记录一次RSS，同时调用macOS footprint。有效运行第一次观察到标准输出是6.220秒，采样RSS峰值1.780GiB，物理footprint峰值2.220GB，总墙钟9.878秒。
这个结果复现了“约2GB”的运行口径，但不包含整个系统动态文件缓存，也不能与没有仪器开销的正式三题速度直接横比。仪器化轮只负责证明内存口径。
内存轮不是一次成功。第一次限制256个token，回答停在第二项；第二次限制512个，停在第四项，还猜测了输入没有提供的KV量化格式。两次程序都正常退出，但回答不完整，所以都被排除。第三次把任务约束在240个汉字，并禁止补充输入外配置，最后用134个token自然结束，才进入结论。
// 程序退出码是工程状态，回答是否完整是内容状态；两者不能互相代替。
▍🧩 谁能真正用上它
使用者 | 具体价值 | 必须接受的代价 |
8GB Mac用户 | 离线尝试26B级文本模型 | 官方M2 Air仅5.10–6.30 tok/s，首token约8–38秒 |
本地文本用户 | 短解释、资料归纳、离线草稿 | 重要答案仍需复核 |
软件开发者 | 研究Swift/Metal低内存嵌入与本地兼容服务 | 目前固定模型、仅文本 |
内存充足且追求吞吐 | 优先选择MLX | 官方同机MLX约76.33–82.07 tok/s |
※ 不同方案目标不同：TurboFieldfare优先压低常驻内存，MLX优先吞吐。
第一类价值是给8GB Mac一张入场券。作者的M2 MacBook Air数据为5.10–6.30 tok/s，首token随提示长度从约8秒增加到接近38秒。这能完成离线尝鲜和不着急的单次任务，但不等于即时云端聊天体验。
第二类价值是把已被验证的文本任务留在本机。三道题已经覆盖短知识解释、设计评审和长文归纳，因此本地资料总结、离线草稿、代码或架构审查，是目前证据最充分的用途。模型仍可能出错，本地运行只改变数据路径和调用费用，不会消除幻觉。
第三类价值属于Mac软件开发者。项目提供原生应用、命令行程序和实验性的本地OpenAI兼容服务。Swift、Metal、分块预填充、有限复用槽和SSD并行读取都是Apache-2.0代码，可以直接检查和改造。它更像一份低内存专用运行时样本，而不是又一个聊天壳。
如果机器内存充足，而且每天要处理大量任务，吞吐可能比节省几GB常驻内存更值钱。项目公开的24GB M5 Pro对照中，MLX达到76.33–82.07 tok/s。TurboFieldfare解决的是“内存不够还能不能跑”，不是“所有机器怎样跑得最快”。
▍🚀 边界比口号更重要
当前只支持Apple Silicon与macOS 26，目标是固定的Gemma 4 26B-A4B IT文本模型；没有图像和音频；App与CLI不会替用户执行工具。
代码采用Apache-2.0，但模型存储、Mac硬件和等待时间都不是零成本。说“代码免费”成立，说“从此所有AI都不用花钱”不成立。更准确的说法是：一部分能够接受等待的文本任务，可以从云端调用迁回本地。
$ 项目仓库：https://github.com/drumih/turbo-fieldfare
$ 系统设计：https://github.com/drumih/turbo-fieldfare/blob/main/docs/SYSTEM_DESIGN.md
$ 官方基准：https://github.com/drumih/turbo-fieldfare/blob/main/docs/BENCHMARKS.md
$ 社区协议：https://github.com/drumih/turbo-fieldfare/blob/main/docs/COMMUNITY_BENCHMARKS.md
最后的判断
M芯片没有成神。TurboFieldfare真正完成的是资源搬家：完整模型仍占约14.3GB磁盘，运行时把常驻物理footprint控制在约2GB，把代价交给SSD读取、缓存和等待。8GB机器获得了运行资格；内存充足、吞吐优先时，MLX仍然更直接。
分享到：