Muse Spark Open 解析：816B 權重開放，誰來承擔本機 Agent 的成本？（2026）

2026 年 10 月 15 日，Meta 在 AI Research 網站發布了〈Introducing Muse Spark Open, The Most Capable US Open‑Weight Model to Date〉，公開 Muse Spark Open 權重。這篇 Muse Spark Open 解析要追問的是：當模型可以搬回自己的機器，哪些控制權真的回來了，哪些成本與責任也一起搬了回來？

先看公告真正交出了什麼，再核對運行與授權條件，最後判斷這次開放對誰有用。最值得把握的變化，是你多了一條自行部署、修改與評估的路；至於值不值得走，要把模型、執行系統與實際任務放在同一張帳上。

Muse Spark Open 解析：816B、42B、1M，回答的是三個問題

We believe the future is for everyone

中文：我們相信，未來屬於每一個人。

Meta，Muse Spark Open 官方公告

這句話代表原文的訴求：讓進階模型更容易由開發者掌握。Hugging Face 的發布與整合說明列出約 816B 總參數、每個 token 約 42B 啟用參數、最高 1M tokens 上下文；輸入涵蓋文字、圖片、音訊與影片，輸出為文字。讀得懂影片，與生成影片，是不同能力。

把它想成一間有許多專家的事務所：816B 是整個組織的規模，42B 是處理當前一小段輸入時動用的部分，1M 則是這次工作能放進上下文的材料容量。這三個數字分別涉及儲存、運算與工作空間，不能互相代替。

All 256 experts stay in memory

中文：全部 256 個專家仍留在記憶體中。

Hugging Face，Muse Spark Open 整合說明

這是 MoE（混合專家）最容易被忽略的一面：每個 token 選用部分專家，能減少當下的運算，卻不會把其餘權重從部署需求中抹去。因此，不能拿「42B 啟用」直接套用一個 42B 密集模型的硬體清單。

兩台 Mac 的示範，背後是一套具體配置

原公告展示的桌面路線，使用兩台 M5 Ultra Mac Studio。Meta 的 Mac 部署指南把條件寫得更清楚：每台 512GB 統一記憶體，或採四台、每台 256GB 的組合；配合 MLX、Thunderbolt 5 與 RDMA，分散載入 NVFP4 權重。指南也列出 macOS 26.2、MLX 0.30.1 以上，以及每台機器存放完整 checkpoint 的磁碟需求。

兩台機器不是把兩個獨立聊天視窗排在一起，而是協作完成同一個模型的推論。統一記憶體讓 GPU 能使用較大的記憶體空間，跨機通訊則要把中間結果送到下一步；裝得下與等待時間，仍是兩個要分別量的問題。

Meta 開發者說明將 BF16 權重概略列為約 1.6TB，NVFP4 約 530GB。這是格式與權重體積的量級，還得加上上下文快取、暫存與執行框架；本機模型記憶體規劃能幫你把這幾筆空間分開。模型卡對其 GPU 部署路線列出 NVFP4 至少 700GB、BF16 約 2TB 顯存的要求；這些配置不能一概套到所有量化格式或 CPU／GPU 混合卸載方案。

同樣地，1M 上下文是容量上限的規格，不是每次請求都能以相同速度、成本和品質處理滿額內容的承諾。你真正需要知道的是：自己的程式庫與圖片放進去後，首個答案要等多久，整個任務完成要多久，記憶體還剩多少。

兩台 M5 Ultra 是原文主打配置，不能當作所有量化版本的最低門檻。Hugging Face 團隊另記錄了單台 M3 Ultra、512GB 記憶體使用 oQ3e 量化的測試，測試提示為 1,024 tokens、生成 128 tokens。這是發布合作方的有限測試，既提供另一條硬體路線，也不能用來推定滿額上下文或完整 Agent 的表現。

推論引擎跟上了，但「支援」仍要看到版本

這次發布的另一個重點，是權重之外的整合。Hugging Face整理了 Transformers、llama.cpp、SGLang、vLLM 與 MLX 等運行路徑；AWS 的上架說明也提供在自己帳戶內部署 BF16 或 NVFP4 端點的選項。開放帶來的是更多部署位置，並不代表一定要購買桌面硬體。

但 vLLM 團隊的發布日文章有一個很實際的註記：當時先提供專用預建容器；一般 nightly wheel 的可用性要等相關程式審查與合併。這足以提醒我們，發布頁列出框架名字，和你手上那個已安裝版本能否正確解析推理與工具呼叫，之間還有一段版本核對。

vLLM 目前的部署配方還把 AMD 指令範例限定為純文字，並說明影片路徑取用影格，音軌需要另行抽出、作為音訊輸入。這裡談的是該配方的實作範圍，不是模型整體缺少音訊能力。核對時要看所選後端、量化、輸入處理與上下文設定。

