Meta 在 10 月 15 日放出 816B 权重：Muse Spark Open 的许可证、门控与本地门槛

放出来的东西，和 Muse Wonder 那条线不是一回事#

官方确认的事实先列清楚。发布日期是 2026-10-15，来源有四份：Meta 官方博客 research.meta.ai/blog/muse-spark-open；Hugging Face 官方博客同日《Welcome Muse Spark Open》（作者 Pedro Cuenca）；PyTorch 官方博客《Muse Spark Is Now an Open-Weights Model》；以及 9to5Mac 同日报道。

这里有个措辞必须抠：官方原话是 open-weights（开放权重），不是 open-source。官方自己没说是开源软件，我们替它说就会错。

谱系也是官方给的：Muse Spark 于 2026-04 首发、一直是闭源；Muse Spark Open 与 Muse Spark 1.3 共享同一底座，额外做了一轮安全后训练，理由写得很直白——为了让它在「没有自家系统护栏」的独立部署里也扛得住滥用。另外，2026-08 发布的小稠密模型 Muse Glimmer 与本模型共用同一 tokenizer。

模型结构（官方 HF 博客）：

• 每层 256 个专家，每个 token 路由到 8 个；
• 语言模型部分 62 层、hidden 8192；每层 128 个 query head / 16 个 KV head（GQA），每 head 64 维；
• attention 块带输出门与输出归一化，对 query/key 做 QK-norm，每个块的输入输出用可学习的残差门合并不是直接相加；
• 输入嵌入与输出层是两个各自约 1.66B 参数的独立矩阵；
• 上下文最长 1M tokens；输入吃文本、图像、音频、音视频，输出只有文本。

用途定位是 agentic coding：多文件重构、长时间的调试会话。这一点决定了它的体型——它被设计成一个能在你的仓库里连跑几小时的同事，而不是一个问答框。

「开放权重」的第一道门：门控下载#

HF 页面上的两个标签值得并排看：license: other，以及仓库状态 gated: manual。

门控表单的字段（官方页面）：First Name、Last Name、Date of birth、Country、Affiliation、Job title（下拉选项包含 Student / Research Graduate / AI researcher / AI developer/engineer / Reporter / Other），另外附带 geo(ip_location)。

填表本身不稀奇，稀奇的是它有多实。作者实测：?blobs=true 的元数据接口对门控仓库仍然可读，我靠它拿到了本文所有仓库体量数字；但同一时刻去读权重之外的 raw/main/config.json，HTTP 状态码是 401——需要登录且账号已获批。

我把这条单独写出来，是因为它是最省时间的排错知识：如果你在 CI 或容器里直接拉 config.json 拿到 401，那不是你 token 过期，是仓库根本没给你放行。此时 huggingface-cli login 加一个已获批的账号才能解决，换镜像、换 UA、加重试都是白费。

顺手记一条第三方口径：The New Stack 认为它的许可证「并非完全开放」——我这篇只拿到 Techmeme 的转述，没取到原文，所以这条按「有第三方评测如此认为（转述，未核实原文）」看待，不作为结论。

我实测的仓库真实体量#

下面这条命令是作者实测、读者可以原样复跑的版本。本机 huggingface.co 不可达，所以走镜像：

# 仓库真实体量：78 个文件 1644.37 GB，以及权重里的真实参数个数
curl -s "https://hf-mirror.com/api/models/meta-models/Muse-Spark-Open-816B-A42B?blobs=true" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); s=d['siblings']; \
print(len(s),'files', sum(x.get('size') or 0 for x in s)/1e9,'GB'); print(d['safetensors']['parameters'])"

换一个脚本能把两个仓库都拆开看，我把它跑了一遍，下面代码与输出都是实测：

#!/usr/bin/env python3
"""核 Muse Spark Open 两个 HF 仓库的真实体量（数据源 hf-mirror.com API）。"""
import json
import urllib.request

REPOS = ["meta-models/Muse-Spark-Open-816B-A42B",
         "meta-models/Muse-Spark-Open-816B-A42B-NVFP4"]

for repo in REPOS:
    url = f"https://hf-mirror.com/api/models/{repo}?blobs=true"
    # 镜像站会拦掉 python 默认 UA，必须显式带一个浏览器 UA，否则 403
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    with urllib.request.urlopen(req, timeout=60) as fh:
        d = json.load(fh)

    sib = d["siblings"]
    total = sum((x.get("size") or 0) for x in sib) / 1e9
    shards = [x for x in sib if x["rfilename"].endswith(".safetensors")]
    biggest = max((x.get("size") or 0) for x in shards) / 1e9

    print(f"--- {repo}")
    print(f"文件 {len(sib)}  总计 {total:.2f} GB  "
          f"权重分片 {len(shards)}  最大分片 {biggest:.2f} GB")
    print(f"参数张量 {d['safetensors']['parameters']}")
    print(f"gated={d.get('gated')}  downloads={d.get('downloads')}  "
          f"likes={d.get('likes')}  lastModified={d.get('lastModified')}")

