Meta Muse Spark Open (816B-A42B) 完整解析：原生多模態 MoE 架構、百萬上下文、評測數據與本地部署指南

Meta Superintelligence Labs 於 2026 年 10 月 15 日正式釋出開放權重（Open-Weight）旗艦模型 Muse Spark Open（Hugging Face 權重代號為 meta-models/Muse-Spark-Open-816B-A42B）。官方將其定位為目前美國規模最大且能力領先的開放權重模型，專為長程代理工作流（Long-Horizon Agentic Workflows）、複雜軟體工程與多步驟深度推理所打造。

這款模型採用稀疏混合專家（Sparse Mixture-of-Experts, MoE）架構，具備 8,160 億（816B）總參數，在處理每個 Token 時僅激活約 420 億（42B）參數，並提供高達 100 萬（1M）Tokens 的上下文視窗。除了程式碼與文字處理外，Muse Spark Open 原生支援文字、圖片、音訊與影片四種模態輸入，讓開發者能透過單一模型同時閱讀大型程式碼庫、檢視螢幕截圖、聆聽語音備忘錄或分析螢幕錄影。

本文依據 Meta AI Research 官方發布部落格、Hugging Face 深度技術文章、Hugging Face 官方模型卡 以及 Meta 開發者技術部落格，完整整理 Muse Spark Open 的底層架構、多模態編碼設計、官方與第三方基準評測、Apple Silicon 桌面端部署方案、投機解碼加速與微調實戰指南。

核心架構拆解：816B 稀疏 MoE 與三大模態編碼器

根據 Hugging Face 深度技術文章 與 官方模型卡 公開的架構細節，Muse Spark Open 是 Muse 模型家族的完整尺寸版本（同系列於 2026 年 8 月釋出的 Muse Glimmer 30B 為針對本地端常駐任務設計的輕量稠密模型，兩者共用相同的分詞器與詞彙表）。

以下為 Muse Spark Open 的核心架構規格總覽：

1. 語言模型主幹與 256 專家 MoE 區塊

在語言模型主幹部分，Hugging Face 技術文章 指出 Muse Spark Open 包含 62 個 Transformer 層，隱藏層維度為 8,192。注意力區塊採用分組查詢注意力（GQA），配置 128 個查詢頭（Query Heads）與 16 個鍵值頭（Key-Value Heads），每個注意力頭維度為 64。為了確保大規模訓練與長序列推論的穩定度，注意力區塊加入了輸出門控（Output Gate）、輸出正規化層以及查詢與鍵正規化（QK-norm）。此外，每個區塊在合併輸入與輸出時，採用學習式殘差門控（Learned Residual Gate），取代傳統 Transformer 直接相加的殘差連接方式。

在前饋網路（FFN）設計上，Muse Spark Open 將稠密網路替換為稀疏混合專家（MoE）區塊：

• 高稀疏度專家配置：每個 MoE 層設有 256 個專家，路由器（Router）針對每個 Token 動態挑選 8 個專家參與運算。
• 獨立專家正規化：每個專家皆為將維度從 8,192 投影至 4,096 再還原回 8,192 的前饋網路，並在輸出端套用該專家專屬的正規化層。全部專家權重合計佔模型總參數量的 97%。
• 記憶體與推論速度特性：部署時需將全部 256 個專家載入記憶體（相當於 816B 模型的記憶體需求），但每個 Token 僅透過 8 個專家進行前向傳播，因此實際運算速度等同於 42B 規模的輕量模型。

2. 視覺與影片感知編碼器（Perception Encoder）

影像與影片影格透過一具 18 億（1.8B）參數的感知編碼器轉換為視覺 Tokens。該編碼器架構與 Muse Glimmer 30B 一致，包含 50 層網路、隱藏維度 1,536 與 16 個注意力頭，會將輸入影像切分為 14×14 的區塊（Patches），並產出 4,096 維度的特徵向量。位置資訊由學習式絕對位置編碼（Learned Absolute Embeddings）與二維旋轉位置編碼（2D RoPE）共同提供，FFN 層則採用 LayerNorm 與 GELU。為了兼顧視覺細節與運算效率，編碼器中僅每第 4 層與最後一層採用全注意力（Full Attention），其餘層皆採用因子為 4 的稀疏注意力（Sparse Attention）。

