模态

模型的模态描述了它接受哪些类型的输入以及产生哪些类型的输出。

第1章至第5章重点介绍大型语言模型（LLM）的推理工程，这些模型以文本作为输入并产生文本输出。本章将把讨论范围扩展到更多模态。

生成式AI模型提供了丰富多样的模态，包括：

幸运的是，尽管模态种类繁多，但如第2章所述，生成式AI模型只有两大基本原型：

• 自回归token生成：从标记化序列开始，预测最可能的下一个token。

• 迭代去噪：从随机噪声开始，逐步细化以趋向最可能的输出。

LLM是最著名的用于token生成的自回归Transformer模型，但绝非唯一的一类。视觉语言模型、文本和多媒体嵌入模型、自动语音识别（ASR）模型、文本转语音（TTS）模型以及许多其他模型都依赖于类似的架构。

许多用于LLM的推理引擎和技术同样适用于这些相关模态。

图像和视频生成模型则依赖迭代去噪，尽管越来越多的混合扩散Transformer模型正在引领质量前沿。虽然从内核选择到参数调优等许多相同的理念同样适用于图像模型优化，但具体细节最终却大相径庭。

对于每种新模态，您还需要调整思考和衡量延迟、吞吐量及质量的方式。例如，TTS模型输出的单个音频token并不特别有用；与其使用首token时间（TTFT），不如改为衡量首词时间或首句时间。

本章讨论LLM之外六种常见模态的推理工程，并特别关注每种模态的不同考量因素：

• 视觉语言模型

• 嵌入模型

• ASR 模型

• TTS 模型

• 图像生成模型

• 视频生成模型

6.1 视觉语言模型

视觉语言模型（VLM）以一张或多张图像或视频以及文本提示作为输入，并生成文本响应。

视觉语言模型通常由两个模块组成：

• 大语言模型（LLM）：标准的大型语言模型。

• 视觉编码器：一个以原始图像和视频为输入，并将其转换为图像 token 的小型模型。

语言模型远大于视觉编码器。例如，在 Mistral Large 3 中，视觉编码器仅有 20 亿参数，而大语言模型则拥有 6730 亿参数。

尽管视觉编码器的参数量较小，但它对推理至关重要。VLM 的视觉编码器采用多种不同的架构和实现方式，因此视觉语言模型的运行时支持在某种程度上较为分散。这种碎片化进一步凸显了 vLLM 和 SGLang 在服务视觉语言模型方面的重要性。

根据经验，向 VLM 发送一张高分辨率输入图像大约会在输入序列中增加约一千个视觉 token。尽管从宏观层面来看，图像 token 与普通 token 类似，但它们的数量会迅速累积。

在各类 VLM 中，推理优化的主要挑战在于处理更长的输入序列和更大的 KV 缓存。这给推理的两个阶段都带来了额外的复杂性：

• 预填充（Prefill）：图像被分块、嵌入、token 化，并作为输入序列的一部分送入预填充阶段。

• 解码（Decode）：机制相同，但上下文更长，且某些模型还针对图像 token 添加了注意力变体。

前一章介绍的每种技术都有助于应对这一挑战：

• 量化：KV 缓存量化可降低长序列的内存带宽和存储开销。

• 推测解码：VLM 的解码与 LLM 一致，可通过推测解码（尤其是 EAGLE）加速。

• 前缀缓存：在多轮对话和重复查询中复用图像的 KV 缓存。

• 并行化：使用张量并行实现快速推理，同时为大型模型和长上下文访问更多显存。

• 分离式部署：将预填充迁移至专用且可独立扩展的工作节点，以处理长序列。

除上述技术外，VLM 还引入了一种新的质量与速度权衡：下采样。图像和视频可以以不同分辨率转换为视觉 token。高分辨率表示所需的 token 数量约为低分辨率图像的四倍，但能提供更丰富的细节信息。下采样通常在单图像输入时不是必要的，但在传入多张图像或视频片段时可能是必要的。

6.1.1 视觉语言模型的视频处理

视频不仅仅是静态帧的简单堆叠。它可能包含音频；尽管许多 VLM 还无法直接处理音频，必须先将其单独转录后再加入提示中。

