Edge0发布145B模型，主打本机运行

145B 参数的模型能在笔记本上完成编程和 Agent 任务吗？Edge0 团队给出的答案是：可以，但要同时改模型架构、训练方式和推理引擎。此次发布的 Edge0-145B、Edge0-120B，以及配套框架和部署工具，试图把更多复杂工作搬到本地。

对程序员来说，值得看的不是参数规模，而是它如何处理内存瓶颈，以及公开成绩能支撑多大的结论。原文展示了有吸引力的内部测试和任务演示，也留下了硬件条件、内存统计口径、实际成本等需要核对的问题。

145B 为什么能装进笔记本

大模型在本地运行，难点不只是算得动。权重要存得下，生成时要读得快，还得给操作系统和其他应用留下资源。

Edge0 的第一步，是让稀疏专家共享大矩阵。每组 64 个专家共享两个大矩阵，每个专家只保留表达自身差异的一小组参数。模型总参数为 145B，但每次推理步骤只有约 10B 参数参与计算。这里的「专家」可以理解为按输入选择调用的不同计算模块。

145B 是总参数规模，不代表每生成一个 token 都要计算全部参数。

第二步是从训练开始就采用面向端侧的架构，而不是先训练云端模型，再靠压缩、剪枝塞进电脑。这个选择决定了它的部署效果不能只归功于某种量化格式。

第三步是把 GPU 显存、系统内存和 SSD 串成流水线，让读取与计算重叠。高频使用的「热专家」留在 GPU 内存，约 40GB 的专家库放在系统内存，约 48GB 的词表数据放在 SSD，按需读取。

第四步是让 CPU 与 GPU 并行工作，再用推测解码（speculative decoding）一次验证多个候选 token，把读取权重的开销分摊到更多输出上。

团队据此报告了 80+ tokens/s 的解码速度，以及笔记本对比中的 28GB 峰值内存。不过，后面的能力与内存对比又使用了 29GB。这两个数字，以及系统内存中的 40GB 专家库如何计入峰值，原文没有解释清楚，不能自行拼成统一配置。

此前 Edge0-35B 在 iPhone 18 Pro Max 上报告约 2.5GB 内存、37+ tokens/s，早期发布还给出峰值低于 2.5GB。它与 145B 的测试硬件不同，不能据此计算扩展效率。原文也没有给出具体功耗、首 token 延迟和持续运行曲线，80+ tokens/s 只能说明其中一个环节。

跑分接近云模型，证据有多硬

原文最有分量的证据集中在编程和 Agent 评测。以下分数均为百分制，越高越好：

评测	Edge0-145B	Qwen3.8-Flash-Next	DeepSeek-V4-Flash-0731	Claude-Opus-4.6（Max）
DeepSWE 1.1	64.6	58.7	54.4	无公开分数
Terminal-Bench 2.1	86.52	83.3	82.7	78.2
GPQA-Diamond	90.4	未列出	90.8	91.3
IFBench	80.6	未列出	79.2	62.5
AA-LCR	79.3	未列出	未列出	78.0

这些 Edge0、Qwen、DeepSeek 和 Claude 的对比成绩来自 Edge0 内部评测。缺失项不代表零分，也不能把某个测试领先扩大成全面领先。

与端侧基线 Qwen3.8-27B 相比，团队报告 Terminal-Bench 和 DeepSWE 的相对提升分别为 18.5%、53.1%；HLE、GPQA、IFBench 则为 14.9%、1.3%、1.4%。注意这里是相对提升，不是增加同样数量的百分点。它支持的判断是：团队报告的最大收益集中在编程和 Agent 工作。

另一个卖点是内存效率。Edge0-145B 在六项评测上的平均分为 72.8，实测峰值内存 29GB；Qwen3.8-Flash-Next 平均分为 71.7，标准 4-bit 部署内存估算为 70GB。由此得出 Edge0 约占基线 40% 内存、可在 48GB 笔记本使用的结论。

问题在于，一边是内部实测，一边是尚待测量的估算。六项异质测试的平均值也只能粗看，无法直接对应团队修复 Bug 的成功率。完整评测设置、硬件环境和复现说明被列为随技术报告发布的内容，当前输入没有展开。

真正有用的是本地执行闭环

对日常 AI 编程更有启发的，是它描述的工作流程：拆解需求、写代码、调用工具执行、失败后修复，再截图检查结果，继续迭代。

如果任务需要几十轮交互，本地推理确实能减少对云模型调用的依赖。代码与数据也可以留在电脑上。但模型能够生成代码，与整个工具链已经可靠，是两件需要分别验证的事。

原文的案例覆盖了多个领域：

• Roadster 飞行原理解说视频在一小时内完成，包含研究、脚本、素材生成和剪辑。
• Manhattan 的 Blender 城市场景在一小时内完成，并迭代材质、灯光和渲染结果。
• 中世纪 RPG 城市场景包含超过一千栋住宅，并渲染了 20 秒飞越镜头，用固定路线暴露穿模、遮挡和比例问题。
• 无人机案例从一句指令生成飞控与视觉识别程序，完成避障和寻找红色背包。
• PCB 案例从 KiCad 两层板布局布线，延伸到 Unreal Engine 5 的制造与装配动画。

这些演示说明了团队希望打通哪些工具，却没有给出重复成功率、失败次数和人工介入记录。视频案例声称人工需要一个月；Manhattan 案例估算人工成本为 12,000 至 18,000 美元、至少一个月，云模型 token 费用超过 150 美元。这些都不足以作为一般项目的成本基线。

没有云模型 token 费用，不等于没有完成任务的成本。

硬件、耗电、等待和审核仍需计算。原文自己也限定：核心模型能力可以离线，依赖在线信息或服务的功能仍然需要联网。

我的判断

我认同它把模型与推理系统一起设计的方向。端侧部署面对的是容量、带宽、算力与散热的共同约束，仅靠参数量或量化位数，很难解释实际体验。

但「达到前沿云模型能力」需要限定在列出的模型和评测上。「全球首个」也只是团队的发布主张，当前材料不足以独立确认。相比直接调用云 API，Edge0 把成本和运维责任更多地转回了本地；相比使用更小的本地模型，它又需要证明复杂任务的成功率足以抵偿资源占用。

部署支持也有边界。团队称首发覆盖 macOS、Windows、Linux，支持 Apple M 系列及 NVIDIA RTX Spark、RTX 4090、RTX 5090，并提供一键部署工具和硬件指南。支持平台不等于每台机器都达到文中成绩。

同样，95% 主流芯片平台覆盖、超过 500 万台量产设备、三个月超过 1500 万次下载，以及截至 2026 年 10 月超过 11 万家客户组织，描述的是整个产品组合。它们不能证明 Edge0-145B 在这些设备上都能运行。

耳机客户的 92% 本地、8% 云端使用比例，也来自以日常对话为主的场景，不能套到编程团队。端云如何分工，仍应由任务和硬件决定。

能拿来做什么

• 用仓库里可验收的前端或 Node 任务试跑，例如修复一个已有 Bug，记录测试是否通过、人工修改量和总耗时，再与现用云模型或小型本地模型比较。
• 把截图检查接进页面生成流程，让模型在运行后检查布局和交互；验收仍要保留测试与人工检查，不能只看最终截图。
• 按真实工作环境测内存和响应，同时打开编辑器、浏览器与开发服务，核对首 token 延迟、生成速度及持续运行表现。
• 对敏感代码优先评估本地推理，同时检查所调用工具的数据流；需要实时信息或机器资源不足时，再使用云端支持。