在處理影片輸入時，模型會將影片影格送入同一具感知編碼器，並結合音訊編碼器同步處理影片中的音軌（這是相較於僅支援純畫面的 Muse Glimmer 的重要升級）。處理器預設以 每秒 2 幀（2 FPS） 對影片進行下採樣（單支影片上限為 96 幀，開發者可透過 processor.video_processor.fps = 4.0 調高取樣率），並在影格之間自動穿插時間戳記文字（例如 "Time: 3.5s"），協助模型掌握事件發生的時間順序。

3. 卷積金字塔音訊編碼器（Audio Encoder）

針對語音與環境音效，Hugging Face 技術文章 說明 Muse Spark Open 內建專屬的音訊編碼器與音訊分詞器，並在對話模板中以 <|audio|> 標記音訊位置：

• 極精簡的 Token 轉換率：音訊塔接收 24 kHz 單聲道原始波形，自動將波形填補（Pad）至 1,920 個取樣點的整數倍，對應每 80 毫秒輸出 1 個音訊 Embedding。換算下來每秒音訊僅產生 12.5 個音訊 Tokens（一段 10 秒鐘的音訊僅佔用 125 個輸入 Tokens）。
• 四階段卷積金字塔結構：編碼器本體為卷積金字塔（Convolutional Pyramid），由四個階段依序組成，各階段的 Patch Sizes 分別為 [16, 6, 5, 4]。每個階段皆包含一個 Patch Embedder 與 2 個一維卷積區塊（Kernel Size 為 7、Stride 為 1）。在最後一個階段結束後，時間序列特徵會通過 RMSNorm → 線性投影（Linear Projection） → RMSNorm 區塊輸出至主幹網路。

4. 百萬 Token 上下文與 KV Cache 記憶體開銷

Muse Spark Open 在推論階段提供 1,000,000 Tokens 的上下文視窗（設定檔中 max_position_embeddings 為 1,048,576），文字、影像、影片與音訊 Tokens 皆共用同一個百萬級上下文空間。

受惠於分組查詢注意力（GQA，僅 16 個 KV Heads），如此龐大模型規模下的 KV Cache 體積依然維持在可控範圍：每個 Token 僅向快取新增 2 × 16 heads × 64 dimensions × 62 layers = 126,976 個數值。在 BF16 精度下，平均每個 Token 約佔用 250 KB，若將 100 萬 Tokens 的上下文視窗塞滿，KV Cache 總記憶體佔用約為 266 GB。

官方基準測試與第三方獨立評測表現

Hugging Face 官方模型卡 與 Meta AI Research 部落格 公布了 Muse Spark Open（設定為 xhigh 推理強度、temperature = 1.0、top_p = 1.0、top_k = disabled）與多款國內外大型開放權重模型的完整基準對照，對照模型包含 Inkling (xhigh)、Nemotron 3 Ultra (thinking on)、Beam、Mistral Large 4、Qwen3.8-2.4T-A95B (xhigh)、GLM 5.3 (max) 以及 Kimi K3 (max)。

1. 官方多維度基準測試對照表

從官方數據可以觀察到幾個明確趨勢：

• MCP 工具調用與知識精準度表現突出：在評估模型跨伺服器工具呼叫能力的 MCP-Atlas 上，Muse Spark Open 以 89.2 分居所有受測模型之冠，在評估真實職場任務的 JobBench（61.8 分） 同樣排名第一。在衡量知識準確度與低幻覺率的 AA Omniscience（25 分） 以及無工具輔助的 HLE-Diamond（26.1 分） 上，亦明顯領先總參數高達 2.4 兆的 Qwen3.8-2.4T-A95B 及 GLM 5.3。
• 多模態結合工具展現高實用性：由於模型在訓練階段即整合了感知編碼器與工具呼叫能力，在需要邊看圖邊呼叫工具處理的 ZeroBench（50.0 vs Kimi K3 的 41.0）、SimpleVQA（73.6） 以及直覺物理推理 IntPhys2（68.3） 皆取得領先。
• 早期企業用戶實測回饋：根據 Meta 開發者部落格 引述的早期測試回饋，Factory 技術人員 Zimu Li 指出該模型在生產環境代理工作流中能穩定選出正確的下一步工具，同時保持精簡扼要的回應。Ollama 工程團隊的 Dong Chen 則表示，該模型在多步驟與平行工具呼叫（Parallel Tool Calls）以及長上下文結構化輸出上表現穩定。

