【AIGC】大模型面试高频考点18-大模型压力测试指标

大模型压测，就是要评估其服务稳定性、性能表现和用户体验，而关于大模型的压测指标需结合LLM特有指标（针对生成式任务的推理特性）和通用性能指标（反映系统整体承载能力）综合分析。

（一）LLM特有指标

生成式大模型（如GPT、DeepSeek、Qwen等）的核心任务是“逐token生成内容”，其性能需重点关注生成效率和用户感知延迟，以下指标为LLM压测的核心特有指标：

（1）TTFT（Time To First Token，首字时间）

定义： 从客户端发送完整请求（含prompt等参数）到接收到模型生成的第一个token的时间间隔，单位为毫秒（ms）或秒（s）。

重要性： 直接影响用户对“响应速度”的初始感知。在交互式场景（如对话、实时问答）中，TTFT过长（如超过2秒）会让用户产生“系统卡顿”的负面体验，甚至放弃使用。例如，用户问“今天天气怎么样？”，若TTFT为1秒，用户会觉得“响应快”；若TTFT为5秒，则可能认为“系统慢”。

测量方法： 在客户端记录请求发送时间戳（t_send）和第一个token接收时间戳（t_first_token），计算TTFT = t_first_token - t_send。需统计多次请求的平均值、p95/p99分位数（避免极端值影响）。

（2）TPOT（Time Per Output Token，每令牌时间）

定义： 生成过程中，相邻两个token之间的平均时间间隔，单位为毫秒/ token（ms/token）。例如，生成第2个token与第1个token间隔50ms，第3个与第2个间隔60ms，则TPOT为(50+60)/2=55ms/token。

重要性： 反映生成内容的“流畅性”。TPOT越高，用户感知的“卡顿感”越强（如生成一段100字的文本，若TPOT=100ms/token，需10秒完成，用户会觉得“断断续续”；若TPOT=30ms/token，需3秒完成，则体验流畅）。

测量方法： 在生成过程中记录每个token的接收时间戳（t_token1, t_token2, …, t_tokenN），计算相邻时间差（Δt_i = t_token(i+1) - t_token_i），再求平均值或分位数（TPOT = mean(Δt_1, Δt_2, ..., Δt_(N-1))）。

（3）TPS（Token Per Second，每秒传输token数）

定义： 单位时间内（通常为秒）模型生成的总token数量，单位为token/s（tok/s）。计算方式为：TPS = (总token数 - 1) / (最后一个token时间 - 第一个token时间)（注：减1是因为第一个token的时间已包含在TTFT中，避免重复计算）。

重要性： 综合反映模型的生成效率，是衡量大模型服务“处理能力”的核心指标。对于长文本生成任务（如文档摘要、代码生成、报告撰写），TPS直接决定任务完成时间（如生成1000 token，TPS=100 tok/s需10秒，TPS=50 tok/s需20秒）。

测量方法： 统计所有并发请求在单位时间内生成的总token数（如10秒内100个请求共生成5000 token，则TPS=500 tok/s）。需区分“单请求TPS”（单个请求的生成效率）和“集群TPS”（整个服务的总生成能力）。

（二）通用性能指标

通用性能指标适用于大多数软件系统，用于评估大模型服务的稳定性、可扩展性和资源效率，是压测中判断“系统是否能满足实际需求”的基础。

（1）响应时间分布（p50、p95、p99）

定义： 响应时间指从客户端发送请求到接收到完整回复（最后一个token）的时间间隔。响应时间分布通过分位数反映不同比例请求的响应表现：

• p50（中位数）： 50%的请求响应时间小于等于该值，反映“典型用户”的体验；
• p95： 95%的请求响应时间小于等于该值，反映“大部分用户”的体验（避免长尾问题掩盖）；
• p99： 99%的请求响应时间小于等于该值，反映“极端情况”下的性能（如高并发、复杂输入）。

重要性： 平均响应时间可能被极端值扭曲（如1个请求100秒，99个请求1秒，平均为2秒，但p99=100秒），而分位数能更真实反映用户体验。例如，若p95=2秒，说明95%的用户在2秒内得到完整回复，服务可用性高；若p99=10秒，说明1%的用户需等待10秒，可能存在长尾瓶颈（如垃圾回收、资源竞争）。

测量方法： 记录每个请求的响应时间（t_response = t_last_token - t_send），对所有请求的响应时间排序，计算对应分位数（如p95=第95%位置的响应时间）。

