Serving 35B MoEs from SSD with Trained Routing Prediction（预路由让 35B MoE 从 SSD 流式推理）

📅 2026-09-20 | 🏷️ 模型发布 & 行业动态 | ⭐ 模型 ⭐3487 / 下载 6.8 万（上架 11 天）；配套论文 HF upvotes 10
🔗 原文（论文）：https://huggingface.co/papers/2609.18063
🔗 模型：https://huggingface.co/Edge0/Edge0-35B-A3B-preview

是什么

Edge0 团队同时发布一个 35B 级 MoE 模型（Edge0-35B-A3B-preview）和一套流式推理引擎方案：35B 模型 4-bit 量化后约 19.5GB，权重不装进显存而是放在 SSD 上，靠一个"预路由器"（prerouter）逐层提前一个 token 预测下一层会用哪些专家，把 SSD 读取时间藏到计算背后——让消费级硬件（普通内存 + 大 SSD）跑得动大 MoE。

🔍 小白解读

先说几个词

• MoE（混合专家）：把一个大模型拆成许多"专科医生"，每个 token 只激活其中两三位，能力大而单次计算省。
• 量化（4-bit）：把模型参数从高精度压缩成 4 位存储，体积和显存需求大幅缩水，像把无损音乐压成高音质 MP3。
• KV 缓存：模型生成时保存的上下文中间状态，长会话下它是显存大户。
• SSD 卸载：模型权重放固态硬盘上，用到哪块读哪块，用存储换内存。
• 预路由（prerouter）：提前猜"下一层会用到哪些专家"的小模型，猜中就能提前把权重从硬盘读出来，病人到诊室时医生已就位。
• 内存墙：计算速度远超数据搬运速度的瓶颈，算得快不如搬得快。

这篇到底在说什么

打个比方：大 MoE 模型像一家有几百位专科医生的医院，每个病人只看两三位医生，但医院发愁的是"养不起整栋楼的医生"——显存装不下 19.5GB 的家当。Edge0 的办法是：把医生名册放进仓库（SSD），前台安排一个会看手相的接待员，提前猜下一位病人要看哪科，提前把医生请到诊室——猜得足够准，病人就感觉不到等待。论文给出了几个硬核工程事实：35B@4bit=19.5GB；第 N+1 层的专家必须在第 N 层输出之前就选好，所以朴素卸载根本来不及提前读；预路由器的预测结果直接当作路由本身来消费。模型 9 月 8 日上架，11 天拿下 3487 likes、6.8 万下载，社区用脚投票的热度很高。

这跟普通人有什么关系

家里那台带大容量 SSD 的普通电脑，能跑的模型上限又提高了一截。对小公司意味着私有化部署的硬件门槛继续下降——不一定非要租昂贵的 GPU 服务器，才能用上 35B 级的模型。

为什么值得架构师关注

• 采购策略：私有化部署的硬件曲线可能从"堆显存"转向"中档显存 + 高速 NVMe SSD"，硬件预算结构可提前调整。
• 选型：A3B 激活量的 35B MoE 定位中端吞吐场景；是否替换现有推理服务，需自测吞吐、首 token 延迟与并发下的表现。
• 新运维维度：SSD 读写放大与寿命消耗成为容量规划的一部分，预路由失效时的延迟长尾必须压测。
• 成本对标：把"本地 SSD 方案的 TCO"与"持续租 GPU"画在同一条时间轴上找拐点。

核心内容

• 模型：Edge0/Edge0-35B-A3B-preview，2026-09-08 上架，text-generation，11 天 ⭐3487 / 68,403 下载。
• 关键工程数字：35B 级模型 4-bit 后 19.5GB；稀疏化降低的是每 token 计算量，不是必须持有的字节数。
• 核心创新：prerouter 逐层提前一个 token 预测下一层路由，且预测结果直接作为路由消费，从而让 SSD 读取提前启动、藏在计算后面。
• 配套论文 "The Other Half of the Memory Wall"（HF upvotes 10）公开了方法细节。

行动建议

有私有化/本地化需求的团队：搭建测试环境实测吞吐与长尾延迟，重点压测 SSD IO 抖动场景；同时关注社区量化版本与主流推理引擎的兼容进度。纯云端团队了解即可。