NVIDIA Fabric Manager и NVSwitch: production-runbook для multi-GPU LLM

Восемь GPU видны в nvidia-smi, но первая NCCL-операция зависает, а LLM-сервис отвечает cudaErrorSystemNotReady. Часто проблема находится ниже приложения: Fabric Manager не завершил инициализацию NVSwitch, версии пакетов разошлись или один link уже выпал из fabric. Ниже — production-runbook, который отделяет готовность инфраструктуры от готовности модели и не маскирует аппаратный сигнал перезапуском контейнера. В результате у дежурного появляется проверяемая цепочка gates, evidence и понятный rollback.

Где заканчивается Fabric Manager и начинается LLM

На NVSwitch-системе зелёный nvidia-smi ещё не означает, что multi-GPU LLM готов принимать трафик. Драйвер может увидеть все GPU, а fabric при этом не завершила инициализацию, отдельный link остаётся down или служба Fabric Manager запущена в несовместимой с драйвером версии. Типичный симптом — приложение стартует дольше обычного, NCCL зависает на первой коллективной операции либо CUDA возвращает cudaErrorSystemNotReady.

Эта статья разбирает single-node control plane: как проверить NVIDIA Fabric Manager, NVLSM, NVSwitch topology и DCGM до запуска модели. Это не повтор материала о multi-node RDMA/RoCE: сеть между серверами начинается после того, как каждый отдельный GPU-узел доказал локальную готовность. Для распределённого контура пригодится руководство про ML-кластер на нескольких GPU-серверах, но смешивать два слоя в одном тесте не стоит.

Рабочая граница проста. Infrastructure gate отвечает на вопрос «fabric собрана и наблюдаема?». Application gate отвечает на вопрос «реальный launcher использует ожидаемые GPU и завершает коллективную операцию?». Только два положительных ответа дают основание запускать vLLM, NIM или training job; один успешный systemctl status не заменяет второй.

Сначала определите, относится ли runbook к вашему серверу. Fabric Manager нужен NVSwitch-based платформам DGX/HGX; на сервере с прямыми NVLink-мостами или только PCIe отсутствие NVSwitch в DCGM discovery нормально. Официальное руководство NVIDIA Fabric Manager описывает службу как control plane, который конфигурирует memory fabric, координирует инициализацию GPU и наблюдает ошибки NVLink/NVSwitch.

Как устроен control plane NVSwitch

У стека несколько владельцев, и путаница между ними дорого стоит во время аварии. Kernel driver создаёт GPU и NVSwitch device state. Fabric Manager координирует инициализацию и, для ранних поколений NVSwitch, маршрутизацию. На B100/B200/B300 и более новых системах в service unit участвует NVLink Subnet Manager: NVLSM обнаруживает fabric, назначает идентификаторы портам, рассчитывает forwarding tables и программирует PKEY.

DCGM находится сбоку от control plane. Он обнаруживает GPU, switch и link entities, читает счётчики, health и диагностические результаты. Ограничение из документации DCGM по topology и links: DCGM наблюдает fabric, но не конфигурирует NVSwitch и не поднимает link. Поэтому dcgmi nvlink --link-status полезна для evidence, а лечить ею отсутствующую конфигурацию нельзя.

Приложение стоит выше. PyTorch, vLLM или NVIDIA NIM видит итог работы driver, FM/NVLSM и runtime. Процесс может перечислить восемь CUDA devices, но первая NCCL all-reduce выявит разрыв, незаметный при простом inventory. Для эксплуатации NIM отдельно пригодится материал про установку и health-check NVIDIA NIM; здесь нас интересует readiness узла до старта контейнера.

Не копируйте entity ids между хостами. DCGM предупреждает, что switch и link identifiers относятся к runtime inventory конкретного host engine. После перезагрузки, замены платы или обновления DCGM сначала выполняйте discovery заново, затем подставляйте найденные ids в мониторинг. Это маленькая деталь, которая отличает воспроизводимый runbook от команды, работающей только на машине автора.

Снимите baseline до любого изменения

Хороший baseline — не скриншот «всё зелёное», а воспроизводимый набор текстовых артефактов. Сохраните версии драйвера, Fabric Manager и DCGM, список PCI devices, topology matrix, switch inventory, состояние каждого link и свежий kernel log. Такой пакет позволяет сравнить узел до и после change, а не спорить по памяти о том, сколько портов было видно вчера.

