Resizable BAR и Above 4G для multi-GPU LLM: production-runbook

Resizable BAR, BAR1 и Above 4G Decoding: три разных понятия

Above 4G Decoding разрешает firmware размещать 64-битные PCIe memory resources выше границы 4 ГБ. Это особенно важно для сервера с несколькими GPU, быстрыми NIC и NVMe: каждому устройству нужны BAR и окна мостов, а суммарный запрос быстро перестаёт помещаться в низком адресном пространстве. Настройка не делает GPU быстрее сама по себе; она создаёт пространство, в котором firmware и ОС могут корректно разложить ресурсы.

Resizable BAR — отдельная возможность PCIe: устройство сообщает набор поддерживаемых размеров BAR, а платформа выбирает один из них. В актуальной документации Linux kernel для этого есть интерфейсы проверки допустимых размеров и изменения resource; сам факт наличия capability не означает, что firmware выбрала максимальное окно или что это нужно конкретному workload. Поэтому фраза «ReBAR включён» без вывода lspci и resource map почти ничего не доказывает.

BAR1 в терминологии NVIDIA — окно, через которое часть framebuffer memory GPU может отображаться для CPU или сторонних PCIe devices. Его total/used/free показывает официальная документация nvidia-smi. BAR1 не равен всей VRAM и не является синонимом Resizable BAR. Типичная ошибка: увидеть большой объём VRAM, ожидать такой же BAR1 и объявить platform faulty, хотя конкретная модель GPU и режим платформы могут использовать другое отображение.

Практическая граница статьи такая: мы не обещаем прирост tokens/s от одной firmware-галочки. Мы проверяем, исчезают ли ошибки назначения MMIO, одинаково ли ОС видит все GPU после reboot и сохраняется ли требуемая P2P topology. Для выбора самих ускорителей полезен отдельный материал про конфигурацию GPU-сервера; здесь же речь только о готовности PCIe address space.

Сначала зафиксируйте симптом и неизменяемый baseline

Не начинайте с BIOS. Сначала запишите, что именно сломано: GPU отсутствует в PCI inventory, виден через lspci, но не в nvidia-smi, или полностью готов на уровне драйвера, а ошибку даёт только приложение. Это три разных владельца проблемы: platform/firmware, kernel/driver и runtime. Если смешать их в одну формулировку «GPU не работает», следующий reboot уничтожит половину доказательств.

Baseline должен включать точную модель платы и firmware, список BDF всех GPU и upstream bridges, версии kernel и NVIDIA driver, состояние IOMMU, вывод nvidia-smi -q, а также логи текущей загрузки. Сохраните не только успешные строки. Сообщения вида BAR no space, failed to assign или NVRM resource error важнее красивого summary: они показывают слой, на котором остановилась инициализация.

Представьте узел с четырьмя GPU и двумя высокоскоростными NIC. После включения ReBAR исчезла одна NIC. Это не «успешный GPU-тюнинг»: bottleneck и конфликт просто переехали на соседний PCIe resource. Нужен полный inventory до и после, а не проверка одного выбранного устройства. Именно поэтому в runbook об I/O-изоляции LLM-узла метрика приложения отделяется от состояния диска; здесь действует тот же принцип по отношению к PCIe.

Соберите evidence bundle до изменения firmware

Команды ниже не меняют состояние узла. Запускайте их из root shell или через sudo, сохраняя stdout и stderr в каталог с датой и именем сервера. Фильтр по NVIDIA удобен для быстрого просмотра, но полный lspci -nnvv нужен обязательно: конфликт может принадлежать bridge, NIC или контроллеру, а не самому GPU.

