PyTorch 2.15, выпущенный 28 октября 2026 года, изменил обмен данными между видеокартами при совместном обучении нейросетей. В публикации от 6 ноября издание The Register раскрыло подробности переработки NCCL, о которых рассказал разработчик PyTorch Тристан Райс: новая система упрощает поиск зависаний и создаёт условия для восстановления работы GPU-кластера после сбоя.
Почему одна неисправная видеокарта может остановить обучение нейросети
При обучении большой языковой модели вычисления часто распределяются между десятками или сотнями графических процессоров. Каждый GPU обрабатывает свою часть данных, а затем участники обмениваются промежуточными результатами. Для видеокарт NVIDIA такой обмен в PyTorch обеспечивает NCCL — библиотека, которая связывает вычисления внутри одного сервера и между несколькими машинами.
Проблема возникает, когда один из участников задерживается, теряет связь или перестаёт отвечать. Остальные видеокарты могут продолжать ждать его данные, из-за чего зависает вся операция. В подобных ситуациях команде приходится выяснять, где именно остановился обмен и можно ли продолжить обучение без полного перезапуска.
6 ноября 2026 года The Register опубликовал разбор PyTorch 2.15 после выступления разработчика фреймворка Тристана Райса на трансляции 5 ноября. Райс рассказал, что прежний интерфейс к NCCL накопил технические сложности, мешавшие предсказуемой работе и развитию распределённых вычислений. Сам релиз PyTorch 2.15 состоялся раньше — 28 октября.
В PyTorch 2.15 переработали управление обменом между GPU
В предыдущей реализации NCCL одна группа процессов могла создавать множество отдельных каналов связи — коммуникаторов. По объяснению Райса, их число порой достигало нескольких десятков. Такое устройство усложняло координацию и могло приводить к взаимным блокировкам: одна операция ждала другую, а работа кластера останавливалась.
В PyTorch 2.15 переписанный механизм стал стандартным для групп процессов, использующих nccl. Теперь для каждой группы коммуникатор создаётся при инициализации, а сама схема ограничивает число коммуникаторов в пределах группы. Когда приложению нужны дополнительные независимые потоки обмена, они организуются через другие группы процессов.
Что это меняет при реальном сбое? Сокращается число взаимодействий, за которыми нужно следить при диагностике зависания. Разработчики получают более понятную структуру связи между видеокартами, а причины нарушения обмена легче локализовать. Это относится прежде всего к системам, в которых модель обучается сразу на нескольких GPU.
«Чёрный ящик» NCCL сохраняет сведения о зависании
Ещё одно изменение PyTorch 2.15 — встроенный регистратор событий, который разработчики называют flight recorder. Его задача похожа на работу бортового самописца: сохранить последовательность операций перед остановкой, чтобы после сбоя можно было восстановить картину произошедшего.
Прежде ошибка могла проявляться как общее сообщение о превышении времени ожидания. При таком результате было трудно понять, какая видеокарта первой перестала отвечать и какую операцию ожидали остальные.
Новый регистратор сохраняет диагностические сведения об операциях обмена. По официальному описанию релиза, при зависании и срабатывании механизма контроля PyTorch может записывать данные со всех участников распределённой задачи. Это помогает сопоставить события на разных GPU, включая те, которые сами по себе продолжали работать.
Для инженеров, обслуживающих обучение больших моделей, разница существенна: вместо попыток воспроизвести редкое зависание появляется возможность исследовать информацию, собранную непосредственно в момент ошибки.
Восстановление кластера после сбоя требует внешнего управления
Переработанный NCCL поддерживает более гибкую перенастройку участников вычислений. Если один GPU вышел из строя или сильно отстал, внешняя система управления задачей — оркестратор — может исключить проблемный процесс и подключить замену. The Register связывает именно этот сценарий с возможностью избежать полного перезапуска обучения.
Но PyTorch 2.15 сам по себе не гарантирует автоматическое продолжение любой прерванной тренировки. Результат зависит от того, как организованы распределённая задача, управление процессами и восстановление её состояния. В официальном описании также указано, что ускоренная перенастройка состава участников доступна при использовании NCCL версии 2.29 и новее.
По сравнению с PyTorch 2.14, где переписанный NCCL предлагался в качестве отдельного экспериментального варианта nccl2, версия 2.15 включает его по умолчанию. Для существующих систем это меняет поведение коммуникационного слоя без необходимости выбирать новый механизм вручную.
Старую реализацию NCCL сохранили на случай несовместимости
Разработчики предусмотрели возможность вернуться к прежнему механизму. Для этого существует переменная окружения TORCH_DIST_USE_NCCL2=0 либо отдельное имя бэкенда nccl-legacy. Оба варианта указаны в официальных примечаниях к PyTorch 2.15.
Такой переходный период важен для кластеров с собственными настройками обмена и системами оркестрации. Переписанный NCCL уже используется по умолчанию, но старый код остаётся доступным, если в определённой конфигурации обнаружится несовместимость.
По сообщению The Register, разработчики допускают удаление прежней реализации в PyTorch 2.16 при условии, что новый механизм подтвердит стабильность. Это пока условный план, а не объявленная дата прекращения поддержки.
Таким образом, PyTorch 2.15 уже предоставляет более подробную диагностику зависаний и новые механизмы перестройки распределённых вычислений. Возможность продолжить конкретную тренировку после отказа GPU по-прежнему определяется устройством самого кластера и программ, которые им управляют.
