GPUDirect RDMA через DMA-BUF: переход с nvidia-peermem для multi-node LLM

Симптом: RDMA есть, а прямой GPU↔NIC путь не доказан

Начните не с модулей, а с наблюдаемого расхождения. Например, два одинаковых GPU-узла работают на одной версии приложения и используют один fabric, но на одном растёт загрузка CPU и память хоста становится заметной частью data path, а на другом обмен остаётся ближе к ожидаемому GPU-centric профилю. Это повод проверить registration path. Сам по себе низкий throughput ничего не доказывает: причина может быть в MTU, routing, PFC/ECN, PCIe topology, NUMA, CPU pinning или вообще в TCP fallback.

Disqualifier важен сразу. Если rdma link уже показывает проблему, NIC не поднимается, ib_write_bw на обычной host memory нестабилен или два узла не видят друг друга по RDMA, сначала чините сеть. DMA-BUF не исправляет fabric. Точно так же миграция registration path не должна становиться способом «вылечить» плохой PCIe: для низкоуровневых P2P-проблем полезен отдельный runbook по PCIe ACS и P2P DMA.

Цель этой статьи уже: доказать, какой kernel path регистрирует GPU memory для RDMA, подтвердить реальную передачу из GPU memory, затем проверить NCCL и только после этого смотреть на LLM SLO. Если application metric не меняется, улучшение низкоуровневого счётчика остаётся доказательством механизма, а не бизнес-эффекта.

DMA-BUF и nvidia-peermem: что на самом деле меняется

GPUDirect RDMA позволяет peer-устройству — обычно RDMA NIC — работать с GPU memory без обязательной промежуточной копии через host memory. В Linux для этого нужен механизм регистрации и обмена memory handles. В современном стеке NVIDIA таким механизмом может быть стандартный DMA-BUF; legacy-вариант использует модуль nvidia-peermem и peer-memory API.

В документации NVIDIA GPU Operator 26.3 DMA-BUF обозначен как рекомендуемый вариант. Для него используется Open GPU Kernel Module, а поддержка RDMA может опираться на inbox-драйверы Linux. Legacy nvidia-peermem по-прежнему описан как отдельный путь и требует соответствующего OFED/DOCA-OFED стека. Это не означает, что каждый существующий peermem-кластер нужно срочно переделать: production-миграция оправдана, когда вы можете воспроизвести baseline и откатить canary без смешения гипотез.

Практическая разница для оператора в ownership. С DMA-BUF вы проверяете open kernel module, kernel/RDMA stack и GPU-memory transfer; с peermem появляется отдельный модуль и его совместимость с RDMA drivers. Поэтому после обновления kernel, NVIDIA driver или NIC stack разные узлы могут формально быть «зелёными», но фактически использовать разные пути.

До миграции зафиксируйте identity узла, GPU и RDMA NIC

Первое обязательное правило — не менять kernel path до evidence bundle. Запишите kernel release, версию и тип NVIDIA kernel module, PCI identity GPU, RDMA devices и физическую близость GPU↔NIC. Иначе после перезагрузки вы увидите «стало работать» и не сможете ответить, что именно изменилось.

Identity должна быть стабильной и машинно проверяемой. Для GPU полезен BDF из nvidia-smi и topology map; для NIC — RDMA device и связанный netdev. Если у вас несколько HCA, не используйте «mlx5_0» как вечную бизнес-идентичность: после firmware или PCI enumeration имя может поменяться. Сопоставляйте его с PCI BDF и физическим портом.

uname -r
modinfo nvidia | grep -E '^(version|license):'
nvidia-smi -L
nvidia-smi topo -m
rdma link
rdma dev show
ibdev2netdev
lsmod | grep -E 'nvidia_peermem|nvidia|ib_core|mlx5'

Сохраните этот вывод вместе с версией CUDA/NCCL и образом приложения. При canary сравнении нужен не просто «другой сервер», а узел того же topology class. Если одна машина имеет другой root complex, другой NIC firmware или другой kernel, она плохой контроль.

