Back to Prompt Library
implementation
Build the application
Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.
Linked challenge: Build a New-Cluster GPU Topology and Bandwidth Acceptance Validator
Format
Code-aware
Lines
93
Sections
11
Linked challenge
Build a New-Cluster GPU Topology and Bandwidth Acceptance Validator
Prompt source
Original prompt text with formatting preserved for inspection.
93 lines
11 sections
No variables
1 code block
## Build
Parse DCGM link telemetry during burn-in. Validate empirical cluster topology against hardware manifests and generate acceptance reports using hosted Claude to identify miswired or underperforming interconnects.
## User
Cluster Infrastructure Hardware Engineer
## Workflow
1. Ingest initial NVLink CRC rates and PCIe bandwidth telemetry from newly racked cluster nodes.
2. Compare empirical communication latency and link matrices against the expected hardware procurement manifest.
3. Query hosted Claude API to synthesize a burn-in acceptance report identifying miswired links.
4. Output a cluster acceptance JSON payload to unblock inventory provisioning or trigger recabling.
## Interface
Terminal CLI and automated JSON report generator for cluster provisioning.
## Data
Synthetic simplified app records of DCGM fabric error logs, PCIe AER records, and JSON hardware procurement manifests.
Starter examples below are synthetic. They are not downloaded records.
## Source
[NVIDIA DCGM exporter](https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/main/README.md)
Uses DCGM exporter telemetry counters to validate NVLink error metrics and PCIe throughput against manifests.
## Tools
pydantic-ai, anthropic-claude, fastapi.
Validates structured multi-GPU topology link matrices and enforces acceptance schema definitions.
Hosted Claude API for burn-in diagnostics; strictly remote API calls.
## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.
## Acceptance
- Identifies specific GPU-to-GPU link pairs failing bandwidth expectations during burn-in.
- Distinguishes between manifest mismatches and physical connector degradation.
- Outputs concrete hardware remediation steps (e.g., recable NVLink topology).
- Produces valid acceptance validation JSON payloads without live restarts.
## Starter Examples
```json
[
{
"input": {
"node_name": "compute-dgx-new-14",
"expected_manifest_bandwidth_gbps": 450,
"gpu_pairs": [
{
"gpu_a": 0,
"gpu_b": 1,
"nvlink_crc_errors": 0,
"bandwidth_gbps": 450
},
{
"gpu_a": 2,
"gpu_b": 3,
"nvlink_crc_errors": 184,
"bandwidth_gbps": 75.2
}
]
},
"expected_output": {
"node_status": "FAILED_BURN_IN",
"impacted_link": "GPU_2_TO_GPU_3",
"error_type": "BANDWIDTH_MISMATCH",
"technician_repair_plan": [
"Inspect physical NVLink mezzanine connector between socket 2 and socket 3.",
"Clean optical pins and reseat link module prior to re-running burn-in suite."
],
"severity": "BLOCKING"
}
},
{
"input": {
"node_name": "compute-dgx-new-15",
"expected_manifest_bandwidth_gbps": 450,
"gpu_pairs": [
{
"gpu_a": 0,
"gpu_b": 1,
"nvlink_crc_errors": 0,
"bandwidth_gbps": 450
},
{
"gpu_a": 1,
"gpu_b": 2,
"nvlink_crc_errors": 0,
"bandwidth_gbps": 450
}
]
},
"expected_output": {
"node_status": "ACCEPTED",
"impacted_link": null,
"error_type": "NONE",
"technician_repair_plan": [],
"severity": "NONE"
}
}
]
```
## Safety
Read-only telemetry and manifest analysis. Does not perform physical power-cycling.
Use mock external writes. Require human review before any real deployment.Adaptation plan
Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.
Keep stable
Hold the task contract and output shape stable so generated implementations remain comparable.
Tune next
Update libraries, interfaces, and environment assumptions to match the stack you actually run.
Verify after
Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.