LLMPerf 基准测试排行榜简介
LLMPerf 基准测试排行榜是一个公开透明的评测平台,旨在对市场上主流的大语言模型(LLM)推理服务提供商进行全面评估。该排行榜由 Ray 项目团队开发和维护,利用开源的 LLMPerf 工具进行测试,为用户和开发者提供了宝贵的参考信息。
评测目标与意义
随着大语言模型在各行各业的广泛应用,选择合适的 LLM 推理服务变得越来越重要。LLMPerf 排行榜的主要目标是:
- 对各大 LLM 推理服务提供商的性能、可靠性和效率进行客观评估
- 为用户和开发者提供清晰透明的比较结果
- 帮助使用者做出更明智的选择和决策
通过这一排行榜,我们可以深入了解每个服务提供商的优势和局限,从而为未来的集成和部署提供重要参考。
关键评测指标
LLMPerf 排行榜主要关注两个核心指标:
-
输出令牌吞吐量(tokens/s): 衡量每秒钟返回的平均输出令牌数。这一指标对需要高吞吐量的应用(如文本摘要和翻译)尤为重要,也便于在不同模型和提供商之间进行横向比较。
-
首个令牌生成时间(TTFT): 从提交提示到 LLM 返回第一个令牌所需的时间。这一指标对流式应用(如聊天机器人)至关重要。
除此之外,排行榜还提供了其他辅助指标,如成功率、不同百分位数下的性能表现等,以全方位评估服务质量。
评测方法与配置
测试环境
- 客户端: AWS EC2 (实例类型: i4i.large)
- 地理位置: 美国西部(俄勒冈)地区
- 测试时间: 2023年12月19日 3:00 AM PST
测试参数
对于每个服务提供商,LLMPerf 采用以下统一配置进行测试:
- 总请求数: 150
- 并发请求数: 5
- 输入提示长度: 550 个令牌
- 预期输出长度: 150 个令牌
- 测试模型: Llama-2 chat 系列的 7B、13B 和 70B 版本
测试命令
python token_benchmark_ray.py \
--model <MODEL_NAME> \
--mean-input-tokens 550 \
--stddev-input-tokens 0 \
--mean-output-tokens 150 \
--stddev-output-tokens 0 \
--max-num-completed-requests 150 \
--num-concurrent-requests 5 \
--llm-api <litellm/openai>
评测结果与分析
70B 模型性能对比
在 70B 模型的评测中,各服务提供商表现差异显著:
- Groq 以平均 184 tokens/s 的惊人吞吐量遥遥领先,展现出强大的处理能力。
- Anyscale 和 Together.ai 分别以 63 tokens/s 和 64 tokens/s 的表现紧随其后。
- Fireworks、Lepton 和 Perplexity 处于中游水平,吞吐量在 30-40 tokens/s 之间。
- Bedrock 和 Replicate 的表现相对较弱,吞吐量不足 25 tokens/s。
这些结果反映了不同服务提供商在处理大规模语言模型时的能力差异,可能与其底层硬件、优化策略等因素有关。
13B 模型性能对比
在 13B 模型的评测中:
- Anyscale 以平均 120 tokens/s 的吞吐量领跑,展现出优秀的性能优化。
- Together.ai 紧随其后,达到 101 tokens/s 的平均吞吐量。
- 其他提供商如 Fireworks、Lepton 和 Bedrock 的表现相对接近,吞吐量在 35-45 tokens/s 之间。
- Replicate 的表现相对较弱,平均吞吐量为 18 tokens/s。
这些结果显示,即使是相同规模的模型,不同服务提供商的性能也可能存在显著差异。
7B 模型性能对比
对于 7B 模型:
- Fireworks 和 Together.ai 表现最佳,平均吞吐量均达到 75-76 tokens/s。
- Anyscale 紧随其后,达到 51 tokens/s 的平均吞吐量。
- Lepton 和 Replicate 的表现相对较弱,平均吞吐量在 30-36 tokens/s 之间。
这些结果表明,即使是较小规模的模型,不同服务提供商之间仍存在明显的性能差异。
首个令牌生成时间(TTFT)分析
除了吞吐量,TTFT 也是评估 LLM 服务质量的重要指标。以 70B 模型为例:
- Anyscale 和 Groq 表现最佳,中位数 TTFT 仅为 0.21-0.22 秒。
- Perplexity 和 Bedrock 紧随其后,中位数 TTFT 在 0.37-0.39 秒之间。
- Replicate 的 TTFT 表现最差,中位数高达 1.19 秒,且波动较大。
这些结果对于需要快速响应的应用场景(如对话系统)尤其重要。较低的 TTFT 意味着用户可以更快地获得初始响应,从而提升整体体验。
评测结果的解读与应用
结果解读注意事项
尽管 LLMPerf 排行榜提供了宝贵的性能洞察,但在解读和应用这些结果时,我们仍需注意以下几点:
-
硬件差异: 各服务提供商的后端基础设施可能存在较大差异,因此这些结果并不一定反映软件在特定硬件上的运行情况。
-
时间波动: 测试结果可能会随时间而变化,受到服务负载、网络状况等因素的影响。
-
地理位置影响: 测试结果(尤其是 TTFT)与客户端位置密切相关。目前的测试位置位于美国西部,其他地区的用户可能会有不同的体验。
-
工作负载相关性: 这些基准测试结果可能与特定用户的实际工作负载不完全相符。
-
服务能力的近似: 测试结果仅是系统能力的一种近似反映,还受到当前系统负载和服务商流量的影响。
应用建议
基于 LLMPerf 排行榜的结果,我们为不同需求的用户提供以下建议:
-
高吞吐量需求: 如果您的应用需要处理大量文本生成任务(如批量摘要或翻译),可以优先考虑在吞吐量测试中表现出色的服务提供商,如 Groq(70B)、Anyscale(13B) 或 Fireworks(7B)。
-
低延迟需求: 对于需要快速响应的应用(如实时对话系统),应关注 TTFT 表现优异的服务提供商,如 Anyscale 和 Groq。
-
成本效益考量: 考虑到较小模型(如 7B 和 13B)在某些任务上可能已经足够,而且通常具有更低的成本和更高的吞吐量,可以根据具体需求权衡选择合适规模的模型。
-
稳定性要求: 对于需要高度稳定服务的应用,建议关注各项指标的波动范围,选择性能表现稳定的服务提供商。
-
综合评估: 在做出最终选择时,建议结合吞吐量、TTFT、成功率等多个指标进行综合评估,并考虑您的具体应用场景和预算限制。
-
实际测试验证: 由于实际性能可能受多种因素影响,建议在最终决策前,使用与您的实际工作负载相似的测试用例进行小规模实测。
未来展望与社区参与
LLMPerf 排行榜作为一个开源项目,其发展离不开社区的支持和参与。我们欢迎各方面的反馈和贡献:
-
反馈渠道: 如果您有任何意见或建议,请通过 GitHub Issues 与我们分享。
-
服务提供商参与: 对于有兴趣将自己的 API 加入排行榜的 LLM 推理服务提供商,我们欢迎您提交 issue 或通过邮件 endpoints-help@anyscale.com 与我们联系。
-
持续更新: 我们计划定期更新排行榜,以反映最新的性能数据和新增的服务提供商。
-
方法论改进: 我们将继续优化测试方法和指标,以提供更全面、更有价值的评估结果。
-
扩展模型覆盖: 未来我们可能会扩大测试范围,覆盖更多的模型类型和规模。
通过 LLMPerf 排行榜,我们希望能为 LLM 生态系统的发展做出贡献,推动性能标准的制定和技术的进步。我们相信,随着更多参与者的加入和技术的不断演进,LLM 推理服务的质量将不断提升,最终惠及所有用户和开发者。