Для LLM-нагрузки отдельно зафиксируйте application baseline: время инициализации distributed job, steady-state throughput, p95/p99 интересующей операции и CPU utilization. Не выбирайте только одну метрику. Например, NCCL transport может стать чище, но end-to-end latency не изменится из-за другого bottleneck. Это нормальный результат, а не повод придумывать эффект.

Gate 1: докажите prerequisites DMA-BUF, а не просто наличие NVIDIA driver

По актуальной документации NVIDIA для GPUDirect RDMA через DMA-BUF требуется Open GPU Kernel Module; GPU Operator также указывает CUDA 11.7+ и Linux kernel 5.12+ как базовые требования этого пути. Проверяйте именно вашу поддерживаемую комбинацию OS/kernel/driver, а не переносите минимумы из документации на неподдерживаемый дистрибутив.

На практике gate должен отвечать на три вопроса. Во-первых, загружен ли open kernel variant, а не только «NVIDIA driver работает». Во-вторых, виден ли RDMA device и его netdev. В-третьих, соответствует ли GPU/NIC topology вашему canary-плану. На этом шаге не нужно запускать LLM: сначала докажите инфраструктурный механизм.

uname -r
modinfo nvidia | grep -E '^(version|license):'
rdma dev show
rdma link
nvidia-smi topo -m
ls -l /dev/infiniband

Не используйте отсутствие nvidia_peermem как единственный PASS. Модуль может быть не загружен, но DMA-BUF transfer всё равно не работать из-за несовместимой комбинации kernel/NIC driver. И наоборот, наличие старого модуля в filesystem ещё не доказывает, что runtime использует legacy path.

Gate 2: отдельно докажите RDMA из GPU memory

Следующий gate отделяет fabric от GPU-memory registration. Сначала полезно подтвердить обычный host-memory RDMA test на той же паре узлов и порту. Если он не проходит стабильно, не переходите к DMA-BUF — иначе две гипотезы смешаются. После PASS запускайте тот же класс perftest с GPU buffer и флагом DMA-BUF.

NVIDIA в troubleshooting для NCCL прямо предлагает сравнивать host-memory transfer и GPU-memory transfer через ib_write_bw; для DMA-BUF используется --use_cuda_dmabuf. Название HCA, GPU id и server address подставляйте из своего inventory, а не копируйте из примера как константы.

# На серверной стороне
ib_write_bw -d mlx5_0 -a

# На клиенте: сначала host-memory baseline
ib_write_bw -d mlx5_0 -a 

# Затем GPU-memory DMA-BUF test
ib_write_bw --use_cuda=0 --use_cuda_dmabuf -d mlx5_0 -a -F --report_gbits -q 1 

Смысл не в том, чтобы получить универсальное число Gbit/s. PASS — GPU-memory test стабильно работает на ожидаемой паре GPU/NIC, не разваливается при повторении и воспроизводится после controlled restart. Сравнение bandwidth полезно только между одинаковыми topology, message sizes и software versions.

Отрицательный контроль: намеренно запустите host-memory вариант отдельно. Если оба режима дают одинаково плохое поведение, не объявляйте DMA-BUF причиной. Если host memory стабилен, а GPU DMA-BUF падает, область поиска сужается к GPU registration/peer path и его совместимости.

Gate 3: проверьте, что NCCL не маскирует path своим fallback

Даже успешный perftest ещё не равен успешному distributed workload. NCCL выбирает transport с учётом topology и доступных plugins. В актуальной документации NCCL_DMABUF_ENABLE существует с NCCL 2.13, имеет значение по умолчанию 1 и автоматически отключается, если platform не поддерживает DMA-BUF. Поэтому отсутствие ручного export не доказывает, что path активен, а сам export не заставит неподдерживаемую систему чудесным образом заработать.

Для canary включите диагностический лог и запустите контролируемый nccl-tests на той же паре узлов. Смотрите не только на итоговую полосу, но и на transport selection, ошибки registration и неожиданный socket fallback. Команда ниже — шаблон локального теста; способ multi-node launch зависит от вашей MPI/Slurm/Kubernetes обвязки.

