登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

豆瓜网 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›LLM Benchmark

LLM Benchmark

尸酒岐 前天 22:58
1. LLM Benchmark

随着大语言模型（LLM）的不断发展，如何系统化、客观化地对其进行评测与性能对比，已经成为研究与工业落地中不可或缺的一环。传统的模型评测往往聚焦在单一的任务或指标，而在实际应用中，LLM 的表现不仅取决于模型本身，还与推理框架、硬件环境以及参数调优方式密切相关。
本文将结合 EvalScope 开源的大模型评测基座，探索如何完成 LLM Benchmark 流程，并通过实际的性能压测，进一步探索推理框架对模型推理表现的影响。
 
2. EvalScope介绍

EvalScope 由阿里巴巴魔搭社区（ModelScope）开源，定位为「大模型全生命周期评估基座」，覆盖通用 LLM、多模态、Embedding、Reranker、CLIP、AIGC（图生文/视频）等全类型模型能力验证与性能压测。
总的来说，EvalScope支持以下特性：

  • 评价基准丰富：内置了多个主流评价基准，包括且不限于：

    • MMLU：涵盖57门学科的多项选择题，考察模型通识与领域理解能力
    • CMMLU：MMLU中文版本
    • C-Eval：中文基础模型评估，涵盖52门学科的四个难度等级（初中、高中、大学、职业）的多项选择题，评估中文语境下知识、推理能力及跨难度层级表现
    • GSM8K：多步小学数据应用题，考察数据理解与多步推理
    • ARC：科学常识推理，分easy和challenge两档，评估模型基础科学知识与推理能力
    • HellaSwag：日常情景常识推理。给定事件描述，选出最合理的后续动作。评估模型的常识推理与情景理解能力。
    • TruthfulQA：真实性 & 抗幻觉评测，涵盖医疗、法律、金融、政治等问题，检测模型是否编造
    • MATH：竞赛级数学，衡量模型在复杂数学推理上的表现
    • HumanEval：python代码能力测试

  • 丰富的场景：单模型评测、竞技场模式、Baseline对比、端到端RAG评测、长推理、吞吐/延迟压测等
  • 多后端支持：Native（自研）、OpenCompass、VLMEvalKit、第三方插件如ToolBench等切换
  • 训练与评测无缝衔接：与ms-swift训练框架无缝衔接，训练完直接evalscope eval出报告
  • 可视化平台：evalscope app一键拉起Gradio WebUI，可视化图的方式实时浏览并交互
在系统架构上，Evalscope使用了模块化设计，组件包括：
Model Adapter -> Data Adapter -> Evaluation Backend -> Performance Evaluator -> Report & Visualization
以上这些组件均借口，可以通过python/cli/web三种入口调用，方便二次开发与私有云集成，进一步丰富了Evalscope的可扩展性。
 
2.1. 快速上手

下面我们通过一个示例快速上手EvalScope如何使用：
# 建议使用 python 3.10
conda create -n evalscope python=3.10
# 激活conda环境
conda activate evalscope
# 安装evalscope依赖
pip install evalscope                # 安装 Native backend (默认)
# 额外选项
pip install 'evalscope[opencompass]'   # 安装 OpenCompass backend
pip install 'evalscope[vlmeval]'       # 安装 VLMEvalKit backend
pip install 'evalscope[rag]'           # 安装 RAGEval backend
pip install 'evalscope[perf]'          # 安装 模型压测模块 依赖
pip install 'evalscope[app]'           # 安装 可视化 相关依赖
pip install 'evalscope[all]'           # 安装所有 backends (Native, OpenCompass, VLMEvalKit, RAGEval)
# 使用命令行方式开始示例测试：
evalscope eval \
--model Qwen/Qwen2.5-0.5B-Instruct \
--datasets gsm8k arc \
--limit 5
在运行示例测试命令后，便会自动下载模型与数据集，进行测试，并最终以表格的形式展示测试结果，例如：
1.png

evalscope也提供了可视化的界面，对测试结果进行可视化展示：
# 安装依赖
pip install 'evalscope[app]'
# 启动可视化服务
evalscope app
对于已经用了推理框架（例如vLLM、SGLang）部署的模型，EvalScope也支持指定模型推理的API进行测试，例如：
# 首先使用vLLM部署模型服务
export VLLM_USE_MODELSCOPE=True && python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-0.5B-Instruct --served-model-name qwen2.5 --trust_remote_code --port 8801
# 使用evalscope对模型推理API进行测试
evalscope eval \
--model qwen2.5 \
--api-url http://127.0.0.1:8801/v1 \
--api-key EMPTY \
--eval-type service \
--datasets gsm8k \
--limit 10
 
