MAGI-2-preview 即將登陸 SGLang：新的 serving PR 揭示了什麼

MAGI-2-preview 是 Sand.ai 的 1140 億參數混合專家（mixture-of-experts）影片生成模型，於 2026 年 8 月 5 日開源——十一天後，出現了第一個跡象，顯示它即將獲得生產級服務基礎設施。8 月 16 日，SGLang 儲存庫中開啟了一個標題為[diffusion][Model] Support MAGI-2-preview的拉取請求（sgl-project/sglang，PR #35014），這個標題名副其實：它將該模型的原生服務支援接入 SGLang 的擴散技術棧。截至撰寫本文時，它仍然只是一個拉取請求——處於開啟狀態，等待程式碼擁有者審查，且 CI 檢查未通過。目前尚無任何合併，因此還無法提供服務。但對於任何正在評估 MAGI-2-preview 能否脫離 Sand.ai 的參考 Docker-and-torchrun 設定、轉移到主流服務執行環境的人來說，這個 PR 是一份詳細的路線圖。

所以請把這篇當作「目前已知資訊」的彙整，而不是發布說明。這個模型是真實存在且已推出的——發布時間是8月5日，權重在 Hugging Face 上、程式碼在 GitHub 上，以 Apache-2.0 授權釋出。尚未證實的是推論服務（serving）的部分：SGLang 整合目前只是一筆開放的 pull request，細節可能在審查過程中有所變動，而且在它正式合併之前，SGLang 實際上無法執行 MAGI-2-preview。這筆 PR 的價值在於，它揭示了這個模型的相關資訊，以及讓它在真實執行環境中運行的方法。

此 PR 所針對的模型，以一段話描述。

MAGI-2-preview 是 Sand.ai 嘗試仿照語言模型的擴展方式——也就是混合專家（MoE）——來擴展影片生成的作品，同時也是開源 MAGI-1（2025 年 4 月推出的 24B 自迴歸影片模型）的後繼者。新模型總參數量約為 114B，但每個 token 僅激活約 6B 參數，採用超細粒度的多頭 MoE：3,072 維的隱藏狀態被拆分為十二個 256 維的頭，每個頭路由到 256 個專家中的六個，相當於每個 MoE 層有 3,072 個專家單元，在 36 層中每個 token 激活 72 個專家。它是一個統一的單一資料流音訊-影片模型——文字、影片和音訊通過同一個 transformer，並在每一層透過自注意力交換資訊，而不是透過獨立的交叉注意力管線。它支援文字轉影片和圖片轉影片，並生成 10 秒片段——這是唯一支援的時長——同時在相同的去噪軌跡中生成同步的立體聲音軌，並將其封裝到輸出檔案中。

生成過程分兩個階段執行。magi2_preview 階段會以 512×896 解析度去噪，接著 magi2_refiner 階段會將輸出放大至 1088×1920。基礎版本使用 100 步的 preview 去噪與 5 步的 refiner 去噪；Sand.ai 表示即將推出步驟數大幅減少的蒸餾版本。檢查點集合是單一 Hugging Face 儲存庫，大小約 307 GB：包含 228 GB 的 preview 階段、Qwen3.5-27B 文字編碼器、14 GB 的 refiner、5 GB 的音訊 VAE、取自 Wan2.2-TI2V-5B 的影片 VAE，以及預設使用的蒸餾 turbo VAE 解碼器。硬體需求為八張 NVIDIA Hopper（H100 等級）GPU，參考啟動器可讓您在各階段中將文字編碼器、preview、refiner 與 VAE 在 CPU 和 GPU 之間卸載。

關於效能表現，流傳的數字皆為通報所得，未經獨立複測。這些宣稱——在中國媒體報導中，VBench 得分 86.54%，領先 Sora 2（84.37%）與 Kling 2.0（84.20%）；並在 Artificial Analysis 的圖生影片排行榜上排名第 6，Elo 約 1106——皆來自廠商與發布報導，且自發布以來十一天內，沒有任何獨立第三方進行過測試。Sand.ai 亦引用推論成本約每段 10 秒 1080p 影片 0.5 元人民幣（約 0.07 美元），使用八張 H100，約為主流水準影片模型的十分之一。在有人實際量測之前，請將上述一切視為廠商與媒體通報的數據。

為何一個提供服務的 pull request 才是真正的新聞

截至目前，執行 MAGI-2-preview 只有一種官方支援的方式：Sand.ai 自家的參考技術棧，也就是 Docker 映像檔加上 torchrun，運行於八張 NVIDIA Hopper H100 上。這是一條可行但特製的路徑——你繼承了 Sand.ai 的啟動器、其 offload 卸載決策，以及它在不同記憶體層級之間暫存文字編碼器、preview、refiner 和 VAE 的專斷方式。一個將該模型加入 SGLang 的 pull request 之所以重要，是因為 SGLang 是自托管生成式 AI 世界中，很大一部分實際上在生產環境部署所用的服務運行時。取得一流支援，意味著 MAGI-2-preview 可以在主流運行時中執行，並有 SGLang 的機制在背後支撐——Ulysses 序列並行、專家並行、激活卸載、VAE、調度器，以及管線階段基礎設施。這就是「我可以在他們的技術棧上運行它」與「我可以在我的團隊已經在營運的技術棧上運行它」之間的差異。