nvidia-smi topo -m показывает связи GPU, CPU affinity и квалифицированные NIC; расшифровка SYS, NODE, PHB, PXB и PIX есть в официальной документации nvidia-smi. Для NVSwitch ориентируйтесь не только на матрицу: DCGM discovery и link-status дают отдельные сущности switch ports.

set -o errexit -o nounset -o pipefail
date -Is
uname -a
nvidia-smi
nvidia-smi topo -m
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
systemctl status nvidia-fabricmanager --no-pager
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 200
journalctl -k -b --no-pager | grep -Ei 'NVRM|Xid|SXid|NVSwitch|NVLink' || true

Не превращайте скрипт в автоматический PASS. На хосте без NVSwitch отсутствие switch entities ожидаемо; на HGX с NVSwitch — стоп-сигнал. Сопоставьте inventory с паспортом платформы и утверждённой конфигурацией. Проверяли ли вы, что число GPU совпадает не с «обычно восемь», а с конкретным SKU и partition mode?

Сохраните вывод в change ticket вместе со временем и серийными идентификаторами. Не записывайте только средний throughput: один неактивный port может потеряться в агрегации. Базовая единица расследования — конкретный GPU, switch и link entity, найденные на этом хосте сейчас. Добавьте checksum артефактов, если ticketing system позволяет прикреплять архивы: так проще доказать, что baseline не был заменён после инцидента.

Согласуйте версии driver и Fabric Manager

Самая приземлённая причина неготовой fabric — пакеты из разных веток. NVIDIA требует устанавливать Fabric Manager той же версии, что и Data Center GPU Driver. На B200/B300 добавляется NVLSM dependency и требования платформы к OFED/MOFED; для service VM руководство указывает также минимальные требования к kernel. Не переносите эти условия на A100 или H100 автоматически: сначала определите поколение baseboard.

Проверяйте установленные пакеты, а не только имя репозитория. На Debian/Ubuntu используйте dpkg-query, на RPM-системах — rpm -qa. Названия зависят от ветки и дистрибутива, поэтому команды ищут по шаблону и не прибивают номер версии гвоздями.

nvidia-smi --query-gpu=driver_version --format=csv,noheader | sort -u
dpkg-query -W 'nvidia-driver-*' 'nvidia-fabricmanager-*' 'nvlsm*' 2>/dev/null || true
rpm -qa | grep -E 'nvidia.*driver|fabricmanager|nvlsm' | sort || true
systemctl cat nvidia-fabricmanager
/usr/bin/nv-fabricmanager --version 2>/dev/null || true

Зафиксируйте пару «driver branch + FM package» как один version lock в Ansible, image manifest или change plan. Отдельное обновление драйвера оставляет службу на старой версии; отдельное обновление FM столь же опасно. После изменения нужен reboot или предусмотренная производителем последовательность reload, а затем полный baseline и gates с нуля.

Не редактируйте vendor unit в /lib/systemd/system без крайней необходимости: package update может заменить файл. Для override используйте systemctl edit и документируйте причину. Практический rollback — заранее доступные пакеты предыдущей согласованной пары и окно, в котором узел выведен из scheduler. «Понизим потом из репозитория» — не план: нужная версия может исчезнуть или потянуть неожиданные зависимости.

Infrastructure gate: докажите готовность fabric

Infrastructure gate должен быть бинарным и послойным. Сначала driver видит ожидаемые GPU. Затем service unit active, а journal не содержит незавершённой инициализации. После этого DCGM обнаруживает NVSwitch и показывает ожидаемые links up. Наконец, health или diagnostic run не возвращает действий isolate/reset. Если один слой не прошёл, верхние тесты не компенсируют провал.

На B200/B300 один unit может управлять FM и NVLSM, поэтому смотрите процессы и journal. По руководству Fabric Manager, операции выполняются через systemctl start|stop|status nvidia-fabricmanager, журнал читается через journalctl -u. После старта дождитесь завершения fabric initialization; мгновенный active не гарантирует configured.

systemctl is-enabled nvidia-fabricmanager
systemctl is-active nvidia-fabricmanager
systemctl show nvidia-fabricmanager -p ActiveEnterTimestamp -p ExecMainStatus
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 300
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
nvidia-smi topo -m