--- meta-models/Muse-Spark-Open-816B-A42B
文件 78  总计 1644.37 GB  权重分片 65  最大分片 29.60 GB
参数张量 {'BF16': 821906490368, 'F32': 130039296}
gated=manual  downloads=402  likes=236  lastModified=2026-10-15T15:46:43.000Z
--- meta-models/Muse-Spark-Open-816B-A42B-NVFP4
文件 141  总计 533.04 GB  权重分片 127  最大分片 17.18 GB
参数张量 {'BF16': 48812377088, 'F32': 130131456, 'U8': 386547056640, 'F8_E4M3': 48318382080}
gated=manual  downloads=331  likes=85  lastModified=2026-10-15T17:18:42.000Z

三件从这堆数字里读出来的事：

第一，下载量小得出乎意料。 发布十几个小时后，BF16 仓库 downloads 402、likes 236；NVFP4 仓库 downloads 331、likes 85。门控审批 + 1.6TB 的体量，这两个数字其实合理。

第二，权重里的参数比官方口径多。 BF16 仓库里真实张量数是 821,906,490,368（BF16）加 130,039,296（F32），合计 822,036,529,664，约 822.04B——比官方的 816B 多出约 6.0B。差额最可能来自多模态编码器与投影层，但 Meta 没有说明自己的口径怎么算，所以这条是作者推断，不是官方结论。

第三，量化版不是清一色 4bit。 NVFP4 仓库按 dtype 拆开是：386,547,056,640 个 U8（4bit 权重按字节打包存）、48,318,382,080 个 F8_E4M3、48,812,377,088 个仍留 BF16、外加 130,131,456 个 F32。全仓库 quantization_config 存在，工具链是 modelopt，HF 标签里有 nvfp4、8-bit、modelopt。也就是说：约 386.5B 个参数确实是 4bit 打包的，但还有约 48.8B 个参数留在 BF16 没降精度——这些通常是路由、归一化、嵌入这类对精度敏感的部分。

许可证：能商用、能蒸馏，但有署名与 MaaS 门槛#

许可证是官方全文，我抓到的是一份 8278 字符的原文：文件 LICENSE.md，标题写的是 MUSE MODEL LICENSE，version: Muse Spark Open，Release date: October 15, 2026，版权归 Meta Platforms。HF 侧的标签是 license: other。下面几条都是官方条款原文的要点：

• 授权范围：免费、可商用、可修改（明确写了含 fine-tune）、可创作衍生作品、可蒸馏（distill）、可合并、可发布、可再分发、可转授权、可出售副本。
• 条件一：所有副本与衍生作品必须带上版权声明、本许可证与 Usage Policy。
• 条件二（署名）：必须在每个用到它的产品或服务的用户界面、文档、网站或设置菜单里显著展示「Built with Muse Spark Open」。这里的 Derivative 定义很宽——包含用它的输出或结果训练/改进出来的任何模型。换句话说，拿它的输出蒸馏出来的小模型，也要挂这句话。
• 条件三（MaaS 门槛）：如果 Licensee 或其关联方，通过 API 或类似接口向第三方提供模型访问且第三方拿到输出（即 Model as a Service），并且在任意连续 12 个月内合计毛收入超过 2000 万美元，那就必须先通知 Meta 并另签一份书面协议。不适用的情况也写明了：内部使用、研究、以及任何不属于 MaaS 的商业活动；或者它只是你产品里的一个组件（前提是那不是 MaaS 业务）。
• 条件四：Meta 不主张对模型输出拥有所有权。
• 条件五：AS IS、不担保；衍生模型的安全、部署与使用由 Licensee 独自承担。

Exhibit A 是 Muse Spark Open Usage Policy（2026-10-15），禁止用途包括违法内容、儿童剥削、人口贩卖、骚扰歧视、无牌照执业（金融/法律/医疗）、侵犯隐私与第三方权利、生成恶意代码、绕过安全措施，以及军事/战争/核相关、ITAR 管制物项、枪支毒品、关键基础设施与重型机械操作、自伤自杀、欺诈与虚假信息等。政策里有一句很实在的定位：明确声明不面向 18 岁以下用户。

