Изоляция GPU в облаке: NVSwitch, NVLink и пределы проверки через nvidia-smi

У поставщика стоит сервер с восемью NVIDIA H200, а вы арендуете четыре. Остальные GPU могут достаться другому клиенту. Если все восемь связаны через NVSwitch, не сможет ли сосед прочитать ваши данные?

Общий NVSwitch сам по себе не означает общий доступ к памяти. В поддерживаемых конфигурациях GPU можно разделить на изолированные группы. Но безопасность зависит от того, как поставщик настроил выдачу устройств и доступ через NVLink. Четыре GPU в выводе nvidia-smi ещё не доказывают, что эта граница настроена правильно.

Четыре H200 из восьми: где проходит граница

Предположим, это платформа HGX или DGX с восемью GPU и NVSwitch. Само название H200 не определяет схему соединений: перед сравнением предложений стоит уточнить модель сервера и топологию.

В памяти арендованных GPU хранятся веса модели, входные данные, промежуточные тензоры и результаты вычислений. При корректной изоляции соседний арендатор не должен получать к ним доступ через свои GPU.

Схема разделения:

Один физический сервер, восемь GPU

Арендатор А                    Арендатор Б
GPU 0, 1, 2, 3                 GPU 4, 5, 6, 7
      │                             │
      └──── общие NVSwitch ──────────┘

Обмен внутри каждой группы разрешён.
Обмен между группами запрещён конфигурацией фабрики.

Схема иллюстрирует требуемое разделение. Номера GPU условные: реальные группы зависят от поддерживаемой конфигурации платформы. Настройки конкретного облака нужно уточнять у поставщика.

Что делают NVLink и NVSwitch

NVLink обеспечивает быстрый обмен между GPU. NVSwitch соединяет несколько GPU через NVLink в общую коммуникационную фабрику. Она полезна, когда модель распределена между несколькими ускорителями и они постоянно обмениваются данными.

В режиме Shared NVSwitch Multitenancy коммутаторами управляет доверенная служебная ВМ. Fabric Manager активирует группы GPU (partitions) и запрещает доступ к GPU за пределами каждой группы. Поставщик передаёт арендаторам GPU и сохраняет управление общими NVSwitch.

В режиме Full Passthrough виртуальной машине передают выделенную группу GPU и NVSwitch. Для небольших конфигураций нужно блокировать связи, выходящие за границы группы, и дополнительно настраивать гипервизор.

В обоих случаях нужно проверить, что требуемое разделение активировано. Сам по себе работающий сервис Fabric Manager этого не подтверждает.

Видимость GPU и изоляция — разные свойства

Слово «выделенные» в описании услуги может означать целые физические GPU. Чтобы оценить изоляцию, уточните, какие механизмы использует поставщик.

Например, приложение можно запустить так:

CUDA_VISIBLE_DEVICES=0,1,2,3 python train.py

Так можно выбрать GPU для задачи. Переменная окружения, которую задаёт сам процесс, не создаёт защитную границу между недоверенными арендаторами.

Переменную NVIDIA_VISIBLE_DEVICES использует NVIDIA Container Runtime, когда предоставляет GPU контейнеру. Помимо перечня устройств контейнера, нужно проверить остальные настройки безопасности.

Для ВМ с прямым доступом к устройствам важна IOMMU — механизм ограничения обращений устройств к памяти хоста. Даже если поставщик подтвердил наличие отдельной ВМ и включённой IOMMU, изоляцию межгрупповых связей NVLink нужно уточнить отдельно.

MIG разделяет ресурсы одного физического GPU. При выдаче четырёх целых H200 из восьми нужно изолировать две группы физических устройств. Наличие или отсутствие MIG само по себе не отвечает на вопрос об их изоляции.

Что можно проверить через nvidia-smi

nvidia-smi помогает проверить состав доступных устройств и их связи. Следующие команды только читают состояние. Их поддержка и полнота вывода зависят от платформы, драйвера и прав доступа.

1. Список устройств

nvidia-smi -L

