Hardware Modeling

Benchmark reports are only useful when the hardware target is precise. Metrum Insights separates catalog data, benchmarkable configurations, and concrete instances.

Three Levels

Level	Example	Use
Catalog	NVIDIA B200, AMD MI300X, Intel Gaudi	Normalized vendor and component names.
Server config	8xB200 SXM, 2xEPYC 9654, 2TB RAM, 8xNVMe, 400GbE	Reusable benchmarkable configuration.
Server instance	b200-lab-rack3-node17 or provider instance id	Actual host that heartbeats and runs jobs.

Do not collapse these levels. A "B200" result is not enough when comparing a single-GPU cloud node with an 8-GPU SXM system.

What To Capture

For each server config, capture:

• GPU vendor, model, count, form factor, interconnect, and MIG/partitioning;
• CPU vendor/model/count and core count;
• RAM size and memory channels when relevant;
• disk type, capacity, and mount points used by model cache or datasets;
• NIC model and bandwidth;
• OS, kernel, driver, CUDA/ROCm, container runtime, and framework compatibility;
• power mode, clocks, persistence mode, and thermal constraints when available.

For each server instance, capture:

• hostname and IP/addressing;
• provider, region, instance type, and provider instance id for cloud;
• onboarding token and worker registration state;
• last heartbeat and readiness failures;
• teardown state for paid resources.

Onboarding Flow

1. Create or reuse the server config.
2. Attach GPU, CPU, disk, and NIC details where the catalog supports them.
3. Create the server instance with a unique hostname.
4. Generate bootstrap/onboarding for the instance.
5. Wait for heartbeat and readiness.
6. Run a small smoke benchmark before full sweeps.

API details: Hardware Onboarding.

The concrete API distinction is:

• POST /rpc/create_server_config creates the reusable SUT config.
• POST /rpc/create_server_config_gpu attaches GPU count and model.
• POST /rpc/create_server_config_instance creates the concrete host.
• POST /api/cloud/onboard can create all of the above for managed cloud onboarding and also provision the provider instance.

Use End To End Benchmark API Example for full request bodies.

SUT Evidence

Every serious report should include SUT evidence:

• resolved server config and instance;
• detected GPUs and driver/runtime versions;
• model server command and environment;
• benchmark tool version;
• telemetry availability;
• logs and warnings.

Use SUT CSV and logs from Results And Reports instead of relying on manual notes.