2. Artificial Analysis 獨立評測與 API 成本分析

根據第三方獨立評測機構 Artificial Analysis 的 Muse Spark Open 專頁 測試結果：

• 智慧指數排名：在涵蓋 10 項高難度評估的 Artificial Analysis Intelligence Index v4.3.2 中，Muse Spark Open (xhigh) 獲得 39 分（與 DeepSeek V4.1 Flash 同分，高於 Mistral Large 4 Preview 的 38 分，並大幅超越同級開放權重模型中位數的 19 分）。
• 推論速度與 Token 消耗量：平均輸出吞吐量達 130.7 tokens/s（同級中位數為 68 tokens/s）。跑完完整 Intelligence Index 評測共生成 1.1 億（110M）個輸出 Tokens，低於同級模型的 1.3 億中位數，印證其推理過程較為精煉、不盲目堆疊冗長思維鏈的特性。
• 雲端 API 定價：在 OpenRouter 平台 與首發推理夥伴上，標準定價為輸入每百萬 Tokens 1.25 美元、輸出每百萬 Tokens 4.25 美元（快取命中享 88% 折扣）。Artificial Analysis 估算其完成單項評測任務的加權平均成本為 0.84 美元（同級模型輸入中位數為 0.43 美元、輸出中位數為 1.68 美元，因此在開放權重模型中屬於單價較高的梯隊，但遠低於 Claude Opus 5.5 的 5.98 美元或 Muse Wonder 的 4.52 美元）。

硬體量化規格、Apple Silicon 桌面超算與投機解碼加速

為了讓 816B 規模的模型能在資料中心、工作站與個人電腦上順利運作，Meta 開發者部落格 宣布在發布首日即聯手 NVIDIA、AMD、Intel、Apple、Hugging Face 與 Unsloth 推出涵蓋多種精度與硬體平台的權重格式：

1. Apple Silicon 桌面端部署：雙機 M5 Ultra 叢集與單機 M3 Ultra 實測

Meta AI Research 部落格 將 Apple Silicon 列為本次發布的核心亮點。Apple 的統一記憶體架構讓配備 M5 Ultra 的 Mac Studio 單機即可讓整合式 GPU 存取高達 512 GB 的記憶體，並具備 1.2 TB/s 的記憶體頻寬。

• 雙機 Mac Studio (M5 Ultra) 組成 1 TB 桌面超級電腦：透過內建的 Thunderbolt 5 與 RDMA（遠端直接記憶體存取） 直接連接兩台 512 GB M5 Ultra Mac Studio（或四台 256 GB Mac Studio），即可合組出 1 TB 統一記憶體，完整容納 NVFP4 量化版本的 Muse Spark Open。搭配 MLX 張量平行（Tensor Parallelism），系統將每一層權重平均切分至兩台機器，推論時權重無須搬移，兩機之間僅需以微秒級延遲交換極小的中間運算結果。
• 本地端全自動代理實測案例：Meta 團隊在此雙機 Mac Studio 桌面環境上，在離線環境下運行由 Muse Spark Open 驅動的 Muse Code，成功為開源 iOS Mastodon 客戶端 Ice Cubes 完成錯誤修復、新功能開發與完整編譯打包。在另一項多模態測試中，模型在本地端直接控制專業剪輯軟體 DaVinci Resolve，逐幀檢視原始影片素材、挑選出最具張力的精彩片段，並自動完成直式短影音裁切與輸出。
• 單機 512 GB Mac Studio (M3 Ultra) 量化實測數據：若開發者手邊僅有單台 512 GB 的 Mac Studio（M3 Ultra），Hugging Face 技術文章 提供了兩組實測數據：
  1. 使用 oMLX 執行 oQ3e（3-bit）量化版：模型權重佔用約 344 GB 記憶體，保留充裕空間供 KV Cache 使用。在 1,024 tokens 提示詞與 128 tokens 輸出的測試下，預填充（Prefill）速度達 225 tokens/s，生成速度達 21 tokens/s。
  2. 使用 llama.cpp 執行 imatrix 校準之 Q2_K（2-bit）量化版：模型權重佔用 304 GB 記憶體，實測生成速度達到 18 tokens/s。

