LLM 性能基准

你可能已经见过 LLM 排行榜。那些排版整齐的排名表会根据各种基准展示顶级 LLM。它们可以作为理解模型能力的有用参考。但如果你把它们当作选择最佳 LLM 的唯一依据，也可能会被误导。

对 LLM 做基准测试是一项复杂任务。某个公开基准上的高分，并不能保证该模型在你的工作负载上也会表现良好。你的生产环境几乎不可能与别人做 LLM 排名时所使用的环境完全一致。当你想为某个特定场景做优化时，这一点尤其明显，例如在将端到端延迟控制在 300 ms 以内的同时，实现 120 tokens/second 的输出吞吐量。

为了获得最适合你用例的配置，你需要为 LLM 推理运行自定义性能基准测试。这意味着要精心设计测试，并且通常需要在吞吐量、延迟和成本之间做权衡。

什么是 LLM 基准

当人们谈论 LLM 基准时，通常指的是两类不同的东西：

• 质量基准。衡量模型回答问题、推理或遵循指令的能力。示例包括 MMLU、GSM8K、HumanEval 和 TruthfulQA。质量基准通常驱动你在网上看到的 LLM 排行榜，用来对最佳 LLM 进行排序。
• 性能基准。衡量模型在真实环境中运行的速度和效率。它们关注吞吐量（每秒 token 数）、延迟（Time to First Token、中位数、P99）、成本效率和 GPU 利用率等 LLM 性能指标。

这两类基准都很重要，但它们服务的目的完全不同。一个在质量排行榜上排名很高的模型，如果延迟过高或成本无法持续，仍然可能在生产中表现不佳。反过来，一个推理性能很优秀但基准准确率稍弱的模型，在速度比其他因素更重要的应用中，仍然可能是正确选择。

在这本手册中，我们更关注 LLM 推理的性能基准。

你应该在什么时候运行性能基准

以下是适合进行自定义基准测试的场景：

• 比较不同模型。当你要在两个顶级 LLM 之间做选择时，基准可以揭示它们在你的工作负载下在吞吐量、延迟和成本方面的差异。
• 评估推理框架。像 vLLM、SGLang、TensorRT-LLM 和 Hugging Face TGI 这样的框架提供了不同的推理优化。基准可以帮助你看清哪一个最适合你的环境，并给出最佳权衡。
• 测试基础设施变更。从 A10G 切换到 H100 GPU，或者从本地部署切换到云上，都会影响性能。基准测试能验证这种影响。
• 衡量优化收益。诸如推测解码、前缀缓存、分离式服务或 KV 缓存卸载 之类的推理技术，都应该通过可重复的性能测试来验证。
• 为生产流量扩容。在正式上线之前，基于真实请求速率和并发水平的基准测试，能够显示你的系统在压力下的表现。

简而言之，只要你需要基于证据来判断哪种推理配置能满足你的要求，就应该运行 LLM 性能基准。

什么时候基准帮不上忙

以下这些情况下，基准不会给你带来有价值的洞见：

• 与你的工作负载不匹配。有些结果来自非常狭窄的测试集。如果你的应用有更长的提示、更高的并发，或者更严格的延迟预算，那么这些数字可能无法迁移。
• 数据集无关。有些基准测代码能力，有些测数学能力，还有些测推理能力。如果你在构建一个客服聊天机器人，那么 GSM8K 或 HumanEval 的高分可能完全无关紧要。
• 基础设施配置不同。你的生产硬件、框架或缓存策略永远不会与已发布的 LLM 排名所使用的精确环境一致。
• 只盯着单一指标。只看每秒 token 数或延迟，会忽略其中的权衡。
• 忽视成本和扩展约束。即使某个模型纸面上看起来很快，把它大规模运行起来也可能成本过高，或者运维复杂度太高。

请记住，把基准当作参考，而不是最终决策者。

选择合适的基准工具

测试和衡量 LLM 性能的方法有很多，但并非所有工具都服务于同一个目的。

通用负载测试工具

Locust 和 K6 是历史较久且被广泛使用的工具，用于模拟真实世界流量。它们侧重于负载测试：生成大量并发请求，以观察你的 LLM 部署如何运行和扩展。它们有助于识别服务器容量、自动扩缩容策略、网络延迟和资源利用率方面的瓶颈。