更重要的是，视频帧所表达的空间运动信息，在观看静态图像时会丢失。VLM 通过在视频片段上进行训练来理解这一时间维度，因此高质量推理通常需要在单次模型调用中处理整个视频片段。

一秒钟的电影视频包含24帧，每帧都是一张图像。如果一张高清输入图像需要约1,000个token来表示，那么一个四秒的视频片段将产生近100,000个token的输入序列。

实际上，视频输入并不会生成如此长的输入序列——降采样几乎是必不可少的。

降低分辨率和帧率使得在单次推理请求中评估整个视频片段成为可能，尽管视频理解模型目前仍只能处理非常短的片段。

在视频被分词和编码之后，推理过程与处理图像类似，只是上下文要长得多。前缀缓存、KV缓存卸载以及优化的注意力实现，对于这些数万token的输入序列而言，显得尤为重要。

6.1.2 全模态模型

视觉语言模型是向”全模态”模型发展趋势中的重要组成部分，这类模型能够接受多种类型的输入并产生多种类型的输出。全模态模型有其优缺点——多种模态的融合提供了独特的能力，但在特定领域中，较小的专用模型通常速度更快、精度更高。

例如，许多视觉语言模型在其图像输入处理中内置了文本识别能力。然而，这些能力落后于专用的光学字符识别（OCR）模型，而后者的体积通常只有前者的一小部分。

在视觉语言模型上运行生产推理，通常需要协调由多个模型和预处理步骤组成的流水线。你可能需要独立的预处理器来从PDF中提取数据、通过OCR从图像中读取文本，或对视频中的音频进行转录。

流水线中的每个组件都必须单独进行速度优化，并且应能独立扩展以避免出现瓶颈。

6.2 嵌入模型

嵌入模型将可变长度的文本块——或图像等其他模态的输入——转换为固定长度的向量表示，以捕捉输入的语义含义。

通过将内容编码到这一共享的语义向量空间中，你可以用简单的数学方法比较各项目之间的距离。嵌入模型（以及向量数据库）被用于构建智能体记忆、RAG、搜索和推荐系统。

为了支持这些应用场景，嵌入模型的推理工作负载具有两种不同的流量模式：

1. 高吞吐量批量回填：批量操作，例如对数百万文档建立索引、更新产品目录，甚至为大语言模型预训练准备数据。

2. 低延迟查询：面向用户的单次搜索、检索或推荐查询，每一毫秒都会影响用户体验。

嵌入模型的推理工程首先需要明确你需要服务的是哪种流量模式。如果两种模式都需要支持，且流量足以证明其成本合理，那么最好为每种使用类型分别构建独立的系统。

6.2.1 嵌入模型架构

Hugging Face 上有数以万计的嵌入模型，但它们都采用以下两种基于 Transformer 的架构之一：

• BERT 风格模型：仅编码器的神经网络，参数量通常小于 1B，最初为掩码标记预测任务而构建。

• 基于 LLM 的模型：现代语言模型，参数量通常不超过 8B，被改造用于生成嵌入向量。

目前，基于 LLM 的嵌入模型提供了更强大的能力，但 BERT 风格模型仍用于对延迟敏感的简单任务，如分类任务。

嵌入模型在嵌入维度（即输出向量的大小）方面引入了其自身的速度与质量权衡。嵌入向量包含数百到数千个值，向量越长，编码的信息越多。

现代嵌入模型使用 Matryoshka 表示法，在嵌入维度与质量之间实现动态权衡，同时在较短的向量中保留更多信息。维度对推理时间没有实质性影响，但会影响系统内的存储、检索和相似度计算时间。

在大多数情况下，来自不同嵌入模型的向量之间无法进行有意义的比较，即使它们长度相同，因为它们将输入编码到了不同的语义空间中。

6.2.2 嵌入模型推理

对于以大语言模型为骨干的嵌入模型（如 Qwen 3 Embed 8B），推理优化与其他小型大语言模型的高吞吐、低延迟部署共享通用工具和技术。

文本嵌入模型有多种运行时环境：vLLM、SGLang、Infinity、TEI（Hugging Face 的文本嵌入推理框架）。但最佳性能来自于对 TensorRT-LLM 的适配以运行这些模型。

TensorRT-LLM 引入了优化的 XQA 内核以实现快速注意力计算，并采用内核融合技术来降低内存访问开销。对于受支持的模型，TensorRT-LLM 在延迟和吞吐量两方面均是性能最优的推理引擎。

