Yanah 让 80B 大模型在 8GB Mac 上本地运行

如果你告诉一位系统工程师——或者问另一个 AI——一个 800 亿参数的模型（磁盘占用 28.99 GB）能否在一台关闭 Wi-Fi 和蓝牙的 8 GB MacBook 上本地运行，速度达到每秒 5 到 8 个 token，他们的第一反应都会说这不可能。 在 stock mlx-lm 或 llama.cpp 这类标准引擎里，确实不可能： Yanah（moe_prefetch）通过利用混合专家（MoE）模型的物理结构、实施精准的三级量化，并把 Apple Silicon 的 NVMe SSD 当作统一内存的预测性零拷贝扩展，同时解决了这两个问题。 Yanah 的 80B 档位运行的是 Qwen3-Next-80B-A3B，这是一个有 48 层的混合混合专家架构： 在磁盘上，这 24,576 个路由专家约占模型的 96%（约 77B 参数）。而「常驻」的稠密主干——token embeddings、Attention、Gated DeltaNet、Routers、Shared Experts 和 lm_head——只有约 3B 参数（约占模型的 4%，在 RAM 中为 1.50 GB）。 对于任何一个词元（token），每一层的 router 只会唤醒 512 个专家中的 10 个（1.95%）。每层其余 502 个专家（98.05%）什么都不做。你永远不需要把全部 800 亿参数同时放进 RAM——你只需要把 1.50 GB 的主干永久留在 RAM 中，再加上一种能在 GPU 需要之前从 SSD 流式读取每层被选中的 10 个专家的方法。 人们以为我们在受限硬件上用的是标准的 2-bit 模型。并不是。 统一的 2-bit 量化会在两处破坏 Qwen3-Next：(1) 它的 36 个 Gated DeltaNet 层会在每个 token 上更新一个滚动循环记忆状态，因此 2-bit 投影会在每一步向短期记忆注入约 37% 的噪声；(2) 2-bit router 只有 4 个权重级别（0、1、2、3），会把 512 路专家排序打乱超过 55%。 因此，Yanah 采用了三级混合精度布局（quantize_2bit.py）： 为什么「2-bit g32」实际上是每权重 3.0 bits：因为 Yanah 使用了 32 的紧凑 group size 以及 BF16 仿射 scale 和 bias，每条 1.125 MiB 专家记录（384 KiB）中有三分之一是高精度 BF16 scale 和 bias 元数据。而且由于每一层都会把 10 个路由专家加权求和后叠加到 4-bit Shared Expert 上，10 个专家之间不相关的量化噪声会部分抵消。 在 Qwen3-80B 的全部 48 层中，Yanah 的 2-bit g32 专家实测相对 RMS 权重误差介于 36.04%（第 0 层）和 36.91%（第 41 层）之间，中位数为 36.68%。 Yanah 的 Source-Available / Fair-Source 流式引擎（moe_prefetch v00.1.00，为 8 GB Mac 改编了 SlotStream 的机制）完全绕过了 macOS swap： 如果 GPU 在每一层都空等 SSD，解码就会慢如蜗牛。Yanah 通过五种机制让 SSD I/O 与 GPU 计算重叠： 以下是 8 GB Mac 上精确的进程内存预算（为 macOS 留出约 3 GB，且零 swap）： *测试所用机型为 64gb MacBook Pro M1 和 M3 MacBook Pro M3。这两项已确认。大多数其他统计数据和说法由 AI 计算得出。我已尽一切努力确保信息确凿可靠。