2. Helion GPU Kernels 與雙引擎投機解碼（DFlash V2 / DSpark）

在伺服器端 GPU 加速方面，Meta 開發者部落格 公布了三項底層效能優化：

1. 自動調優 Helion GPU Kernels：SGLang 與 PyTorch 整合了專屬的 Helion GPU 核心，無須手寫底層 CUDA 即可在 NVIDIA 與 AMD GPU 上帶來 1.03 至 3.95 倍的 Kernel 級加速，並在 AMD Instinct MI350 上實現 3% 的端到端推論加速。
2. SGLang 專用草稿模型 RadixArk/Muse-Spark-Open-DFlash2：由 RadixArk 基於 DFlash V2 打造，單次前向傳播可同時提出一整個區塊的候選 Tokens，並於單一 CUDA Graph 內完成草稿生成與輕量篩選。在 AMD MI355X 上，單路請求吞吐量提升 3.7 倍、16 併發請求提升 2.9 倍，平均每步可接受 6.4 個草稿 Tokens，且輸出準確度維持不變。
3. vLLM 專用草稿模型 Inferact/Muse-Spark-Open-DSpark：由 Inferact、NVIDIA 與 vLLM 團隊共同訓練，單次可提出最多 7 個候選 Tokens，並利用 Muse Spark Open 的滑動視窗注意力（Sliding-Window Attention），即使在 100 萬 Tokens 的長上下文中也能維持極低的驗證成本。此外，其適應性驗證（Adaptive Verification）機制會在伺服器高負載時自動減少檢查的草稿 Token 數量，避免高併發時投機解碼拖慢整體吞吞量。

本地部署、推論程式碼與 TRL 微調實戰指南

1. 推理強度控制（Reasoning Effort）與 Harmony 通道對話模板

在使用 Muse Spark Open 之前，開發者需留意其推理控制機制與對話模板特性：

• 強制開啟推理與四段強度調節：根據 Hugging Face 技術文章 與 官方模型卡，Muse Spark Open 無法關閉推理功能。開發者可透過 reasoning_effort 參數調整模型在回答前的思考深度，支援四個等級："low"、"medium"、"high" 與 "xhigh"（預設為 "xhigh"，處理器在底層會將這四個等級映射為整數 16、64、256 與 512，亦可直接在系統提示詞中加入 Reasoning strength: 1 等數值指令）。面對簡單任務時，建議設為 "low" 以節省 Token 消耗並縮短延遲，面對複雜程式開發與長程代理任務，則建議使用 "high" 或 "xhigh"。
• 官方推薦取樣參數：建議設定為 temperature = 1.0、top_p = 1.0、top_k = disabled。
• Harmony 多通道對話格式：模型採用基於通道（Channel-based）的 Harmony 對話模板，透過 to= 指定訊息接收對象：
  • to=self<|message|>...<|eom|>：模型內部的思考與推理軌跡。
  • to=commentary：工具呼叫前後向終端使用者展示的進度說明。
  • to=user<|message|>...<|eot|>：輸出給使用者的最終回答。
  • to=<tool_name>：當傳入工具定義時，模型會將接收端指向工具名稱，並在 <atem:function_calls> 標籤內以 <atem:invoke> 與 <atem:parameter> 產生結構化工具呼叫。

2. 使用 Hugging Face Transformers 進行多模態與工具呼叫推論

根據 Hugging Face 技術文章，Transformers 提供了 AutoModelForMultimodalLM 與 AutoProcessor，整合了文字分詞器、圖片/影片處理器、音訊特徵擷取器（需預先安裝 torchcodec、librosa 或 torchaudio 之一以支援自動重取樣至 24 kHz 單聲道）與對話模板。

以下為結合圖片輸入、推理強度設定與工具呼叫（Tool Calling）的完整 Python 範例：

from transformers import AutoProcessor, AutoModelForMultimodalLM, DistributedConfig

MODEL_ID = "meta-models/Muse-Spark-Open-816B-A42B"

# 若在多卡/多節點環境，可透過 DistributedConfig 設定張量平行 (tp_size) 與專家平行 (ep_size)
processor = AutoProcessor.from_pretrained(MODEL_ID)
model = AutoModelForMultimodalLM.from_pretrained(
    MODEL_ID,
    dtype="auto",
    device_map="auto"
)

