SolarWM H3 Real-time interaction
EN中文

SolarWM H3

SolarWM H3 Realtime Interaction

关键词:实时交互 · 流式生成

实时交互的核心,是让世界模型及时响应用户的操作。围绕这一目标,我们对 SolarWM H3 [1] 的推理流程进行了分阶段优化:通过编译、注意力后端选择、历史缓存复用以及 CUDA Graph 重放,加速基于 MiniMax H3 [2] 的 DiT 计算。在此基础上,我们结合流式 VAE 解码,同时缩短了从动作输入到画面生成的时间。

这套优化从固定输入形状的静态推理开始,分阶段先提升各个模块的稳态性能,再将加速结果带入交互式部署。借助动态编译和按形状缓存的 Graph,服务能够在支持范围内跨场景、跨提示词长度复用已完成的准备工作。最后还接入了基于 StreamRender-H3 [8] 解码器与权重适配的单潜变量流式版本 [7],使动作对应的首帧不必等待下一生成块的潜变量,从而进一步缩短响应时间。

最终,静态 DiT 的等效帧率由 7.09 提升至 31.49 FPS,吞吐率达到原来的 4.44 倍。计入 VAE 解码后,完整串行后端的稳态速度由 4.92 提升至 24.38 FPS,吞吐率达到原来的 4.95 倍。在一次动作响应测试中,对应首帧的后端就绪时间从约 6.90 秒缩短至 0.58 秒,不包含网络传输和浏览器显示。在当前网页部署的实测中,从按键按下到对应画面显示的延迟中位数为 1.15 秒,包含生成、传输与浏览器显示的完整过程。

下面,我们先通过优化前后的对比视频,直观展示实时视频生成的提速效果,再用时间轴呈现从动作输入到首帧生成的后端响应过程。随后,逐阶段介绍如何减少重复计算与执行开销,并将这些优化应用于实时交互。

后端稳态生成速度从 4.92 FPS 提升至 24.38 FPS,达到原来的 4.95 倍。两侧均展示对应的 102 帧片段,按各自实测的串行 DiT + VAE 稳态帧率匀速播放

从动作输入到首帧

0.00 s
原始等待回放6.90 s
等待下一块潜变量
原始: 当前动作对应的首帧等待首帧
就绪后按稳态帧率循环预览
  1. 当前块 DiT2.41 s
  2. 上一块 VAE1.03 s
  3. 下一块 DiT2.41 s
  4. 响应帧 VAE1.04 s
优化等待回放0.58 s
无需等待未来块
优化: 当前动作对应的首帧等待首帧
就绪后按稳态帧率循环预览
  1. 当前块 DiT556 ms
  2. StreamRender 首帧25 ms

时间轴对比了优化前后的动作响应过程:从动作指令生效,到对应首帧在后端就绪。MiniMax H3 的原生解码器需要等待下一块潜变量,而基于 StreamRender-H3 [8] 的单潜变量适配版本 [7] 无需等待未来输入,即可解码当前块的首帧,让动作更早得到画面反馈。这里衡量的是首帧响应时间,而非整块 17 帧的生成耗时,不包含网络传输与浏览器显示。

加速 DiT 的核心计算

要缩短动作到画面的响应时间,我们先从计算开销最大的 DiT 入手。DiT 根据图像、文本和动作条件流式生成视频潜变量,再由 VAE 将其解码为画面。

我们首先固定分辨率、提示词长度等输入形状,逐步优化编译、注意力计算、历史缓存与计算调度。这样可以先明确每一步优化的效果,再将这些加速能力扩展到需要切换场景和提示词的实时交互服务。

一次完整生成块(chunk)产出 5 个潜变量(latent),对应保留 17 个视频帧。计算过程包含四次去噪前向计算,以及一次历史键值缓存更新(KV refresh)。缓存更新为后续生成准备干净的上下文,因此也必须计入每块耗时。

为便于比较,我们将完整 DiT 耗时换算为等效帧率:DiT FPS = 17 / (每块耗时(毫秒)/ 1000)。下方动态图按优化阶段依次展开,展示 DiT 这一环节的流式生成速度如何从 7.09 FPS 提升至 31.49 FPS。下表汇总各阶段的耗时、帧率与主要改动。