#!/usr/bin/env bash
set -euo pipefail
OUT="pcie-baseline-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"
uname -a > "$OUT/uname.txt"
lspci -Dnn > "$OUT/lspci-nn.txt"
lspci -Dnnvv > "$OUT/lspci-nnvv.txt"
nvidia-smi -L > "$OUT/nvidia-smi-L.txt"
nvidia-smi -q > "$OUT/nvidia-smi-q.txt"
dmesg -T | grep -Ei 'pci|bar|resource|mmio|nvrm|iommu' > "$OUT/dmesg-pcie.txt" || true
journalctl -k -b | grep -Ei 'pci|bar|resource|mmio|nvrm|iommu' > "$OUT/journal-pcie.txt" || true
tar -czf "$OUT.tar.gz" "$OUT"

Не отправляйте bundle в общий чат без проверки: в логах могут быть серийные номера, hostname и иные эксплуатационные детали. Храните его как change evidence. Если после изменения узел не загрузится, out-of-band console и этот архив позволят отличить новый конфликт от старого предупреждения.

Отдельно снимите firmware screenshots или экспорт profile, если BMC это поддерживает. Названия опций различаются: Above 4G Decoding может находиться рядом с PCIe/PCI subsystem, а Re-Size BAR — в другом меню и зависеть от CSM/UEFI mode. Не переносите названия пунктов между платформами наугад; сверяйтесь с руководством именно вашей платы и списком поддерживаемых GPU.

Прочитайте карту BAR в Linux, а не только BIOS-галочки

Linux показывает назначенные PCI resources в lspci -vv и в sysfs resource-файлах. В строках Memory at важны тип адреса, prefetchable-флаг и размер. Нулевой диапазон, disabled resource или повторяющееся предупреждение о нехватке места — повод остановиться до загрузки CUDA workload. Официальный PCI support guide Linux kernel описывает работу с BAR и Resizable BAR; это точнее форумных рецептов с универсальным pci=realloc.

Boot-параметр, перераспределяющий PCI resources, нельзя считать первым лекарством. Он меняет алгоритм назначения на уровне kernel и может затронуть соседние устройства. Сначала докажите, что firmware действительно оставила конфликт или недостаточное bridge window, затем проверьте рекомендации дистрибутива и поставщика платформы. На production-узле любое такое изменение должно иметь отдельное окно и rollback.

#!/usr/bin/env bash
set -euo pipefail
mapfile -t BDFS < <(lspci -dnn | awk 'tolower($0) ~ nvidia {print $1}') printf 'nvidia devices: %s\n' "${#bdfs[@]}" for bdf in "${bdfs[@]}"; do echo "="====" $bdf="===="" lspci -s "$bdf" -vv sed -n ' region p; resizable bar ,+8p' test -r sys bus pci devices resource" && nl -ba done< code>

Сравнивайте не абсолютный «правильный размер из интернета», а симметрию ожидаемо одинаковых GPU и соответствие support matrix. Разные SKU, MIG/vGPU или display mode могут законно отличаться. Если один из четырёх одинаковых ускорителей получил иную карту и именно он не инициализируется, это сильное доказательство; если все четыре одинаковы, ищите следующий слой.

Driver gate: GPU перечислен, BAR1 доступен, новых NVRM ошибок нет

Следующий gate начинается только после чистого PCI inventory. nvidia-smi -q документирован NVIDIA как источник BAR1 Memory Usage: Total, Used и Free. Зафиксируйте вывод для каждого GPU и сопоставьте PCI Bus ID с BDF из lspci. Наличие записи BAR1 подтверждает, что драйвер способен отчитаться об окне, но не доказывает P2P и тем более не гарантирует скорость LLM.

Проверка должна быть позитивной и отрицательной. Позитивная: все ожидаемые GPU видны, driver version едина, query завершается без ошибки. Отрицательная: запрос из процесса с ограниченным CUDA_VISIBLE_DEVICES не должен неожиданно открывать соседний ускоритель. Такая граница важна после passthrough, MIG или изменений device policy: «нужное видно» ещё не означает «лишнее недоступно».

Если BAR1 total различается между одинаковыми картами, не перезапускайте сервис десятки раз. Снимите новый evidence bundle, сравните firmware profile, PCI link state и driver binding. Если же различие объясняется режимом GPU, зафиксируйте это как ожидаемое состояние. Статья про MIG и MPS в multi-tenant GPU полезна для понимания, почему shared accounting не следует трактовать как физическую неисправность.

