Runway 发布 57B 视频扩散 transformer 实时推理研究，四张 H100 跑通 24 fps 对话式视频

每次对话都有它的节奏。一个人停止说话，另一个人开始，这种来回的节奏定下了基调。我们会互相打断、抢话，并且在话题之间跳转，同时始终保持主线。要做到有说服力——要跨越恐怖谷效应——虚拟角色必须保持同样的节奏。

Runway Characters 可以将单张图片变成你可以与之对话的生动角色，其背后是一个拥有约 570 亿参数的自回归视频扩散 Transformer。在每秒 24 帧（fps）的速率下，该模型必须每 166.7 毫秒为单用户生成一个包含 704x1088 分辨率的新四帧视频块，并且对话持续多久，生成就要持续多久。

在 5 月份，我们首次分享了我们是如何构建 Characters 的。在我们新发表的研究报告《Runway Characters: Serving a 57B Video Diffusion Transformer for Real-Time Conversation》中，我们介绍了支撑这一生产环境中背后节奏的推理和系统。我们在下文对其中各项进行宏观介绍，论文中则有深入的探讨。

主要发现：

• Characters 启动时每场会话需要八张 H100。在四张 H100 上，初始软件每个扩散步骤需要 240.9 毫秒，远高于我们要求的 166.7 毫秒。我们的优化将其缩短至 159.3 毫秒（提速 1.51 倍，持续达到 24.5 fps），因此现在每场会话都可以在四张 H100 上实时运行。融合通信内核将其进一步缩短至 147.4 毫秒（1.63 倍）。
• 在最初的步骤中，29% 的 GPU 时间用于在 240 次注意力调用中分别重新处理基本未变的缓存，而注意力机制本身仅占 6%。在写入每一帧时完成该工作，将缓存维护时间从每步 69.7 毫秒减少到 6.2毫秒。
• 将张量并行的 all-reduce 操作融进 FP8 矩阵乘法中，隐藏了其 54-68% 的时间。在我们的生产规模下，融合后的调用耗时 153.8 微秒（而之前为 208.2 微秒），并且随着 GPU 数量的增加，优势更加明显。
• Characters 运行在自回归模型上，这使得像素比较变得相对毫无意义。我们将每次改动与重复运行之间的变异进行了对比。在 51 个评分剪辑中，平均唇形同步差异最多为 0.03，与多次运行间的变异处于同一数量级，四个 10 分钟的会话也显示出相同的结果。
• 在为期七周的遥测中，在持续至少一秒钟的会话中，有 99.5% 的会话里工作节点的平均帧率超过了 23.5 fps。在一次回滚和修复后，融合内核运行中帧率降至 23.5 fps 或更低的会话仅占 0.08%。

永不停止的时钟

传统的生成式视频按照模型的节奏运行。你输入提示词，等待并获得一个完成的视频片段。但角色必须像对面的真人一样快速倾听、响应和反应，没有自然的停顿点，也没有稍后追赶的机会。

这使得速度成为一项硬性要求：对话中的视频角色绝不能落后。在 24 fps 下，只要对话持续进行，Runway Characters 就必须每 166.7 毫秒生成一个新的四帧视频块。播放器只保留少量视频块作为备用，并且由于每一帧都带有其音频切片，迟到的视频块会同时冻结面部并卡住声音。视频模型还要与语音代理共享循环，因此生成多耗费的任何时间，都是用户等待回复的时间。

大多数服务系统通过批处理（在多个用户的请求之间共享 GPU）来获得效率。但虚拟角色无法做到这一点。每个会话都是一个私密的、一对一的流，在 24 fps 下，它需要 2.24 PFLOP/s 的有效算力，超过了单个 H100 的密集 FP8 峰值性能。矩阵乘法已经达到了该峰值的三分之二左右，因此在批处理中加入第二个会话几乎会使步进时间翻倍。我们节省的每一毫秒都必须来自步进过程本身。

时间都去哪了

