Meta 开源 8160 亿参数模型,官方给的方案是两台 Mac Studio

Meta 开源 8160 亿参数模型,官方给的方案是两台 Mac Studio

10 月 15 日,Meta 放出了 Muse Spark Open 的权重。同一天,苹果在自己的机器学习研究页面贴出了一份带命令、带数字的技术文章,讲怎么把这个模型跑在自己的机器上。两家公司分开发,内容严丝合缝。

AI 生成的示意图,非官方原始图表,不代表真实数据形状

一、名字里就写着四件事

Meta AI Research 那篇博客的措辞很克制,第一句就把规格交代完了:Muse Spark Open 是一个原生多模态模型,总参数 816B,激活参数 42B,上下文窗口 100 万 token。

Meta 给它的定语是"迄今美国能力最强的开放权重模型"。这个"美国"是官方自己加的限定,不是媒体补的。后面我们会看到为什么这两个字不能省。

官方博客没有展开架构细节,只说它是原生多模态。SiliconANGLE 的报道里提到,输入可以混用文本、图像、音频、视频。明确来自官方的是定位:面向编码和智能体任务,长周期任务、复杂软件工程、多步推理是重点优化方向。

二、42B 激活,凭什么要 1.6TB 内存

这是整件事里最容易被读错的一行数字。

MoE(混合专家)的思路是把模型切成很多专家,每个 token 只叫醒其中一小部分。816B 里只激活 42B,省下的是每次前向传播的算力。权重一个都没少,全都得在内存里待着,因为你不知道下一个 token 会叫醒谁。

苹果的文章把这个代价写成了确切数字:

原生 BF16 :光模型参数就要超过 1.6TB 内存

4 位 NVFP4 :占用降到约 493GB

单台上限:M5 Ultra Mac Studio 最高 512GB 统一内存

493GB 已经逼近 512GB 了。加上推理过程中的中间计算还要再吃一块内存,苹果的结论很直接:单台装不下,必须跨机器并行。

要注意口径差异。苹果的 493GB 说的是"模型内存占用";据 VentureBeat 转录的模型卡,部署要求写的是 NVFP4 版本至少 700GB 加速卡显存,BF16 版本 2TB。前者是权重的体积,后者是跑起来要准备的空间,不是同一件事。

三、苹果拆模型的方式:切深度,还是切宽度

苹果给了两条并行路线,区别一句话能说清。

流水线并行:按深度切

前半部分层放一台机器,后半部分层放另一台。第一台算完把结果交给第二台。好处是通信量小,只需要传两层之间的中间结果。坏处是后一台得等前一台,两台机器没法一直同时干活。解码速度和单机几乎一样。

张量并行:按宽度切

每一层都拆开分给多台机器,大家一起算同一层再汇总。设备能同时干活,但每个 token、每一层都要广播输入、收集输出,通信次数多得多。没有极低延迟的互联,多出来的算力会耗在等待里。

张量并行能不能真的加速,全看机器之间怎么连。这正是这次苹果端出来的东西:macOS 26.2 里加了一个跑在雷雳 5 上的低延迟 RDMA 驱动,MLX 从 v0.30.1 起在它之上实现了名为 jaccl 的通信集合。苹果的配线方案是每台之间接两根雷雳线,把链路带宽翻倍;四台机器组一个雷雳网格,每对之间都是两根线。

硬件底子是 M5 Ultra 的 1.2TB/s 统一内存带宽,上一代 M3 Ultra 是 819GB/s。苹果说单机的首 token 延迟最高比 M3 Ultra 快 4.6 倍,解码速度约 1.6 倍。

四、怎么用两条命令把它拉起来

苹果没把这部分藏着,直接给了命令。跑基准:

bash 复制代码
mlx.launch --hostfile hostfile.json --backend jaccl \
  --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.benchmark --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  -p 8192 -g 128 -b 1

起一个本地服务,接上任何会讲 OpenAI 兼容接口的编码智能体:

