К содержимому
MoranaLabs
R&D / Computer Vision — 14 мая 2026 г.

Распределенное обучение визуальной foundation-модели на GPU-кластере 

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

512 GPU
в одном прогоне обучения
91 %
эффективность против линейного ускорения
0
рестартов с нуля при сбое узла
стенд · запускается здесь

Стенд: где заканчивается линейное ускорение

Смотреть надо не на время прогона, а на эффективность: место, где она проваливается, и есть потолок конфигурации. Выключите чекпоинты — увидите вторую стену.

90 %75 %50 %81632641282565121024204840968192ВРЕМЯ ПРОГОНА
эффективность время прогона, логарифм
чистый счет82,1 ч

то, ради чего карты и брали

обмен градиентами3,2 ч

ring all-reduce, 1,6 ГБ на шаг через 50 ГБ/с

сбои и чекпоинты2,5 ч

1,04 отказа узла за прогон при наработке 42 тыс. ч

91 %
эффективность против идеального линейного ускорения
87,8 ч
прогон на 512 картах
2,5 ч
потеряно на сбоях и чекпоинтах
9,89 млн ₽
стоимость прогона
На 512 картах обмен градиентами съедает 4 % прогона. Пока эффективность держится выше трех четвертей, докупать карты имеет смысл. Ниже — дешевле оптимизировать обмен, чем расширять парк.

Объем работы, размер модели и цена GPU-часа синтетические, порядок — претрейн зрительной модели. Формулы ring all-reduce и потерь на сбоях — настоящие.

Отказ узла — это не авария, а календарь

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

Инженер, который планирует обучение на сотнях ускорителей и не заложил это в архитектуру, узнает про арифметику на третьей неделе, когда прогон упадет и его придется начинать сначала. Мы начали с нее.

Что стоит за нулем рестартов с нуля

Три механизма, простые по отдельности и работающие только вместе.

  • Частые снимки состояния. Сохраняется не только модель, но и состояние оптимизатора и позиция в потоке данных. Иначе после восстановления модель доучивается на уже виденных примерах, что тихо портит результат.
  • Асинхронная запись. Снимок пишется в фоне, обучение не ждет диск. Иначе частые снимки сами становятся статьей потерь.
  • Автоматический подъем. Прогон перезапускается с последнего снимка без участия человека, включая исключение больного узла из парка.

Итог измеряется просто: сколько машинного времени теряется на одном отказе. Минуты — приемлемо. Часы — означают, что за неделю сгорит бюджет небольшого проекта.

Куда уходят девять процентов

91% эффективности масштабирования означает: увеличив парк вдвое, мы получаем чуть меньше двукратного ускорения. Потери складываются из понятных статей.

Статья потерьЧто с ней делали
Обмен градиентами между узламиСовмещение обмена с вычислениями: пока считается одна часть сети, для другой уже идет синхронизация
Ожидание самого медленного узлаВыравнивание нагрузки и контроль машин с просевшей частотой из-за нагрева
Подача данныхОтдельная работа с загрузчиком, о ней ниже
Запись снимков состоянияАсинхронная запись и разнесение по времени между узлами

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

Загрузчик данных душит раньше сети

Распространенное заблуждение: узкое место распределенного обучения — межузловая связь. На практике первым сдается конвейер подачи данных. Сотни ускорителей требуют изображений с такой скоростью, что обычное чтение мелких файлов из хранилища перестает справляться задолго до того, как упрется сеть.

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

Воспроизводимость — требование, а не роскошь

Прогон, который нельзя повторить, невозможно и отладить. Фиксируются версии данных, порядок их подачи, код и конфигурация. Каждый снимок состояния привязан к этому набору.

Практическая польза вскрывается при первой же аномалии: когда качество внезапно проседает на середине обучения, нужно точно знать, на каких данных это произошло. Без фиксации остается только гадать и запускать заново.

Сокращение цикла вчетверо — что это дало

Формально сокращение времени одного прогона. Практически — изменение способа работы исследовательской команды. Когда цикл занимает недели, проверяется одна гипотеза за раз и цена ошибки в постановке эксперимента огромна. Когда цикл короче в четыре раза, эксперименты становятся дешевле, и команда проверяет то, что раньше отбрасывала на этапе обсуждения.

Сбойный узел лучше исключить, чем чинить на ходу

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

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

Когда все это не нужно

  • Дообучение готовой модели под свою задачу: помещается на одну-две машины, и вся эта инфраструктура избыточна.
  • Небольшая выборка: на десятках тысяч изображений распределенное обучение упрется в переобучение раньше, чем в мощности.
  • Разовый эксперимент: аренда мощностей на короткий прогон дешевле построения собственного контура.

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

Направления рядом — распределенное обучение, высоконагруженные модели и эксплуатация ML.

×4
короче цикл обучения на 512 GPU
  • distributed training
  • GPU cluster
  • foundation model
  • CV
  • PyTorch
заказчик

R&D / Computer Vision · детали под NDA

СтендПроверить расчет руками ↑

Те же цифры, но с ручками: порог, нагрузка, объем.

НаправлениеОбучение на GPU-кластере

Что мы делаем в этом направлении и сколько это стоит.

Комментарий инженера

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

Опишите задачу  ответим как инженеры. 

Оставьте имя и Telegram — остальное обсудим. Без брифов на 40 слайдов и звонков по три раза.

Отвечаем за пару часовотвечает инженер, а не отдел продажNDA до передачи данных

Любой один канал — куда удобнее, туда и ответим

Или сразу написать в Telegram

Без спама и звонков-роботов. Нажимая кнопку, вы соглашаетесь с политикой конфиденциальности и обработкой персональных данных.