Ошибки NVIDIA Xid в AI-инфраструктуре: диагностика и восстановление GPU

LLM-сервис внезапно теряет GPU, в kernel log появляется NVRM: Xid, а очередь запросов уже растёт. Самая дорогая ошибка в этот момент — сразу перезагрузить узел и стереть контекст, не поняв, был ли виноват CUDA-процесс, PCIe, HBM или сама карта. Нужен короткий и воспроизводимый incident workflow: сохранить доказательства, остановить новые назначения, выбрать правильное recovery action и только потом возвращать accelerator в пул. Ниже — production-runbook для выделенных GPU-серверов и Kubernetes-кластеров.

Xid — это сигнал, а не готовый диагноз

Ошибка Xid появляется, когда драйвер NVIDIA фиксирует ненормальное состояние GPU и пишет событие в журнал ядра Linux. Код помогает сузить круг поиска, но сам по себе не отвечает на главный вопрос дежурного инженера: сломалось приложение, драйвер, PCIe-тракт, память ускорителя или сама карта. В официальном каталоге Xid прямо сказано, что одинаковый код может иметь программную и аппаратную природу. Поэтому реакция «увидели номер — сразу перезагрузили сервер» часто стирает полезные следы и не устраняет причину.

В LLM-сервисе последствия особенно неприятны. Один сбой может оборвать длинные генерации, уничтожить KV cache, нарушить tensor-parallel группу и заставить оркестратор перезапустить сразу несколько реплик. Допустим, worker умер на Xid 13 во время нового CUDA-кернела. Если проблема повторяется только на одном build приложения, сначала нужен разбор кода. Если тот же Xid возникает на разных workload и всегда на одной физической карте, приоритет уже у аппаратной диагностики.

Полезно мыслить не номером, а тройкой: событие, контекст, повторяемость. Событие — это Xid и сопутствующая строка. Контекст — версия драйвера, CUDA, модель GPU, PCI bus ID, процесс и момент нагрузки. Повторяемость показывает, привязан ли сбой к приложению, узлу или конкретному GPU UUID. Такой подход отделяет инцидент от догадки.

Первые десять минут: сохранить доказательства и ограничить ущерб

Первая задача — остановить расширение инцидента, не уничтожив диагностику. Зафиксируйте точное время, затронутый endpoint, request или job, имя узла и GPU UUID. Затем прекратите назначать новую работу на подозрительный accelerator. В Kubernetes это может означать cordon всего узла; на выделенном сервере — исключение реплики из балансировщика. Не спешите выгружать модуль драйвера: после reset или reboot часть состояния исчезнет.

Снимайте журнал с запасом по времени. Один Xid нередко сопровождает цепочку: сначала ошибка приложения, затем channel removal, после неё recovery action. Если вы сохраните только последнюю строку, причинный порядок потеряется. NVIDIA рекомендует искать NVRM: Xid в kernel log и собирать nvidia-bug-report.sh как можно ближе к моменту события.

sudo journalctl -k --since "-30 min" --no-pager > /var/tmp/kernel-xid.log
sudo dmesg -T | grep -iE 'NVRM|Xid|PCIe|AER' > /var/tmp/gpu-kernel-events.log
nvidia-smi -L > /var/tmp/gpu-inventory.txt
nvidia-smi -q > /var/tmp/nvidia-smi-q.txt
sudo nvidia-bug-report.sh

Проверяйте, что файлы действительно созданы и имеют разумный размер. На загруженном узле nvidia-bug-report.sh иногда выполняется долго; официальный fallback — safe mode с дополнительными системными данными. Секрет прост: сначала evidence, потом лечение. Исключение одно — угроза целостности данных или безопасности, когда восстановление сервиса важнее полноты расследования.

Заведите для первых десяти минут короткую карточку инцидента. В ней нужны UTC timestamp и локальное время, имя узла, GPU UUID, PCI BDF, Xid, PID и имя процесса, container image digest, версия драйвера, CUDA runtime и последнее успешное действие сервиса. Digest важнее тега: образ с тегом latest завтра уже не воспроизведёт сегодняшний сбой. Для распределённой задачи добавьте rank и peer GPU, потому что упавший процесс может быть жертвой ошибки на другом accelerator.

Не смешивайте сохранение evidence с тяжёлой диагностикой. Команды чтения журналов и инвентаризации почти не меняют состояние. DCGM stress, reset, выгрузка драйвера и power cycle меняют. В runbook полезна явная разделительная черта: до неё разрешены read-only действия, после неё требуется владелец инцидента и подтверждение, что новые job остановлены. Так дежурный не запустит тест памяти на GPU, который ещё обслуживает чужую inference-реплику.

