PCIe ACS и P2P DMA для multi-GPU LLM: production-runbook

Почему исправные GPU могут обмениваться через длинный путь

Симптом неприятно похож на ошибку приложения: все ускорители видны, CUDA инициализируется, память выделяется, а tensor-parallel LLM плавает по latency или зависает при создании communicator. Команда проверяет модель, меняет NCCL-переменные и перезапускает контейнер. Между тем проблема может находиться ниже — в том, куда PCIe fabric отправляет peer-to-peer транзакции.

Для прямого обмена запрос одного GPU должен дойти до памяти другого без обязательного возврата к CPU root complex. PCI Access Control Services, или ACS, умеет перенаправлять трафик вверх по иерархии. В виртуализированной среде это часть изоляции; на выделенном bare-metal узле такой redirect иногда превращает короткий путь между устройствами под одним switch в длинный маршрут через root.

Типичный инцидент начинается после BIOS update: hardware inventory формально тот же, но первый multi-GPU workload дольше проходит инициализацию. Health-check зелёный, потому что он проверяет наличие устройств, а не межGPU путь. Stop condition на этом этапе простой: не компенсировать симптом tuning-переменными, пока не сохранены topology, ACSCtl, IOMMU state и контрольный P2P-тест.

Эта тема отделена от адресного пространства и размещения BAR. Если платформа ещё не прошла базовую подготовку, сначала полезен runbook про Resizable BAR и Above 4G. Здесь же предполагается, что GPU перечисляются корректно; мы доказываем маршрут, корректность передачи и влияние на реальную LLM-нагрузку.

Главная идея статьи: ACS нельзя лечить одной командой. Нужна цепочка доказательств — pinned hardware identity, effective state, active transfer, application readiness и возврат к исходному состоянию теми же проверками.

P2P DMA: три доказательства вместо одного зелёного OK

Peer-to-peer DMA позволяет устройству инициировать обмен с памятью другого устройства без обязательной staging-копии через host buffer. Документация Linux отмечает границу: внутри одной PCIe hierarchy маршрутизация определена достаточно хорошо, а пересечение root ports и host bridges зависит от платформы. Поэтому одинаковые GPU в соседних слотах не гарантируют одинаковый путь.

Первое доказательство — topology identity. Нужно знать GPU UUID, BDF, родительские bridges и switches. Второе — mechanism availability: сообщает ли драйвер, что read/write P2P разрешены для конкретной направленной пары. Третье — traffic proof: проходит ли реальный перенос данных и использует ли приложение этот маршрут. Команда nvidia-smi topo -m отвечает в основном на первый вопрос, nvidia-smi topo -p2p p — на второй.

Официальная документация NCCL подчёркивает, что положительная P2P-матрица не является полной sanity-проверкой при bare-metal IOMMU и ACS. Это важная практическая оговорка: «OK» означает распознанную capability, но не обещает, что все platform settings совместимы с безопасным и производительным direct path.

Owner слоя topology — platform/SRE, а наблюдаемое доказательство — артефакт с hostname, временем, версиями и связкой UUID↔BDF. Отрицательный контроль — пара GPU, которая физически пересекает более дальний bridge или другой root port. Если положительная и отрицательная пары неразличимы во всех тестах, выбранный тест недостаточно чувствителен.

Не делайте вывод по одной средней скорости. Сначала корректность данных и отсутствие hang, затем сравнение на фиксированном binary. Любые универсальные цифры здесь были бы выдумкой: предел задают поколение PCIe, ширина link, switch, GPU, firmware и layout конкретного сервера.

Что означает ACSCtl и почему SrcValid+ — только улика

ACS — набор возможностей downstream port или PCIe switch. В полном выводе lspci -vvv есть capability и control state. Строка ACSCtl с SrcValid+ показывает включённую source validation, а redirect-флаги могут заставлять peer traffic подниматься к root complex. Но одна строка без дерева устройств не доказывает, что этот bridge лежит на пути проблемной пары.

Представьте развязку: два GPU находятся под одним switch и могли бы обмениваться на нижнем уровне. Redirect закрывает короткий съезд и отправляет обе транзакции через центр. Иногда это требование trust boundary. Иногда — BIOS default, не соответствующий роли выделенного inference-узла. Диагностика должна различить эти случаи до write-команды.

NCCL предлагает искать ACS через lspci -vvv | grep ACSCtl и для некоторых PLX/Broadcom bridges на bare metal показывает механизм изменения control word через setpci. Это не переносимый desired state. Адрес extended capability, поддержка firmware и последствия записи проверяются по документации производителя сервера; исходное значение регистра сохраняется обязательно.