export NCCL_DEBUG=INFO
export NCCL_DMABUF_ENABLE=1

# Запускайте тем же orchestrator, который используете для canary
./build/all_reduce_perf -b 8M -e 1G -f 2 -g 1

Если тест не использует ожидаемый RDMA transport, не лечите его отключением safety checks вслепую. Вернитесь к identity и network baseline. Полезный принцип: каждый новый environment override должен отвечать на конкретное наблюдение в логе и иметь обратную команду.

Отдельно не путайте DMA-BUF с настройкой RoCE fabric. ECN/PFC, QoS и congestion control остаются самостоятельным слоем. Если NCCL видит RDMA, но сеть теряет пакеты или уходит в congestion, registration path уже не главный подозреваемый.

Gate 4: LLM canary должен подтвердить полезный эффект, а не красивый low-level test

Теперь повторите реальный workload на canary-узлах. Для training это может быть короткий репрезентативный distributed step; для multi-node inference — фиксированный replay запросов с теми же model revision, tensor/pipeline parallel settings и concurrency. Главное — не менять одновременно registration path, batch policy и модель: иначе attribution потеряна.

Держите рядом минимум три группы метрик: application SLO, NCCL/RDMA evidence и host pressure. Например, если после DMA-BUF direct path CPU utilization упал, но tokens/s и p95 остались прежними, вы доказали разгрузку host path, но не ускорение сервиса. Такой результат может быть полезен для capacity, но его нельзя продавать как рост производительности без дополнительного evidence.

Если наоборот p95 улучшается только на одном canary, сначала проверьте topology class и workload equality. Одна «быстрая» машина на другом PCIe root complex — плохое доказательство. Для смежных вопросов CPU/memory locality полезен runbook по pinned memory и memlock, а throttling GPU лучше исключать отдельным DCGM/Prometheus runbook.

Canary migration: не смешивайте DMA-BUF и legacy path в одном эксперименте

Самая опасная миграция — «обновим половину пакетов и посмотрим». Для canary заранее определите immutable software set: kernel, NVIDIA driver/kernel module type, CUDA/NCCL, RDMA stack, firmware и container image. Меняйте только registration path и связанные обязательные prerequisites.

Если вы используете GPU Operator, текущая документация показывает DMA-BUF как default path для GPUDirect RDMA и отдельный driver.rdma.enabled=true для legacy peer-memory сценария. Для bare metal применяйте ту же идею: два явных профиля конфигурации, а не ручные modprobe на десятках узлов. Infrastructure-as-code должен позволять вернуть прежний профиль целиком.

Порядок rollout: один canary pair → повторение после reboot → небольшой pool → только потом остальной cluster. На каждом этапе повторяйте четыре gates в одном порядке. Если после reboot GPU-memory perftest перестал работать, не переходите к NCCL; если NCCL упал, не объясняйте это application metrics.

Типовые failure modes: где DMA-BUF чаще всего обвиняют зря

Сеть не готова. Host-memory perftest уже нестабилен, но команда сразу запускает GPU test. В результате DMA-BUF получает чужую вину. Negative control здесь простой: сначала стабильный host buffer на том же HCA/port/path.

Смешаны kernel module types. Один узел использует open module, другой — другой driver profile, а orchestration считает их одинаковыми. Distributed job становится экспериментом сразу с несколькими переменными. Лечится inventory gate и node labels/taints, а не дополнительным environment variable.

NCCL auto-disable принимают за успех. Поскольку NCCL_DMABUF_ENABLE по умолчанию включён, можно ошибочно решить, что DMA-BUF точно используется. Документация прямо говорит об auto-disable на неподдерживаемой platform; поэтому нужен log/evidence, а не только значение переменной.

Peermem удаляют до rollback window. Если legacy path был рабочим baseline, не уничтожайте его в том же change, где впервые проверяете DMA-BUF. Сначала докажите новый path, затем сокращайте legacy dependencies отдельным change.