Мини-пример: в 02:14 алерт фиксирует Xid 79, а в 02:15 kubelet перезапускает Pod. Если инженер сначала сделает reboot, останется лишь факт падения. Если он сохранит journal за 30 минут, то увидит PCIe AER за несколько секунд до Xid и одинаковый BDF в двух прошлых событиях. Эти две минуты сбора данных могут сократить расследование на часы.

Как читать частые Xid без ложной уверенности

Для первичного triage удобно группировать Xid не по сотне номеров, а по типу действия. Xid 13 и 31 часто направляют к приложению, MMU или некорректному доступу к памяти, но повторяемость на одной карте требует аппаратной проверки. Xid 45 обычно вторичен: канал удалён из-за другого события, поэтому искать нужно более ранний код. Xid 48 означает double-bit ECC и требует анализа памяти и следующих Xid 63/64. Xid 79 — потеря связи устройства с PCIe bus, что уже выводит расследование за пределы CUDA-процесса.

Современный каталог вводит полезное разделение на immediate action и investigatory action. Первое возвращает платформу в рабочее состояние: перезапустить приложение, reset GPU, drain и reset, reboot узла. Второе отвечает, что делать, если событие повторится: запустить DCGM или Field Diagnostics, проверить приложение, механику PCIe либо обратиться в поддержку. Это разделение стоит перенести в runbook. В противном случае команда либо исследует часами во время outage, либо бесконечно перезапускает неисправную карту.

Обращайте внимание на Xid 154. Он не является отдельной первопричиной, а сообщает требуемое recovery action для другого события: None, Drain P2P, Drain and Reset, GPU Reset Required или Node Reboot Required. Если драйвер уже сформулировал действие, самодельная таблица приоритетов не должна его переопределять. Для версии и модели вашей карты сверяйтесь с актуальным Xid Catalog.

Не превращайте таблицу Xid в автоматическую истину без контекста. Xid 13 после развёртывания нового custom CUDA extension и Xid 13 на стабильном образе, который внезапно начал повторяться на одном UUID, требуют разных очередей действий. В первом случае откатите build, воспроизведите запрос и используйте Compute Sanitizer в тестовой среде. Во втором сначала изолируйте карту, запустите диагностику и сравните с соседними GPU того же узла.

Полезна матрица из двух осей: масштаб и устойчивость. Масштаб отвечает, затронут один процесс, один GPU, несколько GPU за общим switch или весь узел. Устойчивость показывает, исчезло ли состояние после restart приложения, требуется ли reset, либо ошибка возвращается после полного power cycle. Чем шире масштаб и устойчивее симптом, тем меньше оснований обвинять отдельный workload.

Симпатические события всегда читайте после первичного. Channel removal, abort или вторичный NVLink error может быть следствием reset peer-устройства. Сортируйте записи по monotonic timestamp, а не только по строкам из разных файлов: syslog, container runtime и Kubernetes Events могут использовать разные часы. Синхронизация NTP здесь становится частью GPU reliability, а не бытовой настройкой сервера.

ECC, Xid 48 и row remapping: когда память ещё можно вернуть в строй

Ошибки памяти требуют более аккуратной реакции, чем общий restart. Исправляемые ECC-события не равны немедленной смерти GPU, но их тренд важен. Неисправимая ошибка HBM может породить Xid 48; последующие Xid 63 или 64 показывают результат записи row-remapping entry. На Ampere и более новых архитектурах row remapping заменяет деградирующую строку запасной аппаратной строкой. Изменение применяется после reset GPU и сохраняется на весь срок службы ускорителя.

Представьте склад с резервными ячейками: одна повреждённая ячейка ещё не закрывает склад, но растущий расход резерва меняет риск. Смотрите не только volatile ECC counters, но и pending/failure flags, число remapped rows и bucketized availability. Команда nvidia-smi -q даёт общий отчёт, а --query-remapped-rows доступен на поддерживаемых устройствах. Если row-remapping failure flag установлен, решение о RMA подтверждается Field Diagnostics и процедурой вендора, а не произвольным порогом из внутреннего wiki.

Официальная документация по GPU Memory Error Management подчёркивает: pending remap требует reset, а RMA-критерии зависят от архитектуры и результатов диагностики. Поэтому храните baseline по каждой карте. Резкий переход от нуля к неисправимой ошибке после теплового события выглядит иначе, чем медленное накопление correctable ECC за месяцы работы.

