NVIDIA DCGM vs AMD SMI: GPU Telemetry Field Mapping

Executive Summary

For graphics processing unit (GPU) fleets, NVIDIA Data Center GPU Manager (DCGM) Exporter and AMD Device Metrics Exporter expose related signals, but they do not publish a common telemetry contract. This comparison selects NVIDIA DCGM Exporter 4.8.3 paired with DCGM 4.6.0 and AMD Device Metrics Exporter 1.5.2 as its release scope; the selection is not a claim that these are the latest releases. NVIDIA's active collector rows and AMD's enabled field list determine what appears at runtime; hardware, driver, permissions, and partitioning further narrow the output. The safest migration begins with the effective /metrics payload and a versioned dictionary, rather than a global rename of dashboards. ^{[1] [2]}

The clearest transferable families are device identity, occupied frame buffer or video random access memory (VRAM), temperature, and power, provided units and sensor scope are normalized. They are approximate mappings until a live sample confirms scope and cadence. DCGM's default frame buffer used value is described as mebibytes (MiB); AMD's GPU_USED_VRAM is documented in megabytes (MB), and the AMD value is absent on a Single Root Input/Output Virtualization (SR-IOV) hypervisor host using GIM. DCGM energy is a millijoule counter since driver reload; AMD exports accumulated microjoules from an accumulator tied to restart or GPU reset. Convert both to joules before comparing rates, and keep their reset boundaries distinct. ^{[3] [4] [5] [6] [7]}

Activity, interconnect, and health need narrower decisions. DCGM_FI_DEV_GPU_UTIL is a device-sampled percentage; AMD's GPU_GFX_ACTIVITY is graphics-engine activity and its GPU_UMC_ACTIVITY is memory-engine activity. NVIDIA profiling fields are interval averages and are not identical to either AMD field. NVIDIA Peripheral Component Interconnect Express (PCIe) transmit and receive gauges are directional bytes per second; AMD's documented exporter offers an aggregate PCIE_BANDWIDTH in Mb/s. NVLink and extended GPU memory interconnect (XGMI) expose topology-specific signals, not one shared fabric counter. XID and AMD Field Identifier (AFID) values are vendor event identifiers, not interchangeable incident totals. ^{[3] [4] [8] [3]}

The operational rule is to grade each mapping exact, approximate, composable, vendor-specific, or unavailable; carry source API, unit, kind, aggregation, sampling, reset, support, and privilege in the dictionary; and re-baseline alert thresholds on observed workload distributions. Preserve missing-series alerts separately from zero-value alerts because a disabled, unsupported, or unobserved series can disappear without proving that a GPU is idle or healthy. Prometheus distinguishes counter resets from gauges and marks stopped series stale. No hardware was available for this report, so the tables below are documented specifications and a validation plan, not measured parity. ^{[9] [10] [11]}

Introduction and Background

A mixed NVIDIA and AMD private cluster usually inherits dashboards, recording rules, and alerts built around DCGM names. The practical decision is which rules survive a vendor addition and which need new definitions. A metric's spelling, even when both vendors call it “utilization,” is only a hint. An observability contract must name the measured object, the time window, the sensor or API, its unit, its type, the label identity, and when the number resets. Prometheus explicitly advises one quantity and one unit per metric; OpenTelemetry's developing GPU convention uses a fraction of time for utilization and a separate fraction for memory occupancy. Neither convention automatically makes vendor source fields semantically equal. ^{[12] [13]}

GPU Smith's public scope includes private infrastructure integration and operational telemetry, so its role here is an adjacent engineering perspective, not a row in the vendor comparison. The report evaluates documented products and provides a method for operators to verify the mapping on their own hardware. It does not claim a GPU measurement or a client deployment.

The stack boundary matters. DCGM Exporter selects DCGM fields, watches GPU or other entities, labels them, and serves Prometheus output from /metrics. Without a remote host engine, it embeds a DCGM host engine. AMD SMI is the successor to ROCm SMI and provides API and command-line access; AMD's Device Metrics Exporter turns supported signals into Prometheus series. A dashboard often queries an exporter, not the underlying vendor API, so it must use the current exporter schema. ^{[14] [15] [2]}

This comparison is a semantic dictionary and migration procedure. It excludes acceptance burn-in and economic capacity modeling. It treats a documented but absent signal as a support question to test, not as evidence that a device has no activity. NVIDIA warns that configuring a field does not guarantee emission; AMD's virtualization and partition documentation makes the same caution concrete for several fields. ^{[16] [17]}

