大模型国产化适配9-LLM推理框架MindIE-Service性能基准测试

大模型国产化适配9-LLM推理框架MindIE-Service性能基准测试

原创 吃果冻不吐果冻皮  2024年06月21日 12:38 四川

随着 ChatGPT 的现象级走红，引领了AI大模型时代的变革，从而导致 AI 算力日益紧缺。与此同时，中美贸易战以及美国对华进行AI芯片相关的制裁导致 AI 算力的国产化适配势在必行。之前也分享过一些国产 AI 芯片、使用国产 AI 框架 Mindformers 基于昇腾910训练大模型，使用 MindIE 进行大模型服务化。

大模型国产化适配7-华为昇腾LLM落地可选解决方案（MindFormers、ModelLink、MindIE）

发布，华为昇腾终于推出了针对LLM的完整部署方案，结束小米加步枪时代

大模型国产化适配8-基于昇腾MindIE推理工具部署Qwen-72B实战（推理引擎、推理服务化）

另外，我撰写的大模型相关的博客及配套代码均整理放置在Github：llm-action，有需要的朋友自取。

在 基于昇腾MindIE推理工具部署Qwen-72B实战（推理引擎、推理服务化） 中对MindIE-Service推理工具进行了实战演示，本文测试 MindIE-Service 推理框架的性能。

声明：本文LLM推理性能测试数据仅供参考，具体性能实测为准。

LLM推理过程

对于目前基于 Decoder-only Transformer 架构的文本生成大模型而言，其推理过程分为两个阶段：

预填充（prefill）阶段，这一阶段会以并行方式处理输入提示中的词元(Token)；

解码（decoding）阶段，这一阶段文本会以自回归的方式逐个生成“词元”。每个生成的词元都会被添加到输入中，并被重新喂入模型，以生成下一个词元。当LLM输出了特殊的停止词元或满足用户定义的条件（例如：生成了最大数量的词元）时，生成过程就会停止。

词元可以是单词或子词，将文本拆分为词元的确切规则因模型而异。例如，我们可以对比LLaMA模型和OpenAI模型对文本进行分词处理的方式。尽管LLM推理服务供应商经常以基于词元的指标（例如：每秒处理的词元数）来谈论性能，但由于模型分词规则的差异，这些数字在不同模型类型之间并不总是可比较的。例如，Anyscale 团队发现，与 ChatGPT 的分词长度相比，LLaMA 2的分词长度增加了19%（但整体成本要低得多）。HuggingFace 的研究人员也发现，与 GPT-4 相比，对于相同长度的文本，LLaMA 2训练所需的词元要多20%左右。

LLM推理服务的目标

通常情况下，LLM推理服务目标是首Token输出尽可能快、吞吐量尽可能高以及每个输出Token的时间尽可能短。换句话说，我们希望我们的模型服务能够尽可能快地支持我们尽可能多地为用户生成文本。

常见LLM推理服务性能评估指标

那么对于大模型推理服务而言，应该如何准确衡量模型的推理速度呢？下面是一些常见的评估指标：

首Token生成时间（Time To First Token，简称TTFT）：即用户输入提示后，模型生成第一个输出词元（Token）所需的时间。在实时交互中，低时延获取响应非常重要，但在离线工作任务中则不太重要。此指标受处理提示信息并生成首个输出词元所需的时间所驱动。通常，不仅对平均TTFT感兴趣，还包括其分布，如P50、P90、P95和P99等。

单个输出Token的生成时间（Time Per Output Token，简称TPOT）：即为每个用户的查询生成一个输出词元所需的时间。这一指标与每个用户对模型“速度”的感知相关。例如，TPOT为100毫秒/词元表示每个用户每秒可处理10个词元，或者每分钟处理约450个词元，那么这一速度远超普通人的阅读速度。

端到端时延：模型为用户生成完整响应所需的总时间。整体响应时延可使用前两个指标计算得出：时延 = （TTFT）+ （TPOT）*（待生成的词元数）。

每分钟完成的请求数：通常情况下，我们都希望系统能够处理并发请求。可能是因为你正在处理来自多个用户的输入或者可能有一个批量推理任务。

单个请求的成本：API 提供商通常会权衡其他指标（如：时延）以换取成本。例如，可以通过在更多GPU上运行相同的模型或使用更高端的GPU来降低时延。

最大利用率下每百万Token的成本：比较不同配置的成本（例如，可以在1个A800-80G GPU、1个H800-80G GPU或1个A100-40GB GPU上提供Llama 2-7B模型等），估算给定输出的部署总成本也十分重要。

预加载时间：预加载时间只能通过对输入提示的首次oken的生成来间接估算。一些研究发现在250个输入词元和800个输入词元之间，输入词元与TTFT之间似乎并不存在明显的关系，且由于其他原因，它被TTFT中的随机噪声掩盖。通常情况下，输入词元对端到端时延的影响约为输出词元的1%。

生成Token吞吐量：推理服务在所有用户请求中每秒可生成的输出词元(Token)数。考虑到无法测量预加载时间，并且总推理时延所花时间更多地取决于生成的Token数量，而不是输入的Token数量，因此，将注意力集中在输出Token上通常是正确的抉择。

总吞吐量：包括输入的Token和生成的Token。

image.png

注意：

吞吐量和每个输出Token时延之间存在权衡，同时处理 16 个用户请求，与顺序运行请求相比，将具有更高的吞吐量，但将花费更长的时间为每个用户生成输出Token。

对于一些场景，需要考虑端到端推理延迟作为目标，需要注意如下几点：

输出Token长度决定总体响应延迟：对于总体平均时延，您通常只需将预期最大输出token长度乘以模型每个输出token的总体平均时延即可。

输入长度对端到端推理性能并不重要，但对硬件要求很重要：一些研究表明在 MPT 模型中， 512 个输入token增加的延迟小于生成 8 个额外输出Token的延迟。但支持长输入的需求可能会使模型更难以服务。通常建议使用 A100-80GB（或更新版本）来服务 MPT-7B，其最大上下文长度为 2048 个Token。我在 MindIE Service 上，使用羊驼中文数据集，针对百川和千问大模型做了一个简单测试，发现100Token以内，随着输入Token长度的增加，并没有显著增加首Token的时延，如下图所示。

端到端推理延迟与模型大小呈次线性关系：在相同的硬件上，较大的模型推理速度较慢，但推理速度比不一定与模型参数量比匹配。例如：MPT-30B 延迟约为 MPT-7B 延迟的 2.5 倍。Llama2-70B 延迟约为 Llama2-13B 延迟的 2 倍。

image.png

LLM推理优化技术

通常情况下，在上线到生产环境前，需要进行 LLM 推理优化。

常见的 LLM 推理优化技术如下：

算子融合：将不同的相邻算子组合在一起通常会带来更低的延迟。

模型量化：将激活和权重进行压缩以使用更少的比特数。

模型并行化：跨多个设备进行张量并行或对于较大的模型进行流水线并行。

KV 缓存，即保存注意力层的中间key、value值，以供以后重用，避免重复计算。

Continuous batching: 通过服务调度优化提高总吞吐量。

PagedAttention：对Attention的key、value进行高效的内存管理。

本文的测试用到了模型并行推理、KV 缓存、Continuous Batching等。

吃果冻不吐果冻皮

专注于AI工程化（LLM、MLOps、LLMOps、RAG、Agent）落地。

150篇原创内容

公众号

LLM基准测试说明

LLM基准测试输入的选择

有的人喜欢使用随机Token来生成固定大小的输入，然后在最大生成Token上使用强 制停止来控制输出Token大小。但这一做法不够理想，原因有以下两点：

随机Token并不代表真实数据。因此，某些依赖于真实数据分布的性能优化算法（如：投机采样）在随机数据上的表现可能不如真实数据。

固定大小并不代表真实数据。这意味着某些算法的优势无法得到体现，比如：PagedAttention和Continuous Batching等，因为它们很大一部分的创新点在于处理输入和输出的大小变化。

因此，最好使用“真实”数据。但“真实”的定义因具体应用而异，本文使用羊驼中文数据集进行基准测试。

LLM基准测试并发请求的选择

对于一个典型的LLM推理服务，通常，需要接收多个用户的请求。但更多的并发请求会使固定资源集的输出速度变慢。在本文的测试中，测量延迟时，只使用一个用户，保证最佳的推理时延。而测试吞吐量时，由于希望测试一个LLM服务能够处理最大的Token，我们将峰值用户设置为100。

LLM张量并行的选择

随着输入提示变长，生成第一个token的时间占用总延迟的的比例开始变大。跨多个 GPU 的张量并行有助于减少这种延迟。与模型训练不同，将模型推理扩展到更多的 GPU 会显著降低推理延迟的回报。例如，对于 Llama2-70B，在批量大小较小的情况下，从 4x GPU 增加到 8x GPU 仅将延迟降低了 0.7 倍。一个原因是模型并行度越高，MBU 越低。另一个原因是张量并行引入了跨 GPU 节点的通信开销。

而在批量大小较大的情况下，较高的张量并行度会将token延迟相对显著地减少。之前有关于 MPT-7B 每个输出token的时间变化情况的研究。在批量大小为 1 时，从 2x GPU到 4x GPU 仅将token延迟减少约 12%。在批量大小为 16 时，4x 的延迟比 2x 的延迟低 33%。

本文针对不同模型参数规格，选择了不同的模型并行度进行测试。

KV Cache 的配置

KV Cache是仅编码器Transformer架构的模型必备显存优化技术（通过显存换显存）。原理很简单，但是对于LLM推理优化效果很显著。

MindIE-Service中使用npuMemSize和cpuMemSize控制KV Cache的大小。

npuMemSize：NPU中可以用来申请kv cache的size上限。单位：GB。建议值：8。快速计算公式：npuMemSize=(总空闲-权重/NPU卡数-后处理占用)*系数，其中系数取0.8。假设权重保存为FP16，Atlas 800I A2 推理服务器(910B4)单卡为32G，使用8卡进行张量并行，片上系统大约有2-3G。因此，Qwen-72B的npuMemSize大约为：（32G-3G-(722)/8--后处理占用） 0.8 约等于 10G 。该公式只是大概估算，以实际情况为准。如果发现OOM，则适当降低kv cache的上限。

cpuMemSize：CPU中可以用来申请kv cache的size上限。单位：GB。建议值：5。

LLM延迟基准测试

下面使用MindIE Service框架对不同模型的推理时延进行测试。

数据集：羊驼中文数据集 1k

服务器配置：910B4（280T）x 8

框架：MindIE Service

指标：端到端时延、首Token时延、Token间时延

下图为不同模型不同张量并行下的推理时延汇总：

image.png

目前来看，从推理时延上来说，对于6、7B模型，2tp推理首token时延最低，4tp推理token间时延最低，但提升并不明显。对于13、14B模型，推理使用4TP推理能达到最低的推理时延。对于72B模型，目前需使用8TP进行推理是一个比较好的选择。

LLM吞吐量测试报表

下面使用MindIE Service框架对不同模型的推理吞吐量和端到端时延进行测试。

压测工具：Locust

数据集：羊驼中文数据集 0.5k（随机抽取）

服务器配置：910B4（280T）x 8

框架：MindIE Service

指标：吞吐量（每秒处理的Token数）、端到端时延

压测时长：10m

下图为使用Locust压测qwen1.5-7b模型（4tp模型并行推理）性能报表：

qwen1.5-7b-4tp-stat.png

qwen1.5-7b-4tp-chart.png

下图是针对对不同模型、不同张量并行度、不同峰值用户推理吞吐量和端到端时延汇总：

image.png

上面也提到了吞吐量和每个输出Token时延之间存在权衡。在某些应用中，如聊天机器人，低延迟地响应用户是最优先的。在其他应用中，如批量处理非结构化PDF文件，我们可能愿意牺牲处理单个文档的延迟，以便并行快速处理所有文档。因此，应根据实际业务需求，考虑模型部署服务器配置、模型并行度、模型服务实例数。

结语

本文简要介绍了LLM推理过程、LLM推理服务的目标、常见的LLM服务评估指标以及LLM推理优化技术。同时，使用MindIE-Service对不同的大模型的推理延迟和吞吐量进行了测试。

参考文档：

Reproducible Performance Metrics for LLM inference / 可复现的语言大模型推理性能指标

吃果冻不吐果冻皮

专注于AI工程化（LLM、MLOps、LLMOps、RAG、Agent）落地。

150篇原创内容

公众号