Best practice of Blackwell GPU deployment in the Chinese market

何平, NVIDIA TensorRT团队 高级工程师
张一林, NVIDIA GPU加速计算专家团队 高级工程师
AI Open Day 20251107

目录

  1. 议程
  2. NVIDIA RTX PRO GPU* 概述
  3. 硬件背景:Blackwell 架构
  4. DeepSeek R1 优化

  5. TRT-LLM 中的 MoE 后端

  6. MoE 中的通信优化

  7. AIGC-Text2Image

  8. AIGC-Text2Video

议程

  • TRT-LLM 中 DeepSeek R1 的优化
  • TRT-LLM 中的 MoE 后端
  • MoE 中的通信优化
  • AIGC-T2I
  • AIGC-T2V

NVIDIA RTX PRO GPU* 概述

  • 本演示文稿概述了 NVIDIA RTX PRO GPU 的开发和优化策略,这些策略基于 Blackwell 架构,重点关注 TensorRT/TensorRT-LLM 的性能增强。RTX PRO GPU 代表了 GPU 技术的重大进步,旨在应对大型语言模型 (LLM) / 人工智能生成内容 (AIGC) 推理的独特挑战。

注:仅供技术讨论和参考,可能因不同产品组合而异。

硬件背景:Blackwell 架构

  • Blackwell 架构引入了几个驱动我们优化策略的关键特性:
    • 内存约束:设计用于通过高级量化支持实现高效的内存使用。
    • 计算能力:增强了对 FP4 低精度计算的支持。

DeepSeek R1 优化

NVFP4 量化

技术理据

  • 内存限制:Blackwell GPU 设计优先考虑效率而非原始内存带宽。
  • 精度研究:FP4 在模型质量和内存使用之间提供了最佳平衡。
  • 量化策略:专注于 DS-R1 输出投影层/MoE GEMM,其中精度影响最小。
  • 集成:与 TensorRT-LLM 的量化流程无缝集成。

在 DeepSeek R1 上的 NVFP4 量化

  • 模型: nvidia/DeepSeek-R1-0528-FP4-v2 (NVFP4 MoE GEMMs + NVFP4 wo gemm)
  • wo_gemm (输出权重矩阵) 在不分片的情况下占据总权重的 1.07%,但在分片的情况下会占据 29.45%。
  • 基于精度研究,对 wo_gemm 检查点使用 NVFP4 量化,为 Blackwell GPU 内存约束进行了优化。
Page 7
Page 7

NVFP4 量化的优势

  • 优势:
    • 量化层的模型大小减少约 75%。
    • 以最小的精度下降维持了模型质量。
    • 使得更大的模型能够适应内存限制。
    • 由于内存带宽需求降低,推理速度得到提升。
Page 8
Page 8

FP8 上下文多头潜在注意力 (MLA)

  • 在上下文阶段使用 FP8 MLA 替代 BF16,以优化 Blackwell GPU 上的内存使用和计算效率。
  • 技术细节:
    • 与 BF16 相比,FP8 量化将内存占用减少约 50%。
    • 在内存约束内实现更长序列的处理。
    • 针对内存带宽至关重要的上下文阶段进行了优化。
    • 支持连续和分页的 KV 缓存布局。
    • 与 TensorRT-LLM 的注意力机制集成。

多头潜在注意力公式

Page 10
Page 10

SM120 上的 FP8 MLA 计算流程

此图展示了在上下文 (Context) 阶段和生成 (Generation) 阶段,数据如何在 BF16 和 FP8 精度之间转换和计算,以实现 FP8 MHA (多头注意力) 和 FP8 MQA (多查询注意力)。

Page 11
Page 11

FP8 上下文多头潜在注意力 (MLA) 的优势与用法

  • 优势:

    • 降低内存带宽需求。
    • 在长上下文场景下提高吞吐量。
    • 更好地利用 Blackwell 的计算能力。
  • 用法:

    • 启用 FP8 kv 缓存将自动启用 FP8 ctx/gen MLA。
    • python ./examples/llm-api/quickstart_advanced.py --kv_cache_dtype fp8
    • extra-llm-api-config.yml 中应用 --extra_llm_api_options:
kv_cache_config:
  dtype: "fp8"
Page 12
Page 12

用于 MQA/GQA 的 XQA 生成核 (Kernels)

XQA 设计目标

  • 最大化 DRAM 吞吐量: 为生成阶段优化内存访问模式。
  • JIT 编译: 参数在编译时可用,以实现最佳性能。
  • 快速 JIT 编译: 最小化 C++ 模板使用和头文件包含。
  • 张量核心加速: 利用先进的张量核心操作。

XQA 技术实现

  • 利用 Blackwell 特性: 增强的 TMA / 动态寄存器分配。
  • 通过 NVRTC 进行 JIT 编译: 实现运行时优化。
  • 多块执行: 提高 GPU 占用率。
  • 与 TensorRT-LLM 的注意力流程集成

性能影响

  • Blackwell XQA 在 SM120 上的表现:DRAM 82%,TensorCore 78% SOL(Speed of Light)比例,针对 FP8 MLA 内核。
  • 与 fmha_v2 内核相比,端到端(e2e)性能提升约 20%。
Page 16
Page 16

分离式服务 (Disaggregated Serving)

  • 分离式服务组件:
    • Prefill 服务器: 专用于提示(prompt)处理和 KV 缓存生成的 GPU。
    • Decode 服务器: 针对逐个令牌(token-by-token)生成进行优化。
    • Orchestrator(编排器): 管理请求路由和 KV 缓存分发。
    • 通信后端: 使用 UCX/NIXL 实现高效的 GPU 间通信。
    • 方法: trtllm-serve/Dynamo/Triton Inference Server。

采用流水线并行机制的 Prefill 服务器

  • 描述: 使用分块流水线并行(Chunked Pipeline Parallelism, CPP)为 prefill 阶段实现 prefill + decode 分离式服务。
  • 架构原理:

    • 内存带宽限制: 有限的内存带宽限制了单 GPU 的性能。
    • P2P 带宽约束: 有限的点对点带宽限制了 GPU 间的通信。
    • 阶段分离: 上下文(Context)阶段和生成(generation)阶段具有不同的计算特性。
    • 分块 Prefill: 通过将上下文拆分成可管理的块来有效处理长序列,以减少首个令牌生成时间(TTFT)。
  • 实现:

    • 将层(layers)拆分成 P 个分区。
    • 权重内存减少 P 倍。
Page 19
Page 19

使用 trtllm-serve 实现分离式服务

# 启动 PP8 context 服务器
trtllm-serve ${model} --host xxx --port xxx --tp_size 1 --ep_size 1 --pp_size 8 ...

# 启动 TEP8 generation 服务器
trtllm-serve ${model} --host xxx --port xxx --tp_size 8 --ep_size 8 --pp_size 1 ...

# 启动分离式服务器
trtllm-serve disaggregated -c disagg_config.yaml

参考资料: https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/blogs/tech_blog/blog5_Disaggregated_Serving_in_TensorRT-LLM.md

TRT-LLM 中的 MoE 后端

Page 21
Page 21

什么是 MoE(混合专家模型)

MoE (Mixture-of-Experts) 模型是一种神经网络架构,由称为专家的多个专业化子模型和一个门控网络组成,该门控网络为每个输入动态选择要激活的专家。这使得模型可以在专家之间分配任务,比稠密模型更有效地处理数据。

  • 由处理特定数据或任务的专家网络和路由输入的门控网络组成。
  • 每个输入仅由少数专家处理,减少了计算负载。
  • 模块化结构提高了可扩展性和可解释性。
  • 每个专家学习不同的能力,增强了在不同数据上的性能。
Page 22
Page 22

MoE 模型的并行策略

如果 MoE 模型无法容纳在单个 GPU 的内存中,则必须在多个 GPU 上进行并行化。通常,MoE 层有三种并行策略:TP(张量并行)、EP(专家并行)以及两者的混合。

