你正在系统上部署一个模型。服务启动了，提示词也得到了响应。现在有个难题：这速度到底够不够快？
你的第一反应可能是发送curl命令、手写一个asyncio脚本，或者随手写一个一次性的负载生成器。这些做法都存在同样的问题：单进程性能有限、Python的GIL限制了并发能力，或者测出来的数据只是和你自己搭建的参照物比较而来。无论哪种方式，你最终得到的结果都难以完全信任，而且配套的工具一旦需求变化就得重写。
你真正需要的是一个负载客户端：既能让真实服务器达到饱和而不成为瓶颈本身，又能产出可直接使用的结果，配置时间只需五分钟而不是五小时。这正是英伟达AIPerf要解决的问题。
AIPerf有何不同
AIPerf是GenAI-Perf的官方继任者，是一次从零开始的重写。这些设计选择，源自大规模运行大语言模型基准测试所积累的经验教训：
与旧架构彻底切割。AIPerf不再像GenAI-Perf那样构建在Perf Analyzer之上。这是一次彻底的架构革新，也正因如此AIPerf才能实现如此规模的扩展能力。如果你正在迁移现有工作流，迁移指南涵盖了关键的差异点。
客户端本身不该成为瓶颈。包括GenAI-Perf在内的大多数基准测试工具都采用单进程架构，在真实并发或请求速率下会受限于GIL。AIPerf是一个多进程系统：工作进程负责生成负载，独立的记录处理服务负责处理结果，所有环节通过ZMQ协调。这种结构能够避免AIPerf自身成为客户端侧的瓶颈，从而实现更准确的服务器基准测试。
覆盖你实际运行的各种工作负载。AIPerf支持15种以上的端点类型：聊天、响应、NIM排序、图像生成等等——同时还支持ShareGPT等公开数据集，以及来自Mooncake、Baseten、WEKA（AgentX）等平台的流量回放格式。无论你是要做一次快速的合成压测，还是要回放捕获到的生产流量，都不需要更换工具。
负载形态由你自己掌控。AIPerf支持恒定、泊松和伽马到达模式，并可调节突发程度，支持并发数与请求速率的渐进爬升，还支持包括vLLM/SGLang范围比率的合成分布，用于处理可变的输入序列长度/输出序列长度。你掌控的不仅是负载的量，还有负载的形态。
你的第一次基准测试：在vLLM上进行合成ISL/OSL测试
在本次演示中，我们将使用通过vLLM部署的Qwen3-0.6B模型。这个模型选择是刻意为之：它小到可以在单张GPU上运行，速度也足够快，无需长时间等待即可迭代。这里的重点不是专门针对Qwen3-0.6B做基准测试，而是建立起整套测量流程。一旦掌握了这个流程，换成其他模型或端点只需改动一个参数即可。
启动服务器
拉取并启动vLLM，同时启用推理解析器：
docker pull vllm/vllm-openai:latest
docker run --gpus all -p 8000:8000 -e HF_TOKEN vllm/vllm-openai:latest \
--model Qwen/Qwen3-0.6B \
--reasoning-parser qwen3 \
--host 0.0.0.0 --port 8000
安装AIPerf
我们可以使用uv安装一个集中版本：
uv tool install aiperf
或者创建虚拟环境：
uv venv venv
source venv/bin/activate
uv pip install aiperf
有一点平台注意事项：在aarch64架构上，crick依赖以源码形式发布，需要C编译工具链（Debian/Ubuntu上是build-essential，RHEL上是Development Tools）。如果安装卡在这个包上，原因就在这里。
运行基准测试
服务器启动、AIPerf安装完成后，我们现在可以运行第一次性能测试：
aiperf profile \
--model Qwen/Qwen3-0.6B \
--endpoint-type chat \
--streaming \
--url localhost:8000 \
--synthetic-input-tokens-mean 128 \
--synthetic-input-tokens-stddev 0 \
--output-tokens-mean 128 \
--output-tokens-stddev 0 \
--extra-inputs min_tokens:128 \
--extra-inputs ignore_eos:true
这里有几个参数发挥的作用比表面看起来更大：
--synthetic-input-tokens-stddev 0 和 --output-tokens-stddev 0 将工作负载固定为每个请求恰好128个输入Token和128个输出Token。这重现了一种常用的静态基准测试方式，即保持请求长度和输出长度恒定。
--extra-inputs min_tokens:128 和 --extra-inputs ignore_eos:true 强制模型确实生成128个Token，而不是提前停止。如果没有这两个参数，输出Token数量只是一个建议值——模型会在自然完成时就停止，这可能远远达不到你设定的目标输出序列长度。这样一来，吞吐量数据会比实际应有的水平偏低，而且在多次运行之间也无法复现。
--streaming如果你想测量首Token时间和Token间延迟，这个参数是必须的。没有流式输出，服务器会先攒完整个响应再发送，这样就没有首Token或解码Token事件可供测量。
你将看到什么
我们会在下一节讲解如何解读这些数据。目前，先注意下图2所示输出的形态：按百分位划分的延迟、以每秒Token数衡量的吞吐量，以及请求级别的统计数据，全部集中呈现在一处。这就是你后续对比一切结果的基线。
解读数据：AIPerf呈现的内容
一次运行完成后，AIPerf会在控制台打印指标表格，并将完整结果写入CSV和JSON文件。以下是你将看到的内容。
核心四项指标：
首Token时间（TTFT）——从请求发出到收到第一个Token所经过的时间。这是交互式应用场景中最主要的延迟信号。
Token间延迟（ITL）——生成过程中连续Token之间的时间间隔。即使首Token时间看起来正常，较高的Token间延迟也意味着解码阶段存在困难。
请求延迟——完整响应的端到端耗时，将预填充和解码成本合并为一个数值。
输出Token吞吐量——所有并发请求中每秒生成的Token数，这是产能规划中最主要的吞吐量信号。
关于这些指标以及AIPerf报告的其他所有指标的完整定义，请参阅指标参考文档。
获取全貌。以上每项指标都会按百分位（p25、p50、p75、p90、p95、p99）分解报告，并附带最小值、最大值、平均值和标准差。这些分解数据很重要，因为它们能揭示长尾分布：一台平均首Token时间健康、但p99却是异常值的服务器，看起来整体表现不错，但一到生产环境就会出问题。
核心四项之外。如果配备了DCGM或pynvml，AIPerf还会将GPU功耗、利用率和显存占用一并纳入同一份运行输出中。要将延迟突增与显存压力事件关联起来，不需要单独再做一次分析，遥测数据已经就在那里。
进一步探索：配置流量模式
在完成一次静态基准测试后，我们可以开始探索更为动态的场景。上一节展示的是极其固定的流量模式，但真实的推理流量并不遵循静态模式。为了用不那么刻板的场景做基准测试，我们可以利用AIPerf的一些合成工作负载调节参数，为请求引入变化性。
aiperf profile \
--model Qwen/Qwen3-0.6B \
--endpoint-type chat \
--streaming \
--url localhost:8000 \
--request-rate 10 \
--arrival-pattern poisson \
--synthetic-input-tokens-mean 512 \
--synthetic-input-tokens-stddev 128 \
--output-tokens-mean 128 \
--output-tokens-stddev 32 \
--random-seed 42 \
--request-count 200
与上面的静态基准测试相比，有几处变化。
--arrival-pattern poisson 配合 --request-rate 10 表示请求以平均每秒10个的速率到达，到达间隔时间按指数分布抽取。此时服务器经历的是突发和间隙交替，而不是单一用户流，这更接近真实流量下排队现象的实际情况。
--synthetic-input-tokens-stddev 128 在512 Token均值周围引入了方差，产生长短不一的提示词组合。服务器在预填充阶段必须处理长度可变的提示词，而不是完全一致的提示词。
--output-tokens-stddev 32 在输出端加入了方差。注意这次命令中去掉了min_tokens和ignore_eos。在静态基准测试中，这两个参数将输出固定为恰好128个Token，以保持基线的纯净；而这里我们特意放开这个限制，让输出分布可以自然变化。
--random-seed 42 使泊松到达时间和合成长度抽样结果可复现。重新运行这条命令会产生完全相同的请求序列。
--streaming 依然是必需的。没有流式输出，服务器会先攒完整个响应再发送，也就没有首Token或解码Token事件可供测量。
观察这次运行得到的大语言模型指标，其分布明显比静态基线更为宽泛——这符合预期，因为更多请求同时争夺GPU资源，且各请求的预填充长度不尽相同。
观察下图4中的图表，可以看到泊松命令行引入的请求速率大致围绕每秒10个请求波动，但并不完全精确等于该值。这种到达速率模拟了请求到达时间的抖动，而恒定模式则保证固定为每秒10个请求。
在下图5中可以看到，请求长度围绕512 Token均值存在波动，输入序列长度的范围在154到818个Token之间。
对比两次运行的首Token时间可以发现，泊松运行的分布明显更为分散。更多请求同时争夺GPU资源，预填充长度各不相同，预填充和解码操作也相互重叠。而单并发场景是一种理想化情形，一次只处理一个请求，能呈现最低的首Token时间，但代价是牺牲了吞吐量。
在上图6中可以看到，单用户运行的首Token时间波动性远小于泊松实验中变化更多的工作负载。
还有更多值得探索的内容
本次演示只涵盖了基础用法，但AIPerf同样为更复杂的场景而设计。
同一个工具可以处理多节点Kubernetes部署、KV缓存复用预热机制、生产流量回放、前缀合成、自定义数据集，以及跨并发级别的扫描配置。
如果你正在进行大规模分布式推理，请参阅《英伟达Dynamo 1.0如何支撑生产级多节点推理》。
AIPerf代码库中的教程是最快的入门方式。AIPerf代码库及文档是了解新功能和参与贡献的权威参考。
致谢
AIPerf是英伟达与外部贡献者共同协作的成果。特别感谢：Loki Ravi、Dan Ferguson和Sheng Moua（来自AWS）持续的合作、跨公司验证以及推动AIPerf标准化的努力；Aaron Batilo（来自Coreweave）贡献了Weights & Biases导出器、接受长度的推测解码数据集，并加固了并发情况下的扫描/额度调度可靠性；Shounak Ray（来自Baseten）为Baseten流量回放提供了忠实支持；Michael Feil（来自Baseten）实现了更快的流量加载以及会话亲和性头部支持；Cristian Lopez（来自Pinterest）在DAG基准测试方法论上进行了密切合作。我们也感谢Ben Hamm在AIPerf设计、规划和实施过程中提供的产品指导。
Q&A
Q1：AIPerf是什么？它主要用来做什么？
A：AIPerf是英伟达推出的大语言模型推理基准测试工具，是GenAI-Perf的官方继任者。它采用多进程架构，能够在不成为客户端瓶颈的前提下对推理服务器进行准确的性能测试，支持15种以上端点类型和多种流量模式配置。
Q2：AIPerf和GenAI-Perf有什么区别？
A：AIPerf是从零开始重写的工具，不再依赖Perf Analyzer，实现了架构上的彻底革新。它采用多进程系统，工作进程与记录处理服务分离并通过ZMQ协调，从而避免了GenAI-Perf存在的单进程GIL限制问题，能更好地支撑大规模并发测试。
Q3：使用AIPerf做基准测试需要注意哪些关键参数？
A：需要注意streaming参数以测量首Token时间和Token间延迟；min_tokens和ignore_eos参数可确保输出Token数量达到目标值；arrival-pattern和request-rate参数可控制请求到达模式，模拟真实流量的突发和波动特性。
