Слишком хорошо, чтобы быть правдой?
Выполнение машинного обучения (особенно в масштабе) требует существенной координации и бесчисленных технологий. До недавнего времени для этого требовалось настраивать пользовательские среды, адаптированные к конкретным задачам машинного обучения. Однако последние технологические достижения позволили создавать сложные рабочие процессы машинного обучения, которые переносятся в новые среды и запускаются одним нажатием кнопки.
FlyteHub - это новый бесплатный общедоступный реестр рабочих процессов машинного обучения с открытым исходным кодом. С FlyteHub вы можете запустить любой рабочий процесс с открытым исходным кодом и выполнить мощное машинное обучение в любом масштабе без написания кода. Поскольку эти рабочие процессы переносимы, их можно запускать на вашем ноутбуке или в кластере из 1000 машин.
Представьте себе следующий сценарий:
- Специалист по данным пишет рабочий процесс для распознавания изображений.
- Специалист по данным понимает, что другие могут извлечь выгоду из их работы, и загружает рабочий процесс на FlyteHub.
- Поскольку рабочие процессы FlyteHub переносимы, любой, у кого установлен FlyteHub, может импортировать этот рабочий процесс с открытым исходным кодом и выполнять распознавание изображений без написания кода или установки каких-либо дополнительных пакетов.
- Эти пользователи могут внести свой вклад в проект, улучшив рабочий процесс для всех.
Фактически, FlyteHub уже имеет рабочие процессы с открытым исходным кодом для распознавания изображений. Вы можете запустить их за 5 минут без написания кода и даже научить свои собственные модели распознавать нестандартные объекты.
FlyteHub стал возможен только сейчас благодаря нескольким отраслевым достижениям, включая Flyte, который был запущен всего несколько недель назад на KubeCon. Попробуйте FlyteHub прямо сейчас или читайте дальше, чтобы узнать о графике достижений, которые сделали рабочие процессы с открытым исходным кодом возможными сегодня.
Попутно мы покажем, как рабочие процессы с открытым исходным кодом могут быть использованы для охоты и поимки неуловимого Саскватча (более известного как «снежный человек»).
Аналогичные рабочие процессы можно использовать для обнаружения «видов Лазаря» (таких существ, как кит Омуры, которые когда-то считались вымершими) или отслеживания ультра-редких сибирских тигров, численность которых, как считается, ниже 5000.
Вернемся в 2013 год.
Данные BFRO (Организация полевых исследователей снежного человека) свидетельствуют о множественных встречах снежного человека в округе Кинг недалеко от Сиэтла. Мы установили камеры в лесу возле прицельных точек, которые автоматически делают фото каждые несколько секунд.
У нас нет времени просматривать все фотографии. К счастью, у нас есть специалист по данным, который написал код Python, который он называет «Детектор снежного человека». Код использует компьютерное зрение для сканирования каждой фотографии и сообщает нам, есть ли на ней снежный человек.
Мы хотели бы поделиться этим кодом с командой в Калифорнии, чтобы они тоже могли его использовать. Сейчас декабрь, и, по сообщениям, существо может лететь на юг.
До 2013 года пользователю нужно было вручную установить все необходимые требования на свой компьютер, прежде чем он сможет использовать этот код.
Чтобы выполнить нашу задачу Python, команде из Калифорнии необходимо будет установить правильную версию Python и все необходимые библиотеки. Если для задачи требовалась другая технология, например Apache Spark, им нужно было убедиться, что Java и Spark установлены и правильно настроены.
Таким образом было бы очень сложно создать портативный ИИ, «щелкающий» по кнопке, поскольку каждая задача связана с уникальным набором требований. Для разных задач AI могут даже потребоваться разные версии одной и той же библиотеки. Даже для опытных инженеров это неприятный опыт, известный как «ад зависимостей».
В Калифорнийской команде нет инженеров, и мы не хотим подвергать их аду зависимостей. Нам нужна вся возможная помощь. Любой человек в мире должен иметь возможность просто отправить свои фотографии одним нажатием кнопки и присоединиться к охоте за снежным человеком.
2013: Контейнеры революционизируют то, как мы делимся кодом
«Контейнер» подобен фрагменту кода, который связан со всеми необходимыми требованиями. Например, наш контейнер может включать Python версии 3.6 и все пакеты Python, необходимые для выполнения нашей задачи Детектор снежного человека.
Контейнеры работают в изолированной среде. Если вы запустите контейнер Bigfoot Detector на своем ноутбуке, контейнер будет работать с использованием Python 3.6, даже если на вашем ноутбуке установлен Python 2 или не установлен Python вообще.
Когда вы запускаете рабочий процесс FlyteHub с открытым исходным кодом, весь код выполняется внутри контейнеров. Это гарантирует надежную работу кода во всех средах.
Решено? Не так быстро.
Выполнение некоторых задач ИИ может занять много времени (особенно в масштабе).
Когда мы заберем наши камеры, у нас будет 1 миллион фотографий. Если AI-коду требуется 10 секунд для обработки каждого изображения, компьютеру потребуется 115 дней, чтобы завершить все 1 миллион изображений.
Я знаю, о чем вы думаете: «115 дней ?! За это время зверь мог оказаться на полпути к Мексике! »
Нам нужна более быстрая обратная связь.
Чтобы ускорить процесс, мы могли бы использовать 100 компьютеров и разделить изображения между ними. Если каждая машина обрабатывает 10 000 изображений, все 1 миллион фотографий можно сделать за 1 день.
Поскольку код упакован в контейнер, вам не нужно беспокоиться об установке каких-либо требований на всех этих компьютерах, однако вам все равно нужно проинструктировать каждый из 100 компьютеров запустить контейнер Bigfoot Detector.
Мы могли бы написать код, который повторяется 100 раз, сообщая каждой машине запустить контейнер. Однако, если код предполагает, что существует ровно 100 машин, код не переносится.
Чтобы эта задача искусственного интеллекта была переносимой, наша команда должна иметь возможность выполнять ее на 100 компьютерах в день. Команда из Калифорнии (у которой нет 100 компьютеров) должна иметь возможность выполнить ту же задачу на одном ноутбуке и обработать изображения за 115 дней. Другими словами, код не должен понимать инфраструктуру, в которой он работает.
2015: Представлен Kubernetes
Kubernetes - это платформа для запуска контейнеров на «кластере» компьютеров. В вашем кластере может быть только одна машина (ваш ноутбук) или 1000 машин.
Когда вы дадите Kubernetes команду запустить 100 контейнеров, Kubernetes как можно скорее запланирует их на вашем кластере машин.
Kubernetes отслеживает, сколько машинных ресурсов доступно. Если ваш кластер достаточно велик для одновременного запуска 50 контейнеров, Kubernetes немедленно запустит первые 50 контейнеров. Как только один из контейнеров завершит работу, Kubernetes обнаружит, что теперь есть свободное место, и запустит 51-й контейнер. По мере создания большего количества контейнеров Kubernetes будет продолжать запускать новые контейнеры, пока не будут завершены все контейнеры.
Если у вас достаточно ресурсов только для запуска одного контейнера за раз, рабочий процесс Детектора снежного человека займет 115 дней, но в конечном итоге он завершится.
AI с открытым исходным кодом FlyteHub работает на Kubernetes. Кластер Kubernetes может быть таким маленьким, как одна машина, например ваш ноутбук, или большим кластером в AWS. Kubernetes гарантирует, что рабочие процессы успешно работают в любом сценарии.
Решено? Не так быстро.
Как только все эти контейнеры Bigfoot Detector будут готовы, у нас будет 1 миллион выходных данных (по одному выходу на изображение). Нам нужно объединить эти результаты во что-то полезное.
Чтобы решить эту проблему, мы можем создать другой контейнер, который объединяет результаты каждого из контейнеров обработки изображений и ищет положительные результаты.
Проблема в том, что для этого контейнера важен порядок.
В отличие от контейнеров Bigfoot Detector, которые могут работать одновременно, нам нужно дождаться завершения всех задач Bigfoot Detector, прежде чем запускать этот последний контейнер.
Это не единственный сценарий, в котором важен заказ контейнеров. Прежде чем запускать обработку изображений, мы должны разделить фотографии на небольшие партии, чтобы мы могли запускать контейнер Bigfoot Detector для каждой партии фотографий. Наш логический поток выглядит примерно так:
- Шаг 1. Разделите фотографии на небольшие партии.
- Шаг 2: Запустите контейнер Bigfoot Detector для каждой партии фотографий.
- Шаг 3: Объедините результаты из шага 2 и проверьте, есть ли положительные результаты.
Процессы Data Science имеют тенденцию принимать форму, напоминающую «Рабочий процесс» или «Задачи», подобные этой. Эти рабочие процессы могут стать очень сложными. Задачи рабочего процесса могут включать сбор данных, предварительную обработку данных, извлечение функций, обучение модели, оценку модели и многое другое.
Некоторые задачи (например, детектор снежного человека) могут выполняться параллельно. Другим задачам (например, задаче «проверка положительных результатов») необходимо дождаться завершения предыдущих задач, прежде чем они будут запущены.
Поскольку Kubernetes ничего не знает о логике нашего упорядочивания, он не знает, нужно ли ждать завершения некоторых задач, прежде чем запускать другие задачи.
Нам нужен «Менеджер рабочего процесса», который понимает логику нашего рабочего процесса. «Диспетчер рабочего процесса» должен присматривать за рабочим процессом во время его работы. Он должен запускать контейнеры в Kubernetes только после завершения всех предыдущих шагов. Чтобы завершить наш рабочий процесс, диспетчер рабочего процесса должен сделать что-то вроде этого:
- Скажите Kubernetes, чтобы он запустил задачу «Разделить фотографии».
- Дождитесь завершения задачи.
- Скажите Kubernetes запускать задачи «Детектор снежного человека» для каждой партии.
- Дождитесь завершения всех задач Детектора снежного человека.
- Скажите Kubernetes, чтобы он запустил последнюю задачу, чтобы проверить положительные результаты.
- Сохраните результат и покажите его пользователю.
- Пользователь снимает снежного человека и путешествует по миру с цирком.
2019: Lyft представляет Flyte
Flyte был недостающей частью головоломки, необходимой для переносимости рабочих процессов.
Одним из ключевых понятий, введенных Flyte, является «Спецификация рабочего процесса». Спецификация рабочего процесса предоставляет надежный способ выразить логический поток рабочего процесса.
Все рабочие процессы в Flyte должны соответствовать этой спецификации. Flyte может читать эти рабочие процессы, понимать порядок задач и запускать их в Kubernetes в правильном порядке.
Flyte понимает не только порядок, но и поток данных в рабочем процессе. Обычно выходы одной задачи становятся входами для следующей задачи. Flyte понимает это из Спецификации рабочего процесса.
Flyte следит за тем, чтобы результаты одной задачи были доступны для следующей задачи, даже если эти задачи выполняются на совершенно разных компьютерах. Независимо от того, запускаем ли мы Bigfoot Detector на 1 портативном компьютере или на 1000 машинах, результаты этих задач распознавания изображений будут доступны для задачи «Проверить наличие положительных результатов».
Когда мы загружаем наш рабочий процесс в FlyteHub, FlyteHub сохраняет спецификацию рабочего процесса. Любой охотник на снежного человека может импортировать рабочий процесс, отправить свои фотографии и получить результаты, не разбираясь в деталях его работы.
Фактически, рабочий процесс недавно был использован домашним исследователем из Монтаны для создания следующей фотографии:
Глядя на фото, становится ясно, что волосы такого типа могли появиться только из… самого мифа.
Заключение
Сегодняшний пост лишь поверхностно описывает возможности, открываемые этими технологиями. В дальнейшем я опишу спецификацию рабочего процесса Flyte и покажу, как разработчики могут использовать работу друг друга, комбинируя задачи в супер-рабочие процессы.
Попробуйте FlyteHub. Я надеюсь, что, сотрудничая над рабочими процессами с открытым исходным кодом, мы сможем создавать лучшие продукты.
Следите за обновлениями.