# 定義可供模型呼叫的外部工具
tools = [
    {
        "type": "function",
        "function": {
            "name": "weather.get",
            "description": "Get the current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string"},
                },
                "required": ["city"],
            },
        },
    }
]

# 傳入圖片與文字提示詞（亦可傳入 type 為 "video" 或 "audio" 的多模態內容）
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "image": "https://huggingface.co/datasets/merve/vl-test-suite/resolve/main/SF.png"},
            {"type": "text", "text": "I am going to the city in this picture. What clothes should I wear?"},
        ],
    },
]

# 若輸入為包含音軌的影片，可加上 load_audio_from_video=True 與 return_metadata=True
inputs = processor.apply_chat_template(
    messages,
    tools=tools,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
    add_generation_prompt=True,
    reasoning_effort="high"  # 可選: low / medium / high / xhigh (預設為 xhigh)
).to(model.device).to(model.dtype)

input_len = inputs["input_ids"].shape[-1]
outputs = model.generate(**inputs, max_new_tokens=2000)

# 解析模型的推理軌跡、工具呼叫與最終回答
raw_completion = processor.decode(outputs[0][input_len:], skip_special_tokens=False)
parsed_response = processor.parse_response(outputs[0], prefix=inputs["input_ids"][0], tools=tools)
print(parsed_response)

3. 使用 SGLang 與 vLLM 部署高吞吐量 API 伺服器（含投機解碼）

根據 Meta 開發者部落格，在資料中心 GPU 環境下，可直接使用 SGLang（搭配 DFlash2 草稿模型）或 vLLM（搭配 DSpark 草稿模型）啟動相容於 OpenAI API 格式的推論服務：

# 方案 A：使用 SGLang 部署 NVFP4 權重並啟用 DFlash2 投機解碼（4 卡 Blackwell / H200）
sglang serve \
  --model-path meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tp-size 4 \
  --ep-size 4 \
  --quantization modelopt_fp4 \
  --moe-runner-backend flashinfer_trtllm \
  --mem-fraction-static 0.8 \
  --host 0.0.0.0 \
  --port 30000 \
  --enable-layernorm-sp \
  --enable-megamoe-for-layernorm-sp \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path RadixArk/Muse-Spark-Open-DFlash2 \
  --speculative-draft-attention-backend fa4 \
  --speculative-num-draft-tokens 8 \
  --mm-feature-transport cpu \
  --enable-hierarchical-cache \
  --hicache-size 200 \
  --reasoning-parser muse \
  --tool-call-parser muse

# 方案 B：使用 vLLM 部署 NVFP4 權重並啟用 DSpark 投機解碼與 1M 上下文
export VLLM_USE_RUST_FRONTEND=1
vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --max-model-len 1048576 \
  --reasoning-parser muse \
  --tool-call-parser muse \
  --enable-auto-tool-choice \
  --speculative-config '{"method":"dspark","model":"Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'

4. 本地端工作站啟動指令（llama.cpp、Unsloth、MLX 與 Docker）

針對擁有高記憶體 Mac Studio 或本地工作站的開發者，可透過單行指令快速拉取量化模型並啟動服務：

# 1. 使用 llama.cpp 啟動 2-bit 或 4-bit GGUF（啟動後可開啟 localhost:9931 內建 WebUI 傳送圖片與音訊）
curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q2_K

# 2. 使用 Unsloth 執行 2-bit Dynamic GGUF（約需 300 GB 系統 RAM + VRAM）
unsloth run --model unsloth/Muse-Spark-Open-816B-A42B-GGUF:UD-Q2_K_XL

# 3. 在 Apple Silicon Mac 上使用 mlx-lm 執行 3-bit oQ3e 量化模型
mlx_lm.generate --model mlx-community/Muse-Spark-Open-816B-A42B-oQ3e \
  --prompt "Explain convolutional networks like I am 5" \
  --max-tokens 5000

# 4. 使用 Hugging Face CLI 一鍵部署雲端 Inference Endpoints
hf endpoints catalog deploy --repo meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --name muse-spark

5. 後訓練與微調方案：使用 TRL SFTTrainer 進行 FSDP2 + EP LoRA 微調

