Когда кластер на 256 GPU теряет один узел каждые три минуты, а модель весит 8 миллиардов параметров, традиционные чекпоинты превращаются в пытку. Пока система пишет сотни гигабайт на диск — обучение стоит. Пока восстанавливается с последнего сохранения — часы работы уходят в никуда. Meta решила эту проблему радикально: перенесла PyTorch Monarch на AMD Instinct с ROCm и доказала, что отказоустойчивое обучение без чекпоинтов работает в production.

Это не просто техническая заметка о портировании. Это вызов NVIDIA-монополии на инфраструктуру больших моделей и практический ответ на вопрос, который мучает каждую ML-команду: как тренировать, когда железо неизбежно ломается.

Что такое PyTorch Monarch и почему это важно

PyTorch Monarch — это новый runtime для распределённого обучения, который позволяет управлять всем GPU-кластером из одного Python-скрипта. Вместо того чтобы запускать отдельные процессы на каждом узле и координировать их через внешние инструменты, разработчик пишет код так, будто работает с одним компьютером. Monarch сам разбирается, как распараллелить вычисления, как организовать обмен данными между GPU и что делать, когда что-то идёт не так.

Архитектура построена на actor-модели, знакомой по Erlang и Akka. Каждый GPU-процесс — это «актор» с изолированным состоянием. Акторы объединяются в «mesh» — виртуальную сетку, которая абстрагирует физическую топологию кластера. Если один актор падает, его падение не распространяется на остальные: это ключевое отличие от традиционного подхода, где отказ любого узла обрушивает всю тренировочную джобу.

Раньше Monarch работал только на NVIDIA GPU с CUDA. Теперь Meta и AMD совместно портировали runtime на ROCm, и это меняет расклад на рынке AI-инфраструктуры.

Проблема масштаба: почему чекпоинты больше не работают

Традиционная стратегия отказоустойчивости проста: сохраняй состояние модели на диск каждые N шагов, а при сбое восстанавливайся с последнего чекпоинта. Это работало, пока кластеры были маленькими. Сегодня обучение LLM с миллиардами параметров требует сотен или тысяч GPU, и на таком масштабе сбои — не исключение, а правило.

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

Запись сотен гигабайт состояния модели на постоянное хранилище пожирает пропускную способность ввода-вывода. Кластер простаивает. Команда получает счёт за облако, которое просто ждёт. На 1024 GPU MI325 Meta ранее продемонстрировала 96.16% эффективности масштабирования FP8-обучения для DeepSeekV3-671B — но главным вызовом оставалась именно надёжность, а не скорость.

Как Monarch решает проблему без чекпоинтов

Вместо периодических чекпоинтов Monarch использует подход, заимствованный из телекоммуникационных систем: иерархическое дерево супервизии. Каждый актор имеет «супервизор», который следит за его состоянием. Если актор падает, супервизор перезапускает его локально — за секунды, не за минуты. Если локальный перезапуск не помогает, эскалация идёт на уровень выше.

Конкретно для обучения это работает так. Кластер разделяется на реплики — группы GPU, каждая из которых тренирует свою копию модели. Реплики синхронизируются через «кворум» — механизм, заимствованный из распределённых баз данных. Когда одна реплика падает, остальные продолжают обучение. Здоровые узлы не ждут — они работают.

Восстановление происходит через peer-to-peer передачу чекпоинтов. Система выбирает «донора» — одну из работающих реплик — и копирует состояние модели, оптимизатора и планировщика напрямую через сеть, минуя дисковое хранилище. Восстановленная реплика догоняет остальных, формирует новый кворум, и обучение продолжается.

Весь процесс автоматический. Ни ручного вмешательства, ни глобальной остановки, ни перезаписи на диск. Время простоя — секунды на локальный перезапуск, минуты только в худшем случае с полной эскалацией.

Инженерный подвиг: портирование CUDA на HIP

Перенос Monarch с NVIDIA на AMD — это не просто «заменить названия функций». Потребовалось три масштабных направления работы.

Коллективные коммуникации: код на C++, который работал с NCCL (библиотека коллективных операций NVIDIA), был конвертирован в HIP с помощью инструмента hipify_torch и перелинкован с RCCL — аналогом NCCL от AMD, полностью совместимым на уровне API.

Управление памятью GPU: система сборки была расширена для автоматического определения платформы. Вызовы CUDA driver API перенаправляются через HIP-эквиваленты. При этом динамическая загрузка функций (cuMemCreate, hipMemCreate) остаётся идентичной на обеих платформах.