一句话总结这段：这份许可证对个人和小团队基本等同于「随便用」，但也有三条你要落到流程里——署名文案要进 UI 和文档（写死一句 Built with Muse Spark Open）、蒸馏产物也要继承、以及一旦你的 MaaS 生意年毛收入越线就要先谈协议。

装得下吗：两台 Mac Studio 的账#

第三方报道（9to5Mac 引用 Meta 博客）给出的本地方案相当具体：与 Apple 最新的 MLX 配合做了优化；Apple 统一内存让 M5 Ultra 的集成 GPU 每台 Mac Studio 可用最多 512 GB，所以两台机器能装下整个模型；该芯片 1.2 TB/s 的内存带宽「足以读取每个 token 需要的那一小片」；结论是「两台 Mac Studio 表现得像一台有 1TB 统一内存的超级计算机」。

这句「两台能装下整个模型」经不起直接对照。作者计算：512 GB + 512 GB = 1024 GB 统一内存，而 BF16 仓库是 1644.37 GB，差 约 620 GB。能塞进去的只有 NVFP4 的 533.04 GB。所以那句官方话术对应的其实是量化版；想跑 BF16，要么四台，要么换一套 1.7TB 级的方案。

把这件事写成脚本，输入是体量、设备数和每设备内存，输出是能不能装下：

#!/usr/bin/env python3
"""muse_budget.py —— 816B MoE 放哪跑：把「装得下吗」算成一句话。"""
from dataclasses import dataclass

# 实测（2026-10-16，hf-mirror.com API ?blobs=true）
MEASURED_GB = {"bf16": 1644.37, "nvfp4": 533.04}
OVERHEAD = 0.35           # KV + 激活 + 运行时预留，按权重比例（作者经验值）


@dataclass
class Box:
    name: str
    devices: int
    per_device_gb: float

    @property
    def total_gb(self) -> float:
        return self.devices * self.per_device_gb


BOXES = [
    Box("2 × Mac Studio（统一内存，每台 512 GB）", 2, 512),
    Box("4 × Mac Studio（每台 512 GB）", 4, 512),
    Box("8 × H100 80GB（单机 TP=8）", 8, 80),
    Box("4 × H200 141GB（单机 TP=4）", 4, 141),
]

for dtype, weights in MEASURED_GB.items():
    print(f"== {dtype}：权重实测 {weights:.2f} GB ==")
    for box in BOXES:
        have = box.total_gb
        bare = have - weights
        with_oh = have - weights * (1 + OVERHEAD)
        flag = lambda g: f"{g:+8.0f} GB" + ("" if g >= 0 else " 装不下")
        print(f"   {box.name:34s} 可用 {have:6.0f} GB | 仅权重 {flag(bare)} "
              f"| 含 35% 预留 {flag(with_oh)}")

== bf16：权重实测 1644.37 GB ==
   2 × Mac Studio（统一内存，每台 512 GB）     可用   1024 GB | 仅权重     -620 GB 装不下 | 含 35% 预留    -1196 GB 装不下
   4 × Mac Studio（每台 512 GB）          可用   2048 GB | 仅权重     +404 GB | 含 35% 预留     -172 GB 装不下
   8 × H100 80GB（单机 TP=8）             可用    640 GB | 仅权重    -1004 GB 装不下 | 含 35% 预留    -1580 GB 装不下
   4 × H200 141GB（单机 TP=4）            可用    564 GB | 仅权重    -1080 GB 装不下 | 含 35% 预留    -1656 GB 装不下
== nvfp4：权重实测 533.04 GB ==
   2 × Mac Studio（统一内存，每台 512 GB）     可用   1024 GB | 仅权重     +491 GB | 含 35% 预留     +304 GB
   4 × Mac Studio（每台 512 GB）          可用   2048 GB | 仅权重    +1515 GB | 含 35% 预留    +1328 GB
   8 × H100 80GB（单机 TP=8）             可用    640 GB | 仅权重     +107 GB | 含 35% 预留      -80 GB 装不下
   4 × H200 141GB（单机 TP=4）            可用    564 GB | 仅权重      +31 GB | 含 35% 预留     -156 GB 装不下

这张表比任何宣传语都好用。要注意三个反直觉的地方：

第一，8 张 H100 装不下 BF16。 640 GB 的总显存对着 1644.37 GB 的权重，连边都摸不到。别被「8 卡」这个数字安慰到。

第二，8 张 H100 装 NVFP4 也只是「刚好够」。 仅权重余 107 GB，一加激活和 KV 就翻红。这也是它和 2 台 Mac Studio 的差别：统一内存那台机器是整机内存给模型用，而 H 系列卡要按 TP 切权重，有效容量只有显存。