Меняйте Above 4G и ReBAR как управляемый rollout

Сделайте один change set за окно. Если цель — устранить нехватку 32-битного MMIO на multi-GPU сервере, сначала включают поддерживаемое платформой Above 4G Decoding, сохраняют профиль, перезагружают и повторяют весь infrastructure gate. ReBAR включают отдельным шагом только при подтверждённой поддержке CPU/chipset, firmware, GPU и драйвера. Так причинность остаётся видимой.

До reboot назначьте owner: кто меняет firmware, кто наблюдает BMC console, кто принимает решение stop/continue. Stop condition — пропажа любого ожидаемого PCIe device, новая resource allocation error, невозможность загрузить драйвер или отсутствие удалённого доступа. Не продолжайте к CUDA только потому, что «основные GPU вроде видны».

NVIDIA прямо требует Above 4G Decoding в ряде сценариев vGPU/passthrough, но bare-metal inference — другой контекст. Документация по виртуализации подтверждает необходимость large BAR address space для некоторых конфигураций, однако её нельзя механически превращать в обещание ускорения любого LLM. Здесь мы используем это как пример требования к адресному пространству, а не как benchmark.

После reboot сравните архивы машинно, но решение принимайте глазами: исчезновение BDF, изменение bridge window или новая ошибка важнее общего числа строк. Соседние NIC и NVMe должны остаться на месте. Если изменилось несколько классов устройств, rollback безопаснее, чем попытка починить всё в текущем profile.

CUDA gate: контекст на каждом GPU и реальная P2P-матрица

После успешного driver gate создайте CUDA-контекст на каждом устройстве. Простое перечисление GPU через nvidia-smi не гарантирует, что runtime сможет выделить память и выполнить kernel. Минимальный тест должен пройти для каждого индекса в той же среде, из которой стартует production service: тот же container runtime, device mounts и permissions.

#!/usr/bin/env bash
set -euo pipefail
python - <<'py' import torch count="torch.cuda.device_count()" assert> 0, "CUDA devices not found"
for index in range(count):
    with torch.cuda.device(index):
        x = torch.ones(1024, device=f"cuda:{index}")
        torch.cuda.synchronize(index)
        assert float(x.sum()) == 1024.0
        print(index, torch.cuda.get_device_name(index), "PASS")
PY

Затем проверьте peer access между теми парами, которым он нужен по архитектуре. Официальный репозиторий NVIDIA CUDA Samples содержит deviceQuery, topologyQuery и p2pBandwidthLatencyTest. Начиная с CUDA Samples 12.9 старый bandwidthTest удалён как устаревший; NVIDIA рекомендует NVBandwidth для актуальных измерений. Не копируйте старую команду из многолетнего блога и не сравнивайте цифры разных topology как универсальный норматив.

git clone --depth 1 https://github.com/NVIDIA/cuda-samples.git
cmake -S cuda-samples -B cuda-samples/build -DCMAKE_BUILD_TYPE=Release
cmake --build cuda-samples/build -j"$(nproc)"
find cuda-samples/build -type f \( -name deviceQuery -o -name topologyQuery -o -name p2pBandwidthLatencyTest \) -print

Последняя команда намеренно только находит binaries: layout меняется между релизами, поэтому запускать найденный путь следует явно после проверки checkout/tag, соответствующего вашему CUDA Toolkit. Gate считается успешным не при «высокой цифре», а когда deviceQuery проходит, topology соответствует схеме сервера, требуемые пары сообщают peer access, а результаты повторяемы. Если P2P недоступен там, где приложение на него рассчитывает, не маскируйте это увеличением batch size.

Application gate: докажите readiness LLM, а не только здоровье GPU

Теперь запускайте pinned-версию модели и runtime, зафиксированную в change plan. Не обновляйте одновременно BIOS, драйвер, CUDA и vLLM: четыре переменные превращают любой результат в догадку. Для сервиса сохраните model revision, container digest, параметры tensor/pipeline parallelism и placement GPU. Это прикладная граница материала: hardware gate закончен, а успех всё ещё надо доказать на уровне inference.