量化可带来进一步的性能提升。虽然较小的模型更容易因量化而损失质量，但对嵌入模型权重进行 FP8 量化可在质量损失极小的情况下提升性能。

量化后检验嵌入模型质量最简便的方法是：对原始模型和量化模型输入相同数据，然后检查输出向量的余弦相似度。余弦相似度为百分之百意味着向量完全相同；若要对量化结果有信心，相似度至少需达到 99%。

由于嵌入模型并行处理 token，前缀缓存和分离部署并非相关优化手段。考虑到这些模型体量较小，跨多个 GPU 的并行计算也并不高效。相反，高流量部署应采用水平扩展方式，每个 GPU 作为独立副本运行。

在嵌入模型的高流量部署场景中，批处理和排队机制对性能起着重要作用。嵌入模型支持远高于其他模型的批处理规模。单个请求可将数十甚至数百个文本输入以列表形式打包成一批，且即便是需求最高的嵌入模型也相对轻量快速，因此单个 GPU 可并行处理多个请求。

无论是执行大规模数据回填还是应对流量激增，流量都可能超出嵌入模型所能承载的大批处理规模。在这种情况下，一套健壮的排队系统是支撑嵌入模型推理的必要基础设施。

6.3 ASR 模型

自动语音识别（ASR）模型以音频作为输入，生成文本作为输出，为转录和听写应用提供支持。最受欢迎的开源 ASR 模型是 Whisper，由 OpenAI 发布。Whisper 支持数十种语言，具有精准的转录能力。

Whisper 有多种规格，但最大、质量最高的 Whisper 模型仅有 15.5 亿参数。Whisper 通过多实例 GPU（MIG）技术，在 H100 等大型 GPU 的部分资源上运行速度极快。尽管存在各种其他规格、变体、蒸馏版本和量化版本，但在实际应用中，使用最高质量的模型——Whisper 3 Large 和 Whisper 3 Turbo——即可满足大多数延迟预算需求。

Whisper 是一个编码器-解码器模型：

• 编码器：以处理后的音频波形（对数梅尔频谱图）作为输入，并将其编码为音频特征。

• 解码器：将这些编码后的音频特征转换为文本词元。

绝大部分推理时间消耗在解码器上，其架构与大语言模型（LLM）非常相似，是一种自回归 Transformer 模型。幸运的是，目前已有出色的工具可用于优化这一主要瓶颈。

解码器侧性能优化的主要工具是 TensorRT-LLM。借助 TensorRT-LLM，您可以为解码器实现动态批处理，并获得配备高效 CUDA 内核的优化 C++ 运行时。TensorRT-LLM 与 Hopper 和 Blackwell 等近期架构配合尤为出色，使 MIG 成为 ASR 推理的更佳选择。

6.3.1 单块延迟优化

Whisper 的一个使用场景是实时转录，例如在听写应用或语音助手中。

对于实时 Whisper，需要关注单个音频块完成转录的往返时间。一个理想的目标是 200 毫秒，这也是人类的平均反应时间。

在经过优化的 TensorRT-LLM 推理引擎上运行 Whisper 时，在运行时层面能做的性能优化工作并不多。相反，实时 Whisper 的大部分性能提升来自于编排和基础设施层面。

在 ASR 产品体验上最大的提升是流式处理，它在 API 服务层而非模型运行时层实现。通过建立 WebSocket 连接（第 7.5.3 节）并持续地流式传入音频、流式传出文本，产品可以实现实时转录，而不必等待预录制音频完成后再进行转录。

在 ASR 运行时层，一切保持不变。转录的流式实现采用语音活动检测（VAD）模型来监听传入的音频流，并将其分割成离散的音频块供 ASR 模型处理。推理过程照常在各音频块上运行，文本结果则通过 WebSocket 流式返回。

这一架构可以处理多个并发流，并且具有保持转录顺序性的优势。当每个音频块在同一 GPU 上处理时，可以将前一个音频块的输出序列作为下一个音频块的前缀，从而提升转录质量。

6.3.2 长文件延迟优化

Whisper 模型的一个局限性在于它只能支持 30 秒的音频块。转录长文件（如长达一小时的播客）需要一套不同的优化方案。