Stop condition: BDF не сопоставлен с нужной GPU-парой; на хосте есть VM passthrough, SR-IOV или неизвестные DMA isolation requirements; отсутствует out-of-band доступ; после read-only сбора появились AER/Xid. Любой из этих пунктов закрывает change window до уточнения.

Нельзя оценивать ACS отдельно от IOMMU groups. Глобальный override способен изменить isolation semantics для других devices. Поэтому мы не используем «скрипт по всем BDF» как первый шаг и не советуем kernel override ради производительности.

set -euo pipefail
stamp=$(date -u +%Y%m%dT%H%M%SZ)
out="pcie-evidence-$stamp"
mkdir -p "$out"
nvidia-smi --query-gpu=index,uuid,pci.bus_id --format=csv > "$out/gpu-map.csv"
nvidia-smi topo -m > "$out/topology.txt"
nvidia-smi topo -p2p p > "$out/p2p-pcie.txt"
lspci -tv > "$out/lspci-tree.txt"
sudo lspci -vvv > "$out/lspci-vvv.txt"
grep -n "ACSCtl" "$out/lspci-vvv.txt" > "$out/acsctl.txt" || true
cat /proc/cmdline > "$out/proc-cmdline.txt"
dmesg | grep -i -E "iommu|dmar|default domain" > "$out/iommu.txt" || true

Evidence bundle до первого setpci и reboot

Хороший runbook начинается не с изменения, а с возможности доказать, что изменилось. Собирайте evidence тем же пользователем и в том же container namespace, где будет работать сервис. NCCL использует /sys для topology discovery; урезанный или виртуализированный sysfs может дать suboptimal решение ещё до collective.

В bundle входят версии BIOS, kernel, driver, CUDA и NCCL; GPU UUID/BDF; дерево PCIe; полный ACS capability/control state; IOMMU effective mode; состояние links; точная команда теста. Привяжите архив к maintenance ticket. После reboot BDF могут измениться, и без UUID вы легко сравните разные устройства как одно.

Static baseline фиксирует состав и route. Active baseline проверяет доступ и перенос. Application baseline использует ваш закреплённый model artifact, engine image, tensor-parallel size, запросы и warmup. Не называйте один прогон benchmark: задача — получить воспроизводимый до/после сигнал на одном canary.

Пример: GPU0 и GPU1 под одним switch — положительный кандидат. GPU0 и GPU2 пересекают host bridge — отрицательная граница. Если после изменения обе пары меняются одинаково, вероятнее всего, вы измерили CPU scheduling, warm cache или иной слой. Полезный контрфакт меняет только предполагаемую причину.

Добавьте owner и критерии. Platform owner отвечает за PCIe state, ML platform — за NCCL binary, service owner — за LLM probe. Смешивание ответственности приводит к ситуации, когда каждая команда видит зелёный локальный тест, но никто не подтверждает end-to-end readiness.

Bare metal и VM: почему один рецепт опасен

Самая дорогая ошибка — перенести bare-metal совет на hypervisor. В актуальной документации CUDA/NCCL translated IOMMU на Linux bare metal указан как несовместимый с поддерживаемым PCIe peer path NVIDIA; для VM, напротив, IOMMU и ACS обеспечивают isolation, а максимальная производительность зависит от корректной поддержки ATS и passthrough.

Первое поле change request — роль хоста: dedicated bare metal, hypervisor, guest или container на bare metal. Контейнер не равен VM, но может скрыть sysfs и devices. Гипервизор меняет trust boundary; отключение ACS там не является допустимым performance experiment.

Проверяйте /proc/cmdline и kernel messages о IOMMU/default domain. Формулировки зависят от платформы и версии ядра. Вы ищете effective state для GPU path, а не одну магическую строку. Intel DMAR/VT-d и AMD-Vi требуют platform-specific решения и vendor guidance.

Owner bare-metal change — владелец GPU pool вместе с firmware/platform owner. Owner VM path — virtualization и security teams. Stop condition — неизвестная зависимость от passthrough или DMA isolation. Материал про VFIO и IOMMU для GPU passthrough подробнее разбирает среду, где isolation важнее bare-metal короткого пути.

Если узел одновременно обслуживает доверенный LLM workload и недоверенные devices, правильным решением может быть физическое разделение ролей. Низкоуровневая настройка не должна превращать mixed-tenant платформу в неявный dedicated host.

Минимальное изменение: один canary и один подтверждённый bridge