DiT 分阶段提速:从 7.09 到 31.49 FPS
已加入 4 / 4 项优化DiT Denoise Graph + KV Refresh Graph重放去噪与 KV 缓存更新,复用固定缓冲区
31.49DiT FPS539.91ms / 生成块4.44×相对基线吞吐率
优化阶段每块耗时DiT 等效帧率主要改动
原生基线2,396.49 ms7.09原始执行路径
+ Full-model Compile1,036.61 ms16.40使用 TorchInductor 编译完整模型
+ Attention Backend767.00 ms22.16视频查询使用 SDPA,其余分段保留 FlashAttention
+ 历史 K/V 拼接复用733.11 ms23.19复用预先整理的历史 K/V
+ DiT Denoise Graph + KV Refresh Graph539.91 ms31.49通过固定缓冲区重放去噪与缓存更新

第一阶段:编译完整模型

DiT 的执行成本不只来自大规模矩阵乘法。归一化、激活、逐元素运算和张量变换分布在 50 层网络中,并随着每块的多次前向计算反复执行。逐算子运行时,这些操作需要各自调度,还会产生供后续算子读取的中间结果。单个操作的开销不大,放进完整生成循环后却不可忽略。

我们使用 torch.compile 和 TorchInductor [3] 编译完整的 50 层前向计算,并设置 fullgraph=True,要求这条前向路径完整进入编译图。这样,编译器可以在可融合的计算之间消除不必要的中间读写,并减少 Python 层的逐算子调度。这里的“完整模型编译”并不是把整个模型变成一个巨大的 GPU 内核,而是让编译器看到完整前向中的计算关系,再为不同部分生成合适的执行代码。

编译结果的复用还取决于输入形状。历史上下文在启动阶段逐步增长,进入稳态后才保持稳定。去噪与 KV 缓存更新也不是同一条计算路径。因此,我们按这些形状和计算阶段准备相应的编译入口,在测量前完成预热。生成循环复用的是已编译的程序,噪声、相机条件和历史内容仍随每次调用更新。

结果:每块 1,036.61 ms,对应 16.40 DiT FPS。 这一阶段在不改变模型结构和生成步数的前提下,减少了完整前向中的执行开销。它也明确了编译的边界:编译器能够优化算子之间的组织方式,但被调用的注意力实现是否适合当前输入,仍需要单独判断。

第二阶段:选择注意力后端(Attention Backend)

我们分析了编译后的注意力计算,并在完整 DiT 推理中比较不同后端。SolarWM-H3 将条件、音频和当前视频的查询分组计算,其中视频查询需要读取更长的历史上下文。实测发现,原生统一使用的 FlashAttention 并非对所有分组都最合适:视频查询组改用 SDPA 后,完整推理更快。

因此,我们仅将视频查询组切换到 PyTorch SDPA [4],条件与音频组保留 FlashAttention [5]。运行时追踪确认,SDPA 在这次测试中实际调用的是 cuDNN Attention。这一调整保留了原有的上下文范围、位置编码和相机条件,只改变注意力的计算实现。

结果:每块 767.00 ms,对应 22.16 DiT FPS。 相比同阶段每块 1,051.29 ms 的编译对照,耗时降低约 27%。

第三阶段:复用历史 K/V 拼接结果

分析编译后的执行过程,我们发现:原始 KV 缓存虽然保存了历史键和值,但每次 Attention 前仍需将各个历史块重新拼接。在当前块的四次去噪之间,历史内容并未变化,这些反复执行的拼接带来了不必要的内存分配和数据拷贝。

我们将历史 K/V 的整理移到缓存更新时:按层提前拼好下一块需要的历史张量,供其四次去噪直接复用。历史窗口更新后再重新准备,前缀与当前块仍按需组装。优化不改变缓存内容和上下文范围,只减少相同数据的重复整理。

结果:每块 733.11 ms,对应 23.19 DiT FPS。 直接收益来自减少重复拼接及其内存开销。预先整理好的历史张量,也便于后续接入 CUDA Graph 的固定输入缓冲区,为 Graph 重放准备数据。

第四阶段:DiT Denoise Graph + KV Refresh Graph

