Janas：从SSD流式加载专家，让LLM突破内存限制

当模型比内存还大，怎么办？

大语言模型的参数规模持续膨胀，而消费级硬件的内存容量却远远跟不上。一个直接的问题摆在我们面前：如果模型文件比可用内存还大，是否还能运行？

最近在 Hacker News 上出现了一个名为 Janas 的项目，其核心主张简洁而有力——通过从 SSD 流式加载专家（experts），运行超出内存容量的大语言模型。

这个思路的关键在于"专家"二字。它指向的是混合专家（MoE）架构：模型由多个专家子网络组成，每次推理只激活其中一小部分。既然大部分专家在单次前向传播中并不参与计算，就没有必要把它们全部塞进内存——按需从 SSD 读取即可。

Janas 正是把这个观察转化为工程实现：将专家权重存放在 SSD 上，推理时动态流式调入。内存只需容纳当前激活的专家和必要的运行时状态，模型总量则可以远超 RAM 上限。

混合专家（MoE）架构是一种将单个大模型拆分为多个"专家"子网络的稀疏激活设计。每个专家本质上是一组独立的参数（通常是前馈层中的 FFN 权重），而一个轻量的"路由器（router）"网络会根据输入 token 的特征，决定把它分配给哪几个专家处理。典型配置如 Mixtral 8x7B，每层有 8 个专家，但每个 token 只被路由到其中 2 个，因此单次激活参数量仅为总量的约三分之一（加上共享权重）。这种设计的好处是：用更少的计算量获得更大的参数容量，因为不同专家可以各自学习不同的知识领域或语言模式。代价则是训练难度更高、显存占用更复杂，且推理时需要处理多个专家的动态调度。正是这种"总量大、单次激活少"的特性，为 Janas 之类的流式加载方案提供了理论前提——闲置的专家参数完全可以从慢速存储中按需调入，而不必常驻内存。

为什么 MoE 特别适合流式加载

传统稠密模型（dense model）每次推理都要用到全部参数。这意味着无论怎么优化，完整权重都得驻留内存或显存，否则每一步计算都会触发磁盘读取，速度不可接受。

MoE 改变了这个前提。以典型的稀疏 MoE 为例，每个 token 只路由到少数几个专家，其余专家处于闲置状态。参数总量可能很大，但单次激活的参数量小得多。这种"总量大、激活少"的特性，天然适合把冷数据放在慢速但容量大的存储介质上。

Janas 的工程价值正在于此：它把"用得上"和"存得下"解耦。SSD 负责存得下，内存负责用得上，中间通过流式调度衔接。对于拥有大容量 NVMe SSD 但内存有限的用户，这条路让原本跑不动的模型变得可以运行。

流式加载的代价与权衡

从 SSD 流式读取专家并非没有成本。SSD 的顺序读取带宽远高于随机读取，而专家调度往往呈现一定的随机性——不同 token 可能命中不同专家，导致读取模式碎片化。因此实际性能高度依赖几个因素：

• SSD 的随机读取能力：NVMe 相比 SATA 有明显优势
• 专家命中模式：路由是否集中、是否有缓存复用
• 预取策略：能否提前判断下一步需要哪些专家
• 内存缓存大小：能缓存多少专家以减少重复读取

这些权衡决定了 Janas 更适合"能跑起来"而非"跑得快"的场景。对于内存严重不足、但又想尝试大模型的研究者和爱好者，这种取舍是合理的。

SSD 的顺序读取与随机读取在性能上有显著差异。NVMe SSD 的连续顺序读取带宽通常可达 3–7 GB/s，而 4KB 粒度的随机读取 IOPS 虽高（高端盘可达百万级），但单次延迟仍在微秒量级，且当读取模式碎片化时，有效吞吐会大幅下降。SATA SSD 受限于 6 Gbps 接口，顺序带宽仅约 550 MB/s，随机性能差距更明显。流式加载 MoE 专家时，每个 token 可能命中不同专家，导致权重读取呈随机模式——如果专家权重块较大（一个专家可能有数百 MB），读取粒度可接近顺序，性能损失相对可控；但如果调度极碎片化，实际有效带宽可能只有顺序读取的几分之一。这也是为什么 Janas 类方案对 NVMe 有强依赖：SATA 盘上随机读取延迟过高，流式加载的推理速度会跌到不可用的程度。预取策略和专家缓存正是为了缓解这种随机性——通过预测下一步激活的专家并提前读入，把随机访问转化为可控的异步顺序读取。

对本地部署格局的意义

Janas 代表了一类值得关注的工程方向：用存储换内存。在内存和显存价格高企的背景下，把大容量 SSD 作为模型参数的"二级存储"，为本地运行超大模型提供了另一条路径。

它与量化、蒸馏、KV Cache 优化等技术并不冲突，反而可以叠加使用。量化缩小单个专家的体积，流式加载解决总量问题，两者结合能进一步降低硬件门槛。

当然，这一方向也有明显边界。SSD 寿命、读取延迟、吞吐上限都是物理约束，流式加载无法让推理速度接近全内存方案。它解决的是"能不能运行"，而不是"运行得多快"。

小结

Janas 的思路并不复杂，但切中了一个真实痛点：模型增长的速度超过了硬件内存的增长速度。通过把 MoE 的稀疏激活特性与 SSD 的大容量结合，它让超出内存的模型有了运行的可能。

对于关注本地大模型部署、MoE 推理优化的开发者，这个项目提供了一个值得研究的样本。它的价值不在于性能数字，而在于展示了一条被忽视的工程路径——当内存不够时，硬盘可以是答案的一部分。