Команда перечисляет доступные утилите GPU и их UUID. Сверьте модели и количество с заказом. Для обсуждения с поддержкой лучше сохранить UUID: порядковый номер GPU может меняться после перезагрузки.

Четыре GPU в списке соответствуют заказу на четыре устройства. Команда не показывает, какие ограничения настроены между ними и недоступными вам GPU физического сервера.

2. Топология

nvidia-smi topo -m

Матрица показывает связи между видимыми устройствами. Обозначения нужно читать по легенде конкретного вывода. Например, NV18 обозначает соединение через набор из 18 NVLink; PIX, PXB, PHB и SYS описывают разные пути через PCIe и системные соединения.

Число после NV обозначает количество связей. По нему нельзя определить скорость в ГБ/с или разрешения на доступ к GPU другого арендатора.

3. Возможности P2P

nvidia-smi topo -p2p r
nvidia-smi topo -p2p w

Эти команды показывают сообщаемые драйвером возможности P2P-чтения и записи между доступными GPU. P2P — прямой обмен между устройствами.

Для многих задач на нескольких GPU положительный результат внутри вашей группы ожидаем. Он не означает, что произвольный процесс может читать любую чужую память: для этого нужны права на конкретные области памяти.

4. Состояние NVLink

nvidia-smi nvlink --status

Состояние NVLink полезно проверять при медленном обмене между GPU. Активный линк подтверждает, что соединение работает, но не показывает границы partition.

Почему эти команды не доказывают безопасность

Из гостевой ВМ вы наблюдаете только доступную ей часть системы. По четырём видимым GPU и работающему между ними NVLink нельзя установить, изолированы ли остальные устройства сервера.

Нужно различать два вопроса:

• Работает ли обмен внутри моей группы? Топология, возможности P2P и тесты производительности помогают это выяснить.
• Запрещён ли обмен с чужой группой? Для ответа нужны сведения о конфигурации поставщика и проверка границы между группами.

N/A, отсутствие GPU в списке или неактивный линк тоже нельзя трактовать как доказательство утечки либо гарантированной защиты. У этих результатов могут быть разные причины.

Что запросить у провайдера

Попросите поставщика описать механизм изоляции и способ его проверки:

Планируем арендовать 4×H200 на узле с 8×H200. Подтвердите тип выдачи ресурсов и способ изоляции NVLink/NVSwitch от остальных GPU. Какой режим Fabric Manager используется, как выданные GPU сопоставляются с активной partition и как проверяется запрет межгруппового доступа?

Дополнительно стоит уточнить:

• Может ли арендатор изменять конфигурацию общих NVSwitch или только управлять своими GPU в предусмотренных пределах?
• Проверяется ли изоляция после перезагрузки, пересоздания ВМ и изменения состава арендаторов?
• Как исключается доступ к данным предыдущего клиента при повторной выдаче GPU?
• Как обновляются драйверы, прошивки и управляющее ПО?

Поставщик может проверить запрет межгруппового доступа на собственных тестовых ВМ в каждой группе. Внутри групп должен работать разрешённый обмен, а попытки запрещённого доступа между ними должны отклоняться. Результат нужно оценивать вместе с конфигурацией: один успешный тест не охватывает все возможные состояния системы.

Когда имеет смысл арендовать весь узел

На выделенном физическом сервере нет соседнего арендатора. Это упрощает оценку рисков, если вы обрабатываете чувствительные данные или не можете получить достаточные подтверждения разделения ресурсов.

Доступ к памяти, влияние соседа на производительность и побочные каналы требуют отдельных проверок. Запрет межгруппового P2P-доступа ещё не означает, что арендаторы никак не влияют друг на друга. Просадка скорости сама по себе тоже не свидетельствует об утечке данных.

Аренда целого узла также не отменяет доверия к администратору поставщика и требований к сети, дискам, резервным копиям и доступу к приложению. Если в модель угроз входит сам оператор инфраструктуры, этот вопрос нужно обсуждать отдельно: выделение восьми GPU вместо четырёх его не решает.

Подобрать ресурсы для своей задачи можно в конфигураторе GPU-серверов. Для работы с чувствительными данными уточните у инженера схему изоляции выбранной конфигурации.