Janas: Run LLMs larger than RAM by streaming experts from SSD（Janas：用 SSD 流式加载专家参数，跑超过内存的大模型）

📅 2026-10-12 | 🏷️ 工程 & Agent | ⭐ HN 214分/85评论（GitHub 开源）
🔗 原文：https://github.com/prabanta-dev/janas
💬 讨论：https://news.ycombinator.com/item?id=50063717

是什么

Janas 是一个开源推理项目，核心思路：混合专家（MoE）模型每次推理只激活一小部分"专家"参数，于是不必把整个模型装进内存——把放不下的专家权重放在 SSD 上，用到谁再临时读谁，从而在内存远小于模型体积的设备上运行大模型。HN 214 分、85 条评论。

🔍 小白解读

先说几个词

• MoE（混合专家）：一种模型结构，内部有多个"专家"子网络，每次推理只挑最相关的几个干活。打个比方：公司有 100 个顾问，但每个问题只需要 2 个最对口的出马。
• 专家参数流式加载：被选中的专家才从硬盘读入内存，用完可以换出。类比：图书馆书架放不下所有书，用到哪本借哪本。
• 内存墙：模型参数量增长远快于内存容量/带宽增长，导致"模型放不进内存"的困境。
• SSD 读取带宽：现代 NVMe 固态硬盘每秒能读几个 GB，虽然远慢于内存，但如果每次只读一小部分专家，就够用。
• 冷启动/预取：提前猜测会用到哪些专家、提前读取，用来掩盖硬盘延迟——流式方案成败的关键优化。

这篇到底在说什么

现在开源大模型动辄几百 GB，家用电脑几十 GB 内存根本放不下。但新一代主流开源模型很多是 MoE 结构，每次推理真正参与计算的参数只是一小部分。Janas 抓住这一点：模型权重大部分时间躺在 SSD 里，推理时只把当次需要的专家读进内存。打个比方，你不需要把整座图书馆搬回家，只需要每次把要查的几本书借出来。这样，一台普通配置的电脑也有机会跑"参数量远超内存"的大模型。代价是速度取决于硬盘快慢和"猜专家"猜得准不准——猜错了就得临时去硬盘取货，响应变慢。HN 上 214 分、85 条评论，讨论集中在实际吞吐、对 PCIe 带宽的依赖，以及与既有 offloading 方案的对比。这类思路此前在社区有多个探索（如各类 expert offloading 实现），Janas 的价值在于把它做成了较完整的可运行项目。

这跟普通人有什么关系

如果你想在本地/私有环境跑大模型但预算买不起大内存工作站，这类工具让"高配 SSD + 普通内存"成为一种可行配置。对小公司，这意味着数据不出门的私有化部署门槛又降了一截。

为什么值得架构师关注

• 推理成本三要素重排：传统选型是"显存 > 内存 > 磁盘"，MoE 流式方案把高速 SSD 提升为一等公民，采购和容量规划公式要改——大容量 NVMe 的性价比可能远超加内存。
• 私有化部署新选项：对数据敏感、无法上云的中小场景（医院、律所、工厂内网），"能跑起来"比"跑得最快"更重要，这类方案显著降低准入门槛。
• 性能预算意识：流式方案的延迟方差大（命中/未命中差异明显），不适合对首 token 延迟敏感的在线业务，更适合批处理、Agent 后台任务等异步场景。
• 评测要点：如果试用，重点测专家命中率、长上下文下的吞吐衰减、并发多请求时的 SSD 争抢。

核心内容

• 开源仓库 prabanta-dev/janas：利用 MoE 稀疏激活特性，把超出内存容量的专家权重常驻 SSD、按需流式读取。
• 效果定位：在内存显著小于模型体积的设备上运行大模型，把"内存墙"问题转化为"存储带宽与预取策略"问题。
• HN 214 分 / 85 条评论，为近 48h 工程类高热讨论，社区关注点包括实际 tokens/s、NVMe 型号差异、与 llama.cpp 等 offloading 路线的对比。
• 属于"以存储换内存"的降本路线，硬件门槛从"堆内存"转向"堆高速 SSD"。

行动建议

• 对私有化部署需求，用你们的真实负载（上下文长度、并发、qps）压测 Janas，记录首 token 延迟分布和专家命中情况，再决定是否进入选型清单。
• 硬件规划：若走此路线，优先投资 PCIe 4.0/5.0 大容量 NVMe，而非盲目加内存。
• 在线低延迟业务慎用；批处理、夜间跑批等异步场景值得一试。