NVIDIA DCGM and DCGM Exporter

Capabilities

The current NVIDIA exporter documentation distinguishes active default collector rows from commented optional examples. Its shipped default covers clocks, temperatures, power, total energy, frame buffer memory, GPU utilization, PCIe and NVLink throughput, and the last XID value. A configured Prometheus type is used as written, without semantic validation against the DCGM field definition. Operators should therefore treat the collector CSV, the DCGM field identifiers, and the live output as three separate evidence layers. ^{[16] [3]}

A default DCGM watch cadence of 30,000 milliseconds is configurable by field group. An HTTP scrape reads the latest cached host-engine sample, so a 15-second Prometheus scrape does not create a 15-second new device reading by itself. Product-dependent sampling also affects DCGM_FI_DEV_GPU_UTIL. Profiling fields, including DCGM_FI_PROF_SM_ACTIVE, report interval averages, and paused profiling watches return blank values. ^{[18] [3]}

Adoption and collection scope

NVIDIA's release notes pair Exporter 4.8.3 with DCGM 4.6.0; the documentation cautions against mismatched versions. Kubernetes implementations show why exporter labels matter: AWS combines DCGM data with Amazon Elastic Kubernetes Service (EKS) metadata for pod-level views, and Google Kubernetes Engine (GKE) collection adds GPU and pod identity labels. These are examples of attribution, not evidence that an activity number changes meaning at the pod boundary. ^{[1] [19] [20]}

Strengths and limitations

The DCGM field catalog is broad, but effective coverage depends on GPU generation, entity, driver, and privileges. Profiling is documented for supported data center products beginning with Volta, while the container workflow requires SYS_ADMIN for profiling fields. Multi-Instance GPU (MIG) samples add GPU_I_PROFILE and GPU_I_ID; a rule that aggregates without those labels may merge unlike entities. The default last-XID gauge records an identifier, whereas optional exporter XID counts are sampled records within a window and exporter totals reset on restart or collector rebuild. Neither can be renamed into a generic hardware fault count without changing the alert definition. ^{[8] [3]}

AMD SMI and Device Metrics Exporter

Capabilities

AMD SMI provides its own API and command-line surface; the Device Metrics Exporter 1.5.2 publishes a Prometheus schema. Its default empty GPUConfig.Fields list exports all eligible fields, and configuration can prefix metric names. AMD release notes say the server-side collection filter follows enabled fields and labels, while error-correcting code (ECC) and PCIe status remain collected for health validation. An inventory of enabled configuration is therefore part of a schema migration. ^{[15] [2]}

AMD names separate graphics and memory engine activity percentages, GPU_GFX_ACTIVITY and GPU_UMC_ACTIVITY. GPU_USED_VRAM measures occupied capacity in MB. GPU_POWER_USAGE is watts, but in partitioned modes only the primary partition reports the device power sensor and other partitions can report zero. The accumulated GPU_ENERGY_CONSUMED value is in microjoules. A zero from a secondary partition must be interpreted as a visibility rule, not zero socket power. ^{[4] [6]}

Adoption and collection scope

The exporter release notes list supported accelerator and ROCm combinations, including MI2xx and MI3xx with Radeon Open Compute (ROCm) 6.2 or later and MI350P with ROCm 7.13 or later. Those are documented minimums, not a guarantee that each field appears on every product. AMD SMI distinguishes bare metal from virtual machine guest support; its graphics activity API is documented as unavailable in guests. A GIM/SR-IOV hypervisor host does not expose per-virtual-function GPU_USED_VRAM in the exporter list. ^{[21] [15] [6]}

Strengths and limitations

AMD's partition model is central to attribution. In Compute Partitioning mode (CPX) on an MI300X, one socket can yield eight processor handles, and device-wide GPU metrics live only on the primary partition. Exporter identity labels include partition and deployment information; guest mode can leave card_model and serial_number empty. An operator must choose physical-socket and logical-partition views explicitly. For SR-IOV hypervisor deployment, the documented exporter container uses a GIM management device and has a separate installation path. Optional profiler metrics are disabled by default and require performance-counter access. ^{[17] [22]}

Feature Comparison

Mapping grades and dictionary rules

Exact means the observable, scope, unit after a mechanical conversion, time window, and reset contract match for the pinned versions. Approximate means the signals can support a similar operational question after a new baseline but retain a semantic difference. Composable means a documented formula plus labels can form a useful derived view. Vendor-specific means retaining the native signal is safer. Unavailable means the documented exporter has no defensible counterpart for the requested view. These are decision grades, not vendor performance ratings. A conversion can make units comparable without making sampling or sensor identity equal. ^{[12] [23]}