张量并行 (Tensor Parallel)

张量并行将每个专家的权重均匀地拆分并分发到不同的 GPU 上,这意味着每个 GPU 持有所有专家的部分权重。TP 组中的每个 GPU rank 接收所有令牌(tokens)对所有专家的隐藏状态,然后使用部分权重进行计算。

Page 23
Page 23

专家并行 (Expert Parallel)

专家并行将一些专家的完整权重均匀地分发到不同的 GPU 上,这意味着每个 GPU 持有部分专家的完整权重。每个 GPU rank 仅接收发往其 rank 上专家的令牌的隐藏状态,然后使用完整权重进行计算。

Page 24
Page 24

混合并行 (TP + EP)

当同时启用 TP 和 EP 时,每个 GPU 处理一部分专家权重矩阵(如 EP 模式),并且这些权重会进一步在多个 GPU 之间切分(如 TP 模式)。这种混合方法旨在更均匀地平衡各个 GPU 的工作负载,从而提高效率并减少仅使用 EP 模式时可能出现的瓶颈。

Page 25
Page 25

注意力数据并行 (ADP)

在最大吞吐量场景下的 DeepSeek MLA + MoE 架构中,通常采用注意力数据并行(Attention Data Parallel, ADP)+ MoE 专家并行(EP)策略来消除冗余的 KV 缓存存储。

选择注意力 DP 的直觉在于,它为 MLA 执行 TP(其中不同的 GPU 计算不同的注意力头)会复制 KV 缓存内存,这限制了系统可以实现的并发性。复制因子等于 TP 组的大小,例如 TP8 时为 8x。对于像 NVIDIA Blackwell 这样的强大系统,小的并发性会损害吞吐量。

不同 rank 在 MoE 层接收不同的令牌

Page 26
Page 26

TRT-LLM 中的 MoE 后端:CUTLASS vs WIDEEP

在 TensorRT-LLM 中,MoE 后端支持多种选项。默认后端是 CUTLASS,它专注于单节点或小规模专家并行的优化,而 WIDEEP 是我们专为大规模 EP 设计的。

CUTLASS WIDEEP
Communication op All2all 仅支持 MNNVL;AG+RS 用于其他情况 All2all 支持 MNNVL, DeepEP, DeepEP LL;
EPLB static (静态) dynamic (动态)
Page 27
Page 27

MoE 中的通信优化

Page 28
Page 28

MoE 中通信操作的选择:AG/RS vs all2all

Message_AG/RS = (ep_size - 1) * token_num * hidden_dim

Page 29
Page 29

ep_size 大于 top_k 时,all2all 的消息大小将优于 AG/RS。
all2all 的消息大小不会随着 ep_size 的增加而增加。

Message_AG/RS = (ep_size - 1) * token_num * hidden_dim

Message_all2all = ((ep_size - 1) / ep_size) * top_k * token_num * hidden_dim

Page 30
Page 30

MoE 中 all2all kernel 的选择

NCCL all2all

NCCL all2all kernel 假设每个 rank 发送/接收的消息大小是相同的。然而,在 MoE 层中,专家之间的工作负载并不均衡,这会引入额外的开销。

ncclAlltoAll 是一种变体,它允许工作负载不均衡的情况:
- 每个 rank 向所有其他 rank 发送计数值,并从所有其他 rank 接收计数值。
- 发送到目标 rank j 的数据取自 sendbuffj*count 位置,从源 rank i 接收的数据放置在 recvbuffi*count 位置。
- 注意:这假设总的发送和接收计数值等于 cranks*count,这意味着 sendbuffrecvbuff 的大小至少为 cranks*count 个元素。
- 目前不支持原地(in-place)操作。

Page 31
Page 31

DeepEP normal vs LL

下图比较了 DeepEP 的两种模式:普通模式和低延迟(LL)模式。

  • DeepEP 普通模式:节点内通信通过 PCIE/NVLINK 进行。节点间通信通过 RDMA,从一个节点的主 GPU(如 Node A 的 GPU0)到另一个节点的主 GPU(如 Node B 的 GPU0)。
  • DeepEP 低延迟模式:节点内通信也可以使用 RDMA。节点间通信是直接的,每个 GPU 通过 RDMA 与另一个节点上对应的 GPU 通信,形成跨节点的 all-to-all 通信模式。