Минимум нужны readiness, один детерминированный контрольный запрос, отсутствие CUDA/NCCL ошибок и сравнение с pre-change baseline по latency, error rate и времени старта. Не придумывайте порог заранее: используйте собственный SLO и одинаковую нагрузку. Если hardware чист, но TTFT вырос, проверьте NUMA affinity, PCIe topology, storage path, batching и thermal/power limits. ReBAR не должен становиться универсальным объяснением.

Контрфактическая проверка полезнее восторга от одного удачного запуска: верните исходный firmware profile на canary-узле и повторите тот же application probe. Если метрика не меняется, ReBAR, вероятно, не был причиной улучшения. Если меняется только время загрузки весов, но не steady-state throughput, bottleneck мог переехать в storage; сопоставьте результат с практиками GPU scheduling и не смешивайте разные фазы workload.

Проверяли ли вы поведение после второго рестарта? Однократный PASS может скрыть зависимость от порядка enumerating устройств или прогретого cache. Повторите cold boot, затем application probe без ручных вмешательств. Только воспроизводимый результат допускает rollout дальше одного узла.

Rollout, stop conditions и симметричный rollback

Начните с одного canary-узла той же аппаратной ревизии. После reboot повторите gates в неизменном порядке: inventory, resource map, driver/BAR1, CUDA context, P2P, LLM readiness. На каждом этапе сохраните артефакт рядом с baseline. Только после PASS владельца и stop conditions переходите к следующему серверу.

Rollback должен быть симметричным. Верните сохранённый firmware profile, перезагрузите узел, затем снова пройдите те же проверки. «Сервис поднялся» недостаточно: один GPU или NIC мог исчезнуть, а scheduler просто уменьшил параллелизм. Сравните полный inventory и контрольный запрос, а не только HTTP 200.

Для удалённого dedicated server заранее согласуйте hands-on процедуру: BMC console, recovery profile и окно, в котором допустим второй reboot. Если платформа не документирует совместимость ReBAR с установленными GPU, оставьте функцию выключенной и решайте resource conflict поддерживаемым способом. Production ценит воспроизводимость больше, чем красивую галочку в firmware.

Owner каждого gate должен быть назван в change record. Platform engineer подтверждает inventory и bridge resources; GPU/runtime owner — драйвер, CUDA и P2P; владелец сервиса — readiness и SLO. Такая граница избавляет от ситуации, когда все видят красный статус, но никто не имеет права остановить rollout.

Типичные ошибки и куда мигрирует bottleneck

Первая ошибка — считать большой BAR эквивалентом большой VRAM. Вторая — проверять только GPU 0, хотя конфликт может проявиться на последнем устройстве за bridge. Третья — менять Above 4G, ReBAR, CSM и IOMMU одновременно. Четвёртая — использовать чужие bandwidth numbers как pass/fail. У разных серверов различаются root complexes, switches, link width, NUMA и GPU interconnect.

После исправления MMIO bottleneck часто становится видимым в другом месте. Storage может ограничить cold start; CPU/NUMA — подготовку batch; сеть — distributed inference; power limit — устойчивую частоту. Проверяйте end-to-end application metric и отрицательный контроль причины. Если убрать спорную настройку на canary и результат не изменился, не приписывайте ей успех.

Наконец, не игнорируйте firmware lifecycle. Параметр может изменить поведение после обновления BIOS или добавления NIC. Добавьте проверку inventory и BAR resources в acceptance новых узлов, но не автоматизируйте изменение firmware без out-of-band recovery. Хорошая автоматизация сначала обнаруживает drift и останавливает rollout.

Ещё одна ловушка — считать отсутствие ошибок доказательством оптимальной конфигурации. Clean dmesg лишь разрешает следующий gate. Только application baseline покажет, соответствует ли система своей задаче; а если нет, исследование должно перейти к topology, storage, сети или планировщику.

