Масштабное обучение LLM на сотнях и тысячах GPU давно перестало быть вопросом чистой производительности — на первый план выходит надёжность. Ошибка памяти на одной карте или разрыв сети могут обрушить тренировку, идущую неделями. Традиционные чекпоинты спасают лишь частично: запись сотен гигабайт состояния модели съедает время и I/O, прогресс между чекпоинтами теряется, а весь кластер простаивает, пока упавший узел не вернут в строй. В AMD решили дать ответ на уровне среды исполнения и портировали PyTorch Monarch на AMD Instinct GPU с ROCm, открыв для экосистемы AMD ту же модель устойчивости, что раньше работала только на CUDA.
PyTorch Monarch — это actor-based среда, позволяющая управлять всем GPU-кластером из одного Python-скрипта. Ключевые элементы — process mesh, асинхронная модель выполнения и иерархия изоляции сбоев: ошибка в одном акторе не распространяется на остальные, а восстановление занимает секунды. Чтобы запустить Monarch на картах AMD, инженеры проделали три основных шага. Коллективные операции перевели с помощью hipify_torch, заменив CUDA-мосты на HIP и линкуясь с RCCL вместо NCCL. Управление GPU-памятью адаптировали через автоопределение платформы и роутинг вызовов CUDA driver API в их HIP-эквиваленты. Для прямых RDMA-пересылок с GPU оставили путь через libibverbs, заменив GPU-привязки — достаточно выставить GPU_PLATFORM=rocm. Попутно решили две неприятные проблемы: отсутствие статической линковки для HIP runtime (в ROCm нет аналога libcudart_static.a, поэтому amdhip64 линкуется динамически) и нежелание плодить #ifdef в Rust-коде. Вместо этого написали модуль совместимости rocm_compat в nccl-sys и rdmaxcel-sys, который реэкспортирует HIP-типы под CUDA-именами — например, pub type cudaError_t = hipError_t. Все 1 171 тест прошли успешно, поддержка ROCm 7.0+ полная, код отдан в upstream (PR #2393, #2891). Сегодня Monarch на ROCm работает на SLURM, Kubernetes и SkyPilot, включая actor runtime, RDMA, supervision и tensor sharding.
Верхнеуровнево отказоустойчивое обучение собрано из трёх слоёв: Monarch оркестрирует реплики и Lighthouse, объединяя GPU в Process Meshes; TorchFT занимается координацией кворума, выполняет Quorum AllReduce и пропускает упавшие узлы; TorchTitan крутит тренировку (FSDP forward/backward, оптимизатор) и чекпоинты. Когда одна из реплик теряет GPU-процесс, супервизор Monarch ловит ошибку с трейсбеком, инициирует локальный перезапуск, а здоровые реплики продолжают счёт. Lighthouse выбирает реплику-донора, передаёт с неё состояние модели, оптимизатора и шедулера восстанавливающейся ноде, после чего кворум пересобирается, и синхронизация градиентов (например, по схеме DiLoCo) возобновляется без полной перезагрузки чекпоинта.
Проверяли на двух конфигурациях. На SLURM-кластере из 16 узлов и 128 MI300 GPU тренировали Llama 3 8B, инжектируя RCCL-сбои каждые 180 секунд с синхронизацией кворума каждые 20 шагов. Число активных воркеров колебалось от 8 до 16, но тренировка ни разу не остановилась полностью, а кривая потерь плавно сходилась в точности как в эталонном прогоне без инъекций. На Kubernetes-кластере из 32 узлов с 256 MI355 GPU картина аналогичная: количество участников оставалось стабильным (30–32 во время событий восстановления), глобальная средняя потеря уверенно снижалась с 12 до примерно 4. Никакого ручного вмешательства, никаких полных рестартов.
Таким образом, на AMD Instinct GPU впервые показана работоспособность крупномасштабной отказоустойчивой тренировки с actor-based изоляцией сбоев и кворумной синхронизацией. Интеграция готова к продакшену на SLURM и Kubernetes. Дальнейшие планы — расширение поддержки NIC, подключение новых фреймворков предобучения и RL на ROCm, снижение задержек повторного входа нод и перекрытие восстановления с вычислениями.