（2）每秒请求数（QPS，Queries Per Second）

定义： 单位时间内（通常为秒）服务成功处理的请求数量，单位为req/s。计算方式为：QPS = 成功请求数 / 总时间（注：仅统计成功请求，排除错误请求）。

重要性： 反映服务的并发处理能力，是衡量“服务能同时支持多少用户”的核心指标。例如，若QPS=100，说明每秒能处理100个用户请求；若预期用户峰值=1000，则需扩容至QPS≥1000。

测量方法： 在压测工具（如JMeter、Locust、wrk）中统计单位时间内成功返回的请求数（如10秒内成功处理1000请求，则QPS=100 req/s）。需关注“峰值QPS”（服务能承受的最大QPS，超过则错误率上升）和“稳定QPS”（长期运行时保持的QPS，避免性能衰减）。

（3）错误率（Error Rate）

定义： 单位时间内错误请求数占总请求数的比例，单位为百分比（%）。错误类型包括：

• HTTP状态码错误： 5xx（服务端错误，如500 Internal Server Error、502 Bad Gateway）、4xx（客户端错误，如400 Bad Request、413 Payload Too Large）；
• 业务逻辑错误： 模型推理失败（如输入长度超过模型限制、输出格式不符合要求）、超时错误（请求处理时间超过阈值，如30秒）；
• 资源错误： 内存溢出（OOM，Out of Memory）、GPU显存不足（CUDA out of memory）。

重要性： 直接反映服务的稳定性。高错误率（如超过1%）会导致用户体验急剧下降（如频繁报错、请求失败），甚至影响业务可用性（如客服机器人无法回复用户）。

**测量方法：**统计单位时间内错误请求数（按错误类型分类），计算错误率 = (错误请求数 / 总请求数) × 100%。需区分“瞬时错误率”（突发流量导致）和“持续错误率”（系统缺陷导致）。

（4）吞吐量（Throughput）

定义： 时间内系统处理的工作量，需结合任务类型定义：

• 生成式任务： 通常用“每秒生成token数”（即TPS）作为吞吐量，反映内容生成效率；
• 判别式任务（如文本分类、命名实体识别）： 用“每秒处理样本数”（Sample/s）作为吞吐量，反映分类/标注效率；
• 通用场景： 也可用“每秒处理数据量”（如MB/s）反映数据传输或处理能力。

重要性： 与QPS互补，QPS反映“请求数量”，吞吐量反映“实际完成的工作量”。例如，两个服务的QPS均为100，但服务A每个请求生成10 token（吞吐量=1000 tok/s），服务B每个请求生成100 token（吞吐量=10000 tok/s），则服务B的实际处理能力更强。

测量方法： 根据任务类型统计工作量（如生成token数、处理样本数），计算吞吐量 = 总工作量 / 总时间。需关注“峰值吞吐量”（资源极限下的处理能力）和“稳定吞吐量”（长期运行时的平均处理能力）。

（5）资源利用率（CPU、内存、网络）

定义： 系统资源的使用程度，核心指标包括：

• CPU利用率： CPU处理任务的时间占比，分为“用户态利用率”（用户程序占用）和“内核态利用率”（系统调用占用）；
• 内存利用率： 使用量占总内存的比例，需关注“已用内存”（包括缓存和缓冲区）和“可用内存”；
• GPU利用率： GPU计算单元的使用时间占比（通过nvidia-smi查看），反映GPU的计算负载；
• 网络带宽利用率： 网络输入/输出流量占总带宽的比例（如1Gbps网卡使用了500Mbps，则利用率为50%）。

重要性： 识别系统瓶颈的关键指标。例如：

• CPU利用率高（≥90%）：说明计算任务是瓶颈（如预处理、后处理逻辑复杂）；
• GPU利用率低（≤30%）：说明GPU未充分利用（如模型推理效率低、数据加载慢）；
• 内存利用率高（≥85%）：说明内存不足（可能触发OOM，需扩容或优化内存使用）；
• 网络带宽利用率高（≥80%）：说明网络是瓶颈（如输入输出数据量大，需扩展带宽）。

（三）测量方法： 使用系统监控工具收集数据

• CPU/内存：top、htop、vmstat（Linux）；Performance Monitor（Windows）；
• GPU：nvidia-smi（NVIDIA GPU）、rocm-smi（AMD GPU）；
• 网络：iftop、nload（Linux）；Resource Monitor（Windows）；
• 容器环境：kubectl top pods（Kubernetes）、docker stats（Docker）。