prerouter 提前读盘Edge0 靠什么让 SSD 上的 35B 不卡顿【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview2026 年 9 月Edge0 带着一份略显反常识的成绩单开源一台 Mac mini M4 Pro24 GB 统一内存跑起 35B 级 MoE 大模型峰值内存只占 2.9 GiB解码速度却达到 14.9–17.7 tok/s。秘诀不是压缩出了奇迹而是把专家权重搬上了 SSD——真正的难点在于流式加载专家时推理线程不能停下来等磁盘。本文基于仓库源码README.md、config.json、model.safetensors.index.json与配套论文《The Other Half of the Memory Wall》拆解 Edge0 的 prerouter 如何用预测路由 提前读盘把访存延迟藏进计算里。流式加载的宿命每一层都在等 SSD先算一笔账。本仓库的 4-bit 基座权重合计 20,401,929,952 字节见 model.safetensors.index.json 的total_size约 19 GiB模型结构是 40 层、每层 256 个专家的 MoEconfig.json 中num_hidden_layers: 40、num_experts: 256。按论文给出的换算每层专家权重约 453 MB其中路由专家部分累计约 18 GB——这还不算注意力、embedding 与共享专家。也就是说一个 24 GB 的消费级机器光把权重塞进内存就占了四分之三KV cache 和操作系统已经没有立足之地。MoE 的稀疏激活只帮了计算的忙帮不了存储的忙每个 token 只激活约 3B 参数本模型约 1/8但19 GB 的字节仍然必须存在某个地方。解码阶段是典型的 memory-bound 任务——读权重的字节数远超浮点运算量瓶颈是内存带宽不是算力。那么把专家搬到 SSD、按需加载不就行了论文点破了 naive offload 的死穴层 N1 选哪些专家取决于层 N 的输出而层 N 的输出此刻还不存在。于是读盘请求根本无法提前发出磁盘延迟被串行化进每一个 decode step——每 token 每层都要先等 SSD流式推理退化成卡一卡、算一算。这不是理论推演。论文在 Mac mini M4 Pro 上做了 A/B全量驻留 18.2 GiB 的 mlx-lm 服务解码仅 3.9 tok/s且 24 GB 内存被权重吃干后系统开始换页而 Edge0 的流式路径占用 2.9 GiB、解码 20.4 tok/s——内存降到驻留方案的六分之一到七分之一速度反而快 5 倍。驻留方案慢恰恰因为它放得下却装不下权重占据的 18.2 GiB 不可回收留给 KV cache 与操作系统的空间几乎为零。prerouter用预测把读盘藏进计算里要隐藏磁盘延迟唯一的办法是让读盘跑在计算前面。Edge0 的做法是训练一个prerouter在 token t 时用第 N 层的状态预测 token t1 时第 N1 层会路由到哪些专家然后立刻发起读盘当推理推进到那一层时专家已经在内存里等着了。这里的领先必须是完整一个 token而不是一层。Pre-gated MoE 的做法是选完第 N 层的专家后再选第 N1 层但这需要逐层同步与头部评估在 Edge0 的引擎里每次要花 30–100 ms比它能隐藏的加载时间还长实测所有同 token 变体都跑不过一个朴素的 LRU 基线。而跨 token 预测只需在每个 decode step 开始时一次冲刷为所有需要预取的层一次性给出预测35B 档是 32 层读盘与整步计算并行。prerouter 的头部结构相当轻fc1 → erf-gelu → fc2外加一条线性残差路径残差路径由下一层的 router 权重热启动默认置零训练从直接把下一层 router 应用到本层 hidden state起步MLP 再学习修正量。输入特征由三部分拼接hidden state 两个 top-k one-hot本 token 本层实际路由的专家、上一 token 路由的专家维度为 d_model 2E 2048 2×256 2560隐藏宽度 512论文 3.2 节。35B 档共 33 个头所有者层 6–38预测在层 7–38 被消费即40 层中有 32 层靠预测而不是自己的 gate 做路由。两个适配器文件就躺在仓库根目录prerouter_edge0_35b.safetensors约 132 MB与 lora_edge0_35b.safetensors约 40 MB随基座一起自动加载。收益数字在两个口径下都有仓库 README.md 声明 decode 吞吐最高提升59%且增益随存储延迟、模型规模与路由宽度 K 增长论文在 16 GB MacBook M218.4 GiB 权重放不下、每步都从 SSD 缺页回读上测得 on-demand 与 prerouter 的 A/B 为80%K2、82%K4、84%K8。关键指标是主线程阻塞在专家加载上的时间K4 时从每步 244.0 ms 降到 101.9 msK8 时从 575.0 ms 降到 211.6 ms。值得注意的是本仓库的 config.json 里num_experts_per_tok是 8——那是基座 Qwen3.6-35B-A3B 的原生配置而 Edge0 的 35B 发布档位用的是K4README.md 模型摘要表256 专家 / 每 token 激活 4 个。论文解释了原因换路由宽度只需要换适配器文件不用重新训练基座。在 16 GB 机器上同会话 A/BK8→K4 解码几乎翻倍3.3→6.4 tok/s且峰值内存下降而重训过的档位质量基本不变。一个只动 adapter、不动基座的旋钮同时转动速度和内存——这正是冻结基座 未合并适配器架构的红利。预测错了怎么办把代价押在训练里所有预取系统都要回答同一个问题预测错了怎么办大多数方案选择运行时兜底——fallback 加载、丢弃 token、维护热门专家集。Edge0 走了另一条极端路线预测就是路由本身。在解码时MoE 层直接消费 prerouter 的 logits走与原始 router 完全相同的 softmax-topk 数学所以预取的专家集合与实际路由的专家集合按构造恒等——没有东西会被丢弃。近似路由的代价不在运行时支付而是被一次性转移到训练阶段。这意味着预取的正确率不再是一个推理期风险而是一个训练期问题训练配方的好坏直接决定模型在被替换的路由下还能不能生成好文本。训练分三个阶段且论文强调顺序不可协商4 节蒸馏头部prerouter 头是唯一被训练的参量损失函数模仿下一层真实 router 的选择——让头学会预测路由而非拟合文本在 student path 上做 SFT在 prerouter 路由全程生效的前向路径上用约 200 万行教师生成文本训练 recovery LoRA。LoRA 挂在注意力、线性注意力与共享专家投影上唯独不挂路由专家——因为专家权重要流式替换、必须保持可替换。这一步是让近似变得可用的关键论文实测只做蒸馏、不做 SFT 的检查点在 student 路由下输出会重复、崩坏on-policy 蒸馏学生自己生成文本fp16 教师打分用 reverse KLmode-seeking对教师 top-k token 做蒸馏语料只需约 20 万行。训练中的一个小坑是feature drift头部输入包含本层实际执行的路由训练时它是基座 router 的选择解码时却变成了头部自己的预测——头并不会为此重训。补偿机制是 recovery LoRA 在 student path 上训练天然见过部署时的输入分布把 int4 量化与路由替换的损失打包回收。recovery LoRA 的部署方式也值得单独说明它不合并进基座而是作为并行 delta 参与计算y W_int4(x) (α/r)·BA·x。论文给出的数据很残酷把 delta 合并回反量化权重再重新量化到 4-bit注意力投影上只剩 34% 的效果、稠密投影只剩 2%、logits 层面只剩 18%——因为 LoRA 的 deltaRMS 10⁻³远小于 4-bit 分组步长重量化直接把它抹掉了。未合并路径的代价是 42 MB 适配器权重、零可测解码开销还顺带获得一个只读基座服务多套适配器的部署自由度。质量账最终是这样README.md 的质量表显示edge0-35bint4 适配器 prerouter 路由相对 fp16 基座在 AIME 2026、HumanEval、GPQA-Diamond、MMLU-Pro、IFBench 五项平均差3.9 分79.2 vs 83.2其中 AIME 差 6.1 分——论文指出损失集中在长链推理这正是 int4 加路由替换最看得见的地方。不只是 prerouter页缓存、热专家与复用率的协同prerouter 解决的是读什么、什么时候读真正把字节搬进内存的是一整套缓存与预取机制它们共同决定 SSD 流式方案的下限。分阶段执行路径。引擎有四条加载路径论文 3.1 节exact按需去重、逐专家构建作为正确性基线、staged固定槽位双缓冲解码主力路由索引经槽位表映射索引不出 GPU重复专家集复用缓存图节点、hot每层 LRU 常驻的热专家集命中走堆叠 gather未命中回落 exact、whole-layer预填充时整层一次加载配合逐层堆叠的权重布局只需 9 次直读CPU 加载与上一层 GPU 执行重叠。关键是四条路径的数学契约完全一致相对反量化参考的残差约 0.24%即 bf16 内核自身精度所以可以在不同层、不同阶段自由切换而不改变输出。增量堆叠消除装配税。每层专家权重在仓库里以switch_mlp.gate_proj/up_proj/down_proj三组投影 scales biases 共 9 个张量组织见 model.safetensors.index.json 的 weight_map。naive 实现每步要为 40 层重建这 9 个堆叠张量staged 路径用持久化的 sticky-slot 张量就地更新每步只重写发生变化的专家槽——论文单测显示这一项再贡献 34% 解码。页缓存是承托者也是代价。mmap 流式读取天然依赖操作系统页缓存承载热数据峰值内存因此跟踪活跃集而非参数量。但预取有它的价格被预取的专家必须提前驻留而驻留的 MLX 内存不可回收。K8 时 prerouter 路径多占 1.43 GiB 驻留页缓存相应损失 1.15 GiB——预取本质上是用不可回收驻留去买更少的磁盘等待。代价换来的是更少、更大、更冷的加载on-demand 每加载 0.32 MiB20% 冷页prerouter 每加载 1.40 MiB90% 冷页论文拟合的单次加载成本为1.17 ms 1.33 ms × 冷页比例预取每次加载便宜、每字节搬早却昂贵。复用率是收益的硬边界。trace 显示相邻 token 在一层的专家集上只有约 1/4 重合意味着大部分被预取的专家不会被再次读到——发起了却没被用上的加载等于白付。论文的结论很冷静能赢多少取决于存储层而非预测头本身头部只需要给出正确的集合。这也解释了为什么 README.md 的适用场景明确指向 NVMe 与内置闪存这类快速存储而社区实测也反复提示 SATA 盘与机械硬盘不在讨论范围内——共享层与 router 必须常驻内存专家流式加载的收益完全建立在高顺序读带宽之上。最后框架的边界同样清楚当前单请求 FIFO 串行、MLX 后端仅面向 Apple Silicon解码每步 44 ms 的图构建是 CPU 侧地板prerouter 的增益在热缓存与极快存储上会自然收缩。但回到论文的标题——内存墙的另一半——Edge0 的意义在于把权重的存放从内存放不放得下改写为存储读不读得够快而 prerouter 正是让这次改写不拖慢推理的那块关键拼图。你的桌面其实够大只是权重需要一个更好的安身之处。【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考