数据中心/云端

Blackwell 借助 Meta 的 Llama 4 Maverick 突破 1000 TPS/ 用户门槛

NVIDIA 的大语言模型 (LLM) 推理速度创下了世界纪录。在包含 400 亿参数的 Llama 4 Maverick 模型 ( Llama 4 系列中可用的最大、最强大的模型) 上,配备 8 个 NVIDIA Blackwell GPU 的单个 NVIDIA DGX B200 节点可为每位用户实现每秒 1,000 多个 token (TPS) 。这一速度由 AI 基准测试服务 Artificial Analysis 独立衡量。

凭借这一记录,Blackwell 在任何部署场景中都是 Llama 4 的理想硬件,无论是要更大限度地提高吞吐量,还是要更大限度地降低延迟。NVIDIA Blackwell 是第一个在此模型上突破 1,000 TPS/user 的里程碑的平台,在我们的最高吞吐量配置下,它达到了 72,000 TPS/server。

为了充分利用 Blackwell GPU,NVIDIA 使用 TensorRT-LLM 进行了大量软件优化,并使用 EAGLE-3 技术训练了一个预测性解码草稿模型。结合这些方法,NVIDIA 实现了 4 倍的速度提升,相较于之前的最佳 Blackwell 基准。

模型准确性结果

下文所述的优化可显著提高性能,同时保持响应准确性。我们将 FP8 数据类型用于 GEMMs、多专家模型 (MoE) 和 Attention 运算,以减小模型大小,并利用 Blackwell Tensor Core 技术提供的高 FP8 吞吐量。在许多指标中,使用 FP8 数据格式时的准确性与 Artificial Analysis BF16 的准确性相匹配,如下表所示:

  LiveCodeBench AIME 2024 GPQA Diamond MATH-500
  0.397 0.39 0.671 0.889
经过优化的 Llama 4 Maverick (FP8) 0.383 0.40 0.686 0.876
表 1。Llama 4 Maverick 模型精度对比,参考和优化对比

为什么最小化延迟很重要?

大多数生成式 AI 应用场景都需要平衡吞吐量和延迟,确保许多客户能够同时享受“足够好”的体验。但是,对于必须快速做出重要决策的关键应用程序而言,最大限度地降低单个客户端的延迟至关重要。正如 TPS/用户记录所示,Blackwell 硬件是任何任务的最佳选择,无论您是需要更大限度地提高吞吐量、平衡吞吐量和延迟,还是需要更大限度地降低单个用户的延迟 (本文重点)。

针对最小化延迟进行优化

下面概述了 NVIDIA 在推理期间应用的内核优化和融合 (用红色虚线表示) 。NVIDIA 实施了多个低延迟 GEMM 内核,并应用了各种内核融合 (例如 FC13 + SwiGLU、FC_QKV + attn_scaling 和 AllReduce + RMSnorm) ,以确保 Blackwell 在最低延迟场景中表现出色。

A high level overview of the kernel optimizations and fusions applied to the Llama 4 Maverick model to achieve 1000 tokens per second per user.
图 1。用于 Llama 4 Maverick 的内核优化和融合概述

CUDA 内核优化和融合

NVIDIA 针对 GEMM、MoE 和 Attention 运算优化了 CUDA 内核,以在 Blackwell GPU 上实现出色性能。

  • 利用空间分区 (也称为 warp 专门化) 并设计 GEMM 内核以高效方式从内存加载数据,以更大限度地利用 NVIDIA DGX 系统提供的巨大内存带宽 – 总计 64TB/s HBM3e 带宽。
  • 在使用 Blackwell 的第五代 Tensor Core 进行矩阵乘法计算后,以 swizzled 格式混洗 GEMM 权重,以便在加载 Tensor 内存的计算结果时实现更好的布局。
  • 通过按 K 和 V 张量的序列长度维度划分计算,优化注意力内核的性能,从而允许计算在多个 CUDA 线程块中并行运行。此外,NVIDIA 利用分布式共享内存高效地减少了同一线程块集群中线程块的结果,而无需访问全局内存。
  • 支持操作之间的融合,以减少内核执行与内存加载/存储之间的用度。例如,NVIDIA 将 AllReduce 操作与以下 RMSNorm 操作和 Quantize 操作融合到一个 CUDA 内核中。NVIDIA 还将 SwiGLU 操作与之前的 GEMM 融合在一起。

程序化依赖启动

编程依赖启动 (Programmatic Dependent Launch, PDL) 是一项 CUDA 功能,可缩短同一流上两个连续 CUDA 内核之间的 GPU 空闲时间,甚至允许两个 CUDA 内核重叠。

默认情况下,在同一 CUDA 流上启动核函数时,在第一个核函数完成之前,第二个核函数不会开始执行。这会导致两个性能问题:首先,两个连续内核执行之间存在微小差距,如下图所示,此时 GPU 处于空闲状态。其次,当第一次内核执行接近尾声时,内核仍可能占用一些 Streaming Multiprocessors (SMs) 来执行其余 CUDA 块,从而使 GPU 上的其余 SM 处于空闲状态。这导致 GPU 的计算能力未得到充分利用。

A CUDA application utilizes the GPU by launching and executing multiple kernels on it.Typically, this is done on a single CUDA stream. This figure shows the timeline of execution of these kernels when using a single stream.
图 2。单个 CUDA 流