Механизм путают с SLO. GPU-memory RDMA может работать идеально, а LLM не ускориться, если bottleneck — compute, storage или scheduler. Для I/O storm на общем NVMe, например, полезнее отдельная изоляция I/O через cgroup v2/systemd.

Rollback и мониторинг: возвращайте профиль, а не отдельный модуль

Rollback должен быть симметричным rollout. Если baseline использовал legacy nvidia-peermem, верните прежний driver/RDMA profile целиком, перезагрузите узел при необходимости и повторите те же gates: identity → host/GPU perftest → NCCL → application. Это важнее, чем просто увидеть модуль в lsmod.

Для legacy path NVIDIA GPU Operator документирует отдельное включение RDMA driver integration. На bare metal эквивалентом должен быть versioned package/profile, а не «дежурный знает, какой modprobe сделать». После rollback сохраните оба evidence bundles — именно они позволяют понять, воспроизводится ли причинность.

# Пример проверки legacy baseline после возврата профиля
sudo modprobe nvidia-peermem
lsmod | grep nvidia_peermem
rdma dev show
nvidia-smi topo -m

# Затем повторите host-memory и GPU-memory tests,
# соответствующие вашему legacy baseline.

В постоянный мониторинг имеет смысл вынести не «DMA-BUF=1», а симптомы расхождения: node software fingerprint, RDMA link state, NCCL transport errors, неожиданный рост host CPU/memory при одинаковом workload и application SLO. Если инфраструктурный сигнал меняется без user-facing эффекта, храните его как ранний индикатор, но не эскалируйте как outage без порогов.

Когда выделенный GPU-узел даёт практическое преимущество

Здесь коммерческая граница довольно конкретна. Переход между kernel registration paths требует контроля над kernel, типом NVIDIA kernel module, NIC/RDMA stack, firmware, reboot/drain и составом canary pool. В среде, где эти слои скрыты или разделены между несколькими владельцами, вы можете увидеть symptom, но не собрать воспроизводимый evidence bundle.

Ценность dedicated GPU infrastructure в таком кейсе — не «DMA-BUF ускорит всё». Она в ownership: можно закрепить software/hardware profile, вывести узел из нагрузки, выполнить perftest на конкретной GPU↔NIC паре, вернуть baseline и заменить физический компонент, если проблема переживает software rollback. Это особенно важно для multi-node LLM, где один неоднородный узел способен испортить весь distributed job.

Если вы проектируете более широкий AI platform, полезно отделять этот низкоуровневый runbook от orchestration. Например, Kubernetes/KServe/GPU Operator решают scheduling и lifecycle задачи выше, но не отменяют необходимость доказать data path на хосте.

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

Проверено на дату подготовки статьи по официальной документации NVIDIA: GPU Operator 26.3 — GPUDirect RDMA, NCCL Environment Variables, NCCL Networking Troubleshooting и CUDA GPUDirect RDMA.

Особенно внимательно сверяйте minimum kernel/driver/CUDA requirements при обновлениях: эта часть стека меняется быстрее, чем общая логика runbook. Команды в статье — диагностические шаблоны; имена HCA, GPU id, IP, orchestrator и package profile должны соответствовать вашему inventory.

Вывод: мигрируйте не модуль, а доказанную цепочку data path

Переход с legacy nvidia-peermem на DMA-BUF имеет смысл делать как controlled infrastructure change. Сначала сохраните identity и baseline, затем докажите prerequisites open kernel, отдельно подтвердите RDMA из GPU memory, после этого — NCCL transport и только в конце — LLM application SLO. Если любой слой FAIL, не перепрыгивайте к следующему и не маскируйте проблему дополнительными overrides.

Главный operational результат — воспроизводимость. После reboot тот же canary должен проходить те же gates; rollback должен возвращать тот же baseline; улучшение low-level counters без application effect нужно называть именно так. Начните с одной пары однородных GPU-узлов и одного фиксированного workload replay — этого достаточно, чтобы миграция перестала быть догадкой и стала проверяемым change.