Edge0 开源端侧推理框架：创始人称 35B 模型可在 iPhone 上以 1～2.5 GB 峰值内存运行

9 月 10 日，Edge0 创始人 Samuel Zeng（）在 X 上宣布开源端侧推理框架 Edge0，并称「一个 35B 语言模型在 iPhone 上运行，峰值内存只用 1～2.5 GB」，不需要云端、远程服务器或桌面 GPU（）。截至北京时间当天晚间，这条推文的浏览量约 29 万，点赞超过 5,600，转发 450 多次。

与推文同时落地的，还有可以直接检查的代码与权重：和 Hugging Face 上的、两个模型页当天都能打开、下载，采用 Apache-2.0 许可。但速度、内存和质量数据目前都是团队自测口径。

开源包里有什么：两组模型、运行时和打包好的适配器

Edge0 的 GitHub 仓库创建于 9 月 8 日，两天后随推文正式公开。按，首个版本包含 35B 与 8B 两组模型，以及可在本地运行的运行时和推理代码；官方说法是面向「手机、笔记本、PC 和机器人」。

两组模型打包方式相同：基础权重、训练好的 LoRA（低秩适配）适配器、预路由器（prerouter）适配器放在同一个目录里，加载时自动组合，edge0 serve 能起一个 OpenAI 兼容的 /v1/chat/completions 接口。35B 版基于 Qwen3.5-MoE 35B-A3B，4-bit 量化，40 层、256 个专家，每个 token 路由到其中 4 个；8B 版基于 Ling 3.0 tiny，24 层、128 个专家（每个 token 路由 8 个），约 7.9B 总参数、约 1.2B 激活。两边的 4-bit 权重分别约 23 GB 和 4.2 GB，专家权重用内存映射方式按需读取，不预先整包载入。

团队 9 月 7 日预告了这次发布：「9 月 10 日将做一个重大开源发布：Edge0」。此前他们还开源过 Audio8 语音系列模型（）。

内存账怎么算：权重留在闪存，专家按需流进内存

创始人的解释可以拆成四步：完整模型留在存储里；只有当前步骤需要的参数进内存；下一步参数在当前步骤运行时就开始准备；内存被复用，不必一次性载入整个模型（）。

落到实现上有三个部件。一个是「SSD 专家卸载」：MoE（混合专家）的专家权重放在 SSD 上做内存映射、按需流式读取，热专家留在内存缓存里，长尾专家逐层预取。另一个是预路由器：用训练好的头预测下一个 token 要用哪些专家，把 SSD 读取和当前一轮前向计算重叠起来；仓库称这最多能提高 59% 的解码吞吐，存储延迟越高、模型越大、路由宽度 K 越大，收益越明显。还有一个是 Recover-LoRA：int4 基础权重冻结不动，用 fp 教师模型蒸馏训练 LoRA 适配器，把量化损失尽量找回来；适配器不合并进基础模型，一份只读权重可以服务多组适配器。

README 把原理概括成一句话：峰值内存取决于「活跃集」，而不是参数总量。代价也写在同一份文档里：这套做法要求存储够快（NVMe 或内置闪存），长上下文还要额外占 KV cache（键值缓存）。

数字对照：四份官方材料里的内存口径

同一个项目，四份官方材料给出的内存数字并不完全一样。推文说的是 1～2.5 GB（iPhone）；35B 模型卡的标题栏写「3 GiB 活跃内存 · 15 tok/s · 4-bit」，正文写「3 GiB 以内的活跃内存」；仓库 README 的实测表写 2.9 GiB；给 Edge0-35B 的口径是「1～3 GB 内存」。

四份材料里，仓库那张表把测试机、方法和复现命令都写上了：测试机是 Mac mini M4 Pro（24 GB），方法是用 examples/bench.py 先跑 3,300 token 的预填充（prefill），再做 10 步预热、200 步计时的解码，每组跑两遍。结果是 35B 版解码 14.9～17.7 token/秒，预填充冷启动 113、热启动 140 token/秒，峰值活跃内存 2.9 GiB；8B 版解码 23.9～25.3 token/秒，峰值 1.0 GiB。模型卡还标注，长上下文会额外推高 KV cache，8B 版在 3,300 token 时约 3.3 GiB。

质量与边界：比 fp16 低 3.9 分，平台暂限 Apple Silicon

质量数据同样出自团队自测：仓库写明，基准用 OpenCompass、在与 fp16 基础模型相同的设置下跑出；35B 版平均低 3.9 分，8B 版平均低 2.8 分，但 MMLU-Pro 一项高于基础模型（70.1 对 65.8）。

两份模型卡都标着「预览版」，并列出了同样的短板：尚未针对智能体任务优化，工具调用、多步规划和长程自主性目前偏弱，主要面向基础模型擅长的语种。平台方面，仓库写明 MLX 后端运行在 macOS + Apple Silicon（M1/M2/M3/M4）上，CUDA 后端列入了路线图，暂不支持其他平台；有用户据此追问 README 是不是该更新、该用哪一代 iPhone（）。

回应与质疑：32K 上下文、Android 测试与「我们试过这种做法」

在回复区，创始人补了两条边界信息：有人问上下文长度，他回复「32K 完全支持，内存占用几乎不变」（）；被问是否支持 Android 时，他说「目前只有 Metal 后端，我们已经在 Android 手机上测试了」（）。

质疑也很快出现。X 用户 Alexey Moiseenkov（@Darkolorin）引用这条推文写道：「问题是激活 3B 参数时只有 17 tok/s，而在 M4 Pro 上本应能到 200。我们试过这种做法，以目前的实现来说没有用。」（）他说的 17 tok/s，与仓库实测表里 14.9～17.7 token/秒的量级一致。

也有人把问题指向长时稳定性。X 用户 @itsvigneshv 说：「把权重从存储里流式读出、压在 2 GB 以下是诀窍。现在请展示跑十分钟之后的温度和每秒 token 数，因为端侧智能体恰恰是在那之后开始崩的。」（）

引用区里还出现了同类思路的项目：X 用户 Dong Wang 称，他的 Minirun 能在 iPhone 上用 2 GB 内存预算运行 284B 的 DeepSeek v4 Flash，2.8T 的 Kimi K3 峰值内存为 6 GB，并附上了自己的开源项目地址（）。

想亲手复现这些数字的人，条件都写在仓库里：一台 M 系列芯片的 Mac、约 23 GB 磁盘空间（35B 权重）和 Python 3.10+，以及一个可以照着跑的基准脚本。推文里那组内存数字对应 iPhone，而仓库实测的对照设备是 Mac mini，两组记录暂时无法直接比较。