RDMA-интеграция: прямой доступ к памяти GPU через сетевые карты (GPU-direct RDMA) — критическая оптимизация для межсерверного обмена. Путь libibverbs остался нетронутым, но GPU-привязки были заменены с CUDA на HIP.

Самый элегантный трюк — Rust-совместимость. После конвертации заголовков через hipify_torch, инструмент bindgen генерирует HIP-типы вроде hipError_t, hipDeviceptr_t, hipStream_t. Вместо того чтобы расставлять #ifdef в каждом вызове Rust-кода, команда добавила модуль rocm_compat в nccl-sys и rdmaxcel-sys, который переэкспортирует HIP-символы под их CUDA-именами: pub type cudaError_t = hipError_t. Весь остальной Rust-код остаётся платформенно-независимым.

Результат — 1171 тест пройдены, полная поддержка ROCm 7.0+, все изменения апстримлены в открытый код (PR #2393 и PR #2891).

Валидация в production: от 128 до 256 GPU

Теория — это одно. Production-тесты — другое. Meta протестировала стек Monarch + TorchFT + TorchTitan в двух конфигурациях.

SLURM-кластер на 16 узлов (128 GPU MI300), модель Llama 3 8B, инъекция сбоев RCCL каждые 180 секунд, синхронизация кворума каждые 20 шагов. Количество активных воркеров динамически колебалось от 8 до 16 из-за инъекций — но обучение не остановилось ни разу. Кривая потерь сходилась стабильно, практически совпадая с базовым прогоном без инъекций сбоев. Ни одна реплика не была недоступна дольше 30 минут — восстановление происходило быстро, разные реплики убивались и восстанавливались динамически.

Kubernetes-кластер на 32 узла (256 GPU MI355). Количество участников оставалось стабильным (колебания между 30 и 32 во время событий восстановления). Глобальная средняя потеря плавно снижалась с 12 до примерно 4. Это доказывает, что модель отказоустойчивости Monarch работает надёжно на обоих оркестраторах — и SLURM (HPC-традиция), и Kubernetes (cloud-native) — в масштабе четверти тысячи GPU.

Что это значит для индустрии

Портирование Monarch на ROCm — это не просто «ещё одна библиотека для AMD». Это системный сдвиг в том, как индустрия думает о large-scale training.

Во-первых, AMD получает production-ready стек для обучения LLM. До этого ROCm отставал от CUDA именно в надёжности инфраструктуры: научные работы на AMD GPU публиковались, но production-тренировки с тысячами GPU оставались прерогативой NVIDIA. Теперь у AMD есть actor-based runtime, fault tolerance, peer-to-peer чекпоинты и интеграция с TorchTitan — тем же стеком, что используют для Llama.

Во-вторых, подход «без чекпоинтов» меняет экономику обучения. Если кластер на 1000 GPU теряет 5% времени на чекпоинты и восстановление, это 50 GPU-дней на каждой тренировке. При стоимости облачного GPU от $2/час — это сотни тысяч долларов на одной модели. Monarch сокращает эти потери до секунд.

В-третьих, open-source апстрим означает, что технология доступна всем. Не проприетарный инструмент Meta, а часть экосистемы PyTorch. Любой, кто запускает распределённое обучение, может интегрировать Monarch + TorchFT в свой пайплайн.

Анатомия Quorum AllReduce: как это работает под капотом

Ключевой механизм, который делает «без чекпоинтов» возможным — Quorum AllReduce в TorchFT. Обычный AllReduce (например, в NCCL) требует, чтобы все участники были онлайн: если один GPU молчит, вся операция блокируется. Quorum AllReduce работает иначе.

Каждый шаг обучения реплики отправляют градиенты в Lighthouse — координационный сервис, который решает, какой кворум действителен в данный момент. Если реплика не успела прислать результат (упала, зависла, сетеваяpartition), Lighthouse формирует кворум из оставшихся. Здоровые реплики выполняют AllReduce между собой, обновляют модель и продолжают. Упавшая реплика, когда восстановится, получает актуальное состояние от донора и вливается в следующий кворум.

DiLoCo (Distributed Low-Communication) синхронизация происходит не на каждом шаге, а каждые N шагов (в тестах — каждые 20). Это снижает нагрузку на сеть: вместо AllReduce на каждом батче — только периодический обмен псевдоградиентами между репликами. Компромисс — slight convergence slowdown, но он минимален по сравнению с выигрышем от отсутствия чекпоинтов.

Сравнение с альтернативами: почему Monarch лучше существующих решений

До Monarch индустрия использовала три основных подхода к отказоустойчивости.

Azure DLC (Deep Learning Containers) от Microsoft применяет частые чекпоинты в Azure Blob Storage с автоматическим восстановлением. Это работает, но требует 5–10 минут на каждый чекпоинт для моделей 70B+. При сбое каждые несколько часов — это десятки процентов потерь throughput.

Google Pathways использует checkpoint-less подход для своих внутренних моделей, но это проприетарное решение, недоступное вне Google. PyTorch-сообщество не могло его использовать.

DeepSpeed Elastic от Microsoft тоже решает проблему отказоустойчивости, но работает на уровне процессов, а не акторов. При падении узла — перезапуск всей эластичной группы. Monarch изолирует сбой на уровне отдельного актора: если падает один GPU-процесс в реплике, перезапускается только он, а не все восемь.

Monarch сочетает лучшее из всех подходов: checkpoint-less (как Pathways), open-source (в отличие от Pathways), actor-based изоляция (тоньше, чем DeepSpeed Elastic), и теперь — кросс-платформенность NVIDIA/AMD.

Что это значит для open-source сообщества

Важный нюанс: всё, что описано выше, не проприетарная технология Meta. Все 1171 тест, все изменения в nccl-sys и rdmaxcel-sys, все hipify-конвертации — апстримлены в открытый код (PR #2393 и PR #2891 в репозитории Monarch). Любой, кто запускает распределённое обучение, может pip install monarch и интегрировать TorchFT в свой пайплайн.

Для исследователей это означает, что отказоустойчивость уровня Meta доступна на университетском кластере из 16 GPU. Для стартапов — что не нужно изобретать свой fault-tolerance layer: он уже есть, протестирован на 256 GPU, и работает с SLURM и Kubernetes из коробки.

Следующий шаг команды — расширение поддержки на RL-фреймворки (TorchRL, OpenRLHF) и оптимизация NIC-совместимости для более широкого спектра сетевых карт. Если вы запускаете distributed training и устали от чекпоинтов — Monarch уже готов к интеграции.

FAQ

Чем Monarch отличается от традиционного Elastic PyTorch (torchrun)?

Torchrun перезапускает всю джобу при любом сбое — все узлы останавливаются и ждут восстановления. Monarch изолирует сбой: падает один актор — перезапускается только он. Остальные продолжают обучение. Это как разница между перезагрузкой всего сервера при падении одного процесса и автоматическим рестартом только этого процесса через systemd.

Можно ли использовать Monarch без AMD GPU?

Да, Monarch работает и на NVIDIA GPU с CUDA — AMD-порт просто расширяет поддержку. Если у вас кластер на H100 или A100, Monarch так же даёт отказоустойчивость без чекпоинтов. ROCm-порт важен потому, что открывает альтернативу NVIDIA для масштабного обучения.

Какие минимальные требования для запуска Monarch?

Monarch работает на SLURM, Kubernetes и SkyPilot. Минимальная конфигурация — два узла с несколькими GPU на каждом. Для production-обучения LLM — от 8 узлов. ROCm 7.0+ для AMD Instinct, CUDA 12+ для NVIDIA. Все зависимости входят в экосистему PyTorch.

Как peer-to-peer чекпоинт влияет на сетевую нагрузку?

Передача чекпоинта от донора к восстановленной реплике использует RDMA (прямой доступ к памяти через сеть), минуя CPU и дисковую подсистему. Для Llama 3 8B это десятки гигабайт, но RDMA на InfiniBand или RoCE передаёт их за секунды без нагрузки на основные узлы. При этом передача происходит асинхронно — другие реплики продолжают тренировку.

Итог

PyTorch Monarch на AMD Instinct — это не апгрейд библиотеки, а изменение правил игры. Отказоустойчивость без чекпоинтов, восстановление за секунды, 1171 тест, 256 GPU, Llama 3 8B — всё это теперь доступно на AMD с ROCm 7.0+. Для команд, которые устали терять дни обучения на чекпоинты и рестарты, или которые ищут альтернативу NVIDIA-монополии — это готовый production-инструмент. Код открыт, интеграция с TorchTitan и TorchFT работает, SLURM и Kubernetes поддерживаются. Следующий шаг — RL-фреймворки и расширение NIC-поддержки.