何平, NVIDIA TensorRT团队 高级工程师
张一林, NVIDIA GPU加速计算专家团队 高级工程师
AI Open Day 20251107
注:仅供技术讨论和参考,可能因不同产品组合而异。
wo_gemm (输出权重矩阵) 在不分片的情况下占据总权重的 1.07%,但在分片的情况下会占据 29.45%。wo_gemm 检查点使用 NVFP4 量化,为 Blackwell GPU 内存约束进行了优化。此图展示了在上下文 (Context) 阶段和生成 (Generation) 阶段,数据如何在 BF16 和 FP8 精度之间转换和计算,以实现 FP8 MHA (多头注意力) 和 FP8 MQA (多查询注意力)。
优势:
用法:
python ./examples/llm-api/quickstart_advanced.py --kv_cache_dtype fp8extra-llm-api-config.yml 中应用 --extra_llm_api_options:kv_cache_config:
dtype: "fp8"
架构原理:
实现:
# 启动 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
MoE (Mixture-of-Experts) 模型是一种神经网络架构,由称为专家的多个专业化子模型和一个门控网络组成,该门控网络为每个输入动态选择要激活的专家。这使得模型可以在专家之间分配任务,比稠密模型更有效地处理数据。
如果 MoE 模型无法容纳在单个 GPU 的内存中,则必须在多个 GPU 上进行并行化。通常,MoE 层有三种并行策略:TP(张量并行)、EP(专家并行)以及两者的混合。
张量并行将每个专家的权重均匀地拆分并分发到不同的 GPU 上,这意味着每个 GPU 持有所有专家的部分权重。TP 组中的每个 GPU rank 接收所有令牌(tokens)对所有专家的隐藏状态,然后使用部分权重进行计算。
专家并行将一些专家的完整权重均匀地分发到不同的 GPU 上,这意味着每个 GPU 持有部分专家的完整权重。每个 GPU rank 仅接收发往其 rank 上专家的令牌的隐藏状态,然后使用完整权重进行计算。
当同时启用 TP 和 EP 时,每个 GPU 处理一部分专家权重矩阵(如 EP 模式),并且这些权重会进一步在多个 GPU 之间切分(如 TP 模式)。这种混合方法旨在更均匀地平衡各个 GPU 的工作负载,从而提高效率并减少仅使用 EP 模式时可能出现的瓶颈。
在最大吞吐量场景下的 DeepSeek MLA + MoE 架构中,通常采用注意力数据并行(Attention Data Parallel, ADP)+ MoE 专家并行(EP)策略来消除冗余的 KV 缓存存储。
选择注意力 DP 的直觉在于,它为 MLA 执行 TP(其中不同的 GPU 计算不同的注意力头)会复制 KV 缓存内存,这限制了系统可以实现的并发性。复制因子等于 TP 组的大小,例如 TP8 时为 8x。对于像 NVIDIA Blackwell 这样的强大系统,小的并发性会损害吞吐量。
不同 rank 在 MoE 层接收不同的令牌
在 TensorRT-LLM 中,MoE 后端支持多种选项。默认后端是 CUTLASS,它专注于单节点或小规模专家并行的优化,而 WIDEEP 是我们专为大规模 EP 设计的。
| CUTLASS | WIDEEP | |
|---|---|---|
| Communication op | All2all 仅支持 MNNVL;AG+RS 用于其他情况 | All2all 支持 MNNVL, DeepEP, DeepEP LL; |
| EPLB | static (静态) | dynamic (动态) |
Message_AG/RS = (ep_size - 1) * token_num * hidden_dim
当 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
NCCL all2all kernel 假设每个 rank 发送/接收的消息大小是相同的。然而,在 MoE 层中,专家之间的工作负载并不均衡,这会引入额外的开销。
ncclAlltoAll 是一种变体,它允许工作负载不均衡的情况:
- 每个 rank 向所有其他 rank 发送计数值,并从所有其他 rank 接收计数值。
- 发送到目标 rank j 的数据取自 sendbuff 的 j*count 位置,从源 rank i 接收的数据放置在 recvbuff 的 i*count 位置。
- 注意:这假设总的发送和接收计数值等于 cranks*count,这意味着 sendbuff 和 recvbuff 的大小至少为 cranks*count 个元素。
- 目前不支持原地(in-place)操作。
下图比较了 DeepEP 的两种模式:普通模式和低延迟(LL)模式。
两种模式的特点如下:
普通模式 (Normal mode)
低延迟模式 (Low latency mode)
在 RTX PRO GPU 上,点对点访问的延迟可能非常高,因为它可能需要跨越 PCIe 以及 NUMA 节点之间的 SMP 互连。下图展示了一个典型的服务器拓扑结构,包含多个 GPU、CPU、PCIe Switch 和 NIC。
如下表和流程图所示,不同的 MoE 后端(CUTLASS vs WIDEEP)采用不同的数据处理流程。即使在 ep_size=32 的情况下,由于数据类型差异导致的消息大小增加4倍,也可能会抵消 all2all 带来的算法优势。
随着专家并行(EP)规模的增加,通信(comm)所占的比例显著上升,使得通信内核的优化至关重要。下图比较了 CUTLASS 和 WIDEEP 在不同 EP 规模下各计算部分(gemm、attn、comm 等)的时间占比。
在从 bf16 到 nvfp4 的量化过程中,首先计算 fp32 的 per-tensor scale,然后计算 fp8 的 pre-block scale(block_size=16)。通过这种方式,数据大小可以减少到原始大小的 28%。
NVFP4 (E2M1) 格式包含1位符号位,2位指数位和1位尾数位。
下图展示了不同配置下的每步延迟。与 CUTLASS 和 WIDEEP-bf16 相比,使用 nvfp4 量化的 WIDEEP(WIDEEP-nvfp4/bf16/C)显著降低了通信开销,尤其是在高专家并行(EP)规模下。
在吞吐量(TPS/GPU)方面,WIDEEP_nvfp4dispatch/combine 在各种 EP 规模下均表现出最高的性能。
下表展示了 ep_size = 8 时的精度结果。与基线相比,使用 nvfp4 量化对 gsm8k 平均准确率的影响很小。
- WIDEEP (bf16/bf16): 95%
- WIDEEP (nvfp4/bf16): 94.01%
- WIDEEP (nvfp4/nvfp4): 94.92%
大多数文生图任务使用扩散模型。其工作流程如下图所示:
1. 文本编码:首先,将提示(prompt)输入文本编码器模型(如 CLIP、T5)以生成文本嵌入。CLIP 用于连接文本和图像,T5 适用于包含大量细节或较长文本的复杂提示。
2. 生成噪声张量:生成一个随机的潜在张量(latent tensor),该张量代表编码后的噪声图像。
3. 去噪:将文本嵌入和随机潜在张量传递给去噪模型。该模型会进行多次推理,每次迭代去除一些噪声。最终输出一个没有噪声的潜在张量。这个步骤占据了超过 95% 的时间,因此是使用低精度推理进行加速的主要目标。
4. 解码:最后,将去噪后的潜在张量传递给解码器模型(VAE)以生成最终的输出图像。
以 Flux 模型为例,介绍几种低精度推理方案:
TensorRT
SVDQuant 的开源推理引擎
下图展示了不同精度方法(BF16、TRT FP8、TRT nvFP4、SVDQuant nvFP4)生成的图像质量对比。可以看出,低精度技术在保持高质量视觉效果方面表现良好。
下表比较了不同方案在 H20 和 RTX PRO GPU 上的单次迭代延迟。
结果表明,低精度推理能在可接受的精度损失范围内显著提升推理速度。例如,在 RTX PRO GPU上,TRT nvFP4 (177.076 ms) 的速度远快于 TRT BF16 (567.715 ms)。
本节以 Wan2.1 为例,介绍视频生成流程。
从文本到视频(Text-to-Video)技术将自然语言描述转换为动态视频序列。该过程通常遵循以下核心步骤:
Wan2.1 示例 (官方): https://github.com/Wan-Video/Wan2.1
DeepSpeed-Ulysses 沿序列维度(sequence dimension)在参与的 GPU 之间划分单个样本。
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 在不同精度下评估视频生成效果。下图中对比了四种配置的效果:
1. BF16 GEMM + FA2
2. BF16 GEMM + SageAttention
3. FP8 blockscale GEMM + SageAttention
4. nvFP4 GEMM + SageAttention
使用 Wan2.2 在不同精度下评估视频生成效果。下图中对比了与上一节相同的四种配置在 Wan2.2 模型上的效果。
评估 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 的总加速比。
在 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 的总加速比。