Configure AIPerf Benchmark
Create a reproducible benchmark that answers the current performance question without changing the deployed candidate.
Freeze semantics only for runs used in the same direct comparison.
Read agent-docs/rules/execution/user-workload.md,
agent-docs/rules/benchmarking/benchmark-isolation.md,
agent-docs/rules/benchmarking/comparison-uncertainty.md,
agent-docs/rules/benchmarking/concurrency-grid.md,
agent-docs/rules/benchmarking/evidence-eligibility.md,
agent-docs/rules/benchmarking/proxy-workload-selection.md,
agent-docs/rules/benchmarking/series-boundaries.md, and
agent-docs/rules/benchmarking/tool-version.md before selecting flags. Also read the user workload, deployment
ledger, and the AIPerf documentation matching the pinned source or runtime. Inspect matching Dynamo recipe perf.yaml
files when available.
Inputs
Require:
- exact user-workload path and SHA256;
- current
DEPLOY_ROOT, applied DGD, deployment ledger, and successful smoke test;
- the baseline-characterization goal or approved candidate's performance question and target operating region; and
- an exact existing benchmark-plan path, SHA256, and series ID only when considering series reuse.
Workflow
- Require a successful smoke test and resolve the in-cluster frontend endpoint, served model, tokenizer, Kubernetes
context, namespace, artifact collection path, and GPU count.
- Decide whether the run is an absolute characterization or a direct comparison. For a comparison, identify the
candidate and reference measurements needed to answer the question.
- Reuse an existing series only when its workload and measurement semantics still answer the question. Otherwise
assign a new series ID and require any comparison reference to be measured under the new plan.
- Select workload input in this order:
- user-provided Mooncake trace;
- exact user-provided ISL/OSL and traffic controls;
- closest Dynamo recipe trace as a
recipe_proxy.
- Validate a selected trace as JSONL. Record its path, SHA256, row count, timestamp range, ISL/OSL distribution,
prefix/hash information, and any rows outside the served context limit. Do not silently filter or clip rows.
- Choose the experiment that best exposes the behavior under investigation:
trace_fidelity: preserve timestamps and fixed-schedule behavior;
static_shape: preserve the exact synthetic ISL/OSL target;
capacity: vary concurrency or request rate over a bounded range.
- Select the objective and metrics needed for the question:
- with target SLOs, use goodput/good-request fraction and the stated attainment constraints;
- without sufficient SLOs, preserve a throughput/latency/error Pareto view.
- Configure one measured run by default. Set the measurement duration to 30 minutes or less. For request-count or
fixed-schedule workloads, choose or validate a count or schedule that is expected to complete within that limit and
set a bounded execution timeout. Stop rather than silently truncate or weaken a workload that cannot fit.
- Do not enable repetitions only to obtain confidence intervals. Configure more than one run only when prior analysis
documents why another run is necessary to resolve a consequential decision and why that value justifies the GPU
cost. Exception: the once-per-series noise-floor pilot (n=3) required by
agent-docs/rules/benchmarking/comparison-uncertainty.md is pre-authorized; it arrives as a repeat_decision: necessary from analyze-aiperf-results whose rationale names the series pilot, and runs as repetitions of one
unchanged configuration. Plans stay immutable; no plan marker is involved.
- Pin the AIPerf runtime version or source commit per
agent-docs/rules/benchmarking/tool-version.md: resolve
the latest stable release (or apply that rule's reference-reproduction/operator-override exceptions) and record
the resolution mechanism, its output, and the date in the plan. Write the immutable series plan and the
run-scoped <DEPLOY_ROOT>/benchmark/aiperf-config.yaml and <DEPLOY_ROOT>/benchmark/perf.yaml.
Benchmark Plan
For a new series, write:
<EXP_ROOT>/inputs/benchmark-plans/<series-id>.json
Use a filesystem-safe series ID. Never overwrite a plan. When reusing a series, use its exact existing path and SHA256
and change only endpoint address, Job identity, namespace, or artifact wiring in the run-scoped files.
The plan must identify:
- performance question, target operating region, and characterization or comparison intent;
- plan ID, benchmark-series ID, and any required reference candidates;
- user-workload path and SHA256;
- workload source:
user_trace, user_static, or recipe_proxy;
- trace path/hash or exact synthetic distribution;
- fixed-schedule, concurrency, request-rate, request-count/duration, warmup, a per-run measurement limit of no more
than 30 minutes, repetitions with a default of one, any approved repeat rationale, confidence policy and level when
needed, and seed;
- endpoint type, streaming behavior, model, and tokenizer;
- target metrics, SLOs, goodput thresholds, and optimization direction;
- AIPerf source commit when available and required runtime version, plus the version-resolution mechanism, its
output, and the resolution date (
agent-docs/rules/benchmarking/tool-version.md);
- proxy rationale and limitations when applicable.
Manifest Rules
perf.yaml is a Kubernetes Job, not the AIPerf-native config.
- Run AIPerf inside the cluster and use the target context and namespace.
- Prefer an existing compatible recipe Job as a starting point. Modify only the run-scoped copy.
- Enforce the 30-minute measurement limit with AIPerf workload controls. Do not rely only on a Kubernetes Job timeout.
- Ensure raw artifacts remain available after Job completion, either on a PVC or in the completed pod until copied.
- Read referenced secret names from existing manifests; never copy secret values into benchmark files.
- Do not embed a local host path that is unavailable to the benchmark pod.
Stop with a concrete configuration blocker when the performance question is missing, no defensible workload can be
selected, a required comparison cannot be made, or the planned run cannot fit within 30 minutes without changing its
semantics.
1---2name: configure-aiperf-benchmark3description: Selects and freezes a question-driven AIPerf workload, objective, load policy, and Kubernetes execution manifest for a successfully deployed Dynamo candidate. Use when a candidate needs performance characterization or a comparable measurement against a reference.4license: Apache-2.05---67# Configure AIPerf Benchmark89<!--10SPDX-FileCopyrightText: Copyright (c) 2025-2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.11SPDX-License-Identifier: Apache-2.012-->1314Create a reproducible benchmark that answers the current performance question without changing the deployed candidate.15Freeze semantics only for runs used in the same direct comparison.1617Read `agent-docs/rules/execution/user-workload.md`,18`agent-docs/rules/benchmarking/benchmark-isolation.md`,19`agent-docs/rules/benchmarking/comparison-uncertainty.md`,20`agent-docs/rules/benchmarking/concurrency-grid.md`,21`agent-docs/rules/benchmarking/evidence-eligibility.md`,22`agent-docs/rules/benchmarking/proxy-workload-selection.md`,23`agent-docs/rules/benchmarking/series-boundaries.md`, and24`agent-docs/rules/benchmarking/tool-version.md` before selecting flags. Also read the user workload, deployment25ledger, and the AIPerf documentation matching the pinned source or runtime. Inspect matching Dynamo recipe `perf.yaml`26files when available.2728## Inputs2930Require:3132- exact user-workload path and SHA256;33- current `DEPLOY_ROOT`, applied DGD, deployment ledger, and successful smoke test;34- the baseline-characterization goal or approved candidate's performance question and target operating region; and35- an exact existing benchmark-plan path, SHA256, and series ID only when considering series reuse.3637## Workflow38391. Require a successful smoke test and resolve the in-cluster frontend endpoint, served model, tokenizer, Kubernetes40 context, namespace, artifact collection path, and GPU count.412. Decide whether the run is an absolute characterization or a direct comparison. For a comparison, identify the42 candidate and reference measurements needed to answer the question.433. Reuse an existing series only when its workload and measurement semantics still answer the question. Otherwise44 assign a new series ID and require any comparison reference to be measured under the new plan.454. Select workload input in this order:46 - user-provided Mooncake trace;47 - exact user-provided ISL/OSL and traffic controls;48 - closest Dynamo recipe trace as a `recipe_proxy`.495. Validate a selected trace as JSONL. Record its path, SHA256, row count, timestamp range, ISL/OSL distribution,50 prefix/hash information, and any rows outside the served context limit. Do not silently filter or clip rows.516. Choose the experiment that best exposes the behavior under investigation:52 - `trace_fidelity`: preserve timestamps and fixed-schedule behavior;53 - `static_shape`: preserve the exact synthetic ISL/OSL target;54 - `capacity`: vary concurrency or request rate over a bounded range.557. Select the objective and metrics needed for the question:56 - with target SLOs, use goodput/good-request fraction and the stated attainment constraints;57 - without sufficient SLOs, preserve a throughput/latency/error Pareto view.588. Configure one measured run by default. Set the measurement duration to 30 minutes or less. For request-count or59 fixed-schedule workloads, choose or validate a count or schedule that is expected to complete within that limit and60 set a bounded execution timeout. Stop rather than silently truncate or weaken a workload that cannot fit.619. Do not enable repetitions only to obtain confidence intervals. Configure more than one run only when prior analysis62 documents why another run is necessary to resolve a consequential decision and why that value justifies the GPU63 cost. Exception: the once-per-series noise-floor pilot (n=3) required by64 `agent-docs/rules/benchmarking/comparison-uncertainty.md` is pre-authorized; it arrives as a `repeat_decision:65 necessary` from `analyze-aiperf-results` whose rationale names the series pilot, and runs as repetitions of one66 unchanged configuration. Plans stay immutable; no plan marker is involved.6710. Pin the AIPerf runtime version or source commit per `agent-docs/rules/benchmarking/tool-version.md`: resolve68 the latest stable release (or apply that rule's reference-reproduction/operator-override exceptions) and record69 the resolution mechanism, its output, and the date in the plan. Write the immutable series plan and the70 run-scoped `<DEPLOY_ROOT>/benchmark/aiperf-config.yaml` and `<DEPLOY_ROOT>/benchmark/perf.yaml`.7172## Benchmark Plan7374For a new series, write:7576```text77<EXP_ROOT>/inputs/benchmark-plans/<series-id>.json78```7980Use a filesystem-safe series ID. Never overwrite a plan. When reusing a series, use its exact existing path and SHA25681and change only endpoint address, Job identity, namespace, or artifact wiring in the run-scoped files.8283The plan must identify:8485- performance question, target operating region, and characterization or comparison intent;86- plan ID, benchmark-series ID, and any required reference candidates;87- user-workload path and SHA256;88- workload source: `user_trace`, `user_static`, or `recipe_proxy`;89- trace path/hash or exact synthetic distribution;90- fixed-schedule, concurrency, request-rate, request-count/duration, warmup, a per-run measurement limit of no more91 than 30 minutes, repetitions with a default of one, any approved repeat rationale, confidence policy and level when92 needed, and seed;93- endpoint type, streaming behavior, model, and tokenizer;94- target metrics, SLOs, goodput thresholds, and optimization direction;95- AIPerf source commit when available and required runtime version, plus the version-resolution mechanism, its96 output, and the resolution date (`agent-docs/rules/benchmarking/tool-version.md`);97- proxy rationale and limitations when applicable.9899100## Manifest Rules101102- `perf.yaml` is a Kubernetes Job, not the AIPerf-native config.103- Run AIPerf inside the cluster and use the target context and namespace.104- Prefer an existing compatible recipe Job as a starting point. Modify only the run-scoped copy.105- Enforce the 30-minute measurement limit with AIPerf workload controls. Do not rely only on a Kubernetes Job timeout.106- Ensure raw artifacts remain available after Job completion, either on a PVC or in the completed pod until copied.107- Read referenced secret names from existing manifests; never copy secret values into benchmark files.108- Do not embed a local host path that is unavailable to the benchmark pod.109110Stop with a concrete configuration blocker when the performance question is missing, no defensible workload can be111selected, a required comparison cannot be made, or the planned run cannot fit within 30 minutes without changing its112semantics.