bash 复制代码
mlx.launch --hostfile hostfile.json --backend jaccl \
  --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.server --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --port 8080

苹果文章里给的配置示例用的是 OpenCode,把 baseURL 指到 127.0.0.1:8080 就行。这条路的吸引力在于:权重在本地,请求不出本机,智能体工具链不用改。

五、官方实测:三个配置,两组数字

苹果用 mlx_lm.benchmark 测的,条件是 8192 token 上下文、生成 128 个 token、batch size 为 1。batch 为 1 的意思是"一个人对着一个模型说话",这是本地 AI 的典型场景,说明不了多人并发的吞吐。

Muse Spark Open 的解码速度(token/秒)

2 台 · 流水线:15.74

2 台 · 张量:24.99

4 台 · 张量:36.73

首 token 延迟(秒,越低越好)

2 台 · 流水线:8.4

2 台 · 张量:8.2

4 台 · 张量:4.8

苹果的表里,Muse Spark Open 在 M3 Ultra 和单机 M5 Ultra 两列都是空的。它在那两种配置下放不下,没有可比的数字。

从流水线换成张量,双机速度从 15.74 提到 24.99,涨了接近六成。机器再翻倍到四台,速度只从 24.99 到 36.73,不到五成。差额就是张量并行的通信税:每层都要广播输入、收集输出,机器越多,单次加机器带来的收益越小。苹果的措辞是,像雷雳 RDMA 这样的低延迟通信技术,对张量并行"能否产生任何加速至关重要"。

上下文拉到 65536 token 之后,出现了两处反转。一是在这个长度下,双机张量并行的 prefill 反而落后于双机流水线,苹果给的解释是 Muse Spark Open 的专家输出需要额外归一化,多出来的 prefill 通信在低机器数时抵消了算力收益;解码不受影响。二是双线缆的价值在大上下文才显现:四台机器在 65536 上下文下,每对链路接两根线把首 token 延迟从约 50.5 秒降到 40.6 秒。

功耗也给了。65K 上下文推理时,M3 Ultra 峰值约 200W,M5 Ultra 约 300W,苹果的形容是"一台普通烤面包机用电量的一小部分"。四台机器满载 1200W 上下,还在一台大家用电器的范围内。

六、25 token/秒,是什么手感

苹果的说法是四台机器上"每秒超过 36 个 token,高于平均人类阅读速度"。这句话对阅读成立,对干活未必。

Plotly 在发布当天把模型拉进自己的数据分析考试里跑了一遍,43 道题过了 38 道(88%)。他们按苹果的数字估算:一道典型的问题,跑在两台 Mac Studio 上大约要 3 分半,四台大约 2 分出头,而走 OpenRouter 的托管 API 是 48 秒。

硬件那笔账也得先算清楚。VentureBeat 引苹果官网价:256GB 的 M5 Ultra Mac Studio(1TB SSD)标价 10,799 美元,四台凑出 1TB 内存合计 43,196 美元,税前、不含配件。而 Meta 官方演示用的是两台 512GB 配置,苹果说这个配置 10 月底才上市,价格还没公布。另有 Engadget 估算四台 256GB 方案约 38,000 美元,Plotly 文章里引用的 256GB Mac Studio 单价则是 11,299 美元。几个来源的数字对不齐,可能来自配置与统计口径的差异,但都属于第三方推算,Meta 和苹果都没有给出这套方案的官方总成本。

七、Meta 自己那张表:工具调用领先,编码落后

按 VentureBeat 转录的 Meta 官方对照表,Muse Spark Open 排在前面的集中在工具调用和视觉:

排在前面

MCP-Atlas 89.2(Qwen3.8 84.5、GLM 5.3 84.2、Kimi K3 82.3)

JobBench 61.8(GLM 5.3 61.4、Kimi K3 54.3、Qwen3.8 52.7)

HLE-Diamond 无工具 26.1(Kimi K3 22.2、Qwen3.8 17.3)

ZeroBench 带工具视觉 50(Kimi K3 41)