经过编译、注意力后端和历史 K/V 复用优化,单次前向已经明显加快,但 CPU 仍需逐一发起 GPU 内核调用。稳态生成反复执行相同结构的计算,任务提交却仍在每次前向中从头进行。这些开销随着每块的多次去噪与缓存更新不断累积,无法仅靠加快 GPU 内核来消除。

我们使用 CUDA Graphs [6] 记录内核调用及其依赖关系,将逐个提交计算任务改为重放已捕获的执行路径。捕获范围同时覆盖DiT 去噪与 KV 缓存更新。后者需要在去噪后的潜变量上再执行一次前向,为后续生成建立历史上下文,因此同样值得加速。一个稳态生成块的四次去噪和一次 KV refresh,都通过各自的 Graph 执行。

进入稳态后,历史窗口大小和计算形状保持稳定,为 Graph 复用提供了条件。完成预热与捕获后,每次重放只需更新噪声、时间步、相机条件和历史数据,而不必重新组织整段计算。复用的是执行路径,而不是输入内容,新的控制动作仍会随相机条件进入当前块的生成。

结果:每块 539.91 ms,对应 31.49 DiT FPS。 本阶段通过 Graph 重放减少了 CPU 的逐内核提交与重复调度,在不减少去噪步数、不省略缓存更新的前提下,进一步缩短了每块的生成时间。

加速 VAE 解码

VAE 的延迟需要从两个方面理解:执行一次解码有多快,以及解码所需的输入何时才能凑齐。前者是计算效率问题,后者由时间窗口决定。两者都会影响动作对应的画面何时出现,但不能用同一种优化解决。

对于计算效率,我们先编译原生 H3 VAE 的完整解码路径,使用 fullgraph=True 和 dynamic=False。其权重、注意力后端、空间分块方式,以及 7 个潜变量的窗口、5 个潜变量的推进步长和 2 个潜变量的重叠均保持不变。固定窗口为编译器提供了稳定的计算形状,可以减少解码过程中的逐算子执行开销。

VAE 解码提速:从 20.68 到 37.71 FPS
已加入 1 / 1 项优化Full-model Compile编译完整解码路径
37.71VAE FPS450.84ms / 5 潜变量1.82×相对基线吞吐率
原生 VAE 配置每推进 5 个潜变量的耗时VAE 等效帧率
未编译解码器821.87 ms20.68
编译后解码器450.84 ms37.71

如上表所示,独立解码测试中,吞吐率达到原来的 1.823 倍,耗时降低 45.14%。与此同时,输入等待还有另一层约束。DiT 每块生成 5 个潜变量,原生解码窗口却需要 7 个:为凑齐后续的 2 个潜变量,当前画面的解码需要等待下一块 DiT 生成。即使把 VAE 内核进一步加速,这段由未来输入依赖造成的等待仍然存在。

实时部署所用的基础因果解码器与蒸馏权重来自 NVIDIA 的 StreamRender-H3 [8]。我们接入的是团队流式解码工作 [7] 在这些权重上适配的单潜变量解码版本,利用已经到达的潜变量与历史状态推进解码,不再为了当前块的首帧等待下一块输入。DiT 仍按块输出 5 个潜变量,VAE 则以单潜变量为单位推进解码。这项调整并未改变 DiT 的分块生成方式。文章开头使用的正是这条部署路径,它与上表中的编译版原生 VAE 权重和执行方式不同,不能把两者的计时当作同一配置。

实时交互结果

我们在保留前述 DiT 加速方法的基础上,为提示词长度启用动态形状编译,使不同长度提示词能够共享编译结果。去噪与 KV refresh Graph 则按输入形状缓存,命中时直接复用,减少切换场景时的重复准备。接入 StreamRender 单潜变量流式解码器 [8][7] 后,串行 DiT + VAE 后端的稳态生成速度达到 24.38 FPS,吞吐率为原始串行路径的 4.95 倍。单潜变量解码还消除了等待下一块 DiT 的依赖,使一次动作对应首帧的后端就绪时间缩短至约 0.58 秒。在当前网页部署的实测中,从按键按下到对应画面显示的延迟中位数为 1.15 秒,包含生成、传输和浏览器显示的完整过程。

实时交互演示

总结