針對需要微調模型的企業與研究團隊，Muse Spark Open 支援 PyTorch TorchTitan（含預訓練、多輪 SFT、LoRA 與強化學習）、SGLang Miles（支援將 Muon 與 Adam 優化器狀態卸載至 CPU 記憶體或 NVMe 進行全參數 RL）、NVIDIA NeMo AutoModel，以及 Fireworks AI（支援最高 262,144 tokens 序列長度的 Serverless LoRA）與 Together AI 的託管微調 API。

Hugging Face 技術文章 同時公開了在 8 個節點（共 64 張 H100 GPU） 上使用 TRL SFTTrainer 進行 LoRA 監督式微調的完整配方。該方案利用 DistributedConfig(fsdp_size=64, ep_size=8) 將模型以 FSDP2 切分至 64 張 GPU，並將每層的 256 個專家分為 8 組進行專家平行（Expert Parallelism）。微調時將全部 256 個專家保持凍結，僅針對注意力層的四個投影矩陣（q_proj、k_proj、v_proj、o_proj）訓練 LoRA 適配器：

import torch
from datasets import load_dataset
from peft import LoraConfig
from transformers.distributed import DistributedConfig
from trl import SFTConfig, SFTTrainer

train_dataset = load_dataset("allenai/tulu-3-sft-mixture", split="train[:500000]")

training_args = SFTConfig(
    output_dir="muse-spark-lora-sft",
    model_init_kwargs={
        "dtype": torch.bfloat16,
        "distributed_config": DistributedConfig(fsdp_size=64, ep_size=8)
    },
    per_device_train_batch_size=1,
    max_steps=500,
    max_length=2048,
    packing=True,          # 使用區塊對角遮罩將樣本緊密打包為 2048 tokens 序列
    save_only_model=True,  # 僅儲存 LoRA 適配器，不儲存分片後的優化器狀態
    logging_steps=1,
)

trainer = SFTTrainer(
    model="meta-models/Muse-Spark-Open-816B-A42B",
    args=training_args,
    train_dataset=train_dataset,
    peft_config=LoraConfig(
        r=16,
        lora_alpha=32,
        target_modules=["q_proj", "k_proj", "v_proj", "o_proj"]
    ),
)

trainer.train()

根據 Hugging Face 團隊實測，使用 torchrun --nnodes 8 --nproc_per_node 8 執行 500 步微調僅需約 2 小時，訓練吞吐量約為每秒 8,000 Tokens，平均 Token 準率由 72% 提升至 84%，Loss 則從 1.26 降至 0.57。

安全性評估與 Muse Model License 授權規範

1. 四大安全維度與抗越獄防護測試

由於開放權重模型可被開發者單獨部署於無外部防護欄的環境中，官方模型卡 指出 Muse Spark Open 接受了額外的安全後訓練（Safety Post-Training），並依據 Meta Superintelligence Scaling Framework 完成四大領域評估：

• 適應性越獄防護（StrongREJECT v2）：在面對適應性攻擊者的測試中，Muse Spark Open 的失守率僅 0.5%（越低越好），遠低於 Qwen3.8-2.4T 的 65.6%、GLM 5.3 的 62.9% 與 Kimi K3 的 66.6%。
• 網路安全（Cybersecurity）：在無系統級防護欄的情況下，模型在 Meta 內部網路安全基準上拒絕了 99.2% 的越獄請求，在 PolyGuard（網路安全子集）、RedCode 與 CyberBench 2024 的綜合測試中拒絕率達 94.8%（同環境下對照組 Kimi K3 分別為 75.5% 與 70.2%）。
• 化學與生物安全（Chemical and Biological）：在單輪 BioTIER 基準上拒絕超過 98% 的有害請求，內部單輪化學基準拒絕率超過 99%。在全新開發的多輪代理（Multi-turn Agentic）測試中，亦拒絕超過 97% 的有害生物請求與 98% 的有害化學請求。
• 失控與錯位風險（Loss of Control）：在衡量誠實度的 MASK 基準上取得 98.1% 的誠實率，並在 Agentic Misalignment（代理錯位）基準上測得 0% 的不當自主行為率。

