3GB 内存跑 35B 模型技术突破还是营销话术【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview35B 参数、4-bit 量化、全量 checkpoint 约 19 GiB 的模型官方宣称峰值活动内存只要 2.9 GiB社区标题则直接写成3GB 内存跑 35B 模型。乍看之下这像是把参数总量和运行内存两个概念强行凑在了一起——毕竟按常识int4 权重也要约 19 GiB 才能全部驻留。但当 MoEMixture of Experts遇上专家按需流式加载这个数字确实可以成立。本文以 Edge0-35B-A3B 的仓库源码为证据结合社区实测情报逐层拆解3GB的构成、代价与边界它既不是纯营销话术也不是无条件的魔法而是一个条件苛刻、但工程上真实成立的技术突破。先对账35B 模型到底有多大3GB到底指什么要判断3GB 跑 35B是真是假第一步是搞清两边数字的口径。在仓库根目录的 model.safetensors.index.json 中元数据字段给出了 4-bit 量化后全部权重的精确体积metadata: { total_size: 20401929952 }约 20.4 GB19.0 GiB与社区实测旗舰版 edge0-35b 约 23GB 存储的说法量级吻合差异来自 LoRA 与 prerouter 适配器、分词器等附带文件。也就是说checkpoint 本体确确实实接近 19 GiB一份不缩水。那3GB从何而来README.md 的 Performance 表格写得很清楚解码速度Prefill 吞吐冷 / 热峰值活动内存*14.9–17.7 tok/s113 / 140 tok/s2.9 GiB并附注释*短上下文长上下文会额外增加 KV cache专家权重从 SSD 按需流式加载、不常驻内存。这里存在全文最关键的一个口径辨析3GB不是运行这个模型需要 3GB 内存而是短上下文条件下、SSD 流式架构的峰值活动内存。README 的 Limitations 部分也明确承认长上下文会让 KV cache 增长要把峰值压回 3 GiB 就得使用短上下文。换言之3GB 跑 35B的完整表述应该是3GB 内存 足够快的 SSD 短上下文——营销标题省略了后半截这正是争议的根源。数字拆解3GB 里住着什么19GB 留在了哪里要理解内存为什么能被压到 3 GiB需要回到 MoE 的稀疏激活特性。模型架构见 config.json的关键数字是40 层num_hidden_layers: 40每层 256 个专家num_experts: 256每 token 只激活 4 个num_experts_per_tok: 8README 标注 K4 激活MoE 中间维度仅 512moe_intermediate_size: 512每个 MLP 块包含switch_mlp可路由专家与shared_expert共享专家两部分我统计了 model.safetensors.index.json 中全部 1757 个张量 key 的归属类别张量数量是否常驻内存switch_mlp256 个可路由专家权重360❌ 按需流式加载shared_expert共享专家每层必算480✅ 常驻router_gate路由打分120✅ 常驻attention含 linear_attn / self_attn710✅ 常驻embed_tokens/lm_head6✅ 常驻其余norm 等81✅ 常驻这是整个方案的地基推理路径上每一层都必须经过的注意力、共享专家、路由门控、embedding 与输出头全部常驻唯独 256 个可路由专家可以用时再取。由于每 token 在每层只激活 K4 个专家解码时实际需要拉进内存的专家权重远小于总量——MoE 的稀疏激活特性天然让专家粒度 offload成为可能这也是 Edge0 区别于操作系统级 swap 的本质它做的是语义级专家粒度的调度而非页级盲换入换出。再叠加 4-bit 量化config.json中bits: 4、group size 64router gate 与 shared expert gate 提高到 8-bit 以保路由精度权重体积先被压缩数倍常驻集进一步缩小。两者相乘才把必须住进内存的那部分压到了 1–2 GiB 权重 KV cache 运行时的水平最终实测 2.9 GiB。所以严格说3GB是4-bit 量化 专家粒度过载 共享层常驻三件事叠加的结果前两件缺一不可。换 SSD 省内存的代价带宽敏感性与硬件要求内存省下来了代价转移到了存储带宽上。每解码一个 token都要从 SSD 拉取激活的专家权重40 层 × K4 意味着每 token 涉及 160 个专家块的读取含 shared_expert 常驻部分除外。解码速度的上限基本由SSD 带宽 ÷ 每 token 专家流量决定。这带来几个硬约束第一对存储介质极其挑剔。社区多篇实测文章的一致结论是方案对 NVMe SSD 性能高度敏感不适用于 SATA SSD 或机械硬盘——后者的顺序/随机读带宽不足以支撑 token 级实时拉取。所谓3GB 内存跑 35B的成立条件隐含了现代 NVMe 数百 MB/s 以上随机读这一前提而这在旧设备上并不默认存在。第二推理延迟被流式读取主导。如果专家权重在 forward pass 中才被发现要加载解码就会卡在读盘上。Edge0 的解法是 README.md 中披露的Prerouter用一个小型训练头预测下一步的路由选择让专家加载与当前步的前向计算重叠而非串行阻塞。官方口径该机制带来最高 59% 的解码吞吐提升且收益随存储延迟、模型规模与路由宽度 K 增大而放大——这正是在 SSD 延迟成为瓶颈的背景下把能跑升级成够快的关键工程细节。第三解码速度仍然显著低于常驻内存方案。官方在 M4 Pro 上的 14.9–17.7 tok/s属于可交互但远非流畅的水平社区在 iPhone 上的实测为 6.4 tok/s、峰值内存约 4 GB比桌面端高符合移动端 NVMe 带宽更弱的直觉。省内存是用吞吐换来的3 GiB 内存与 15 tok/s 是一对不能只取前者。与官方实测数据的对账3.9 分代价能跑之外人们更关心跑得怎么样。README 的 Quality 表格提供了官方用 OpenCompass 统一口径测得的 int4 流水线含 LoRA 与 prerouter相对 fp16 基座的差距Benchmarkedge0-35b (int4)Qwen3.6-35B-A3B (fp16)AIME 202686.692.7HumanEval90.995.1GPQA-Diamond79.881.8MMLU-Pro81.084.6IFBench57.961.7Average79.283.2平均损失 3.9 分AIME数学推理损失 6.1 分最大其余各榜损失在 2–4 分之间。这个数字由Recover-LoRA机制支撑int4 基座冻结用 FP 教师蒸馏训练 LoRA 适配器恢复 4-bit 量化损失的绝大部分。仓库中 lora_edge0_35b.safetensors 与 prerouter_edge0_35b.safetensors 与基座 checkpoint 同仓发布edge0启动时自动加载无需手工 merge——README 还指出适配器保持未合并状态一份只读基座可同时服务多套 LoRA这对单机多租微调是实打实的架构红利。把三组数据放到一起对账可以得出一个平衡的结论内存19 GiB checkpoint → 2.9 GiB 峰值活动内存官方与社区M4 Pro 2.9 GiB、8b 档 1.0 GiB、iPhone 约 4 GB交叉一致真实速度10–17.7 tok/s 桌面、6.4 tok/s 手机可交互但非实时真实质量相对 fp16 基座损失 3.9 分且社区验证仅降 3.9 分的说法与官方一致真实。结论真突破、伪命题还是条件成立回到标题的三选一证据指向条件成立的真突破但营销话术的包装需要拆穿。真突破的部分把 MoE 专家按需流式加载做成可用的推理系统本身需要解决两个硬问题——加载延迟用训练的路由预测 head 提前预取59% 吞吐和量化精度损失用蒸馏式 LoRA 恢复 3.9 分内。这两项都是仓库中真实存在、可验证的系统级创新并非 PPT 概念论文《The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction》也说明该工作已进入学术流程。对端侧生态而言它第一次让 35B 级 MoE 进入了手机级内存的射程且已经在 iOS / macOS / Android / Windows / Python 多平台被社区实测验证。话术的部分3GB 跑 35B省略了三个限定词——短上下文长上下文 KV cache 会把峰值推高、NVMe SSDSATA 与机械盘不适用、4-bit 专家 offload 的组合单靠其一都做不到。把峰值活动内存直接写作运行需要会让读者误以为这是无条件的颠覆。给读者的判据如果你手上有一台 8–16 GB 内存、内置 NVMe 的 Mac/PC/手机且场景是短上下文的对话、摘要、代码改写那么 Edge0-35B 是真实可用的——约 19 GiB 的模型文件躺在 SSD 上内存只需 3 GiB换来 10–17 tok/s 的本地推理隐私与离线是实打实的收益如果你的场景是长文档、长上下文或对吞吐有高要求或者存储还是老式 SATA/机械盘那么3GB这个数字对你并不成立。技术没有魔法只有把正确的约束条件写清楚之后依然成立的工程——Edge0 属于后者。【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