Xid 79: расследуем PCIe, питание и механику узла

Фраза «GPU has fallen off the bus» означает, что драйвер потерял доступ к устройству по PCIe. Перезапуск контейнера здесь редко достаточен: процесс уже не может общаться с accelerator. Проверяйте AER-события в kernel log, состояние соседних устройств, PCIe link width и speed, питание, riser, кабельные соединения и температуру в шасси. На multi-GPU сервере важна топология: общий riser или switch может связать несколько внешне независимых падений.

Типичная ловушка — объявить карту неисправной после единственного Xid 79, хотя причина была в неплотном power connector после обслуживания. Обратная ошибка дороже: месяцами перезагружать узел, где один и тот же BDF исчезает при высокой мощности. Нужен корреляционный ряд: PCI bus ID, GPU UUID, нагрузка, power draw, AER counters и история обслуживания.

После cordon и сохранения логов выполните холодную проверку механики согласно политике дата-центра. Не открывайте сервер под питанием и не меняйте seating без разрешённого maintenance window. Если Xid повторяется после перестановки карты или следует за ней в другой слот, это сильнее указывает на GPU. Если остаётся на слоте, исследуйте плату, riser и питание. Для выбора и эксплуатации GPU-узлов полезен отдельный материал KingServers о конфигурации GPU-сервера для ML.

Матрица восстановления: приложение, GPU reset, drain или reboot

Хороший runbook начинается не с команды, а с precondition. Перезапуск приложения допустим, когда recovery action не требует reset, GPU остаётся видимым, DCGM health не указывает на изоляцию, а событие связано с конкретным workload. GPU reset требует завершить все процессы на затронутом устройстве; monitoring-agent, X server или peer-to-peer job тоже могут блокировать операцию. На NVLink/NVSwitch-системах ограничения reset зависят от поколения и fabric state, поэтому сначала сверяйтесь с nvidia-smi и документацией платформы.

GPU=0
nvidia-smi -i "$GPU" --query-compute-apps=pid,process_name,used_memory --format=csv
nvidia-smi -i "$GPU" -q
sudo nvidia-smi --gpu-reset -i "$GPU"
nvidia-smi -i "$GPU" -q

Команда reset выполняется от root и только когда устройство свободно. Если recovery action требует Node Reboot, не пытайтесь «сэкономить» перезагрузку серией resets: OS мог остаться в несогласованном состоянии. Для Drain P2P нужно остановить peer-to-peer traffic и связанные UVM-процессы, затем снова запросить recovery action. Для Drain and Reset запрещайте новые job, дайте неповреждённым задачам завершиться или дойти до checkpoint и только после этого сбрасывайте GPU.

Запишите критерий возврата: устройство видно по UUID, отсутствует pending recovery action, короткая диагностика проходит, scheduler снова видит ожидаемый ресурс, а тестовый workload даёт корректный ответ. Одного факта, что nvidia-smi снова открылся, недостаточно. В AI inference добавьте canary-запрос с реальной моделью и контроль latency/error rate.

Формализуйте четыре результата восстановления. Recovered означает, что причина понятна, действие выполнено и canary прошёл. Recovered under observation — сервис вернулся, но причина не доказана; такому GPU нужен повышенный мониторинг и ограниченный rollout. Isolated оставляет карту или узел вне scheduler до длинной диагностики. Escalated означает, что собран пакет для hardware vendor или NVIDIA и дальнейшие resets запрещены без согласования.

Зачем отдельный статус under observation? Представьте редкий Xid 13, который исчез после restart и не повторился в коротком тесте. Немедленный RMA не обоснован, но и считать инцидент закрытым рано. Назначьте небольшой canary traffic, удерживайте резервную реплику и задайте окно: например, до следующего maintenance review или определённого числа workload cycles. Порог выбирает ваша SLO-политика, а не статья.

Не забывайте про blast radius reset. В системах с несколькими GPU один процесс может держать контексты на всей tensor-parallel группе. Сброс одной карты завершит peer job и может оставить framework в долгом timeout. До reset проверьте процессы на всех связанных устройствах, остановите serving group как единицу и уведомите владельца нагрузки. Минимально достаточное действие не всегда минимально по числу устройств; оно минимально по риску повторного отказа.

Kubernetes-runbook: вывести GPU-узел из ротации без второго инцидента

