AREX Feed Article
Meta 发布开放权重模型 Muse Spark Open：816B 参数、1M 上下文，Unsloth 2-bit 量化版称可在 Mac Studio 运行
Meta 于 10 月 15 日发布开放权重模型 Muse Spark Open：总参数 816B、每个词元激活约 42B 的稀疏混合专家（MoE）模型，接受文本、图像、视频与音频输入，输出文本，上下文窗口 1M token。权重已挂在 Hugging Face 的 下，模型卡标注发布日期为 2026 年 10 月 15 日，许可证为 Muse Model License；的开篇写道：「今天我们发布 Muse Spark Open，Muse Spark 的开放权重版本。」
发布同日，本地 AI 工具团队 Unsloth AI 在 X 上发帖：这条发布于协调世界时 10 月 15 日 17 时 45 分（北京时间 16 日凌晨 1 时 45 分）的称，Muse-Spark-Open-816B-A42B 的 Dynamic 2-bit GGUF（llama.cpp 生态的单文件量化权重格式）版本「可在 Mac Studio 上运行」，并称该模型为「新的 SOTA 开放模型」。作为参照，按 Meta 模型卡，部署原生权重需要至少 700GB 显存（NVFP4）或 2TB（BF16）；Unsloth 的最小 2-bit 量化把这道门槛写到了 256GB 统一内存。
推文、模型卡与开发者博客拼出的发布链条
推文附带的两个链接分别指向 和 Unsloth 的，前者收录各档 GGUF 量化，后者给出从下载到运行的完整步骤。GGUF 仓库的模型卡署名作者为 Meta Superintelligence Labs，页面顶部写着「阅读我们的 Muse Spark Open 运行指南」。
Meta 开发者博客这样描述模型用途：Muse Spark Open 为 agentic（智能体式）工作训练，可以「读大型代码库、规划改动、调用工具、检查结果，并在某一步失败时自我纠正」。博客列出的发布日支持覆盖 SGLang、vLLM、TensorRT-LLM、Hugging Face Transformers、MLX、llama.cpp 与 Unsloth，称已在 NVIDIA、AMD、Intel 与 Apple 芯片上验证；量化精度清单里，Meta 提供 BF16 与 NVFP4，AMD 提供 FP8 与 MXFP4，Intel 提供 INT4 与 MXFP4，Unsloth 提供 GGUF 量化。Unsloth 指南中则写明：「感谢 Meta 为 Unsloth 提供 day-zero 访问。」
截至 10 月 16 日发稿核验，meta-models 仓库页面显示 69 个点赞、累计 402 次下载。
模型卡写明的规格：256 个专家取 8 个，词表 202,048
按模型卡，Muse Spark Open 是带感知编码器（Perception Encoder）的 MoE Transformer：语言模型共 62 层、隐藏维度 8192，注意力采用分组查询注意力（GQA），128 个查询头对应 16 个 KV 头；MoE 部分共 256 个专家，每个词元按 top-k 路由激活 8 个，816B 总参数、约 42B 激活的口径由此而来。多模态输入由一个 1.8B 参数、50 层、按 14×14 图块（patch）切分的感知编码器处理。词表规模 202,048，输入与输出嵌入不共享。
推理时上下文长度 1M token，Unsloth 指南写明最大值为 1,048,576。训练数据覆盖文本、图像、音频与视频，来自 100 种以上语言。Meta 推荐的采样参数是 temperature 1.0、top_p 1.0、top_k 禁用；模型支持 low、medium、high、xhigh 四档 reasoning effort（控制模型作答前思考量的参数），默认 xhigh，官方建议复杂解题、编码与 agentic 任务使用 high 或 xhigh。
这次开放的是经过额外安全后训练的版本，模型卡的表述是：让它「在缺乏系统级护栏独立运行时更能抵御滥用」，Meta 同时建议把它部署在带有针对性护栏的更大系统中。许可证为 Muse Model License，模型注明不得用于违反适用法律（包括贸易合规法）的用途，且不面向 18 岁以下人群提供下载或使用。
Meta 给出的部署路径：托管端点与 Mac Studio 上的 MLX
自建部署之外，发布日就有一批托管端点可接：Baseten、Fireworks AI、Groq（有限预览）、Modal、Nebius、OpenRouter、Together AI；云厂商模型目录也同步上架，包括 AWS SageMaker、Google Cloud Model Garden 与 Microsoft Foundry Models。按博客的说法，这类端点让团队可以先评估模型，再决定投入哪套硬件。
博客给出的 Apple 硬件配置为：MLX 已支持 NVFP4 权重推理，可部署在两台各配 512GB 统一内存的 M5 Ultra Mac Studio 上，或者四台 256GB 的 Mac Studio（合计 1TB 统一内存），机器之间用 Thunderbolt 5 直连并启用 RDMA（远程直接内存访问）。MoE 架构配合 MLX 张量并行：以两台机型为例，每一层拆到两台机器上，每台持有并计算一半权重，「权重不移动，只有小的中间结果在两台机器之间以微秒级往返」。博客对这套配置的总结是「运行在桌面上的最强美国开放权重模型」。
博客还刊出了两位早期用户的反馈：Factory 技术成员 Zimu Li 称模型「能持续选对下一个工具，并保持响应紧凑，这正是生产级 agent 需要的决断力」；Ollama 工程团队的 Dong Chen 称它「在工具调用和长上下文上表现尤其好，包括多步与并行调用，结构化输出很干净」。两位用户由 Meta 挑选刊出，属于发布方呈现的材料。
「SOTA」之名对照 Meta 自己的基准表
「新的 SOTA 开放模型」是 Unsloth 推文里的表述；而 Unsloth 自己的另外两份页面文本（GGUF 仓库模型卡与运行指南）没有沿用这个说法，给出的都是内存门槛、量化精度基准与运行步骤。Meta 提供的对照数据由自己测试：全部基准以 xhigh reasoning effort、temperature 1.0、top_p 1.0、top_k 禁用运行，对比对象按模型卡的说法是「其他领先的开放权重模型」，包括 Inkling、Nemotron 3 Ultra、Beam、Mistral Large 4、Qwen3.8-2.4T-A95B、GLM 5.3 与 Kimi K3，其中 Beam 与 Mistral Large 4 在多项上没有数据。
领先项集中在 agentic、多模态与安全：MCP-Atlas 89.2，比次高的 Qwen3.8-2.4T-A95B（84.5）高 4.7 分；无工具 HLE-Diamond 26.1，对照组最高 22.2；带工具 ZeroBench 50.0，Kimi K3 为 41.0；SimpleVQA 73.6、IntPhys2 68.3 也都是表内最高。安全两项差距更大：StrongREJECT v2 自适应攻击的有害响应率 0.5（越低越好），对照组为 62.9～86.4；FORTRESS 静态攻击 ARS 5.8，对照组 21.6～28.2。模型卡另附自测安全数据：在无系统护栏、以开发者方式查询的设定下，模型拒绝 99.2% 的内部基准越狱，跨 PolyGuard（网络子集）、RedCode 与 CyberBench 2024 的合并口径为 94.8%，同设定下 Kimi K3 分别为 75.5% 和 70.2%。
落后项集中在综合与编码：Artificial Analysis Intelligence Index 得分 39，低于 GLM 5.3 的 45 和 Kimi K3 的 44；GPQA Diamond 89.0，低于 Qwen3.8-2.4T-A95B 与 Kimi K3 的 93.5；Terminal-Bench 2.1 得分 76.4，低于 Kimi K3 的 85.0；GDPVal-AA v2 得分 1,401，低于 GLM 5.3 的 1,653。Meta 自己的最高级表述同样带着限定：「最强」前面是「美国开放权重模型」。
Unsloth 的量化账本与两条运行路径
Unsloth 指南给出的压缩起点是：BF16 语言模型权重约 1.63TB，未计运行开销。其 Dynamic 3.0 系列量化后的内存需求（系统内存加显存，或统一内存）如下：
| 量化档 | 内存需求 |
|---|---|
| 1-bit | 180～212GB |
| 2-bit | 250～316GB |
| 3-bit | 346～410GB |
| 4-bit | 512GB |
| 6-bit | 640GB |
| 8-bit | 870～950GB |
指南写明，2-bit 档的 UD-IQ2_XXS「可装入 256GB 内存」，8-bit 则需要约 900GB。Meta 开发者博客对这条路线的描述是：Dynamic GGUFs 把模型「压缩到低至 2-bit，最小版本可装进约 300GB 的系统内存加显存，或 Apple 芯片上的统一内存」。约 300GB 与 256GB 两个口径并不矛盾，都落在 Unsloth 给出的 2-bit 档 250～316GB 区间内。
运行路径有两条：用 Unsloth Desktop（支持 macOS、Windows 与 Linux，底层调用 llama.cpp，显存不足时把层卸载到系统内存），或直接用 llama.cpp。指南给出的启动命令是：
unsloth run --model unsloth/Muse-Spark-Open-816B-A42B-GGUF:UD-IQ2_XXS直接用 llama.cpp 的用户需要注意：从 main 分支构建需要 llama.cpp 的 30616 号 pull request 先行合并，否则要用 Unsloth 维护的预编译版本；Apple 设备上 Metal 支持默认开启。指南同时提醒，内存不足时 llama.cpp 可以把部分权重放到磁盘上，代价是生成速度变慢；上下文越长，内存占用越高。
量化的代价：通用任务在 UD-IQ2_S 以下开始退化
Unsloth 用 KLD（KL 散度，衡量量化模型与原模型输出分布的差异，越低越好）给自家量化打分：UD-Q4_K_XL 的 KLD 很小，Q3_K_XL 也「相当合理」。按 top-1% 准确率口径，低于 UD-IQ2_S 的量化在通用任务上开始退化，因此官方建议 agentic 任务至少从 UD-IQ2_S 用起；聊天类任务即使用最小档也「没有问题」。
指南的两张基准图把代价画得很直观：磁盘占用约 225GB 的 IQ2_XXS，通用任务 top-1 准确率约 85.7%、聊天任务约 94.3%；磁盘约 510GB 的 Q4_K_XL 两项分别约 97.2% 与 98.2%。从 IQ2_XXS 到 Q4_K_XL，聊天曲线抬升约 4 个百分点，通用曲线接近 12 个百分点，通用能力受量化影响明显更大，与指南文字的判断一致。
Meta 模型卡的限制条款同样提醒：与全精度相比，量化推理「在边界场景可能出现轻微质量差异」。
把这些数字拼起来，「可在 Mac Studio 上运行」成立的具体形态是：装进 256GB 统一内存的是最小的 UD-IQ2_XXS，按 Unsloth 的建议适合聊天类任务；做 agentic 任务至少要 UD-IQ2_S，而指南没有单独给出这一档的内存数字。至于精度，文中的两份数据都出自发布方：Unsloth 的自测 KLD 曲线，以及 Meta 模型卡的边界提醒。