Table 1 is a CSV-friendly field dictionary. Each row carries the native key, its closest counterpart, source API or exporter family, unit and kind, grade, and the main reset, support, or scope constraint. Scope: the selected releases; documented specifications, not hardware measurements. “Gauge” describes the exported series type; where a source does not specify a reset rule, the row says to verify it. Use release-specific exporter references for the dictionary; treat remaining unversioned API references as general context that needs separate version validation.

The default exporter series DCGM_FI_DEV_POWER_USAGE maps to DCGM_FI_DEV_BOARD_POWER_WATTS (field 155), which NVIDIA describes as “Power usage for the device in Watts.” The separate DCGM_FI_DEV_BOARD_POWER_RAW_WATTS (field 157) is the one described as “Current instantaneous power usage of the device in Watts.” ^{[16] [5]}

The table supports query design, not a promise of identical thresholds. It also illustrates why a simple label_replace() cannot repair a semantic mismatch. Capacity can be normalized mathematically, while activity and temperature still need sensor and time-window validation. The exported gpu_clock field may represent several clock types, so the target clock type must be selected on AMD before recording it under a neutral name. ^{[12] [27]}

Mappings to reject

Table 2 lists tempting translations that would erase information. The row identifies the operational question that should replace the rename.

The do-not-translate cases protect alerts from false parity. For example, an allocated GPU count may be stable while compute activity falls, and a missing per-partition power sensor may legitimately report zero. Neither observation alone establishes an idle or healthy accelerator. ^{[28] [11]}

Performance and Benchmarks

This article does not benchmark hardware. A telemetry schema comparison cannot establish throughput or efficiency, and no controlled cross-vendor GPU workload was run. The measurable comparison is observability fidelity: does each selected time series cover the same entity, interval, quantity, and aggregation? NVIDIA profiling metrics are interval averages, not a kernel trace; AMD's optional profiler metrics are disabled by default and have a separately configured sampling window. Those facts make profiler and general-purpose utilization panels different instruments. ^{[8] [4]}

A useful test workload alternates a known busy interval with an idle interval while both exporters are scraped. An AWS operational example demonstrates 20 seconds at full utilization followed by 20 seconds at zero. That example is a reproducible shape for checking lag and smoothing, not a cross-vendor benchmark result. Compare raw samples first, then use equal recording windows. DCGM's 30-second default watch cadence means a short burst can be undersampled even if Prometheus scrapes more frequently. AMD's health service has a separate 30-second default polling interval, which should not be mistaken for every metric's sampling period. ^{[19] [18] [22]}

For capacity panels, use a controlled allocation and release, then inspect byte scale and reserved-memory behavior. For power, hold a stable workload long enough to compare gauge medians and the derivative of energy counters after conversion. For interconnect, test an explicitly directional host-device transfer and a peer transfer separately. The NVIDIA PCIe direction is defined from the GPU's perspective; AMD's exporter aggregate PCIe bandwidth cannot provide that direction in the documented schema. AMD SMI's separate API can return bytes sent and received over one second, but that is an integration decision beyond a name swap. ^{[5] [4] [30]}

For Device Metrics Exporter 1.5.2 on MI250, AMD reports that reading PCIe bandwidth takes about one second per GPU because the kernel pcie_bw sampler blocks per read. Validate the effective scrape duration when enabling this field. ^[21]

Data Analysis and Evidence

The most useful numerical data here are unit and collection-contract differences, not market-size estimates. A dashboard migration can be wrong by a scale factor even when graphs look plausible. The calculation below follows each vendor's published unit and NIST's distinction between decimal and binary byte multiples. It is a schema conversion, not a measured hardware result. ^{[3] [7]}

Table 3 gives arithmetic templates for a neutral recording layer. The uppercase AMD expressions are configuration-key pseudocode, not executable PromQL. Before writing a query, substitute the exact series names observed in the deployment's /metrics output, including its configured prefix. Retain the unit-scale, source-type, sampling, and reset checks below.

The table's 1,048,576 and 1,000,000 multipliers differ by about 4.86% when translating an equal displayed count into bytes. That percentage is arithmetic from the stated units, not an independent vendor measurement. NIST also cautions that historical use of “MB” may vary, so a controlled allocation remains part of the validation. ^{[7] [23]}

