我通过从SSD流式传输MoE专家权重，在36 GB MacBook上运行35B–480B编码模型——自包含应用，并且我也公开了那些*失败*的基准测试

我厌倦了"你的Mac无法运行这个"的说法，于是 fork 了 llama.cpp，使MoE模型的专家权重能够从SSD流式传输，而不是强行载入RAM。MoE每token只激活少数专家，因此大部分权重处于闲置状态——Slipstream 保留始终需要的权重在内存中，并按需流式传输路由的专家，进入一个有界RAM缓存，该缓存拒绝加载任何会导致Mac交换内存的数据。它以原生macOS应用的形式发布，引擎已内置其中——下载.dmg，拖到应用程序文件夹，打开。无需编译。将 Kilo/Cline/Cursor/OpenCode 指向 localhost:8080。（尚未公证，因此首次启动需要右键单击→打开。）由于这个 sub 需要真实数据，首先是基于事实的部分： - Qwen3.6-35B-A3B（Q4），从内部NVMe流式传输：10 GiB缓存（命中率78%）下约13 tok/s，14 GiB缓存下约19 tok/s。35B的模型适合交互式工作。 - Laguna 118B-A8B，它无法放入36 GB内存：约2.8 tok/s。可用于批量编码，不适合聊天。 - 最大的杠杆并非巧妙的kernel——我将一个文件（流式传输的专家权重）移到更快的磁盘上，性能提升了2.7倍。存储位置胜过一切。 - 我原本错误地否定了一条零拷贝路径，但在实际缓存大小下，它带来了13–24%的提升——现在默认启用。 还有那些*没成功*的，因为这是诚实的一部分： - 双SSD条带化：内部NVMe + 慢速USB（共享总线）效果为负。 - 投机性预取预测器（静态+在线）：-8%。预测无法超越读取成本。 - HOT专家保留：-1%到-6%（它缩小了通用缓存）。 完整文章（包括负面结果）：BENCHMARKS.md。 仓库 + 自包含的.dmg在链接中。采用MIT许可，完全在设备上运行。受 JustVugg/colibri（为CPU/CUDA实现此功能）启发；我将其适配到Apple Silicon + Metal。 乐意回答基准测试问题——如果有人拥有两块快速NVMe驱动器并想测试双SSD路径（应该会胜出），我很期待数据。