Проблема масштабирования GPU-кластеров
При работе с крупными кластерами GPU сбои оборудования — это не исключение, а правило. Ошибки Xid, двойные ошибки ECC, отключение GPU от шины PCIe или нестабильные соединения InfiniBand могут остановить распределенное обучение или вывести из строя реплику инференса. Раньше обнаружение проблемы было лишь половиной дела; вторая, более сложная часть — это восстановление узла до здорового состояния.
Together AI анонсировала функцию полностью автоматического восстановления узлов (Automatic node remediation). Эта система уже используется клиентами платформы и внутренней инфраструктурой инференса для повышения отказоустойчивости и минимизации простоев.
Почему статуса NotReady недостаточно
Большинство систем авто-ремонта полагаются на один сигнал: узел переходит в статус NotReady. Однако этот сигнал не различает, сломался ли узел физически или просто временно недоступен из-за сетевых или хранилищных сбоев. Кроме того, статус NotReady не указывает причину отказа, что делает невозможным выбор между перезагрузкой и заменой машины.
Система Together AI работает по строгому правилу: ремонт узла происходит только после прохождения проверки здоровья (health check), и каждое действие сопровождается доказательной базой (evidence). Это предотвращает массовую замену узлов при общих сбоях инфраструктуры благодаря встроенным «предохранителям» (circuit breakers).
Архитектура обнаружения: две стороны гипервизора
Так как GPU передаются в виртуальные машины напрямую (passthrough) для производительности уровня bare-metal, мониторинг ведется с двух сторон:
- Внутри VM: экспортеры отслеживают логи ядра (ошибки Xid, отключение PCIe), DCGM (двойные ошибки ECC, переназначение строк, частота повторных передач PCIe, термическое троттлинг), Node Problem Detector (блокировки ядра, перезапуски kubelet) и статусы в Slurm (DOWN/DRAIN).
- На хосте: отслеживается состояние InfiniBand, флэппинг линков и доступность самого хоста.
Каждый алерт содержит стабильное описание, понятное человеку, и машиночитаемую полезную нагрузку. Например, для ошибки Xid указываются код и мнемоника NVIDIA, а для троттлинга — пиковая температура и количество срабатываний.
Политики и контроль: что, когда и как
Платформа определяет что делать (наименьшее действие для исправления), а пользователь решает когда и нужно ли это делать. Доступны следующие настройки:
| Параметр | Описание | Значение по умолчанию / Возможности |
|---|---|---|
| Согласие (Consent) | Требуется ли ручное одобрение | Approve before repair (по умолчанию) или Fully automatic (с выборочным авто-одобрением по кодам Xid) |
| Ожидание простоя (Wait for idle) | Пауза ремонта до завершения задач | До 24 часов (по умолчанию 2 часа). На Kubernetes ждет освобождения GPU, на Slurm — отсутствия аллокаций. |
| Прерывание задач | Поведение при истечении таймера | По умолчанию ремонт продолжается после таймаута. Опция "Do not interrupt" снимает ограничение, но требует настройки интервала чекпоинтов. |
| Логирование | Аудит действий | Записывается инициатор (Together Health Checker / пользователь), правило, время и причина. |
Интеграция собственных детекторов (Preview)
Команды, управляющие крупными флотами GPU, часто имеют свои системы мониторинга (NVSentinel, внутренние сканеры). Together AI позволяет интегрировать их через три канала:
- API: Создание ремонта с указанием режима, ID запроса и доказательств.
- Консоль: Ручное открытие ремонта через интерфейс узла.
- Node Labels (Preview): Детекторы могут открывать ремонт, добавляя аннотацию и метку к узлу. Это обеспечивает RBAC-авторизацию, идемпотентность (защита от двойных перезагрузок) и атрибуцию запроса к внешнему детектору.
Все запросы, независимо от источника, проходят через единую систему контроля емкости, аудита и безопасности платформы, что исключает возможность имперсонации или бесконтрольного воздействия на кластер.
Источник: Together AI ↗