Автоматизируйте acceptance, но оставьте firmware под контролем человека

После успешного canary превратите read-only часть runbook в повторяемую проверку. Храните ожидаемый inventory как данные: serial узла, firmware version, BDF каждого GPU, NIC и NVMe, driver version, допустимый CUDA device count и пары P2P. Скрипт сравнения должен показывать добавленные, исчезнувшие и изменившиеся устройства, а не только возвращать зелёный exit code. Тогда новая плата или переставленная карта не пройдут под видом обычного reboot.

Автоматизировать запись firmware settings сложнее: интерфейсы Redfish и vendor BMC различаются, а ошибка может лишить сеть сразу несколько узлов. Поэтому разделите workflow. CI или конфигурационный агент собирает evidence и формирует diff; человек подтверждает изменение на одном canary; автоматизация повторяет read-only gates после reboot. Массовое применение допустимо только для однородной аппаратной ревизии с проверенным recovery profile.

В acceptance report полезны четыре независимых результата. Platform PASS означает, что полный PCI inventory совпал с ожидаемым и BAR resources назначены без новых ошибок. Driver PASS — все GPU присутствуют в nvidia-smi, BAR1 читается, NVRM clean. Runtime PASS — CUDA-контекст создаётся на каждой карте и требуемые P2P пары доступны. Application PASS — pinned LLM revision отвечает, а измеряемые показатели укладываются в собственный baseline или SLO. Один общий статус скрывает место отказа.

Не фиксируйте абсолютный размер BAR как универсальную константу для всех серверов. При обновлении GPU generation, переходе в MIG/vGPU, добавлении PCIe switch или passthrough ожидаемая карта меняется. Версионируйте baseline вместе с hardware profile. Если узел отличается от profile, отправляйте его на review, а не автоматически исправляйте до похожего состояния.

Отрицательный тест автоматизации прост: временно подайте checker заранее подготовленный inventory без одного неважного на первый взгляд NVMe или с изменённым BDF. Pipeline обязан остановить rollout. Если он проверяет лишь число GPU, он пропустит миграцию конфликта на storage и создаст узел, который успешно инициализирует модель, но не выдержит cold start после очистки cache.

Сохраняйте provenance каждой проверки: время, hostname, boot ID, версии kernel и драйвера, commit скрипта и имя владельца change. Без этого два внешне одинаковых PASS нельзя сравнить. Для fleet используйте отчёт с полями expected/observed и ссылкой на сырой bundle, а не копируйте гигантский lspci в тикет. Через месяц такой формат ответит на главный вопрос: проблема появилась после firmware update, после установки новой NIC или уже существовала в baseline.

Наконец, закрепите срок пересмотра profile. Поддержка ReBAR и поведение драйвера меняются вместе с firmware и GPU generation; старый PASS не переносится автоматически на новую сборку. Перед обновлением повторите исследование по официальным release notes, пометьте preview или experimental функции и проведите canary заново.

Вывод: сначала адресное пространство, потом CUDA, затем LLM

Resizable BAR и Above 4G Decoding полезны только в точном контексте. Above 4G даёт firmware место для 64-битных PCIe resources, ReBAR позволяет выбирать поддерживаемый размер окна, а NVIDIA BAR1 показывает отображение framebuffer memory. Ни один из этих фактов по отдельности не доказывает ускорение inference.

Надёжный путь выглядит скучно, и это хорошо: evidence bundle, одно firmware-изменение, полный PCI inventory, driver/BAR1, CUDA context, P2P и pinned LLM probe. Те же проверки выполняются при rollback. Пройдите этот checklist сначала на canary-узле; если hardware gate чист, а SLO не улучшился, перенесите расследование на реальный bottleneck вместо ещё одной случайной BIOS-галочки.

Для нового multi-GPU dedicated server этот runbook стоит включить в приёмочные испытания до передачи узла команде ML. Один час на baseline и возвратный профиль обычно дешевле ночной диагностики после того, как сервер уже включён в production pool.