本文涉及到的详细测试代码和测试步骤放置于：
https://github.com/xinyuwei-david/david-share.git下的：Deep-Learning/
LLM-performance-test，本文中不再赘述代码实现。欢迎给repo点亮Star，您的点赞是作者持续创作的动力。
推荐一个Github上的LLM推理性能测试工具：GuideLLM，可以测试各个模型在TGI和vLLM下的推理性能。
下面测试都是基于：prompt_tokens=512,generated_tokens=128测试的。
先看一下Meta-Llama-3.1-8B-Instruct-quantized.w4a16在A100上用vLLM推理的性能测试结果：
接下来测试microsoft/Phi-3.5-mini-instruct on vLLM：
使用结果
GuideLLM的结果用于优化LLM部署，以提高性能、资源效率和成本效益。通过分析性能指标，可以识别瓶颈，确定最佳请求率，并选择最具成本效益的硬件配置。
例如，如果我们部署一个对延迟敏感的聊天应用程序，我们可能希望优化首次生成标记时间（TTFT）和标记间延迟（ITL）。合理的阈值取决于应用程序要求，但我们可能希望确保首次生成标记时间（TTFT）低于200毫秒，标记间延迟（ITL）低于50毫秒（每秒20次更新）。从上面的示例结果中，我们可以看到模型在每台服务器的请求率为2.37次每秒时，平均可以满足这些要求。如果您希望更高比例的请求满足这些要求，可以使用“按基准的性能统计”部分来确定90%或95%的请求满足这些要求的速率。
如果我们部署一个对吞吐量敏感的摘要应用程序，我们可能希望优化服务器每秒可以处理的最大请求数。在这种情况下，吞吐量基准显示服务器的最大处理能力为每秒4.06次请求。如果我们需要处理更多请求，可以考虑增加服务器数量或升级硬件配置。
配置
GuideLLM提供了多种CLI和环境选项来定制评估，包括设置每次基准运行的持续时间、并发请求数量和请求率。
一些典型的CLI配置包括：
--rate-type：用于基准测试的速率。选项包括sweep、synchronous、throughput、constant和poisson。
--rate-type sweep：（默认）sweep运行服务器性能的全范围，从同步速率开始，然后是吞吐量，最后是介于找到的最小和最大请求率之间的10个恒定速率。
--rate-type synchronous：同步以同步方式逐个运行请求。
--rate-type throughput：吞吐量以尽可能快的速度发送请求。
--rate-type constant：恒定速率以恒定速率运行请求。使用--rate参数指定每秒请求速率。例如，--rate 10或多个速率--rate 10 --rate 20 --rate 30。
--rate-type poisson：泊松从泊松分布中抽取，平均值为指定速率，为运行增加一些现实世界的变化。使用--rate参数指定每秒请求速率。例如，--rate 10或多个速率--rate 10 --rate 20 --rate 30。
--data-type：用于基准测试的数据。选项包括emulated、transformers和file。
--data-type emulated：仿真支持字符串或文件格式的EmulationConfig，用于--data参数生成虚拟数据。至少指定提示标记的数量，并可选地指定输出标记的数量和其他参数以变更长度。例如，--data "prompt_tokens=128"，--data "prompt_tokens=128,generated_tokens=128"，或--data "prompt_tokens=128,prompt_tokens_variance=10"。
--data-type file：文件支持文件路径或URL，用于--data参数。文件应包含编码为CSV、JSONL、TXT或JSON/YAML格式的数据，CSV、JSONL和TXT每行一个提示，JSON/YAML为提示列表。例如，--data "data.txt"，其中data.txt内容为"prompt1\nprompt2\nprompt3"。
--data-type transformers：transformers支持数据集名称或文件路径，用于--data参数。例如，--data "neuralmagic/LLM_compression_calibration"。
--max-seconds：每次基准测试运行的最大秒数。默认是120秒。
--max-requests：每次基准测试运行的最大请求数。
