# ECC GPU: volatile и aggregate счётчики ошибок

Как читать ECC GPU с учётом типа ошибки, области памяти и истории сбросов. Практическая таблица отделяет новые приращения от исторических итогов и недоступных полей.

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

## Сначала определите, что именно посчитано

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

В [справочнике запросов NVML](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) различаются volatile и aggregate счётчики ECC. Доступность зависит от устройства и его конфигурации. Если запрос не поддерживается, значение должно оставаться неизвестным. Подстановка нуля превращает отсутствие наблюдения в утверждение, что ошибок не было.

## Сравнивайте одинаковые величины

Исправленные ошибки следует учитывать отдельно от неисправленных. Сохраняйте указанную область памяти, вместо того чтобы складывать все категории в один нерасшифрованный итог. Подпись «ошибки GPU» слишком широка для решения об обслуживании. Рядом со значением нужна конфигурация сбора: замена экспортера иначе может незаметно изменить смысл метрики.

В [документации nvidia-smi](https://docs.nvidia.com/deploy/nvidia-smi/index.html) описаны поля ECC и ограничения отчётности. Перед созданием сборщика необходимо проверить перечень запросов установленной версии инструмента. Поле, доступное на серверном ускорителе, не становится автоматически доступным на любой профессиональной станции или в каждой конфигурации разделения GPU.

## Считайте сброс границей наблюдения

Предположим, в условном примере volatile показывает 12 до обслуживания и 0 после него, а aggregate сохраняет значение 18. Из этого не следует, что двенадцать неисправностей устранены или что восемнадцать новых ошибок появились после запуска. Значения относятся к разным историям накопления. Для их сопоставления сначала нужен контекст сброса устройства или жизненного цикла драйвера.

Сохраняйте исходные показания до вычисления разностей. Если счётчик уменьшился или изменился идентификатор устройства, начинайте новую эпоху измерений. Не публикуйте отрицательную скорость ошибок и не добавляйте модуль отрицательной разности к числу инцидентов. Когда переход не наблюдался сборщиком, оставляйте явный пропуск в данных.

## Подготовьте таблицу свидетельств

Одна строка таблицы должна соответствовать одному наблюдению: время UTC, идентификатор загрузки хоста, UUID GPU, версия драйвера, класс ошибки, область памяти, семейство счётчика, значение и статус запроса. Если известно обслуживание, добавляйте ссылку на его запись. Исходный вывод производителя позволит пересмотреть трактовку без повторного нагрузочного теста.

При исследовании повторяемой нагрузки сравнивайте приращения внутри одной эпохи и отмечайте начало и конец эксперимента. Рост в этом интервале показывает временную связь. Сам по себе он не устанавливает приложение как физическую причину неисправности и не определяет результат гарантийного обращения.

## Разделяйте результаты проверки

Неизменный исторический итог, новое приращение и недоступное поле — три разных результата. Их сопоставляют с отказами приложения и событиями устройства по применимой процедуре поддержки оборудования. Отсутствие ошибок в конкретном наблюдении полезно в пределах проверенной области, но не является заключением об общем здоровье всей видеокарты.

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

- [Бывший в эксплуатации GPU: какие проверки нужны перед пилотом](/ru/journal/used-gpu-health-check/)
- [Паспорт GPU в CSV: какие поля выгрузить из nvidia-smi](/ru/journal/gpu-inventory-csv-from-nvidia-smi/)