大模型推理性能究竟该如何科学评估？吞吐量、延迟等核心指标怎样正确使用，才能切实指导LLM应用部署的优化？本文将深入剖析关键要点，帮助您彻底理解这些概念。

核心内容概览：

• 负载测试与性能基准测试的区别及适用场景
• LLM推理工作原理与关键术语详解
• 行业通用性能指标的定义与测量差异

引言

随着生成式AI与大型语言模型（LLM）的广泛应用，越来越多的企业开始部署基于LLM的应用。此时，如何准确评估不同AI服务背后的效率，成为一项刚性需求。简而言之，LLM应用部署的成本，取决于其每秒能处理的请求数量，同时必须满足终端用户对响应速度的要求，并保证回答的准确性。这三点缺一不可。

本文将系统梳理LLM应用成本评估的核心指标——吞吐量与响应延迟，旨在澄清容易混淆的术语，解析主流测试工具对这些指标的定义与测量差异，并探讨基准测试中的关键参数。以下是本文的目录安排。

1. 负载测试与性能基准测试

负载测试与性能基准测试是评估LLM部署的两种不同策略。负载测试通过模拟高并发请求，检验模型在高流量下的承受能力，重点关注服务器容量、自动扩展策略、网络延迟及资源利用率等方面。

性能基准测试则更侧重于模型本身的性能表现，例如吞吐量、延迟及词元级别的指标，旨在发现模型效率、优化及配置方面的问题。

总结而言：负载测试确保模型能够应对高流量，而性能基准测试关注的是请求处理效率。将两者结合，才能全面评估LLM部署的能力，并找到改进方向。

2. LLM推理基本原理

在探讨基准测试指标之前，有必要先回顾LLM推理的工作原理及相关术语。在实际生产环境中，LLM推理生成通常经历以下几个阶段：

• 提示（Prompt）：用户提交查询
• 排队（Queuing）：查询进入处理队列
• 预填充（Prefill）：模型处理提示（prompt）
• 生成（Generation）：模型逐词元（Token）输出响应

词元（Token）是自然语言模型（包括大模型）特有的概念，它是模型处理自然语言的最小语言单位，所有词元的集合构成词表。每个LLM都拥有自己的分词器，用于高效表示输入文本。粗略估算，多数主流LLM中，1个Token约等于0.75个英文单词；对于汉字，1个Token约等于1.8个汉字，具体数值因模型而异。

序列长度指序列的长度。输入序列长度（ISL）是模型接收的Token数，包含用户请求、系统提示（如模型指令）、历史对话记录、思维链（CoT）推理以及检索增强生成（RAG）的文档。输出序列长度（OSL）是模型生成的Token数。上下文长度是模型每一步生成时使用的总Token数（含输入和已生成的输出），每个LLM都有最大上下文长度的限制。

流式传输（Streaming）允许将部分输出以增量词元块的形式实时返回给用户，这对需要快速初始响应的聊天应用尤其重要。非流式模式下则一次性返回完整结果。

3. LLM推理指标

本节将解释行业常用的指标，例如“首Token时间”（Time to First Token，简称TTFT）和“Token间延迟”（Intertoken Latency，简称ITL）。尽管这些指标听起来直观，但不同测试工具在定义与测量方式上存在一些细微但重要的差异。

3.1 首Token时间（TTFT）

首Token时间（TTFT）是指从提交提示到生成第一个Token所需的时间，即用户等待模型首次输出的时长。具体如下图所示：

TTFT通常包含请求排队时间、预填充时间及网络延迟。提示越长，TTFT越大，因为注意力机制需要计算整个输入序列来创建键值缓存（KV Cache），之后迭代生成循环才启动。此外，生产环境中多个请求可能同时处理，导致某个请求的预填充阶段与其他请求的生成阶段重叠。

需要注意的是，不同的基准测试工具（如GenAI-Perf和LLMPerf）在测量TTFT时，通常会忽略那些“无内容”的初始响应——例如返回了空字符串或未生成任何Token的情况。原因在于：如果第一条返回的内容为空，TTFT指标便失去了参考价值。

3.2 端到端请求延迟（e2e_latency）

端到端请求延迟（e2e_latency）是指从提交请求到接收完整响应的总时间，包含排队、批处理及网络延迟（如下图所示）。流式模式下，由于分次返回结果，解词元步骤可能多次执行。 对单个请求而言，端到端延迟就是从请求发出到最后一个Token返回的时间差。也就是说：

需要注意的是，生成阶段的持续时间（generation_time）是从收到第一个Token到最后一个Token的时间跨度。同时，一些测试工具（如GenAI-Perf）会过滤掉最后的完成信号或空白响应，不将其计入e2e_latency。

3.3 Token间延迟（ITL）

Token间延迟（ITL）是序列中连续词元生成的平均间隔时间，也称为每Token时间（Time Per Output Token，TPOT）。 尽管定义看似简单，不同工具在指标收集方式上存在差异。例如，GenAI-Perf不将TTFT纳入平均值计算（而LLMPerf则包含）。GenAI-Perf通过以下公式定义ITL：

即：平均Token时间 = (收到最后一个Token的时间 - 收到第一个Token的时间) / (总Token数 - 1)

这里减1的目的是排除首Token，使ITL更准确地反映解码（Decoding）阶段的真实性能。此外，随着输出Token数量增加，KV Cache也会逐渐增大。每生成一个新Token，注意力机制的计算量呈线性增长。不过通常，这一阶段不会是计算瓶颈。如果ITL保持稳定，说明内存管理与带宽利用均较优，Attention机制也处理得高效。

3.4 每秒生成Token数（TPS）