3. 模型性能测试

接下来我们的目标是测试模型在不同场景下（例如GPU、推理引擎、推理参数等）的性能表现。对于性能测试部门，EvalScope也提供了对应的功能来完成，下面展示基本用法：
# 安装额外依赖
pip install evalscope[perf] -U
# 使用vLLM部署模型服务
export VLLM_USE_MODELSCOPE=True && python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-0.5B-Instruct --served-model-name qwen2.5 --trust_remote_code --port 8801
# 执行性能评测
evalscope perf \
  --parallel 1 10 50 100 200 \
  --number 10 20 100 200 400 \
  --model qwen2.5 \
  --url http://127.0.0.1:8801/v1/chat/completions \
  --api openai \
  --dataset random \
  --max-tokens 1024 \
  --min-tokens 1024 \
  --prefix-length 0 \
  --min-prompt-length 1024 \
  --max-prompt-length 1024 \
  --tokenizer-path Qwen/Qwen2.5-0.5B-Instruct \
  --extra-args '{"ignore_eos": true}'
对应参数解释：

  • parallel: 请求的并发数，可以传入多个值，用空格隔开
  • number: 每个并发请求的数量，可以传入多个值，用空格隔开（与parallel一一对应）
  • url: 请求的URL地址
  • model: 使用的模型名称
  • api: 使用的API服务，默认为openai
  • dataset: 数据集名称，此处为random，表示随机生成数据集

    • 随机表示的是根据prefix-length、max-prompt-length和min-prompt-length随机生成prompt，必须指定tokenizer-path。生成的prompt token数量会在prefix+[min-prompt-length, max-prompt-length] 之间均匀分布，且在一次测试中所有请求prefix部分相同。需要注意的是，由于chat_template和tokenize算法的影响，生成的prompt的token数量可能有些误差，不是精确的指定token数量
    • 支持多模态数据集

  • tokenizer-path: 模型的tokenizer路径，用于计算token数量（在random数据集中是必须的）
  • extra-args: 请求中的额外的参数，传入json格式的字符串，例如{"ignore_eos": true}表示忽略结束token
在性能评测结束后，会打印每轮测试的结果，以及测试总结，具体指标解释可以参考官方文档具体说明[1]。
 
3.1. 可视化结果

模型性能测试的结果可以通过wandb和swanlab进行可视化展示。这里以swanlab为例：
# 安装swanlab离线看板
pip install 'swanlab[dashboard]'
# 在性能测试命令中加上--swanlab-api-key local 参数
evalscope perf \
  --parallel 1 10 50 100 200 \
  --number 10 20 100 200 400 \
  --model qwen2.5 \
  --url http://127.0.0.1:8801/v1/chat/completions \
  --api openai \
  --dataset random \
  --max-tokens 1024 \
  --min-tokens 1024 \
  --prefix-length 0 \
  --min-prompt-length 1024 \
  --max-prompt-length 1024 \
  --tokenizer-path Qwen/Qwen2.5-0.5B-Instruct \
  --extra-args '{"ignore_eos": true}' \
  --swanlab-api-key local
在测试结束后，运行：
swanlab watch -h 0.0.0.0 /home/ubuntu/outputs
即可提供web访问页面，查看包括可视化结果、统计表格、以及系统、硬件等信息。例如：
2.png

 
4. vLLM推理性能测试

在具备了LLM Benchmark的能力后，也就提供对推理框架例如vLLM调优的基础（baseline+benchmark对比）。下面我们开始尝试对vLLM的不同参数进行调优，观察对推理性能的影响。
 
4.1. 测试环境说明

在这次测试会使用以下环境与参数：

  • 硬件选择：AWS p5.4xlarge实例

    • GPU单卡H100，80GB内存
    • 16 vCPU, 256GB内存

  • 模型选择：由于现在主流LLM均在往MoE方向发展，所以测试近期比较热门的gpt-oss-120b（117B参数量，激活参数5.1B），它也能够在单卡H100上运行
 
4.2. 测试指标

