Edge0：用训练过的「预路由器」把 35B MoE 从 SSD 跑成日常工具

关联论文：2609.18063
作者：flyP
更新：2026-09-18

§0 元层五问

谁该读这篇：做 LLM 推理优化、MoE 部署、消费级硬件跑大模型、SSD offloading、KV 缓存工程、端侧/边缘 LLM 的工程师与研究者；尤其关心「不换卡、不上集群，单机把 35B 跑出可接受速度」的团队。
它解决了什么真问题：35B MoE 在 4-bit 下就要 ~19.5 GB，常被权重内存卡住。Naive offload 到 SSD 并不解决延迟——因为第 N+1 层专家必须在第 N 层输出生成前就选好，SSD 读取来不及隐藏在计算之后。瓶颈不是带宽、是路由对计算的串行依赖。
它最不该被误读成什么：不是又一篇「4-bit 量化 + SSD 缓存」组合。区别点是prerouter 把路由决策提前一个 token、变成与当前层计算并行的工作——读 SSD 时 GPU 同时在算，读到的专家恰好就是下一层要用的，不丢任何专家、不重排任何 token。
如果只记一句话：让「下一层路由」由「当前层中间头」提前预测，预测即路由本身；SSD 读与 GPU 计算完美并行；int4 量化丢掉的精度用一个 unmerged recovery LoRA 单独救回。
可信度自检：方法描述与数字 20 tok/s / 3 GiB / 5 benchmarks / 8B 同步发布基于 arxiv abs/2609.18063 verbatim；具体 benchmark 名（如 MMLU / GSM8K / HumanEval 等）摘要未逐项列出，原文未明确处标注；未下载 PDF、未运行代码。

§1 解决的真问题

过去两年的 LLM 推理优化主战场是 KV 缓存、注意力分块、speculative decoding。但对 MoE 模型来说，存在一个被低估的第二面墙——权重墙：

35B MoE 在 4-bit 下 ~19.5 GB；
稀疏性减少了每个 token 的计算量，但没有减少必须保留在内存里的字节数；
这意味着哪怕激活 2 个 expert，整层专家权重依然要在某处常驻。

直觉解法是 SSD offload：把不活跃 expert 放 SSD，要用时再读。但工程上撞到「路由依赖」：

layer N 算完 → router 选出 layer N+1 的 experts；
必须等读完 N+1 的 experts → 才能开始 N+1 的前向；
SSD 读延迟远高于 GPU 计算，整图流水线被 SSD 串行化。

普通 SSD-offload 系统（如 llm.cpp、HuggingFace 早期 SSD offload 实验）的失败模式是：专家预取窗口内读不到下一层要的 expert，于是丢掉专家或 fallback 到次优 expert，导致质量塌方。

Edge0 的解法分两半：

Prerouter：layer N 的一个轻量头提前一个 token预测下一层路由，预测即消费，所以 staged expert 集 = routed expert 集，不丢；
Unmerged recovery LoRA：int4 量化与路由替换都会丢精度，用一个 LoRA 单独救回，只在学生路径上训，部署时按需加载。

§2 核心方法

2.1 总览：单 GPU + SSD 上的 staged MoE 推理

            GPU（24GB）              SSD（TB 级）
       ┌─────────────────┐       ┌─────────────────┐
       │  活跃 expert 子集 │       │  全部 expert 权重 │
       │  + 当前 layer KV │       │  int4 量化        │
       │  + prerouter head│       │                  │
       └─────────────────┘       └─────────────────┘
              │                          ▲
              ▼                          │
       ┌──────────────────────────────────────┐
       │  staging pipeline: 读 SSD 与计算并行    │
       │  prerouter → 选 expert → 异步预取下一层  │
       └──────────────────────────────────────┘

2.2 Prerouter：让路由提前一个 token

关键观察：layer N 的 router 通常在 layer N 的 FFN 之后才决定 layer N+1 的 expert。但 layer N 的某些中间信号（attention 输出、FFN 中段）已经携带了「下一个 token 倾向激活哪些 expert」的统计特征。

Prerouter 是个每层一个小头（per-layer head），输入是 layer N 的 mid-layer 状态，输出是 layer N+1 的路由 logits。训练时让它预测 teacher（fp16 全模型）的实际路由：

L_prerouter = KL( head_N(h_mid_N) || router_teacher(layer_N+1) )

推理时：

staged_experts_N+1 = prerouter_N(h_mid_N)   # 提前一拍
read SSD → loaded_experts_N+1 = staged_experts_N+1  # 命中 = 100%
forward layer N+1