Counter treatment is similarly quantitative. A driver reload resets NVIDIA's energy total, and AMD's energy accumulator ties to restart or GPU reset. Prometheus rate() adjusts detected counter resets; it should be applied before summing across GPUs. It must not be applied to a power or temperature gauge. That distinction determines whether an energy-based power panel is an honest rate or an arbitrary slope through a reset. ^{[5] [6] [11] [9]}

Finally, counts in the metric names are not always counts of events. DCGM_FI_DEV_XID_ERRORS is a last-code gauge. Optional exporter XID count series count sampled records in a window, and totals reset with exporter lifecycle events. AMD publishes correctable, uncorrectable, and deferred error categories. A cross-vendor “error rate” requires a written event taxonomy and observation rules, not merely addition across all RAS fields. ^{[3] [16]}

Dashboard Migration Procedure

Inventory, normalize, validate

A migration should start with the live metric surface and end with a recorded decision for each old rule. The operator should retain the original vendor metric beside any neutral recording rule until both can be inspected under a controlled workload. This matters because NVIDIA's configured rows can be absent, and AMD can prefix fields or change what a partition exposes. Prometheus recording rules create new series; they do not change the evidence produced by the exporter. ^{[16] [17] [33]}

1. Freeze versions and topology. Record GPU model, firmware, driver, DCGM or AMD SMI version, exporter image digest, collector configuration, partition mode, and privilege set. Pin NVIDIA's paired exporter/DCGM release and AMD's supported ROCm matrix. ^{[16] [21]}
2. Inventory effective series. Save /metrics samples from each deployment mode, including primary and secondary partitions or guests. Compare configured fields with observed names, types, help text, and labels. An enabled field is not proof of emission. On dense MI250 nodes with PCIe bandwidth enabled, account for delayed or empty metric responses when assessing scrape completeness. ^[21]
3. Define stable identity. Join by physical device identifier only where present; preserve partition, link, and pod labels. NVIDIA MIG adds instance labels, AMD CPX can create multiple handles per socket, and Kubernetes pod attribution uses the PodResources API. ^{[17] [29]}
4. Normalize units and types. Create distinct neutral names for bytes, joules, watts, degrees Celsius, and ratios. Convert MiB and MB explicitly. Keep cumulative values as counters and instantaneous values as gauges. ^{[7] [12] [9] [31]}
5. Annotate availability. Mark each mapping by GPU generation, driver, bare metal or guest, hypervisor role, privilege, and collector mode. For example, NVIDIA profiling needs SYS_ADMIN, AMD profiler access can need CAP_PERFMON, and AMD per-VF VRAM use is not visible on a GIM host.
6. Check cardinality. Count series before adding link, partition, process, pod, or code labels. Each distinct label set consumes Prometheus resources; a per-link or per-event dashboard can multiply series unexpectedly. ^[9]
7. Re-baseline alerts. Run vendor-native and neutral panels together through representative idle, loaded, and partitioned conditions. Keep separate missing-series alerts because Prometheus marks disappearing series stale. Use a for duration chosen from the real sample cadence and response objective. ^{[10] [34]}
8. Document exceptions. Leave XID, AFID, health status, NVLink, and XGMI as vendor-native names unless a tested higher-level question justifies an explicit derived rule. Preserve the grade and source URL in the dictionary. ^{[3] [32]}

Alert evidence templates

The following Prometheus Query Language (PromQL) expressions are templates, not universal limits. Replace placeholder thresholds with values derived from a pinned fleet's observed distribution and operational objective. The expressions assume neutral recording rules already normalize units, identity, and counter resets. Prometheus recommends rate() before aggregation, and absent() is available for missing-series detection. ^[11]

max by (cluster, physical_gpu) (gpu_temperature_celsius{sensor="chosen"}) > TEMPERATURE_LIMIT_C

sum by (cluster, physical_gpu) (rate(gpu_energy_joules_total[WINDOW])) > POWER_LIMIT_W

max by (cluster, physical_gpu) (expected_physical_gpu{cluster="CLUSTER"})
  unless on (cluster, physical_gpu)
max by (cluster, physical_gpu) (gpu_temperature_celsius{cluster="CLUSTER",sensor="chosen"})

Populate the template expected_physical_gpu series from inventory, with one cluster and physical_gpu label pair per expected device. A fixed absent() selector checks only its specified metric-and-label combination. ^[11]

