PCIe AER и downtraining GPU: production-runbook для LLM inference

Когда подозревать PCIe, а когда не стоит

PCIe редко становится первым подозреваемым при деградации LLM inference. Обычно команда сначала смотрит utilization GPU, VRAM, clocks, throttling, CPU steal, NUMA и очередь запросов. Это правильный порядок: большинство проблем действительно находится выше. Но есть характерная комбинация признаков, при которой стоит спуститься на link layer: приложение теряет throughput или растёт latency, GPU не загружен так, как ожидалось, host-to-device transfer занимает заметно больше времени, а модель и workload не менялись.

Disqualifier здесь важнее красивой гипотезы. Если сервис целиком держит weights и KV cache на GPU, почти не гоняет данные через host после warmup, а p95 растёт одновременно на всех узлах независимо от конкретного BDF, PCIe — слабый кандидат. Точно так же не надо объяснять PCIe любой низкий GPU utilization: причиной может быть CPU preprocessing, storage, tokenizer, scheduler или network backpressure.

И наоборот, настораживает узел, который отличается от соседей того же hardware class. Например, две одинаковые машины работают на одной версии драйвера и одном образе, но одна после обслуживания показывает меньший negotiated link width или generation. Такая асимметрия — уже полезный след: сравнивать нужно не «нормально ли вообще», а «совпадает ли текущий effective state с известным baseline этого конкретного слота и GPU».

Если проблема выглядит как throttling, сначала исключите его по отдельному runbook: мониторинг GPU throttling через DCGM и Prometheus. Для multi-GPU topology полезен и материал про PCIe ACS и P2P DMA. Эта статья намеренно уже: здесь нас интересуют ошибки линии, retrain и downtraining.

Сначала зафиксируйте identity и baseline

До любых reset, retrain, перестановки карты или перезагрузки снимите evidence bundle. Главная ошибка диагностики — потерять исходное состояние, а затем пытаться доказать, что стало лучше. Для GPU используйте стабильный идентификатор: UUID и PCI Bus ID. NVIDIA прямо рекомендует для автоматизации UUID или PCI bus ID, потому что индекс GPU может меняться между перезагрузками.

Минимальный baseline должен отвечать на пять вопросов: какой это GPU; какой BDF видит ОС; какой upstream path ведёт к Root Port; каковы максимальные и текущие speed/width; были ли AER-события до инцидента. Если у вас несколько одинаковых узлов, сохраните те же данные с одной здоровой машины. Это превращает расследование из гадания в diff.

GPU=0
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,name --format=csv
nvidia-smi -i "$GPU" -q | sed -n '/PCI/,/Clocks/p'
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
echo "GPU BDF: $BDF"
lspci -s "$BDF" -vv
lspci -t
journalctl -k -b | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid' | tail -n 200

Привяжите GPU к реальному PCIe-пути

Сообщение AER часто приходит не от самого GPU, а от Root Port или другого элемента иерархии. Поэтому BDF endpoint — только начало. Нужно понять, через какой upstream bridge, riser или PCIe switch проходит карта. Это особенно важно в 2U/4U GPU-серверах: физический слот на задней панели не всегда очевидно соответствует тому Root Port, который вы увидите в журнале.

Начните с lspci -t, затем раскройте подробности endpoint и upstream-портов через lspci -vv. В Capability PCI Express ищите LnkCap и LnkSta: первое описывает возможности конкретного звена, второе — согласованное состояние. Сравнивать надо speed и width вместе. Gen5 x8 и Gen4 x16 — разные состояния, и один только номер поколения не говорит, что линия деградировала.

Не делайте ещё одну распространённую ошибку: не сравнивайте текущий link с маркетинговым максимумом GPU. Ограничение может находиться в слоте, riser, switch или платформе. Правильный baseline — то, что поддерживает минимальное звено по пути и что стабильно показывает здоровый узел той же конфигурации.

GPU_BDF=0000:65:00.0
lspci -s "$GPU_BDF" -vv | grep -E 'LnkCap:|LnkSta:'
lspci -t
# Затем повторите -vv для upstream bridge/root port из дерева:
lspci -s 0000:64:00.0 -vv | grep -E 'LnkCap:|LnkSta:|AER|DevSta:'

