你正在一个系统上部署模型。它启动了，提示词也能得到响应。现在关键问题是：这算快吗？
你的直觉可能会让你发送 curl 命令、手写 asyncio 脚本，或者凭感觉再写一个一次性的负载生成器。所有这些路径都有同样的问题：单进程性能限制、Python 的 GIL 限制并发，或者拿你自己构建的参考标准来测量数字。无论哪种方式，你最终得到的结果都无法完全信任，并且绑定在需求一变就得重写的工具上。
你需要的是一个负载客户端，它能够压满真实服务器而自身不成为瓶颈，产生可据以行动的输出，并且配置只需五分钟，而不是五小时。这就是 NVIDIA AIPerf。
AIPerf 有何不同
AIPerf 是 GenAI-Perf 的指定继任者，并且是从头重写的。其设计选择反映了大规模运行 LLM 基准测试的深刻教训：
与旧架构彻底决裂。AIPerf 不像 GenAI-Perf 那样运行在 Perf Analyzer 之上。这是一次干净的架构决裂，也是 AIPerf 能够如此扩展的原因。如果你要移植现有工作流，迁移指南涵盖了关键差异。客户端不应成为瓶颈。大多数基准测试工具，包括 GenAI-Perf，都使用单进程架构，在真实并发或请求速率下会受 GIL 限制。AIPerf 是一个多进程系统：工作进程生成负载，独立的记录处理服务处理结果，一切通过 ZMQ 协调。这种结构通过防止 AIPerf 成为客户端瓶颈，实现了更准确的服务器基准测试。与你实际运行的工作负载广度相匹配。AIPerf 支持 15 种以上的端点类型：聊天、响应、NIM 排名、图像生成等——以及公共数据集，如 ShareGPT 和来自 Mooncake、Baseten、WEKA (AgentX) 等的 trace 回放格式。无论你是在运行快速的合成冒烟测试，还是回放捕获的生产流量，都不需要不同的工具。你真正能控制的负载形态。AIPerf 支持恒定、泊松和伽马到达模式，可调突发性，并发和请求速率的逐步爬坡，以及合成分布，包括用于可变 ISL/OSL 的 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 个输入和 128 个输出 token。这复现了一个常用的静态基准测试，该测试保持请求和输出长度恒定。
--extra-inputs min_tokens:128
和 --extra-inputs ignore_eos:true
告诉模型实际生成 128 个 token，而不是提前停止。没有这些，输出 token 数量只是一个建议。模型会在自然完成时停止，这可能远低于你的目标 OSL。吞吐量数字最终会低于应有的水平，并且在不同运行之间不可复现。
--streaming
如果你想测量 TTFT 和 ITL，这个标志不是可选的。没有流式传输，服务器会在发送之前批处理完整响应，就没有首 token 或解码 token 事件可供测量。
你会看到什么
图 1. AIPerf 实时仪表板用户界面的示例动画。实时仪表板显示运行进度、指标列表及其分布，以及来自 AIPerf 后端的事件运行日志
我们将在下一节中介绍如何解读这些数字。现在，请注意下面图 2 中输出的形状：按百分位细分的延迟、以每秒 token 数表示的吞吐量，以及请求级统计信息都集中在一处。这就是你将用来比较其他所有内容的基线。
图 2. AIPerf 运行结束时输出指标的示例截图，其中包括各种不同指标的有效、活动和摘要统计信息摘要，以及用于快速查看的百分位细分、复现命令行和输出位置
解读数字：AIPerf 呈现的内容
运行完成后，AIPerf 会将指标表打印到控制台，并将完整结果写入 CSV 和 JSON。以下是你看到的内容。
核心四项：
TTFT（首 Token 时间）——从发送请求到收到第一个 Token 所需的时间。这是交互式用例的主要延迟信号。ITL（Token 间延迟）——生成过程中相邻 Token 之间的时间。ITL 高意味着解码阶段吃力，即使 TTFT 看起来正常。请求延迟——完整响应的端到端时间。将预填充和解码成本合并为一个数字。输出 Token 吞吐量——所有并发请求每秒生成的 Token 数。这是容量规划的主要吞吐量信号。
关于这些指标以及 AIPerf 报告的所有其他指标的完整定义，请参阅指标参考。
了解全貌。 上述每一项都以百分位数细分（p25、p50、p75、p90、p95、p99）报告，同时附有其最小值、最大值、平均值和标准差。这些细分很重要，因为它们可以突出长尾分布；一个平均 TTFT 健康但 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 事件可供测量。
查看本次运行的 LLM 指标，分布明显比静态基线更宽——当更多请求同时竞争 GPU 访问且每个请求的预填充长度不同时，这是预期之中的。
图 3. 泊松到达模式运行的汇总统计示例截图。由于新的流量模式，统计分布与 512/128 静态场景截然不同
查看下方图 4 中的图表，可以看到泊松命令行引入的请求速率以每秒 10 个请求为中心，但并非完全匹配。与保证固定每秒 10 个请求的恒定模式相比，这种到达速率模拟了请求到达时间的抖动。
图 4. 与恒定每秒 10 个请求模式相比，从第一个请求调度开始的报告延迟，显示调度时间的变化以指定的请求速率为中心
您可以在下方图 5 中看到，请求长度在 512 个 token 的均值附近存在变化，输入序列长度范围从 154 到 818 个 token。
图 5. 一张直方图，展示了输入（请求）长度的分布，以所请求的 512 平均 token 数为中心
比较两次运行之间的 TTFT，你可以看到 Poisson 运行的分布要宽得多。更多请求同时争抢 GPU 访问，预填充长度各不相同，预填充和解码操作相互重叠。单并发场景是一种理想化场景，一次只运行一个请求，呈现出尽可能最低的 TTFT，代价是吞吐量。
图 6. 一张直方图，比较单个活跃用户与 Poisson 到达模式 AIPerf 运行之间首 token 时间分布的差异
在上面的图 6 中，你可以看到单用户运行的 TTFT 变异性小于 Poisson 实验中变化大得多的工作负载。
还有更多值得探索
本演练涵盖了基础知识，但 AIPerf 也为更复杂的场景而构建。
同一个工具可处理多节点 Kubernetes 部署、KV 缓存复用预热机制、来自生产流量的 trace 回放、前缀合成、自定义数据集，以及跨并发级别的 sweep 配置。
如果你正在大规模运行分布式推理，请参阅《NVIDIA Dynamo 1.0 如何以生产规模驱动多节点推理》。
AIPerf 仓库中的教程是最快的入门方式。AIPerf 仓库和文档是新功能和贡献的权威参考。
致谢
AIPerf 是 NVIDIA 与外部贡献者协作的成果。感谢以下各位：Loki Ravi、Dan Ferguson 和 Sheng Moua（AWS）持续协作、进行跨公司验证，并致力于推动 AIPerf 的标准化；Aaron Batilo（Coreweave）贡献了 Weights & Biases 导出器、验收长度推测解码数据集，并增强了并发场景下 sweep/credit-dispatch 的可靠性；Shounak Ray（Baseten）提供了忠实的 Baseten trace 回放支持；Michael Feil（Baseten）实现了更快的 trace 加载以及会话亲和性标头。Cristian Lopez（Pinterest）在 DAG 基准测试方法上给予了密切协作。我们感谢 Ben Hamm 在我们设计、规划和实现 AIPerf 期间提供的产品指导。