同時，官方模型卡也提醒幾項實務限制：當輸入極短或低解析度的影片（例如僅數秒且短邊約 100 px）時，模型有時會回覆無法檢視該影片，建議提供較長片段並確保短邊解析度達 448 px 以上以獲得穩定結果。此外，針對面向終端用戶的代理應用，官方建議避免直接向用戶暴露原始思維鏈（Raw Chain-of-Thought），並在執行不可逆的真實世界操作前加入人工確認（Human-in-the-loop）機制。

2. Muse Model License 授權條款重點

根據 Hugging Face 儲存庫中的 LICENSE.md，Muse Spark Open 採用 Muse Model License（發布日期：2026 年 10 月 15 日），核心規範如下：

1. 免費使用、修改與衍生創作：授權人可免費使用、複製、修改（含微調）、建立衍生模型（包含蒸餾與合併）、發布及銷售模型副本，且 Meta 不主張模型生成輸出內容之所有權。
2. 顯著標示要求（Attribution）：任何使用本模型或衍生模型（包含透過模型輸出結果進行訓練或蒸餾的模型）之產品或服務，必須在使用者介面（UI）、隨附文件、網站或設定選單中顯著標示 "Built with Muse Spark Open"。
3. 模型即服務（MaaS）之 2,000 萬美元營收門檻：若被授權人或其關聯企業透過 API 或類似介面，將模型或衍生模型作為「模型即服務（Model as a Service, MaaS）」提供給第三方存取，且企業與關聯公司在連續 12 個月內的總營收（Aggregate Gross Revenue）超過 2,000 萬美元（US$20,000,000），則必須先向 Meta 取得獨立的書面商業授權協議。
4. 非 MaaS 商業用途不受營收門檻限制：授權條款第 3 條明確記載，上述 2,000 萬美元門檻不適用於企業內部使用、研究用途，或將模型作為自有產品或服務的功能元件（非對外提供 MaaS API 業務）。此外，使用者須遵守隨附的使用政策（Usage Policy），模型亦不適用於未滿 18 歲之個人。

常見問題（FAQ）

Q1：Muse Spark Open 與同系列的 Muse Glimmer、Muse Wonder 有何差別？

在 Meta 的 Muse 模型產品線中，Muse Glimmer 30B 是 2026 年 8 月開源的 300 億參數輕量稠密（Dense）代理模型，僅支援圖片與影片視覺編碼，適合在一般筆電或單機桌面端常駐執行。Muse Wonder 則是具備主動記憶（Active Memory）與主動焦點（Active Focus）的閉源旗艦模型。本次釋出的 Muse Spark Open 則是 816B 總參數、42B 激活參數的開放權重稀疏 MoE 模型，新增了音訊編碼器，完整支援文字、圖片、影片與音訊四種輸入模態與 100 萬 Tokens 上下文。

Q2：個人或中小型團隊沒有資料中心 GPU 叢集，該如何體驗或部署 Muse Spark Open？

若想在本地端運行，具備 512 GB 統一記憶體的 Apple Mac Studio（M3 Ultra 或 M5 Ultra）可透過 oMLX / mlx-lm 運行 3-bit oQ3e 量化版（約佔 344 GB，生成速度約 21 tokens/s），或透過 Unsloth Dynamic GGUF 與 llama.cpp 在具備約 300 GB 系統 RAM 與 VRAM 總和的工作站上運行 2-bit 版本。若無大記憶體硬體，可直接透過 Baseten、Fireworks AI、Groq、Modal、Nebius、OpenRouter 與 Together AI 等雲端 API 平台按量呼叫，或在 AWS SageMaker、Google Cloud Model Garden 與 Microsoft Foundry Models 中部署私有實例。

Q3：推論時可以關閉 Muse Spark Open 的思考（Reasoning）過程以節省費用嗎？

無法關閉。根據 Hugging Face 技術文章 說明，Muse Spark Open 為原生推理模型，不支援停用推理模式，且預設推理強度為最高的 "xhigh"。若希望在簡單任務中減少思考 Token 消耗並加快回應速度，請在呼叫 apply_chat_template 或 API 時將 reasoning_effort 明確設為 "low" 或 "medium"。

相關連結

• Meta AI Research 官方發布部落格：Introducing Muse Spark Open
• Hugging Face 官方深度技術部落格：Welcome Muse Spark Open
• Hugging Face 官方模型主頁與模型卡：meta-models/Muse-Spark-Open-816B-A42B