Synthesia如何在Amazon EC2 G7e实例上优化生成式AI视频推理

Synthesia 是一家面向企业的 AI 视频平台，通过帮助用户无需相机或麦克风即可创建视频内容，彻底改变了内容创作方式。为此，Synthesia 允许用户生成能够模拟真实人物外貌和声音的视频分身。Synthesia 通过一系列内部开发的模型实现这一目标，这些模型基于多种架构，包括潜在扩散视频生成模型。

像 Synthesia 这样的客户通常选择在亚马逊弹性计算云（Amazon EC2）实例上托管其模型，因为该服务提供了对底层硬件的灵活控制。其中，他们发现G7e 实例系列是运行 GPU 内存密集型生成式 AI 视频模型的高性价比选择，可提供配备 96GB GPU 内存的 NVIDIA RTX PRO 6000 Blackwell GPU。

当使用包含变分自编码器（VAE）解码器架构的 AI 模型生成视频时，客户常发现 GPU 利用率受限于将视频帧保存到存储文件的速度。这会导致 GPU 等待（stalls）并降低平均 GPU 内核利用率（即 GPU 积极执行计算内核的时间百分比而非空闲状态）。

本文介绍了一种与 Synthesia 研发工程团队共同设计的视频解码优化技术，名为异步帧生成流水线。采用该技术可重叠 GPU 计算、设备到主机（D2H）数据传输以及主机端后处理。本文以Wan 视频生成模型的 VAE 解码器为例，通过在 G7e 上的基准测试显示，GPU 内核利用率从 82% 提升至 99.9%，从而将视频解码的延迟降低了 8.2%（吞吐量相应提升）。我们预计该技术将惠及所有采用分块视频生成流水线并需将帧传输到主机内存的客户。

您可以在相关 GitHub 仓库中找到异步生成流水线在 Hugging Face Wan 2.2 14B 模型 Diffusers 格式上的端到端实现示例。

在以下章节中，我们将分析潜扩散模型如何生成视频，以及传统顺序解码方法为何导致 GPU 利用率低下。

理解顺序解码的瓶颈

潜扩散视频生成模型已成为生成时间连贯视频序列的强大工具。为降低计算和内存需求，这些模型在变分自编码器（VAE）的压缩潜空间中执行扩散过程，如图 1 所示，其维度通常远低于原始视频像素空间。

图 1 VAE 模型的高层架构。所示帧取自 Wan 2.2 仓库示例视频，该视频用于后续章节的示例实现。

推理时，潜表征会以噪声初始化，并通过扩散过程进行迭代去噪。为确保输出符合文本提示，每个去噪步骤都会根据存在的文本输入进行条件化。最终去噪步骤后，扩散过程会生成仍以 VAE 潜空间表示的视频。最后一步是使用 VAE 的解码器将潜视频解码为人类可读的像素视频。

一次性处理整个潜空间或像素视频通常会消耗大量资源，即使在大型 GPU 上也是如此。因此，通常会沿时间维度将视频分割，并逐个潜帧解码，生成如图 2 所示的 4 个连续像素帧的块。

图 2 解码一个潜帧会生成包含 4 个时间连续像素帧的块，这些帧从 GPU 传输到主机。

一旦某个块被解码并处理完毕，对应的像素帧必须通过 D2H 传输转移到主机（CPU）内存，以便写入文件或进一步处理。若等到整个视频完全解码后再传输，整个解码视频需先存储在 GPU 内存中，这种策略难以扩展到任意长的视频。更节省内存的替代方案是每次解码一个块时即传输已解码帧，使解码器的 GPU 内存占用与块大小而非完整视频相关。

传统的块N中新生成的一组帧会从GPU内存同步传递到CPU RAM，并在CPU启动处理块N+1的CUDA内核（以下简称内核）之前提交到存储。这导致块之间的GPU系统性停滞，因为设备到主机（D2H）的复制阻止GPU立即开始处理下一个块，从而降低整体硬件利用率并增加处理时间。我们将这种同步过程称为顺序帧生成流水线，如图3所示。

图3 顺序帧生成流水线的示意图。处理块N+1的内核启动需要等待块N的帧完成全部复制和存储。

在下一节中，您将学习如何通过重叠GPU计算与数据传输和主机端处理的异步流水线克服这一瓶颈。

异步帧生成流水线

为最小化GPU停滞并提高GPU利用率，需修改上一节介绍的顺序流水线，使所有主机端CPU工作（如将解码后的帧追加到文件）与不间断的设备端内核流并行运行。本节以异步Wan VAE解码器的实现为例进行说明，该解码器基于PyTorch实现，可在关联的GitHub仓库中找到。