使用一个名称容易引起混淆的指标——实时因子（RTF）来衡量长文件转录的性能。如果世界上最快的打字员能在 30 分钟内手动转录一小时的音频，其 RTF 为 2X。而使用针对长文件优化的 Whisper 部署方案，可以在不到四秒的时间内转录一小时的音频，RTF 高达 1000X。

对长文件进行快速转录需要一个多步骤的处理流水线。第一步同样是使用 VAD 模型，这次在其专用硬件上独立运行。该模型用于去除静音并切分出有意义的音频片段，而非按时间间隔进行分割——后者存在将单词切成两半的风险。

然后，这些音频块可以被并行处理。理想情况下，使用多个 GPU（或多个 MIG）同时处理更多音频块。RTF 的提升与所用 GPU 数量大致呈线性关系。每个 GPU 通过动态批处理同时处理多个音频块，以实现高利用率。

最后，按时间戳将分块转录结果拼接在一起。

并行化块转录使得无法将前一序列作为下一序列的前缀。但其他质量改进技术足以弥补这一不足。

对于 ASR 输出，可以通过测量输出的压缩比和每分钟词数来自动检测幻觉现象，例如重复的单词和短语。当某个音频块出现问题时，可以：

1. 以更高的温度重新运行该块。这看似违反直觉——较高的温度通常会产生更多幻觉——但其目的是打破重复词语的循环，从而生成不同的输出结果。
2. 将整段音频或其中某个片段重新切分为更小的块，并重新运行转录。

在实践中，这些技术消除了将前一序列作为前缀传递的需求，从而实现了对长文件高效且准确的并行转录。

6.3.3 说话人日志（Diarization）

说话人日志，即在转录文本中标注每段话是由谁说的，是一个与语音转录相邻的问题。说话人日志模型通过声音特征对音频进行分类，然后对文件进行分段和聚类，从而标记出说话人变化的时间戳。

说话人日志模型是一类完全不同的模型。Whisper 是一种编码器-解码器 Transformer 模型，而 pyannote audio 等说话人日志系统则是由经典机器学习模型组成的流水线。

说话人日志流水线包含用于分割、嵌入和聚类的模型。要优化说话人日志处理，需要快速运行每个模型，并高效地协调整个流水线。

由于说话人日志是一个机器学习流水线，您可以使用 PyTorch 和 pyannote 等工具，并结合 Torch 编译等优化手段来提升其性能。实际上，即使是高度优化的说话人日志实现，处理一个音频文件所需的时间也至少是语音转录的两倍。

6.4 TTS 模型

文本转语音（TTS）模型，也称为语音合成模型，以文本作为输入，生成音频作为输出，专门用于生成语音。2025 年，Orpheus TTS 等开放模型将极其逼真的语音合成引入了开放模型生态系统。许多公司对 Orpheus 进行了微调，以提升音质并生成特定产品的声音，从而推动了开放模型在语音 AI 领域的广泛应用。

现代 TTS 模型是经过微调的大语言模型（LLM）。例如，Orpheus TTS 衍生自 Llama 3.2 3B。这意味着许多为 LLM 开发的运行时和性能优化方法同样适用于语音合成模型。

TTS 模型的参数量较小——Orpheus TTS 拥有 30 亿参数，已属较大规模——这意味着与 ASR 模型类似，H100 上的 MIG 是高效且性能出色的推理选项。

与通常以 FP16 运行的 ASR 模型不同，TTS 模型的权重和 KV 缓存可以量化为 FP8，以获得更好的性能，此外还可利用 TensorRT-LLM 推理引擎引入的优化内核和动态批处理功能。

基于 LLM 骨干网络的 TTS 模型，通过将 LLM 的词汇表扩展数万个编码音频 token 来进行训练。然后，使用文本输入与 token 化音频输出的配对数据对模型进行训练。这意味着在实际使用 TTS 模型时，还需要一个音频解码器，将音频输出 token 转换为波形。

这一音频解码过程可能成为推理的潜在瓶颈。音频解码器应使用 PyTorch 实现，并针对目标 GPU 编译以实现高效运行，同时应使用动态批处理并设置较短的超时时间（例如 15 毫秒）。音频解码器不支持动态批处理（In-flight batching）。

TTS 模型的性能采用与 LLM 略有不同的指标来衡量。关键指标包括：