常规来说，会从三个大的类别来评测LLM推理表现，包括：

  • 输出质量：包括正确率、任务完成率、参考相似性（ROUGE/BLEU/BERTScore）、Exact Match/F1、Perplexity、公信度与幻觉率等方面的表现，评估LLM推理输出的质量高低
  • 性能效率：包括TTFT（首token延迟）、ITL（token间延迟）、吞吐（Throughput）、RPS（每秒请求数）、显存/计算资源使用、FLOPs、成本等方面的表现，评估LLM推理的性能高低
  • 鲁棒与安全性：包括对抗鲁棒性、提示敏感度、泛化能力、有害偏见、公平性、越狱率等方面的表现，评估LLM推理的稳定性与安全性
在这个测试场景下，我们仅关注推理的性能效率，具体地说，主要关注以下指标：

  • TTFT（Time to First Token）：处理prompt并生成第一个 token 所需的时间 。也就是用户在看到模型输出之前必须等待的时间。

    • TTFT一般包含请求排队的时间、prefill时间以及网络延迟。且prompt越长，TTFT越长
    • 在生产环境中，一个推理应用可能会处理多个请求，所以某个请求的prefill阶段可能会与其他请求的generation阶段有重合

  • 端到端请求延迟（e2e_latency）：在一个请求提交后，到获取到完整返回所用的时间

    • 包含了请求排队时间、batching时间和网络延迟
    • 常规来说，对于单个请求，e2e_latency = TTFT + generation_time

  • ITL（Intertoken latency）：在一个sequence中，连续token生成的平均间隔时间，也称TPOT（time per output token）
  • TPS（Tokens per second）：推理系统每秒输出token的吞吐，计入了所有并发请求。随着请求数的增加，一般会伴随着系统的总TPS增加，直到达到所有可用GPU计算资源的饱和点，超过该点后，总TPS可能会下降
  • RPS（Requests per second）：在一秒内系统能够处理的平均请求数
 
4.3. 不同应用场景的需求

对于不同的应用场景，所需要关注的指标也是不一样的。一个应用的具体场景首先决定了其序列的长度，包括输入序列长度ISL（Input Sequence Length）和输出序列长度OSL（Output Sequence Length）。进而影响系统处理输入prompt，生成KV Cache以及生成输出token的速度。
较长的ISL会增加prefill阶段的GPU内存需求，从而增加TTFT延迟。而较长的OSL会增加decode（generation）阶段的GPU内存需求（包括带宽和容量），从而增加ITL延迟。所以在优化推理系统时，仍然要考虑到应用的场景是什么，才能决定关注并优化的指标是什么。
下面是几个常见的应用场景以及ISL/OSL的典型组合：

  • 翻译：包括不同语言之间的翻译以及代码翻译，其特点是ISL和OSL长度相近，通常在500-2000个token左右
  • 生成：包括故事、文案、代码等。其特点是OSL较长（常规可能在1000 token），远长于ISL的token（100 token左右）
  • 摘要：包括retrieve、多轮对话等。其特点是ISL较长，远长于OSL的token（例如1000:100的规模）
  • 推理：推理模型会生成大量的token，其特点是ISL较短，简单场景通常100个token左右，而OSL非常大，甚至能达到1000-10000个token
 
4.4. 测试参数

在指定测试参数时，常规来说，我们会指定并发数、请求数、prompt token数、生成token数等参数。除了这些参数之外，还有些相关的LLM serving参数，它们不仅会影响推理性能，也会影响benchmark的准确性。
大部分LLM都有一个EOS标记，表示生成过程的结束。ignore_eos 参数通常用于指示LLM推理框架是否应该忽略EOS标记，并持续生成标记直到达到 max_tokens 的上限。出于benchmark测试的目的，此参数应设置为 True，以确保达到预期的输出长度，从而获得一致的测量结果。
不同的采样参数（如greedy、top_p、top_k 和 temperature）可能会对LLM的生成速度产生影响。例如，greedy采样直接选择具有最高logit值的token，无需对整个token的概率分布进行归一化和排序，从而节省了计算开销。无论选择哪种采样方法，在同一benchmark测试中保持一致性都是一个良好的实践。
 
5. vLLM+gpt-oss-120b性能测试

5.1. vLLM部署gpt-oss-120b

下面我们参考vLLM官方文档[3]部署gpt-oss-120b模型。vLLM官方文档提到针对 gpt-oss 系列模型进行了以下优化：

  • 灵活的并行选项：模型可以切分到 2、4、8 块 GPU 上，从而扩展吞吐量。
  • 高性能的attention和 MoE kernel：attention kernel针对attention sinks机制和sliding window shapes进行了专门优化。对于这两个机制的解释可以参考文档[4]
  • 异步调度：通过将 CPU 操作与 GPU 操作重叠，实现最高利用率和高吞吐量。