Когда evidence подтверждает bare-metal роль, нужную GPU-пару под ACS-enabled switch и допустимость изменения, выберите один canary. Выведите его из scheduler, остановите GPU workloads и сохраните исходный ACS word для каждого затрагиваемого BDF. Не применяйте цикл ко всем PCI devices: удобство не оправдывает blast radius.

Для поддерживаемого PLX bridge NCCL показывает запись нулевого control word через setpci. Считайте это примером механизма. На части платформ устойчивый путь — BIOS option; runtime write исчезнет после reboot. Firmware update также способен перестроить topology.

У change gate три элемента. Owner выполняет запись. Evidence — read-back плюс неизменный inventory GPU/NIC/NVMe. Stop condition — исчез device, изменились IOMMU groups, появились AER/Xid, read-back не совпал или management access нестабилен. При stop выполняется rollback до запуска NCCL.

Отрицательная граница: bridge вне пути проверяемой пары не трогают. Если результат требует глобального отключения ACS, остановитесь и вернитесь к архитектуре сервера. Возможно, правильнее разместить GPU под одним switch или выбрать другой dedicated chassis.

Для автоматизации используйте fail-closed discovery: сначала GPU UUID, затем текущий BDF и родительский bridge, затем vendor/device ID и ожидаемая topology signature. Любое несовпадение завершает unit без write. Жёстко заданный BDF после firmware update опасен.

set -euo pipefail
bridge="03:00.0"   # заменить после сопоставления с lspci -tv
before=$(sudo setpci -s "$bridge" ECAP_ACS+0x6.w)
printf '%s %s
' "$bridge" "$before" | sudo tee /var/tmp/acs-before.txt
sudo setpci -s "$bridge" ECAP_ACS+0x6.w=0000
after=$(sudo setpci -s "$bridge" ECAP_ACS+0x6.w)
printf 'ACSCtl word: before=%s after=%s
' "$before" "$after"
test "$after" = "0000"

Infrastructure gate: topology, active P2P и NCCL

После изменения повторите те же read-only проверки. Сначала UUID↔BDF и PCIe tree: никакой device не исчез. Затем ACSCtl/read-back и IOMMU state. Только при совпавшем inventory запускайте P2P matrix; изменение порядка усложняет локализацию сбоя.

Следующий уровень — active transfer. В NCCL 2.31 появились opt-in active diagnostics, которые проверяют ожидаемые directed P2P edges передачей и валидацией данных. Это свежая возможность, отключённая по умолчанию: указывайте точную версию. Для закреплённых старых стеков используйте согласованный CUDA sample или nccl-tests из собственного artifact registry.

Положительный gate: ожидаемые P2P edges проходят data check, collective завершается без hang и неожиданного fallback. Отрицательный контроль: тот же binary с NCCL_P2P_DISABLE=1. Это не production tuning, а контрфакт. Если результат полностью одинаков, workload мог не использовать P2P или bottleneck находится в другом месте.

nvidia-smi topo и dcgmi topo описывают отношения, но не резервируют hardware и не измеряют bandwidth. Для NVSwitch отдельный control plane ведёт Fabric Manager; смежный runbook — NVIDIA Fabric Manager и NVSwitch. Не пытайтесь исправить его состояние через PCIe ACS.

Сохраняйте stdout, NCCL logs и exit codes как единый evidence set. Средняя скорость без correctness и ошибок недостаточна. Сначала отсутствие data corruption и hang, затем повторяемый performance comparison.

set -euo pipefail
nvidia-smi topo -m
nvidia-smi topo -p2p p

# Для NCCL 2.31+: active diagnostics являются opt-in
NCCL_RUN_DIAGNOSTICS=1 NCCL_DEBUG=INFO   ./all_reduce_perf -b 8M -e 256M -f 2 -g 4 | tee nccl-p2p-enabled.log

# Контрфакт: те же binary и параметры, P2P отключён
NCCL_P2P_DISABLE=1 NCCL_DEBUG=INFO   ./all_reduce_perf -b 8M -e 256M -f 2 -g 4 | tee nccl-p2p-disabled.log

Application gate: докажите результат на реальном LLM

Идеальный all-reduce не гарантирует улучшения LLM. Model-parallel layout может связывать другие GPU-пары, CPU affinity — заставлять input pipeline пересекать NUMA, batching — скрывать межGPU задержку. Application gate идёт после infrastructure gate, но оценивается отдельно.

Закрепите model revision, tokenizer, engine image, tensor-parallel size, набор запросов, concurrency и warmup. Смотрите readiness, ошибки communicator, latency distribution и useful throughput. Не меняйте batch size между «до» и «после». Если модель не загружается, это FAIL независимо от nccl-tests.