SimpleVQA 73.6(Kimi K3 71.9)

排在后面

Terminal-Bench 2.1:76.4,Kimi K3 85.0、GLM 5.3 83.9、Qwen3.8 82.0

DeepSWE 1.1:60,Kimi K3 68、GLM 5.3 67

GDPVal-AA v2:1401,GLM 5.3 1653、Qwen3.8 1613、Kimi K3 1537

Artificial Analysis 智能指数一栏,Meta 在表里给自己填的是 39,GLM 5.3 是 45,Kimi K3 是 44,Qwen3.8-2.4T-A95B 是 40。VentureBeat 特别提示,这个 39 出自 Meta 的材料,他们未能核实 Artificial Analysis 对 Spark Open 这个检查点的独立公开评估;该机构对托管版 Spark 和 Wonder 的评分是另一回事。

另外两个变量会影响怎么读这张表。一是推理档位不同,Muse Spark Open 用的是 xhigh,GLM 5.3 和 Kimi K3 用的是 max。二是 DeepSWE 的成绩各家用的是自己偏好的智能体框架,比的不只是模型。Terminal-Bench 2.1 这一项,第三方整理的表格标注了 Terminus 2 这套外壳。

MCP-Atlas 这个测试值得单独说一句。它给模型的是用自然语言写的任务,不告诉它该用哪些工具。模型得自己判断该调什么、按什么顺序调。SiliconANGLE 的报道里提到,测试覆盖 36 个在线 MCP 服务器上的 220 个工具。这类题目考的是"在陌生工具箱里找对东西"的能力,跟 Terminal-Bench 那种在终端里改代码的考法不是一回事。

"美国最强"这个说法,就是在这个背景下成立的。Meta 自己的表里,另一家美国开放模型 Inkling 是 26,NVIDIA Nemotron 3 Ultra 是 23,都低于 39。但榜上排在 39 前面的几款,来自中国实验室。

八、许可证上,值得读完的三行

Muse Spark Open 用的是 Meta 自己的 Muse Model License,Apache 2.0 那套在这里不适用。博客里的说法是"附带有限商业条款,允许许多开发者免费使用"。许可文本写得更具体:

署名

任何用到本模型或衍生品的产品或服务,都要显著展示"Built with Muse Spark Open",位置可以是界面、文档、网站或设置菜单。

模型即服务的收入门槛

如果你通过 API 之类的方式把模型输出提供给第三方,且你与关联方在任意连续 12 个月内的总营收超过 2000 万美元,需要通知 Meta 并另行签署书面协议。内部使用、研究、非模型服务的商业活动,以及把模型作为自己产品的一个组件,都不在这条之内。

衍生品的定义比想象中宽

许可里"Derivatives"包含用本模型创建、训练、微调、蒸馏或改进的 AI 模型,也包含用它的输出或结果训练出来的模型。用 Spark Open 的输出去蒸馏一个新模型,那个新模型仍然要遵守署名要求和使用政策。Meta 声明对生成输出不主张所有权。

九、不想买两台 Mac,还有几条路

Meta 这次把落地的门开得比较宽,四类路径都有官方说法。

托管 API: Baseten、Fireworks AI、Groq、Modal、Nebius、OpenRouter、Together AI,七家首发。Together AI 公布的价格是每百万输入 token 1.25 美元、缓存输入 0.15 美元、输出 4.25 美元,各家未必一致。

GPU 服务器自部署: 权重可从 Hugging Face、Amazon SageMaker AI、Google Cloud Model Garden、Microsoft Foundry Models 下载。推理引擎支持 SGLang、vLLM、TensorRT-LLM、Transformers、llama.cpp、Unsloth,针对 AMD、Apple、Intel、NVIDIA 都做了优化。

本地苹果硅: MLX,权重直接从 Hugging Face 拉,起一个 OpenAI 兼容的本地服务。

继续训练: PyTorch 的 TorchTitan,Meta 官方点名用来做进一步调优。