专用的 LLM 基准工具

像 NVIDIA GenAI-Perf 和 LLMPerf 这样的工具，是专门为 LLM 性能基准而构建的。这些工具聚焦于吞吐量和延迟等推理层指标。它们可以提供模型性能的细粒度洞见，但不同工具对指标的定义或计算方式可能不同。

框架专用基准脚本

一些推理框架（如 vLLM 和 SGLang）提供了自己的基准脚本、命令和使用指南。对于快速实验，以及理解该特定框架所带来的优化效果，它们很有帮助。不过，你必须特别注意它们的默认参数和配置。结果看起来可能很好，但未必反映你的生产环境。

使用 MAX 进行端到端基准测试

MAX 包含 benchmark_serving.py，这是一个用于衡量 LLM 服务端点端到端性能的脚本，涵盖吞吐量、延迟和资源利用率。它基于 vLLM 的测量方法，因此结果在不同后端之间仍然具有可比性。

借助它，你可以：

• 对任何兼容 OpenAI 的 HTTP 端点进行基准测试，包括托管服务。
• 同时测试 chat 和 completion API。
• 在不同请求模式下测量细致的延迟指标。
• 在一致的方法论下比较不同服务后端，例如 vLLM 和 MAX。

你应该基准哪些指标

在为 LLM 推理运行性能基准时，仅报告一个数字是不够的。真实世界的性能取决于多个 LLM 性能指标，而且它们之间存在不同的权衡。最重要的包括：

• 吞吐量：模型每秒可以处理或生成多少 token 或请求。这衡量的是可扩展性和原始效率。

• 延迟：模型响应请求的速度。关键延迟指标包括 TTFT、ITL、中位延迟和尾延迟（P95、P99）。这些指标决定了你的 LLM 对用户而言有多“灵敏”。

  更多信息请参见 LLM 推理指标。

• 成本：通常以每千 token 成本、每请求成本或每单位时间成本来衡量。对于自托管推理来说，GPU 往往是成本的最大驱动因素。许多顶级 LLM 需要大型且昂贵的 GPU 才能高效运行。

• 资源利用率：GPU/CPU 利用率、内存分配和缓存命中率。高利用率通常意味着更好的硬件效率。这在生产环境中特别重要，因为它直接决定你每花一美元能获得多少性能。

你最终得到的结果，在很大程度上取决于基准是如何运行的。需要控制的关键参数包括：

• 服务器参数：并行方式（例如数据、张量和专家）、缓存策略、内存分配
• 客户端参数：请求速率、并发限制、批大小、超时
• 框架差异：vLLM、SGLang、TensorRT-LLM、TGI 等框架中的优化
• 工作负载变化：模型选择、输入序列长度、输出长度、请求分布

在某些情况下，即便这些变量只有很小差异，也可能显著改变结果。

如何创建好的 LLM 性能基准

运行 LLM 性能基准比看起来更难。像“200 tokens/second”这样的数字听起来很简单，但如果脱离上下文，它几乎没有意义。真正的 LLM 基准测试需要捕捉测试环境、工作负载和约束条件，才能让结果具有可复现性和相关性。

下面是一个带有虚拟数据的基准模板示例：

类别	参数	值
模型	名称	meta-llama/Llama-3.1-8B-Instruct
	框架	vLLM 0.4.2
	量化	FP16
硬件	GPU	4 x NVIDIA A10G
	GPU 内存	24 GB
服务器配置	张量并行	1
	数据并行	4
	最大批大小	16
客户端配置	请求速率	50 req/s
	并发	16
	输入长度	256 tokens
	输出长度	512 tokens
结果	吞吐量	98 tokens/sec
	中位 TTFT	210 ms
	P99 延迟	1.4 s
	GPU 利用率	89%
	每 1M token 成本	$0.52

使用此模板的建议：

• 始终记录框架版本和硬件类型。这些方面的细微差异都可能显著改变结果。
• 包含输入/输出长度。它们会强烈影响吞吐量和延迟。
• 感知 tokens/sec 可能比原始模型输出速率更适合衡量流式性能（也就是用户真正看到的性能）。
• 保持成本指标的一致性，例如统一按每请求或每百万/千 token 来衡量。