• TTFB：首字节时间（TTFB）相当于语音合成中的首 token 生成时间（TTFT）。

• 首句生成时间：与 TTFB 相比，一个更面向用户的延迟指标是生成第一个有意义短语或句子所需的时间。

• TPS：与 LLM 类似，TTS 模型以 token 为单位生成内容，因此解码速度可以用每秒 token 数来衡量。

与 LLM 的 TTFT 目标一致，语音合成的目标也是尽量降低 TTFB。对于 Orpheus，在单张 H100 上最低可达 150 毫秒。

然而，语音合成模型在 TPS 方面有不同的目标。模型生成的 token 会被转换为音频波形。根据不同模型，可能需要每秒 80 到 100 个 token 才能实时生成音频。超过这一水平后，继续提升每秒 token 数并不会带来额外收益。

因此，性能提升的重点在于扩展吞吐量，即模型能够同时支持的实时输出数量。如果单张 GPU 能够支持大量并发用户，语音合成的单用户成本将大幅降低。

6.4.1 流式实时文本转语音

大多数 TTS 任务都需要实时语音合成。

与 ASR 模型类似，实时系统的性能提升较少来自运行时层面。该层通常已经通过 TensorRT-LLM、量化和编译后的 SNAC 解码器完成了优化，更大的收益往往来自基础设施编排。

同样，通过 WebSocket 进行流式传输，通常比按离散数据块发送文本、再接收音频更能改善用户体验。在测试推理引擎、确定它可以支持多少个并发实时流之后，应将批处理大小与活跃 WebSocket 连接数设置到相近水平，以维持高而稳定的利用率。

TTS 模型很少用于非实时应用。不过，如果您确实遇到批量使用场景，例如将大量文档语料库回填为音频以提高可访问性，请注意 TTS 模型对长输入的处理效果不佳，语音质量在 30 秒左右之后就会开始下降。

6.4.2 语音到语音模型

一个令人兴奋的研究领域是语音到语音模型，即以音频作为输入并生成音频作为输出的模型。

目前，大多数语音系统采用级联方式，其中 ASR 模型、LLM 和 TTS 模型在流水线中协同工作，以实现对用户的聆听、思考和响应。这些流水线还采用 VAD 和嵌入模型等辅助组件，以促进自然对话并添加上下文信息。

语音到语音模型（如OpenAI的gpt-realtime）在核心LLM的基础上增强了音频输入和输出能力，有效地将整个流水线统一在单一模型中。这得益于ASR、LLM和TTS具有极为相似的架构，尤其是在解码器部分。

截至本文发布时，尚无具有商业可行性的开源语音到语音模型，而gpt-realtime等闭源方案在能力上明显不及级联多模型方案，且成本更高。然而，该领域的研究十分活跃，这一新兴模态很快将需要其专属的推理工程方法。

6.5 图像生成模型

与大型语言模型相比，图像和视频生成模型在多个维度上都截然不同。

首先是架构。尽管一些近期模型（如 HunyuanImage-3.0）与 LLM 更为相似，但大多数图像和视频生成模型仍是迭代去噪器，而非自回归令牌生成器。

图像生成系统通常不是像 LLM 那样的统一解码器，而是多个小型模型在潜在空间中协同工作的流水线。因此，相关工具链也不同。在本书出版时，SGLang Diffusion 和 vLLM Omni 都还是很新的产品；大多数图像和视频生成模型的推理实现仍位于更底层的技术栈中，直接使用 PyTorch 或 TensorRT。

约束条件也不同。图像生成模型通常比前沿语言模型小十到二十倍，推理瓶颈在于计算资源，而不是带宽。

但最显著的差异或许在于，这类模型提供了更直接的质量与速度权衡。

以编程方式评估图像模型的输出质量非常困难。基于视觉语言模型的自动化评测流程，充其量只能提供方向性信号，而且可能与人类偏好存在偏差。图像质量判断高度主观，因此大多数评估工作仍需要邀请人类在数千张图像中进行选择，并通过汇总这些主观偏好来建立质量基准。

6.5.1 图像生成内核优化

当你从模型仓库中阅读某个图像生成模型的模型卡时，推理示例通常使用 diffusers 库，且几乎没有任何优化。