默认情况下，PyTorch为每个设备在单个默认CUDA流上调度工作，除非显式创建其他流，否则操作按提交顺序执行。为解耦计算与D2H复制，实现中使用两个CUDA流：计算内核（提交到默认流，后续称为计算流）与D2H复制（提交到专用的复制流）。图4展示了在GPU加速实例（本例中为G7e）上的完整配置。

图4 异步帧生成流水线实现中关键组件的高层架构图。

在主机端，内核提交与D2H传输及后传输处理交替进行。为避免主机端阻塞调用并最大化GPU利用率，异步流水线引入了两个机制：

• 一个专用的Worker CPU线程，负责从主机内存（RAM）读取块并写入文件，使主线程专注于内核启动和D2H传输调度。
• 在GPU内存（VRAM）和主机内存（RAM）中各使用两个内存缓冲区，并对主机内存缓冲区进行页锁定，确保D2H复制完全异步执行。

双缓冲策略确保相邻块的计算、D2H传输和主机处理可以安全重叠，因为它们操作的是不同的内存缓冲区。

图5 异步帧生成流水线实现中事件、流、缓冲区和Worker组件的交互示意图。事件表示为左右条件，描述流程等待的条件及完成时触发的信号。操作框的大小经过调整以适配文本，不代表实际处理时间。

由于缓冲区可能被不同组件并发访问，实现中引入了同步机制以避免内核和线程对缓冲区数据的破坏。这可通过CUDA事件实现，其作为屏障，用于判断类似“块N的解码是否完成”等条件。图5展示了流、线程和事件的交互。

G7e基准测试结果

为量化异步帧生成流水线的影响，您可以在g7e.2xlarge EC2实例上使用此sample notebook，对单个41个潜在帧的测试视频分别对同步和异步流水线进行基准测试。基准测试基于未优化的Hugging Face Diffusers Wan 2.2 14B模型作为共同基线。两种情况下，基准循环均先执行一次完整解码周期以初始化CUDA和PyTorch的内存池和缓存。预热后，基准测试会执行10次连续的完整视频解码循环。我们提供了一个端到端示例的运行结果，如表1所示。

| 指标 | 同步（秒/视频） | 异步（秒/视频） | |------------------|---------------------|---------------------| | min | 21.98 | 20.16 | | mean | 21.99 | 20.17 | | P99 | 22.01 | 20.20 |

表1 同步与异步流水线在10次连续解码运行中的基准测试结果。

示例结果表明，在此基准测试中速度提升了最高8.2%，解码器的实时因子从3.21降至2.95。以撰写本文时g7e.2xlarge的定价（俄亥俄区域按需GPU单价为3.36美元）计算，单GPU解码1000小时视频可节省约896美元。这一节省是理论值，假设底层模型在无瓶颈情况下以完全计算效率运行。

若想定性理解这一性能提升的实现方式，可通过此示例笔记本分析同步与异步管道的性能剖析结果。图6和图7展示了示例运行结果，对比显示异步管道不存在GPU等待延迟，而同步管道则存在该问题。

图6 同步管道单线程单流的性能剖析。当主CPU线程将第N块数据写入磁盘时，GPU流会停滞等待CPU启动处理第N+1块数据所需的内核

图7 在异步管道中，计算流不会因向磁盘写入帧数据而中断。主线程可自由启动处理内核。此图与图6采用不同缩放级别以突出差异

通过在稳态下分析连续两块数据的时间轴，可量化GPU内核利用率的提升。在示例运行中，同步场景的利用率为82%，异步场景提升至99.9%。

结论

本文展示了如何通过异步帧生成管道，在Amazon EC2 G7e实例解码潜在视频时提升GPU利用率。通过使用双CUDA流、固定内存缓冲区和专用工作线程，将GPU计算与设备到主机的数据传输及主机侧I/O解耦，消除了传统同步解码管道中的固有GPU等待问题。

基于Wan 2.2 14B VAE解码器的示例基准测试显示，解码延迟降低了8.2%，按撰写本文时g7e.2xlarge的定价（俄亥俄区域按需GPU单价3.36美元）计算，单GPU解码1000小时视频可节省约896美元。这些改进无需调整模型权重或影响推理质量，完全通过优化硬件利用率实现。我们预期该内核利用率提升在优化和编译后的模型中将产生更显著的影响，这类模型能更高效地利用GPU资源。

文中所述技术不仅适用于Wan架构或特定GPU型号，任何需要将帧传输到主机内存的分块视频生成管道均可从中受益。我们建议探索关联的示例实现，以了解如何将异步帧生成管道集成到自己的视频生成工作流中。

开始在G7e实例上部署生成式AI视频工作负载，请访问Amazon EC2 G7e实例页面。

• * *

作者简介