每一步通过一个 60 层的 Transformer 进行四次遍历来对一个潜在帧进行去噪，总共产生 240 次注意力调用。每次调用都会读取其自身的 5,788 个槽位的缓存，其中只有 757 个是新的。在最初的实现中，每次调用都会对整个缓存重复进行工作：将旋转位置编码（RoPE）重新应用到每个缓存的键上，将缓存重新量化为 FP8，并通过复制来移动窗口。这种维护工作在 239.2 毫秒的单步耗时中占了 69.7 毫秒。

在写入时完成一次

为了解决这个问题，我们在每个新帧进入缓存时对其应用 RoPE 和 FP8 量化，并使用每个会话校准一次的每个注意力头（per-head）缩放比例。我们将缓存存储为环形缓冲区，因此窗口无需复制即可推进。缓存维护耗时降至每步 6.2 毫秒

我们模型中的位置每 42 步重置一次，因此缓存的键无法永久保留其旋转。在每次重置时，我们对缓存的窗口应用单个增量旋转，而不是在每次读取时重新旋转所有内容。这表现为 42 步中较慢的一步（耗时 263 毫秒），播放缓冲区可以吸收这个延迟。

环形缓冲区只有在写入时应用 RoPE 才能生效。每个新帧都会覆盖最旧的槽位，因此一旦环形缓冲区回绕，槽位顺序将不再与时间顺序匹配。原始代码按槽位顺序分配位置，因此结合环形缓冲区，它会悄悄地给缓存帧赋予错误的位置。现在有一个测试将这种组合标记为无效。

每步扩散时间的累计瀑布图。每个优化及其效果，以毫秒为单位；越低越好。

将通信融入计算

去除了缓存工作后，矩阵乘法之后第二大的开销是每个块之后、每步 240 次的张量并行 all-reduce 操作。换用更快的集合通信仅节省了 0.4 毫秒，因为归约操作仍然必须等到整个矩阵乘法完成后才能开始。

因此，我们将两者进行了融合。我们将 ParallelKittens 中的融合 GEMM 和 all-reduce 内核扩展到了 FP8 和奇数 GPU 数量。每个输出瓦片（tile）在其部分结果到达时立即在 NVLink 交换机中进行归约，而后面的瓦片仍在计算中。在我们的生产规模下，融合调用耗时 153.8 微秒，而原先为 208.2 微秒，隐藏了 54-68% 的 all-reduce 开销。

如果没有这个融合内核，我们的优化将扩散步进时间带到了 159.3 毫秒，在四个 H100 上维持了 24.5 fps。有了它，步进时间达到了 147.4 毫秒。

给解码器分配专用的 GPU

将潜在变量转换为视频帧的解码器每步耗时 114ms。如果在扩散 GPU 上，它会为每一步增加这段时间，因为张量并行组必须等待最慢的成员。而在其自己的 GPU 上，它可以在对下一个块进行去噪的同时解码前一个块，步进周期仅比扩散时间多出 1.6 毫秒。

我们在 B200 上测试了替代方案。一个同时用于解码和扩散的 GPU 达到了 1,000 W 的功耗上限，这使其扩散内核变慢了 18-26%。

单次会话使用四个 H100，第 i 步的去噪与第 i-1 步的解码以及第 i-2 步的播放重叠。

当像素无法衡量质量时

其中三项优化改变了模型的数值运算：FP8 缓存、融合的前注意力内核和融合的 all-reduce。常规的检查方法是将输出像素与参考进行对比。在自回归模型中，这种对比在几秒钟内就会失去意义，因为任何数值差异（甚至是 GPU 的非确定性）都会让视频走向不同的生成轨迹。在大约 10 秒后，相同生产配置的两次运行在 PSNR 上的差异与任意两种配置之间的差异一样大。

因此，我们转而通过具体任务来评估每次改动。我们针对各种配置生成了包含 53 个剪辑的评估集，该评估集由 50 张合成参考图像构建，涵盖真实感、卡通、黏土动画、奇幻和非人类风格。我们还运行了四次生产环境，以测量相同运行之间的口型同步得分波动情况。