Как читать AER и replay без ложных выводов

Linux AER driver собирает расширенную информацию об ошибках PCIe, сообщает её пользователю и участвует в recovery. В документации ядра ошибки делятся на correctable и uncorrectable. Correctable исправляются протоколом без потери функциональности; uncorrectable уже могут затрагивать транзакцию или надёжность самой линии. Это ключевая граница: наличие correctable warning не равно «GPU сломан», но серия событий — хороший триггер для корреляции.

AER в Linux работает через Root Port service driver и зависит от того, передала ли прошивка управление AER операционной системе через ACPI _OSC. Поэтому отсутствие сообщений в dmesg не всегда означает отсутствие ошибок на физическом уровне. На одних платформах телеметрия будет полной в Linux, на других часть обработки остаётся в firmware/BMC. Зафиксируйте эту особенность платформы до того, как строить алерт «AER=0 — всё хорошо».

Отдельный сигнал — replay. PCIe использует механизм повторной передачи, и рост соответствующего счётчика может указывать, что протоколу приходится восстанавливать транзакции. Но опять же: абсолютное число без окна наблюдения и без baseline мало полезно. Снимайте delta за одинаковый интервал под одинаковой нагрузкой и сравнивайте с p95/throughput приложения.

В NVIDIA-стеке часть PCIe-показателей можно получать через NVML/DCGM; для долгоживущей автоматизации предпочтительнее NVML/DCGM, чем парсинг человекочитаемого вывода nvidia-smi, поскольку NVIDIA отдельно предупреждает, что формат NVSMI не гарантирует обратную совместимость.

START=$(date -Is)
echo "start=$START"
# запустите один и тот же canary workload
sleep 60
journalctl -k --since "$START" | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid'
# На поддерживаемых системах проверьте sysfs AER counters для endpoint/upstream port:
find /sys/bus/pci/devices/0000:65:00.0 -maxdepth 1 -type f -name 'aer_*' -print -exec cat {} \;

Докажите влияние на LLM, а не только на PCIe-счётчик

Даже если вы нашли AER и current link ниже baseline, этого недостаточно для коммерчески значимого вывода. Production-вопрос звучит не «есть ли ошибка PCIe», а «мешает ли она полезной работе». Поэтому разделите infrastructure gate и application gate.

Infrastructure gate считается пройденным, когда identity однозначна, topology известна, current link сопоставлен с capability и peer baseline, а AER/replay измеряются в фиксированном окне. Application gate — отдельный эксперимент: один и тот же prompt set, те же model revision, batch/concurrency, CPU affinity, tokenizer path и network path. Сравнивайте request throughput и latency, а не только GPU utilization.

Особенно аккуратно с prefilling и streaming. Workload, который часто передаёт большие host buffers, может сильнее проявлять деградацию PCIe, чем steady-state decode с данными уже в VRAM. Поэтому canary должен представлять реальный traffic mix. Если проблема видна только в synthetic host-to-device copy benchmark, а production SLO не меняется, вы доказали механизм, но не доказали влияние на сервис.

Для NUMA-проверок используйте отдельный runbook NUMA-locality для GPU-инференса: remote memory может имитировать часть симптомов, но это другой слой.

Triage: software, retrain или физический путь

Когда evidence собран, можно выбирать действие. Если link state соответствует baseline, AER не растёт, а application gate деградирован, оставайтесь на software path: драйвер, runtime, NUMA, CPU, storage, network или сама модель. Не надо «на всякий случай» трогать PCIe reset.

Если current speed/width ниже ожидаемого и состояние появилось после boot или maintenance, сначала ищите наименее разрушительный способ подтвердить гипотезу. Для production-узла это обычно drain workload, фиксация evidence, затем контролируемый reboot в maintenance window. Ручной reset bridge или endpoint может затронуть другие устройства в той же иерархии; Linux AER recovery для серьёзных ошибок тоже способен выполнять reset выше originator. Поэтому topology должна быть известна до любого воздействия.

Если после reboot/retrain линия возвращается к baseline и application metric восстанавливается, это сильная корреляция, но ещё не повод закрывать инцидент. Нужен контрфакт: повторите тот же canary и проверьте, не растут ли AER/replay снова. Возвращающаяся деградация указывает на физический путь, signal integrity, riser, слот, питание, board или firmware/BIOS interaction.

