内存不够也能跑 80B：把专家放到 SSD 上

48 GB 的模型，32 GB 的笔记本。常规选项只有两个：放弃，或者量化到面目全非。有人选了第三条路——让模型大部分时间躺在硬盘上。

一、发生了什么

GitHub 项目 janas，作者 prabanta-dev（Maurizio Cammalleri），纯 C 写，除标准库外没有依赖。README 第一句就把定位说死了：这是实验，不是产品。

它的机制建立在 MoE 的一个特性上。混合专家模型内部有很多组「专家」参数，但每个 token 只激活其中少数几个。既然每次只用一小部分，就没必要把所有参数都读进内存。

于是它的做法是：权重整体留在 NVMe 硬盘上；每生成一个 token，只把当前需要的那几个专家从盘上读进来；反复被用到的专家留在内存里，形成缓存；读盘走 O_DIRECT，绕过系统页缓存，直接全速读。打开模型时，它会把当时所有空闲内存都吃成专家缓存——跑 80B 时约 19 GB——也可以用 --cache 参数设上限。GPU 是可选的，用 Vulkan 加速读 prompt；再用模型自带的预测块或小草稿模型做推测解码，一次猜几个词再由主模型校验。

官方数字来自一台 Intel Core Ultra 9 185H、32 GB DDR5、5.7 GB/s NVMe 的笔记本。Qwen3-Next-80B-A3B 是 48.4 GB，读 1024 token 的 prompt 是 62 tok/s，同一台机器同一个文件上 llama.cpp 是 16；生成是 24 对 2.8；开推测解码后 37。作者在 13 个模型上都报了领先，唯一例外是 3-bit 的 Qwen3-30B——prompt 读取 100 对 112 略慢，但生成快约 3 倍。

推测解码的收益跟语言有关。作者公布的草稿接受率在 Qwen 系列和较大的 Gemma 上是 74% 到 89%，Gemma 的两个小模型是 63% 到 72%，而同一套设置换成意大利文，Qwen3.5-2B 只有大约三分之一命中，几乎等于白跑。这不是配置问题，是草稿模型对文本类型的敏感度。

还要看 llama.cpp 那一侧的条件：80B 模型上常规构建一开 GPU 就爆内存，作者只能用关掉权重重排、关掉 host 缓冲、加上 mmap 的方式才让它跑起来。他自己也承认，两边的测量方法并不完全一致。

二、跟你有什么关系

只有 32 GB 内存的笔记本用户。 现在有一条能碰 80B 的路。代价是硬盘占用、发热，以及后台别开太多东西。

准备买大内存机器的人。 先问自己是不是真需要 80B。同样是这台机器，9B 模型读 prompt 有 111 tok/s。多数日常任务用不到那么大的模型。

做内部工具的人。 「热数据留内存、冷数据留盘」这个思路本身值得抄，不一定要用这个项目。很多系统里最贵的不是算力，是把用不上的东西全塞进内存。

三、怎么判断要不要试

1. 先量硬盘顺序读。他那台是 5.7 GB/s 的 NVMe。盘慢一半，等盘时间就成倍涨，瓶颈会从算力整体移到磁盘上。
2. 确认模型是 MoE 且激活参数少。同机上稠密 27B 只有 4.4 tok/s，流式加载救不了稠密模型。
3. 用 --cache 给内存占用设上限。它的默认行为是填满所有空闲内存，桌面可能被挤进 swap。作者自己也说，这个引擎对机器相当粗暴，用之前先把重要工作存盘。
4. 首次运行和稳态分开测。缓存没填满之前，速度会明显低于公布值。
5. 关掉浏览器和编辑器再测一遍，看速度掉多少。作者说这两样开着时只剩约四分之三的速度，等盘时间变成五倍。

四、三个别信的说法

「这是 llama.cpp 的替代品。」 作者自己写的是实验，接口一周内改过多次，唯一的稳定承诺是模型文件格式。它适合拿来验证想法，不适合压在生产上。

「37 tok/s 说明 80B 变便宜了。」 这个数字来自单台机器、单次测量，而且对照组是被迫用 mmap 才跑起来的 llama.cpp。换个 CPU、换个硬盘、开着后台，数字都会变。它证明的是「可行」，不是「普遍如此」。

「显存不够就上 SSD 流式加载。」 稠密模型没有稀疏激活，每个 token 都要过全部权重，流式只会更慢——重量没减少，只是多了一次读盘。这条路只对 MoE 成立，而且要求激活参数足够少。

五、一句话结论

省下的不是模型大小，是「每个 token 要读多少」。这才是流式加载真正改变的东西。

信息来源

• prabanta-dev, "janas"（在内存不足的机器上运行大型 MoE 模型）, GitHub, 2026 年 10 月：https://github.com/prabanta-dev/janas

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。