這也是完整生態比單一榜單更值得觀察的原因。權重、量化、工具呼叫解析器、分散式執行與部署文件一起交付，開發者才比較有機會把模型接到既有系統；任何一層接錯，都可能讓模型看起來像是不會用工具。

榜單、影片與加速數字，分別能證明多少？

上圖可以幫你定位原文的主張：它重視長任務與工具使用，而不只是問答。惟 Meta 的評測方法報告說明，表格混合官方榜單、內部測試與供應商自行報告的結果；部分程式任務還使用各模型偏好的 Harness。把這些分數排成一列，不會自動得到完全相同條件的比較。

同一張表裡，各欄領先的任務也有差異。公告標題中的美國開放權重模型定位，有其比較範圍；本文不把它擴張成全球所有任務都領先的結論。要採用它，應先找與你的任務接近的評測，再核對工具、推理設定、時間與成本預算。

原文另稱，Meta 用本機 Muse Code 完成 Ice Cubes 的 iOS 程式修改、建置，以及 DaVinci Resolve 的影片檢視與直式裁切。這些是 Meta 報告的工作流示範；本文未在該硬體上重跑，也不把示例轉寫成一般專案的成功率。示範回答「這條路跑得通嗎」，固定考題才更接近「我的工作能穩定交付嗎」。

公告還提到 Helion 核心最佳化，以及額外安全後訓練。核心運算的加速幅度，和完整服務從收到請求到交付結果的加速，是不同分母；Meta 報告通過自家發布門檻，也不等於下游接入任意工具後都通過安全驗收。這兩件事都值得肯定，但都要守住各自的測試範圍。

Muse Spark Open 授權：商用有條件，不能只讀 Open

Muse Model License允許使用、修改、微調、蒸餾及散布等行為，同時要求保留授權與使用政策，並在產品介面或相關文件等位置展示指定標示。它是一份自訂授權；下載得到權重，並未抹去這些義務。

其中最值得商業團隊看清楚的是第三條：若授權使用者或關係企業向第三方提供透過 API 等介面取得模型輸出的 Model-as-a-Service 業務，且使用者與關係企業合計總營收在任一連續十二個月超過 2,000 萬美元，將此模型或衍生物納入該業務前，須通知 Meta 並另簽書面協議。

條文明列內部使用、研究、其他非 Model-as-a-Service 商業活動，以及用模型驅動自身非此類服務產品功能的例外。所以，不能把它縮寫成「公司營收一過門檻就全面禁止商用」。反過來，自己的服務是否落在定義內，也應在部署決策時釐清，而不是上線之後才讀授權。

AlphaLab 的判讀：控制權回來了，驗收也回來了

一、我同意：可自行運行，本身就是有價值的選擇

權重可取得，讓團隊有機會固定模型版本、選擇部署位置、調整系統與研究失敗原因。這種可控制性，即使沒有每一項評測都第一，也可能值得投入。真正的價值，是你能不能用這些選擇解決一個原本受制於外部服務的問題。

二、我存疑：桌面能跑，是否就值得把服務搬回來？

如果每天只做少量任務，大型本機配置的閒置時間、維運與升級，可能吃掉你以為省下的費用；若已有持續工作量、資料處理邊界與工程能力，帳就可能不同。比較時，分母應該是「驗收通過的任務數」，再把硬體、電力、工程時間、失敗重試與服務費一起計入。

三、長上下文與多模態，應換成能判分的任務

拿一個多檔案修補、一段附有畫面的錯誤回報、一個需要中途失敗後恢復的工具任務，分別設驗收條件。讓現有方法與候選模型用同一份資料、工具與時間預算作答，記錄完整耗時、修改是否正確與重試次數。這比把長度上限或參數規模直接當成生產力，更接近採用問題；AI Evals 入門可以幫你把考題、分母與判分方式固定。

四、本機部署，把資料邊界和操作權限分開處理

模型卡的安全與限制說明建議依應用加上系統層防護，並提醒工具整合與後續修改會改變風險。即使推論留在自己的機器，Agent 仍可能透過瀏覽器、套件下載或外部 API 傳出資料。先畫清資料流，再限制可讀檔案、可寫目錄與工具動作；第一次試用可丟棄的工作副本，讓它交出修補供驗收。

下一步：先選一個任務，再決定模型應該住哪裡

一般讀者可以從原公告與公開選例，觀察它到底讀了什麼、用了哪些工具、最後交出什麼。已有授權帳戶或相容硬體的團隊，可先用同一組小型任務比較現有方案；暫時沒有條件的讀者，先把驗收考題寫好，也比先下硬體訂單更有用。

這次 Muse Spark Open 解析的結論是：開放權重擴大了選擇，但好選擇應該能說明自己的代價。往後值得追蹤的，是公開可重跑的完整任務證據、量化後的品質與記憶體取捨、部署版本成熟度，以及實際商業情境的授權適配。模型搬回來之前，先讓這四件事有答案。