Если же link стабилен после холодного старта, но деградирует только под определённой нагрузкой, расследование становится интереснее: коррелируйте температуру платы, питание, BMC SEL, AER delta и workload. Не заменяйте этот анализ снижением PCIe generation «для стабильности» без фиксации причины: такой workaround может скрыть дефект и одновременно урезать capacity.

Когда переходить к riser, слоту и плате

Физическую диагностику начинайте только после software evidence, иначе очень быстро появляется «ремонт методом перестановки». На выключенном и снятом с нагрузки сервере проверьте посадку GPU и riser, крепёж, разъёмы питания, следы перегрева и соответствие riser/slot спецификации платформы. На системах с PCIe switch добавьте его firmware и health в evidence bundle.

Лучший hardware experiment — один контролируемый swap за раз. Перенесли GPU в другой заведомо исправный slot: если проблема следует за картой, подозрение смещается к endpoint. Оставили GPU, заменили riser: если проблема исчезла, у вас локализован элемент пути. Нельзя одновременно переставить карту, заменить riser, обновить BIOS и драйвер, а потом объявить RCA — вы потеряете причинность.

Для каждого swap сохраняйте stable identity новой комбинации: serial/UUID GPU, BDF, slot label из документации сервера, upstream Root Port, BIOS version. После каждого изменения повторяйте те же два gate: infrastructure и application. Симметрия важна — одни и те же проверки до и после изменения позволяют отличить реальное исправление от случайного изменения нагрузки.

Если сервер арендованный или размещён у провайдера, именно здесь ценность ownership становится практической: нужна возможность drain узла, получить BMC/firmware evidence, выполнить замену riser/slot и вернуть прежнюю конфигурацию. Это не обещание «dedicated быстрее»; это граница управляемости, без которой такой RCA часто останавливается на гипотезе.

Что вынести в постоянный мониторинг

После инцидента не стоит превращать все найденные счётчики в paging alerts. Хороший мониторинг PCIe строится слоями. Первый слой — inventory: GPU UUID/BDF, ожидаемый speed/width и upstream path. Второй — error telemetry: AER и поддерживаемые PCIe counters. Третий — application SLO. Срабатывать должна комбинация, а не любой одиночный correctable event.

Практический pattern: alert высокого приоритета, если current link отличается от expected baseline и одновременно деградирует application metric. Средний приоритет — sustained рост error/replay delta на конкретном BDF без SLO impact; это повод для плановой проверки. Единичный correctable warning можно оставить как event для расследования, а не будить команду ночью.

Для скриптов и exporter-логики лучше опираться на NVML/DCGM или стабильный structured interface, а не на свободный текст nvidia-smi -q. NVSMI удобен для ручной диагностики, но NVIDIA не гарантирует обратную совместимость его текстового вывода. Для AER Linux предоставляет статистику в sysfs на поддерживаемых системах; учитывайте, что firmware ownership через ACPI _OSC влияет на то, что именно увидит ОС.

GPU=0
STAMP=$(date -Is)
echo "timestamp=$STAMP"
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,utilization.gpu,power.draw,temperature.gpu --format=csv,noheader
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
lspci -s "$BDF" -vv | grep -E 'LnkCap:|LnkSta:'
for f in /sys/bus/pci/devices/${BDF}/aer_*; do [ -r "$f" ] && printf '%s=' "$f" && cat "$f"; done

Recovery и rollback: доказательство важнее перезагрузки

Recovery считается успешным не тогда, когда GPU снова появился в nvidia-smi. Нужно восстановить всю цепочку доказательств. Сначала identity: тот ли endpoint и тот ли slot. Затем effective link state: speed/width вернулись к expected baseline. Потом error window: AER/replay не демонстрируют прежний паттерн. И только после этого application canary подтверждает SLO.

Rollback должен быть заранее определён. Если изменение включало BIOS option, firmware, перестановку riser или новый driver, вы должны знать, как вернуться к предыдущей комбинации. Особенно опасны инциденты, где несколько действий дают временное улучшение: без rollback вы не поймёте, что действительно повлияло на линию.