围绕 SolarWM H3 的实时交互,我们分阶段优化了 DiT 的推理性能。完整模型编译与注意力后端选择提升了计算效率,历史 K/V 拼接复用与 CUDA Graph 重放减少了重复开销,最终将 DiT 的等效帧率从 7.09 提升至 31.49 FPS,吞吐率达到原来的 4.44 倍。

结合 StreamRender 单潜变量流式解码器 [8][7] 后,串行 DiT + VAE 后端的稳态生成速度从 4.92 提升至 24.38 FPS,吞吐率达到原来的 4.95 倍。单潜变量解码还消除了首帧对下一生成块的等待。在本文记录的一次动作响应测试中,从动作被后端采纳到对应首帧就绪的时间,由约 6.90 秒缩短至 0.58 秒。

面向实时部署,我们为提示词长度启用动态形状编译,并按输入形状缓存去噪与 KV refresh Graph,减少切换时的重复准备。在当前网页部署的实测中,从按键按下到对应画面显示的延迟中位数为 1.15 秒,包含生成、传输与浏览器显示的完整过程。从计算提速、流式解码到部署复用,这些优化共同缩短了操作与画面之间的等待,让世界模型更适合实时交互。

参考文献

  1. [1]J. Huang, G. Fang, S. Qian, et al. SolarWM: Open Data and Scalable Training for Long-Horizon Video World Models. arXiv:2609.02886, 2026. arxiv.org/abs/2609.02886
  2. [2]MiniMax. MiniMax H3. Official model and inference repository. github.com/MiniMax-AI/MiniMax-H3
  3. [3]PyTorch. torch.compile. API documentation. PyTorch documentation
  4. [4]PyTorch. torch.nn.functional.scaled_dot_product_attention. API documentation. PyTorch documentation
  5. [5]Dao-AILab. FlashAttention. Official implementation. github.com/Dao-AILab/flash-attention
  6. [6]PyTorch. CUDA semantics: CUDA graphs. Documentation. PyTorch CUDA Graph documentation
  7. [7]B. Chen, Y. Chen, Y. Du, J. Huang, G. Fang, and S. Qian. H3 Streaming VAE Decoder: Training-Free Streaming without Future Latents. SolarX-Team, October 2026. H3 Streaming VAE Decoder
  8. [8]Y. Lu, T. Ye, Y. Li, S. Xue, H. Liu, S. Han, and E. Xie. StreamRender-H3: Interactive Coding Worlds with Real-time Streaming Diffusion Render. NVIDIA Research, 2026. Project page. StreamRender-H3
  9. [9]Y. Li, J. Chen, H. Li, H. Liu, J. Yu, L. Zhu, P. Luo, S. Han, and E. Xie. Sol Video Inference Engine: Agent-Native Full-Stack Acceleration Framework for Efficient Video Generation. arXiv:2606.23743, 2026. arxiv.org/abs/2606.23743

引用

SolarWM 论文

@misc{huang2026solarwmopendatascalable,
  title = {SolarWM: Open Data and Scalable Training for Long-Horizon Video World Models},
  author = {Junchao Huang and Guian Fang and Shengju Qian and
            Xianghao Kong and Zhuoran Zhao and Wei Huang and
            Yihua Du and Zixin Zhang and Justin Cui and Yuchao Gu and
            Yukang Chen and Xinting Hu and Tianyu He and Shaoshuai Shi and
            Zhuotao Tian and Xin Wang and Mike Zheng Shou and Li Jiang},
  year = {2026},
  eprint = {2609.02886},
  archivePrefix = {arXiv},
  primaryClass = {cs.CV},
  url = {https://arxiv.org/abs/2609.02886}
}

本篇博客

@misc{du2026acceleratingsolarwmh3,
  title  = {SolarWM H3 Realtime Interaction},
  author = {Du, Yihua and Huang, Junchao and Chen, Bohong and
            Liu, Yaoyang and Zhang, Zixin and Kong, Xianghao and
            Yan, Dongyu and Zhao, Zhuoran and Fang, Guian and
            Chen, Yajing and Qian, Shengju},
  year   = {2026},
  month  = {oct},
  note   = {SolarX-Team technical blog},
  url    = {https://solarx-team.github.io/SolarWM-H3-Realtime/}
}