如何衡量推理性能
我们应该如何考虑LLM的推理速度呢？可以使用四个关键指标来衡量LLM的服务性能：
1.首个Token响应时间（TTFT）：用户输入查询后，多快可以开始看到模型的输出。在实时交互中，响应时间需要尽可能短，但在离线工作负载中则不那么重要。这个指标由处理提示信息和生成第一个输出token所需的时间决定。
2.每个输出Token的时间（TPOT）：系统生成每个用户查询的输出token所需的时间。这个指标与用户感知模型“速度”的方式直接相关。例如，如果TPOT是100毫秒/token，那么每秒可以生成10个token，或者每分钟约450个词，这比一般人的阅读速度要快。
3.延迟：模型生成用户完整响应所需的总时间。总体响应延迟可以使用前两个指标来计算：延迟=(TTFT)+(TPOT)(需要生成的token数量)。
4.吞吐量：推理服务器每秒可以为所有用户和请求生成的输出令牌数量。
这些指标帮助我们评估和优化模型在处理请求时的效率和速度。
我们的目标是什么？最快的首个token响应时间、最高的吞吐量和最快的每个输出token时间。换句话说，我们希望我们的模型能够尽可能快地为尽可能多的用户生成文本。
值得注意的是，吞吐量和每个输出token的时间之间存在权衡：如果我们同时处理16个用户查询，与顺序执行查询相比，我们将拥有更高的吞吐量，但生成每个用户的输出令牌所需的时间会更长。
根据不同的总体推理时延目标，可以参考如下经验：
输出长度主导总体响应延迟：对于平均延迟，您通常可以取预期或最大输出token长度，并将其乘以模型的整体平均每个输出token的时间。
输入长度对性能影响不大，但对硬件要求很重要：对于MPT模型，增加512个输入token的延迟增加少于生成8个额外输出token。然而，支持长输入的需求可能使模型更难服务。例如，我们推荐使用A100-80GB（或更新型号）来服务最大上下文长度为2048 token的MPT-7B。
总体延迟与模型大小的增长呈次线性关系：在相同的硬件上，更大的模型运行更慢，但速度比率不一定与参数数量比率相匹配。MPT-30B的延迟约为MPT-7B的2.5倍。Llama2-70B的延迟约为Llama2-13B的2倍。
我们经常被潜在客户问到要提供平均推理延迟。我们建议，在您确定具体的延迟目标（“我们需要每个token少于20毫秒”）之前，您应该花一些时间来描述您的预期输入和期望的输出长度。
LLM推理的挑战
优化LLM推理可以从一些通用技术中受益，例如：
算子融合（Operator Fusion）：将不同的相邻算子结合在一起，通常可以减少中间变量和内存操作，获得更好的延迟。
量化：使用更少的比特数压缩激活和权重值。
压缩：稀疏性或蒸馏。
并行化（Parallelization）：对较大模型在多个设备上进行张量并行处理或流水线并行处理。
除了这些方法之外，还有许多重要的特定于Transformer的优化。一个典型的例子是KV缓存。仅解码器的Transformer模型中的注意力机制在计算上是低效的。每个token都会关注之前看到的所有token，因此随着每个新token的生成，会重新计算许多相同的值。例如，在生成第N个令牌时，第(N-1)个令牌会关注第(N-2)个、第(N-3)个……第1个token。同样，在生成第(N+1)个token时，第N个token的注意力再次需要查看第(N-1)个、第(N-2)个、第(N-3)个……第1个token。KV缓存，即保存注意力层中的中间键/值，用于保留这些结果以便后续重用，避免重复计算。
内存带宽是关键
LLM中的计算主要由矩阵乘法操作主导；这些具有小尺寸的操作在大多数硬件上通常受到内存带宽的限制。在自回归方式生成token时，激活矩阵的一个维度（由批量大小和序列中的token数量定义）在小批量时较小。因此，速度依赖于我们能多快从GPU内存加载模型参数到本地缓存/寄存器，而不是我们能多快地在加载的数据上进行计算。在推理硬件中可用和实际达到的内存带宽是预测token生成速度的更好指标，而不是它们的峰值计算性能。
推理硬件的利用率在服务成本方面非常重要。GPU昂贵，我们需要它们尽可能多地工作。共享推理服务通过将来自许多用户的工作负载结合起来，填补个别空白并批量处理重叠的请求，承诺降低成本。对于像Llama2-70B这样的大型模型，我们只有在大批量大小时才能实现良好的成本/性能比。拥有一个能够在大批量大小下运行的推理服务系统对于成本效率至关重要。然而，大批量意味着更大的KV缓存大小，这反过来又增加了服务模型所需的GPU数量。这里存在一个拉锯战，共享服务运营商需要做出一些成本权衡并实施系统优化。
模型带宽利用率（MBU）
LLM推理服务是如何优化的？
如前所述，尤其是在解码时，小批量大小的LLM推理受限于我们能多快从设备内存加载模型参数到计算单元。内存带宽决定了数据移动的速度。为了衡量底层硬件的利用率，我们引入了一个新的指标称为模型带宽利用率（MBU）。MBU定义为（实际内存带宽）/（峰值内存带宽），其中实际内存带宽为（总模型参数大小+KV缓存大小）/TPOT。
例如，如果一个7B参数模型以16位精度运行，TPOT等于14ms，那么它在14ms内移动了14GB的参数，相当于1TB/秒的带宽使用。如果机器的峰值带宽为2TB/秒，我们的MBU为50%。为简单起见，这个例子忽略了KV缓存大小，它在较小的批量大小和较短的序列长度时较小。MBU接近100%表明推理系统有效地利用了可用的内存带宽。MBU也有助于以标准化的方式比较不同的推理系统（硬件+软件）。MBU是对模型Flops利用率的补充，后者在计算受限的设置中很重要。
图1 在类似于roofline的图表中展示了MBU的图形表示。橙色阴影区域的实线斜线显示了如果内存带宽完全饱和（100%）时可能达到的最大吞吐量。然而，实际上对于小批量大小（白点），观察到的性能低于最大值——低多少是MBU的一个衡量标准。对于大批量大小（黄色区域），系统受到计算限制，实际达到的吞吐量作为峰值可能吞吐量的一部分被测量，这就是模型Flops利用率（MFU）。
MBU和MFU决定了在给定硬件设置推动推理速度的空间有多大。图2 显示了我们基于TensorRT-LLM的推理服务在不同张量并行度下测量的MBU。当传输大块连续内存时，可以达到峰值内存带宽利用率。当像MPT-7B这样的较小模型分布在多个GPU上时，我们观察到较低的MBU，因为我们在每个GPU中移动的内存块较小。
图3实证观察了在NVIDIA H100 GPU上，不同张量并行度和Tensor大小下的MBU。随着批量大小的增加，MBU减少。然而，随着GPU的扩展，MBU的相对减少不那么显著。同样值得注意的是，选择具有更大内存带宽的硬件可以用更少的GPU提升性能。在批量大小为1时，我们可以在2xH100-80GB上实现高达60%的MBU，相比之下，在4xA100-40GBGPU上的MBU为55%（见图2）。
基准测试结果
延迟
我们已经测量了在不同Tensor并行度下，MPT-7B和Llama2-70B模型的首个token响应时间（TTFT）和每个输出token的时间（TPOT）。随着输入提示的增长，生成第一个Token所需的时间开始占据总延迟的大部分。在多个GPU之间进行Tensor并行有助于减少这种延迟。
与模型训练不同，增加更多GPU对推理延迟提升的回报有显著的递减。例如，对于Llama2-70B模型，从4x增加到8x GPU在小批量大小时仅将延迟减少0.7倍。其中一个原因是更高的并行度具有较低的MBU（如前所述）。另一个原因是Tensor并行引入了GPU节点间的通信开销。
在更大的批量大小下，更高的Tensor并行度导致相对更显著的Token延迟减少。图4显示了MPT-7B的每个输出Token时间是如何变化的。在批量大小为1时，从2x增加到4x仅将Token延迟减少约12%。在批量大小为16时，4x的延迟比2x低33%。这与我们之前的观察一致，即在批量大小为16时，相对于批量大小为1，Tensor并行度更高时MBU的相对减少较小。
图5 显示了Llama2-70B的类似结果，不过4x到8x之间的相对改进不那么明显。我们还比较了两种不同硬件上的GPU扩展。因为H100-80GB的GPU内存带宽是A100-40GB的2.15倍，我们可以看到在批量大小为1时，4x系统的延迟降低了36%，在批量大小为16时降低了52%。
吞吐量
我们可以通过批处理请求来权衡吞吐量和每个Token的时间。在GPU评估期间对查询进行分组，与顺序处理查询相比，可以增加吞吐量，但每个查询的完成时间会更长（忽略排队效应）。
批处理推理请求有几种常见技术：
静态批处理Static batching：客户端将多个Prompt打包进请求中，并在批次中所有序列完成后返回响应。我们的推理服务支持这种方法，但并不要求这样做。
动态批处理Dynamic batching：Prompt在服务器内部即时批量处理。通常，这种方法的表现不如静态批处理，但如果响应短或长度一致，可以接近最优。当请求具有不同参数时，这种方法效果不佳。
连续批处理Continuous batching：这种将请求在到达时一起批量处理的想法在orca这篇出色的论文中被介绍，并且目前是最先进的方法。它不是等待批次中所有序列完成，而是在迭代级别将序列组合在一起。它可以实现比动态批处理高10倍到20倍的吞吐量。
图 6：使用 LLM 服务的不同类型的批处理。批处理是提高推理效率的有效方法。
连续批处理通常是共享服务的最佳选择，但在某些情况下，其他两种方法可能更好。在低QPS（每秒查询量）环境中，动态批处理可以胜过连续批处理。在更简单的批处理框架中实现低级GPU优化有时更容易。对于离线批量推理工作负载，静态批处理可以避免显著的开销并实现更好的吞吐量。
批量大小
批处理的效果高度依赖于请求流。但我们可以通过使用统一请求对静态批处理进行基准测试来获得其性能的上限。
延迟权衡Latency Trade-Off
请求延迟随批量大小增加而增加。例如，使用一块NVIDIA A100 GPU，如果我们将批量大小设置为64以最大化吞吐量，延迟将增加4倍，而吞吐量将增加14倍。共享推理服务通常选择一个平衡的批量大小。拥有自己模型的用户应该根据他们的应用决定适当的延迟/吞吐量权衡。在某些应用中，如聊天机器人，快速响应的低延迟是最优先的。在其他应用中，如批量处理非结构化PDF文件，我们可能愿意牺牲处理单个文档的延迟，以便并行快速处理所有文档。
图7 显示了7B模型的吞吐量与延迟曲线。这条曲线上的每一条线都是通过将批量大小从1增加到256获得的。这有助于确定我们可以将批量大小增加到多大，以满足不同的延迟限制。回想我们之前的屋顶图，我们发现这些测量结果与我们所期望的一致。在达到一定的批量大小后，即当我们进入计算受限制的情况时，每次批量大小加倍只会增加延迟，而不会增加吞吐量。
在使用并行处理时，了解底层硬件细节非常重要。例如，并非所有云平台上的8xA100实例都相同。一些服务器在所有GPU之间拥有高带宽连接，而其他服务器则将GPU成对连接，并且成对之间的带宽连接较低。这可能引入瓶颈，导致实际性能与上述曲线显著偏离。
优化案例研究：量化
量化是一种常用的技术，用于减少LLM推理的硬件需求。在推理过程中降低模型权重和激活的精度可以显著减少硬件需求。例如，从16位权重切换到8位权重可以在内存受限的环境中（例如，在A100上的Llama2-70B）将所需的GPU数量减半。降至4位权重则可以使在消费级硬件上运行推理成为可能（例如，在Macbook上的Llama2-70B）。
根据我们的经验，应谨慎实施量化。简单的量化技术可能导致模型质量大幅下降。量化的影响也因模型架构（例如，MPT与Llama）和大小的不同而异。
在试验量化等技术时，我们建议使用像Mosaic Eval Gauntlet这样的LLM质量基准来评估推理系统的质量，而不仅仅是孤立地评估模型的质量。此外，探索更深层次的系统优化也很重要。特别是，量化可以使KV缓存更加高效。
如前所述，在自回归Token生成中，注意力层的过去键/值（KV）被缓存，而不是在每一步都重新计算。KV缓存的大小基于一次处理的序列数量和这些序列的长度而变化。此外，在生成下一个令牌的每次迭代中，新的KV项被添加到现有缓存中，随着新token的生成，缓存变得更大。因此，在添加这些新值时有效管理KV缓存内存对于良好的推理性能至关重要。Llama2模型使用一种称为分组查询注意力（GQA）的注意力变体。请注意，当KV头的数量为1时，GQA与多查询注意力（MQA）相同。GQA通过共享键/值帮助减小KV缓存大小。计算KV缓存大小的公式是：batch_size * seqlen * (d_model/n_heads) * n_layers * 2 (K and V) * 2 (bytes per Float16) * n_kv_heads
表3 显示了在序列长度为1024 Token的不同批量大小下计算的GQA KV缓存大小。相比之下，Llama2模型的参数大小为70B模型的140 GB（Float16）。KV缓存的量化是另一种减小KV缓存大小的技术(除了GQA/MQA)，我们正在积极评估其对生成质量的影响。
如前所述，小批量llm令牌生成是GPU内存带宽限制问题，即生成速度取决于模型参数从GPU内存移动到片上缓存的速度。将模型权重从FP16(2字节)转换为INT8(1字节)或INT4(0.5字节)需要移动更少的数据，从而加快令牌生成。然而，量化可能会对模型生成质量产生负面影响。
结论和关键结果
我们上面概述的每个因素都影响了我们构建和部署模型的方式。我们使用这些结果来做出考虑硬件类型、软件栈、模型架构和典型使用模式的数据驱动决策。以下是我们经验中得出的一些建议。
确定你的优化目标：你关心交互性能吗？最大化吞吐量？最小化成本？这里有可预测的权衡。
关注延迟的组成部分：对于交互式应用程序，首个Token的响应时间决定了你的服务的响应性，而每个输出Token的时间决定了它的速度感。
内存带宽是关键：生成第一个Token通常是计算受限的，而随后的解码是内存受限操作。因为LLM推理通常在内存受限的设置中运行，MBU是一个有用的优化指标，可以用来比较推理系统的效率。
批处理至关重要：同时处理多个请求对于实现高吞吐量和有效利用昂贵的GPU至关重要。对于共享在线服务，连续批处理是不可或缺的，而离线批量推理工作负载可以通过更简单的批处理技术实现高吞吐量。
深入优化：标准的推理优化技术对于LLM很重要（例如，算子融合、权重量化），但探索更深层次的系统优化也很重要，特别是那些能改善内存利用率的优化。一个例子是KV缓存量化。
硬件配置：应根据模型类型和预期工作负载来决定部署硬件。例如，当扩展到多个GPU时，对于较小的模型如MPT-7B，MBU的下降速度比较大的模型如Llama2-70B要快得多。性能随着Tensor并行度的提高也往往呈次线性增长。尽管如此，如果流量高或用户愿意为额外低延迟支付溢价，对于较小的模型使用更高Tensor并行可能仍然有意义。
数据驱动的决策：理解理论很重要，但我们建议始终测量端到端服务性能。推理部署性能低于预期的原因有很多。MBU可能因为软件效率低下而意外地低。或者不同云提供商之间的硬件差异可能导致意外（我们观察到两个云提供商的8xA100服务器之间存在2倍的延迟差异）。
参考：LLM Inference Performance Engineering: Best Practices | Databricks Blog（https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices）