A temperature limit must name the sensor: AMD documents edge and hotspot or junction readings, while NVIDIA's GPU and memory temperatures are separate fields. A power limit should identify whether it is board, socket, or partition scope. If an AMD secondary partition reports zero because the physical sensor belongs to the primary partition, a zero-power alert is a schema error. Grafana's display unit option changes presentation, not the stored metric, so conversion belongs in the query or recording rule. ^{[4] [3] [23]}

Implications and Future Directions

A mixed-fleet procurement review should ask for an observability acceptance matrix alongside hardware and software compatibility. The matrix needs the actual /metrics payload for each ordered accelerator and deployment mode, a field-by-field support statement, version-pinned documentation, and a path to expose the selected labels to the monitoring plane. This is a buyer's evidence request, not a prediction about any vendor's future releases. AMD's current exporter release notes list supported ROCm combinations; NVIDIA links an exporter release to a DCGM version. ^{[21] [1]}

The same review should identify who can access device files, host-engine sockets, Kubernetes pod resources, and profiling counters. Kubernetes says pod-resource monitoring agents require a privileged security context; NVIDIA profiling and AMD profiler collection have their own documented capability requirements. A signal that exists in an API but cannot be collected under the site's security model is operationally unavailable. SR-IOV hosts and guests deserve separate rows because their visible fields and labels differ. ^{[29] [18]}

Common conventions may reduce naming friction, but they do not erase sensor differences. OpenTelemetry's GPU convention is still marked as developing and distinguishes usage from memory utilization; its common hardware convention models energy as a joule counter and power as a watt gauge. A portable layer can adopt those units while retaining vendor, source_api, sensor, physical_gpu, partition, and support_grade as explicit metadata. The remaining vendor-native panels are a feature of honest observability, not migration debt. ^{[13] [31] [35]}

GPU Smith's public operations scope includes telemetry and procedures for existing facilities. In that advisor posture, the defensible recommendation is a measured mapping record and a small live validation on the specified fleet before an alert becomes production policy. The report supplies the schema questions, while actual thresholds and reliability behavior remain properties of the deployed systems and workloads. ^[34]

Frequently Asked Questions (FAQs)

Is AMD SMI the same as ROCm SMI?

AMD calls AMD SMI the successor to ROCm SMI. Its API and command-line output should be treated as a source of AMD telemetry, while the Device Metrics Exporter schema determines the Prometheus names used by a dashboard. As of this report, the exporter documentation is labeled 1.5.2. ^[15]

What is the AMD equivalent of NVIDIA GPU utilization?

GPU_GFX_ACTIVITY is the closest general AMD exporter field for graphics-engine busy percentage, but the mapping is approximate. GPU_UMC_ACTIVITY measures memory-engine activity, not VRAM occupied. NVIDIA DCGM_FI_PROF_SM_ACTIVE is a profiling interval ratio with another scope. Validate all three under the same workload before reusing a threshold. ^{[6] [3] [8]}

Can DCGM Exporter rules be reused with AMD Device Metrics Exporter?

Rules that normalize device identity, bytes, joules, and watts can often be composed from documented fields after unit conversion. Alerts for temperature, utilization, PCIe, NVLink or XGMI, ECC, and event identifiers need a new scope statement or a vendor-native branch. An exporter label prefix, optional DCGM collector, unsupported field, or guest-mode omission can make a syntactically correct query return no series. ^[16]

Are missing GPU metrics equivalent to zero?

No. Prometheus marks a previously present series stale when a target stops returning it, and absent() is intended for missing-series alerts. AMD's documented partition modes can yield zero on a secondary partition for a sensor available only on the primary, while other fields may disappear entirely on a guest or host. Maintain explicit missing-series and scope checks. ^{[10] [11]}

Conclusion

The DCGM to AMD SMI migration is a translation of measurement contracts, not a search-and-replace of metric names. Capacity and energy can be normalized through stated units and reset rules; activity, temperature, PCIe, interconnect, health, and event codes carry important scope differences. A dashboard can display both vendors under shared headings only after the underlying series have been graded and tested. ^{[5] [6]}

For an SRE or platform team, the deliverable is a versioned dictionary, a saved sample of each exporter's live output, and an alert review that records which thresholds were re-baselined. Keep physical and partition identity, missing-series behavior, and privilege requirements explicit. Preserve vendor-native panels where no equivalent exists. The current documents provide a strong specification for that work, but they do not replace validation on the actual GPUs, drivers, partition modes, and monitoring cadence. ^{[16] [17] [10]}