引言 — 这篇文章详细介绍了分析工具 GenZ，用于研究 LLM 推理性能与各种平台设计参数之间的关系。该工具量化了在不同服务设置下支持 SOTA LLM 的平台要求。此外，文章还预测了支持未来可能超过数百万亿个参数的 LLM 所需的硬件能力。从 GenZ 中得出的趋势和见解可以为部署 LLM 的人工智能工程师以及设计下一代硬件加速器和平台的计算机架构师提供指导。源代码可在 GitHub 上获取。
本文包括两篇，此为第一篇。
原论文已经上传至知识星球。
摘要--要在各种推理用例中高效部署这些参数繁重的模型，需要精心设计具有充足计算、内存和网络资源的硬件平台。
在这项工作中，我们提出了一个分析工具 GenZ，用于研究 LLM 推理性能与各种平台设计参数之间的关系。
我们的分析提供了针对不同 LLM 工作负载和用例配置平台的见解。我们量化了在不同服务设置下支持 SOTA LLM 的平台要求。
此外，我们还预测了支持未来可能超过数百万亿个参数的 LLM 所需的硬件能力。
从 GenZ 中得出的趋势和见解可以为部署 LLM 的人工智能工程师以及设计下一代硬件加速器和平台的计算机架构师提供指导。
最终，这项工作揭示了在各种应用中释放大型语言模型全部潜力的平台设计注意事项。源代码可在 GitHub 上获取。
I. 前言
大型语言模型（LLM）是执行自动回归任务的生成式人工智能模型中最流行的变体之一。
LLM 已经显示出巨大的Scaling Law的特性，与较小的模型相比，较大的模型显示出更好的性能。
目前，已知最大的模型有 1.8T 个参数，未来的 LLM 有可能超过几百兆个参数。
预填充阶段包括使用所有输入token的单一前向传递。自动回归解码阶段在模型的每次前向传递中生成一个输出token。
预填充阶段通常具有与训练前向传递类似的特征，并且对计算要求很高。相比之下，解码阶段需要内存带宽和容量（特别是在处理长上下文查询时）。
如何为 LLM 推理设计下一代硬件平台？
这并非易事，因为有大量精度和上下文长度不断增加的新兴LLM，有多种多样的LLM推理用例，还有不同的AI平台供应商（如英伟达、英特尔、AMD等）。
这项工作的目的是揭开人工智能平台需求（即计算 FLOPs、内存容量、内存带宽、互联延迟和互联带宽）的神秘面纱，并对这些需求进行量化。
为此，我们引入了一个一阶分析模型，即 GenZ（Generative LLM analyZer），来提炼不同硬件参数对端到端推理性能的影响。利用这一工具，我们可以通过硬件组件的效率因子（通过实际系统验证测量确定）来研究当前的平台，而不会受限于其特定的软件工具链。我们还使用 GenZ 来量化不同 LLM 用例的硬件要求。据我们所知，这是第一项针对不同用例，量化整个平台满足生成式人工智能模型服务 SLO 要求的工作。
首先，这项工作提供的数据有可能指导从事 LLM 部署工作的人工智能工程师为他们的用例选择合适的硬件平台配置。
其次，这项工作为计算机架构师设计下一代人工智能平台提供了具体指导，因为它能引导各种硬件特性与 LLM 推断性能之间的相互作用。
我们对填充和解码阶段的服务需求进行了量化，并注意到两者之间存在显著差异。我们发现 FLOPS 和互连 BW 是预填充阶段的瓶颈，而内存 BW 和互连链路延迟则是解码阶段的关键瓶颈。
GenZ工具：
一种一阶分析工具，可帮助分析不同平台上的 LLM 工作负载。
分析了不同工作负载优化对性能的影响。
分析了不同平台特性对性能的影响。
分析了目标 LLM 推理的平台要求，以满足给定的服务级别目标（SLO：Service Level Objectives）和目标使用场景。
II. 主要结论
LLM 推理过程的预填充和解码阶段在工作量上有显著差异。
我们发现，增加 TFLOPS 和芯片间带宽可减少预填充延迟，但不会影响解码延迟。
另一方面，增加高速内存带宽（HBM）和减少芯片间网络链接延迟有助于改善解码阶段的延迟，但不会减少预填充阶段的延迟。
我们还发现，并行化在大型系统中发挥着重要作用，在预填充阶段，使用流水线并行化可获得最佳吞吐量。在解码阶段，混合使用张量并行和流水线并行对大型系统的吞吐量来说是最佳的，而对小型系统来说则是张量并行。.
我们还量化了在各种使用情况下满足各种模型的 SLO 吞吐量要求，并提供了根据使用情况和模型变化修改需求的分析公式。
III. 背景介绍
A.LLM 架构
如图 3 所示，LLM 通常是通过堆叠多个Transformer解码器层来设计的 [124]。每层包括多头自注意（MHA：multi-head self-attention）和多层感知（MLP：nd a multi-layer perception）。
关键模型参数主要包括模型嵌入维度（Dmodel）、头部数量（H）、前馈隐藏维度（Dff），其中 Dff 为 Wff ∗Dmodel，以及解码器块/层数量（L）。
对于每个解码器层，输入序列被投射到三个线性块上，产生三个激活，即 "查询（Q）"、"键（K）"和 "值（V）"。
然后，Q/K/V 值被拆分成 H 块（chunk），每块宽度为 d，其中 d = Dmodel/H，可以并行计算。
对于具有分组查询注意力（GQA）的 LLM，会生成 K/V 的 Hkv 块，这些块由 Q 在 H/Hkv 头中共享。对于每个注意力头，相应的 Q 和 K 被送入批量矩阵乘法运算，然后进行缩放并通过softmax运算计算注意力分数。
注意力分数与 V 块相乘，产生输出激活，然后通过另一个线性层进行投射。
MLP 模块由三个线性层组成。FFup 和 FFgate 将 Dmodel 的输入投射到更高的中间维度 Dff。FFgate 的输出通过非线性运算激活。FFdown 将元素相乘的输出投影回 Dmodel。MLP 的输出与 MLP 的输入相加并归一化。
混合专家（MoE） 是一类特殊的 LLM，它由多个 "专家 "多层感知器（MLP）层（用 "E "表示）组成，每个输入标记从中选择 "K "个专家。与此相反，密集语言模型可被视为 MoE 的一种特例，其中 E = K =1，即只有一个专家 MLP 层，且用于每个输入token。
通过引入多个专家并对每个标记选择性地激活其中的一个子集，MoEs 可以有效地扩展模型容量，同时保持高效的计算和内存使用，这使其成为构建规模更大、功能更强的语言模型的理想方法。
B.生成式 LLM 推理
预填充。预填充阶段只对输入的 τp Token序列运行一次，为每个 LLM 层生成 K 和 V 激活，这些激活通常被保存为 KV 缓存。生成的 KV 缓存将用于所有后续输出Token的生成。
表 II 显示了每个 LLM 解码层在预填充阶段的operator明细。Cop和Mop是operator所需的浮点运算次数和内存需求。由于所有输入token都可以并行处理，因此预填充阶段主要以计算为限(computing bounded)。
解码。在预填充阶段之后，输出token自动递增生成，即每次迭代都将最后生成的token作为 LLM 的输入，并生成一个新的输出 "token"。
表 III 显示了每个 LLM 解码层在解码阶段的operator细分。Cop 和 Mop 是operator所需的浮点运算次数和内存需求。
所有模型权重和过去的 KV 缓存都用于生成单个输出token。由于模型的输入是单个token，所有矩阵-矩阵乘法都转换为矩阵-向量乘法。这使得生成阶段高度受内存限制(memory bounded)。在每个生成步骤结束时，新生成的 KV 缓存会被填充到现有的 KV 缓存中，这意味着它与输出序列长度呈线性增长。我们定义在解码阶段τd个tokens被生成。
波束搜索是一种启发式搜索算法，常用于 LLM 的解码过程中。它通过同时探索多个潜在序列，帮助生成更多上下文相关和连贯的词序列。最大并行序列的数量是一个由用户定义的参数，称为 "波束大小"（BeamSize，Sb）。通常情况下，生成推理的 Sb = 4。
在生成式 LLM 推理过程中，模型会根据之前的上下文预测下一个单词，并通过波束搜索维持一组可能的候选序列。这些候选序列按其可能性排序，算法通过考虑其他词语选择不断完善这些序列。通过并行探索预定数量的可能性，波束搜索提高了生成文本的质量。在共同预填充阶段之后，解码阶段会启动两个并行波束。选择可能性最大的波束作为最终输出。
C.检索增强生成（Retrieval Augmented Generation）
尽管有望成为通用人工智能（AGI）的一个令人兴奋的范式，但LLMs仍然受到事实幻觉、不完整、过时或不正确的知识以及缺乏特定领域知识的障碍。
通过检索增强生成（RAG）增强LLMs的外部知识已被证明可以有效应对所有此类挑战。在预填充之前，RAG 接受输入查询嵌入，使用 KNN 搜索将其与大型向量数据库进行比较，并使用从数据库中检索到的 k 个最相似的向量来增强查询。由于这些知识数据库的大小可能达到数万亿，因此多年来已经提出了几种ANN（近似最近邻）技术，包括IVF-PQ、HNSW、SONG 和CAGRA ，这些技术在搜索延迟和内存大小与精度之间进行权衡。
在 LLM 服务中使用 RAG 的关键含义是输入提示词（input prompt）大小的显着增加。这会导致更高的 Time Per Output Token （TPOT） 和更大的 KV 缓存。我们将在第七节中详细研究这些影响。
D.LLM的服务评估指标
LLM 推理服务 [42] 的关键指标是：
1） 首次token时间 （TTFT）：完成具有整个输入 τp 的一次前向传递并生成一个输出token的时间.
2） 每个输出令牌的时间 （TPOT ）： 为每个请求生成输出token的时间。连续token的时间几乎与token产生的时间一致。 第 i 个输出token的TPOT与模型权重和τp + i 成正比。
3） 延迟 （Tlat）：模型为用户生成完整响应所需的总时间。总体反应可以使用前两个指标来计算延迟：Tlat = TTTFT + TTPOT × τd。
4） 吞吐量 （μthr）：指推理平台在 B 的批量大小（batch size）下，每秒可以生成的输出token数。μthr = B / TTPOT
IV. GenZ：生成式LLM分析工具
在这项工作中，我们旨在了解平台的需求，以满足不同用例的LLM的服务水平目标（SLO）。
平台被定义为通过互连网络连接的各种加速器的集合，例如 Nvidia HGX 、Google TPU pods、Intel HLS-Gaudi2、AMD Instinct MI300X 平台 等等。
社区中缺乏现有的工具/框架来帮助我们研究具有不同输入的不同操作点的 LLM 推理。
为了解决这个问题，我们构建了一个一阶分析工具，即GenZ。GenZ 有三个关键组件：1） Model Profiler，2） NPU Characterizer，以及 3） Platform Characterizer。我们在图 2 中展示了 GenZ 的概述，并在以下各节中讨论其每个组成部分。
A.目标用例
与以前的DNN模型，例如ResNet相比，LLM有一个很大的区别，就是模型执行形态在不同的用例之间改变很大。
区中缺乏现有的工具/框架来帮助我们研究具有不同输入的不同操作点的 LLM 推理。
一个用例可以被特征化为三个主要特性：
1) 束尺寸，Sb：在解码阶段保持并行输出的数量。通常值：2-4。
2）输入token数，τp：用户作为输入提示词传入的token数量。该值随不同的应用而变化。TTTFT 主要取决于 τp。
3)输出token数，τd：在解码阶段以自动递归方式生成的token数。与 τp 类似，该值在不同应用中也有很大差异。
表 IV 显示了我们在这项工作中考虑的五个用例，它们具有不同的输入token长度、输出token长度和延迟限制。
这些用例代表了不同的实际应用，如聊天服务、代码生成、摘要和问题解答。此外，几乎所有基于问题解答的 LLM 代理都使用了检索增强生成（RAG）。我们还将其作为一个单独的用例进行建模，在这种情况下，输入token会将上下文附加到输入提示中。
我们使用 LLM 工作负载一词来指运行在硬件平台上并提出特定计算要求的特定任务，并将其定义如下：
W orkload = {U secase, LLM Model, Optimizations}
其中，Optimizations = {BatchSize, Precision, Parallelism}
我们使用各种hugging face数据集和LLaMA tokenizer来估算各种用例的输入和输出token。
我们使用dophin数据集进行聊天服务token估算。我们使用 LongBench对文本摘要和代码生成进行平均token估算。
B.Model Profiler
表 I 显示了我们在这项工作中研究的各种 LLM 的详细信息。我们考虑了五个不同的模型，作为当前最先进 LLM 的代表集。我们选择的模型代表了从 7B 到 1.8T 参数 LLM 的全部模型规模。
我们还拥有不同架构的模型，包括基于 MoE 的 LLM（Mixtral-8x7B 和 GPT4）。LLaMA2、LLaMA3、Mix-tral 和 GPT3 架构均可公开获取。我们将 GPT4 表示为 1.8T 参数的专家混合模型，共有 120 层。GPT4 的单层有 16 个专家，每个专家又111B个参数，对于每个token有两个专家被激活。有55个共享的注意力参数。
每个前向推理（生成 1 个token）使用约 280B 个参数和约 560 TFLOP。一个密集的 1.8 万亿参数模型每次推理大约需要 3,700 TFLOP。
我们还开发了一个未来的超级 LLM 模型，它使用了一个按比例放大的 MoE 模型--超级 LLM。每层有 32 个专家，共有约 10T 个参数。一共有128层，每个token有四个专家被激活。
对于每个新模型，GenZ 都会使用hugging face自动建模工具 来确定模型中每个算子的精确形态。
由于 LLM 的所有层都是相同的，因此我们只需要保存一层的算子维度。
所有 LLM 的层尺寸都可以用几个变量来建模，如表 I 所示。利用这些存储的变量，我们可以计算 TFLOPS、权重大小、KV 缓存估算以及算术强度等指标。
离线储存这些模型算子可以让我们为任意的LLM模型建模更大的上下文长度。例如，LLaMA2-7B的上下文长度限制为 4K，但利用这种离线建模，我们可以将上下文长度扩展到任何大小。
在模型建模的这一阶段，我们还对流行的优化进行了建模，包括内核融合（Flash Attention，FLAT, Segment KV Caching ）和模型量化（FP16, INT8/FP8, INT4/FP4）。由于这项工作专注在LLM的推理，我们默认使用INT8来做量化精度，来进行我们的实验和分析，除非特别指出。
在对 GenZ 上的 MoE 模型进行剖析时，对于解码，我们假设无论批量大小如何，在每个解码步骤的每一层都只选择'k'个专家。在表 I 中，我们将 "k "的值表示为最后一列选择的专家。对于 "预填充"，我们假定所有专家都会因大量 token 而被激活，与批量大小无关。
C.NPU Characterizer
我们最小的硬件单元是加速器（又称 NPU），如图 2 所示。我们假设每个 NPU 都有一定数量的高效计算内核，每秒可执行 F LOP S 数量的运算。
为了限制讨论范围，我们假设片上内存足以实现最高计算效率。此外，我们还加入了计算效率因子，以考虑软件和内存同步问题导致的低效率。
每个 NPU 可访问两个外部存储器（快存储器和慢存储器）。较快（较小）的存储器可以是类似 HBM/DDR 存储库的存储器，而较慢（较大）的存储器可以是 PCIe 访问 CPU 存储器或 CXL 访问 SSD/闪存。大多数模型权重和激活将优先使用较快的内存，但是，如果容量不够，数据可能会被卸载到较慢的内存中。虽然这会大大降低推理性能，但仍能实现推理，而不会出现内存不足（OOM）错误。
对于该系统，我们逐个按照算子来分析模型性能。我们采用基于顶线的方法计算每个算子在加速器上的运行时间。
Sfast 是分配给每个算子的快速内存分区。如果 Mop > Sfast，算子的额外数据将被卸载到较慢的内存中。
由于所有参数、模型权重和 KV 缓存都是统一使用的，因此将有固定比例的参数被卸载。使用理想的预取调度程序，每个算子从慢速存储器读取数据的时间可以与从高速存储器读取数据的时间重叠，而被掩盖。因此，总的内存读取时间将如公式 1 所示。
D.Platform Characterizer
我们将推理平台定义为使用互连网络（ICN）连接的多个 NPU，如图 2 所示。
一个 ICN 可以有不同的拓扑连接、链路延迟和不同的链路带宽。
通常，分布式 LLM 采用五种不同类型的并行策略：数据并行（DP）、张量并行（TP）、流水线并行（PP）[78]、专家并行（EP）（仅用于 MoE 模型）和序列并行（SP）（主要用于训练长序列）。
对于 TP LLM，每层需要两次all-reduce通信原语，因此 LLM 的每次前向传递总共需要进行 2× 层数的all-reduce调用。
我们讲all-reduce通信进行建模。
对于信息大小为 M 的all-reduce通信，其中 M 是每个加速器的初始/最终数据大小，N 是以张量并行方式分配模型的加速器数量。每个加速器向 N-1 个相邻加速器发送 M/N 大小的数据。All-reduce时间模型为：
对于 LLM 的 PP 分布，只需要节点到节点的信息传递。在这种情况下，传输大小为 M 的信息所需的时间定义为 TN2N。
对于 EP，需要在所有节点之间进行两次all-to-all传输，这些节点共享一层的专家。
SP的每层需要进行all gather和reduce scatter 操作。
在我们的建模中，我们有一个选项，可以决定是将集合通信任务与计算任务重叠，还是顺序执行。协调集合通信与算子计算的同时执行是一个开放性的问题以及研究挑战。
由于现有的 SOTA LLM 推理服务框架并不包含这些技术，我们选择将互联集合通信建模为非重叠。考虑到这些因素，模型执行时间由 (6) 定义。
E.GenZ验证研究
我们在真实的硬件平台上对 GenZ 进行了验证：HGX服务器配备了8个NVIDIA H100 SXM GPU（80 GB），通过NVLinks完全连接。
我们进行了两类研究：
(i) 单个加速器系统上的预填充和解码，以验证 GenZ 的加速器建模。
(ii) 在不同的平台上验证集合通信与互联模型。
单个加速器平台验证：在第一项研究中，我们在 H100 GPU 上使用 vLLM框架为 LLaMA2-7B 和 LLaMA2-13B 模型提供服务。
对于每个模型，我们运行了两个用例（Sb = 1, τp = 544, τd = 200）和（Sb = 1, τp = 2173, τd = 200），并获得了 LLM 服务指标（TTFT、TPOT）。
我们将结果与GenZ提供的建模结果进行比较。
由于 GenZ 的目的是提供一阶分析，我们插入经验测得的 GPUTensor TFLOPs 效率系数为 60%，GPU 内存带宽效率系数为 70%。图 4 显示了两个模型的 TTFT 和 TPOT 时间比较。实际值和模型值之间的 TTFT 和 TPOT 地球均方根误差分别为 5.88% 和 3.86%。这证实了 GenZ 产生的趋势与实际硬件上观察到的趋势一致。
平台互连验证：为了在平台规模上验证集合时间，我们使用 nccl-tests对 all-reduce 通信原语进行基准测试，NCCL-tests 是 NVIDIA GPU 的通信原语性能基准测试。
GenZ 的通信时间在 2 个 GPU、4 个 GPU 和 8 个 GPU 的平台大小下得到验证。
对于集合通信，我们观察到NVLINK的平均链路效率为75%，这使得每个GPU inHGX盒的有效链路带宽为350 GB/s。
我们分析了用例（表IV）和模型（表I）的所有组合，并收集它们的all-reduce（AR）消息大小。
对于解码，每次 AR 调用的消息大小非常小（< 128KB），而对于预填充，每次调用的消息大小为几百 MB。图 5 比较了三种不同平台大小的真实硬件延迟以及 GenZ 产生的相应延迟。
由于预填充和解码阶段在消息大小上存在明显差异，因此我们独立验证预填充和解码的集合通信时间。我们发现，对于解码消息的大小，链接延迟，TLink 是主要的，因此延迟似乎几乎是恒定的。然而预填充的 AR 消息足够大，但链路带宽 BWLink 是集体时间的主要贡献者。对于所有数据点，实际值和 GenZ 值之间的解码和预填充消息大小存在 3.89% 和 2.7% 的几何平均误差。
高阅读量文章
