Nvshmem Collect Performance Data
NVIDIAOfficialCreated by NVIDIA NVSHMEM Team
- Skill
- Workflow
- Software development
- Apache-2.0
- Medium risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a standardized procedure for collecting NVSHMEM performance metrics, including bandwidth and latency tests. It captures essential system, topology, and configuration evidence to create a portable, reproducible performance report. The skill is designed to be run within an active compute allocation, ensuring that performance data is gathered under controlled, representative conditions without requiring privileged access or system modifications.
What it does
- Collects system, GPU, network, and topology evidence using a bundled script.
- Executes selected NVSHMEM performance tests with specified placements.
- Validates benchmark results for correctness and completeness.
- Generates a structured, portable Markdown report containing all performance data and environment context.
- Provides a mechanism to stage commands for users when direct compute-node access is unavailable.
When to use it
- When you need to perform a performance sanity check on an NVSHMEM installation.
- When you need to gather reproducible performance evidence for troubleshooting or baseline comparison.
- When you require a standardized report of NVSHMEM put/get bandwidth and latency.
- When you need to document system and topology configuration alongside benchmark results.
Advantages
- Ensures reproducible and consistent performance data collection.
- Captures comprehensive environment context alongside raw metrics.
- Operates in a read-only, unprivileged manner.
- Produces a portable, self-contained artifact package.
- Supports both direct execution and staged command generation for restricted environments.
Usage examples
- “Run the recommended device sanity suite with two PEs on the allocated node.”
- The agent executes the collector script, runs the four standard device put/get tests, and generates a comprehensive performance report.
- “I need a two-node put-latency baseline but cannot grant you cluster access.”
- The agent provides the necessary collector script and benchmark commands for the user to run, then packages the returned output into a report.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/nvshmem-collect-performance-data/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip nvshmem-collect-performance-data.zip -d .agents/skills
Documentation by NVIDIA NVSHMEM Team
NVSHMEM Performance Data Collection
Purpose
Collect reproducible NVSHMEM performance evidence, with the four device put/get bandwidth and latency tests as the recommended sanity suite. Preserve the system, topology, placement, initialization, transport, commands, raw output, and tuning configuration in a portable Markdown report without inventing system-specific acceptance thresholds.
Requirements
Use an allocated compute node with the target GPUs visible; never collect evidence or run benchmarks on a login node.
Make the target NVSHMEM installation, selected perftest executable, and a known-good launcher/bootstrap path available. Direct target access is optional when a user can run the staged commands and return their complete output.
Provide a writable output parent directory for the artifact package. The bundled collector itself is read-only and writes only to stdout.
Require no API keys, privileged access, package installation, or system-configuration changes.
Inputs
Required
Resolve these values from the request, the target environment, or focused follow-up before benchmark execution:
an explicit test, preset, or suite selection;
the NVSHMEM installation prefix and perftest root;
access to the participating compute nodes, or a user who can run and return the staged commands;
a known-good launcher and bootstrap path;
allocated nodes, total PEs, PEs per node, and local PE-to-GPU placement;
the output parent directory for a new artifact package.
For an unspecified request, require only the suite choice first. Do not collect the remaining execution inputs until the user selects a suite. Do not ask again for values that are already explicit or safely observable.
Optional
exact message-size ranges, datatype, atomic operation, thread-group scope, CUDA graph, mmap, EGM, bidirectional, or other selected-test options;
an exact
NVSHMEM_REMOTE_TRANSPORTexecution override;an installation or source tree containing the selected test's standard
.argsfile;a caller-provided launcher command, binding policy, artifact-directory name, or reporting notes;
an identical matched baseline for range assessment;
raw stdout, stderr, exit statuses, hostname output, and environment evidence from user-run collection when direct execution is unavailable.
Scripts
| Script | Use | Invocation |
|---|---|---|
scripts/collect-performance-environment.sh | Collect read-only NVSHMEM, GPU, network, RDMA, launcher, topology, and allowlisted environment evidence. It writes to stdout and can exit with status 2 after producing useful partial output. | Run on every participating compute node as collect-performance-environment.sh [--prefix PATH]; retain complete output even when it exits nonzero. |
Instructions
Resolve the Request
Classify the request before running a benchmark.
Treat an exact executable, named family, or named preset suite as an explicit selection.
Treat requests such as "run perftests," "check NVSHMEM performance," or "perform a sanity check" as unspecified.
For an unspecified request, read references/perftest-catalog.md, summarize the available families, recommend the default device sanity suite, and require the user to choose one of:
the recommended four-test device sanity suite;
a custom device suite;
a host or feature-specific suite.
Run nothing until the user explicitly selects a choice. After a custom category is chosen, ask only for the exact tests, placement, PE count, and special mode that materially affect the run.
If the user already selected a test or suite, skip the menu and honor that scope.
Use canonical executable names. Do not translate or accept shortened
_latnames.
Assume the standard NVSHMEM perftest set exists. Do not inventory executables or enumerate every argument variant before selection. When a selected executable is missing at launch, report an installation or build problem instead of silently substituting another test.
Default Device Sanity Suite
Use exactly these device point-to-point tests when the user selects the recommended suite:
device/pt-to-pt/shmem_put_bw
device/pt-to-pt/shmem_put_latency
device/pt-to-pt/shmem_get_bw
device/pt-to-pt/shmem_get_latencyRun each test with exactly two PEs. Measure one same-node placement and, when a two-node allocation is already available, one two-node placement with one PE per node. Do not request or create a new allocation merely to add the two-node placement; record it as unavailable.
For a selected non-default test, read its entry in references/perftest-catalog.md. Use two PEs for point-to-point tests unless the benchmark documents another requirement. Require an explicit node count, PE count, PEs per node, and GPU placement for collective, tile, or allocation tests.
Prepare the Target
Resolve these values from the user, environment, or direct inspection:
NVSHMEM installation prefix and perftest root;
launcher and bootstrap path;
allocated nodes and task/GPU capacity;
local PE-to-GPU binding;
selected same-node and two-node placements;
output parent directory.
Resolve PERF_ROOT from an explicit path first, then $NVSHMEM_PREFIX/bin/perftest, then $NVSHMEM_HOME/bin/perftest. Do not search the filesystem for alternate installations. Check only the selected executable paths with test -x.
If the user supplies a remote-transport override, use that exact value for every probe and measured command. Otherwise do not ask for, select, or inject one; preserve the inherited setting or NVSHMEM default. Route transport-recommendation requests to nvshmem-select-remote-transport rather than invoking it automatically.
Prefer a caller-provided, known-good launcher. Otherwise use this order:
srun --overlapinside an active Slurm allocation;nvshmrunwhen available and already configured;mpirunonly after a two-rank launcher and hostname preflight succeeds.
Never run a benchmark on a login node. For a same-node run, prove two ranks start on one hostname and use distinct GPUs. For a two-node run, prove one rank starts on each of two distinct hostnames. Do not call a run inter-node without distinct hostname evidence.
Before each placement probe, retain 00-preflight.command, 00-preflight.stdout, 00-preflight.stderr, and 00-preflight.status in its placement directory. Require every rank to report rank/local rank, hostname, and applicable GPU visibility or binding.
Create a new artifact directory without overwriting prior data:
nvshmem-performance-<UTC timestamp>/
environment/
same-node/
two-node/
commands.md
NVSHMEM_PERFORMANCE_REPORT.mdUse additional placement directories for custom suites when needed. Store stdout and stderr separately for every command and record its exit status.
Collect System Evidence
Collect evidence before benchmarks on every participating compute node. Tell the user that the bundled collector is read-only, then run:
run_script("scripts/collect-performance-environment.sh", "--prefix", "<resolved-prefix>")Use the bundled collector script and pass the already resolved installation with --prefix. Prefer run_script; when it is unavailable, execute that same bundled file with bash. Redirect each node's complete output to environment/<hostname>.txt. Preserve partial output even when the collector exits with status 2.
If direct target access is unavailable, give the user the collector plus the selected launcher preflight and benchmark commands. Ask them to return the complete stdout, stderr, exit statuses, and hostname output. Do not treat login-node evidence as compute-node evidence.
Run the Initialization Probe
Before measured tests, run a minimal device-side probe for every placement using the selected launcher and resolved executable:
NVSHMEM_INFO=1 NVSHMEM_DEBUG=INFO "$PERF_ROOT/device/pt-to-pt/shmem_put_latency" \
-b 4 -e 4 -n 1 -w 1 -t 1 -s threadPlace the launcher before the executable in the actual command. Retain the command, stdout, stderr, and status as 01-init.*, plus successfully initialized transport paths and PE/GPU/NIC selection. Treat runtime debug success messages—not the NVSHMEM_INFO default—as transport proof; mark absent proof incomplete. Mark the placement invalid or incomplete and stop on initialization failure, wrong placement, or mismatch with a supplied remote-transport override. Other initialized paths such as P2P or IBGDA may coexist and are not a mismatch.
Keep NVSHMEM_INFO=1 and NVSHMEM_DEBUG=INFO probe-only. Do not select an HCA, disable P2P, or change a tuning variable merely to make the probe pass.
Run Selected Tests
Use the selected test's standard adjacent .args configuration when available. Look beneath the installation's share/src/perftest tree or an explicitly supplied source tree for the matching relative .args file.
For the default suite, use the first nonempty normal line for each test. For
shmem_put_bw, deterministically use the first nonempty line without--bidirand record its complete scope, CTA-count, and threads-per-CTA configuration.This default-suite rule takes precedence over variant prompting. For custom or non-default suites, explain only relevant semantic variants and require a selection instead of running all variants.
If no
.argsfile is available, inspect the selected executable's--helpand use its built-in defaults unless the user requested specific limits.Use
--repetitions 3when supported. If native repetitions are unavailable, run the identical process three times and retain each raw result.Set
NVSHMEM_MACHINE_READABLE_OUTPUT=1; when a remote-transport override was supplied, set it on every measured command too. Fall back to the human-readable table when the installed version does not emit machine-readable rows.Run benchmarks serially. Do not overlap tests or silently change message-size ranges, datatypes, atomic operations, scopes, CUDA graph mode, mmap mode, or bidirectionality.
Record the fully resolved command before execution. Preserve all other pre-existing NVSHMEM_*, CUDA, provider, launcher, and binding variables. Report inherited, requested, and effective remote-transport values; an explicit request overrides only inherited NVSHMEM_REMOTE_TRANSPORT.
Validate Results
Validate every run before summarizing it:
Require a zero launcher/test exit status.
Confirm the intended node, PE, and GPU placement from hostname and per-rank output.
Confirm the output identifies the selected test or expected metric.
Require at least one nonempty message-size or operation row.
Reject missing, nonnumeric,
NaN, infinite, or nonpositive measured values.Preserve the output units; do not silently convert decimal GB/s to GiB/s.
Confirm three timed repetitions or three separate runs when requested.
Search stdout and stderr for initialization, CUDA, bootstrap, transport, timeout, and launch failures.
Mark a run valid, invalid, or incomplete. Do not discard partial evidence, average incompatible placements, or call a result expected merely because it is positive.
Write the Handoff Report
Copy assets/performance-report-template.md to the artifact directory as NVSHMEM_PERFORMANCE_REPORT.md, replace every placeholder, and remove unused optional sections.
For bandwidth tests, report the peak bandwidth and the value at the largest measured message size, then retain the complete curve. For latency tests, report the smallest-message latency and retain the complete curve. Preserve native metrics for atomics, collectives, allocation, and other tests.
Use relative artifact paths in the report so the entire directory can be submitted as one package. Include:
collection completeness and missing placements;
selected tests and rationale;
system, software, GPU, NIC, and topology evidence;
launcher-preflight hostname/binding artifacts and runtime initialization proof;
inherited, requested, effective, and successfully initialized transport paths plus PE/GPU/NIC evidence;
summary and full result tables;
exact commands and exit statuses;
validation findings, anomalies, assumptions, and raw-log links.
If no matched baseline is supplied, write Range assessment: not performed (no matched baseline supplied). Do not estimate expected ranges from nominal link speed. If a matched baseline is supplied, compare only identical benchmark, message size, placement, PE count, transport, and relevant options, and state any remaining comparability limits.
Output Format
Return the artifact directory and a concise Markdown handoff. Copy the report template to NVSHMEM_PERFORMANCE_REPORT.md and include these fields in order:
| Field | Required content |
|---|---|
| Collection status | complete, incomplete, or invalid, plus unavailable placements and the reason. |
| Scope and placement | Selected tests, rationale, node count, total PEs, PEs per node, and PE-to-GPU binding. |
| Environment evidence | Relative paths to per-node collector output, NVSHMEM version, GPU/NIC topology, launcher, remote-transport configuration, and runtime initialization proof. |
| Results | A summary table, complete native-unit result curves, three-repetition evidence, and paths to stdout, stderr, commands, and exit statuses. |
| Validation and comparison | Per-run validity, anomalies, assumptions, and either a matched-baseline comparison or Range assessment: not performed (no matched baseline supplied). |
Use relative paths so the package remains portable. Do not issue an expected or regressed verdict without a matched baseline.
Examples
Collect the recommended suite after the user selects it:
User: Run the recommended device sanity suite with two PEs on the allocated node.
Action: Use run_script("scripts/collect-performance-environment.sh", "--prefix", "<resolved-prefix>"), then collect the four device put/get bandwidth and latency tests with the resolved two-PE placement.
Output: Return the artifact-directory path and NVSHMEM_PERFORMANCE_REPORT.md with the same-node results.Stage commands when direct compute-node access is unavailable:
User: I need a two-node put-latency baseline but cannot grant you cluster access.
Action: Request the selected placement and output directory, then provide the collector, launcher preflight, initialization probe, and benchmark commands for the user to run.
Output: Package the returned stdout, stderr, exit statuses, and hostname evidence; mark missing data incomplete instead of estimating it.Troubleshooting
| Error or condition | Cause | Solution |
|---|---|---|
| The collector exits with status 2. | One or more evidence sources are unavailable, but the script produced partial output. | Retain the complete output, record the missing evidence, and rerun on the allocated target compute node if possible. |
| Initialization probe fails or ranks use the wrong GPUs. | The launcher, bootstrap path, or PE-to-GPU binding is not valid for the placement. | Stop that placement, capture stdout and stderr, correct the known-good launcher or binding, and rerun the probe before measuring. |
A selected perftest executable or .args file is missing. | The resolved installation or source tree is incomplete. | Report the installation or build problem; do not substitute a different test or invent command-line options. |
| A result cannot be compared to a baseline. | Benchmark, placement, PE count, transport, or options differ. | Preserve both datasets and report the comparability limit; do not label the result expected or regressed. |
Limitations
Treat system evidence as a snapshot of the participating compute nodes and active allocation. It cannot establish site-wide consistency, platform policy, or an untested network path.
Assume the standard NVSHMEM perftest set is available; do not inventory it. Treat a selected executable missing at launch as an installation or build problem.
Stage commands for the user when direct compute-node access is unavailable. Do not treat login-node evidence as compute-node evidence.
Keep collection within the existing allocation and software environment; do not install dependencies, allocate nodes, or make driver, fabric, or system changes.
Keep collection read-only and unprivileged. Collect only the allowlisted performance and launcher variables emitted by the bundled script; never expose unrelated environment variables or secrets.
Never overwrite an existing artifact directory or raw log, replace a failed device test with a host analogue, or represent a same-node result as two-node evidence.
Compare results only when the benchmark, message size, placement, PE count, transport, and relevant options match. Without a matched baseline, state that range assessment was not performed and do not issue an expected or regressed verdict.
<!-- ci trigger -->
Files
- ATTRIBUTION.mdAdded by AutoGineer967 B
- BENCHMARK.md9.4 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md17.1 KiB
- assets/performance-report-template.md4.1 KiB
- evals/evals.json12.7 KiB
- references/perftest-catalog.md8.4 KiB
- scripts/collect-performance-environment.shScript12.7 KiB
- skill-card.md3.8 KiB
- skill.oms.sig5.2 KiB
evals/evals.json
{
"skill_name": "nvshmem-collect-performance-data",
"evals": [
{
"id": "nvshmem-collect-performance-data-001",
"prompt": "Please run some NVSHMEM perftests and tell me whether performance looks sane. I have not chosen any particular benchmark yet.",
"expected_output": "The agent summarizes the standard perftest families, recommends the four-test device sanity suite, presents the three suite choices, and waits for an explicit selection without collecting the system or running a test.",
"assertions": [
"The agent offers the recommended default device sanity suite, a custom device suite, and a host or feature-specific suite",
"The agent briefly explains device RMA, scalar/store, atomics, completion/signaling, collectives, tile collectives, TMA, host/on-stream, allocation, and special-mode possibilities without enumerating every option variant",
"The agent does not scan for installed perftests, collect system evidence, inspect executable help, or run a benchmark before the user selects a suite",
"The agent does not claim an expected performance range"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-002",
"prompt": "I explicitly choose the recommended NVSHMEM device sanity suite. The perftests are installed under /opt/nvshmem/bin/perftest, and I have an active two-node Slurm allocation with two GPUs per node. Use srun and prepare the collection plan before running anything.",
"expected_output": "The agent resolves exactly the four canonical device point-to-point tests, plans two-PE same-node and two-node placements, and stages environment collection, launcher preflight, information probes, serial repetitions, artifacts, validation, and reporting.",
"assertions": [
"The selected executables are exactly device/pt-to-pt/shmem_put_bw, shmem_put_latency, shmem_get_bw, and shmem_get_latency; shmem_put_bw uses the first nonempty .args line without --bidir and records its full scope, CTA, and thread configuration",
"The agent uses two PEs, keeps same-node and one-PE-per-node two-node results separate, and does not use shortened _lat aliases",
"The plan collects system evidence with the resolved prefix on every participating node and runs an NVSHMEM_INFO=1 NVSHMEM_DEBUG=INFO shmem_put_latency probe before measured tests for each placement",
"The plan uses srun --overlap, retains per-rank launcher-preflight hostname and GPU-binding artifacts, and uses serial execution, machine-readable output, three repetitions, timestamped artifacts, and exact command/stdout/stderr/status capture",
"The agent does not inventory unrelated perftest executables"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-003",
"prompt": "Collect device atomic-add latency for 64-bit integers between two PEs on one node. Use the installed standard NVSHMEM perftest and preserve my existing transport settings.",
"expected_output": "The agent skips the generic menu, selects the canonical device atomic latency benchmark, records the requested operation and datatype, and asks only for unresolved placement or launcher details before execution.",
"assertions": [
"The agent selects device/pt-to-pt/shmem_atomic_latency and does not add the four-test default suite",
"The exact atomic operation and 64-bit integer datatype remain explicit in commands and reporting",
"The agent consults only the selected test's standard .args or --help when resolving its requested options and does not perform a preliminary inventory pass",
"The agent does not ask for or inject a remote transport override and preserves the user's transport and tuning environment"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-004",
"prompt": "Run the device all-to-all latency perftest for me. I have not decided how many nodes or PEs to use.",
"expected_output": "The agent selects the device collective family but withholds execution until the user supplies an explicit node, PE, PEs-per-node, and GPU layout.",
"assertions": [
"The agent identifies device/coll/alltoall_latency without showing the generic suite menu",
"The agent requests node count, total PEs, PEs per node, and GPU placement before generating a final launch",
"The agent does not inherit the two-PE point-to-point default or infer a production scale",
"No benchmark is run while the collective layout is unresolved"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-005",
"prompt": "I specifically want the device TMA put-bandwidth perftest on our H100 NVLink node. Help me collect it with two PEs.",
"expected_output": "The agent selects shmem_put_tma_bw directly, checks the relevant NVSHMEM build, GPU, CUDA, and option support, and keeps the TMA result distinct from ordinary put bandwidth.",
"assertions": [
"The selected executable is device/pt-to-pt/shmem_put_tma_bw",
"The agent verifies TMA capability using supplied or collected evidence without scanning the complete perftest inventory",
"The agent does not silently add device/pt-to-pt/shmem_put_bw or the default four-test suite",
"The report plan labels the result as the TMA path and records the exact options and placement"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-006",
"prompt": "Measure CUDA-graph-captured reduction-on-stream latency across two nodes. We will use 16 PEs, eight PEs per node, one PE per GPU, float32 sum, and our existing srun launcher.",
"expected_output": "The agent selects the host on-stream reduction benchmark, honors the explicit scale and reduction choices, and resolves only the selected test's documented CUDA graph mode before collection.",
"assertions": [
"The agent selects host/coll/reduction_on_stream and does not substitute a device collective",
"The plan records two nodes, 16 total PEs, eight PEs per node, GPU placement, float32, and sum",
"CUDA graph mode is enabled only if the selected .args file or executable help documents it",
"The agent does not enumerate unrelated special modes or inventory the perftest tree"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-007",
"prompt": "Run the standard perftest-mmap-sanity.list preset in this allocation and package the results. Do not replace it with the default sanity suite.",
"expected_output": "The agent honors the explicitly selected mmap preset, records the list path and mapped-memory modes, and does not prepend a benchmark-family menu or substitute the four device tests.",
"assertions": [
"The agent selects perftest-mmap-sanity.list exactly as requested",
"The plan preserves and reports buffer type, handle mode, placement, and every exact command from the selected preset",
"The agent does not describe the mmap preset as the four-test device sanity suite",
"The agent validates each selected run independently and retains partial evidence for failures"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-008",
"prompt": "I choose the recommended four-test device suite, but my current Slurm allocation has only one node with two GPUs. Run what is available and do not request another allocation.",
"expected_output": "The agent collects and runs the two-PE same-node placement only, records the two-node placement as unavailable, and does not allocate resources or represent the local result as inter-node evidence.",
"assertions": [
"The agent uses the four canonical device tests with two PEs on the allocated node",
"The agent does not call salloc, sbatch, or otherwise request a second node",
"The report marks two-node collection incomplete or unavailable and never claims that the remote path was measured",
"The same-node run still includes prefix-aware system collection, retained launcher preflight, an NVSHMEM_INFO=1 NVSHMEM_DEBUG=INFO probe with runtime transport proof, repetitions, and raw artifacts"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-009",
"prompt": "The same-node information probe failed with exit status 1 and stderr 'nvshmem_init failed: bootstrap initialization error'. Please continue with the selected bandwidth tests anyway and summarize whatever they print.",
"expected_output": "The agent refuses to run measured tests for the failed placement, preserves the probe evidence, marks the placement invalid or incomplete, and reports the initialization failure without fabricating performance results.",
"assertions": [
"The agent stops the placement after the failed NVSHMEM_INFO probe",
"The exact command, stdout, stderr, and exit status are retained in the artifact/report plan",
"No measured bandwidth or latency row from that placement is accepted as valid",
"The agent does not force or substitute a transport, select an HCA, disable P2P, or change tuning variables merely to make initialization pass"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-010",
"prompt": "I selected device/pt-to-pt/shmem_get_latency, but /opt/nvshmem/bin/perftest/device/pt-to-pt/shmem_get_latency is missing when you check it. Find another latency test with a similar name and use that instead.",
"expected_output": "The agent reports the selected executable as missing from the installation or build and does not search for, alias, or substitute another test.",
"assertions": [
"The agent checks only the selected executable path and reports an installation/build problem",
"The agent does not search the filesystem or inventory other perftest executables",
"The agent does not substitute a host latency test, put latency test, or shortened shmem_get_lat alias",
"The run is marked incomplete and the missing-executable evidence is retained"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-011",
"prompt": "Package these successful shmem_put_bw outputs into the NVSHMEM Markdown report. Statistical row: '&&&& PERF_STATS shmem_put_bw___thread___size__8___bandwidth +GB/s mean=1.25 stddev=0.05 min=1.20 max=1.30 repetitions=3'. Legacy row: '&&&& PERF shmem_put_bw___thread___size__1048576___bandwidth 82.5 +GB/s'. No matched baseline is available.",
"expected_output": "The agent validates both machine-readable forms, preserves their native units and repetition metadata, summarizes peak and largest-message bandwidth, retains the full size table, and states that range assessment was not performed.",
"assertions": [
"The agent parses the encoded test, scope, byte size, bandwidth metric, and GB/s units from both rows",
"The plus sign before GB/s is not interpreted as an uncertainty value",
"The report includes peak bandwidth and the largest-message value while retaining both complete rows and their provenance",
"The report states 'Range assessment: not performed (no matched baseline supplied)' and does not estimate an expected value from link speed"
],
"expected_skill": "nvshmem-collect-performance-data",
"expected_script": "None"
},
{
"id": "nvshmem-collect-performance-data-012",
"prompt": "How can I profile an ordinary CUDA matrix-multiplication kernel with Nsight Compute? The application does not use NVSHMEM and I am not asking for communication benchmarks.",
"expected_output": "The agent recognizes that the request is unrelated to NVSHMEM performance data collection and answers without invoking this skill.",
"assertions": [
"The agent does not invoke nvshmem-collect-performance-data",
"The agent does not present the NVSHMEM perftest-family menu or system collector",
"The response stays focused on ordinary CUDA kernel profiling"
],
"expected_skill": null,
"expected_script": null
}
]
}
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an API key, Needs Node.js
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- NVIDIA NVSHMEM Team
- Publisher
- NVIDIA (Official)
- Source
- NVIDIA/skills · skills/nvshmem-collect-performance-data · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by NVIDIA NVSHMEM Team or NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nvshmem-collect-performance-data.zip