一个容易被忽略的工程细节:Meta 在 SGLang 里塞了自研的可自动调优 Helion GPU 内核,官方称在 NVIDIA 和 AMD GPU 上有 1.03 到 3.95 倍的内核级加速,端到端在 AMD MI350 上是 3%。内核级和端到端是两个口径,别混着读。

Meta 还演示了两个跑在设备上的完整流程:用 Muse Code 驱动 Spark Open 给开源 Mastodon 客户端 Ice Cubes 改 iOS 代码,修 bug、加功能、跑完整构建;另一个是接管 DaVinci Resolve,逐帧看素材挑出精彩片段并裁成竖版。这两个都是官方演示,没有公开的量化指标。

十、现在还悬着的三件事

512GB 版 Mac Studio 的定价。苹果只说这个配置 10 月底上市,价格没公布。没有它,Meta 演示的那套双机方案在发布当天还买不齐。

完整的评估报告。Meta 说模型按"Meta Superintelligence Scaling Framework"评估并达到了发布门槛,详细结果写在模型卡里,完整评估报告"即将发布"(available soon)。目前公开的是结论,过程还在路上。

第三方独立复现。除了 Plotly 那份 43 题的数据分析考试,主流第三方评测机构的独立跑分还没出来。Meta 表格里那个 39,暂时只该当成 Meta 自己的数字。

十一、我的判断

这次真正新的东西在别处。"跑在哪"这个问题,第一次有了官方答案和官方数字。以前开放权重放出来,硬件方案要社区自己摸索;这次苹果把命令、配线方式、功耗、首 token 延迟全摊开了,连几根雷雳线都写了。

它同时把一道算术题摆到了台面上:为了把数据留在本地,你愿意接受 25 到 37 token/秒(双机到四机)的速度,并为此准备几万美元的硬件吗。对大多数团队,答案还是先走 API,把模型换成 Spark Open 看看效果;本地那套,等 512GB 的定价出来再算。

顺带一句,Plotly 那 43 题里模型错的地方挺有参考价值:5 道"隐藏彩蛋"只找到 2 道,还自己在一份本来正确的数据上编了个"物理上不可能"的异常值。长周期、多步推理是它的长项,不等于它不会在中间某一步自信地跑偏。

你手上有没有那种"数据绝对不能出内网"的场景?如果有,这套方案现在值得算一遍账了。欢迎在评论区说说你的硬件预算和你打算跑什么任务。

相关推荐
miofly1 小时前
OpenCode控制台密钥泄露事件:1.4%用户受影响,多方说法现分歧
开源·github
miofly1 小时前
GitHub 周榜趋势速报 | 2026-10-18
开源·github
鶴哥只手遮天1 小时前
Spring Boot 4.1.1 深度源码解析-第 15 章 · 条件注解体系:全部 `@ConditionalOnXxx` 的实现原理
java·后端·开源
鶴哥只手遮天1 小时前
Spring Boot 4.1.1 深度源码解析-第 30 章 · 基础设施能力:SSL Bundle、Task 与虚拟线程、Retry
java·后端·开源
鶴哥只手遮天1 小时前
Spring Boot 4.1.1 深度源码解析-第 26 章 · 指标、观测与链路追踪:Micrometer 与 OpenTelemetry
java·后端·开源
鶴哥只手遮天2 小时前
Spring Boot 4.1.1 深度源码解析-第 19 章 · Spring MVC 自动配置:DispatcherServlet、消息转换
java·后端·开源
miofly2 小时前
GitHub 日榜趋势速报 | 2026-10-18
开源·github
鶴哥只手遮天2 小时前
Spring Boot 4.1.1 深度源码解析-第 28 章 AOT 与 GraalVM Native与序列化模型
java·后端·开源
鶴哥只手遮天2 小时前
Spring Boot 4.1.1 深度源码解析-第 27 章 · 可执行归档与 Loader:`JarLauncher` 与嵌套 jar
java·后端·开源