PASS означает: все предусмотренные платформой GPU и switch entities присутствуют, ожидаемые links up, topology соответствует baseline, новых Xid/SXid нет. Отрицательная граница столь же важна: если discovery не показывает NVSwitch на системе, где он обязан быть, не расширяйте привилегии приложению и не отключайте проверки. Остановитесь на infrastructure layer и разберитесь с driver/FM/device binding.

Пример: после обновления узел показывает восемь GPU, но DCGM discovery не содержит switches. Перезапуск vLLM ничего не меняет, потому что проблема ниже контейнера. Правильное действие — закрыть scheduler admission, проверить согласование пакетов, unit/journal и только затем повторить gate. Так диагностическая ошибка не превращается в серию упавших пользовательских запросов.

Сохраните результат gate машинно-читаемым: число ожидаемых сущностей, список down/disabled links и timestamp последнего события. Тогда автоматизация может отказать admission по конкретной причине, а не по расплывчатому «GPU unhealthy». Но не подменяйте hardware profile универсальным числом: разные HGX поколения имеют разную topology.

Application gate: проверьте реальный launcher

Даже идеальный infrastructure gate не доказывает, что service unit, контейнер или Kubernetes pod видит нужные devices. Application gate запускается в том же окружении, с теми же cgroup/device permissions и переменными, что production workload. Для PyTorch минимальный тест — NCCL all-reduce между всеми локальными rank: он создаёт CUDA tensor на каждом GPU и проверяет одинаковую сумму после коллективной операции.

Сохраните скрипт как immutable artifact и запускайте через фактический Python environment приложения. Ожидаемое число процессов задавайте из inventory платформы, а не вшивайте восемь во все серверы. В примере восемь — явный resource budget для конкретного восьми-GPU узла, а не универсальная настройка.

import torch
import torch.distributed as dist

dist.init_process_group("nccl")
rank = dist.get_rank()
world = dist.get_world_size()
torch.cuda.set_device(rank)
value = torch.tensor([rank + 1.0], device=f"cuda:{rank}")
dist.all_reduce(value)
expected = world * (world + 1) / 2
assert value.item() == expected, (rank, value.item(), expected)
torch.cuda.synchronize()
if rank == 0:
    print(f"PASS: {world} ranks, all_reduce={value.item():.0f}")
dist.destroy_process_group()

torchrun --standalone --nproc-per-node=8 fabric_smoke.py

CUDA_VISIBLE_DEVICES=0 python3 - <<'py' import torch assert torch.cuda.device_count()="=" 1, print('pass: launcher boundary exposes one gpu') py< code>

Отрицательный тест не ломает fabric: он проверяет, что launcher действительно ограничивает видимость. Если процесс всё равно видит больше одного GPU, проблема в изоляции, а успешный all-reduce не даёт права пускать multi-tenant workload. Для MIG/MPS правила другие; их сверяйте с руководством по MIG и MPS для multi-tenant GPU.

После smoke test запускайте readiness модели: загрузка весов, один контролируемый inference request и проверка логов. Не используйте latency одного запроса как benchmark; здесь нужен functional gate. Если infrastructure PASS, а all-reduce падает, область поиска уже узкая: launcher, NCCL/runtime, device mapping или container permissions, а не весь сервер.

Повторите тест из штатного launcher, а не только из интерактивной root shell. Разница в device cgroup, mount namespace или переменных окружения часто объясняет случай «у администратора работает». Фиксируйте world size, image digest и commit smoke script рядом с результатом.

Xid и SXid: как не потерять контекст ошибки

Xid — сообщение NVIDIA driver в kernel log. SXid — аналогичный класс сообщений от NVSwitch driver. Справочник NVIDIA Xid Errors разделяет источники: номер важен, но без модели GPU, driver version, времени, workload и соседних событий его недостаточно для решения.

При событии сначала заморозьте контекст. Закройте узел для новых заданий, но не перезагружайте автоматически: reboot стирает часть volatile evidence. Снимите journalctl -k, журнал FM/NVLSM, nvidia-smi -q, discovery и link-status. Затем определите, fatal ли событие, требуется ли reset/isolate и повторяется ли оно на том же port.