В Kubernetes сначала отделите сетевое исключение реплики от обслуживания узла. Уберите endpoint из serving-пула или дождитесь readiness failure, чтобы новые запросы не шли в умирающий процесс. Затем cordon запрещает новые назначения. kubectl drain эвакуирует управляемые Pod через Eviction API и ждёт graceful termination; параметры --delete-emptydir-data и --force нельзя добавлять автоматически, потому что они меняют риск потери локальных данных и поведение unmanaged Pod.

NODE=gpu-worker-07
kubectl cordon "$NODE"
kubectl get pods -A -o wide --field-selector spec.nodeName="$NODE"
kubectl drain "$NODE" --ignore-daemonsets --grace-period=900

# После диагностики, reset/reboot и canary-проверки:
kubectl uncordon "$NODE"

Официальная справка kubectl drain рекомендует не работать с машиной, пока drain не завершён. Для training job проверьте checkpoint, для inference — PodDisruptionBudget и запас реплик. Если узел содержит локальный model cache, его повторный прогрев может вызвать latency spike после uncordon; возвращайте capacity постепенно.

NVIDIA device plugin отслеживает NVML event stream и при критическом Xid помечает GPU unhealthy, после чего устройство исчезает из Allocatable. Сопоставьте логи device-plugin с dmesg и фактическим количеством GPU. Это не автоматический ремонт: плагин защищает scheduler от назначения на плохой accelerator. Архитектуру GPU scheduling и очередей можно сверить с материалом KingServers о распределении GPU между inference, training и batch, а устройство платформы — с гайдом по Kubernetes для AI inference.

DCGM Diagnostics: проверяем узел активно, а не по одному счётчику

DCGM разделяет неинвазивный health monitoring и активные diagnostics. Первое можно держать во время нагрузки; второе потребляет GPU, CPU, память, питание и fabric, поэтому запускать его нужно на освобождённых устройствах. Level 1 подходит для быстрой проверки deployment, level 2 — как epilogue после сбоя, более длинные уровни и отдельные plugins — для post-mortem администратором. Актуальная документация DCGM 4.6 предупреждает, что доступность теста зависит от GPU, установленных plugins и окружения hostengine.

dcgmi discovery -l
dcgmi diag --run 1 --entity-id gpu:0
dcgmi diag --run pcie,memory --entity-id gpu:0 --json
dcgmi diag --run 2 --entity-id gpu:0 --json

Не запускайте level 3 или 4 на production-узле «на всякий случай»: stress, power, memory bandwidth и memtest занимают время и могут конфликтовать с workload. Сохраняйте JSON, exit status, версию DCGM и список доступных entities. В официальной справке dcgmi diag статус 0 означает отсутствие найденной ошибки, а ненулевой код может указывать как на finding, так и на проблему запуска или недоступный plugin.

DCGM Diagnostics не ремонтирует GPU, не заменяет Field Diagnostics и не определяет RMA. Его ценность — воспроизводимое активное доказательство: PCIe test падает только на GPU 3, memory test фиксирует ECC, либо software suite выявляет несовместимость библиотек. Для постоянного наблюдения используйте DCGM Exporter и health metric с категориями SOFTWARE_XID, HARDWARE_MEMORY, HARDWARE_PCIE и другими, но алерт должен вести к runbook, а не прямо к reboot.

Стройте лестницу тестов. Сначала level 1 проверяет развёртывание и доступность библиотек. Затем выбирайте plugin по симптомам: pcie после bus errors, memory после ECC, NVLink или bandwidth tests при меж-GPU сбоях. Level 2 уместен как более широкий epilogue. Длинный stress запускайте только если короткие проверки не объяснили повторяемый отказ и у вас есть окно, охлаждение и питание для полной нагрузки.

Результат Skip не равен Pass. Он может означать неподдерживаемую функцию, отсутствующий executable или неверное окружение hostengine. Сохраняйте не только сводный статус, но и per-entity message. Если plugin недоступен, это отдельная задача платформы: нельзя заключить, что память исправна, когда memory test вообще не стартовал.

Сравнивайте подозрительный GPU с контрольным того же SKU и сервера. Одинаковая software failure на всех устройствах чаще говорит об окружении; isolated hardware finding на одном UUID усиливает аппаратную гипотезу. Но не выдумывайте собственные performance thresholds поверх DCGM defaults без квалифицированного baseline: power cap, охлаждение и профиль карты меняют ожидаемый результат.

Evidence pack и алерты: чтобы следующий Xid не начинался с нуля

