引言
随着生成式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）指从提交请求到接收完整响应的总时间，含排队、批处理和网络延迟（如下图所示）。流式模式下，由于分次返回结果，解词元步骤可能多次执行。
需要注意的是，生成阶段的持续时间（generation_time）是从收到第一个 Token 到最后一个 Token 的时间跨度。同时，一些测试工具（比如 GenAI-Perf）会过滤掉最后的完成信号或者空白响应，不把这些算进 e2e_latency 里。
3.3 Token 间延迟（ITL）
Token间延迟（ITL）是序列中连续词元生成的平均间隔时间，也称每Token时间（Time Per Output Token，TPOT）。
即：平均 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 就会趋于饱和，甚至可能开始下降。比如，在一次完整的基准测试中，可以这么理解时间轴上的事件：
「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）：请求之间的间隔时间是随机的，但平均速率固定
不同测试工具支持的负载控制方式也不太一样，有的更倾向用并发数，有的支持两种。一般建议优先用并发控制，因为如果只控制发送速率，而系统处理不过来，未完成请求数可能会无限堆积。
小tip：在设定测试参数时，可以从并发数 1 开始，逐步增加到略高于最大批处理大小的范围。因为通常，在并发数接近最大批处理时，系统吞吐量会达到饱和，而延迟会继续上升。
4.3 其他重要参数
除了负载相关的，还有一些其他设置也会影响推理性能，或者影响测试准确性：
「是否忽略 EOS（ignore_eos 参数）」：大多数 LLM 都有一个特别的“结束符”（EOS Token），表示生成结束。正常推理时，模型遇到 EOS 就会停止生成。但在性能测试时，为了测到指定长度、保证每次输出长度一致，通常会设置忽略 EOS，让模型继续生成直到达到最大 Token 数。
「采样策略」（Sampling Parameters）：不同的采样策略，比如：Greedy（每次选得分最高的 Token）、Top-p（按累积概率筛选）、Top-k（按最高 k 个概率选）、Temperature（调整随机性）都会影响生成速度。
比如 Greedy 策略最快，因为不用排序、归一化概率分布，直接拿最高分的 Token 就行了。做基准测试时，「不管选哪个采样方法，都要在整个测试过程中保持一致，避免引入额外干扰」。