這個 PR 實際建置的內容

該整合建立在既有的 SGLang 機制之上，而非參考 torchrun 路徑。此 PR 新增了多頭 MoE 層、attention-sink 管道、用於 refiner 階段的區塊視窗局部注意力，以及多串流超連線——這些是 MagiMoE 中泛用層無法直接表達的架構組件。在這些組件之外，它重用了 SGLang 既有的 Ulysses 序列並行、專家並行、offload、VAE、排程器與管線階段元件。它也附帶文件（SGLang 擴散文件中的 MAGI-2 cookbook 頁面）與 47 個無需 GPU 的單元測試，這是一個好跡象，顯示模型行為中有多少部分可以在不租用八張 H100 的情況下驗證。

該 PR 也明確說明了模型的約束條件：

• 硬體 — 八張 NVIDIA Hopper H100，參考堆疊的 CPU / GPU / 往返卸載模式對應到文字編碼器、預覽器、精煉器與 VAE 在各階段之間的位置。

• 並行 — --num-gpus 必須整除每個頭軸，而 --tp-size、--ring-degree，以及 --enable-cfg-parallel 會被拒絕。這是一個具有許多路由維度的模型，並行配置必須與它們對齊。

• 輸出 — 僅接受 1920×1088 和 896×512 解析度，且僅限 10 秒片段；不支援 torch.compile。

如果你正在規劃部署，最後那一組值得讀兩遍：這是一個至少在目前早期整合階段，鎖定於兩種解析度和一種時長的模型。

什麼仍未經證實

關於 serving 工作的一切。這個 PR 目前是開啟狀態，正等待 code-owner 審查，而截至 8 月 16 日 CI 檢查仍未通過。如此規模的 pull request 可能在審查階段擱置數天甚至數週；目前既沒有 merged 狀態，也沒有 release，SGLang 方面更沒有任何公告。至於模型端的宣稱——VBench 分數、Artificial Analysis 排名、0.5 元的成本數字——都是廠商與媒體所報導，並非經獨立重現驗證。如果你今天要基於這個 PR 建立工作流程，你其實是建立在路線圖上，而不是建立在可運行的 runtime 上。

這對成本計算意味著什麼

{{1}}MAGI-2-preview{{/1}} 之所以引起關注，在於其經濟性。一個每次 token 啟動 {{2}}6B 參數{{/2}}、同時承載 {{3}}114B{{/3}} 容量的模型，每段影片的運行成本很低——Sand.ai 給出的數字是：在八張 H100 上，每段 {{5}}10 秒 1080p 影片{{/5}} 約 {{4}}0.5 元人民幣{{/4}}——而這種數字正是決定小型團隊是否負擔得起影片生成的關鍵。但這 {{6}}0.5 元人民幣{{/6}} 的估算假設了參考架構、H100 叢集，且不含服務開銷。像這樣的開源模型通常要能廣泛使用，靠的是受管 API：由他人代管、按段計價，你就不需要租八張 H100。

當託管路由存在時，路由的角度就變得重要。在路由平台上，供應商為 MAGI-2-preview 剪輯設定什麼牌價，你就支付什麼——OrcaRouter 以零加價傳遞供應商牌價，因此供應商降價當天就會在我們這邊生效，無需重新談判。而一個發布僅十一天、沒有獨立基準測試的開放權重檢查點，正是你希望放在自動故障轉移後面的那種模型：將路由指向它進行評估，在同一端點上保留經過驗證的後備方案；一旦早期檢查點停滯或產生不可用的內容，呼叫就會故障轉移，而不是你的管道。這就是在不將生產路徑押注在未經驗證模型上的情況下試用它的方式。

我們現在正在觀看的內容

• PR 是否合併，以及審查中有哪些變更。約束清單 — 兩種解析度、一個持續時間、不使用 torch.compile — 可能並非最終版本。

• 蒸餾檢查點。Sand.ai 表示更少步數的權重即將推出；這正是將 0.5 元的數字從實驗室測量轉化為實際每片段成本的關鍵。

• 首個獨立基準測試。VBench 與排行榜數據為廠商及媒體所報導；第三方實際執行將可驗證「6B 活躍」的主張是否成立。

• 其他 runtime 是否也會跟進。SGLang 是第一個採用 MAGI-2-preview 的主要 serving runtime；vLLM 及其他 runtime 可能不久後也會跟進。

• 是否出現受管 API。該模型的整體賣點是大規模低成本；一旦存在託管路線，上述的轉嫁定價計算就會生效。

老實說：MAGI-2-preview 是一個發布僅十一天的開放模型，其成本結構可能值得關注，而 SGLang 的 PR 是目前最明確的訊號，顯示生態系正在認真看待它。但服務支援目前是一份待合併的 pull request，而非已發布的功能。請把路線圖視為真實存在，但把執行環境視為尚未到位——而當這個模型真正透過正式 API 上線時，採用它的方式就是「故障轉移優先」，如此一來，你就不必把生產路徑押在一個尚未被任何人獨立基準測試過的檢查點上。