Наблюдаемость полного стека для NVIDIA AI Factory: Гайд

В эпоху больших языковых моделей и генеративного ИИ инфраструктура перестала быть просто «железом». Она стала сложнейшим живым организмом, где каждый компонент — от вентилятора сервера до маршрутизатора InfiniBand — влияет на конечный результат обучения или инференса. Для инженеров, управляющих NVIDIA AI Factories, главная боль — это не отсутствие данных, а их избыток. Тысячи метрик, десятки дашбордов, бесконечные алерты, которые не ведут к действию. Это классическая проблема «арбузных метрик»: снаружи всё зелено, а внутри система уже сломана.

В этой статье мы разберем фундаментальный подход к построению наблюдаемости (observability) полного стека для инфраструктуры NVIDIA. Мы не будем просто перечислять инструменты. Мы создадим стратегию, которая позволит вам за минуты, а не за часы, находить корневую причину сбоев, таких как «серые отказы» в сетях InfiniBand, и предотвращать потерю сотен часов вычислений GPU. Это руководство для тех, кто хочет перейти от хаотичного сбора данных к управляемой, предсказуемой и эффективной операционной модели.

01Почему традиционный мониторинг не работает для AI-кластеров?

Традиционные системы мониторинга часто фокусируются на изолированных компонентах. Вы следите за загрузкой CPU, температурой GPU и доступностью сети по отдельности. Но в распределенном обучении моделей, особенно по модели Bulk Synchronous Parallel (BSP), система ведет себя как единое целое. Если один узел в кластере из тысяч становится «медленным» (straggler), он держит в ожидании весь коллектив. Все остальные GPU простаивают, пока этот один узел догоняет остальных.

Классический пример — так называемый «серый отказ» (gray failure). Представьте, что вы запустили тренировку модели, которая должна идти три дня. На шестой час пропускная способность падает. GPU загружены, но работа идет медленнее. Система не сообщает об ошибке «Down», потому что узел технически работает. Однако, если проследить путь данных, вы обнаружите, что один канал InfiniBand начал генерировать повышенное количество ошибок битов (Bit Error Rate — BER). Это вызывает повторные передачи пакетов, что блокирует синхронные коллективные операции NCCL. В результате весь кластер работает на скорости самого медленного звена.

Такие сбои трудно обнаружить, потому что они не являются критическими отказами в традиционном понимании. Они «тихие». Без полностековой наблюдаемости, которая связывает метрики сети, GPU и оркестрации, вы можете потратить дни на поиск причины, просто меняя настройки софта, не подозревая, что проблема в физическом кабеле или порту коммутатора.

02Карта доменов отказов: Что именно нужно мониторить?

Прежде чем выбирать софт, нужно четко определить границы ответственности. В архитектуре NVIDIA AI Factory выделяют пять ключевых доменов, в которых могут происходить скрытые отказы, потребляющие ресурсы:

1. Здоровье платформы (Platform Health)

Это базовый уровень. Сюда входят вентиляторы, блоки питания (PSU), базовые системы управления (BMC), шасси, процессоры, память и локальное хранилище. Если отключается PSU или перегревается чипсет, GPU может снизить частоту или отключиться. Мониторинг этого уровня обычно осуществляется через протоколы Redfish или IPMI.

2. Здоровье и производительность GPU

Самый важный ресурс. Здесь мы следим за утилизацией, температурой, потреблением энергии, ошибками ECC (коррекция ошибок памяти) и XID (внутренние ошибки NVIDIA). Также критически важен пропускной канал NVLink между GPU внутри одного узла. Падение пропускной способности NVLink может так же сильно ударить по производительности, как и отказ сети.

3. Сеть (Fabric)

Для распределенного обучения сеть — это кровеносная система. Нужно мониторить целостность каналов InfiniBand или Ethernet, перегрузки (congestion) и здоровье коммутаторов/кабелей. В современных кластерах также важно отслеживать NVLink масштаба стойки (rack-scale NVLink), если он используется.

4. Кластер и задачи (Cluster and Jobs)

Здесь мы смотрим на планировщик задач (например, Slurm или Kubernetes), очереди ожидания, зарезервированные, но неиспользуемые GPU. Если GPU зарезервированы, но не работают, это прямой убыток. Очереди показывают, насколько эффективно используется инфраструктура.