第三，四台 Mac Studio 跑 BF16 也悬。 仅权重余 404 GB，含预留就变成 −172 GB。真要跑 BF16，预算要按 1.7TB 以上算。

1M 上下文的隐形成本：KV cache#

官方给的 attention 结构恰好够我们手算 KV。每层 16 个 KV head × 64 维，K 和 V 各一份，所以：

#!/usr/bin/env python3
"""muse_kv.py —— 1M 上下文的 KV cache 到底吃掉多少内存。"""
LAYERS = 62
KV_HEADS = 16          # 官方：每层 128 query head / 16 KV head（GQA）
HEAD_DIM = 64
PER_TOKEN_PER_LAYER = 2 * KV_HEADS * HEAD_DIM          # 2 = K 和 V
PER_TOKEN_ALL_LAYERS = PER_TOKEN_PER_LAYER * LAYERS

def kv_gb(ctx: int, batch: int, dtype_bytes: float) -> float:
    return PER_TOKEN_ALL_LAYERS * ctx * batch * dtype_bytes / 1024 ** 3

print(f"每 token 每层 KV 元素 {PER_TOKEN_PER_LAYER}；"
      f"×{LAYERS} 层 = 每 token {PER_TOKEN_ALL_LAYERS:,} 个元素")
print(f"{'上下文':>12} {'BF16(2B)':>11} {'FP8(1B)':>11} {'FP4(0.5B)':>11}")
for ctx in (128 * 1024, 256 * 1024, 512 * 1024, 1024 * 1024):
    cells = [f"{kv_gb(ctx, 1, b):.1f} GB" for b in (2.0, 1.0, 0.5)]
    print(f"{ctx:>10,}  {cells[0]:>11} {cells[1]:>11} {cells[2]:>11}")

每 token 每层 KV 元素 2048；×62 层 = 每 token 126,976 个元素
         上下文    BF16(2B)     FP8(1B)   FP4(0.5B)
   131,072      31.0 GB     15.5 GB      7.8 GB
   262,144      62.0 GB     31.0 GB     15.5 GB
   524,288     124.0 GB     62.0 GB     31.0 GB
 1,048,576     248.0 GB    124.0 GB     62.0 GB

这就是「1M 上下文」真正贵的地方：光是一条 1M token 的会话、batch=1、KV 存 BF16，就要额外 248 GB；量化到 FP8 也要 124 GB。上面那张预算表里，NVFP4 在 8 张 H100 上只剩 107 GB 余量——连一条 1M 会话的 FP8 KV 都放不满。所以自建这套东西时，--max-model-len 不是一个可以随手写 1048576 的参数，它是你账单上的主项之一。

起服务这块，官方 PyTorch 博客确认 SGLang 与 vLLM 已做优化支持，并对 NVIDIA、AMD、Intel 做了优化；PyTorch 侧用 Helion 出高性能算子，TorchTitan 开箱支持其 SFT 与 RL。启动命令大致长这样（作者推断：具体量化开关名以当期 vLLM / SGLang 文档为准，我没有 GPU 机器，这两条命令未经本机验证）：

# 门控仓库：先用已获批的账号登录，token 走环境变量，不要写进脚本
export HF_TOKEN="${HF_TOKEN:?请先在 HF 上提交门控表单并等待获批}"

# NVFP4：4 张 141GB 卡 / 2 台 512GB 统一内存机器可参照此形态
vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tensor-parallel-size 4 \
  --quantization modelopt \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.92

# SGLang 侧（同样写法）
python -m sglang.launch_server \
  --model-path meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tp-size 4 --context-length 262144 --mem-fraction-static 0.9

注意我把 --max-model-len 写成 262144 而不是官方上限的 1048576：按上面那张 KV 表，砍到 256K 能省下大约 186 GB（BF16 KV）或 93 GB（FP8 KV）——在很多机器上，这一刀就是从「装不下」到「装得下」的分界线。真正需要 1M 的场景，再把长度当独立配置去调。

另外，官方自述（属厂商自述）在基于 Muse Spark Open 的 Muse Code 上做了全本地 agentic 实测：给开源 Mastodon 客户端 Ice Cubes 提交真实 iOS 改动（修 bug、加功能、完整构建），以及端到端驱动 DaVinci Resolve（逐帧看素材挑高光并裁成竖版）。云侧同日上架的两个变体是 BF16 与 NVFP4（AWS SageMaker JumpStart，AWS 官方博客）；此外官方称权重同时上了 Google Cloud Model Garden 与 Microsoft Foundry（第三方报道）。

