
48GB 内存跑 104GB 大模型:slotstream 从 SSD 流式加载专家,小内存 Mac 也能跑 Qwen3.8-Flash-Next
手把手教程:用开源工具 slotstream 在内存远小于模型体积的 Mac 上运行 125B 参数的 Qwen3.8-Flash-Next(4bit 量化 104GB),从安装、下载权重到内存调优的完整实操。
原文来源:GitHub - carloslfu/slotstream — 一个 Swift 编写的开源工具,通过从 SSD 流式加载专家权重,让内存远小于模型体积的 Mac 也能运行 125B 参数的 MoE 大模型
本地跑大模型,最卡脖子的永远是内存。Qwen3.8-Flash-Next 是个 125B 参数的 MoE 模型,4bit 量化后光权重就有 104GB——绝大多数 Mac 的内存都装不下。Ollama、MLX 这类常规方案的答案通常是「换台更大的机器」,或者把模型量化到损失惨重的程度。
开源项目 slotstream 换了个思路:既然内存装不下,就从 SSD 流式加载。作者在 48GB 内存的 M5 Pro 上实测:约 12 tok/s 的解码速度、3 秒冷启动、峰值内存 32GB——模型该有的能力一个不少,只是权重按需从硬盘流进来。项目发布后冲上 Hacker News 热榜,核心卖点是一个 Swift 二进制搞定一切、兼容 Ollama 和 OpenAI API,现有工具链直接换引擎。
本文带你完整走一遍:从检查自己的机器、安装、下载 104GB 权重,到跑起来并理解它的内存机制。
先确认你的 Mac 能不能跑
slotstream 的要求:Apple Silicon、macOS 14+、约 110GB 空闲磁盘。磁盘是第一个门槛——不管内存多大,512GB 的 Mac 才是现实起点。
不同内存档位的预期(来自官方 slotstream doctor --sim-ram N 的模拟,只有 48GB 档是实测数据):
| 内存 | slotstream 占用 | 热解码速度 |
|---|---|---|
| 8GB | 8.1GB(下限) | ~3 tok/s(会警告换页) |
| 16GB | 10GB | ~4 tok/s |
| 24GB | 16GB | ~8 tok/s |
| 32GB | 22GB | ~9 tok/s |
| 48GB 及以上 | 33GB | ~12 tok/s(加内存无增益) |
下载任何东西之前,先跑一条命令看你的机器方案:
slotstream doctor它会打印你机器的内存计划,以及磁盘能否放下权重。
—— 广告 ——
安装
一条命令装预编译二进制:
curl -fsSL https://raw.githubusercontent.com/carloslfu/slotstream/main/install.sh | sh装到 ~/.slotstream/bin 并加入 PATH。重复执行同一行命令即可升级,卸载是 rm -rf ~/.slotstream。
想验证下载物完整性(可选):发布版由 CI 从 tag 构建并带签名来源证明:
gh attestation verify slotstream-arm64.tar.gz --repo carloslfu/slotstream也可以自己编译——只要 Command Line Tools,不需要 Xcode:
git clone https://github.com/carloslfu/slotstream && cd slotstream
make build下载 104GB 权重
二进制很小,权重不小——103.8GB,24 个文件,只需下载一次。serve 和 run 首次使用会触发下载,也可以直接:
slotstream pull传输前它会打印大小、目标位置和你的空闲磁盘,等你确认;磁盘放不下会直接拒绝。实测一次完整安装约 35 分钟,Hugging Face 的传输上限约 36–57MB/s,100Mbps 宽带预计 2 小时 20 分,25Mbps 要 9 小时。
中断是安全的:pull 支持断点续传,24 个文件全部按内置的 sha256 校验,截断或损坏的下载到不了引擎。随时可以 pull --verify 重新哈希已有副本(实测 8 秒)。
跑起来
不启动服务器,直接一句出结果:
slotstream run --prompt "why is the sky blue?"正常使用走 serve,监听 11434 端口,实现 Ollama 客户端和 OpenAI SDK 使用的 chat/generate 子集:
slotstream serve测试兼容性(实测可用):Open WebUI、Ollama CLI、OpenAI SDK。流式、CORS、常规采样参数都支持;不支持的能力——工具调用、图片、JSON-schema 输出、logprobs——会返回明确的 400 而不是静默忽略。
curl localhost:11434/api/chat -d '{
"model": "qwen3.8-flash-next:4bit",
"messages": [{"role": "user", "content": "hello"}]
}'或者直接用 Ollama CLI 接上:
OLLAMA_HOST=http://localhost:11434 ollama run qwen3.8-flash-next:4bit几个使用要点:
- 提示 + 补全长上限 32768 token(
--max-context) - 同一时间只跑一个模型进程
- 长提示是慢的轴:整个提示处理完才出第一个 token,8000 token 的提示在 48GB Mac 上要等约 1 分钟,16GB 的要 3 分钟以上
- 但对话内只需付一次代价:后续轮次只 prefill 新增部分,首 token 时间保持平稳——第 8 轮对话是 6.0 秒而不是 25.8 秒
- 前缀缓存复用不是逐位等同重算,两个 token 接近并列时回复偶尔会不同;需要精确复现加
--no-prefix-cache
内存机制:为什么它不吃满内存
理解 slotstream 怎么工作,才知道怎么调。这个模型绝大部分字节在两个地方:68GB 的路由专家(每层 512 个,每个 token 激活 10 个)和 32GB 的 n-gram 表。稠密主干只有 3.8GB,常驻内存。
专家权重通过 pread 读进一个由全部 48 层共享的固定缓存槽池,热层会借用冷层的槽位。关键设计:缓存大小改变速度,绝不改变输出——贪心解码下 4GB 缓存和 24GB 缓存的输出逐位一致,这是项目的一个常驻测试。
为什么不直接 mmap?因为 MLX 无法物化内存映射张量的部分内容:top-10 专家 gather 会求值该层全部 512 个专家,mmap 路径会加载约 100GB 然后崩溃。官方实测 mlx_lm.load() 常规路线把 48GB 机器干进 48GB swap 也没吐出一个 token。
自动内存规划:无参数运行时自动取三个下限的最小值——33GB、内存的 70%、Metal working-set 限制减 2GB,且在其他应用实际占用内存时会继续缩小。33GB 是实测曲线的拐点:在逐 GB 扫描中,34 到 84GB 之间解码和 prefill 没有任何加速,所以 128GB 的 Mac 拿到的计划和 48GB 一样。运行中每 15 秒重查一次,请求之间调整缓存,压力大时收缩、压力过后再涨回来,输出在调整前后逐位一致。
手动控制:
slotstream serve --memory-gb 24 # 进程总内存上限(最小 8.1)
slotstream serve --max-ram-percent 60 # 调整 70% 的内存占比
slotstream serve --experts-per-layer 200 # 直接调缓存大小
slotstream serve --pool-gb 16 # 或按字节池大小现状与限制
诚实说明:项目目前只在一台机器上实测过——48GB 的 M5 Pro。小内存档位是曲线估算而非实机数据,且小内存 Mac 的 SSD 通常更慢。v0 只支持一个模型(qwen3.8-flash-next:4bit),引擎就是按这个模型的几何结构写的,pull 也不认识其他名字。macOS 14 和 15 只验证过安装器,没验证过运行时。
适合谁用
- 内存不够但想跑顶级开源 MoE 的人:这是目前少有的「低内存 + 大模型」可行路线
- Ollama/OpenAI 生态用户:API 兼容意味着换引擎不换工具
- 在意数据不出本机的人:权重完全本地,无任何云依赖
不适合:需要工具调用、图片输入、JSON-schema 输出的场景(明确不支持);或者你的工作负载是长提示密集型的——流式加载模型的长提示 prefill 会比较慢。官方在 PLAN.md 里公开了设计文档和里程碑,MEASUREMENTS.md 里有全部数据的测量方法和失败实验记录。
一句话总结:内存不够不再是跑不动大模型的终审判决——前提是你能接受 SSD 换内存、并且耐心等那 104GB 下载完。
© 2026 四月
原文链接:https://www.aprilzz.com/tutorials/slotstream-run-qwen-ssd-mac
相关文章
Qwen3.8-27B 本地部署实操:从 GGUF 到 vLLM,一块 24GB 显卡就能跑
手把手把 Qwen3.8-27B 跑起来:硬件要求、量化档位怎么选、Ollama / llama.cpp / vLLM 三条路线完整命令,以及 262K 上下文的坑。
llama.cpp 还是 vLLM?2026 年本地 LLM 推理引擎选型指南(附实测基准)
Red Hat 工程师用 Llama 3.1 8B 在单张 H200 上实测了两个主流推理引擎:64 并发下 vLLM 吞吐是 llama.cpp 的 44 倍,但 llama.cpp 在消费级硬件上依然是唯一选择。本文把量化、GGUF、PagedAttention、连续批处理讲清楚,附完整选型决策树。
用电子垃圾攒一台 128GB 显存的本地 AI 服务器:从 eBay 旧件到跑起 DeepSeek
四块 32GB 显存的 AMD V620 云游戏退役显卡、2017 年的 X299 主板、Intel 最差 CPU——作者用几百美元的 e-waste 攒了一台本地 AI 服务器,还 3D 打印风扇导流罩、用 Arduino 自制了温控。