事实上，虽然图像生成在理论上受计算量限制，但你往往需要选择内存高效的内核并使用内核融合，才能真正触及这一瓶颈。

高性能图像模型推理通常使用以下三个库之一：

• SGLang Diffusion：专为流行的图像和视频生成架构构建的高性能推理引擎。

• TensorRT：基于 NVIDIA 内部内核的流行模型高质量黑盒实现。

• PyTorch：通过精心的内核选择与融合，实现对性能的掌控、灵活性以及更优的高端表现。

如果你希望立即获得效果良好的方案，直接使用 SGLang Diffusion 或 TensorRT 的模型实现即可。但使用 PyTorch 时，高级推理工程师有机会进行深度定制。

最核心的内核是注意力内核。许多图像生成模型开箱即用 FlashAttention 2，但 FlashAttention 3 和 FlashAttention 4 分别在 Hopper 和 Blackwell GPU 上表现更佳。

还有一大批较小的内核，尤其是像 RMSNorm 这样的归一化函数，是进行融合的理想候选，有助于确保高效的内存使用。

此外，GEMM 内核对于计算密集型推理至关重要。GEMM 内核适用于线性层，通常可以安全地量化为 8 位浮点格式，从而在张量核心上获得两倍的 FLOPS。来自 CuTe、CUTLASS 或 DeepGEMM 的内核可能在不同模型上各有优势。

Torch 编译支持自动内核融合，并提供插件系统用于插入手动选择的内核，编译生成的引擎可以缓存，以加快节点启动时的加载速度（这一点很重要，因为编译需要数分钟时间）。

与大多数高性能引擎一样，Torch 编译会针对执行编译的特定 GPU 型号和架构进行优化——如果你想在 B200 上运行模型，请在 B200 上进行编译。

6.5.2 加速图像生成的一个奇妙技巧

内核选择和 Torch 编译都是正儿八经的推理优化技术。但推理优化的世界里也有一些有趣的小技巧，下面就介绍其中一个。

图像生成时间与步骤数成线性关系。这就是为什么少步模型和潜在一致性模型比完整的 50 步模型快得多。但减少步骤数可能会使图像质量降低到不可接受的程度。

每次通过去噪模型时，批量大小为 2，因为每个步骤都包含一次有提示引导和一次无提示引导的处理。

作为复习，引导参数控制在合并每个步骤生成的两个迭代结果时，提示引导图像的权重比例。如果引导值为零，则无需生成提示引导图像。

经过最初几个步骤后，图像的基本轮廓已经确定，其余步骤用于填充细节。因此，提示词的遵循在影响图像大致轮廓的早期步骤中更为重要——模型不会在后期步骤中改变主意，在生成猫的过程中突然生成一只狗。

如果在图像生成进行到一半时关闭引导，就可以在不减少步骤数的情况下节省通过去噪器的次数。如果在 50 步运行的最后 20 步跳过引导，则模型只需通过 80 次而非 100 次，而图像质量通常仍然保持较高水平。

6.6 视频生成模型

视频生成是需求最高的模态。在条件允许的情况下，这些模型应在 Blackwell GPU（或 Rubin，一旦可用）上运行。这些 GPU 提供高内存容量以支持上下文并行（Context Parallelism），具备快速的张量核心（Tensor Cores）用于注意力计算，以及支持更精确量化的微缩放数据格式。

在架构上，视频生成与图像生成类似，只不过是从潜在空间渲染完整视频，而非单帧图像。遵循”更大规模解锁更多技术”的原则，视频生成使用与图像生成相同的所有技术，并在此基础上增加了额外的优化。

与图像生成一样，视频生成受计算资源限制，通过对潜在空间进行迭代去噪来实现。视频生成模型的去噪步骤数量与图像生成模型大致相同（约50步），但每一步处理的数据量要多得多。

由于视频生成模型受计算资源限制，批处理并不像文本生成那样有用。视频生成模型通常在八块 GPU 组成的完整节点上运行，批量大小为1：八块 GPU 协同工作，每次生成一个视频。

与批量工作负载不同，后者可以通过调整批量大小在延迟和吞吐量之间进行权衡，而提升视频生成吞吐量和降低成本的唯一途径是让模型本身运行得更快。