Page 32
Page 32

两种模式的特点如下:

  • 普通模式 (Normal mode)

    • 为长序列输入提供高吞吐量,主要面向训练或预填充(prefill)推理。
    • 在节点间通信期间对 token 进行去重处理。
    • 节点内通信需要点对点(peer-to-peer)访问。
  • 低延迟模式 (Low latency mode)

    • 面向对延迟敏感的推理解码。
    • 每个 rank 直接将 token 发送到目标 rank。
    • 节点内通信也可以使用 RDMA。

拓扑结构 (Topology)

在 RTX PRO GPU 上,点对点访问的延迟可能非常高,因为它可能需要跨越 PCIe 以及 NUMA 节点之间的 SMP 互连。下图展示了一个典型的服务器拓扑结构,包含多个 GPU、CPU、PCIe Switch 和 NIC。

Page 34
Page 34

DeepEP LL 的优化

默认精度 (Default precision)

  • 低延迟分发 (Low latency dispatch) 支持 bf16 数据输入,在通信前将其量化为 fp8(使用 fp32 scale,block_size=128)。
  • 低延迟合并 (Low latency combine) 仅支持 bf16 的 IO 和通信。

如下表和流程图所示,不同的 MoE 后端(CUTLASS vs WIDEEP)采用不同的数据处理流程。即使在 ep_size=32 的情况下,由于数据类型差异导致的消息大小增加4倍,也可能会抵消 all2all 带来的算法优势。

Page 35
Page 35

随着专家并行(EP)规模的增加,通信(comm)所占的比例显著上升,使得通信内核的优化至关重要。下图比较了 CUTLASS 和 WIDEEP 在不同 EP 规模下各计算部分(gemm、attn、comm 等)的时间占比。

Page 36
Page 36

Nvfp4 量化

在从 bf16 到 nvfp4 的量化过程中,首先计算 fp32 的 per-tensor scale,然后计算 fp8 的 pre-block scale(block_size=16)。通过这种方式,数据大小可以减少到原始大小的 28%。

NVFP4 (E2M1) 格式包含1位符号位,2位指数位和1位尾数位。

Page 37
Page 37

性能与精度 (Perf & Accuracy)

下图展示了不同配置下的每步延迟。与 CUTLASS 和 WIDEEP-bf16 相比,使用 nvfp4 量化的 WIDEEP(WIDEEP-nvfp4/bf16/C)显著降低了通信开销,尤其是在高专家并行(EP)规模下。

Page 38
Page 38

在吞吐量(TPS/GPU)方面,WIDEEP_nvfp4dispatch/combine 在各种 EP 规模下均表现出最高的性能。

Page 39
Page 39

下表展示了 ep_size = 8 时的精度结果。与基线相比,使用 nvfp4 量化对 gsm8k 平均准确率的影响很小。
- WIDEEP (bf16/bf16): 95%
- WIDEEP (nvfp4/bf16): 94.01%
- WIDEEP (nvfp4/nvfp4): 94.92%

Page 40
Page 40

AIGC-Text2Image

Page 41
Page 41

Text2Img 扩散模型

大多数文生图任务使用扩散模型。其工作流程如下图所示:
1. 文本编码:首先,将提示(prompt)输入文本编码器模型(如 CLIP、T5)以生成文本嵌入。CLIP 用于连接文本和图像,T5 适用于包含大量细节或较长文本的复杂提示。
2. 生成噪声张量:生成一个随机的潜在张量(latent tensor),该张量代表编码后的噪声图像。
3. 去噪:将文本嵌入和随机潜在张量传递给去噪模型。该模型会进行多次推理,每次迭代去除一些噪声。最终输出一个没有噪声的潜在张量。这个步骤占据了超过 95% 的时间,因此是使用低精度推理进行加速的主要目标。
4. 解码:最后,将去噪后的潜在张量传递给解码器模型(VAE)以生成最终的输出图像。