5. Сервисы инференса (Inference Services)

Если вы запускаете модели в продакшене, важны задержка (latency), процент успешных запросов и поведение кэша. Для этого часто используются микросервисы NVIDIA NIM. Здесь метрики отличаются от метрик обучения: здесь важна отзывчивость, а не только пропускная способность.

03Маппинг компонентов на инструменты: Фреймворк выбора

Главная ошибка — пытаться собрать все метрики всеми инструментами. Это приводит к шуму и усталости от алертов. NVIDIA предлагает четкий фреймворк, который сопоставляет компоненты инфраструктуры с конкретными инструментами телеметрии. Цель — покрыть все «зеленые» зоны (полная поддержка) минимальным набором инструментов.

Вот как распределяются роли основных инструментов:

• DCGM (Data Center GPU Manager): Король для GPU. Используйте его для утилизации, температуры, энергии, NVLink и ошибок XID/ECC. Он отлично интегрируется с Prometheus. DCGM не заменяет данные BMC, но покрывает 90% потребностей в мониторинге GPU.
• NVSM (NVIDIA System Management): Необходим для DGX-систем. Он агрегирует данные о здоровье всей системы: диски, питание, общее состояние. Если у вас есть DGX, NVSM обязателен для полного понимания здоровья узла.
• UFM (Unified Fabric Manager): Специализированный инструмент для InfiniBand. Он видит то, что не видят другие: BER, перегрузки, маршрутизацию. Если у вас InfiniBand — UFM ваш главный друг.
• NetQ: Аналог UFM, но для сетей на базе Spectrum Ethernet/RoCE. Если у вас нет InfiniBand, а есть Ethernet, используйте NetQ. Не ставьте оба, если у вас только одна тип сети.
• NMX: Нужен только для мониторинга NVLink масштаба стойки. Если у вас классическая топология с NVLink только внутри узла, NMX не нужен — DCGM справится.
• BCM (Base Command Manager) и Run:ai: Это уровни оркестрации и управления кластером. BCM агрегирует задачи, резервации и алерты. Run:ai добавляет справедливость распределения ресурсов. Они не заменяют DCGM или UFM, а дополняют их, показывая влияние сбоев на бизнес-задачи.

04Практический сценарий: Настройка для InfiniBand-кластера

Давайте применим этот фреймворк к реальной ситуации. У вас есть кластер DGX с InfiniBand, управляемый Slurm и BCM. Основные задачи — обучение моделей. Инференс пока не в продакшене. Ваша цель — единый дашборд для триажа и алерты, которые ловят регрессии сети и GPU до того, как будет потеряно несколько часов вычислений.

Шаг 1: Определение доменов

В зону охвата входят: платформа, GPU, InfiniBand, кластер/задачи. Исключаем из начального этапа: NetQ (нет Ethernet), NMX (нет rack-scale NVLink), Run:ai и NIM (нет инференса и сложных требований к справедливости очередей на старте).

Шаг 2: Выбор инструментов

• Redfish/IPMI: На каждом узле для мониторинга вентиляторов, PSU, шасси и BMC.
• DCGM: На каждом GPU-узле для метрик производительности и здоровья GPU.
• NVSM: На узлах DGX для агрегации системного здоровья.
• UFM: Для мониторинга здоровья портов InfiniBand, BER, перегрузок и маршрутизации.
• BCM: Как агрегатор кластера для задач, зарезервированных ресурсов и консолидированных алертов.

Почему именно такой набор? DCGM один не увидит регрессию BER в сети. UFM один не увидит шторм ошибок XID на GPU. BCM один не даст низкоуровневых счетчиков. Вместе они закрывают все дыры, в которых теряются часы работы GPU.

05Построение набора алертов Top-K

Инструменты могут экспортировать сотни метрик. Ваша задача — отобрать «Top-K» (наиболее важные) метрики, привязанные к Service Level Indicators (SLI) и Service Level Objectives (SLO). Алерт должен быть actionable — то есть вести к конкретному действию.

Вот стартовый список метрик для вашего стека:

• Платформа: Скорость вентиляторов, статус PSU, ключевые температуры (SPD_FAN_*, PWR_*, TEMP_*) через Redfish/IPMI.
• GPU: DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_MEM_COPY_UTIL, DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_XID_ERRORS. Плюс данные о здоровье от NVSM.
• InfiniBand: PortXmitDataExtended, SymbolErrorCounterExtended, Effective_BER, Total_Raw_BER, Chip_Temp. Обратите внимание на BER — это индикатор «серых» отказов.
• Задачи: Сигналы от BCM/Slurm: количество работающих задач, зарезервированные GPU, время ожидания в очереди. Это связывает технические сбои с бизнес-влиянием.

Расширяйте этот список только тогда, когда инцидент покажет, что чего-то не хватает. Алерьте на симптомы, которые ведут к действию (например, «заменить кабель», «вывести узел из эксплуатации»), а не на каждый возможный счетчик.

06Единый дашборд триажи: Архитектура решения

После выбора инструментов и метрик нужно собрать всё воедино. Рекомендуемая архитектура выглядит так:

1. Установите экспортеры IPMI и DCGM на каждый GPU-узел.
2. Запустите UFM Telemetry там, где доступна сеть InfiniBand, и экспортируйте данные в Prometheus.
3. Оставьте BCM как плоскость агрегации кластера.
4. Направьте Grafana на Prometheus для создания дашбордов и алертов.
5. Добавьте общедоступный дашборд Slurm, если BCM не предоставляет контекст на уровне задач.

Используйте двухуровневый подход. Уровень 1 — это дашборд Grafana для быстрой триажи. Он отвечает на вопрос: «Где проблема? В GPU, узле или сети?». Уровень 2 — это углубленный анализ в интерфейсах вендоров (UFM Web UI, BCM Base View) после того, как домен проблемы определен. Это ускоряет операционную работу в день 2, так как не нужно искать проблему в пяти разных системах.

07Критерии приемки и масштабирование

Когда вы можете считать, что система наблюдаемости готова? Когда:

• Каждый домен отказов имеет хотя бы один инструмент полной поддержки.
• Алерты привязаны к короткому списку метрик, имеют владельцев и действия.
• Сигналы от GPU, узлов и сети имеют общую временную шкалу в одном представлении.
• Дополнительные инструменты добавляются только по мере необходимости, а не «на всякий случай».

Не измеряйте зрелость наблюдаемости количеством дашбордов. Измеряйте её способностью сигналов называть отказавший компонент и следующее действие до того, как будет потеряна значительная вычислительная мощность.

После внедрения базового стека масштабируйте покрытие в этом порядке:

1. Включите полную телеметрию GPU через DCGM User Guide.
2. Валидируйте пути здоровья DGX через NVSM User Guide.
3. Настройте видимость сети через UFM (для InfiniBand) или NetQ (для Ethernet).
4. Для агрегации кластера используйте Base Command Manager и NVIDIA Mission Control.
5. Для инференса добавьте наблюдаемость NVIDIA NIM Operator.

08Что это значит на практике

Внедрение этого фреймворка меняет парадигму работы с AI-инфраструктурой. Вместо того чтобы реагировать на падения сервисов, вы проактивно управляете здоровьем кластера. Вы перестаете гадать, почему тренировка замедлилась, и начинаете точно знать, что один порт InfiniBand начал терять пакеты, и уже можете заменить кабель до того, как это повлияет на следующую итерацию обучения.

Для команд в России и СНГ, где доступ к облачным сервисам может быть ограничен, локальный запуск таких стеков (Prometheus, Grafana, DCGM, UFM) становится критически важным активом. Это позволяет сохранять контроль над данными и обеспечивать отказоустойчивость собственных AI-фабрик. Ключ к успеху — не в количестве собираемых данных, а в их осмысленной агрегации и четкой привязке к бизнес-результатам. Начните с малого, покройте базовые домены, настройте алерты и постепенно расширяйте охват. Ваша инфраструктура станет предсказуемой, а ваши вычисления — эффективными.

Наблюдаемость — это не просто мониторинг. Это способность понимать состояние системы в любой момент времени и принимать обоснованные решения. В мире AI, где каждый час простоя стоит дорого, это конкурентное преимущество.

Источник: NVIDIA Developer ↗