早期的视频生成模型是逐帧生成的，即一次生成一帧。这降低了视频输出的质量和连贯性。如今，视频生成模型在潜在空间中对整个视频执行去噪步骤。图像生成的潜在空间表示二维（宽度、高度），而视频模型的潜在空间则表示三维（宽度、高度、时间）。

这意味着每次注意力计算都需要传递大量数据。对于视频模型而言，注意力计算占总计算时间的70%至80%，因此注意力机制是最重要的优化对象。

6.6.1 注意力优化与量化

注意力优化从内核选择开始。测试 FlashAttention、DeepGemm、CuTe 和 CUTLASS 内核，以确定哪些内核对您的模型表现最佳。

语言模型使用 KV 缓存来加速注意力计算，而视频生成模型则使用其他缓存模式来尝试复用模型输出。在实践中，复用部分注意力计算可以使视频生成速度提升 30% 到 40%。

具体方法和算法随着新研究的出现而不断变化，但缓存有两种基本方式：

• 基于时间步的缓存：缓存并复用某些时间步的输出，以跳过整个步骤。
• 基于 Transformer 的缓存：缓存并复用隐藏状态，以跳过 Transformer 内部的某些层。

各类算法和实现的质量损失从可忽略不计到完全不可用不等——在将这些策略用于生产环境之前，请务必仔细测试。

除了内核和缓存之外，加速注意力计算的主要手段是量化。

对于受带宽限制的语言模型推理，量化的好处在于减少了需要从内存加载的数据量。对于视频模型，量化意味着通过切换到低精度张量核心，可以访问双倍的 FLOPS。

然而，语言模型量化侧重于权重——即大型线性层，量化对这些层的影响可以忽略不计。对于视频模型，量化权重仍然有帮助，但尽管这些层占用了大部分内存带宽（这是制约语言模型的瓶颈），它们在视频模型的计算时间中只占很小一部分。

相反，视频模型上的量化侧重于注意力机制。注意力是任何模型中量化风险最高的部分，因为误差会在推理过程中不断累积。对于视频模型，推理步骤约为 50 步，而非 token 生成中数千次的自回归迭代，因此风险略低，但仍不可忽视。

降低质量影响的第一种方法是使用分块量化和微缩放数据格式（MXFP8），这两者在 Hopper 和 Blackwell 架构上均可使用。微缩放数据格式能更好地保留异常值，而异常值对注意力精度有重大影响。

最复杂的注意力量化方法是在模型内部进行选择性量化，具体包括：

• 按步骤：将早期步骤保持为 FP16，对后期步骤进行量化。
• 按层：保持第一层和最后一层不变，对隐藏层进行量化。

按步骤量化遵循与图像生成模型中无分类器引导技巧相同的洞见：早期步骤确立图像的整体轮廓，而后期步骤则细化细节。这些早期步骤对提示词遵循度和准确性更为重要。

对于层而言，第一层和最后一层更为重要，因为它们负责接收输入并产生最终输出。隐藏层只执行中间计算，受近似处理的影响较小。

通过仅对视频生成过程中不那么重要的部分进行量化，可以保持输出质量。这些策略体现在 SageAttention 等内核中——这是一个 8 位注意力内核，可用于视频生成模型上的高质量低精度注意力计算。

6.6.2 上下文并行

虽然视频生成模型通常运行在配备八块GPU的完整节点上，但它们使用的是上下文并行（Context Parallelism），而非张量并行（Tensor Parallelism）。

上下文并行将模型权重复制到每块GPU上。视频模型的体量足够小，将权重复制八份虽然会占用相当数量的内存，但在B200上是可行的。

上下文并行并非将模型拆分到各GPU上，而是通过将注意力计算分配到各GPU来实现并行。这一过程通过环形注意力（ring attention）等机制进行协调——每块GPU持有一部分上下文，并将中间结果传递给环中的下一块GPU。

Transformer模型的注意力机制采用多头形式，通常具有八个或更多注意力头。由于注意力头之间相互独立，它们可以分别运行，最后再合并结果。

能够并行化的不仅仅是注意力计算。例如，使用变分自编码器（VAE）进行隐空间解码的步骤占总推理时间的3%至5%，同样可以跨GPU并行执行。

这些并行技术使AI视频生成成为可能。随着视频序列越来越长、视频模型越来越大，并行技术将继续成为视频生成模型推理中最关键的技术手段。