自己跑还是买 token#

作者实测：我拉了 OpenRouter 的模型列表（https://openrouter.ai/api/v1/models，当时共 465 个模型），meta/muse-spark-open 已经在列，上下文 1,048,576，价格 $1.25 / 百万输入、$4.25 / 百万输出。

关键是它和谁同价：闭源的 meta/muse-spark-1.2 与 meta/muse-spark-1.3 都是 $1.25 / $4.25，而 meta/muse-wonder 是 $4 / $20。

这组数字给出的结论很直接：开放权重当天就上了第三方 API，而且和自家闭源上一代同价。「免费下载」在这里是个陷阱——你要先付出 533 GB 起的存储、几十万到上百万级的硬件、以及运维时间，之后才轮到省 token 钱。判断标准很简单：如果你的月 token 账单还没到能买下一台 512GB 统一内存机器的量级，那 API 就是更划算的那条路。

第三方报道里还有一组厂商自报的分数：SiliconAngle 2026-10-15 转述 Meta 自家基准表，JobBench agent 测试 61.8，Thinking Machines Lab 的 Inkling 31.1、NVIDIA Nemotron 3 Ultra 27.2。我没取到原始表格，所以按「Meta 官方基准表（媒体转述）」对待。官方口径本身只提「cleared the release thresholds in its Meta Superintelligence Scaling Framework，完整评测报告稍后发布」——在完整报告出来之前，这组分数不该写进你的选型文档。

总结#

把这次发布拆成四句话：

1. 官方交付的是开放权重（open-weights），不是开源软件。 这个措辞的差别不是文字游戏——它后面挂着许可证、使用政策与署名义务。
2. 第一道门是流程，不是技术。 gated: manual 意味着你要先交表等审批；config.json 回 401 就是没放行的直接证据，别去怀疑自己的 token。
3. 第二道门是体积。 实测 BF16 1644.37 GB、NVFP4 533.04 GB。两处最重要的细节：真实张量数是 约 822.04B，比官方口径多 约 6.0B（作者推断来自多模态编码器，Meta 未说明）；NVFP4 也不是纯 4bit，还有约 48.8B 个参数留在 BF16。
4. 第三道门是 KV。 1M 上下文、batch=1、BF16 KV 就是 248 GB。这才是「本地跑前沿模型」账单上最容易漏掉的一项；先把 --max-model-len 砍到 256K，往往比换硬件划算。

至于许可证本身：可商用、可蒸馏、可再分发，Meta 不主张输出所有权——这份条款对开发者算相当宽松。真正要落到实处的是两条：把 Built with Muse Spark Open 写进你的 UI 与文档（蒸馏出来的模型也要），以及如果你的 MaaS 生意在任意连续 12 个月毛收入越过 2000 万美元，动手前先通知 Meta。

参考与致谢#

• Meta 官方博客：《Muse Spark Open》发布说明 — research.meta.ai/blog/muse-spark-open（官方定位、架构规格、1M 上下文、Muse Code 全本地实测）
• Hugging Face 官方博客：《Welcome Muse Spark Open》，Pedro Cuenca，2026-10-15（专家路由、层数、KV head 等结构表）
• PyTorch 官方博客：《Muse Spark Is Now an Open-Weights Model》，2026-10-15（SGLang / vLLM 支持、Helion、TorchTitan）
• 9to5Mac，2026-10-15（MLX 优化、M5 Ultra 每台 512 GB、1.2 TB/s 带宽、两台 Mac Studio 的表述，属第三方报道）
• AWS 官方博客（SageMaker JumpStart 同日上架 BF16 与 NVFP4 两个变体）；Google Cloud Model Garden、Microsoft Foundry 上架为第三方报道
• SiliconAngle，2026-10-15（转述 Meta 自家基准表：JobBench 61.8 / Inkling 31.1 / Nemotron 3 Ultra 27.2，第三方转述）
• The New Stack（「许可证并非完全开放」的说法，本文仅见转述，未核实原文）
• 模型仓库：huggingface.co/meta-models/Muse-Spark-Open-816B-A42B 与 ...-NVFP4；体量数字经 hf-mirror.com 的 ?blobs=true 元数据接口实测
• OpenRouter 模型列表（openrouter.ai/api/v1/models，挂牌价与上下文长度为本机实测）

披露：本文不含推广链接，与 Meta、Hugging Face、OpenRouter、Apple、AWS 均无利益关系。文中「作者实测」的数字可按下文命令在本机复现；启动命令未经我本机验证，请以当期推理引擎文档为准。写于 2026-10-16，仓库状态与挂牌价请以你阅读时的页面为准确。