借助 CUDA 中的变成依赖启动 API,NVIDIA 允许二级内核在主内核仍在运行时开始执行。在前言期间,次要函数可以执行计算并加载不依赖于主核函数执行的数据。这不仅消除了两个连续内核之间的间隙,而且提高了 GPU 利用率;第一个内核仅占用 GPU 上部分 SM,而其他 SM 可以开始运行第二个内核。

This figure shows the concurrent execution of the primary kernel and secondary kernel using the Programmatic Dependent Launch APIs in CUDA. It reduces the gaps between two consecutive kernels.
图 3。重叠内核可缩短执行时间

预测解码

预测解码是一种热门技术,用于在不影响生成文本质量的情况下加速 LLM 的推理速度。它通过让更小、更快的“draft”模型预测一系列预测性 token 来实现这一目标,然后由更大的“target” LLM 并行验证这些 token 。加速是在一次目标模型迭代中生成可能的多个 token ,但会产生额外的 draft 模型开销。

Diagram showing the speculative decoding pipeline. The target model starts with a context phase, producing an initial token (t1). The draft model then generates a sequence of speculative tokens (d2–d4). The target model enters a generation phase where it evaluates the draft tokens, accepting correct ones (like d2 and d3) and rejecting incorrect ones (like d4), and outputs verified tokens (t2–t5). This cycle repeats with new speculative tokens (d5–d7) and target-verified outputs (t5′–t8). The process allows multiple tokens to be verified in a single target model pass, significantly reducing inference time.

上图展示了端到端工作流程。最初,在目标模型进入上下文阶段 (也会生成 token t1) 后,草稿模型会快速生成潜在 token 序列 (例如 d2-d4) 。然后,目标模型进入生成阶段,同时为整个草稿序列生成下一个 token 。如图所示,它可能会“接受”多个 token (例如 d2、d3) ,前提是这些 token 与其生成的 token 相匹配,但会“拒绝”其他 token (例如 d4) 。

此循环重复:保留已接受的token,如果发生拒绝,目标模型提供正确的下一个token (例如拒绝 d4 后的 t4) ,草稿模型生成新的预测序列 (d5-d7) 。通过并行验证多个token,而不是使用较慢的目标模型逐个生成它们,并利用草稿模型的快速猜测,可以显著提高速度,尤其是在草稿模型的预测通常正确的情况下。接受长度 (AL) 的定义是,您只需执行一个验证步骤即可平均生成多少个token。AL 值越高,速度提升就越大。

NVIDIA 使用基于 EAGLE3 的架构作为其预测解码方法,仅修改预测层的 FFN 大小以获得更好的 AL。在推理过程中,NVIDIA 会记录目标模型前向传递中的低、中、高级特征 (在第一、中间和最后解码层后隐藏的状态) 。之后,NVIDIA 将这些隐藏状态和 token 嵌入相结合,并将其馈送至预测层。然后,预测层以自回归方式生成一系列草稿 token,以便目标模型进行并行验证。

预测层的开销很小,但不可忽略,因此一个挑战是在草稿长度和端到端加速之间找到良好的平衡。草稿长度越长,AL 就越高,但运行其他草稿模型的成本也是如此。根据 NVIDIA 的以下实验,草稿长度 = 3 可提供最佳加速。

Line graph showing how three metrics—Speed Up (orange), AL (dark green), and Latency (light green)—change with increasing draft token length from 0 to 7. Speed Up increases from 1.00 at draft length 0, peaks at 2.06 at draft length 3, then slightly declines. AL rises consistently to 3.44 by draft length 5, while Latency grows more gradually to 1.94 by draft length 7. The graph illustrates that draft length 3 yields the optimal performance gain before diminishing returns.
图 5。Draft length 3 可在平衡延迟和 AL 开销的情况下实现最佳加速

使用 CUDA Graph 和重叠调度程序减少主机开销

预测解码的另一个挑战是减少目标模型和草稿模型之间的通信/同步开销。如果 NVIDIA 在主机侧放置采样/验证逻辑,则会在主机和设备之间创建额外的同步点,并破坏 CUDA Graph。相反,保留设备侧的验证逻辑,以保持目标模型向前传递、验证逻辑和草稿模式向前传递到一个 CUDA Graph 中。NVIDIA 还启用了 TensorRT-LLM 重叠调度程序,以进一步重叠当前迭代的模型前向传递与下一次迭代的输入准备和 CUDA Graph 启动。

Torch.compile() 用于优化草图模型层

由于验证逻辑是通过 Torch 原生操作在设备端实施的,因此 NVIDIA 最终获得了大量小型 Torch 原生内核。手动融合它们可能非常复杂且容易出错,因此 NVIDIA 使用 torch.compile() 让 OpenAI Triton 自动融合并为该部分生成最佳内核。这有助于 NVIDIA 将草稿模型的用度从 25% 降低到 18% (草稿长度 = 3) 。

总结

NVIDIA 再次证明了其在数据中心和 AI 基础设施方面的领导地位,在包含 400 亿个参数的 Llama 4 Maverick 上,每位用户实现了每秒 1000 多个 token 的标志性性能。这一创纪录的速度由强大的 Blackwell 架构、从 CUDA 级别到深度软件优化以及 NVIDIA 定制的 speculative decoding 实现的显著加速相结合,直接满足了新一代 AI 交互的低延迟需求。正如 NVIDIA 所展示的,这些进步可确保即使是大型模型也能提供无缝的实时用户体验和复杂的 AI 代理部署场景所需的速度和响应速度。

 

标签