# Row remapping GPU: pending, remapped и запас строк

Как трактовать число row remapping, состояние pending и резерв строк GPU, не смешивая их с retired pages и универсальным порогом замены оборудования.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-row-remapping-state/
Language: ru

## Различайте механизмы работы с памятью

В отчётах GPU встречаются remapped rows, pending remapping и retired pages. Эти названия не обозначают взаимозаменяемые счётчики. До интерпретации нужно определить точную архитектуру устройства и механизм, описанный для данного продукта. Если объединить поля разных поколений, получится длинная история с числами, которые могут вообще не иметь общего физического смысла.

NVIDIA описывает [row remapping](https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/row-remapping.html) как замену деградирующих строк памяти аппаратными резервными строками. Документация отличает его от прежнего механизма исключения страниц. Поэтому количество переназначенных строк не означает напрямую, что приложение потеряло такой же объём доступной видеопамяти.

## Сохраняйте состояние вместе с итогами

Запись наблюдения должна содержать число переназначений, наличие ожидающих изменений, сообщаемое состояние отказа и информацию о резервных строках, которую предоставляет устройство. Поля отвечают на разные вопросы: что уже зарегистрировано, остался ли незавершённый переход и сообщает ли сам механизм переназначения о проблеме.

В [справочнике видимой статистики](https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/user-visible-statistics.html) объясняются доступные сведения о переназначении. Их трактовку для конкретного устройства следует сохранять рядом с записью. Отсутствие поля у другой модели не доказывает неограниченный запас строк. Нулевой результат одной категории также не отменяет событие, которое зарегистрировано в другой категории.

## Правильно трактуйте pending

Рассмотрим условную проверку: общее количество переназначений не изменилось, но индикатор pending стал активным. Если собирать только итоговый счётчик, важный переход состояния останется незаметным. И наоборот, последующее исчезновение pending не объясняет выполненное административное действие, если оно не отмечено в истории обслуживания.

Для применения ожидающего переназначения описанному механизму необходим сброс GPU. Это ограничение жизненного цикла, а не команда немедленно сбросить занятый сервер. Зависимости устройств, выполняемая работа и процедура восстановления платформы определяют план действий администратора. Перед согласованным восстановлением необходимо сохранить свидетельства, поскольку изменение состояния может усложнить дальнейшую диагностику.

## Ведите проверяемую историю

Практическая запись включает время, хост, UUID GPU, драйвер, версию инструмента, исходные поля remapping и событие обслуживания. Отдельно сохраняйте состояния «поддерживается», «не поддерживается» и «запрос завершился ошибкой». Если инструмент сообщает несколько категорий резерва, оставляйте эти категории вместо придуманного общего процента оставшегося срока жизни карты.

Следующее наблюдение сравнивайте с тем же устройством и с той же семантикой полей. При смене сборщика или прошивки сначала отмечайте изменение, а затем объединяйте временные ряды. Гладкий график, полученный удалением незнакомых значений, менее полезен, чем явный пропуск с понятной причиной отсутствия наблюдений.

## Ограничивайте выводы об оборудовании

Сведения row remapping дополняют исследование отказов приложения, событий памяти и результатов диагностики производителя. Они не задают единого порога замены для всех семейств GPU. Решение об обслуживании принимают по применимым правилам конкретного продукта, отделяя техническое наблюдение от предположений о гарантии и ожидаемом остаточном сроке эксплуатации.

## Связанные материалы

- [Бывший в эксплуатации GPU: какие проверки нужны перед пилотом](/ru/journal/used-gpu-health-check/)
- [Приёмка GPU-узла: какие доказательства полезнее красивого бенчмарка](/ru/journal/gpu-acceptance-evidence/)