这是大语言模型延迟 – 吞吐量基准测试系列的第三篇博文，旨在指导开发者如何使用 TensorRT-LLM 对 LLM 推理进行基准测试。有关基准测试和参数的常用指标的背景知识，请参阅 LLM 推理基准测试：基本概念。阅读《 LLM 推理基准测试指南：NVIDIA GenAI-Perf 和 NIM》，了解如何在您的应用中使用 GenAI – Perf 和 NVIDIA NIM。
在部署、集成或对任何大语言模型 (LLM) 框架进行基准测试时，务必要考虑推理性能。您需要确保调整所选框架及其功能，以便其提供对应用程序至关重要的性能指标。
TensorRT-LLM 是 NVIDIA 的开源 AI 推理引擎，允许您使用其原生基准测试和服务工具部署模型，并具有一系列可调整的功能。在本文中，我们将提供实用指南，介绍如何使用 trtllm-bench 调整模型，然后使用 trtllm-serve 进行部署。
如何使用 trtllm-bench 进行基准测试
trtllm-bench 是 TensorRT-LLM 基于 Python 的实用程序，可直接对模型进行基准测试，而无需承担完整推理部署的开销。它使快速生成模型性能洞察变得简单。trtllm-bench 在内部为引擎设置了最佳设置，通常可提供良好的性能。
设置 GPU 环境
基准测试始于正确配置的 GPU 环境。要将 GPU 恢复为默认设置，请运行：
sudo nvidia-smi -rgc
sudo nvidia-smi -rmc
要查询 GPU 的最大使用量：
nvidia-smi -q -d POWER
如果您要设置特定的功率限制 (或设置最大值) ，请运行：
nvidia-smi -i <gpu_id> -pl <wattage>
有关更多详细信息，请参阅 trtllm-bench 文档。
准备数据集
您可以使用 prepare_dataset 准备合成数据集，也可以使用我们的文档中指定的格式创建自己的数据集。对于自定义数据集，您可以格式化 JSON 行 (jsonl) 文件，并在每行上配置有效载荷。以下是单个数据集条目的示例：
{"task_id": 1, "prompt": "Generate infinitely: This is the song that never ends, it goes on and on", "output_tokens": 128}
出于本文目的，我们提供基于 ISL/ OSL 为 128/ 128 的合成数据集的输出示例。
运行基准测试
要使用 trtllm-bench 运行基准测试，您可以使用 ttg_ 11 子命令。使用 PyTorch 流运行基准测试时，您只需在已安装 TensorRT-LLM 的环境中运行以下命令：
trtllm-bench throughput \
--model meta-llama/Llama-3.1-8B-Instruct \
--dataset dataset.jsonl \
--tp 1 \
--backend pytorch \
--report_json results.json
--streaming \
--concurrency $CONCURRENCY
throughput 命令将自动从 HuggingFace 中提取检查点 (如果未缓存) ，并使用 PyTorch 流引导 TRT-LLM。运行完成后，结果将保存到 results.json 并打印到终端，如下所示：
注意：这只是输出样本，不代表性能声明。
===========================================================
= PYTORCH BACKEND
===========================================================
Model: meta-llama/Llama-3.1-8B-Instruct
Model Path: None
TensorRT-LLM Version: 0.21.0rc0
Dtype: bfloat16
KV Cache Dtype: None
Quantization: None
===========================================================
= REQUEST DETAILS
===========================================================
Number of requests: 100
Number of concurrent requests: 94.6050
Average Input Length (tokens): 128.0000
Average Output Length (tokens): 128.0000
===========================================================
= WORLD + RUNTIME INFORMATION
===========================================================
TP Size: 1
PP Size: 1
EP Size: None
Max Runtime Batch Size: 3840
Max Runtime Tokens: 7680
Scheduling Policy: GUARANTEED_NO_EVICT
KV Memory Percentage: 90.00%
Issue Rate (req/sec): 1.0526E+15
===========================================================
= PERFORMANCE OVERVIEW
===========================================================
Request Throughput (req/sec): 86.5373
Total Output Throughput (tokens/sec): 11076.7700
Total Token Throughput (tokens/sec): 22153.5399
Total Latency (ms): 1155.5715
Average request latency (ms): 1093.2284
Per User Output Throughput [w/ ctx] (tps/user): 117.1544
Per GPU Output Throughput (tps/gpu): 11076.7700
Average time-to-first-token [TTFT] (ms): 162.6706
Average time-per-output-token [TPOT] (ms): 7.3272
Per User Output Speed (tps/user): 137.1475
-- Per-Request Time-per-Output-Token [TPOT] Breakdown (ms)
[TPOT] MINIMUM: 6.6450
[TPOT] MAXIMUM: 8.1306
[TPOT] AVERAGE: 7.3272
[TPOT] P50 : 7.6079
[TPOT] P90 : 8.1246
[TPOT] P95 : 8.1289
[TPOT] P99 : 8.1306
-- Per-Request Time-to-First-Token [TTFT] Breakdown (ms)
[TTFT] MINIMUM: 93.9210
[TTFT] MAXIMUM: 232.4339
[TTFT] AVERAGE: 162.6706
[TTFT] P50 : 159.7857
[TTFT] P90 : 220.0530
[TTFT] P95 : 226.9148
[TTFT] P99 : 232.4339
-- Per-Request Generation Throughput [GTPS] Breakdown (tps/user)
[GTPS] MINIMUM: 122.9921
[GTPS] MAXIMUM: 150.4894
[GTPS] AVERAGE: 137.1475
[GTPS] P50 : 131.4444
[GTPS] P90 : 150.4112
[GTPS] P95 : 150.4606
[GTPS] P99 : 150.4894
-- Request Latency Breakdown (ms) -----------------------
[Latency] P50 : 1091.7905
[Latency] P90 : 1130.7200
[Latency] P95 : 1133.0074
[Latency] P99 : 1137.6817
[Latency] MINIMUM: 1050.1519
[Latency] MAXIMUM: 1137.6817
[Latency] AVERAGE: 1093.2284
===========================================================
= DATASET DETAILS
===========================================================
Dataset Path: /workspace/benchmark_toolkit/synthetic_data.jsonl
Number of Sequences: 100
-- Percentiles statistics ---------------------------------
Input Output Seq. Length
-----------------------------------------------------------
MIN: 128.0000 128.0000 256.0000
MAX: 128.0000 128.0000 256.0000
AVG: 128.0000 128.0000 256.0000
P50: 128.0000 128.0000 256.0000
P90: 128.0000 128.0000 256.0000
P95: 128.0000 128.0000 256.0000
P99: 128.0000 128.0000 256.0000
===========================================================
分析性能结果
运行上述命令时，主要统计数据显示在 PERFORMANCE OVERVIEW 部分下。在我们深入了解细节之前，以下是一些有用的术语：
- 在概述上下文中，
Output表示生成的所有输出令牌 (包括上下文令牌) Total Token表示生成的总序列长度 (ISL+ OSL)Per user、TTFT和 tg_ 21 认为每个请求都是“用户”；然后根据这些统计数据形成分布。
有关更深入的说明，请参阅本系列第一篇博文 — — LLM 推理基准测试：基本概念。
===========================================================
= PERFORMANCE OVERVIEW
===========================================================
Request Throughput (req/sec): 86.5373
Total Output Throughput (tokens/sec): 11076.7700
Total Token Throughput (tokens/sec): 22153.5399
Total Latency (ms): 1155.5715
Average request latency (ms): 1093.2284
Per User Output Throughput [w/ ctx] (tps/user): 117.1544
Per GPU Output Throughput (tps/gpu): 11076.7700
Average time-to-first-token [TTFT] (ms): 162.6706
Average time-per-output-token [TPOT] (ms): 7.3272
Per User Output Speed (tps/user): 137.1475
您还会注意到，trtllm-bench 报告令牌的最大数量和批量大小。
===========================================================
= WORLD + RUNTIME INFORMATION
===========================================================
TP Size: 1
PP Size: 1
EP Size: None
Max Runtime Batch Size: 3840
Max Runtime Tokens: 7680
它们在 TensorRT-LLM 的环境中具有特殊的含义：
- 令牌的最大数量是指引擎本身在一次批量迭代中可以处理的令牌的最大数量。此限制包括所有上下文请求的所有输入令牌之和，以及批量中所有生成请求之和的单个令牌。
- 最大批量大小是批量中允许的最大请求数。假设您的迭代包含一个上下文长度为 128 的请求、四代请求 (共 132 个令牌) ，并且您已将最大令牌设置为 512 个，最大批量大小为 5 个请求。在这种情况下，即使引擎尚未满足最大令牌，它也将限制为批量大小。
在分析结果时，了解您的优先级很有帮助。一些常见问题：
- 您的目标是提高每个用户的 token 吞吐量吗？
- 您是否正在处理大量文本并需要尽可能高的吞吐量？
- 您是否希望第一个 token 快速返回？
您选择的调优很大程度上取决于您要优先考虑的场景。在本文中，我们重点介绍如何优化每个用户的体验。我们希望优先考虑 Per User Output Speed 指标或上下文阶段完成后向用户返回 token 的速度。借助 trtllm-bench，您可以使用 tg_ 27 指定未完成请求的最大数量，从而缩小系统可支持的用户数量。
此选项可用于生成几种不同的曲线，这在搜索延迟和吞吐量目标时至关重要。以下是一组基于 NVIDIA Llama-3.1 8B FP8 和 Meta Llama – 3.1 8B FP16 为 128/ 128 ISL/ OSL 场景生成的曲线。假设我们希望尽可能多地利用该系统，但我们仍然希望用户体验到约 50 个令牌/ 秒的输出速度 (令牌之间约 20 毫秒) 。为了评估 GPU 性能和用户体验之间的权衡，您可以根据每个用户的输出速度绘制每个 GPU 的输出吞吐量。
在图 1 中，我们可以看到，Llama-3.1 8B FP16 只能以大约 72 个 token/ 秒/ 用户的速度处理大约 256 个并发用户，然后才会违反 50 个 token/ 秒/ 用户的约束条件。但是，通过观察 Llama-3.1 8B FP8 优化检查点，我们发现 TensorRT-LLM 能以大约 66 个 token/ 秒/ 用户的速度处理 512 个并发用户。我们可以得出结论，量化模型只需使用 trtllm-bench 扫描两个模型，即可在相同预算内为更多用户提供服务。
借助这些数据，您可以考虑以下事项：
- 如果您想强制引擎包含 512 个条目，可以将最大批量大小设置为 512；但是，如果指向此实例的流量超过 512 (超出 512 的任何请求都会排队) ，这可能会增加优先令牌时间 (TTFT) 。
- 您可以使用
trtllm-bench使用其他数据集评估服务质量场景和模型，并绘制各种指标。借助该工具，您可以通过简单易用的方式调整命令行，根据优先级进行价值评估。
注意：在此场景中，我们仅探索单个 GPU 模型。如果您的模型需要多个 GPU，则可以使用 --tp、tg_ 33 和 tg_ 34 选项配置 tg_ 31，以找到最佳分片/ 数据并行配置。此外，如果您是开发者并且需要高级功能，可以使用 --extra_llm_api_options 参数。
如何使用 trtllm-serve 为大语言模型提供服务
TensorRT-LLM 能够使用 trtllm-serve 命令轻松建立与 OpenAI 兼容的端点。您可以使用上面 trtllm-bench 中的调优来启动经过调优的服务器。与基准测试不同，trtllm-serve 除了常规设置之外，对配置不作任何假设。要根据上述最大吞吐量结果调整服务器，您需要根据上述输出提供以下命令：
trtllm-serve serve nvidia/Llama-3.1-8B-Instruct-FP8 --backend pytorch --max_num_tokens 7680 --max_batch_size 3840 --tp_size 1 --extra_llm_api_options llm_api_options.yml
--extra_llm_api_options 提供了一种在 LLM API 级别直接更改设置的机制。为了匹配基准测试中的设置，您需要在 llm_api_options.yml 中使用以下内容：
cuda_graph_config:
max_batch_size: 3840
padding_enabled: true
配置并运行后，您应看到服务器正在运行的状态更新：
INFO: Application startup complete.
INFO: Uvicorn running on http://localhost:8000 (Press CTRL+C to quit)
随着服务器的运行，您现在可以使用 GenAI-Perf 对模型进行基准测试 (类似于本系列的第二个博客) ，也可以使用我们的移植版本 benchmark_serving.py。这些可以帮助您验证经过调整的服务器配置的性能。在未来的版本中，我们计划增强 trtllm-bench，以便能够启动经过优化的服务器进行基准测试。
开始针对 LLM 进行基准测试和性能调整
借助 trtllm-bench，TensorRT-LLM 提供了一种对各种配置、调优、并发性和功能进行基准测试的简单方法。trtllm-bench 中的设置可直接转换为 TensorRT-LLM 的原生服务解决方案 tg_ 47。它使您能够将性能调优无缝移植到与 OpenAI 兼容的部署中。
有关性能、模型特定调优以及 TensorRT-LLM 调优/ 基准测试的更多详细信息，请参阅以下资源：
- 如需更深入地了解可用的性能选项，请参阅性能调优指南。
- 有关
trtllm-bench文档，请参阅性能基准测试页面。 - 要了解如何分析 TensorRT-LLM，性能分析涵盖使用 Nsight System 分析模型执行。
- 如需深入了解 DeepSeek-R1 的性能调优，请查看 DeepSeek – R1 的 TensorRT-LLM 性能调优指南。
查看以下资源：
- 如需详细了解平台架构如何超越 FLOPS 来影响 TCO，您可以阅读博文“NVIDIA DGX 云推出即用型模板来基准 AI 平台性能”。另请参阅此处可在 NGC 上下载的性能基准测试方法集合 (即用型模板) 。
- 阅读《 IT 领导者 AI 推理和性能指南》，了解如何降低每个 token 的成本并更大限度地利用 AI 模型。
