Эта запись в блоге является продолжением нашей серии 5 причин, почему ИИ не масштабируется. Чтобы увидеть последний блог из этой серии, нажмите здесь.

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

На самом деле, на вопрос, почему проекты машинного обучения пришлось свернуть, руководители групп ИИ чаще всего отвечают, что это связано с «отсутствием инфраструктуры». Инфраструктура чаще всего упоминается как самая большая проблема, замедляющая дорожную карту ИИ¹.

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

1 — Повышение производительности в ресурсоемких задачах

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

Эффективно организуя данные и ИИ вокруг архитектуры Kubernetes, команды ИИ могут воспользоваться преимуществами эффективного управления ресурсами на уровне кластера, автоматического масштабирования и всех преимуществ контейнеризации. Такая эффективность сама по себе может привести к гораздо более эффективному использованию ресурсов, которые легко отслеживать и контролировать с помощью единой системы управления, такой как ОС Petuum AI.

Планировщики ресурсов, такие как AdaptDL, оптимизируют производительность ресурсов специально для рабочих нагрузок машинного обучения и глубокого обучения. Например, многоузловое распределенное задание по обучению может быть выполнено в десятую часть времени при сохранении точности.

2 — Интенсивное сотрудничество и междисциплинарная экспертиза

Основная причина, по которой команды ИИ не могут использовать Kubernetes в полной мере, заключается в сложности — эффективная оркестровка Kubernetes требует таланта и опыта. Для большинства инженеров машинного обучения альтернативная стоимость освоения Kubernetes слишком высока. Тем временем для администраторов, контроллеров высокопроизводительных вычислений и других инженеров, обладающих необходимыми навыками контейнеризации, знание систем машинного обучения и их уникальных тонкостей может быть слишком слабым для эффективной оптимизации.

Наем или обучение инженера MLOps с нуля обычно стоит того, но даже если бюджет оправдан, для его реализации может потребоваться некоторое время. Здесь может помочь система абстракции, созданная для инженеров машинного обучения. С помощью ОС Petuum AI специалисты по обработке и анализу данных, инженеры-программисты и другие лица, не разбирающиеся в Docker, могут за считанные минуты раскручивать новые графы инфраструктуры, а также развертывать и интегрировать специальные приложения.

3 — Платформенная интеграция требует серьезной настройки

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

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

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

Мы обнаружили, что благодаря расширяемой и компонуемой платформе для управления контейнерными приложениями и потоками между ними трудности с интеграцией для инженеров могут быть в основном устранены. Вместо того, чтобы переписывать код интеграции для приложений ИИ, инженеры могут просто настроить файл конфигурации, представляющий граф всей инфраструктуры. ОС Petuum AI использует этот подход «инфраструктура как граф», чтобы упростить взаимодействие между программами. Шаги по подключению нового компонента к системе, например, Tensorboard для мониторинга, так же просты, как загрузка приложения, настроенного по умолчанию, из библиотеки, а затем подключение его к смонтированному файловому тому.

4 — Модульные и многоразовые системы для постоянного улучшения

По мере того, как проект ИИ продолжает масштабироваться, растет потребность в пересмотре уровня инфраструктуры, равно как и усилия, необходимые инженеру MLOps для обеспечения бесперебойной работы операций. Существующие приложения искусственного интеллекта необходимо улучшить для автоматизации, мониторинга или более оперативных процессов. Даже хорошо построенную систему необходимо обновлять каждый год или два просто из-за скорости инноваций в области ИИ. Без высокомодульной платформы для абстракции инфраструктуры инженерам приходится тратить значительные усилия на переписывание и тестирование обновлений системы, что приводит к простоям.

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

Использование платформы, построенной на принципах компонуемости, означает, что организованные системы, используемые командами, могут быть скопированы как целые приложения, дополнены новыми потоками и другими приложениями и развернуты практически без дополнительных затрат. Благодаря Petuum Platform эти графы инфраструктуры не ограничены средой Kubernetes и могут быть развернуты где угодно. Например, мы написали полную инфраструктуру для системы НЛП на локальном компьютере и отправили ее заказчику для развертывания без каких-либо настроек для среды.

Чтобы узнать больше о том, как платформа Petuum может помочь вашей организации лучше удовлетворить потребности в оркестровке инфраструктуры с помощью нашей абстракции Kubernetes, посетите наш веб-сайт по адресу www.petuum.com и подайте заявку на участие в нашей закрытой бета-версии!

[1] CometML 2021 Опрос практиков машинного обучения