Model · 2026-10-15

Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta

Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta

Hugging Face Blog2026-10-15About 4 min readImmediate attention

Marked important by the editors and published within 30 days.

Open-weight modelsMultimodalCoding agentsQuantisation & speculative decoding
On this page12 sections

The full write-up and the editors' notes are in Chinese; the summary above is from the original announcement.

Record

The signal

#

发生了什么

Meta 发布了开放权重模型 Muse Spark Open,这是 Muse 系列中体量最大的一款。它沿用该系列上一款小模型 Muse Glimmer 的 tokenizer 与词表,但在架构上把每层的稠密前馈网络替换成专家混合(MoE)结构。

模型总参数约 8160 亿,每个 token 只激活约 420 亿;输入可以是文本、图像、音频和视频,输出只有文本。推理上下文窗口最长 100 万 token,图像、视频、音频 token 与文本共用同一个窗口。

具体内容

架构上的关键数字:

  • 语言模型 62 层,隐藏维度 8192。
  • 每层 128 个 query 头、16 个 key-value 头(分组查询注意力),每头 64 维。
  • 每个 MoE 层 256 个专家,路由为每个 token 选 8 个;专家占模型总参数约 97%。
  • 注意力块带输出门与输出归一化,并对 query 和 key 做归一化(QK-norm);每个块的输入输出通过可学习的残差门结合,而非直接相加。

部署方面,所有 256 个专家都要常驻显存,因此显存需求按 8160 亿参数模型计算,但计算速度接近 420 亿参数模型。BF16 checkpoint 以 safetensors 格式存储约 1.5 TB;NVFP4 checkpoint 用 4 位精度存储参数,原文称精度损失可忽略,专为 NVIDIA Blackwell GPU 准备。原文给出的参考部署方式是:BF16 在 4 个节点、每节点 8 张 H200 上以张量并行 TP=32 运行,NVFP4 在单节点 B200 上运行。

多模态侧,感知编码器 1.8B 参数、50 层、隐藏维度 1536、16 个注意力头,把图像切成 14×14 的 patch;视频帧走同一编码器。音频编码器每 80 毫秒输出一个音频 token,即每秒 12.5 个 token,10 秒音频对应约 125 个输入 token。

长上下文方面,配置中 max_position_embeddings 设为 1,048,576。按原文计算,每个 token 向 KV 缓存写入 126,976 个值,BF16 下约 250 KB/token,满 100 万 token 上下文约需 266 GB。

推理支持上,transformers 提供 MuseSparkForConditionalGeneration 与 MuseSparkProcessor,用 DistributedConfig 分别设置 tp_size 与 ep_size;原文同时给出 llama.cpp、vLLM、SGLang 的部署配方。推理强度通过 low/medium/high/xhigh 映射到 16/64/256/512,且无法完全关闭推理,简单任务建议用 low 以少消耗 token。

与以往相比

与同系列 8 月发布的 Muse Glimmer 相比,Muse Spark Open 把稠密前馈换成 MoE,规模大幅提升,并新增音频编码器,因此可以处理带声音的视频。原文称它是目前美国开放权重模型中最强的一个。

对读者意味着什么

  1. 想自托管的话,先算显存而不是看激活参数:8160 亿参数常驻显存与 1.5 TB 的 BF16 权重决定了这不是单机能跑的东西,NVFP4 版本把门槛压到单节点 B200,但绑定了 Blackwell。
  2. 做智能体编码产品的团队可以评估它的多模态输入:截图、录屏、语音笔记与代码库可以进同一个上下文,适合需要一边看界面一边改代码的任务。
  3. 长上下文有明确成本:100 万 token 的 KV 缓存按原文估算约 266 GB,容量规划时要和权重显存一起算。

Why now

Why it matters

#

这是目前开放权重阵营里体量最大的多模态 MoE 模型之一,且明确面向智能体编码训练,意味着团队可以在自己的基础设施上评估一个能同时读代码、截图和录屏的模型。但它把部署门槛推到了多节点 H200 或单节点 B200 的量级,选型时必须先算显存与许可,而不是只看激活参数。

Background

Technical context

#

MoE 通过路由让每个 token 只经过少数专家,使总参数与单 token 计算量脱钩:这里总参数约 8160 亿,但每 token 只算约 420 亿。代价是所有专家都要驻留显存,所以显存按总参数算、速度按激活参数算。分组查询注意力减少 KV 头数,从而压低长上下文下的 KV 缓存增长;NVFP4 则是把权重压到 4 位以适配 Blackwell 的数值格式。

At your level

Have AI explain this signal at your level

Pick your level of experience and AI writes an explanation for it on the spot.

Audience

Who should care

#
评估自托管开放权重模型的基础设施与平台团队做编码智能体、需要多模态输入的工程团队负责推理容量规划与 GPU 采购的工程师关注开放权重模型许可与部署成本的技术决策者
Areas it may affect
开放权重模型多模态推理自托管部署编码智能体

Next

Learning path

#
  1. 先读开放权重与模型许可的基础材料,弄清权重可下载不等于可随意商用。
  2. 再理解 MoE 的总参数与激活参数如何脱钩,以及为什么显存要按总参数估算。
  3. 然后用 KV 缓存的计算方式复算 100 万 token 上下文的显存开销,判断自己的场景是否用得上。
  4. 最后对照原文给出的 transformers、vLLM、SGLang 配方,在自己的硬件上跑一次小规模验证。

Getting started

Have AI draft a learning path

From the related knowledge and skills on this page, AI drafts a path from the basics to applying it.

Network

Where it sits in the network

#

How this signal connects to neighbouring technologies, skills and background knowledge. Follow any link to keep exploring.

Comparison

Compare with another technology

Pick another published technology and AI writes a comparison of what they share, how they differ and when to use each.

Further thought

Follow-up questions

#
  • BF16 与 NVFP4 两个 checkpoint 在你们任务上的质量差距有多大,是否值得为单节点部署接受 4 位精度?
  • 100 万 token 上下文配上约 266 GB 的 KV 缓存,在你们的并发下实际能开多长?
  • 模型无法关闭推理,low 档在简单编码任务上的 token 消耗与准确率表现如何?

Publication record

Featured in

#

The briefings that carried this signal, newest first; the last row is the weekly review of its week. The tag is the section it ran in.

  1. 技术简报 - 2026-10-20

    Immediate attention

Sources

Hugging Face Blog

MetaBig tech2026-10-15
Open original sourcehttps://huggingface.co/blog/meta-muse-spark-open