引言 — 这篇文章详细介绍了分析工具 GenZ，用于研究 LLM 推理性能与各种平台设计参数之间的关系。该工具量化了在不同服务设置下支持 SOTA LLM 的平台要求。此外，文章还预测了支持未来可能超过数百万亿个参数的 LLM 所需的硬件能力。从 GenZ 中得出的趋势和见解可以为部署 LLM 的人工智能工程师以及设计下一代硬件加速器和平台的计算机架构师提供指导。源代码可在 GitHub 上获取。
本文包括两篇，此为第二篇。
原论文已经上传至知识星球。
摘要--要在各种推理用例中高效部署这些参数繁重的模型，需要精心设计具有充足计算、内存和网络资源的硬件平台。
在这项工作中，我们提出了一个分析工具 GenZ，用于研究 LLM 推理性能与各种平台设计参数之间的关系。
我们的分析提供了针对不同 LLM 工作负载和用例配置平台的见解。我们量化了在不同服务设置下支持 SOTA LLM 的平台要求。
此外，我们还预测了支持未来可能超过数百万亿个参数的 LLM 所需的硬件能力。
从 GenZ 中得出的趋势和见解可以为部署 LLM 的人工智能工程师以及设计下一代硬件加速器和平台的计算机架构师提供指导。
最终，这项工作揭示了在各种应用中释放大型语言模型全部潜力的平台设计注意事项。源代码可在 GitHub 上获取。
V. 使用 GENZ 进行工作负载优化分析
对于 LLM 推理，批量大小（batch size）、精度和并行性是为了提高性能、效率和资源利用率的优化，而无需修改 LLM 的核心实现。
需要注意的是，虽然这些优化可以提高推理性能，但其中一些优化也可能会带来权衡或限制。例如，较低的精度可能会导致一些精度损失，而并行策略可能会引入通信开销或需要专门的硬件配置。在本节中，我们研究了输入批处理和并行化策略对LLM推理的影响。
A. 输入批处理（Input Batching）
由于解码阶段的大多数算子都是memory bound，因此批处理多个查询可以帮助提高解码的吞吐性能。
图 6 显示了 μthr 和TPOT 如何随着批量大小的增加而增加。在 NVIDIA 的 A100（80GB） GPU 上以 int8 精度运行 LLaMA2-7B 模型，使用 2k 输入token，随着我们将批次从 1 增加到 44，我们看到 μthr 提高了 10.9×而 TPOT 仅增加了 1.83×。μthr 在 B = 38 后变为常数。
在此之后，解码延迟随批量大小线性增加。饱和吞吐量是 B=1 吞吐量的 14.5 倍，延迟仅增加 2.63×。因此，在解码阶段对输入进行批处理被证明是非常有利的。
静态batching 和连续batching 代表了 LLM 服务中常用的两种主要batching机制。
在静态批处理中，所有可用请求都会一起批处理，但这些请求的所有前向传递都会在运行任何其他请求之前完成。静态批处理的一个关键挑战是新请求的排队延迟更高。
对于连续批处理，可以在每次前向传递后添加新查询。新查询的预填充阶段可以与旧查询的解码阶段一起运行。因此，它有助于减少新查询的排队时间，但可能会导致初始查询的尾延期增加。
在这项工作中，我们主要从静态批处理中获得认识和结论，但这些结论也适用于运行连续批处理的平台。
B. 并行化策略
满足 SLO 需要来扩大平台中的加速器数量。然而，对于并行策略的影响，目前还缺乏明确的统一意见。
最优并行化策略可能因模型和工作负载配置而异。我们还观察到，在预填充和解码阶段，不同的并行化策略的工作方式存在着巨大的差异。
图 7 显示了模型权重和 KV 缓存如何以不同程度的 TP + PP 进行分割的示例。在这项工作中，我们将评估限制在 TP 和 PP 上，涉及不同的 LLM。我们将 MoE的EP 和 SP 对平台的影响留作未来的工作。
每个灰色方框代表一个加速器 NPU，彩色块代表层。我们展示了 LLM 在不同 NPU 上的运行情况。
(a) 全部 TP 时，所有层的权重在所有 NPU 之间平均分配。
(b) 采用混合 TP 和 PP 时，层在加速器组之间分配。在各组中，层权重以张量并行方式分配。
(c) 全部 PP 将所有层分开分配给 NPU。
在所有情况下，一旦通过 TP/PP 对模型进行了分割，DP 就会在平台上的其余 NPU 中使用。
图8比较了HGX上的不同LLM模型：H100x8。我们使用Sb = 4，τp = 4000，τd = 256的工作负载。
选择并行化策略的关键要点：- 预填充：PP 比 TP 能提供更多查询。对于 Mixtral 8x7B 和 GPT3-175B，PP=8 比 TP=8 多 2.32 倍和 1.38 倍的查询量。- 解码：一般来说，仅 TP 或 TP + PP 混合在吞吐量方面更胜一筹。另一方面，较高的 PP 使平台能够容纳更大的批量。例如，PP=8 的 HGX:H100x8 可以容纳 GPT3-175B，由于微批处理，它可以容纳 256 个批次，而 TP 在 B=32 后会出现 OOM 错误。
我们在图 9 中显示了运行时明细，以了解这些性能增益。
在compute bound的预填充阶段，所有 NPU 的计算量都已完全饱和，因此，无论微批量大小如何，GEMM 和 SA 时间都保持不变。区别因素在于集合通信时间。TP:8 每层需要两个 AR，因此 8 个 NPU 共需要 192 个集合通信。而 PP:8 只需要在流水线阶段的接口处发送信息，因此只需要 7 个集合通信时间。
在memory bound的解码阶段，我们看到了截然不同的行为。由于 AR 消息的大小非常小，因此集合通信时间都很短。在PP中使用更小的微批次规模进一步缩短了集合时间。在 PP 阶段，层的顺序化执行会导致更大的延迟。值得注意的是，虽然总延迟时间会增加，但每阶段的延迟时间会随着PP的减少而减少。
VI. 使用 GENZ 进行平台特性分析
在本节中，我们使用 GenZ 研究不同的平台特性。
我们主要关注四个平台特性：TFLOPS (HWc), Memory BW (BWfast), Interconnect link bandwidth (BWlink), Interconnect link latency (TLink) 。
为了了解每个特性对 LLM 推理性能的影响，我们在保持其他参数不变的情况下改变了每个参数。我们假设 NPU 拥有 800 TFLOPS、40 GBHBM 内存（4000 GB/s 内存带宽）、300 GB/s 互连带宽和 2 us 的链路延迟。对于每个参数，我们研究了表 IV 中的所有用例和表 I 中的所有模型，但为了节省篇幅，我们只在正文中展示了几个关键数据点。
A. TFLOPS 扩展
平台 TFLOPS 分别为 2×、4×、8×、12×。我们分别展示了 Mixtral 8x7B 和 GPT-3 分别在拥有 2 个和 12 个 NPU 的平台上进行推理。我们选择基于 RAG 的问题解答作为研究的代表性用例。
图 10 显示了预填充和解码阶段的运行时明细。
我们观察到，在计算 TFLOPS 为 12 倍的情况下，预填充延迟分别缩短了 4.33 倍和 2 倍。对于 GPT3-175B，我们看到 TTFT 延迟的改善较小，因为它主要由通信时间决定，但 FLOPS 的增加只会减少预填充和关注时间。
主要结论：
- 增加计算量有可能显著减少填充延迟，但对解码延迟没有影响。- 由于网络延迟在预填充中的重要作用，增加 FLOPS 所带来的好处随着平台规模的扩大而减少。
B.内存带宽扩展
我们将平台内存带宽分别调整为 2×、4×、8×、12×。我们分别展示了 2 个和 12 个 NPU 平台上的 Mixtral 8x7B 和 GPT-3 推理。
图 11 显示了预填充和解码阶段的运行时间明细。
我们观察到，当解码延迟达到原始计算内存 BW 的 8 倍时，分别缩短了 4.21 倍和 1.73 倍。与 TFLOPS 扩展类似，当解码延迟由通信时间主导时，我们发现解码延迟的改善幅度变得更小。
主要结论
- 增加带宽有可能显著减少解码延迟，但对预填充延迟没有影响。- 与 TFLOPS 一样，由于解码过程中网络延迟的巨大影响，增加快速内存带宽所带来的好处会随着平台规模的增长而减少。
C.ICN 带宽
接下来，我们将平台互连网络带宽分别调整为 1×、2×、3×、6×。
我们展示了在该平台上分别使用24个和84个NPU进行GPT3-175B和GPT4-175B推理的情况。我们选择代码生成作为本研究的代表性用例。
图 12 显示了预填充和解码阶段的运行时间明细。
我们观察到，当 ICN BW 增加到原始 BW 的 6 倍时，预填充延迟分别缩短了 1.44 倍和 1.56 倍。
主要结论
- 增加 ICN BW 有可能显著减少填充延迟，但对解码延迟的影响微乎其微。- 增加互连网络带宽带来的好处只有在平台规模足够大时才能看到，因为只有这时网络延迟才会成为预填充阶段的主要因素。
D.ICN 链路延迟
最后，为了研究平台互连网络链路延迟的影响，我们将Tlink从2微秒减少到0.1微秒。
在具有24个和84个NPU的平台上分别进行GPT-3 175B和GPT-4 175B的推理。我们选择代码生成作为本研究的代表性用例。
图13显示了预填充和解码阶段的运行时间分解。
我们观察到，当Tlink从2微秒减少到0.1微秒时，解码延迟分别减少了1.8倍和2.9倍。
我们为平台建立的互连网络模型假定了连接加速器的最佳拓扑结构。深入研究 LLM 推理的不同拓扑结构会带来广阔的设计空间，这也是目前的研究课题。
主要结论
- 减少互连网络延迟可显著降低解码延迟，但对预填充延迟的影响微乎其微。- 只有在平台尺寸足够大，以至于网络延迟在解码中占主导地位时，减少互连网络链路延迟的好处才会显现出来。
E.更少的芯片来做卸载
为推理提供服务的最有效方法是将所有模型权重和键值 (KV) 缓存存储在 NPU 的高速内存（如 HBM）中。
然而，由于资源限制，这种方法并不总是可行。
在这种情况下，可以将模型权重和 KV 缓存转移到较慢的内存中。对于同时使用模型权重和 KV 缓存的 LLM 推理，可行的策略是卸载固定部分的模型权重和 KV 缓存。
图14展示了在配备2个和4个A100-40GB GPU（PCIe）的平台上，对参数为Sb = 4, τp = 8000, τd = 256的LLaMA3-70B进行性能分析的情况，以及采用基于卸载的系统进行LLM推理的后果。
虽然在较小批量大小下模型适合该平台，但批量大小的增加导致对KV缓存的需求增加，结果就是一些参数被卸载。因此，由于卸载，2xA100和4xA100配置的推理延迟分别增加了13.2倍和12.7倍。因此，卸载参数可以确保正确性，但会对推理性能造成重大影响。
VII. 使用 GENZ 估算平台需求
在本节中，我们回答了这样一个问题：在给定一个大型语言模型（LLM）的使用案例时，应该选择什么样的平台配置来满足服务等级目标（SLO）要求？
预填充（Prefill）和解码（decode）阶段各自提出了一套独特的平台要求。
关键的平台要求指标包括计算操作（PetaFLOPs）、内存带宽（TB/s）和内存容量（GBs）。
这些指标对于理解运行各种工作负载上LLM模型所需的硬件资源至关重要。
这些要求由工作负载决定。我们的目标是量化这些要求并提供分析方程来扩展这些要求。我们通过假设使用案例和模型的其余组件不是瓶颈，来孤立地研究每项要求。
A. 平台内存容量需求
对于平台上的LLM推理，应该有足够内存容量来存储完整的模型参数+KV缓存在NPU的快速内存中。其中KV缓存 = 2 * B * (τp + Sb * τd) * Hkv * D/H * Nlayers。
图15展示了不同模型和使用场景下内存需求的分布。对于LLaMA2-7B、LLaMA3-70B和GPT3-175B，在每次推理迭代中都使用所有模型参数，而在Mixtral-8x7B和GPT4-1.8T中，每次推理周期只激活总模型参数的27%和15%。
随着模型大小的增加，KV缓存参数与活跃权重的比例逐渐减少。具体来说，最大的KV缓存大小（代码生成）与活跃权重的比例分别为82%、11%、20%、27%和2.8%，对应于LLaMA2-7B、Mixtral-8x7B、LLaMA3-70B、GPT3-175B和GPT4-1.8T。
此外，MoE（Mixture of Experts）模型与密集型LLM相比，表现出显著较小的KV缓存。另外，值得注意的是，KV缓存与批量大小成线性扩展。此外，Mixtral 8x7B和LLaMA3-70VB采用GQA（Gated Query Attention）来最小化KV缓存占用，从而增强批量大小能力。
B. 平台计算需求
考虑到预填充阶段主要是计算密集型的，因此所有场景中预填充阶段决定了平台所需的TFLOPs（每秒万亿次浮点运算）的先决条件。图16(a)展示了为满足表IV中的要求，不同模型所需的平台级计算TFLOPs。
计算TFLOPs取决于模型的维度和输入token的数量。在对首次token时间（TTFT）的期望较为宽松的情况下，所需的TFLOPs也会相应减少。当使用RAG（Retrieval-Augmented Generation）进行问答时，由于提示尺寸的增加，所有模型的TFLOPs需求增加了5.41倍。
C. 平台内存带宽需求
满足TPOT（每秒万亿次操作数）约束所需的内存带宽决定了平台的要求。
图16(b)展示了为满足不同工作负载的要求所需的平台级内存带宽。我们假设LLM推理使用的模型权重和KV缓存以FP8（8位浮点格式）存储。
改变数据格式将成比例地增加或减少带宽需求。
对于GPT4，即使上下文长度增加到10倍，从基于QA（问答）的内存带宽需求到基于RAG（检索增强生成）的QA的内存带宽需求仅增加了8%，这归因于模型本身的庞大尺寸。
VIII. 极端规模要求: AI助手
回顾过去几年模型规模的发展轨迹，可以发现模型规模不断扩大的趋势仍在继续。此外，大型语言模型（LLMs）的最大上下文长度也在稳步增加。例如，GPT-4-Prompts数据集，包含多轮对话提示，已经包含了高达90万个token的提示。最近推出的Google Gemini能够在生产环境中容纳高达100万个token的提示。在本节中，我们将详细说明为支持这些具有广泛上下文长度的即将到来的LLMs所需的平台要求，并将其与当前的最先进标准进行对比。
我们设想一个拥有10万亿参数的超级大型语言模型（Super-LLM）作为未来的模型，如表I所示。我们的目标是将Super-LLM作为一个标准的AI助手，能够与人类进行实时对话，提供各种主题的答案，并记住过去的互动。因此，支持大上下文窗口对于AI助手至关重要。这项工作负载可以描述为：Sb=4,τp=可变,τd=2000。鉴于其作为个人助手的角色，我们将以批量大小为1的方式运行它。为了进行无缝对话，我们假设它能够以人类的阅读或听力速度生成输出，这相当于每分钟300个单词。
对于实时会话，KV 缓存会随上下文线性增长，从而导致更高的内存容量和带宽要求。图 17 显示了当上下文长度扩展到 200 万token时，使用超级 LLM 所需的内存带宽和容量。
为了衡量其可行性，我们将其与当前的 SOTA 内存 HBM3e 进行了比较，后者的带宽为 1.2 TB/s，每个堆栈的内存容量为 36 GB。我们需要 40 TB/s 的内存带宽来制作超级 LLMAI 助手，这相当于大约 32 个 HBM3e 堆栈。另一方面，它需要大约 15 TB 的内存容量，相当于 400 个 HBM3e 堆栈。
主要结论
- 平台内存容量似乎比内存带宽更容易成为瓶颈。- 由于模型的稀疏激活，内存带宽处于合理的范围内。内存容量需求的增长似乎不可持续。
IX. 相关工作
LLM推理服务和分析。我们正在看到与LLM推理服务相关的巨大兴起。有关批量优化、内存优化和调度的研究工作。各种文章提供了当前硬件系统上LLM推理性能的指标、分析、见解和最佳实践。各种工作提供了有关现有硬件系统上transformer推理和各种优化的调查。
LLM推理的硬件和硬件建模。Chiplet Cloud是一种基于芯片组的ASIC AI超级计算机架构，它优化了为服务大型生成语言模型而生成的每个token的总拥有成本（TCO）。LLMCompass为其框架模型进行了LLM的DSE，该模型详细建模了NPU架构。在DNN推理设计空间建模方面已经有很多工作，这些工作侧重于建模各种数据流和循环排序的延迟、带宽和能效。除了计算建模，网络模拟器如ASTRA-sim模拟分布式训练中的通信。
X. 结论
随着LLMs的最近进展，设计高效LLM服务的硬件平台变得至关重要，以在保持成本效益的同时提供高吞吐量和低延迟。为了理解不同模型、用例和SLO对LLM推理硬件平台要求的影响，我们引入了GenZ，这是一个一阶分析工具。使用GenZ，我们进行了三项主要分析：
1）不同工作负载优化对性能影响的分析，
2）不同平台特性对性能影响的分析，
3）目标用例和SLO下目标LLM推理的硬件平台要求分析。
我们相信我们提出的工具和分析将为下一代硬件和LLMs的未来平台设计提供指导。
高阅读量文章