在所有运行中，51 个剪辑的 SyncNet 得分平均差异至多为 0.03，所有 95% 置信区间均落在 ±0.08 以内。仅四次生产运行的 LSE-D 差异就达到 0.024，LSE-C 差异达到 0.018。交替进行说话和倾听的四个 10 分钟会话显示出相同的模式，没有任何差异在会话期间的增长超过重新运行所产生的偏差。

这些结果是对改动进行了范围界定，而不是证明完全等价。SyncNet 在风格化角色上的表现较弱，置信区间宽两到五倍，并且四次长会话无法排除缓慢趋势的可能性。

生产环境中出了什么问题

融合内核于 2026 年 8 月投入生产环境，并稳定运行了数周。随后，在升级 PyTorch 和 NCCL 后，由于我们的基准测试缺乏输入多样性，工作进程开始出现内存不足的情况。

会话的第一次前向传播长度取决于其提示词，并且内核会为其看到的每个 Token 数量保留一个缓冲区，因此工作进程会为每个新的提示词长度绑定新的多播缓冲区。使用固定提示词的基准测试从未触发过该问题。系统中的每个优化都配备了保留纯代码路径的开关，因此回退到 NCCL 只需要更改配置。

我们现在仅对稳定状态形状进行融合，并允许第一次前向传播使用 NCCL。经过持续 15 小时的灰度测试（其中每个测量会话的平均帧率均达到 24.0 fps 或更高），我们于 2026 年 10 月 8 日重新启用了该内核。在随后的 15 天里，持续时间至少一秒的会话中，有 0.7% 的平均帧率在 24 fps 或以下，而此前五周每周的这一比例为 7-23%。

另外两个 Bug 通过了所有的 eager 模式测试，却仅在编译时失败。其中一个 Bug 中，编译器合法地将一次调用的读取操作移动到了下一次调用对共享缓冲区的写入操作之后，导致 96% 的元素出错。现在，每个内核测试都会在 torch.compile 下通过 CUDA 图将调用串联起来。

我们最严重的一个 Bug 是每步添加了一次 .item() 调用来监控 FP8 缩放比例。它阻止了 CPU 超前于 GPU 运行，使单步耗时从 168.5ms 增加到 278ms，所浪费的时间比我们所有的缓存工作节省的总时间还要多。

对话轮次的去向

对话有其自身的节奏。在一项涵盖 10 种语言的研究中，一个说话者结束到下一个说话者开始之间的间隔平均为 208ms。而商业语音代理在同一指标上的平均值则为 1.30s。

我们对 12 个线上会话中的 51 次对话轮次进行了追踪。中位轮次延迟（从用户发言结束到客户端听到角色声音）为 2.13 秒。其中语音智能体占了 1.42 秒。我们的流水线（从智能体的第一段音频到第一个说话帧）耗时 0.49 秒，传输到浏览器大约增加了 190 毫秒。

各阶段的中位轮次延迟。时间消耗分布：从用户发言结束到客户端收到虚拟形象音频。

Blackwell 与超越四块 GPU

生产环境在四块 H100 上以每步 159.3 毫秒实时运行，在三块 B200 上则为 154.3 毫秒。但并非每一项 H100 优化都能直接套用。FP8 缓存可在 H100 上节省 17.0 毫秒，但在 B200 上却会增加 2.4 到 6.7 毫秒的开销，因为我们的构建版本中没有采用逐头缩放（per-head scales）的 FP8 注意力算子。融合算子在解码脱离关键路径时最为重要，在更多 GPU 数量下，端到端性能最高可提升 1.20 倍。

更多的 GPU 可以加速模型，但无法加速解码器。在八块 H100 上，扩散模型的耗时降至每步 118.2 毫秒，但负责将结果转换为视频帧单 GPU 无法跟上进度，因此每步仍需 128.7 毫秒（31 fps）。

与我们一起构建实时技术

我们坚信实时视频是生成式媒体的发展方向，而对其进行模型服务本身就是一个研究课题。完整论文涵盖了算子设计、质量评估和生产环境测量。如果你想从事低延迟系统和 GPU 算子的工作，我们在招聘。