# GPU row remapping: pending state, remapped rows and spares

Interpret GPU row-remapping counts, pending state and spare information without confusing them with retired pages or a universal hardware replacement threshold.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-row-remapping-state/
Language: en

## Distinguish the recovery mechanisms

GPU memory reports can mention remapped rows, pending remapping and retired pages. These names do not describe interchangeable counters. Before interpreting them, identify the exact device architecture and the mechanism documented for that product. Combining fields from different generations produces an impressive-looking history that may have no coherent physical meaning.

NVIDIA describes [row remapping](https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/row-remapping.html) as replacement of degraded memory rows using hardware spares. The documentation distinguishes this from earlier page retirement. A count of remapped rows is therefore not a direct statement that the same amount of usable VRAM has disappeared from an application.

## Read state as well as totals

An observation should retain the remapping count, whether changes are pending, any reported failure state and the spare-capacity information available on that device. These fields answer different questions: what has already been recorded, whether a transition remains outstanding and whether the remapping mechanism reports a problem.

The [user-visible statistics reference](https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/user-visible-statistics.html) explains the exposed remapping information. Keep its device-specific interpretation attached to the record. A missing field on another GPU model is not evidence of unlimited spares, and a zero in one category does not cancel an event reported in another category.

## Understand a pending transition

Consider a hypothetical inspection where the remapping total is unchanged but the pending indicator becomes active. Recording only the total would hide a meaningful state transition. Conversely, observing that pending later clears does not explain which administrative action occurred unless the maintenance timeline records it.

The documented mechanism requires a GPU reset for pending remapping to take effect. That is a lifecycle constraint, not an instruction to reset an occupied server immediately. Device dependencies, active work and platform recovery procedures determine how an administrator plans the transition. Preserve the evidence before any supervised recovery changes it.

## Keep an auditable history

A practical record contains timestamp, host, GPU UUID, driver, tool version, raw remapping fields and the corresponding maintenance event. Store explicit supported, unsupported and failed-query states. Where the tool reports several spare categories, retain those categories rather than inventing a universal percentage of remaining GPU life.

Compare the next observation against the same GPU and reporting semantics. If the collector or firmware changes, annotate the change before joining the series. A clean graph created by dropping unfamiliar values is less useful than a graph that honestly displays an observation gap and the reason it exists.

## Bound the operational conclusion

Row-remapping evidence contributes to a broader hardware investigation alongside application failures, memory events and vendor diagnostics. It does not establish a universal replacement threshold across GPU families. Use the relevant product guidance for a maintenance decision, and keep the technical observation separate from an assumption about warranty eligibility or expected remaining service life.

## Related reading

- [Used GPUs: which checks are needed before a pilot?](/journal/used-gpu-health-check/)
- [GPU-node acceptance: evidence beyond an attractive benchmark](/journal/gpu-acceptance-evidence/)