NVIDIA发布AIPerf：GenAI-Perf的继任者，多进程架构解决LLM推理基准测试客户端瓶颈
AIPerf是GenAI-Perf的官方继任者，从零重写，采用多进程架构和ZMQ协调，支持15种以上端点类型、ShareGPT等公开数据集及Poisson/gamma等到达模式，避免客户端成为压测瓶颈。
AI解读：NVIDIA发布了AIPerf，定位为GenAI-Perf的正式继任者，从底层重写。核心变化是不再运行在Perf Analyzer之上，而是采用多进程架构：工作进程产生负载，独立记录处理器服务处理结果，通过ZMQ协调。NVIDIA称这一设计能避免客户端在真实并发或请求速率下成为瓶颈。
对做LLM服务压测的团队来说，AIPerf解决的是测量可信度问题。单进程工具受Python GIL限制，并发一高结果就不可信；AIPerf把负载生成和结果处理拆开，让被测服务器先成为瓶颈，而不是压测工具本身。
功能上支持15种以上端点类型（聊天、响应、NIM排序、图像生成等），可直接回放Mooncake、Baseten、WEKA（AgentX）的trace格式，也内置ShareGPT等公开数据集。负载形态支持恒定、Poisson和gamma到达模式，可调突发性，支持并发和请求速率的渐变爬坡，以及vLLM/SGLang的range-ratio合成分布。
NVIDIA用Qwen3-0.6B加vLLM做了两个示例：第一个固定128输入和128输出token的静态基准，需配合min_tokens和ignore_eos才能确保输出足量；第二个改为Poisson到达、平均每秒10个请求、输入512±128、输出128±32，随机种子固定为42。两次运行对比显示Poisson场景下TTFT分布明显更宽，因为并发请求争抢GPU且prefill长度不一。
AIPerf输出TTFT、ITL、请求延迟和输出token吞吐四个核心指标，均附带p25到p99百分位、最小最大平均值和标准差。在有DCGM或pynvml时还能同run采集GPU功耗、利用率和显存。
安装可通过uv工具完成，aarch64平台需注意crick依赖为源码形式，需要C工具链。文档和仓库是获取新特性的主要渠道。
NVIDIA发布了AIPerf，并将其定位为GenAI-Perf的正式继任者。AIPerf是一次从零开始的重写，也是与旧架构的彻底切割——它不再运行在Perf Analyzer之上，NVIDIA称这正是AIPerf能够扩展的原因。
根据NVIDIA技术博客，AIPerf采用多进程架构：工作进程生成负载，独立的记录处理器服务处理结果，各部分通过ZMQ协调。NVIDIA表示，这一结构允许更准确地基准测试服务器，因为它防止AIPerf自身成为客户端侧瓶颈。相比之下，GenAI-Perf等多数基准工具使用单进程架构，在真实并发或请求速率下会受GIL限制。
功能方面，AIPerf支持15种以上端点类型，包括聊天、响应、NIM排序和图像生成等，并支持ShareGPT等公开数据集以及来自Mooncake、Baseten、WEKA（AgentX）等来源的trace回放格式。负载形态支持恒定、Poisson和gamma到达模式，可调突发性，支持并发和请求速率的渐变爬坡，以及包括vLLM/SGLang range-ratio在内的合成分布，用于可变ISL/OSL。
静态基准示例：Qwen3-0.6B + vLLM
NVIDIA的演示使用通过vLLM服务的Qwen3-0.6B。博客说明模型选择是有意为之：小到可以在单GPU上运行，快到可以反复迭代而无需等待。重点不是专门基准测试Qwen3-0.6B，而是建立测量循环；一旦建立，换成其他模型或端点只是一个flag的改动。
启动服务器需拉取并运行vLLM容器，启用qwen3 reasoning parser。安装AIPerf可用uv tool install aiperf，或在虚拟环境中执行uv pip install aiperf。博客提醒，在aarch64平台上，crick依赖以仅源码形式提供，需要C工具链（Debian/Ubuntu上的build-essential，RHEL上的Development Tools）；如果安装卡在该包上，原因就在这里。
静态基准命令的核心flag值得注意：--synthetic-input-tokens-stddev 0和--output-tokens-stddev 0把工作负载固定为每请求恰好128输入和128输出token；--extra-inputs min_tokens:128和--extra-inputs ignore_eos:true告诉模型实际生成128个token而不是提前停止——否则输出token数只是建议，模型自然结束时可能远低于目标OSL，导致吞吐数字偏低且跨运行不可复现。--streaming在需要测量TTFT和ITL时不是可选项：不开启流式，服务器会在发送前批量处理完整响应，就没有首token或解码token事件可测。
AIPerf报告哪些指标
运行完成后，AIPerf将指标表打印到控制台，并将完整结果写入CSV和JSON。四个核心指标是：TTFT（从请求发出到收到首token的时间，交互场景的主要延迟信号）、ITL（生成期间连续token之间的时间，ITL高意味着解码阶段吃力，即使TTFT看起来健康）、请求延迟（完整响应的端到端时间，合并prefill和decode成本）、输出token吞吐（所有并发请求每秒生成的token数，容量规划的主要吞吐信号）。
以上每项指标都以百分位（p25、p50、p75、p90、p95、p99）以及最小值、最大值、平均值和标准差报告。NVIDIA解释说，这些分布很重要，因为可以突出长尾分布：一台均值TTFT健康但p99异常的服务器在聚合指标上看起来没问题，却会在生产环境中失败。
如果有DCGM或pynvml可用，AIPerf还会在同一次运行输出中拉取GPU功耗、利用率和内存消耗。将延迟尖峰与内存压力事件关联不需要单独的性能分析会话，遥测数据已经在其中。
动态流量模式：Poisson到达与可变长度
第二个示例引入可变性：--arrival-pattern poisson配合--request-rate 10表示请求平均每秒到达10个，到达间隔从指数分布中抽取，服务器经历突发和空隙。--synthetic-input-tokens-stddev 128在512 token均值附近引入方差，产生长短混合的提示；--output-tokens-stddev 32在输出侧增加方差。该命令中去掉了min_tokens和ignore_eos，博客称这是故意释放约束，让输出分布可变。--random-seed 42让Poisson时序和合成长度抽样可复现，重跑同一命令产生相同的请求序列。
对比两次运行的TTFT，Poisson运行的分布明显更宽。博客解释原因：更多请求同时争夺GPU访问，prefill长度各不相同，prefill和decode操作重叠。单并发场景是一个理想化案例，一次运行一个请求，呈现尽可能低的TTFT，代价是吞吐。在输入长度直方图中，输入序列长度在154到818 token之间，围绕512均值分布。
NVIDIA在文末致谢了外部贡献者，包括AWS的Loki Ravi、Dan Ferguson和Sheng Moua（持续协作、跨公司验证及推动标准化到AIPerf）、Coreweave的Aaron Batilo（Weights & Biases导出器、接受长度投机解码数据集，以及并发下sweep/credit-dispatch可靠性加固）、Baseten的Shounak Ray（Baseten trace回放支持）和Michael Feil（更快的trace加载和会话粘性头），以及Pinterest的Cristian Lopez（DAG基准测试方法学协作）。
- AIPerf支持15种以上端点类型：聊天、响应、NIM排序、图像生成等。
- 支持公开数据集：ShareGPT，以及Mooncake、Baseten、WEKA（AgentX）等trace回放格式。
- 负载形态：恒定、Poisson和gamma到达模式，可调突发性，支持渐变爬坡。
- 合成分布：包括vLLM/SGLang range-ratio，用于可变ISL/OSL。
- 指标输出：TTFT、ITL、请求延迟、输出token吞吐，附带p25至p99百分位、最小值、最大值、平均值、标准差。
- GPU遥测：有DCGM或pynvml时，同run采集功耗、利用率、内存消耗。
- 安装注意：aarch64平台crick依赖为源码形式，需要C工具链。