這是大語言模型延遲 – 吞吐量基準測試系列的第三篇博文，旨在指導開發者如何使用 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 -rgcsudo 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-InstructModel Path: NoneTensorRT-LLM Version: 0.21.0rc0Dtype: bfloat16KV Cache Dtype: NoneQuantization: None============================================================ REQUEST DETAILS===========================================================Number of requests: 100Number of concurrent requests: 94.6050Average Input Length (tokens): 128.0000Average Output Length (tokens): 128.0000============================================================ WORLD + RUNTIME INFORMATION===========================================================TP Size: 1PP Size: 1EP Size: NoneMax Runtime Batch Size: 3840Max Runtime Tokens: 7680Scheduling Policy: GUARANTEED_NO_EVICTKV Memory Percentage: 90.00%Issue Rate (req/sec): 1.0526E+15============================================================ PERFORMANCE OVERVIEW===========================================================Request Throughput (req/sec): 86.5373Total Output Throughput (tokens/sec): 11076.7700Total Token Throughput (tokens/sec): 22153.5399Total Latency (ms): 1155.5715Average request latency (ms): 1093.2284Per User Output Throughput [w/ ctx] (tps/user): 117.1544Per GPU Output Throughput (tps/gpu): 11076.7700Average time-to-first-token [TTFT] (ms): 162.6706Average time-per-output-token [TPOT] (ms): 7.3272Per 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.jsonlNumber of Sequences: 100-- Percentiles statistics --------------------------------- Input Output Seq. Length-----------------------------------------------------------MIN: 128.0000 128.0000 256.0000MAX: 128.0000 128.0000 256.0000AVG: 128.0000 128.0000 256.0000P50: 128.0000 128.0000 256.0000P90: 128.0000 128.0000 256.0000P95: 128.0000 128.0000 256.0000P99: 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.5373Total Output Throughput (tokens/sec): 11076.7700Total Token Throughput (tokens/sec): 22153.5399Total Latency (ms): 1155.5715Average request latency (ms): 1093.2284Per User Output Throughput [w/ ctx] (tps/user): 117.1544Per GPU Output Throughput (tps/gpu): 11076.7700Average time-to-first-token [TTFT] (ms): 162.6706Average time-per-output-token [TPOT] (ms): 7.3272Per User Output Speed (tps/user): 137.1475 |
您還會注意到，trtllm-bench 報告令牌的最大數量和批量大小。
============================================================ WORLD + RUNTIME INFORMATION===========================================================TP Size: 1PP Size: 1EP Size: NoneMax Runtime Batch Size: 3840Max 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 模型。
?