incident_dir="/var/tmp/nvswitch-incident-$(date +%Y%m%dT%H%M%S)"
install -d -m 0700 "$incident_dir"
journalctl -k -b --no-pager > "$incident_dir/kernel.log"
journalctl -u nvidia-fabricmanager -b --no-pager > "$incident_dir/fabricmanager.log"
nvidia-smi -q > "$incident_dir/nvidia-smi-q.txt"
nvidia-smi topo -m > "$incident_dir/topology.txt"
dcgmi discovery --list > "$incident_dir/dcgm-discovery.txt"
dcgmi nvlink --link-status --show-entity-ids > "$incident_dir/nvlink-status.txt"
tar -C /var/tmp -czf "$incident_dir.tar.gz" "$(basename "$incident_dir")"

DCGM публикует отдельные NVSwitch поля для fatal/non-fatal SXid, link errors, replay/recovery/CRC/ECC counters и reset-required. В актуальном каталоге DCGM field identifiers ids расширяются по поколениям, поэтому старый список без проверки dcgmi dmon --list рискован.

Не лечите каждый non-fatal counter reboot’ом. Сравните его с baseline и проверьте прирост: старое ненулевое значение без новых событий отличается от растущего счётчика под нагрузкой. Fatal SXid, link down или reset-required — другой класс: workload удерживать на узле нельзя до выполнения рекомендаций NVIDIA и повторных gates.

Знакомая ловушка — увидеть Xid приложения и сразу винить NVSwitch. Сопоставьте timestamps: если SXid и link error появились раньше NCCL timeout, fabric — сильный кандидат. Если fabric стабильна, а ошибка возникла только в одном контейнере после смены image, расследование должно подняться на application layer. В incident report разделяйте факт, гипотезу и принятое действие: это уменьшает число необоснованных reboot.

Мониторинг без ложного зелёного статуса

Для steady state собирайте три группы сигналов: состояние links, события Xid/SXid/reset-required и динамические counters температуры, throughput и ошибок. Один общий «GPU healthy» слишком груб: сервер может выдавать inference, пока один путь деградирует и retries постепенно растут. Alert должен указывать host, entity type, switch/link id и изменение значения за интервал.

Документация DCGM по NVSwitch и ConnectX рекомендует сначала обнаруживать ids через discovery и link-status, затем выбирать поля из каталога установленной версии. Switch temperature и aggregate throughput относятся к nvswitch entity, per-port errors — к switch_link. Entity/field mismatch может вернуть N/A; это не доказательство поломки.

dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
dcgmi dmon --list

# Подставьте ids, найденные на текущем хосте.
dcgmi dmon --entity-id nvswitch:0 --field-id 858,861,862 --count 5
dcgmi dmon --entity-id switch_link:0:3 --field-id 780,781,782,783 --count 5

Числа полей в примере соответствуют documented NVSwitch entities, но automation должна сверять их с release на узле. Для NVLink 5+ доступны дополнительные aggregate/per-link counters; на NVLink 4 и старше некоторые поля закономерно возвращают N/A. Маркируйте hardware generation в inventory, иначе одна panel будет показывать «нет данных» и «авария» одинаково.

Свяжите infra alert с application SLI, но не склеивайте их. Рост replay errors без изменения inference может быть ранним предупреждением; рост latency без link errors — повод проверить CPU, storage или scheduler. Если после ремонта fabric latency остаётся высокой, bottleneck мигрировал на соседний слой. Для orchestration и очередей полезен материал про GPU scheduling между inference, training и batch.

Храните raw counters достаточно долго, чтобы видеть скорость изменения, а не только последнее значение. Alert на абсолютный порог без baseline шумит после перезагрузок и замены железа. Отдельно отслеживайте отсутствие scrape: потерянная телеметрия не должна выглядеть как нулевые ошибки.

Recovery: возвращайте узел через те же gates

Recovery начинается не с systemctl restart, а с решения о blast radius. Запретите новые задания, дождитесь или корректно завершите текущие, сохраните evidence и только затем меняйте состояние FM, driver или хоста. В руководстве есть ABORT_CUDA_JOBS_ON_FM_EXIT, но поведение зависит от поколения и deployment model; на H100 и более новых системах часть опций неприменима. Не предполагайте, что stop FM безвреден для текущих CUDA jobs.