Безопасный контрфакт — временно отключить P2P только для тестового процесса, а затем вернуть обычный launcher. Если application metric меняется в ожидаемую сторону только при исправном P2P, attribution усиливается. Если нет, проверьте перенос bottleneck на CPU, storage, memory pressure или network.

Не формулируйте «отключение ACS ускоряет LLM» как общее правило. Защищаемый вывод звучит точнее: на конкретном hardware/firmware/software baseline восстановлен direct path выбранных GPU-пар, collective прошёл, а фиксированный workload вернулся к своему диапазону.

При Xid или AER stop condition срабатывает немедленно. Это уже incident response, а не performance change. Используйте отдельный runbook по ошибкам NVIDIA Xid, чтобы не смешивать аппаратный сбой с маршрутизацией.

Что чаще всего ломает честный вывод

Первая ловушка — сравнить холодный baseline с прогретым сервисом после change. Модельные weights, filesystem cache, JIT и allocator state должны проходить одинаковую процедуру. Иначе PCIe получает чужую заслугу.

Вторая — проверить только соседние индексы GPU. Индекс не равен физической близости и может измениться после reboot. Работайте через UUID/BDF и directed pairs. Третья — считать SrcValid+ достаточным обвинением. Нужны parent bridge, control bits и active test.

Четвёртая — оставить global kernel override ради одного canary. Он меняет semantics шире выбранной пары и способен ослабить isolation. Пятая — запустить production с тестовой переменной NCCL_P2P_DISABLE; контрфакт должен жить только в отдельном launcher и иметь time limit.

Шестая — следить лишь за throughput. P2P-проблема может проявляться хвостом latency, зависанием communicator или ошибкой данных. Собирайте correctness, readiness, p95/p99 внутри вашего измерительного контура, error rate и resource counters, но не обещайте чужие численные пороги.

Наконец, не смешивайте remediation и architecture. Если topology физически пересекает root complexes, ACS write не превратит её в one-switch path. Иногда честный результат диагностики — требование к другому размещению ускорителей или другой платформе.

Симметричный rollback и повторная сертификация после обновлений

Rollback — не обратная команда, а возврат доказанного состояния. Верните сохранённый ACS word или BIOS option, выполните нужный reboot, заново сопоставьте UUID/BDF, повторите topology, P2P, NCCL и тот же LLM probe. Если configuration вернулась, а application baseline нет, rollback не завершён.

Startup automation не должна доверять фиксированным BDF. После firmware update адрес может принадлежать другому bridge. Устойчивый unit вычисляет путь заново, сверяет vendor/device IDs и topology signature, а при несовпадении прекращает работу без write.

После каждого BIOS, firmware, kernel или driver update evidence считается устаревшим. Canary проходит тот же gate sequence; только затем обновляется золотой образ. Это сохраняет versioned proof и делает regression видимой, а не спрятанной в случайном workload.

Owner закрывает change ticket лишь после возврата узла в scheduler и успешного service readiness. Security/virtualization owner отдельно подтверждает, что isolation assumptions не изменились. Для арендованного dedicated GPU сервера запросите у провайдера topology и доступные firmware options до миграции модели.

Храните короткую запись: причина, затронутые BDF, before/after control word, версии, ссылки на evidence, результат положительного и отрицательного контроля. Такой журнал полезнее набора «магических» команд без контекста.

Вывод: короткий P2P-путь подтверждается цепочкой gates

PCIe ACS действительно способен мешать multi-GPU P2P, но лечить его нужно как control-plane change. Topology показывает, где искать; ACSCtl и IOMMU — effective state; active P2P/NCCL доказывает механизм; закреплённый LLM workload — прикладной результат. Пропуск звена оставляет правдоподобную, но недоказанную историю.

Для bare-metal canary действуйте узко: evidence bundle, одна GPU-пара, один подтверждённый bridge, read-back, infrastructure gate, application gate и те же проверки в rollback. Для VM не переносите bare-metal рецепт: ACS и IOMMU являются частью isolation, оптимизация идёт через поддерживаемый passthrough/ATS path.

Начните с read-only части на одном узле. По PCIe tree, ACSCtl, IOMMU state и P2P matrix станет понятно, есть ли основания открывать maintenance window. Не требуется рисковать production, чтобы получить первый полезный ответ.

Если нужна инфраструктура с предсказуемой multi-GPU topology, обсудите с King Servers конкретные GPU-пары, switches, firmware mode и модель эксплуатации до переноса LLM. Тогда аппаратная схема становится проверяемым требованием, а не сюрпризом после запуска. Следующий шаг прост: сохраните baseline сегодня, пока узел работает спокойно, и превратите его в canary gate для будущих обновлений.