内容编辑转载：语言大模型推理性能工程：最佳实践
在这篇文章中，MosaicML工程师团队分享了如何在生产环境中充分利用流行开源语言大模型（LLM）的最佳实践。此外，他们还提供了围绕模型部署推理服务的指南，以帮助用户更好地选择模型和部署硬件。他们在生产环境中使用了多个基于PyTorch的后
在这篇文章中，MosaicML工程师团队分享了如何在生产环境中充分利用流行开源语言大模型（LLM）的最佳实践。此外，他们还提供了围绕模型部署推理服务的指南，以帮助用户更好地选择模型和部署硬件。他们在生产环境中使用了多个基于PyTorch的后端。这些指南是MosaicML工程师团队基于FasterTransformers、vLLM以及NVIDIA的TensorRT-LLM等背后的经验总结而来。
MosaicML在今年年中先后开源了MPT-7B、MPT-30B语言大模型，随后被Databricks以13亿美元的价格收购。
（以下内容由OneFlow编译发布，转载请联系授权。原文：https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices）
来源 | Databricks
OneFlow编译
翻译｜杨婷、宛子琳
1
理解语言大模型的文本生成
语言大模型的文本生成通常可分为两个阶段：首先是“预填充（prefill）”阶段，这一阶段会以并行方式处理输入提示中的词元；然后是“解码（decoding）”阶段，在这一阶段，文本会以自回归的方式逐个生成“词元”。每个生成的词元都会被添加到输入中，并被重新喂入模型，以生成下一个词元。当LLM输出了特殊的停止词元或满足用户定义的条件（例如生成了最大数量的词元）时，生成过程就会停止。
词元可以是单词或子词，将文本拆分为词元的确切规则因模型而异。例如，我们可以对比LLaMA模型和OpenAI模型对文本进行分词处理的方式。尽管LLM推理服务供应商经常以基于词元的指标（例如每秒处理的词元数）来谈论性能，但由于模型分词规则的差异，这些数字在不同模型类型之间并不总是可比较的。例如，Anyscale团队发现，与ChatGPT的分词长度相比，LLaMA 2的分词长度增加了19%（但整体成本要低得多）。HuggingFace的研究人员也发现，与GPT-4相比，对于相同长度的文本，LLaMA 2训练所需的词元要多20%左右。
2
LLM服务的重要指标
我们应该如何准确衡量模型的推理速度呢？
我们团队使用了以下四个指标：
首个词元生成时间（Time To First Token，简称TTFT）：即用户输入查询后，模型生成第一个输出所需的时间。在实时交互中，低时延获取响应非常重要，但在离线工作负载中则不太重要。此指标受处理提示信息并生成首个输出词元所需的时间所驱动。
单个输出词元的生成时间（Time Per Output Token，简称TPOT）：为每个查询系统的用户生成一个输出词元所需的时间。这一指标与每个用户对模型“速度”的感知相关。例如，TPOT为100毫秒/词元表示每个用户每秒可处理10个词元，或每分钟处理约450个词，这一速度远超普通人的阅读速度。
时延：模型为用户生成完整响应所需的总时间。整体响应时延可使用前两个指标计算得出：时延 = （TTFT）+ （TPOT）*（待生成的词元数）。
吞吐量：推理服务器在所有用户和请求中每秒可生成的输出词元数。
我们的目标是：以最短的时间生成首个词元、达到最高吞吐量以及在最短的时间内生成输出词元。换句话说，我们希望模型能够尽可能快地为尽可能多的用户生成文本。
值得注意的是，我们需要权衡吞吐量和每个输出词元的时间：与依次运行查询相比，如果我们同时处理16个用户查询，吞吐量会更高，但会花费更长的时间为每个用户生成输出词元。
如果你对整体推理时延有具体目标，以下是一些有效的启发式方法可用于评估模型：
输出长度决定了整体响应时延：对于平均时延，通常只需将预期/最大的输出词元长度与模型的每个输出词元的整体平均时间相乘。
输入长度对性能来说影响不大，但对硬件要求至关重要：在MPT模型中，添加512个输入词元增加的时延要少于生成8个额外输出词元的时延。然而，支持长输入的需求可能使模型难以部署。例如，我们建议使用A100-80GB（或更新版本）来为最大上下文长度为2048个词元来部署MPT-7B模型。
整体时延与模型大小呈次线性关系：在相同的硬件上，较大的模型速度较慢，但速度比不一定与参数数量比相匹配。MPT-30B的时延约为MPT-7B时延的2.5倍，LLaMA2-70B的时延约为LLaMA2-13B时延的2倍。
经常有潜在客户要求我们提供平均推理时延。对此，我们建议：在锚定特定时延目标（例如，"单个词元的生成时间低于20毫秒"）之前，你应该花一些时间来描述你预期的输入长度和想要的输出长度。
3
语言大模型推理所面临的挑战
以下通用技术可用于优化语言大模型的推理：
算子融合：将相邻的不同算子合并在一起通常可以获得更短的时延。
量化：对激活值和权重进行压缩，以使用更少的比特数。
压缩：稀疏性或蒸馏。
并行化：在多个设备间进行张量并行，或者针对较大的模型进行流水线并行。
除上述方法以外，还有许多针对Transformer的重要优化技术，如KV（键-值）缓存。在基于Transformer的仅解码器模型中，注意力机制的计算效率较低。每个词元都要关注之前所有已生成的词元，因此每生成一个新词元，都要重新计算许多相同的值。例如，当生成第N个词元时，第（N-1）个词元要关注第（N-2）个词元、（N-3）个词元……直到第1个词元。同样，当生成（N+1）个词元时，第N个词元的注意力机制又需要关注第（N-1）个、（N-2）个、（N-3）个……直至第1个词元。KV缓存则用于保存注意力层的中间键/值，以便后续重复使用，避免重复计算。
4
内存带宽是关键
在LLM中，计算主要由矩阵乘法计算主导；这些维度较小的计算在大多数硬件上通常受内存带宽的限制。在以自回归方式生成词元时，激活矩阵的维度之一（由批大小和序列中的词元数定义）在小型批大小上较小。因此，速度由我们将模型参数从GPU内存加载到本地缓存/寄存器中的速度决定，而不是由计算加载数据的速度决定。相比峰值计算性能，推理硬件中可用和可实现的内存带宽能够更好地预测词元的生成速度。
对于服务成本来说，推理硬件的利用率非常重要。由于GPU的价格十分高昂，因此我们需要尽可能地让它们完成更多工作。共享推理服务通过将多个用户的工作负载组合在一起，填补各自的差距，并将重叠的请求进行批处理，以降低成本。对于LLaMA2-70B等大型模型，只有在较大的批大小下才能实现更好的性价比。拥有能够以较大批大小运行的推理服务系统对于成本效率至关重要。然而，较大的批大小意味着较大的KV缓存，这反过来又增加了部署模型所需的GPU数量。我们需要在这两者之间博弈，进行取舍，共享服务运营商需要权衡成本，优化系统。
5
模型带宽利用率（MBU）
LLM推理服务器的优化程度如何？
正如之前的简要解释，对于LLM来说，在更小的批大小下进行推理，特别是在解码阶段，其性能受到从设备内存到计算单元加载模型参数的速度限制。内存带宽决定了数据搬运的速度。为测量底层硬件利用率，我们引入了一个名为模型带宽利用率（MBU）的新指标。MBU的计算公式为（实际内存带宽）/（峰值内存带宽），其中实际内存带宽为（（总模型参数大小+KV缓存大小）/ TPOT）。
例如，如果一个由70亿参数构成的16位精度的模型，在TPOT为14毫秒的情况下，它在14毫秒内传输了14GB的参数，这就意味着其带宽用量为1TB/秒。如果机器的峰值带宽为2TB/秒，则我们是以50%的MBU在运行。
为简单起见，这个例子忽略了KV缓存大小，在较小的批次大小和较短的序列长度上，KV缓存也较小。接近100%的MBU值意味着推理系统有效地利用了可用的内存带宽。MBU还可用于以标准化的方式比较不同的推理系统（硬件+软件）。MBU与模型FLOPs利用率（MFU，由PaLM论文引入的指标）互补，后者在计算受限的情况下非常重要。
图1以类似屋顶线图（roofline plot）的方式展示了MBU，橙色阴影区域中的实斜线表示内存带宽100%饱和时的最大可能吞吐量。然而，在现实情况下，对于小批次大小（白点），观察到的性能低于最大吞吐量，降低程度可通过MBU来度量。对于大批次（黄色区域），系统受计算限制，相对于理论最高吞吐量，实际所占的吞吐量以MFU衡量。
————————————————
版权声明：本文为CSDN博主「OneFlow深度学习框架」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/OneFlow_Official/article/details/134046927
MosaicML在今年年中先后开源了MPT-7B、MPT-30B语言大模型，随后被Databricks以13亿美元的价格收购。
（以下内容由OneFlow编译发布，转载请联系授权。原文：https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices）
来源 | Databricks
OneFlow编译
翻译｜杨婷、宛子琳
1
理解语言大模型的文本生成
语言大模型的文本生成通常可分为两个阶段：首先是“预填充（prefill）”阶段，这一阶段会以并行方式处理输入提示中的词元；然后是“解码（decoding）”阶段，在这一阶段，文本会以自回归的方式逐个生成“词元”。每个生成的词元都会被添加到输入中，并被重新喂入模型，以生成下一个词元。当LLM输出了特殊的停止词元或满足用户定义的条件（例如生成了最大数量的词元）时，生成过程就会停止。
词元可以是单词或子词，将文本拆分为词元的确切规则因模型而异。例如，我们可以对比LLaMA模型和OpenAI模型对文本进行分词处理的方式。尽管LLM推理服务供应商经常以基于词元的指标（例如每秒处理的词元数）来谈论性能，但由于模型分词规则的差异，这些数字在不同模型类型之间并不总是可比较的。例如，Anyscale团队发现，与ChatGPT的分词长度相比，LLaMA 2的分词长度增加了19%（但整体成本要低得多）。HuggingFace的研究人员也发现，与GPT-4相比，对于相同长度的文本，LLaMA 2训练所需的词元要多20%左右。
2
LLM服务的重要指标
我们应该如何准确衡量模型的推理速度呢？
我们团队使用了以下四个指标：
首个词元生成时间（Time To First Token，简称TTFT）：即用户输入查询后，模型生成第一个输出所需的时间。在实时交互中，低时延获取响应非常重要，但在离线工作负载中则不太重要。此指标受处理提示信息并生成首个输出词元所需的时间所驱动。
单个输出词元的生成时间（Time Per Output Token，简称TPOT）：为每个查询系统的用户生成一个输出词元所需的时间。这一指标与每个用户对模型“速度”的感知相关。例如，TPOT为100毫秒/词元表示每个用户每秒可处理10个词元，或每分钟处理约450个词，这一速度远超普通人的阅读速度。
时延：模型为用户生成完整响应所需的总时间。整体响应时延可使用前两个指标计算得出：时延 = （TTFT）+ （TPOT）*（待生成的词元数）。
吞吐量：推理服务器在所有用户和请求中每秒可生成的输出词元数。
我们的目标是：以最短的时间生成首个词元、达到最高吞吐量以及在最短的时间内生成输出词元。换句话说，我们希望模型能够尽可能快地为尽可能多的用户生成文本。
值得注意的是，我们需要权衡吞吐量和每个输出词元的时间：与依次运行查询相比，如果我们同时处理16个用户查询，吞吐量会更高，但会花费更长的时间为每个用户生成输出词元。
如果你对整体推理时延有具体目标，以下是一些有效的启发式方法可用于评估模型：
输出长度决定了整体响应时延：对于平均时延，通常只需将预期/最大的输出词元长度与模型的每个输出词元的整体平均时间相乘。
输入长度对性能来说影响不大，但对硬件要求至关重要：在MPT模型中，添加512个输入词元增加的时延要少于生成8个额外输出词元的时延。然而，支持长输入的需求可能使模型难以部署。例如，我们建议使用A100-80GB（或更新版本）来为最大上下文长度为2048个词元来部署MPT-7B模型。
整体时延与模型大小呈次线性关系：在相同的硬件上，较大的模型速度较慢，但速度比不一定与参数数量比相匹配。MPT-30B的时延约为MPT-7B时延的2.5倍，LLaMA2-70B的时延约为LLaMA2-13B时延的2倍。
经常有潜在客户要求我们提供平均推理时延。对此，我们建议：在锚定特定时延目标（例如，"单个词元的生成时间低于20毫秒"）之前，你应该花一些时间来描述你预期的输入长度和想要的输出长度。
3
语言大模型推理所面临的挑战
以下通用技术可用于优化语言大模型的推理：
算子融合：将相邻的不同算子合并在一起通常可以获得更短的时延。
量化：对激活值和权重进行压缩，以使用更少的比特数。
压缩：稀疏性或蒸馏。
并行化：在多个设备间进行张量并行，或者针对较大的模型进行流水线并行。
除上述方法以外，还有许多针对Transformer的重要优化技术，如KV（键-值）缓存。在基于Transformer的仅解码器模型中，注意力机制的计算效率较低。每个词元都要关注之前所有已生成的词元，因此每生成一个新词元，都要重新计算许多相同的值。例如，当生成第N个词元时，第（N-1）个词元要关注第（N-2）个词元、（N-3）个词元……直到第1个词元。同样，当生成（N+1）个词元时，第N个词元的注意力机制又需要关注第（N-1）个、（N-2）个、（N-3）个……直至第1个词元。KV缓存则用于保存注意力层的中间键/值，以便后续重复使用，避免重复计算。
4
内存带宽是关键
在LLM中，计算主要由矩阵乘法计算主导；这些维度较小的计算在大多数硬件上通常受内存带宽的限制。在以自回归方式生成词元时，激活矩阵的维度之一（由批大小和序列中的词元数定义）在小型批大小上较小。因此，速度由我们将模型参数从GPU内存加载到本地缓存/寄存器中的速度决定，而不是由计算加载数据的速度决定。相比峰值计算性能，推理硬件中可用和可实现的内存带宽能够更好地预测词元的生成速度。
对于服务成本来说，推理硬件的利用率非常重要。由于GPU的价格十分高昂，因此我们需要尽可能地让它们完成更多工作。共享推理服务通过将多个用户的工作负载组合在一起，填补各自的差距，并将重叠的请求进行批处理，以降低成本。对于LLaMA2-70B等大型模型，只有在较大的批大小下才能实现更好的性价比。拥有能够以较大批大小运行的推理服务系统对于成本效率至关重要。然而，较大的批大小意味着较大的KV缓存，这反过来又增加了部署模型所需的GPU数量。我们需要在这两者之间博弈，进行取舍，共享服务运营商需要权衡成本，优化系统。
5
模型带宽利用率（MBU）
LLM推理服务器的优化程度如何？
正如之前的简要解释，对于LLM来说，在更小的批大小下进行推理，特别是在解码阶段，其性能受到从设备内存到计算单元加载模型参数的速度限制。内存带宽决定了数据搬运的速度。为测量底层硬件利用率，我们引入了一个名为模型带宽利用率（MBU）的新指标。MBU的计算公式为（实际内存带宽）/（峰值内存带宽），其中实际内存带宽为（（总模型参数大小+KV缓存大小）/ TPOT）。
例如，如果一个由70亿参数构成的16位精度的模型，在TPOT为14毫秒的情况下，它在14毫秒内传输了14GB的参数，这就意味着其带宽用量为1TB/秒。如果机器的峰值带宽为2TB/秒，则我们是以50%的MBU在运行。
为简单起见，这个例子忽略了KV缓存大小，在较小的批次大小和较短的序列长度上，KV缓存也较小。接近100%的MBU值意味着推理系统有效地利用了可用的内存带宽。MBU还可用于以标准化的方式比较不同的推理系统（硬件+软件）。MBU与模型FLOPs利用率（MFU，由PaLM论文引入的指标）互补，后者在计算受限的情况下非常重要。
图1以类似屋顶线图（roofline plot）的方式展示了MBU，橙色阴影区域中的实斜线表示内存带宽100%饱和时的最大可能吞吐量。然而，在现实情况下，对于小批次大小（白点），观察到的性能低于最大吞吐量，降低程度可通过MBU来度量。对于大批次（黄色区域），系统受计算限制，相对于理论最高吞吐量，实际所占的吞吐量以MFU衡量。
————————————————
版权声明：本文为CSDN博主「OneFlow深度学习框架」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/OneFlow_Official/article/details/134046927
