In this article
Normalize units and labels only after preserving vendor field meaning, device scope and unsupported-query status.
A shared dashboard needs an explicit translation layer
Mixed GPU fleets benefit from common reports, but common labels must not hide different measurements. A field named power, utilization or memory can have a different scope, unit or collection method across tools. Start with a mapping document rather than renaming every AMD field to the nearest familiar NVIDIA label.
The AMD SMI CLI guide describes the management tool and recommends library interfaces for robust telemetry consumers. Preserve the installed tool, library and driver versions. A screenshot-friendly CLI layout is a different integration boundary from a programmatic collector with explicit return statuses.
Define a metric dictionary
For each selected observation, record vendor field, API or command, unit, device scope, update behavior and normalized output name. Specify whether power refers to a supported board or another exposed domain, and whether a utilization value covers the activity relevant to the workload. Do not assume identical meaning from a shared percentage sign.
The AMD SMI function reference gives function-specific behavior and platform support. Keep the query status with the value. A function unavailable on one device must not become a zero that makes that GPU appear cooler, less busy or free of errors compared with a better-observed device.
Preserve device and partition identity
Connect local tool indices to stable inventory information and the host. Retain partition or virtualization context where applicable. Two devices called GPU zero on different machines are not one metric series, and a changed partition view must not inherit a whole-device history merely because the display name remained convenient.
Use a small saved fixture for every supported mapping: successful value, unavailable field, query failure and changed identity. Verify unit conversion separately from collection. If one source returns bytes and another reports a displayed memory unit, the normalized number needs a documented conversion rather than a guessed multiplier based on its apparent magnitude.
Compare observed coverage before performance
Consider an illustrative fleet report with temperature available on one GPU and an unsupported query on another. The second row should show unknown coverage, not a lower temperature. A completeness column is useful because it separates a monitoring limitation from the operating state being compared.
For workload comparisons, use the same application measurements alongside the vendor telemetry: completed work, response latency and known test conditions. Management utilization is context, not a cross-vendor benchmark score. A device that reports a higher percentage has not thereby established higher useful throughput or better energy efficiency.
Review mappings when the stack changes
Keep raw observations and the mapping version so a later library change can be audited. Recheck supported functions and fixture behavior after a driver or management-library update. The resulting report should make units, scope and missingness visible. It gives a mixed fleet a common language while preserving the vendor-specific evidence needed to interpret that language correctly.