В этом материале
Направленный peer access, отношение топологии и передача движка являются отдельными наблюдениями.
Физическое соединение не равно проверке возможностей
Две GPU могут находиться в одном сервере и при этом различаться способами программной передачи данных между ними. Видимое межсоединение, благоприятная ячейка топологии и успешный запрос peer access являются отдельными свидетельствами. Ни одно из них само по себе не доказывает прямую передачу в конкретном движке при выбранном разделении модели.
В руководстве CUDA по производительности взаимодействие устройств и перемещение данных рассматриваются в контексте нагрузки. Исследование должно относиться к определённому пути передачи. Само наличие нескольких карт не является свидетельством того, что их VRAM превращается в единый прозрачный пул выделения памяти.
Постройте направленную матрицу пар
Строка соответствует исходной GPU, столбец — целевой. Рядом с локальными индексами используйте постоянные идентификаторы. Для каждого проверенного направления сохраняйте результат запроса возможностей. Ошибку запроса, недоступность поддержки и реальный отрицательный результат нужно различать. Пустая ячейка означает отсутствие проверки, если запись явно не устанавливает иное.
Руководство DCGM по топологии и линиям даёт контекст отношений устройств и наблюдаемых соединений. Поместите эту инвентаризацию рядом с матрицей возможностей вместо её подмены. Сохраняйте ОС, драйвер, runtime и конфигурацию разделения: поддержка и видимость способны меняться вместе со средой выполнения.
Отделяйте возможность от успешной передачи
Положительный ответ проверки является предпосылкой исследования прямого пути, а не измеренной скоростью. Выполните ограниченный тест с известными размерами буферов и направлениями и проверьте фактический маршрут. Если ПО использует промежуточную память хоста, подпишите это явно, не смешивая результат с наблюдениями прямой передачи.
Рассмотрим условные устройства A и B. Наблюдения A-to-B и B-to-A следует хранить отдельно, даже если оба направления поддерживают одинаковое поведение. Ошибка передачи после положительной проверки возможностей требует отдельной записи. Нельзя отмечать её успешной только потому, что другая копия через хост завершилась без ошибки.
Проверьте путь самого приложения
Затем определите распределение весов, состояния и коммуникаций в движке. Независимое копирование не устанавливает производительность коллективных операций или обслуживания модели. Сохраняйте параметры параллелизма и подтверждайте участвующие устройства. Матрица особенно полезна, когда в конфигурацию случайно попала другая GPU вместо проверенной карты.
Изолированные и одновременные передачи сравнивайте тогда, когда это различие относится к нагрузке. Учитывайте конкуренцию общего пути и размещение памяти. Используйте повторные наблюдения: одна быстрая передача не резервирует такую же пропускную способность для каждого конкурентного запроса приложения.
Оставляйте вывод на нужном уровне
Итоговый документ содержит три части: топологию, направленные результаты возможностей и измеренное поведение нагрузки. Объясните связь между ними, не объединяя их смысл. Так можно различить отсутствие поддержки, неожиданный программный маршрут и узкое место реальной параллельной работы. Это также предотвращает обещание, что любые две видимые GPU смогут разместить модель за счёт простого сложения их VRAM.
При смене драйвера или состава устройств повторяйте затронутые проверки и сохраняйте новую версию матрицы. Старое положительное наблюдение полезно как история, но его нельзя автоматически переносить на другую среду исполнения.