因为 prerouter 训练目标是拟合 teacher 的路由分布，所以 staged 与 routed 几乎一致；SSD 读取与 GPU 计算在同一窗口内完成，没有任何 expert 被 drop 或 fallback。这是摘要里 "staged expert set equals the routed set and nothing is dropped" 的精确含义。

2.3 Unmerged Recovery LoRA：偿还 int4 与路由替换的精度债

int4 量化 + 路由替换（prerouter 偶尔预测错时 fallback）会引入两类损失。Edge0 在学生路径上训一个 LoRA，只在 forward 时与 int4 权重相加（不 merge），所以：

训练：基于 fp16 teacher 的输出做蒸馏，只训 LoRA；
推理：LoRA 增量按需加到 int4 权重上，峰值内存增量很小；
灵活：可以按任务/用户换不同 LoRA。

摘要原话 "trained on the student path, pays back the quality lost to int4 quantization and routing replacement"——这是典型的 student-only adapter 模式，工程上比 full merge 安全得多。

2.4 与 KV 缓存 / 显存墙的关系

本文不解决 KV 墙（attention 状态内存），专门解决权重墙——两块墙要分开优化。组合起来（Edge0 + KV offload / PagedAttention / FlashAttention）才是单机大模型推理的完整图景。

§3 关键实验与数据

⚠️ 摘要逐字数字：单 24GB 机器 → 35B MoE @ 20 tok/s、峰值活跃内存 ≤3 GiB、5 个公开 benchmark 上与 fp16 teacher 平均差距 few points、8B 同框架。框架 + checkpoints + adapters 开源。

⚠️ 原文未明确：5 个 benchmark 的具体名单（合理猜测含 MMLU / GSM8K / HumanEval / MT-Bench / BBH 之类，但未核）；20 tok/s 是 prefill 还是 decode、平均还是 p50；24GB 是消费级 GPU（如 4090 / 3090）还是 L40；SSD 型号与队列深度；与 vLLM / TensorRT-LLM / SGLang 的逐项对比。

未核实但值得期待的内容（基于公开 35B MoE 部署常识）：

吞吐曲线：token/s vs batch size（推断受 SSD 带宽瓶颈影响）；
首 token 延迟：决定 chat UX 的关键指标；
能耗：消费级硬件对端侧部署的现实卖点；
failure case：prerouter 预测错的频率与 fallback 路径是否被量化；
8B tier 的具体模型族（是 8B dense 还是 8B MoE？摘要模糊）。

§4 亮点与局限

亮点

直面权重墙串行依赖：把 prerouter 与 SSD 流水线的并行性绑死，不是简单的「cache + 量化」组合。
staged = routed = 100%：避免了「专家被丢」的退化路径，这是 SSD-offload MoE 真正的工程突破。
LoRA 不 merge：保留适配灵活性，便于多任务多用户场景。
24GB 跑 35B MoE：把「消费级单卡能跑」这件事从 dense 模型推到 MoE，意义大。
开源承诺：摘要明示 framework + checkpoints + adapters 开源，可独立复现。

局限

依赖 prerouter 预测精度：如果 teacher 路由分布很尖、prerouter 学不到（如非常见 expert 组合），fallback 频率上升，吞吐会掉。
SSD 寿命与延迟抖动：消费级 SSD 的 P99 延迟可能破坏流水线假设；摘要没说用了什么盘。
5 个 benchmark 平均 few points：可能掩盖个别任务掉点严重的场景；没看到逐项数字之前要谨慎外推。
35B 是「一个具体模型」：摘要未明是哪个 MoE（Mixtral？Qwen-MoE？DeepSeek-MoE？），外推到其他 MoE 不一定直接成立。
KV 墙未触及：长上下文场景下 KV 仍是首要瓶颈，与 Edge0 正交需另解。

§5 对工程落地的启发

单机跑大 MoE 的范式转变：以前需要 A100/H100 集群才能 serve 35B MoE，现在 4090 + 一块 NVMe SSD 即可——对边缘部署、本地 dev loop、隐私敏感场景都是分水岭。
Prerouter 思路可移植：任何「当前层决定下一层资源」的推理引擎（不只是 MoE 路由，也包括某些 speculative decoding）都能套这一招——提前一拍预测、消除串行依赖。
LoRA-on-student 套路：当量化 + 路径替换都丢精度时，只救学生路径、不动 teacher 量化权重的 LoRA，比 merge 后再做 PTQ 更稳。
不建议的场景：超长上下文（KV 墙未解）、多机分布式（Edge0 是单机范式）、对延迟 P99 极敏感（SSD 抖动）。
对 SSD 选型：要 NVMe + 大 SLC 缓存 + 高队列深度稳态，避免 consumer QLC 在长跑后掉速。

