使用 NVIDIA H100 为 Llama 2 70B 加速

Perplexity 对性能的追求促使我们采用 NVIDIA 和 AWS 提供的最新技术。在本篇博文中，我们很高兴能分享最新实验的结果：对 Llama 2 70B 在各种硬件和软件设置下的推理性能对比。

我们的 LLM 推理平台 pplx-api 基于由开源库驱动的前沿技术栈构建。自 pplx-api 于 10 月开启公开测试以来，我们一直在解决扩展难题，并学习如何最优化我们的配置以实现大规模扩展。这促使我们带着以下指导性问题进行了实验：

在其他设置保持不变的情况下，将 GPU 从 NVIDIA A100 更换为 NVIDIA H100，所带来的性能提升幅度是多少？

H100 原生支持的 8 位浮点数 (fp8) 量化带来的效率提升是多少？这种量化带来的精度损失又是多少？

张量并行（tensor parallelism）和批次大小（batch size）如何影响延迟和 Token 吞吐量？

综上所述，哪种配置在性能和成本效益之间实现了最具可扩展性的平衡？

实验设置

我们进行了一系列本地基准测试作为实验，以规避网络延迟影响。

关键指标：

延迟：推理服务器生成完整响应所需的总时间。

吞吐量：推理服务器在所有用户和请求中，每秒、每个 GPU 可生成的输出 Token 数量。

常量：

以下因素会影响关键指标，因此我们在实验的不同试验中保持了这些因素的一致性。

AI 模型

性能随着 LLM 的规模而扩展。参数越多，计算量越大，推理速度越慢。例如，在其他设置相同的情况下，Llama 2 13B 比 Llama 2 70B 更快。我们在本实验中坚持使用 Llama 2 70B，因为我们旨在优化对最强开源模型的服务能力。

输入/输出 Token 数据集

每个样本请求/响应对中的输入和输出 Token 数量会影响性能测量。通常情况下，输出 Token 的生成决定了总响应时间。当采样数据仅诱导 LLM 产生“是/否”回答时，响应速度比要求 LLM 撰写论文的样本要快。我们的数据集由合成请求组成，包含 1024 个输入 Token，诱导产生 512 个输出 Token。选择该分布是为了匹配我们 在 Llama 2 70B 公共部署中 观察到的流量分布。

软件版本

NVIDIA TensorRT-LLM（v0.5.0 版本） 是一个用于优化 LLM 推理的开源库。它于 2023 年末发布，集成了 NVIDIA 的多项推理优化方案，并为本实验的关键参数提供了灵活的定制层：批次大小、量化和张量并行。

变量

我们针对 4 个配置维度进行了实验：张量并行、GPU 架构、量化和最大批次大小。这些维度相互关联，因为它们每一个都代表了相对于 GPU 内存这一关键瓶颈资源的权衡。

GPU 架构

第九代 Hopper (H100-HBM3-80GB / p5.48xlarge) GPU 架构相比其前身 Ampere (A100-SXM4-80GB / p4de.24xlarge) 拥有 庞大 的功能提升，包括 2 到 6 倍的计算速率和近 2 倍的 GPU 内存带宽。GPU 内存带宽是推理的关键指标，因为推理过程中矩阵乘法的主要延迟瓶颈来自于将数 GB 的模型数据从 GPU 内存加载到计算寄存器。基于这些统计数据，我们假设在 NVIDIA H100 和 A100 的同类对比中，延迟和吞吐量将展现出 2 倍的提升。

NVIDIA H100 和 A100 的另一个主要区别在于，H100 Tensor Core 原生增加了对 8 位浮点数 (fp8) 指令的支持，这为下述进一步优化打开了大门。这就是为什么我们专门为 H100 使用 fp8 和 fp16 的原因。

为了保持实验中每个 GPU 的内存一致，我们在 NVIDIA A100 和 H100 上都使用了 8x80GB GPU 内存的节点。除了支持更大的批次大小外，GPU 内存之所以重要，是因为模型的参数在服务器启动时会被加载到 GPU 内存中以便快速访问。例如，如果模型中的 700 亿个参数每个都是 16 位浮点数，那么模型的大小约为 140GB，这无法装入单个 GPU。因此需要张量并行，我们在下文中对此进行了说明。

张量并行

张量并行指的是运行推理服务器所消耗的 GPU 设备数量。当我们分配一定数量的 GPU 时，TensorRT-LLM 会汇集它们的资源，以帮助我们达到运行 Llama 2 70B 所需的最小内存预算。我们的假设是，与更高的张量并行度相比，较低的张量并行度会导致更高的延迟（因为消耗的资源较少以满足每个批次），但每 GPU 的吞吐量更高（因为利用率更好）。

量化

量化是降低神经网络所使用的权重和激活值精度的过程。我们使用这种技术将从 fp16 切换到 fp8 时的 GPU 内存消耗减半。这使得以更低的总 GPU 内存使用量运行同一模型成为可能，从而实现更低的张量并行度，进而提高吞吐量。

量化的实现可能会降低精度。因此，我们通过比较 WikiText 语料库上的困惑度（Perplexity，衡量 LLM 预测句子中下一个 Token 好坏的统计指标）来评估不同精度的准确性。对于 8 位浮点数和带有 8 位激活值及 SmoothQuant (w8a8 SQ) 的 8 位权重，其在 WikiText 上的困惑度与 fp16 相比没有显著变化（< 1%），因此我们确信可以继续进行。然而，w4a16 表现出了显著的 7% 困惑度变化，这可能归因于更低的精度以及 int4 和 fp16 之间必要的动态转换。

批次大小