Page 42
Page 42

针对 text2image 模型的低精度推理解决方案

以 Flux 模型为例,介绍几种低精度推理方案:

Page 43
Page 43

下图展示了不同精度方法(BF16、TRT FP8、TRT nvFP4、SVDQuant nvFP4)生成的图像质量对比。可以看出,低精度技术在保持高质量视觉效果方面表现良好。

Page 44
Page 44

下表比较了不同方案在 H20 和 RTX PRO GPU 上的单次迭代延迟。

  • 准确率 (Accuracy): BF16 > FP8 > SVDQuant nvFP4 > nvFP4
  • 速度 (Speed): nvFP4 > SVDQuant nvFP4 > FP8 > BF16

结果表明,低精度推理能在可接受的精度损失范围内显著提升推理速度。例如,在 RTX PRO GPU上,TRT nvFP4 (177.076 ms) 的速度远快于 TRT BF16 (567.715 ms)。

Page 45
Page 45

AIGC-Text2Video

视频生成概述

本节以 Wan2.1 为例,介绍视频生成流程。

Page 47 - 视频生成流程图,以Wan2.1为例
Page 47 - 视频生成流程图,以Wan2.1为例

从文本到视频(Text-to-Video)技术将自然语言描述转换为动态视频序列。该过程通常遵循以下核心步骤:

  • 文本编码 (Text Encoding): 输入的提示(prompt)由强大的文本编码器(例如 CLIP、T5)处理,以创建数值表示,即“文本嵌入”(text embeddings)。CLIP 能有效连接文本和视觉概念。T5 在理解复杂、详细或长篇的提示方面表现出色。
  • 去噪 (Denoising - 核心步骤): 文本嵌入和噪声隐向量(noise latent)被传递到一个去噪模型(通常是扩散模型)。该模型迭代地、一步步地精炼噪声,以揭示视频结构。这是计算量最大的阶段,消耗超过90%的计算资源。
  • 视频解码 (Video Decoding): 最终,干净的隐张量(clean latent tensor)被解码器转换为像素空间,生成输出视频。

Wan2.1 示例 (官方): https://github.com/Wan-Video/Wan2.1

DeepSpeed Ulysses:长上下文并行计算

DeepSpeed-Ulysses 沿序列维度(sequence dimension)在参与的 GPU 之间划分单个样本。

Page 48 - DeepSpeed Ulysses 长上下文并行计算架构图
Page 48 - DeepSpeed Ulysses 长上下文并行计算架构图
  1. 在注意力计算之前,它对已分区的查询(queries)、键(keys)和值(values)采用 all-to-all 通信集合(collective),使得每个 GPU 都能接收到完整的序列,但只处理一个不重叠的注意力头(attention heads)子集。
  2. 这使得参与的 GPU 能够为不同的注意力头并行计算注意力。
  3. 最后,DeepSpeed-Ulysses 采用另一次 all-to-all 操作来收集注意力计算的结果,同时沿序列维度重新分区。

DeepSpeed-Ulysses 论文链接: https://arxiv.org/pdf/2309.14509

量化实践

提示 (Prompt): "CG animation digital art, a sleek and advanced cat-like robot standing in the bustling center of Times Square, surrounded by towering skyscrapers and diverse crowds. The robot is equipped with bright, neon lights and intricate mechanical designs, moving gracefully as it performs a synchronized dance routine. It has expressive LED eyes and a metallic finish that reflects the vibrant city lights. The crowd watches in awe, their faces filled with excitement and admiration. The robot moves from side to side, spinning and twirling with precision, capturing every beat of the music. The background features the iconic New York skyline, with billboards and advertisements flickering in the night. A sense of futuristic wonder and urban energy permeates the scene. High-definition close-up shot of the robot's mechanical limbs and facial expression."

中文翻译: “CG动画数字艺术,一个圆滑先进的猫形机器人站在繁华的时代广场中心,周围是高耸的摩天大楼和多样的人群。机器人配有明亮的霓虹灯和复杂的机械设计,优雅地进行着同步舞蹈。它有富有表现力的LED眼睛和反射着充满活力的城市灯光的金属外壳。人群敬畏地观看,脸上充满了兴奋和钦佩。机器人左右移动,精准地旋转和转圈,捕捉着音乐的每一个节拍。背景是标志性的纽约天际线,夜晚的广告牌和广告闪烁不定。一种未来奇观和都市活力的感觉弥漫在场景中。高清特写镜头展示了机器人的机械肢体和面部表情。”

Wan2.1 评估

使用 Wan2.1 在不同精度下评估视频生成效果。下图中对比了四种配置的效果:
1. BF16 GEMM + FA2
2. BF16 GEMM + SageAttention
3. FP8 blockscale GEMM + SageAttention
4. nvFP4 GEMM + SageAttention

Page 49 - 使用 Wan2.1 在不同精度下的视频生成效果对比
Page 49 - 使用 Wan2.1 在不同精度下的视频生成效果对比

Wan2.2 评估

使用 Wan2.2 在不同精度下评估视频生成效果。下图中对比了与上一节相同的四种配置在 Wan2.2 模型上的效果。

Page 50 - 使用 Wan2.2 在不同精度下的视频生成效果对比
Page 50 - 使用 Wan2.2 在不同精度下的视频生成效果对比

性能分解

SP 扩展效率评估 (RTX PRO GPU)

评估 RTX PRO GPU* 在不同 SP(序列并行)配置下的扩展效率。

基准测试配置:
* 720p 分辨率,24 FPS,97 帧。
* 呈现的基准测试结果基于启用 SageAttention 和 BF16 GEMM 的执行。
* NCCL Allgather 操作的延迟(主要来自 FSDP)通过与计算流重叠而被有效隐藏。最终的 Ulysses 特定 Allgather 操作本质上很小,总共对流水线造成的开销可以忽略不计(~0%)。
* *SP 5/10/20 被选中是因为注意力头的数量只能被 5 整除,而不是 16。

表格解读:
该表格展示了在不同序列并行度(SP 1, 5, 10, 20)下,各计算部分(GEMM, fMHA, Others, NCCL)的延迟(单位:秒)和占比。同时计算了相对于 SP 1 的加速比(Speedup)。例如,在 SP 20 配置下,总延迟从 43.986s 降低到 2.534s,实现了 17.35x 的总加速比。

Page 51 - 性能分解表格:不同SP配置下的扩展效率
Page 51 - 性能分解表格:不同SP配置下的扩展效率

跨 GPU 平台性能对比 (H20 vs RTX PRO GPU)

在 H20 与 RTX PRO GPU* 上使用 SageAttention 和 FP8 块级量化 GEMM 的性能对比。

基准测试配置:
* 720p 分辨率,24 FPS,97 帧。在 8x GPU 上测试。启用 Sage Attention。
* NCCL Allgather 操作的延迟(主要来自 FSDP)通过与计算流重叠而被有效隐藏。最终的 Ulysses 特定 Allgather 操作本质上很小,总共对流水线造成的开销可以忽略不计(~0%)。

表格解读:
该表格对比了四种不同配置下的性能:
1. BF16 GEMM (RTX PRO GPU)
2. FP8 blockscale GEMM (RTX PRO GPU)
3. FP8 blockscale GEMM (H20)
4. nvFP4 GEMM (RTX PRO GPU)

表格详细列出了各部分的延迟(GEMM, fMHA, Quantize Overheads 等),并计算了相对于基准配置的加速比。例如,使用 nvFP4 GEMM 的 RTX PRO GPU 相对于使用 BF16 GEMM 的 RTX PRO GPU 实现了 1.22x 的总加速比。

Page 52 - 性能分解表格:H20 vs RTX PRO GPU 性能对比
Page 52 - 性能分解表格:H20 vs RTX PRO GPU 性能对比

Page 53 - NVIDIA Logo
Page 53 - NVIDIA Logo