Сегодня мы объявляем о создании специальной рабочей группы (SIG) по Ray на аппаратных ускорителях.
Когда Ray был создан в Калифорнийском университете в Беркли более 10 лет назад, ландшафт вычислений выглядел совсем иначе. В то время под «распределенными вычислениями» понимались кластеры CPU, работающие на таких фреймворках, как Apache Hadoop и Apache Spark. GPU только начинали переходить из сферы графики и научных вычислений в машинное обучение.
Сегодня ускоренные вычисления занимают центральное место в разработке и развертывании ИИ, а ускорители и их возможности стали более специализированными и разнообразными. Например:
- NVIDIA RTX 6000 Pro поддерживает гибкие рабочие нагрузки, охватывающие обучение ИИ, инференс, графику и видео.
NVIDIA RTX 6000 Pro поддерживает гибкие рабочие нагрузки, охватывающие обучение ИИ, инференс, графику и видео.
- NVIDIA B200 и AMD MI355X обеспечивают значительно больший объем памяти для поддержки более крупных моделей, а GB200 NVL72 объединяет 72 GPU для крупномасштабного обучения и инференса с интенсивным обменом данными.
NVIDIA B200 и AMD MI355X обеспечивают значительно больший объем памяти для поддержки более крупных моделей, а GB200 NVL72 объединяет 72 GPU для крупномасштабного обучения и инференса с интенсивным обменом данными.
- Помимо GPU, Google Ironwood TPU нацелены на ИИ-нагрузки огромного масштаба, а Groq LPU специализируются на инференсе с низкой задержкой.
Помимо GPU, Google Ironwood TPU нацелены на ИИ-нагрузки огромного масштаба, а Groq LPU специализируются на инференсе с низкой задержкой.
Сообщество Ray активно работает над тем, чтобы не отставать от этих изменений. Сегодня Ray поддерживает более десятка видов аппаратных ускорителей, от GPU NVIDIA и AMD до TPU, Trainium, Gaudi и других. Мы считаем, что сейчас самое подходящее время для развития этого фундамента с помощью более амбициозных и систематических усилий в рамках Ray, чтобы сделать ускорители простыми в использовании, эффективными при масштабировании и надежными в промышленной эксплуатации.
Специальная рабочая группа по ускорителям призвана объединить поставщиков оборудования, участников разработки Ray и разработчиков приложений для определения и продвижения общей, нейтральной по отношению к поставщикам дорожной карты поддержки ускорителей в Ray. Эта публичная рабочая группа будет отвечать за то, чтобы рабочие нагрузки Ray продолжали развиваться в эпоху фрагментированных, специализированных ускорителей.
Наша первоначальная дорожная карта фокусируется на 3 основных областях: инфраструктура разработки и тестирования, возможности учета аппаратного обеспечения и сетевое взаимодействие/транспорт, которые описаны в следующих разделах.
Ссылка: Инфраструктура разработки и тестирования
Надежная поддержка ускорителей требует гарантированного доступа к оборудованию для разработки, тестирования и отладки. Мейнтейнерам и участникам разработки необходимо проверять изменения на устройствах, на которые они влияют, воспроизводить сбои и выявлять регрессии до того, как они дойдут до пользователей. Поскольку агентное программное обеспечение ускоряет разработку, надежное тестирование и верификация становятся еще более важными: как человеческим участникам, так и агентам по написанию кода требуется воспроизводимая обратная связь от реального оборудования и репрезентативных рабочих нагрузок. Мы хотим сделать это рутинной частью участия в развитии Ray, с четким путем для поставщиков оборудования и облачных провайдеров по внесению ресурсов и экспертных знаний.
Наши первоначальные приоритеты:
- Общий доступ к оборудованию. Установить документированный процесс подключения облачных и хостируемых поставщиками ускорителей к инфраструктуре разработки и тестирования Ray, включая доступ для участников разработки для воспроизведения и отладки сбоев.
Общий доступ к оборудованию. Установить документированный процесс подключения облачных и хостируемых поставщиками ускорителей к инфраструктуре разработки и тестирования Ray, включая доступ для участников разработки для воспроизведения и отладки сбоев.
- Воспроизводимые среды разработки и тестирования. Предоставить поддерживаемые среды с явными версиями драйверов, сред выполнения и зависимостей, чтобы участники разработки могли воспроизводить результаты CI и последовательно проверять изменения у разных провайдеров.
Воспроизводимые среды разработки и тестирования. Предоставить поддерживаемые среды с явными версиями драйверов, сред выполнения и зависимостей, чтобы участники разработки могли воспроизводить результаты CI и последовательно проверять изменения у разных провайдеров.
- Более широкое покрытие CI. Расширить существующие конвейеры целевыми проверками для пулл-реквестов, а также более широким ночным и релизным тестированием. Покрытие должно включать распределенные рабочие нагрузки, восстановление после сбоев и регрессии производительности, наряду с базовой функциональностью устройств.
Более широкое покрытие CI. Расширить существующие конвейеры целевыми проверками для пулл-реквестов, а также более широким ночным и релизным тестированием. Покрытие должно включать распределенные рабочие нагрузки, восстановление после сбоев и регрессии производительности, наряду с базовой функциональностью устройств.
- Устойчивая эксплуатация и владение. Определить обязанности по поддержке сред, расследованию сбоев и обеспечению работоспособности интеграций между релизами. Сделать результаты тестирования и состояние инфраструктуры прозрачными, а также управлять мощностями и затратами, чтобы инфраструктура могла расти вместе с участием сообщества.
Устойчивая эксплуатация и владение. Определить обязанности по поддержке сред, расследованию сбоев и обеспечению работоспособности интеграций между релизами. Сделать результаты тестирования и состояние инфраструктуры прозрачными, а также управлять мощностями и затратами, чтобы инфраструктура могла расти вместе с участием сообщества.
Ссылка: Планирование с учетом аппаратного обеспечения
Чтобы приложения получали максимальную отдачу от ускорителя, Ray должен сначала знать, какое оборудование есть на каждом узле и как оно структурировано. По мере развития экосистемы ускорителей, узлы ускорителей больше не представляют собой просто набор идентичных устройств. Производительность рабочей нагрузки зависит от взаимосвязанности устройств, их отношения к CPU и сетевым картам (NIC), а также от группировки узлов в более крупные домены, такие как стойки и TPU-слайсы.
Наша цель — дать Ray точное и последовательное представление об этой структуре для разных поставщиков и платформ. Имея такую картину, планировщик Ray сможет размещать задачи и акторы на нужном оборудовании, а пользователи смогут видеть, из чего состоит их кластер и как он подключен.
Наши первоначальные приоритеты:
- Общие аппаратные интерфейсы. Определить нейтральные по отношению к поставщикам интерфейсы для маркировки оборудования, представления его архитектуры и описания спецификаций, чтобы приложения и библиотеки могли ориентироваться на возможности, а не писать код, специфичный для поставщика. Это включает в себя последовательный способ идентификации SKU ускорителей, включая новые модели на момент запуска. Сюда также входит документированная точка расширения и контрольный список для поставщиков, добавляющих новый ускоритель.
Общие аппаратные интерфейсы. Определить нейтральные по отношению к поставщикам интерфейсы для маркировки оборудования, представления его архитектуры и описания спецификаций, чтобы приложения и библиотеки могли ориентироваться на возможности, а не писать код, специфичный для поставщика. Это включает в себя последовательный способ идентификации SKU ускорителей, включая новые модели на момент запуска. Сюда также входит документированная точка расширения и контрольный список для поставщиков, добавляющих новый ускоритель.
- Усиленное обнаружение. Укрепить механизм обнаружения Ray, обеспечив четкую ответственность за интеграцию каждого ускорителя и подкрепив его покрытием CI, описанным в предыдущем разделе. Обнаружение должно фиксировать топологию и архитектуру оборудования, а не только тип и количество устройств.
Унификация обнаружения. Усовершенствуйте механизм обнаружения Ray с четким распределением ответственности за интеграцию каждого ускорителя и обеспечьте его покрытие с помощью CI, как описано в предыдущем разделе. Обнаружение должно фиксировать топологию и архитектуру оборудования, а не только тип и количество устройств.
- Интеграция с платформами и облаками. Взаимодействуйте с облачными провайдерами и платформами развертывания, чтобы механизм обнаружения отражал базовую структуру везде, где запущен кластер. Часть этой информации (например, к какой стойке или разделу принадлежит узел) доступна только со стороны платформы, а не изнутри самого узла.
Интеграция с платформами и облаками. Взаимодействуйте с облачными провайдерами и платформами развертывания, чтобы механизм обнаружения отражал базовую структуру везде, где запущен кластер. Часть этой информации (например, к какой стойке или разделу принадлежит узел) доступна только со стороны платформы, а не изнутри самого узла.
- Видимость оборудования. Предоставьте средства для просмотра ускорителей в кластере и способов их соединения, а также метрик ускорителей на панели управления Ray. Это позволит пользователям убедиться, что Ray правильно распознает оборудование, и понять, где была размещена их задача. Это также дает контрибьюторам возможность проверять новые интеграции.
Видимость оборудования. Предоставьте средства для просмотра ускорителей в кластере и способов их соединения, а также метрик ускорителей на панели управления Ray. Это позволит пользователям убедиться, что Ray правильно распознает оборудование, и понять, где была размещена их задача. Это также дает контрибьюторам возможность проверять новые интеграции.
- Понятные руководства для пользователей. Документируйте то, как Ray обнаруживает и представляет оборудование, а также как использовать эту информацию при размещении задач. Хорошие руководства помогают как разработчикам приложений, так и агентам по написанию кода, которые все чаще пишут код Ray за них.
Понятные руководства для пользователей. Документируйте то, как Ray обнаруживает и представляет оборудование, а также как использовать эту информацию при размещении задач. Хорошие руководства помогают как разработчикам приложений, так и агентам по написанию кода, которые все чаще пишут код Ray за них.
LinkСети и транспорт ввода-вывода
Перемещение данных между ускорителями часто имеет такое же значение, как и выполнение вычислений на самом ускорителе. Современные рабочие нагрузки ИИ, такие как крупномасштабное обучение с подкреплением, требуют передачи больших тензоров весов моделей между устройствами и узлами от воркеров обучения к воркерам инференса. Исторически объектное хранилище Ray создавалось для данных ЦП, поэтому тензоры ускорителей приходилось копировать в память хоста, сериализовать и передавать через стандартную сеть хоста перед отправкой на другое устройство.
Чтобы избежать этого узкого места, был представлен Ray Direct Transport (RDT), позволяющий акторам передавать ссылки на тензоры через Ray, в то время как фактические данные пересылаются напрямую между устройствами с использованием высокопроизводительных протоколов передачи, таких как UCX и RDMA. Наша цель — обеспечить надежную высокоскоростную прямую передачу данных между различными ускорителями, фреймворками и сетевыми фабриками при сохранении привычной модели программирования Ray.
Наши первоочередные задачи:
- Широкая интеграция транспортных протоколов. Поддержка более широкого спектра ускорителей, фреймворков и интерконнектов в RDT, чтобы Ray мог выбирать самый быстрый путь между акторами — будь то внутрисегментный TPU ICI, NVLink на одном узле или кросс-узельный GPUDirect RDMA.
Широкая интеграция транспортных протоколов. Поддержка более широкого спектра ускорителей, фреймворков и интерконнектов в RDT, чтобы Ray мог выбирать самый быстрый путь между акторами — будь то внутрисегментный TPU ICI, NVLink на одном узле или кросс-узельный GPUDirect RDMA.
- Жизненный цикл транспорта и восстановление. Обеспечение того, чтобы каждый аппаратный транспорт корректно обрабатывал инициализацию, завершение работы и восстановление после сбоев на реальном оборудовании, благодаря чему RDT будет работать надежно по мере масштабирования акторов или их перезапуска в динамических рабочих нагрузках, таких как обучение с подкреплением и дезагрегированный инференс.
Жизненный цикл транспорта и восстановление. Обеспечение того, чтобы каждый аппаратный транспорт корректно обрабатывал инициализацию, завершение работы и восстановление после сбоев на реальном оборудовании, благодаря чему RDT будет работать надежно по мере масштабирования акторов или их перезапуска в динамических рабочих нагрузках, таких как обучение с подкреплением и дезагрегированный инференс.
- Проверенные рецепты и наблюдаемость. Предоставление облачным провайдерам и производителям оборудования возможности публиковать проверенные конфигурации развертывания, проводить бенчмаркинг высокопроизводительных рабочих нагрузок, а также выводить понятную диагностику и метрики транспорта.
Проверенные рецепты и наблюдаемость. Предоставление облачным провайдерам и производителям оборудования возможности публиковать проверенные конфигурации развертывания, проводить бенчмаркинг высокопроизводительных рабочих нагрузок, а также выводить понятную диагностику и метрики транспорта.
LinkОбласть охвата
В то время как базовая логика планирования и размещения остается в Ray Core, SIG Accelerator отвечает за определение интерфейсов плагинов, тестирование CI и уровни зрелости ускорителей в Ray. Поставщики оборудования и облачные провайдеры создают и поддерживают собственные плагины устройств, транспорты и поддержку day-zero для новых SKU, в то время как авторы фреймворков и практики машинного обучения обосновывают нашу дорожную карту реальными потребностями рабочих нагрузок.
LinkПрисоединяйтесь
Независимо от того, создаете ли вы интеграцию нового ускорителя, запускаете крупномасштабное обучение или инференс на базе Ray, либо предоставляете облачную инфраструктуру и инфраструктуру CI, мы приглашаем вас принять участие!
- Присоединяйтесь к обсуждению в Ray Slack.
Присоединяйтесь к обсуждению в Ray Slack.
- Посещайте наши встречи сообщества для обсуждения предложений, рассмотрения приоритетов дорожной карты и обмена отзывами о рабочих нагрузках.
Посещайте наши встречи сообщества для обсуждения предложений, рассмотрения приоритетов дорожной карты и обмена отзывами о рабочих нагрузках.
- Ознакомьтесь с открытыми запросами на изменение (PR), связанными с ускорителями на Github, и вносите свой вклад в проект.
Ознакомьтесь с открытыми запросами на изменение (PR), связанными с ускорителями на Github, и вносите свой вклад в проект.