Полезный контрфакт — вернуть прежнюю конфигурацию на canary, если это безопасно, и проверить, возвращается ли симптом. Для аппаратного дефекта такой эксперимент не всегда разумен: не нужно повторно создавать потенциально fatal состояние ради красивого RCA. В этом случае достаточно устойчивой связи «дефектный элемент → ошибка» и «замена элемента → стабильный baseline» при одинаковом workload.

Отдельно документируйте ownership. Кто имеет право drain узел, кто меняет BIOS, кто работает с железом, кто принимает SLO после возврата. Hardware runbook без owner часто зависает именно в момент, когда диагностика уже доказала проблему, но никто не хочет брать риск физического действия.

Решение по узлу: вернуть в пул, наблюдать или вывести

Не каждый PCIe incident требует немедленной замены сервера. Решение удобно формализовать. Вернуть узел в production можно, если negotiated link устойчиво соответствует baseline, error delta не возвращается в canary-окне, application SLO восстановлен и причина изменения понятна. Если причина не доказана, но симптомы исчезли после reboot, разумнее оставить узел под наблюдением или в пониженном blast radius, а не сразу считать его исправным.

Выводите узел из пула, если деградация воспроизводится, link снова downtrain после нагрузки, появляются uncorrectable/fatal события, устройство теряется или recovery затрагивает соседние endpoints. То же относится к повторяющемуся дефекту riser/slot: workaround вроде принудительного более низкого поколения может быть допустим временно только как явно зафиксированное operational решение с capacity impact и сроком устранения.

Для LLM-платформы полезно хранить topology class как часть inventory: модель сервера, BIOS, CPU, slot, riser, GPU SKU, ожидаемые link parameters. Тогда новый узел не просто «GPU A100/H100/другой», а член конкретного класса с проверяемым baseline. Это облегчает и capacity planning, и замену железа.

Если вам нужна среда, где команда может контролировать BIOS, PCIe topology, reboot window и аппаратную замену, выделенный GPU-сервер даёт такую границу ownership. Но покупать «больше PCIe» без измерения бессмысленно: сначала докажите, что именно link state влияет на ваш workload, и только потом принимайте инфраструктурное решение.

Источники и ограничения runbook

Основные внешние опоры этого runbook — официальная документация Linux Kernel по PCI Express Advanced Error Reporting и документация NVIDIA по nvidia-smi/NVML/DCGM. Linux описывает AER как механизм сбора расширенной информации об ошибках, их вывода и recovery; отдельно подчёркивает классификацию correctable/uncorrectable и зависимость OS AER от ACPI _OSC. NVIDIA документирует PCI bus ID как стабильный способ адресации GPU и рекомендует NVML для поддерживаемой автоматизации, поскольку текстовый вывод NVSMI может меняться между версиями.

Ссылки: Linux Kernel: PCIe AER Driver Guide HOWTO, NVIDIA System Management Interface documentation, NVIDIA DCGM Feature Overview.

Команды в статье — диагностический baseline, а не универсальная автоматизация для всех платформ. Названия sysfs-файлов, доступность отдельных counters и поведение firmware зависят от kernel, platform firmware и устройства. Перед изменениями на production-сервере сверяйтесь с документацией конкретной модели сервера и maintenance policy.

Вывод: ищите причинность по слоям

PCIe-проблема в GPU-инференсе опасна тем, что может выглядеть как «модель почему-то стала медленнее», а сам ускоритель при этом продолжит отвечать на health-check. Надёжный путь — не начинать с reset и не верить одному счётчику. Зафиксируйте identity, восстановите topology, сравните capability с effective link state, измерьте AER/replay в окне и только затем подтвердите влияние одинаковым application canary.

Если после recovery link вернулся к baseline, повторите те же gate в том же порядке. Если деградация возвращается, переходите к физическому пути — riser, slot, switch, board, power и firmware — меняя только один фактор за раз. Так вы получите RCA, который можно повторить, а не историю «перезагрузили — вроде прошло».

Практический следующий шаг простой: выберите один здоровый и один подозрительный GPU-узел, снимите одинаковый evidence bundle и сохраните expected topology class. Даже если текущего инцидента нет, этот baseline резко сокращает время диагностики, когда p95 однажды начнёт расти без очевидного GPU error.