Edge0 发布大参数本地模型，性能待复测

1450 亿参数的模型，能在一台笔记本上运行，厂商还报出了超过 80 tokens/s 的生成速度。Edge0-145B 想证明的是：通过稀疏专家、低比特训练和分层加载，大模型可以搬到个人电脑上。

但「29GB 峰值内存」不等于一台 32GB 笔记本就能跑。原文最值得读的是它如何搬运权重，以及宣传数字背后有哪些条件。先把结论放前面：这是值得关注的本地推理方案，性能目前仍是厂商自报，硬件和授权都需要细看。

145B 为什么不用同时装进显存

据原文，Edge0 在 2026 年 11 月 12 日发布了 Edge0-145B、较小的 Edge0-120B，以及推理框架和部署工具。两款模型衍生自 Qwen3.8-Flash-Next，采用原生 4-bit 训练，标称上下文为 256,000 tokens。

这里的关键是稀疏混合专家模型（MoE）。145B 是总参数量，每一步推理实际参与计算的约为 10B。模型共有 512 个专家，每个 token 激活其中 10 个；每组 64 个专家还共享两个大型矩阵，减少重复存储。

可以把专家理解为按需调用的计算模块。模型拥有很多模块，但处理一个 token 时，只让其中一小部分工作。总参数量决定了模型有多大，激活参数量则更接近单步计算要付出的成本。

不过，没参与计算的专家仍然需要存放，而且后续随时可能被调用。Edge0 因此把加载拆成三层：常用专家留在 GPU 内存，约 40GB 的专家库放在系统 RAM，约 48GB 的词表数据按需从 SSD 流入。CPU 和 GPU 并行计算，再用推测解码（speculative decoding）把读取权重的成本分摊到多个 token 上。

推测解码的大意是先提出一批候选 token，再批量验证，争取一次读取权重完成更多输出。它能否带来收益，要看候选的接受情况和具体实现，不能只看模型参数量。

这套方案的关键，是让每一步只计算、读取当前需要的部分。

原文还说，模型从训练阶段就面向端侧架构设计，因此比事后压缩云端模型更能保留能力。但它同时提到模型衍生自 Qwen3.8-Flash-Next，没有解释具体改造和训练过程。「保留能力」目前是厂商的解释，文章没有提供足够实验来单独验证这项归因。

29GB 和 80 tokens/s，要连着测试条件看

Edge0 给出的笔记本数据包括：29GB 峰值内存、超过 80 tokens/s 的解码速度、超过 1,100 tokens/s 的提示词处理速度，典型功耗约 120W；在 128K 至 256K 上下文下，长输入仍保持相近速度。

提示词处理也叫预填充（prefill），对应模型读入输入的阶段；解码（decode）对应后续逐 token 生成。对于编程助手，前者影响读完代码和开始回答的等待，后者影响回答持续输出的速度，两项都需要看。

但原文没有交代上述结果对应的完整硬件配置、测试负载，以及「相近速度」具体指哪个指标。另一个容易误读的点，是 29GB 与 40GB 专家库、48GB SSD 数据之间的关系。

这些数字的统计口径没有说清。尤其在统一内存机器上，GPU 与系统内存可能共享物理资源，不能直接把各项相加，也不能认定 29GB 已经覆盖全部需求。原文明确指向高内存、兼容的工作站级笔记本，例如高内存 MacBook Pro，还需要存放权重本身。

厂商另外报告，在配有 24GB 显存的 RTX 5090 D 上，Q3_K 格式的 agent 解码达到 121.2 tokens/s。这是另一套硬件条件下的数据，不能用来证明笔记本也能达到同样速度。

能力评测同样来自厂商选择的对照：

评测	Edge0 报告成绩	原文提供的参照
DeepSWE 1.1	64.6	Qwen3.8-Flash-Next 为 58.7
GPQA-Diamond	90.4	DeepSeek-V4-Flash-0731 为 90.8
Terminal-Bench 2.1	86.52	未给出直接对照
六项评测平均分	72.8	Qwen3.8-Flash-Next 为 71.7，估算占用 70GB

这些成绩能说明厂商宣称它具备较强能力，不能直接推出它已经全面接近云端模型。原文作者没有亲自复测，文章也明确表示，当时尚无外部独立运行结果。仓库超过 10,000 stars 能反映关注度，无法补上性能验证。

本地运行的价值，比省 API 费更具体

原文看重三件事：没有按 token 收取的 API 费用、数据留在本机，以及断网仍能工作。

对程序员来说，这些诉求很实际。代码库不必发送给远程推理服务，离线时也可以继续使用编程助手。如果 agent 每天发起数千次调用，持续调用费也确实值得计算。

但原文没有给出总成本对照。本地方案仍有硬件、电费和维护成本，约 120W 的典型功耗也需要计入。文章同时引用了 Gemini 4 Hydrogen 每百万输入 tokens 1.50 美元，以及一款决策模型 0.10 美元的价格，用来说明云端价格也在下降；后者没有说清具体计费口径，不能据此精确算回本周期。

文章还提到 InferSSD：它尝试通过 NVMe 存储，在消费级 GPU 上运行 800B 级 MoE 模型，预填充快，但解码比 llama.cpp 慢。两者共同关注的问题，是如何足够快地把权重送到计算单元。

这能帮助理解本地推理为什么越来越依赖内存带宽和 SSD。不过，原文进一步断言瓶颈已经不再是智能水平，就说得太满了。权重搬运效率提高，不会自动保证复杂任务的正确率。

开放程度也要分开看。Edge0-AI/edge0 的代码采用 Apache 2.0，权重则在 Qwen 许可证之上使用 Edge0 自己的社区许可证：允许研究、内部使用和输出的商业使用，但出售模型或将模型作为商业服务提供，需要另行许可。

代码采用 Apache 2.0，不代表权重可以按同样条件商用。

因此，下载 Edge0/Edge0-145B-q3k 做内部实验，与把它接到收费产品后端，是两件授权要求不同的事。原文关于「能构建自己的产品」的乐观描述，必须受到这项限制约束。

我的判断

我认同文章把重点放在端侧架构，而非只看参数规模。稀疏激活、矩阵共享、分层加载和低比特训练，确实构成了一套连贯的设计思路。它试图解决的是大模型如何在有限硬件资源里持续工作。

但「145B 装进背包」容易让读者忽略配置门槛。29GB 的口径、长上下文下的速度、持续运行表现，都没有被原文充分解释。它也没有给出完整的质量与速度对照，无法据此判断该方案比常见本地模型或云端 API 更划算。

作者建议有合适硬件的人尝试，没硬件的人先别买电脑，这个取舍合理。性能判断仍主要建立在厂商材料上，属于待复现的发布解读。文章还把开放权重与可复现研究、供应商独立性联系起来，这个方向成立，但实际可复现程度仍取决于训练信息、工具和授权是否足够完整。

能拿来做什么

• 已有高内存电脑的开发者，可以把 Edge0/Edge0-145B-q3k 当作本地编程助手的候选，用自己的代码库测试代码解释、问题定位和修改建议，同时记录配置、内存峰值、首 token 等待和生成速度。
• 评估离线工作流时，要检查完整链路。模型在本地运行，不代表编辑器插件、agent 工具和检索服务都能离线，也不自动保证这些组件不发送数据。
• 对每天大量调用模型的团队，先用真实任务比较本地方案与云端 API 的成本和完成质量；原文没有提供足够数据支持统一的回本结论。
• 准备接入 Node 后端或对外提供模型服务前，分别核对代码和权重许可证；原文已明确，商业服务需要另行许可，不能仅凭仓库的 Apache 2.0 标识决定上线。