slotstream：让 104GB 大模型在 48GB Mac 上跑起来

把 104GB 模型塞进 48GB 内存

在 Apple Silicon Mac 上跑本地大模型，通常受限于统一内存大小。Qwen3.8-Flash-Next 是一个 125B 参数的 MoE 模型，4-bit 量化后仍有 104GB，远超多数 Mac 的内存上限。slotstream 的做法是：不把整个模型载入内存，而是按需从 SSD 流式加载专家模块，让 48GB 内存的机器也能跑起来，实测速度约 12 tok/s。

这个思路直接改变了本地大模型的硬件门槛。以往要跑百亿级 MoE 模型，要么买 128GB 内存的高配 Mac，要么依赖云端 API。slotstream 用 SSD 换内存，把硬件成本降了一个数量级。项目基于 MLX 和 Swift 实现，兼容 Ollama API，意味着你现有的 Ollama 工作流可以无缝切换。

它怎么做到“流式专家加载”

MoE（混合专家）模型的特点是，每次推理只激活部分专家模块，而非全部。slotstream 利用这一点，将专家参数分块存储在 SSD 上，推理时按需读取到内存。这避免了传统推理框架需要常驻全部参数的问题。实际效果是，内存占用从 104GB 降到可运行水平，而速度损失控制在可接受范围——12 tok/s 对于交互式对话和代码生成已经够用。

从工程实现看，项目用 Swift 编写，深度适配 Apple Silicon 的 MLX 框架，并且暴露了与 Ollama 兼容的 API。这意味着你可以用任何支持 Ollama 的客户端（如 Open WebUI）连接它，而无需修改现有代码。对于喜欢折腾的开发者，它还提供了自定义加载策略的可能。

三个真实使用场景

场景一：本地开发环境下的模型验证。在写代码或调 prompt 时，需要频繁试验不同模型的行为。云端 API 每次调用都有延迟和费用，而 slotstream 让你在本地快速启动一个 100B+ 级模型，随时测试，不产生额外成本。

场景二：隐私敏感的数据处理。当处理涉及个人或商业机密的数据时，不希望上传到云端。slotstream 完全本地运行，数据不出设备，适合法律、医疗等对数据合规有严格要求的场景。

场景三：离线环境下的 AI 助手。在没有稳定网络的环境（如飞机、偏远地区），一个本地运行的强大模型可以作为知识库问答或写作助手。12 tok/s 的速度足以支持流畅的文本交互。

与同类方案的实质差异

目前本地跑大模型的方案主要有两类：一是用 llama.cpp 等框架，通过 CPU/GPU 混合推理，但内存占用仍与模型大小成正比；二是用 Ollama 直接加载，但同样受限于内存。slotstream 的差异在于它专门针对 MoE 模型设计，通过流式加载突破了内存瓶颈，这是通用推理框架没有做到的。

另一个差异是它的开发语言和生态。基于 Swift 和 MLX，意味着它能充分利用 Apple Silicon 的神经网络加速单元，性能优于纯 CPU 方案。同时，兼容 Ollama API 让它可以接入现有工具链，降低了迁移成本。

不过，它也有明显边界：只支持 MoE 架构的模型，对于 Dense 模型（如 LLaMA 系列）无法发挥流式优势；速度 12 tok/s 适合文本交互，但实时语音或视频生成可能不够流畅；另外，它对 SSD 的读取速度有一定要求，建议使用内置 SSD 而非外接硬盘。

结论

slotstream 用流式加载的方式，让 104GB 的 Qwen3.8-Flash-Next 在 48GB Mac 上以约 12 tok/s 运行，兼容 Ollama API，MIT 协议开源。它的价值在于降低了 MoE 大模型本地运行的内存门槛，特别适合拥有中端 Mac、希望本地运行大模型的开发者。如果你需要处理隐私敏感数据或离线环境下的 AI 应用，它值得一试。但若你用的是 Dense 模型，或对速度有更高要求，它可能不是最优解。

FAQ：常见问题

slotstream 支持哪些模型？

它目前主要支持 MoE 架构的模型，例如 Qwen3.8-Flash-Next（125B MoE，4-bit 量化后 104GB）。对于 Dense 模型，流式加载的优势不明显，可能无法发挥其设计效果。

运行 slotstream 需要什么硬件配置？

需要 Apple Silicon Mac（M 系列芯片），建议内存至少 48GB（实测可在 48GB 上运行 104GB 模型），并确保 SSD 读取速度足够快，因为专家参数会实时从 SSD 流式加载。