通过以下命令即可直接通过vLLM部署gpt-oss-120b：
# 安装flashinfer
pip install flashinfer-python
# 部署gpt-oss-120b
vllm serve openai/gpt-oss-120b --served-model-name gpt-oss-120b --trust_remote_code --port 8801 --async-scheduling
在部署时会遇到下面的报错：
(EngineCore_0 pid=5768) ValueError: To serve at least one request with the models's max seq len (131072), (4.79 GiB KV cache is needed, which is larger than the available KV cache memory (2.47 GiB). Based on the available memory, the estimated maximum model length is 63488. Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine.
可以尝试增加gpu_memory_utilization（默认为0.9）或减少max_model_len参数值来解决。这里我们通过增加gpu_memory_utilization解决：
vllm serve openai/gpt-oss-120b --served-model-name gpt-oss-120b --trust_remote_code --gpu_memory_utilization 0.95 --port 8801 --async-scheduling
部署后GPU内存使用情况为：79449MiB /  81559MiB
 
5.2. 基准测试

在部署完gpt-oss-120b后，我们选择Summarization作为应用场景，也就是ISL远长于OSL的场景（假设ISL : OSL = 1024 : 128）。首先做一个基准测试作为baseline：
evalscope perf \
  --parallel 1 10 50 100 200 300 \
  --number 10 20 100 200 400 600 \
  --model gpt-oss-120b \
  --url http://127.0.0.1:8801/v1/chat/completions \
  --api openai \
  --dataset random \
  --max-tokens 128 \
  --min-tokens 128 \
  --prefix-length 0 \
  --min-prompt-length 1024 \
  --max-prompt-length 1024 \
  --tokenizer-path openai-mirror/gpt-oss-120b \
  --extra-args '{"ignore_eos": true}' \
  --swanlab-api-key local
在这个配置下，prompt length=1024，output length=128。下面是整体的结果：
3.png

从这个图里我们可以得到几个结论：

  • 随着并发不断升高，RPS先快速提升，最终在200-300并发之间达到吞吐饱和。在300并发下，RPS和token生成速度基本不变的情况下，平均延迟与p99延迟仍然在上升，请求排队时间变长
  • 随着并发不断升高，TTFT成为主要瓶颈

    • TTFT 从 1 并发的 0.072 秒，增加到 300 并发的 9.640 秒
    • P99 TTFT 达到 16.943 秒，远超平均值，说明部分请求在 Prefill资源时遭遇了严重瓶颈

  • TPOT相对稳定，随着并发的上升，恶化程度远小于TTFT和延迟。

    • TPOT反应的是Decoding阶段的效率，其相对稳定表明 Decoding 阶段的资源争抢不如 Prefill 阶段严重

  • 生成的吞吐表现不错，在单卡H100上，基于达到最高1852 token/s。其趋势与RPS基本保持一致，也说明了在200-300并发时，系统处理生成任务能力也接近了上限
 
6. 优化TTFT？

在baseline测试中，可以看到在Summarization的场景下，相比TPOT来说，TTFT是一个非常明显的瓶颈。接下来我们尝试是否可以优化TTFT。
 
6.1. 关闭chunked prefill

在vLLM V1版本中，chunked prefill是默认启动的。这个功能的意思是将长prefill请求切分为更小的chunk，然后与其他的decode请求一起进行调度。这个功能可以更好地平衡prefill（计算需求高）与decode（内存需求高）的操作，继而提升吞吐与延迟表现，特别是在混合负载。
下面我们关闭chunked prefill，使其对一个请求先做prefill完成后，再进行decode：
vllm serve openai/gpt-oss-120b --served-model-name gpt-oss-120b \
--trust_remote_code \
--no-enable-chunked-prefill \
--gpu_memory_utilization 0.95 \
--port 8801 \
--async-scheduling
然后继续进行一轮perf测试后，统计的各项指标基本没有任何改进，甚至稍微有一点点下降：
4.png

通过对比swanlab的可视化结果细节，也同样基本没有区别。
 
6.2. 关闭async-scheduling

