AREX Feed Article
NVIDIA 团队开源 Sol-H3 的 DGX Spark 版本：称约 56 秒生成 5 秒 768p 视频与立体声音频
9 月 11 日，NVIDIA 的 Enze Xie 开源发布 Sol-H3 的 DGX Spark 版本（Apache 2.0）。按其自报的数字，在单台 NVIDIA DGX Spark（GB10）上，这套方案用约 56 秒的「热端到端」（hot E2E）生成 5 秒 1,344×768、24 FPS 的视频并带立体声音频；在 8×B300 上完成同样 5 秒规格的生成，用时约 1.65 秒。
Sol-H3 属于推理效率方向的工程发布。它把 MiniMax-H3 的权重、FastH3 的四步草稿模型与 Lightricks 的 LTX-2.5 精修器组织成一条两阶段管线：先出 384p 草稿，再把潜变量直接送去精修出 768p。的署名是 NVIDIA Research 的 Efficient AI Team 与 Singapore Lab；核心贡献者是 Haopeng Li、Junsong Chen、Yitong Li、Jincheng Yu、Jingyu Xin、Haocheng Xi、Song Han 与 Enze Xie。
计时口径：「热端到端」与 6.7 倍加速
项目页把这次结果概括为「不到一分钟」：该时长对文本到视频音频（T2VA）与首尾帧（FL2VA）都适用，参考图生成（Ref2VA）因需要更多 token（词元）而略慢。同一负载下列了三档对比：四步 LoRA（低秩适配）374 秒，四步 LoRA 加量化 153 秒，Sol-H3 56 秒；页面给 Sol-H3 标出的加速是 6.7 倍。Xie 在推文里这样描述两版的差别：「服务器版是实时的。边缘端一台机器，不到一分钟。」
Xie 把这 56 秒的计时称为「热端到端」：从编码开始，经过两个阶段，到视频/音频 VAE（变分自编码器）解码；冷启动不在此列。该版本的 定义正式请求的端到端（E2E）为一段连续区间：起于请求进入（早于全新的 Qwen 编码），止于带音频的 MP4 完成封装，调度与潜变量传输都计入；并强调「这不是吞吐或冷启动声明」，单次请求的延迟会波动。
项目页的拆解图进一步把总延迟 56.17 秒分成七项：Qwen 提示编码 2.4%、H3 四步生成 35.2%、H3 上采样器加 VAE Adapter 3.8%、LTX 三步精修 44.0%、LTX VAE 解码 12.5%、MP4 输出与音频混流 1.3%、请求开销 0.9%。
潜空间直传：384p 草稿到 768p 精修
项目页把 Sol-H3 描述为一条「由粗到细」的两阶段管线：先在紧凑的 H3 潜空间里生成场景，在 H3 空间做 2 倍上采样，再把潜变量送进 LTX 做三步精修和卷积 VAE 解码。
第一步是一段 672×384、124 帧的草稿：MiniMax-H3 权重加一个四步 LoRA（来自 FastH3 的少步数模型），文本侧是 NVFP4 AWQ 量化的 Qwen，DiT（扩散 Transformer）以 W8A8 FP8 运行；草稿注意力用稀疏方案（90% 视频稀疏度、64 token 块），后端是 cuDNN BSA。
两阶段之间没有像素级的往返：一个学出来的 VAE Adapter（潜变量适配器）把上采样后的 H3 潜变量直接映射进 LTX 空间，省掉 H3 的 VAE 解码器与 LTX 的 VAE 编码器。
第二步用 LTX-2.5 做三步联合音视频更新，输出 1,344×768、121 帧，注意力换成 Sol-Attn 稀疏算子。文本侧不再实时跑编码器：一条与内容无关的质量提示（「4K、精修、高质量、电影级细节、干净质感、自然运动」）在离线阶段经 INT8 Gemma 与 connector（连接器）编码一次并缓存，推理时不加载这两个组件；草稿阶段仍会为每个请求实时编码 Qwen。README 注明，缓存通用条件是质量与性能之间的取舍，不保证每个生成场景中的身份不变。
草稿阶段还兼容其他 MiniMax-H3 少步数 LoRA，并支持 384p、480p、512p 三种草稿分辨率，按比例上采样到 768p。这套栈建立在团队此前公开的两篇论文上：（注意力稀疏化）与 （全栈加速框架）；项目页建议引用本次发布时一并引用它们。
119.68 GiB 的内存池：两套模型如何常驻
把两个阶段装进一台 Spark，难点在内存。项目页给出的数字是：DGX Spark 把 CPU 与 GPU 的统一内存合成一个 119.68 GiB 的池子；官方 MiniMax-H3 的 BF16 权重单独就要 133.4 GiB，比容量高 13.7 GiB；朴素的两阶段方案需要两套完整模型栈，要 142.4 GiB，高 22.7 GiB。项目页的结论是，即使做低位宽权重量化，这样的配置也放不下。
Sol-H3 的常驻足迹是 116.9 GiB，采样时余 2.8 GiB。项目页把省出这块空间的改动与其余提速手段一起拆成五项优化：
- Sol-Attn：在注意力执行过程中现场挑块。每个查询块用自己的阈值筛轻量 query-key 分数，选中的块做精确计算，跳过的块用池化 K/V 摘要做近似修正；路由、稀疏与修正共用一次 online-softmax，不写独立的全量分数图或路由索引张量，也不需要重训练。项目页给出的算子加速是相对 FA4 的 3.1 倍。
- VAE Adapter：跨阶段 VAE 从 2 次降到 0 次。
- 精修提示缓存：第二阶段的文本编码移到离线。
- 常驻部署：让两阶段不重建、不切换权重，请求从提示编码直接走到两个阶段。
- kernel（算子）与 I/O 融合：选中的块走融合路由与合并的 cuDNN BSA；卷积 VAE 直接输出 NHWC 布局；分块编码与音频混流避免额外暂存。
示例：毛毡浣熊与一桌中文对白
项目页展示的样本覆盖 T2VA、FL2VA 与 Ref2VA 三类任务，规格是 1,344×768、5 秒。示例 01 是一段定格动画：穿青绿色围裙的灰色毛毡浣熊在微型糕点店里偷走草莓挞上的那颗草莓。页面公布的提示词要求看得见毛毡纤维、柔和的微缩灯光和刻意顿挫但连贯的定格动作；声轨是布料摩擦、台面轻响和一声木头的吱呀，没有人声。
示例 02 是一段普通话对白，场景围绕一台修好的老收音机：女儿问「妈，修好了？」，母亲答「好了，听听看。」，随后她拧一下旋钮；对白之后，是一声轻的旋钮咔哒和微弱的电流声。按 README 的说法，输出的音频是原始 H3 音频压成的立体声 AAC。这两段与另外几段一起构成页面上的「Selected generations」，即团队挑选的展示样本。
开源范围、运行前提与验证边界
代码已经进入 的 sol-engine 分支：包含 infer.py 推理入口、download_checkpoints.py、prepare.py、configs、runtime 与一组 CPU 契约测试。该仓库采用 Apache-2.0 许可证；README 补充说明，模型权重的访问权限与许可独立于这段集成代码的许可。
运行前提写得很具体：Linux aarch64、单块 GB10/SM121 GPU、内存完全可用；运行时分成 Stage1、Stage2 与 Qwen 三套环境。README 给出的单条命令是 python infer.py --paths paths.json --prompt ... --seed 42 --output-dir outputs/fox；附带的 CPU 契约测试不加载 CUDA 与模型权重，可直接运行。
对 Spark 之外的硬件，划了边界：有用户问这套方案能否也跑在 RTX 5090 上，他回答说 5090 的显存远小于 Spark，当前为 Spark 设计的方案对 5090 可能并非最优。
验证覆盖同样标了边界。README 记录：T2VA 完成过一次全链路预热与三次连续纯文本请求，离线的提示上下文与第一阶段潜变量、音频载荷与参考一致；FL2VA 与 Ref2VA 只做了有限的功能覆盖，README 的原话是「有限的覆盖，而不是对每一种组合或参考类型的验证」。上述验证基于既有的运行时环境，洁净环境下的安装尚未验证。