NVIDIA 发布 AIPerf：多进程负载客户端替代 GenAI-Perf，用 Qwen3-0.6B 演示静态与泊松两种 LLM 推理基准

AIPerf 是 GenAI-Perf 的指定后继者，且是一次彻底重写：它不再像 GenAI-Perf 那样运行在 Perf Analyzer 之上，而是采用多进程架构——工作进程生成负载、独立的记录处理服务处理结果，并通过 ZMQ 协调。 原文将这一架构变化描述为 AIPerf 能够扩展的原因，并指出多数基准工具（包括 GenAI-Perf）使用单进程架构，在真实并发或请求速率下会受 GIL 限制。 证据来自原文对架构设计的直接陈述，属于工具设计说明而非对照实验；原文未给出 AIPerf 与 GenAI-Perf 的量化对比数据。

AIPerf 覆盖 15 种以上端点类型（chat、responses、NIM rankings、图像生成等），并支持 ShareGPT 等公开数据集以及 Mooncake、Baseten、WEKA（AgentX）等来源的 trace 回放格式。 原文强调从快速合成冒烟测试到回放生产流量的场景无需更换工具，并称负载形状可控：constant、Poisson、gamma 到达模式、可调突发性、并发与请求速率的渐进爬坡，以及 vLLM/SGLang range-ratio 等合成分布。 证据为原文对功能范围的列举，未附各端点类型或数据集的验证结果。

原文以 vLLM 服务的 Qwen3-0.6B 演示了两条命令：静态基准将输入与输出都固定为 128 token（标准差为 0，并用 min_tokens:128 与 ignore_eos:true 强制输出长度）；泊松基准以平均每秒 10 请求、指数分布到达间隔、输入 512±128、输出 128±32、随机种子 42、共 200 请求运行。 原文指出静态命令复现了常用的固定长度基准，而泊松命令引入突发与间隙、可变 prefill 长度，更接近真实排队；并说明去掉 min_tokens 与 ignore_eos 是刻意放开输出长度约束。 证据为原文给出的完整命令行与参数解释；原文称泊松运行的输入序列长度落在 154 到 818 token 之间，并称该运行指标分布明显宽于静态基线。

AIPerf 报告 TTFT、ITL、请求延迟与输出 token 吞吐四项核心指标，并给出 p25、p50、p75、p90、p95、p99 分位以及最小值、最大值、平均值和标准差；在具备 DCGM 或 pynvml 时还会把 GPU 功耗、利用率和显存占用纳入同一次运行输出。 原文强调分位分解能揭示长尾分布——平均 TTFT 健康但 p99 异常的服务在聚合指标上看似正常却会在生产中失败；并指出延迟尖峰与显存压力事件的关联无需另开一次 profiling 会话。 证据为原文对指标定义与输出内容的说明；原文提到 --streaming 是测量 TTFT 与 ITL 的必要条件，否则服务器会先聚合完整响应再发送。

原文的演示面向在单 GPU 上通过 vLLM 服务 Qwen3-0.6B 的读者，目的是建立可重复的测量循环，而非评测该模型本身；原文明确表示换模型或端点只需改一个 flag。方法适用于需要区分 prefill 与 decode 行为、关注长尾延迟与 GPU 遥测的推理服务团队，并声称同一工具可扩展到多节点 Kubernetes、KV cache 预热、生产 trace 回放、前缀合成、自定义数据集与并发扫描。原文还给出 aarch64 平台注意事项：crick 依赖仅以源码形式发布，需要 C 工具链（Debian/Ubuntu 上的 build-essential，RHEL 上的 Development Tools）。

原文以图 2、图 4、图 5、图 6 呈现静态与泊松两次运行的指标分布，但正文只给出定性描述（泊松运行分布“明显更宽”、TTFT 离散度更大、输入长度 154 到 818 token），未列出具体数值，因此无法从文本复核差异幅度。原文称多进程架构可避免客户端成为瓶颈，但未给出客户端侧资源占用或饱和点的测量。原文列举的 15 种以上端点类型、trace 回放格式与复杂场景（多节点 Kubernetes、KV cache 预热、并发扫描）均未在本文中演示。此外，原文未说明 Qwen3-0.6B 演示所用 GPU 型号、vLLM 版本或 AIPerf 版本，复现时需自行确认环境。