async-scheduling是一个实验性质的功能，这有助于降低 CPU 开销，从而改善延迟和吞吐量。然而，异步调度目前不支持某些功能，例如结构化输出、推测解码和流水线并行。
vllm serve openai/gpt-oss-120b --served-model-name gpt-oss-120b \
--trust_remote_code \
--no-enable-chunked-prefill \
--gpu_memory_utilization 0.95 \
--port 8801 \
测试后的结果如下：
5.png

可以看到，关闭async-scheduling后，无论是RPS、Latency还是TTFT，这些指标都出现不同程度的下降，说明异步调度无论是在低并发还是高并发的情况下，都是有必要启用的。
 
6.3. 总结

在继续尝试了多种vLLM提供的各类参数后（例如--max-num-batched-tokens、--max-num-seqs等），我们仍然无法达到比第一次表现更好的测试。而在vLLM官方文档中提到的优化部分（例如并行策略、输入处理以及多模态Caching），均不适用于这次测试。从目前的情况来看，说明vLLM默认对单卡gpt-oss-120b已经做了相对不错的优化。
 
7. vLLM监控

下面我们再基于监控继续探索在测试过程中的各项指标，首先部署grafana与prometheus：
# Prometheus
# 编写配置文件prometheus.yaml
global:
  scrape_interval: 5s      
  evaluation_interval: 30s  
scrape_configs:
  - job_name: 'vllm'        
    static_configs:
      - targets:
          - '172.31.9.251:8801' # vllm启动时指定的服务端口
# 启动 prometheus
docker run -d \
  -p 9090:9090 \
  -v /home/ubuntu/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus
# Grafana
docker run -d -p 3000:3000 --name=grafana grafana/grafana-enterprise
然后参考官方文档[6]配置grafana dashboard，并再次运行测试。得到如下部分监控结果：
6.png

7.png

从监控中可以看到，从端到端的延迟以及token输出延迟指标来看，p50和平均值基本一致，而p90，p95和p99超出了许多，原因主要是由于在高并发后大量请求排队导致。这也符合高并发下的预期表现。
 
8. 对比SGLang

在了解了gpt-oss-120b在单卡H100和vLLM推理框架下的summarization场景表现后，我们继续看看sglang上的表现。
在OpenAI gpt-oss开源模型后，sglang也在第一时间进行了集成，可以参考官方github进行部署[7]。使用默认参数部署时，同样会遇到与vLLM部署时同样的OOM问题。解决方法也一样，增加分配的GPU mem比例即可，如下命令所示：
python3 -m sglang.launch_server --mem-fraction-static 0.95 --model openai/gpt-oss-120b
部署后运行与vLLM同样的测试，得到如下结果：
8.png

再次运行vLLM测试后，对比两者结果：
9.png

10.png
11.png
12.png

可以看到，在当前场景下：SGLang整体表现优于vLLM。且随着并发升高，SGLang的吞吐也相较vLLM有更大的提升。
 
总结

本文介绍了EvalScope 在大模型评测中的优势与应用场景，也通过示例展示了其在多维度 Benchmark、性能压测与可视化分析中的能力。在此基础上，我们还对 vLLM 的推理性能表现进行了实验，验证了不同参数配置对延迟、吞吐与并发表现的影响。
总体来看，EvalScope 为研究者和工程师提供了一套 开箱即用、可扩展、可对接推理框架 的完整评测工具链，降低了构建 Benchmark 与性能分析的门槛。而结合 vLLM 等推理框架的实验结果，也为 LLM 的实际落地提供了有价值的调优参考。
References

[1] EvalScope模型推理性能压测,快速开始：https://evalscope.readthedocs.io/zh-cn/latest/user_guides/stress_test/quick_start.html
[2] LLM Inference Benchmarking: Fundamental Concepts：https://developer.nvidia.com/blog/llm-benchmarking-fundamental-concepts/
[3] GPT OSS：https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/GPT-OSS.html
[4] 探秘Transformer系列之（25）--- KV Cache优化之处理长文本序列： https://www.cnblogs.com/rossiXYZ/p/18811785#122-streamingllm
[5] vLLM Optimization and Tuning：https://docs.vllm.ai/en/latest/configuration/optimization.html
[6] Prometheus and Grafana： https://docs.vllm.ai/en/latest/examples/online_serving/prometheus_grafana.html#launch
[7] OpenAI gpt-oss Day 0 Support：https://github.com/sgl-project/sglang/issues/8833

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除
LLMBenchmark

使用道具 举报

相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
尸酒岐
前天 22:58

0

粉丝关注

17

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