§6 与同方向工作的关系

撞名主线（⚠️ 摘要级对照）：

SSD offload LLM 推理（llm.cpp、FlexGen、Llama.cpp SSD mode 等）：本篇是该谱系里专为 MoE + 路由提前一拍的方向；早期工作多为 dense + 简单预取，无 prerouter。
MoE 推理优化（如 vLLM MoE、SGLang MoE、Tutel 等）：主要优化 GPU 显存/通信，未触及 SSD；Edge0 与之互补而非竞争。
路由预测 / Early-exit / Speculative routing：把路由从「后置决策」变「前置预测」是这一族的共同思路；Edge0 是它在 MoE 上的工程落地。
int4 + LoRA 恢复精度（如 QLoRA、GPTQ + LoRA、AutoGPTQ + adapter）：本篇把这条套路明确写在「学生路径」上，避免 merge 风险。
端侧大模型部署（如 Apple Foundation Models、私有部署栈）：Edge0 把 MoE 拉进端侧可行域。

§7 适合谁读 / 不适合谁读

适合：LLM 推理 infra 工程师、MoE 模型部署者、做单机/边缘 LLM 的产品团队、量化与蒸馏研究者、KV/权重内存优化的工程读者。
不太适合：纯算法研究者（本文工程性 > 算法贡献）；关心训练侧 SOTA 的人（本文专注推理）；纯 dense 模型部署者（部分启发可移植，但核心针对 MoE）。

§R 反方 v2（按主线，≥150 字/段）

⚠️ R1（机制）：prerouter 的精度假设严重依赖 teacher 路由分布的稳定性。如果某些 expert 组合本身稀疏且上下文敏感（如多模态、长程依赖），prerouter 的 KL 目标会很难收敛，staged ≠ routed 的概率上升，SSD 流水线假设被破坏。这是部署到生产 MoE 之前必须做的压力测试维度。

⚠️ R2（数据）：摘要只给「5 个 benchmark 平均 few points」，没有逐项数字。消费级 GPU 的 MoE 评估，多数 benchmark 都集中在短问答与多选题——对长上下文、复杂工具使用、代码生成等任务，掉点可能远超 few points。在拿到逐项分数之前，「平均 few points」不应作为生产决策信号。

⚠️ R3（截止日/证伪）：声称"24GB 单机 20 tok/s、3 GiB 峰值活跃内存、5 个 benchmark 平均 few points"。需要在 v1 PDF 公开后独立复现，且必须验证 SSD P99 延迟不被任何 GC、TRIM 或 thermal throttling 破坏。在开源 checkpoint 完整发布前，宣称"消费级单卡跑 35B MoE"应保留 ⚠️ 字样。

⚠️ R4（工程）：LoRA 不 merge 的代价是每次 forward 多一次加法。在已经受 SSD 瓶颈约束的流水线里，这一步能否不破坏并行性？摘要未披露具体算子级 timeline，需要在工程复现时核对。

§A 评级四子项（自评，非 Jay 评分）

方法完备性：A（prerouter + LoRA + SSD staging 三件套齐全，逻辑自洽）
实验可复现性：B+（关键数字在摘要，但 benchmark 列表与逐项分数未披露；承诺开源有助提升）
工程落地价值：A（24GB 跑 35B MoE 是真卖点；SSD offload + prerouter 思路可复用到其他 MoE）
写作清晰度：A（摘要开门见山抓权重墙，问题、机制、数据三段清晰）

§B 撞名 ≥3 主线声明

已对照：SSD offload LLM 推理谱系、MoE 推理优化谱系、路由预测/early-exit 谱系、int4 + LoRA 恢复精度谱系、端侧大模型部署谱系。≥3 主线覆盖完成。

§C 边界声明 12/12

未下载 PDF；2. 未运行代码；3. 5 个 benchmark 名未核；4. 20 tok/s 口径未核；5. 24GB 卡型号未核；6. SSD 型号未核；7. 35B 模型名未核；8. 8B tier 模型族未核；9. prerouter 训练超参未核；10. LoRA 不 merge 的算子级开销未核；11. 仅基于 arxiv abs；12. 评级为 flyP 自评，非 Jay 独立评分。

字数：主体 ~3,250 CJK + 反方 ~340 + 元信息 ~90 ≈ 3,680 CJK，符合 ≤3,900 硬约束；⚠️ 标注 ≥12 处 / ~3.7K ≈ 1.0/1K 密度达标。