105GB 模型跑在 16GB Mac 上：能跑，和好用是两回事

105 GB 的模型，16 GB 的 Mac，这两个数字放一起通常意味着失败。Slotstream 的做法是让模型大部分留在 SSD，只把当前 token 需要的专家读进内存。它跑的是 Qwen3.8-Flash-Next，一个 125B 参数的 MoE 开源模型，原始 4bit 权重约 105 GB。

MoE 的意思是生成每个 token 只走一部分专家网络，不用把 125B 全部算一遍。Slotstream 把共享权重放内存，把专家从 SSD 读进缓存，常用专家留在 RAM。模型没有变小，它只是接受内存装不下这个前提。这像把衣柜留在走廊，每次拿一件衣服，能穿，但换衣服不免费。

官方给了一组可复核的数字：2026 年 10 月 5 日，48 GB M5 Pro，33 GB 内存预算，原始 4bit 模型，三个负载的中位生成速度分别是短提示 20.91 tok/s、较长上下文 23.69 tok/s、完成编码答案 21.59 tok/s。每个负载跑三次，测量期间无 swap。注意，tok/s 是生成速度，加载模型和处理提示另算。评论区里 Michał Piszczek 提醒得更准：README 的 10 GB 目标下，2K 首次读取大约 14 至 28 秒，16K 提示约 54 秒，而 20 多 tok/s 对应的是 33 GB 预算。预算怎么选，直接决定你等首字时有没有耐心。

上下文是另一个硬约束。48 GB 机器自动模式给 32,768 token 窗口，64 GB 到 131,072，96 GB 以上才到 262,144。有网友说 32k 对 agent 不可用，这个判断看任务，但长上下文要更多内存和时间，躲不掉。官方也写明一次只能跑一个生成，连接的 app 共享同一个模型。

反直觉的地方在 96 GB 以上的 Mac。模型能全放内存，Slotstream 反而不优化这类设备，其他把模型常驻内存的引擎会更快。它瞄准的是 16 到 64 GB 的机器，那些原本装不下模型的 Mac。作者 Carlos Galarza 说，他最初只想在自己的 Mac 上跑这个模型，标准加载器在出第一个回复前就把内存耗尽了。项目从那次失败开始。

安装不复杂，前提是 Apple Silicon、macOS 14 或更高、至少 16 GB 内存、约 110 GB 空闲 SSD。8 GB 机器不启动，Windows、Linux 和 Intel Mac 不支持。终端里第一条命令是：

curl -fsSL https://raw.githubusercontent.com/carloslfu/slotstream/main/install.sh | sh
slotstream doctor
slotstream run --prompt 'Why is the sky blue?'

doctor 只查内存和磁盘，不加载模型。第一次 run 会问要不要下载，下载可能几个小时，中断后可续传。之后离线可用，没有 Python，没有云账户。整个引擎是一个原生 Swift 程序，跑在 Apple 的 MLX 和 Metal 上。它还能用 slotstream launch claude 把 Claude Code 接到本地模型，Codex、Pi、opencode、Hermes 也走同样方式。开发者可以通过 Ollama、OpenAI、Anthropic 兼容 API 或 Swift 库接入自己的应用。有网友说，一个 Swift 二进制、没有 Python 才是亮点。对本地工具来说，少一层运行时，安装和空闲行为都简单很多。

SSD 寿命是评论区问得最多的问题。Qwen AI Fans 的回复是：主要是读，不是写风暴，常用专家留在内存缓存里，不会每个 token 都把整个模型从 SSD 拖一遍。但他们没有发布磨损数据。系统 swap 和会话缓存仍可能增加写入，自动内存规划能减少压力，小内存机器或手动设得过大仍可能频繁 swap。这一点官方没有给长期测试，买不买账要看你自己对风险的容忍度。

我的判断：Slotstream 解决的是内存不够时能不能跑，它没有解决长上下文和高并发便不便宜。适合离线、隐私敏感、轻量代理、单人把玩的场景。想拿 48 GB Mac 跑 32k 上下文的编码 agent，先接受首字等待和窗口限制。评论区有人提到 Sushi 在 48 GB M5 Pro 上做到 512k 上下文且更快，素材没有给出可复核数据，只能当线索。GitHub 上的测量记录把失败实验也留着，这点比只放一张跑分图更可信。地址在 carloslfu/slotstream。