TPS（Tokens Per Second） 是系统整体每秒生成的Token数量。起初，随着并发请求数增加，系统TPS也会随之上升，直到GPU资源被完全利用，TPS便会趋于饱和，甚至可能开始下降。例如，在一次完整的基准测试中，可以这样理解时间轴上的事件： 以上图为例，假设基准测试总时间线包含n个请求，事件定义如下：

• Li：第i个请求的端到端延迟
• T_start：测试开始时间
• Tx：首个请求发送时间戳
• Ty：末个请求的最后响应时间戳
• T_end：测试结束时间

GenAI-Perf将TPS定义为：总生成Token数除以第一个请求和最后一个请求的最后一个响应之间的端到端延迟时间：

LLMPerf将TPS定义为：总生成Token数除以整个基准测试持续时间：

因此，LLMPerf的指标还包含以下开销：

• 输入提示生成
• 请求准备
• 响应存储

据观察，在单并发（single concurrency）场景下，这些开销有时可占到整个基准测试持续时间的33%左右。需要注意的是，TPS的计算是批量（batch）完成的，不是实时（live）动态变化的指标。此外，GenAI-Perf使用了滑动窗口技术（sliding window technique）来寻找稳定的测量区间。

这意味着，最终统计结果基于一部分已完成且具有代表性的请求子集，即在计算时会排除刚开始预热（warming up）和最后收尾阶段（cooling down）的请求。

每个用户的TPS（TPS per user）表示从单个用户角度测量的吞吐量，定义为：

该定义适用于单个用户的每次请求。当输出序列长度不断增加时，TPS per user的值会逐渐趋近于1/ITL（即每个Token平均生成时间的倒数）。需要注意的是，随着系统中并发请求数的增加：系统整体的总TPS会增加，但单个用户的TPS（TPS per user）会随延迟增加而下降。

3.5 每秒请求数（RPS）

每秒请求数（RPS）表示系统1秒内成功完成的平均请求数，计算公式为：

尽管RPS指标比TPS更粗略，但它同样重要，尤其适用于应用服务器层面的性能评估。

4. 基准测试与最佳实践

本节将介绍确保测试有效性的关键参数及其取值范围。合理的测试设置，才能保证测试结果既可靠，又能真实反映系统性能。

4.1 应用场景对LLM性能的影响

不同的应用场景，对输入（ISL）和输出（OSL）Token数量的要求截然不同。而这些Token数的变化，直接影响系统消化输入、构建KV缓存、生成输出的速度。

一般来说：输入序列越长，预填阶段（Prefill）所需的显存就越多，首Token时间（TTFT）就越高；输出序列越长，生成阶段（Generation）对显存带宽与容量的要求也越高，Token间延迟（ITL）就越大。

因此，在部署LLM时，务必明确自身应用场景中输入和输出的长度分布，这样才能合理规划硬件资源，实现最优利用。常见应用场景及其ISL / OSL特征举例如下：

翻译：包括语言翻译和代码翻译。特点是输入输出长度相近，通常在500～2000个Token左右。

内容生成：例如生成代码、故事、邮件正文或通过检索生成一般性内容。特点是输出很长（约1000 Token量级），而输入通常较短（约100 Token量级）。

摘要总结：包括检索、链式思考提示（CoT prompting）、多轮对话等场景。特点是输入很长（约1000 Token以上），输出很短（约100 Token）。

推理（Reasoning）：近年来的新型推理模型，在处理复杂推理、代码生成、数学题、逻辑谜题时，常需要非常详细的链式思考、反思验证等。特点是输入短（约100 Token），但输出极长（1000到10000 Token级别）。

4.2 负载控制参数（Load Control Parameters）

以下将介绍专门用于“施加负载”的参数。

并发数（Concurrency N）：同时活跃的请求数量，也可理解为同时发起请求的用户数。每当一个用户的请求完成，立即发起下一个请求，确保系统中始终有N个活跃请求。通常，描述LLM推理负载最常用的参数就是并发数。

最大批处理大小（Max Batch Size）：推理引擎一次能同时处理的最大请求数。这可能是并发请求的一个子集。如果并发数超过最大批处理大小乘以活跃副本数，多余的请求需排队等待。这种情况下，TTFT（首Token时间）也会因排队而增加。

请求速率（Request Rate）：控制新请求发送频率的另一种方式。

恒定速率（Constant Rate）：每1/r秒发送1个请求。

泊松分布速率（Poisson Rate）：请求之间的间隔时间随机，但平均速率固定。

不同测试工具支持的负载控制方式有所不同，有的更倾向于使用并发数，有的支持两种方式。通常建议优先使用并发控制，因为如果仅控制发送速率，而系统处理能力不足，未完成请求数可能会无限堆积。

小提示：设定测试参数时，可从并发数1开始，逐步增加至略高于最大批处理大小的范围。因为通常，当并发数接近最大批处理时，系统吞吐量会达到饱和，而延迟会继续上升。

4.3 其他重要参数

除负载相关参数外，还有一些其他设置会影响推理性能或测试准确性：

是否忽略EOS（ignore_eos参数）：大多数LLM都有一个特殊的“结束符”（EOS Token），表示生成结束。正常推理时，模型遇到EOS即停止生成。但在性能测试中，为了测到指定长度、保证每次输出长度一致，通常会设置忽略EOS，让模型继续生成直到达到最大Token数。

采样策略（Sampling Parameters）：不同的采样策略，如Greedy（每次选得分最高的Token）、Top-p（按累积概率筛选）、Top-k（按最高k个概率选）、Temperature（调整随机性）都会影响生成速度。

例如，Greedy策略最快，因为无需排序、归一化概率分布，直接选取最高分的Token即可。进行基准测试时，无论选择哪种采样方法，都应在整个测试过程中保持一致，避免引入额外干扰。