После восстановления соберите один incident bundle. В него входят kernel log с временным окном, полный Xid string, GPU UUID и PCI BDF, nvidia-smi -q, driver/CUDA/DCGM versions, DCGM JSON, nvidia-bug-report.log.gz, workload и container image, timeline действий и результат canary. Для HGX добавьте Fabric Manager logs. Этот пакет помогает вендору и вашей команде отличить повтор аппаратного дефекта от нового программного случая.

Алерт по слову Xid слишком шумный. Разделите severity: informational события сохраняются, application-class создают ticket и коррелируются по build, reset/reboot-class немедленно запрещают новую работу, hardware recurrence эскалируется владельцу платформы. Ключи корреляции — GPU UUID, Xid, recovery action и окно времени. Не используйте только hostname: карты переставляют, узлы переустанавливают, а UUID остаётся стабильнее.

Проверьте, можете ли вы ответить через пять минут: какой физический accelerator затронут, какие job работали, был ли Xid первым событием, что потребовал драйвер, повторялось ли это за 30 дней? Если нет, наблюдаемость ещё не операционная. Для сравнения с прикладным health-check полезен гайд KingServers по NVIDIA NIM на выделенном GPU, но Xid-runbook должен жить на уровне узла и драйвера, независимо от serving framework.

Postmortem должен закончиться изменением системы, а не фразой «узел перезагрузили». Если причиной был новый CUDA build, добавьте canary на малой доле GPU и автоматический rollback по Xid. Если подвёл riser, внесите torque и seating check в maintenance checklist. Если evidence потерялся, настройте persistent journal и удалённую доставку kernel events. Каждое действие должно иметь владельца, срок и проверяемый результат.

Отдельно храните историю по GPU UUID: дата, Xid, workload, recovery action, diagnostic result и физическое перемещение. Такой журнал переживает переименование узла. Он также защищает от эффекта «каждый инцидент первый»: три редких события за квартал на одной карте становятся заметны только при общей идентичности.

Проведите game day без реального повреждения: сымитируйте потерю одной inference-реплики, пройдите cordon/drain, соберите шаблон evidence и верните узел через canary. Не инжектируйте Xid в production без согласованной лаборатории. Цель упражнения — проверить людей, доступы и наблюдаемость. Когда настоящий Xid появится ночью, команда будет выполнять знакомую процедуру, а не придумывать её под давлением.

Итог: возвращайте GPU в строй по доказательствам

Xid — не приговор карте и не разрешение на слепой restart. Надёжный процесс выглядит спокойнее: сохранить журнал и идентичность GPU, остановить новые назначения, прочитать recovery action, выбрать минимально достаточное восстановление, прогнать подходящую диагностику и вернуть capacity через canary. ECC и row remapping требуют собственной ветки, Xid 79 — проверки PCIe и питания, а повторяемость на одном UUID переводит разговор из области приложения в область железа.

Передайте runbook не только SRE, но и владельцам моделей. Они определяют допустимую потерю запросов, поведение очереди, checkpoint для training и canary, который действительно проверяет качество ответа. Платформенная команда отвечает за GPU, драйвер, PCIe и scheduler; команда приложения — за воспроизводимость workload. Без этой границы каждый Xid превращается в спор между «железом» и «кодом», хотя данные уже могли бы показать направление.

Раз в квартал пересматривайте команды по текущим версиям драйвера, DCGM и GPU Operator. В августе 2026 года актуальная документация DCGM описывает четыре уровня диагностики и canonical named tests, но доступность plugins остаётся runtime-dependent. Помечайте экспериментальные и неподдерживаемые возможности рядом с командой, а не в памяти инженера. Runbook устаревает тише, чем сервер, и потому нуждается в регулярной проверке.

Отдельно измеряйте время до изоляции и время до безопасного возврата. Первая метрика показывает, насколько быстро команда защищает новые задания; вторая — сколько занимает evidence, диагностика и canary. Не оптимизируйте их одной кнопкой reboot. Зрелость процесса видна в том, что восстановление становится быстрее, а доля необъяснённых повторов снижается.

Начните с простого упражнения: возьмите один GPU-узел, проверьте команды сбора evidence, время drain, доступность DCGM plugins и критерии uncordon. Такой rehearsal обнаружит права, отсутствующие логи и слишком жёсткие PDB до реального outage. Если для AI-нагрузки нужен выделенный GPU-сервер с понятным контуром эксплуатации, команда KingServers поможет подобрать конфигурацию и заложить диагностику в runbook с первого дня.