MAGI-2-preview 即将登陆 SGLang：新服务 PR 揭示了什么

MAGI-2-preview 是 Sand.ai 的 1140 亿参数混合专家视频生成模型，于 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 与 torchrun 配置迁移到主流服务运行时的人来说，这个 PR 就是一份详细的路线图。

所以请把这当作一篇"目前已知情况"的汇总，而不是发布说明。该模型是真实存在的，并且已经交付——那是在8月5日，权重托管在Hugging Face上，代码以Apache-2.0许可证发布在GitHub上。尚未得到验证的是服务（serving）部分：SGLang集成目前只是一个开放的拉取请求，其细节在评审过程中仍可能变化，在该PR合入之前，SGLang实际上无法运行MAGI-2-preview。价值在于这个PR所揭示的关于模型本身以及如何在真实运行时中运行它的路径。

本 PR 所针对的模型，用一段话描述。

MAGI-2-preview 是 Sand.ai 尝试以语言模型扩展的方式来扩展视频生成——即使用混合专家（MoE），并且它是开源 MAGI-1（2025年4月发布的 24B 自回归视频模型）的继任者。新模型总参数量约为 114B，但每个 token 仅激活约 6B 参数，采用超细粒度的多头 MoE：将 3,072 维的隐藏状态拆分为 12 个 256 维的头，每个头路由到 256 个专家中的 6 个，这样每个 MoE 层有 3,072 个专家单元，跨 36 层每个 token 激活 72 个专家。它是一个统一的单流音视频模型——文本、视频和音频通过同一个 Transformer，并在每一层通过自注意力交换信息，而不是通过单独的交叉注意力管道。它支持文本到视频和图像到视频，并生成 10 秒的片段——这是唯一支持的时长——同时在同一去噪轨迹中生成同步的立体声配乐，并将其封装进输出文件中。

生成过程分两个阶段。一个magi2_preview阶段在 512×896 下进行去噪，然后一个magi2_refiner阶段将分辨率提升到 1088×1920。基础版本使用 100 步预览去噪和 5 步精炼去噪；Sand.ai 表示，一个步骤少得多的蒸馏版本即将推出。检查点集是一个约 307 GB 的 Hugging Face 仓库：包括 228 GB 的预览阶段、一个 Qwen3.5-27B 文本编码器、14 GB 的精炼器、一个 5 GB 的音频 VAE、一个从 Wan2.2-TI2V-5B 借用的视频 VAE，以及默认使用的蒸馏 turbo VAE 解码器。硬件要求是八块 NVIDIA Hopper（H100 级）GPU，参考启动器允许你在各阶段之间将文本编码器、预览、精炼器和 VAE 在 CPU 和 GPU 之间卸载。

在性能方面，目前流传的数据均为报道转述，而非独立复现的结果。这些宣称——同一批中国媒体报道中VBench得分86.54%，领先Sora 2（84.37%）和Kling 2.0（84.20%）；在Artificial Analysis图生视频排行榜上位列第6，Elo约1106——全部来自厂商和发布报道，发布至今十一天内，没有任何独立第三方对这些数据做过实测。Sand.ai还表示，在八块H100上生成一段10秒1080p视频的推理成本约为0.5元（约合0.07美元），约为主流视频模型的十分之一。在有人实际测量之前，这些都只能视为厂商和媒体转述的数据。

为什么 serving pull request 才是真正的新闻

迄今为止，运行 MAGI-2-preview 只有一种受支持的方式：Sand.ai 自己的参考技术栈——一个 Docker 镜像外加 torchrun——部署在八块 NVIDIA Hopper H100 上。这是一条可行但高度定制化的路径：你会继承 Sand.ai 的启动器、它的卸载决策，以及它在内存层级之间分派文本编码器、preview、refiner 和 VAE 时那种固执己见的做法。一个为 SGLang 添加该模型的 pull request 之所以意义重大，是因为在自托管生成式 AI 领域中，相当大一部分实际生产部署使用的正是 SGLang 这个服务运行时。一流支持意味着 MAGI-2-preview 可以在主流运行时中运行，背后有 SGLang 的整套机制支撑——Ulysses 序列并行、专家并行、激活卸载、VAE、调度器，以及流水线阶段基础设施。这就是“我能在他们的技术栈上运行”与“我能在我团队已经在运营的技术栈上运行”之间的区别。

该 PR 实际构建的内容

