
9 月
slotstream:105 GB 的 Qwen 3.8-Flash-Next,怎样在 48 GB Mac 上跑到约 12 tok/s
核心结论:slotstream 没有把 105 GB 模型“压进”48 GB 内存,而是利用 MoE 的稀疏激活特性,让主干常驻内存、专家权重按需从 SSD 进入固定缓存池。这个思路能让模型跑起来,但不会消除磁盘、首 token 等待和平台限制。
调研与撰写:AI 基于仓库、模型卡和社区讨论整理;主导与审校:智盒编辑。性能数据均标明作者实测或估算,不扩写为通用保证。
AI 摘要
- 项目用途:在装不下完整权重的 Apple Silicon Mac 上运行 Qwen 3.8-Flash-Next 4-bit。
- 核心机制:3.8 GB 稠密主干常驻内存,512 个专家按需从 SSD 流式进入共享缓存池。
- 作者实测:48 GB M 5 Pro、约 33 GB 进程预算下,热解码约 12 tok/s;8 GB 至 32 GB 档位主要来自曲线估算。
- 硬门槛:macOS 14+、Apple Silicon、约 110 GB 可用磁盘,并且当前只支持这一款模型。
- 智盒判断:这是很聪明的工程实验,也有真实使用价值,但不是 Ollama 或 llama.cpp 的通用替代品。
它解决的不是算力,而是内存布局

Qwen 3.8-Flash-Next 是一个 125 B 参数的 MoE 模型,4-bit 权重约 105 GB。常规加载器试图把权重整体映射到内存,48 GB Mac 会在生成第一个 token 前进入大量 swap。slotstream 的做法不同:它只让约 3.8 GB 的稠密主干常驻,模型每一步需要的专家权重再从 SSD 读入固定槽位。
这项优化成立的前提是 MoE 的稀疏性。模型有 512 个专家,但每个 token 只激活其中 10 个。slotstream 因此可以把有限内存留给热点专家,而不是为永远不会同时使用的全部专家买单。
截至 2026-09-03 核查,项目约 262 Star、14 Fork,采用 MIT 许可,仓库当天仍有提交。数字会继续变化,判断项目价值时应优先看 README 的测量方法和限制,而不是只看 Star。
作者公布的性能,应该怎样读
| 设备或条件 | README 给出的结果 | 证据边界 |
|---|---|---|
| 48 GB M 5 Pro | 热解码约 12 tok/s,峰值内存约 32 GB | 作者真实硬件测量 |
| 32 GB Mac | 约 9 tok/s | 由 48 GB 曲线估算 |
| 24 GB Mac | 约 8 tok/s | 估算 |
| 16 GB Mac | 约 4 tok/s | 估算,长上下文等待明显增加 |
| 8 GB Mac | 约 3 tok/s | 最低档,doctor 会提示分页风险 |
“热解码”只描述模型开始连续出字后的速度。长 prompt 仍要在首 token 前完整预填:作者报告 48 GB Mac 处理 8 K prompt 约等 39 秒,32 K prompt 约等 3 分钟。16 GB Mac 的 32 K 等待可能达到约 6.4 分钟。
因此,这个项目适合本地批处理、离线研究和能够接受等待的聊天工作流,不适合要求极低首 token 延迟的交互产品。
上手前先跑 doctor
项目提供一条安装脚本,但脚本会从网络下载并执行。更稳妥的做法是先阅读脚本,或克隆仓库后自行构建。
git clone https://github.com/carloslfu/slotstream
cd slotstream
make build
slotstream doctordoctor 会显示本机内存方案、预计速度和磁盘是否足够。确认后再拉取约 105.3 GB 的 25 个权重文件。下载支持断点续传和 SHA-256 校验,但 512 GB Mac 才有比较现实的空间余量。
启动服务后,它提供 Ollama 与 OpenAI 风格的部分聊天接口:
slotstream serve
curl localhost:11434/api/chat -d '{
"model": "qwen3.8-flash-next:4bit",
"messages": [{"role": "user", "content": "hello"}]
}'Open WebUI 和部分 OpenAI SDK 路径已经测试。工具调用、图像、JSON Schema 输出和 logprobs 暂不支持,Ollama CLI 也不是完整兼容。
适合谁,不适合谁
适合:
- 有 Apple Silicon Mac、磁盘空间充足,想研究大 MoE 模型本地推理的人。
- 需要数据留在本机,同时能接受较慢首 token 的开发者。
- 想研究专家缓存、统一内存和 SSD 流式加载的系统工程读者。
不适合:
- Linux、Windows、NVIDIA 或 AMD 独显用户。
- 想切换 Llama、DeepSeek 或其他 Qwen 型号的人。
- 需要工具调用、多模态、超长上下文和稳定生产 SLA 的团队。
如果你更需要通用模型兼容,优先看 llama.cpp 或 Ollama;如果你关心国产模型按场景怎么选,可以先读智盒的国产大模型场景选型决策树、国产模型长上下文选型和Kimi K 3 在 8 GB 内存上的 CPU 推理实验。
风险与限制
- 只支持 Qwen 3.8-Flash-Next 4-bit,模型几何结构被写进了引擎。
- 只有 48 GB 档位是真机测量,小内存速度不能当作保证。
- SSD 会承担持续随机读取,速度、温度和寿命影响需要长期观察。
- 本地运行不等于自动安全;下载脚本、模型权重和开放的本地 API 都要按普通软件供应链管理。
FAQ
8 GB Mac 真能跑吗?
项目给出的最低内存规划约 8.1 GB,doctor 会明确提示分页风险。能启动和适合日常使用是两回事,8 GB 设备更适合验证,不适合重度工作。
为什么不能支持普通稠密模型?
稠密模型每个 token 都要使用全部权重,没有“只加载少数专家”的空间。slotstream 的收益来自 MoE 稀疏激活。
可以商用吗?
代码采用 MIT 许可,但模型权重仍受 Qwen 自己的模型许可约束。商用前要同时检查两份许可。
它会替代 Ollama 吗?
不会。它只实现 Ollama API 的一部分,目标是让一个特定大模型在小于权重体积的内存里运行。










