先看证据
把机制串起来
MoE（混合专家）模型把参数分散到多个专家网络里，每个 token 只调用其中一小部分，因此计算量可以远小于模型总参数量。但推理时通常仍要把全部专家权重装进设备，42B 活跃参数不代表只需要存放 42B 参数。上下文越长，注意力的 KV 缓存通常越占显存，也会影响吞吐；分组查询注意力能压低缓存开销，但不能让百万 token 免费。
模型共有 816B 参数，但每个 token 通过路由从 256 个专家中选 8 个参与计算，活跃参数约 42B；这降低单 token 计算量，却不消除完整权重的存储需求。语言模型有 62 层、隐藏维度 8192，并采用 128 个查询头与 16 个 KV 头的分组查询注意力，以减少 KV 缓存相对开销。图像输入另由 1.8B 参数的视觉感知编码器处理；模型也接收视频和音频，但公开材料没有交代完整的多模态融合机制。NVFP4 量化降低权重体积，代价是量化精度与推理实现需要权衡
['先按量化方案核对显存：NVFP4建议约700GB', '双M5 Ultra是分布式部署，不是单机复现方案', '适合长流程工具调用；编码任务建议先做本地基准测试', '长上下文先测缓存、吞吐和成本，勿只看窗口上限']
权重开放，部署问题随之浮出水面
Meta Superintelligence Labs 于 2026 年 10 月 15 日发布 Muse Spark Open，将 Muse Spark 的开放权重版本交给开发者使用。它面向编码、多模态输入和长流程 Agent 工作，接受文本、图像、视频与音频输入，输出文本，并提供约 1M token 的上下文窗口。Meta 还称开放版本经过额外安全后训练。
这次发布的看点不只是“又一个大模型开放权重”，而是 Meta 同时给出了从数据中心到两台 Mac Studio 的运行路径。后者很容易被简化成“模型能在 Mac 上跑”，但它实际指两台高内存设备协同部署，不是普通用户在一台电脑上启动一个 816B 模型。开放的是权重和更多控制权，随之而来的硬件、运维与许可问题并没有消失。
42B 活跃参数，不代表只需容纳 42B
Muse Spark Open 是一个总计 816B 参数的混合专家模型。每个 token 会从 256 个专家中路由到 8 个，约有 42B 参数参与该 token 的计算。稀疏路由减少了单次计算所需调用的参数量，但服务时仍需把完整模型权重放进可用内存，因此“42B 活跃参数”不能直接换算成 42B 模型的部署成本。
这一区别在硬件数字上很明显。Meta 文档给出的 BF16 权重约为 1.65TB，NVFP4 版本约为 537GB，服务端建议分别准备约 2TB 和 700GB 的 VRAM。官方展示的桌面路径，是两台各有 512GB 统一内存的 M5 Ultra Mac Studio，通过 Thunderbolt 5/RDMA 连接，并由 MLX 将模型层切分到两台机器。它证明了特定配置下可以运行，不证明单机运行或低成本部署已经变得容易。
长上下文与多模态，仍要看任务如何落地
模型卡列出 62 层、8192 的隐藏维度，以及一个 1.8B 参数的视觉感知编码器；官方资料称它能接收图像、视频和音频。上下文上限为 1,048,576 token，给长文档处理、跨轮次任务状态保留等工作提供了空间。但窗口大小只是模型可接收的上限，不等于长上下文任务自然可靠，也不意味着输入这些内容没有显著的计算与内存代价。
对 Agent 系统而言，实际价值更可能来自工具调用和持续任务，而非单纯把更多文本塞进提示词。Meta 提供 low、medium、high、xhigh 四档 reasoning_effort，默认值为 xhigh，意味着调用方需要把推理深度作为延迟与资源预算的一部分来管理。材料没有给出各模态完整的编码、融合细节，也没有证明所有长流程、多模态任务都能从 1M 窗口中获得同等收益。
评测结果呈现的是强项与短板，而非总排名
现有对比中，Muse Spark Open 的亮点集中在工具使用和部分知识评测。MarkTechPost 引述的 MCP-Atlas 得分为 89.2，在 Meta 的对比表中领先；JobBench 为 61.8，略高于 GLM 5.3 的 61.4。AA Omniscience 得分 25，也被列为该表最高。它在 Terminal-Bench 2.1 上则为 76.4，低于所列 Kimi K3 的 85.0、GLM 5.3 的 83.9 和 Qwen3.8 的 82.0。
整体指标同样提醒读者不要把单项第一读成全面领先。材料所列 Artificial Analysis Intelligence Index 为 39，低于 GLM 5.3 的 45、Kimi K3 的 44 和 Qwen3.8 的 40。Meta 的评测方法说明，不同模型的结果来自排行榜、内部评测或模型提供方自报，且对比设置尽可能使用各模型的高推理强度；Meta 也指出自身的工具和系统提示未必针对第三方模型调优。因此，MCP-Atlas 的领先应限定在具体表格与设置之内，不能直接外推为所有开放模型中的通用排名。
选型时，把许可和运行成本一起算进去
工程团队的部署选择并不只有“本地”与“云端”两格。Meta 列出的路径包括 Blackwell Ultra 或 H200 服务器、两台高内存 Mac Studio，以及 Unsloth 的低比特 GGUF 配置；模型也可通过 SGLang、vLLM、TensorRT-LLM、Transformers、MLX、llama.cpp 和 Unsloth 等引擎运行。不同权重格式与引擎意味着不同的内存、吞吐和兼容性取舍，不能仅凭参数量或“能跑”来比较成本。托管 API 则可作为不自建硬件的路径，但会把控制权和成本结构转移到服务商一侧。
还要把开放权重与许可自由度分开看。所给许可说明允许使用、修改、微调、蒸馏、再分发和销售，也对规模较大的模型即服务业务设置条件：12 个月收入超过 2000 万美元时，需要与 Meta 签订协议，并须遵守 Usage Policy。对于负责人来说，合理的评估顺序是先用目标任务验证工具调用、编码和长上下文表现，再按权重格式核算完整部署资源，最后审查许可是否覆盖预期的产品与服务形态。若团队无法承担这些验证和运行条件，开放权重本身并不足以构成采用理由。