00
引言
本地运行大模型，通常绕不开一个硬约束：参数越多，内存需求越高。
MoE，也就是 Mixture of Experts，可以让模型每次只激活少量专家，从而降低计算量。但这并没有自动解决内存问题——没有参与当前计算的专家权重，仍然需要存放在某个地方。
Edge0 给出了一种颇有工程味的答案：把完整专家权重留在 SSD，需要时再流式载入；同时训练一个 Prerouter，提前猜出下一步会用到哪些专家，让读取与计算尽量重叠。
项目给出的醒目数字是：35B 级模型在短上下文测试中，MLX 分配器的峰值活跃内存约为 2.9 GiB。本文来探讨该技术背后的技术原理。
01
Edge0 到底是什么
Edge0 是一个 Apache-2.0 许可证下发布的开源流式 MoE 推理框架，目前提供两个模型档位：
|
|
|
|
|
|
|---|---|---|---|---|
| Edge0-35B-A3B | Qwen3.6-35B-A3B |
|
|
|
| Edge0-8B-A1B | Ling 3.0 |
|
|
|
官网Github: https://github.com/Edge0-AI/Edge0
这里的 A3B 可以理解为模型虽然拥有约 35B 总参数，但一次前向计算只激活其中一部分。稀疏激活降低了计算成本，而 Edge0 进一步把“非活跃权重如何存放”也纳入推理系统设计。
截至 2026 年 9 月，项目当前实现使用 MLX，面向 Apple Silicon 的 macOS。CUDA 后端仍在路线图中，因此它暂时不是一个覆盖 Windows、NVIDIA GPU、Android 和 iPhone 的通用推理方案。
02
第一招：SSD Expert Offloading
传统方案通常希望尽可能把模型权重放进内存或显存，因为计算单元等待存储读取会直接拖慢生成速度。
Edge0 反过来接受了一个现实：SSD 容量远大于内存，那就把完整专家权重映射在 SSD 上，只让当前路由选中的专家进入内存，并缓存最近使用的权重。
这样一来，内存保存的是 Working Set，也就是眼下真正参与计算的活跃集合，而不是模型的全部参数。
这解释了为什么 35B 总参数与 2.9 GiB 活跃内存可以同时成立。但代价也很直接：如果下一层需要的专家还没有读取完成，计算就必须等待 SSD。
所以，SSD 速度、文件缓存命中率、专家复用模式和系统内存压力都会影响最终吞吐。它不是凭空消除了成本，而是把资源瓶颈从“大内存常驻”改写成“存储、缓存与调度协同”。
03
第二招：Prerouter 提前预判专家
Prerouter 是 Edge0 用来隐藏 SSD 等待时间的关键组件。
普通 MoE 会先计算当前层的路由结果，然后才知道需要载入哪些专家。如果每层都遵循“计算路由—读取权重—继续计算”，存储访问会反复进入生成 Token 的关键路径。
Edge0 训练了一个轻量预测头，利用隐藏状态与路由特征，提前预测后续可能使用的专家。系统可以在当前前向计算尚未结束时，预取下一步的权重。
项目把这种机制描述为跨层、跨 Token 的 Dual Shift。其目标不是取代原生 Router，而是把原本发生在未来的等待尽量提前，并让加载、缓存和计算形成流水线。
Edge0 官方报告，在同一模型、适配器和负载下交替比较 Prerouter 与原生路由，解码速度最高提升 59%。这是项目方测试的最大值，并非所有设备和输入都能获得相同收益；实际效果取决于缓存命中、SSD 延迟、路由宽度和专家工作集。
04
第三招：Recover-LoRA 修复 4-bit 量化损失
让模型能跑只是第一步，压缩后的质量是否可用同样重要。
Edge0 使用 4-bit 权重降低存储和读取成本，同时冻结量化后的基础模型，用 FP Teacher 蒸馏训练 LoRA，尝试恢复量化造成的能力损失。项目将这套方法称为 Recover-LoRA。
LoRA 和 Prerouter 适配器以 Safetensors 文件与模型放在同一目录，启动时自动加载，并且不需要合并回基础权重。这样，一份只读基模理论上可以搭配多套适配器，而不用为每个版本重新量化整份模型。
这一设计的重点是：Edge0 发布的不是一个孤立 Checkpoint，而是“4-bit 基模 + LoRA + Prerouter + 流式运行时”的完整管线。
05
3GB、15 Token/s，应该怎样正确理解
项目在一台配备 24GB 统一内存的 Mac mini M4 Pro 上进行了性能测试。使用约 3.3K Token 的 Prompt，经过 10 步预热后，对 200 Token 解码区间计时，两个档位各运行两轮。
官方公布的结果为：
|
|
Edge0-35B | Edge0-8B |
|---|---|---|
|
|
|
|
| Prefill
|
|
|
| Prefill
|
|
|
|
|
|
|
这里至少要保留四个条件。
第一，2.9 GiB 是短上下文下 MLX Allocator 的峰值，不是 macOS 活动监视器中的整机进程占用。
第二，模型文件仍需约 23GB SSD 空间。
第三，热 Prefill 受操作系统 Page Cache 帮助，不能与第一次启动混为一谈。
第四，长上下文会让 KV Cache 继续增长。
模型质量同样来自项目方基于 OpenCompass 的自测。Edge0-35B 完整 Int4 管线在 AIME 2026、HumanEval、GPQA-Diamond、MMLU-Pro 和 IFBench 五项平均 79.2，FP16 基模为 83.2，平均差约 3.9 分。
这些数字说明方案具有潜力，但不是独立第三方基准。测试集平均分也无法替代你的真实业务评测，特别是中文能力、长上下文、工具调用和 Agent 任务。
06
五分钟跑起来：最短部署路径
当前要求是 Apple Silicon Mac、Python 3.10 以上，项目推荐 Python 3.12。MLX 版本也需要与仓库要求保持一致。
安装项目后，可以使用自带脚本下载模型：
# Python >= 3.10; the MLX backend requires macOS with Apple Siliconpython3.12 -m venv .venv && .venv/bin/pip install -e '.[dev,fetch]'
.venv/bin/python scripts/fetch_models.py --tier edge0-35b --target-dir models随后指向本地模型目录并启动对话：
# quick demoedge0 demo edge0-35b# serve (OpenAI-compatible /v1/chat/completions)edge0 serve edge0-35b
curl http://127.0.0.1:8000/v1/chat/completions \-H 'Content-Type: application/json' \-d '{"messages":[{"role":"user","content":"Hello!"}],"max_tokens":32}'# 5) One-shot chat (pass --max-new to cap length; add --show-thinking to# print the model's reasoning block too)edge0 chat edge0-35b --prompt "Explain streaming inference in one sentence."
服务默认提供 /v1/chat/completions 风格的本地接口。部署成功后，不要只看它能否回答问题；还应记录冷启动时间、首 Token 延迟、持续吞吐、SSD 读取、实际进程内存和长上下文增长。
07
它适合谁，又不适合谁
Edge0 最适合三类探索。
第一，Apple Silicon 上内存紧张、但内置 SSD 较快的本地推理。
第二，需要离线、隐私或低网络依赖的桌面应用。
第三，希望研究 MoE Expert Offloading、预测式预取和多适配器服务的开发团队。
它暂时不适合追求成熟跨平台部署的生产团队。当前模型和框架仍标注为 Preview，CUDA 尚未实现，Agent 工具调用、多步规划和长周期自治也被模型卡明确列为较弱能力。
08
写在最后
Edge0 最有意思的地方，不是制造了一个“35B 塞进 3GB”的魔术，而是重新安排了参数、内存、存储和时间之间的关系。
MoE 解决“每次算多少”，SSD Offloading 解决“非活跃权重放哪里”，Prerouter 解决“读取等待如何隐藏”，Recover-LoRA 则处理“4-bit 量化后质量如何尽量恢复”。四者合在一起，才构成这条端侧推理路径。
它距离通用生产方案仍有明显距离，但提出的问题非常现实：当内存不再足够容纳所有权重时，能否把存储也变成推理系统的一部分？
对开发者而言，最值得关注的不是官方报道里的 3GB，而是这种系统级思路。未来端侧模型的竞争，很可能不只是谁压缩得更小，还包括谁能把计算、缓存、路由和存储调度得更聪明。
添加个人微信，进专属粉丝群！