该集成构建在现有的 SGLang 机制之上，而非参考的 torchrun 路径。该 PR 添加了多头 MoE 层、attention-sink 管道、用于精炼阶段的块窗口局部注意力，以及多流超连接——这些是通用层尚未表达的 MagiMoE 架构组件。围绕这些，它复用了 SGLang 现有的 Ulysses 序列并行、专家并行、卸载、VAE、调度器和流水线阶段组件。它还附带文档（针对 SGLang 扩散文档的 MAGI-2 食谱页面）和 47 个无需 GPU 的单元测试，这表明在不租用八块 H100 的情况下，模型行为有多少可以得到验证。

该 PR 还明确了模型的约束条件：

• 硬件 — 八块 NVIDIA Hopper H100，参考堆栈的 cpu / gpu / 往返卸载模式映射到文本编码器、预览器、精炼器和 VAE 在各阶段之间的位置。

• 并行 — --num-gpus 必须整除每个 head 轴，而 --tp-size、--ring-degree 和 --enable-cfg-parallel 会被拒绝。这个模型具有大量路由维度，并行布局必须与它们对齐。

• 输出 — 仅接受 1920×1088 和 896×512 分辨率，且仅限 10 秒片段；不支持 torch.compile。

如果你正在规划部署，最后一组值得读两遍：至少在早期集成中，这个模型锁定为两种分辨率和一种时长。

什么仍然未经验证

关于模型服务（serving）工作的全部内容。该 PR 目前处于开启状态，等待代码所有者（code owner）审核，截至 8 月 16 日 CI 检查仍在失败。如此规模的拉取请求可能会在审核中搁置数天甚至数周；目前没有合并状态，没有发布版本，SGLang 方面也没有任何公告。而模型侧的说法——VBench 分数、Artificial Analysis 排名、0.5 元的成本数字——均来自厂商和媒体报道，并未被独立复现。如果你今天基于这个 PR 构建工作流，你是在基于一份路线图（roadmap）构建，而不是基于一个可运行的实现（runtime）。

这对成本计算意味着什么

MAGI-2-preview 引起关注的原因在于其经济性。一个每个 token 激活 6B 参数、总容量达 114B 的模型，每条片段运行成本很低——Sand.ai 给出的数字是，在八块 H100 上生成一条 10 秒 1080p 片段约需 0.5 元——而正是这样的数字决定了小团队是否能够负担得起视频生成。但 0.5 元的前提是参考技术栈、H100 集群以及无服务开销。这类开放模型通常要变得广泛可用，靠的是托管 API：由他人托管、按片段定价，而你不需要租用八块 H100。

当存在托管路由时，路由角度就变得重要了。在路由平台上，供应商为MAGI-2-preview片段设定的标价就是您需要支付的价格——OrcaRouter以零加价传递供应商的标价，因此供应商降价在发布当天就会在我们这边生效，无需重新协商。而一个发布仅十一天、没有独立基准测试的开权重检查点，正是您希望放在自动故障转移背后的那种模型：将路由指向它进行评估，在同一端点上保留经过验证的回退方案，一旦早期检查点停滞或产生不可用的输出，调用就会故障转移，而不是让您的管道承担风险。这就是在不拿生产路径冒险的情况下试用未经验证模型的方式。

我们现在正在看的

• PR 是否合并，以及审查中有哪些变更。约束列表——两个分辨率、一个时长、不使用 torch.compile——可能不是最终版本。

• 蒸馏检查点。Sand.ai表示更少步数的权重即将推出；正是这一点，将0.5元这个数字从实验室测量值转变为实际每片段成本。

• 首批独立基准测试。VBench和排行榜数据由厂商和媒体报道；第三方运行将厘清6B激活参数的说法是否成立。

• 其他运行时是否会跟进。SGLang 是首个采用 MAGI-2-preview 的主流服务运行时；vLLM 及其他可能也紧随其后。

• 是否有托管 API 出现。该模式的整个卖点是规模化后的低成本；一旦存在托管路由，上述转嫁定价的计算随即生效。

坦率地说：MAGI-2-preview 是一个发布仅十一天的开源模型，其成本结构可能举足轻重，而 SGLang 的 PR 是迄今生态系统认真对待它的最明确信号。但服务端支持仍只是一份待合并的 PR，并非已交付的能力。应把路线图视为真实，把运行时视为尚未到位——当该模型真正通过正式 API 落地时，采用它的方式是故障转移优先，而不是把生产路径押注在一个无人独立基准测试过的检查点上。