通过批处理实现并行是一种从资源受限系统中榨取性能的经典策略。通过在神经网络的每次前向传递中处理多个请求，批处理以增加部分延迟为代价提高了吞吐量。批处理还会导致更高的 GPU 内存消耗，因为管理注意力机制的 KV 缓存大小会随着批次大小线性增长。

放大

以 Llama 2 70B（拥有 80 层）为例，在 4096 上下文大小下，使用 batch size 32 的 fp16，KV 缓存的大小达到了惊人的 40 GB。这最终导致 Llama 2 70B fp16（仅权重就占用 140GB）无法轻松装入张量并行 2 (TP-2) 下可用的 160GB GPU 内存中。

结果

我们遍历了实验中 4 个变量的兼容组合，并在下文中展示了最具洞察力的趋势。

放大

在比较 H100 fp16 → fp8 和 A100 fp16 → w8a8 with SmoothQuant 时，量化带来的延迟改善在 10% 左右。然而，与 fp16 相比，混合精度的 w4a16 在低批次大小下表现更好，而在高批次大小下表现更差。这可能是由多种因素造成的，包括计算内核优化不足、int4 与 fp16 之间的转换时间，以及 w4a16 仍然使用 16 位浮点数进行激活，导致 KV 缓存尺寸没有节省这一事实。由于 w4a16 也显示出较低的准确性，我们得出结论，应坚持为 A100 使用 w8a8 SQ，为 H100 使用 fp8。

放大

在前两张图中，我们仅展示了 TP-8 的配置。当两者都使用 fp16 / BS-128 / TP-8 时，H100 相比 A100 实现了 54% 的延迟和 184% 的吞吐量；当 H100 使用 fp8 时，这一性能提升至 49% 的延迟和 202% 的吞吐量。这种性能提升归功于 H100 和 A100 在计算能力和内存带宽方面的增长。值得注意的是，这种差异在批次大小较低时表现得不那么明显，此时利用率可能较低。

在构建平台时，我们希望在满足用户特定延迟要求的同时实现吞吐量最大化。因此，与其在相同批次大小下比较 A100 和 H100，不如仅在它们满足延迟要求的配置下比较吞吐量更有意义。我们设定了 25600ms 的延迟上限来完成 512 个输出 Token，并发现 H100 / TP-8 / fp8 / BS-128 的吞吐量是 A100 / TP-8 / fp16 / BS-64 的 251%，因为它能够在更低的延迟下处理两倍的批次大小。鉴于量化提供了 GPU 内存节省，我们现在需要评估张量并行如何增加下一层优化。

放大

在量化和架构方面，赢家很明显：H100 优于 A100，而更低精度的量化改善了内存利用率、延迟和吞吐量。然而，批次大小和张量并行在我们的关键指标中呈现出权衡关系。较大的批次大小以牺牲一定的延迟和内存消耗为代价来优化吞吐量。另一方面，更高的张量并行度增加了可用内存的总池并优化了延迟，但由于分布式矩阵乘法的同步成本以及锁定了更多的 GPU 资源，从而在吞吐量上进行了妥协。

放大

我们实验中实现吞吐量最大化的配置是 H100 / fp8 / TP-2 / BS-128，每 GPU 每秒可处理 767 个输出 Token。这比 A100 / fp16 / TP-8 / BS-64 提高了 460%。然而，它付出的代价是延迟加倍——512 个输出 Token 的响应时间接近 42000ms——因此它可能不适合作为生产配置。TP-4 BS-128（626 tok/sec/gpu，响应时间 26188ms）和 TP-2 BS-32（435 tok/sec/gpu，响应时间 18821ms）的结果可能在我们关键指标上代表了更好的权衡。

结论

我们的结果表明：

与 A100 相比，在相同配置下使用 H100 可达到 54% 的延迟和 184% 的吞吐量；当 H100 利用其对 fp8 的原生支持时，这一数据分别提高至 49% 和 202%。

当在延迟约束下实现吞吐量最大化时，H100 / fp8 / TP-8 / BS-128 的吞吐量是 A100 / fp16 / TP-8 / BS-64 的 251%，因为它能够以更快的速度处理双倍的批次。

利用具有 fp8 的 TP-2 H100，我们可以实现 A100 / fp16 / TP-8 / BS-128 的 373% 的吞吐量，而延迟增加幅度不到 10%。

对于 LLM 推理系统的运营者而言，批次大小和张量并行在吞吐量和延迟之间存在权衡。

这些结果让我们对全面转型至 H100 GPU 驱动之前的 A100 硬件栈充满信心。我们很高兴能够证实 NVIDIA 所宣传的性能提升，并期待他们在加速硬件方面的下一次突破。

下一步

我们优化的下一个前沿领域是研究 结构化稀疏性 和 int4 精度带来的准确性和性能影响，这可以显著减少 Llama 2 70B 的 GPU 内存占用，并带来高达 2 倍的延迟改进。我们很高兴能继续深耕极速推理之旅，并希望赋能我们的用户在我们的平台上构建强大的应用程序。

在短期内，pplx-api 将取消速率限制，并提供更多定制化的 Perplexity LLM，包括一个带有事实依据的互联网驱动型 LLM。

在 perplexity.ai/pro 注册 Perplexity Pro。获取我们前沿 pplx-api 的访问权限，并在您的项目中利用这些高级功能。在我们的 博客 上了解更多关于 pplx-api 的信息。

有兴趣塑造 AI 的未来吗？我们在招聘！加入一个推动大规模生成式 LLM 基础设施的团队。在 Perplexity Careers 探索机会。

作者：

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats