可复现的语言大模型推理性能指标

原创
2023/11/17 08:51
阅读数 80

LLMPerf是一个开源项目,旨在帮助用户对语言模型进行基准测试,并使其性能具有可复现性。它能够帮助用户评估不同LLM的性能,并根据具体任务做出明智的决策。该项目选择了多个指标来衡量LLM的性能,包括吞吐量、时延、内存使用和成本等。本文介绍了如何使用LLMPerf进行基准测试,并提供了一些实用的技巧和建议。此外,本文还对当前最流行的LLM进行了基准测试,并提供了详细的结果和分析。

需要说明的是,LLMPerf测试可能仍需进一步完善。本文中他们对比了Fireworks给出的性能,不过Fireworks也发布博客进行了澄清,我们也将在后续文章中加以介绍。


 (本文由OneFlow编译发布,转载请联系授权。原文:https://www.anyscale.com/blog/reproducible-performance-metrics-for-llm-inference)


来源 | Anyscale

OneFlow编译

翻译|宛子琳、杨婷


重点内容摘要:


  • 我们见过许多关于LLM性能的声明,然而,这些声明通常难以复现。


  • 我们发布了LLMPerf(https://github.com/ray-project/llmperf),这是一个用于对LLM进行基准测试,以复现这些声明的开源项目。本文将讨论我们选择的指标以及如何对其进行衡量。


  • 有趣见解:100个输入词元与单个输出词元对时延的影响大致相当。若想提升速度,减少输出要比减少输入更有效。


  • 我们还展示了这些基准测试在部分当前LLM产品上的结果,并确定了这些LLM产品各自的优势。其中重点关注的是Llama 2-70B。


  • 对单个词元价格测算的结果总结:由于速率限制较低,Perplexity beta目前尚不适用于在生产环境中使用;Fireworks.ai和Anyscale Endpoints均可行,但在典型工作负载(550个输入词元,150个输出词元)的平均端到端时延上,Anyscale Endpoints便宜15%,快17%。Fireworks在高负载水平下的首词元时间(Time To First Token,TTFT)更短。

  • 特别是在LLM中,由于性能特征变化迅速,每种用例都有不同的要求,因此“因人而异(Your mileage may vary)”的规则更为适用。


最近,许多人宣称他们的LLM推理表现出色。然而,这些声明通常是不可复现的,而且细节也存在缺失,例如,某篇帖子仅声明称其结果针对“不同输入大小”,并附上了一张人们看不懂的图表。


我们考虑过发布自己的基准测试结果,但意识到仅仅发布结果只会延续不可复现的问题。因此,除发布结果之外,我们还拿出了自己内部的基准测试工具,并将其开源。


在接下来的部分,我们将讨论衡量LLM的关键指标,以及各个供应商在相应指标上的表现。


1

LLM的定量性能指标


LLM的关键指标是什么?我们建议将重点放在以下指标:


通用指标


以下指标适用于共享公共端点以及专用实例。


每分钟完成的请求数


在几乎所有情况下,你都希望系统能够处理并发请求。这可能是因为你正在处理来自多个用户的输入,或者可能有一个批量推理工作负载。


在许多情况下,除非你与共享公共端点的供应商达成了某些额外协议,否则他们会将你的速率限制得非常低。我们发现,一些供应商将速率限制在90秒内不超过3个请求。


首词元时间(TTFT)


在流式应用中,TTFT指的是LLM返回第一个词元前所需的时间。我们不仅对平均TTFT感兴趣,还包括其分布:P50、P90、P95和P99。


词元间时延(ITL)


词元间时延指的是连续输出词元之间的平均时间。我们决定将TTFT纳入词元间时延的计算。我们发现有些系统在端到端时间中很晚才开始流式传输。


端到端时延


端到端时延应该大致等于词元的平均输出长度乘以词元间时延。


单个典型请求的成本


API供应商通常可以通过牺牲其中一个指标来降低成本。例如,你可以通过在更多GPU上运行相同的模型或使用更高端的GPU来降低时延。


2

专用实例的额外指标


如果你正在使用专用计算运行LLM,例如Anyscale Private Endpoints,那么就会有一些额外标准。请注意,很难比较通用LLM实例和专有LLM实例的性能:它们的约束条件不同,利用率成为一个更为重要的实际问题。


配置


同一模型通常由于配置不同,导致在时延、成本和吞吐量之间出现不同权衡。例如,在p4de实例上运行的CodeLlama-34B模型可以配置为8个副本,每个副本有1个GPU,也可以配置为4个副本,每个副本有2个GPU,或者配置为2个副本,每个副本有4个GPU,甚至还可以配置为1个副本,拥有全部8个GPU。你还可以为流水并行或张量并行配置多个GPU。


每种配置都有不同特性:每个副本有一个GPU的情况可能拥有最低的TTFT(因为有8个“队列”等待输入),而一个副本有8个GPU的情况可能具备最大的吞吐量(因为有更多的批处理内存,且实际上有8倍的内存带宽)。


每种配置都会导致不同的基准测试结果。


输出词元吞吐量


还有一个重要的额外标准:总生成词元吞吐量,这便于比较成本。


最大利用率下的每百万词元成本


为比较不同配置的成本(例如,你可以在1个A10G GPU、2个A10G GPU或1个A100-40GB GPU上提供Llama 2-7B模型等),考虑给定输出的部署总成本十分重要。为进行比较,我们将使用AWS的1年预留实例定价(https://aws.amazon.com/cn/ec2/instance-types/p4/)。


3

考虑到但没有包含的测量标准


当然,我们可以将其他衡量标准添加到该列表。


预加载时间(未包含)


由于预加载时间只能通过对输入大小的首词元的回归来间接测算,因此我们在这一轮基准测试中没有加入这一指标。我们计划在未来的版本中添加预加载时间。


根据我们对大多数当前技术的经验,并没有发现预加载时间(获取输入词元,将它们加载到GPU并计算注意力值)对时延的影响比输出词元更显著。



上图显示了在不同的输入大小时,首词元时间(TTFT)的变化。所有这些样本都来自单次运行(5个并发请求)。这些数据点都将取均值,从而得到下面图表中的单个样本点。


可以看到,在250个词元输入和800个词元输入之间,输入词元与TTFT之间似乎并不存在明显的关系,且因其他原因导致的TTFT的随机噪声“掩盖(swamped)”了这一关系。

实际上,我们尝试过使用回归分析来估计这一关系,通过比较550个输入词元和3500个输入词元的输出,并估算梯度,我们发现每增加一个输入词元会增加0.3-0.7毫秒的端到端时间,相比之下,每增加一个输出词元会增加30-60毫秒的端到端时间(适用于Anyscale Endpoints上的Llama 2-70b模型)。因此,输入词元对端到端时延的影响约为输出词元的1%。我们将在未来继续对此进行测量。


总吞吐量(包括输入和生成的词元)


考虑到无法测量预加载时间,并且所花时间更多地取决于生成的词元数量,而不是输入的词元数量,因此,我们认为将注意力集中在输出上是正确的选择。


4

输入选择


运行该基准测试时,我们需要选择用于测试的输入和速率。


有人使用随机词元来生成固定大小的输入,然后在最大词元上使用强制停止(hard stop)来控制输出大小。我们认为这一做法不够理想,原因有以下两点:


  1. 随机词元并不代表真实数据。因此,某些依赖于真实数据分布的性能优化算法(如投机采样)在随机数据上的表现可能不如真实数据。

  2. 固定大小并不代表真实数据。这意味着某些算法的优势无法得到体现,比如分页注意力(paged attention)和连续批处理(continuous batching)等,因为它们很大一部分的创新点在于处理输入和输出的大小变化。


因此,我们希望使用“真实(real)”数据。显然,“真实”的定义因具体应用而异,但我们希望至少有一个平均水平的数据作为初始基准。


输入大小


为确定一个“典型”的输入和输出大小,我们查看了Anyscale Endpoints的终端用户数据。基于这一数据,我们选择了以下数值:


  • 平均输入长度:550个词元(标准差为150个词元)

  • 平均输出长度:150个词元(标准差为20个词元)


为简化问题,我们假设输入和输出都服从正态分布。在未来的工作中,我们将考虑Poisson分布等更具代表性的分布,因为这类分布在建模词元分布方面性质更佳,例如Poisson分布在负值时为0。


在计算词元数量时,我们始终使用Llama 2快速分词器,以一种独立于系统的方式估计词元数量。在过去的研究中,我们注意到ChatGPT的分词器比Llama 2的分词器更“高效”(Llama 2是每词1.5个词元,而ChatGPT是每词1.33个词元)。因此我们认为,ChatGPT不应因为这一点而受到惩罚。


输入内容


为使基准测试更具代表性,我们决定让LLM执行两项任务。


第一项任务是将数字的单词表示转换为数字表示。这实际上是一个“校验和”任务,用于确保LLM的正常运行:我们有很高的概率期望返回的值与我们发送的值相同(根据经验,良好运行的LLM很少出现概率低于97%的情况)。


第二项任务是为了增加输入和输出的灵活性。我们在输入中包含了莎士比亚十四行诗的若干行,并要求LLM在输出中选择若干行。这使我们得到了一个真实的词元和大小分布。我们还可以利用这一任务来“理智地检验”LLM——我们期望输出行在一定程度上类似于我们提供的输入行。


并发请求


一个关键特征是同时发出的请求数量。显然,更多的并发请求会使固定资源集的输出速度变慢。在测试中,我们已经将5作为关键数字进行了标准化。


5

LLMPerf


LLMPerf实现了上述标准。它还进行了参数化(LLMPerf允许改变输入和输出大小以匹配应用程序,这样就可以为自己的工作运行服务供应商的基准测试)。

单个词元的LLM产品基准测试结果


如上所述,我们很难比较按词元计费的LLM产品和按分钟计费的产品,因为后者以时间单位支付产品费用。在这些实验中,我们关注的是已知的按词元计费的产品。因此,我们选择了Anyscale上的llama-2-70b-chat,Fireworks和Perplexity。对于Fireworks,我们使用了Developer PRO账户(将速率限制提高到每分钟100个请求)。


每分钟完成的请求数


我们利用这一方法,通过改变并发请求数,来测算每分钟可以完成的请求,并观察整体时间变化。然后,我们将完成的请求数量除以完成所有请求所需的时间(以分钟为单位)。


需要注意的是,这种方法可能稍显保守,因为我们以“轮次”而不是连续查询的方式完成了并发请求。举例来说,如果我们同时发起了5个请求,其中4个在5秒内完成,另一个在6秒内完成,那么就会有1秒钟的时间并没有完全达到5个并发请求。


结果如图所示。


在处理过程中我们遇到了一个问题:即Perplexity的速率限制非常低。因此,我们只能在每轮之间暂停15秒来完成一个“一一对应”的比较。如果暂停时间少于这个值,就会开始从Perplexity那里出现异常。我们将这标记为每秒0.5个并发请求。我们一直运行实验,直到出现异常。


我们可以看到,Fireworks和Anyscale都可以扩展到每分钟完成数百个查询。Anyscale的扩展能力略高一些(最高达到每分钟227个查询,Fireworks最高为每分钟184个查询)。


首词元时间


我们比较了每个产品的TTFT。TTFT对于流媒体应用程序(如聊天机器人)尤为重要。



我们再次受到了Perplexity测试速度的限制。最初,在低负载情况下,Anyscale比Fireworks快,但随着并发请求的数量增加,Fireworks似乎略胜一筹。在进行5个并发查询时(这是我们关注的重点),时延差距通常在100毫秒以内(Fireworks为563毫秒,Anyscale为630毫秒)。需要注意的是,TTFT因网络条件存在很大差异(例如,服务部署在附近或远程地区)。


词元间时延


从上图可以看出,尽管两者的差异相对较小(约5%到20%),但Anyscale上的词元间时延始终优于Fireworks。


端到端时间


下图显示了完成查询所需的端到端时间。我们可以看到,就噪声而言,端到端请求时间是更敏感的衡量标准之一。



可以看到,Anyscale的端到端时间始终优于Fireworks,但随着负载水平增加,两者之间的差距变小(尤其是比例上的差距)。在运行5个并发查询时,Anyscale为4.6秒,而Fireworks为5.3秒(快15%),但运行30个并发查询时,两者的差距变小了(Anyscale快5%)。


每千次请求的成本



Perplexity目前处于公开测试阶段,因此没有价格可供比较。对于Fireworks,我们使用了其网站上列出的价格,即每百万输入词元收费0.7美元,每百万输出词元收费2.80美元。对于Anyscale Endpoints,根据其定价页所示,无论是输入还是输出,都是每百万个词元1美元。


6

结果分析


利用上述数据,我们可以计算出何时使用何种LLM产品:


  • 对于低流量的交互式应用(比如聊天机器人),这三种方案都可行。ITL和TTFT都足够小,不会成为主要问题,因为人类每秒大约阅读5个词元,即便方案中最慢的速度也是人类的6倍之多,所以它们之间没有显著的差异。然而,在这种工作负载下,Anyscale是这三种方案中最便宜的,大约便宜15%。

  • 如果你需要端到端的超低时延应用,且工作负载不是很大,那么一旦Perplexity推出公测版本,就值得考虑。然而,在Perplexity公布价格之前,很难知道这种低时延的“成本”是多少。

  • 如果有大量工作负载,则可以考虑Anyscale和Fireworks。然而,对于特定的工作负载,Anyscale比其他服务便宜大约15%。同时,如果你的输入和输出比例很高,例如10个输入词元对应1个输出词元,那么Fireworks会更便宜(Fireworks为89美分,Anyscale为1美元),极端的文本摘要就属于这种情况。


7

总结


LLM的性能正飞速优化。我们希望LLMPerf这一基准测试工具能够帮助社区比较输出结果。我们将继续努力,改进LLMPerf(特别是使其更易于控制输入和输出的分布),以期提升透明度和可复现性。同时,我们也希望用户能够利用LLMPerf来对特定工作负载的成本和性能建模。


从这一点可以看出,LLMPerf基准测试并不适用于所有情况,尤其是在涉及LLM时,结果的适用性取决于特定的应用。


其他人都在看

试用OneFlow: github.com/Oneflow-Inc/oneflow/

本文分享自微信公众号 - OneFlow(OneFlowTechnology)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部