Если ошибка появилась после package change, предпочтительный rollback — последняя согласованная пара driver/FM, а не ещё одно обновление вперёд. Если журнал и DCGM указывают reset/isolate, следуйте runbook производителя платформы: software restart не заменяет power cycle или замену компонента, когда требуется hardware action.

systemctl is-active nvidia-fabricmanager
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 300
nvidia-smi
nvidia-smi topo -m
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
journalctl -k -b --no-pager | grep -Ei 'NVRM|Xid|SXid|NVSwitch|NVLink' || true
torchrun --standalone --nproc-per-node=8 fabric_smoke.py

После reboot не сравнивайте только количество GPU. Повторите infrastructure gate, затем application gate и один LLM readiness request. Сравните topology и entity inventory с baseline. Если приложение заработало, но counter продолжает расти, узел не готов: локальное улучшение не отменяет деградацию.

Контрфактическая проверка помогает не спутать совпадение с причиной. Верните последнюю согласованную конфигурацию, не меняя одновременно container image и модель; если gates снова PASS, связь с package change подтверждается сильнее. Если проблема остаётся, переходите к hardware/service case с evidence, а не расширяйте список случайных изменений.

В Kubernetes вывод узла и возврат отражайте в scheduler, taints и admission. После восстановления не снимайте cordon до application gate. Общую архитектуру сопоставьте с руководством по KServe, GPU Operator, Kueue и autoscaling, но readiness NVSwitch-узла остаётся отдельным нижним gate.

Production checklist для change и дежурства

Соберите проверки в operational contract. До изменения: platform SKU, driver/FM/NVLSM versions, baseline topology, package rollback и свободное окно. После: service/journal, discovery, links, DCGM health, Xid/SXid, all-reduce и LLM readiness. Во время эксплуатации: alert на link state, fatal/non-fatal events, reset-required и рост error counters с entity labels.

Назначьте владельцев. Platform team отвечает за packages, systemd, firmware и hardware case. SRE — за admission, evidence и alerts. Команда модели — за launcher и application smoke. Когда ownership размыт, авария ходит по кругу: SRE перезапускает контейнер, ML-инженер меняет NCCL variables, platform team узнаёт о down-link последней.

Определите stop conditions заранее. Нет ожидаемого NVSwitch entity, есть link down, fatal SXid, reset-required, несовпадение driver/FM или all-reduce failure — узел не принимает workload. N/A по unsupported field требует уточнения поколения, но не обязательно изоляции. Такие правила делают дежурство предсказуемым и не зависят от уверенности инженера ночью.

Version lock и gates должны жить рядом с provisioning code. Проверка, которую нельзя воспроизвести после следующего обновления, превращается в устную традицию. Храните smoke script, список обязательных entities и ожидаемое число GPU как версионируемые artifacts для каждого server class.

Для каждого gate задайте owner, timeout, evidence path и rollback action. Тогда «проверить NVSwitch» перестаёт быть абстрактным пунктом и становится конечной процедурой. Раз в квартал прогоняйте runbook в maintenance window: аварийная инструкция, которую никто не запускал, обычно содержит устаревшие package names и ids.

Что считать действительно готовым узлом

Готовность NVSwitch-сервера — цепочка доказательств, а не один зелёный процесс. Driver и Fabric Manager согласованы по версии, FM/NVLSM завершили инициализацию, DCGM обнаруживает ожидаемые switch/link entities, topology совпадает с baseline, свежих fatal Xid/SXid нет, а реальный launcher завершает NCCL all-reduce и LLM readiness.

Полезная привычка — разделять infrastructure и application gates. Тогда ошибка локализуется по слою: package/service/fabric, наблюдаемость, launcher или модель. Отрицательная проверка границы и rollback к последней согласованной паре защищают от практики «дать больше прав и перезапустить всё».

Начните с простого шага: снимите baseline одного GPU-узла сегодня, пока он здоров, и сохраните вывод вместе с package versions. Затем превратите команды в change checklist и automation без жёстко скопированных entity ids. Если для multi-GPU LLM нужна выделенная инфраструктура с понятным hardware profile и окном обслуживания, параметры сервера согласуйте вместе с gate-планом, а не после первого инцидента.