Версия сайта для слабовидящих
В этой статье для специалистов по Machine Learning рассмотрим, от каких факторов зависит выбор MLOps-средств и как сделать его наиболее верным способом. Когда развертывание продукта с открытым исходным кодом или индивидуального решения на собственной инфраструктуре лучше готового инструмента в облаке и почему часто бывает наоборот.
3 главных фактора выбора MLOps-решений
MLOps – это набор инженерных практик, чтобы сократить разрыв между различными специалистами, участвующими в процессах разработки, развертывания и эксплуатации систем машинного обучения. Сегодня эта концепция является одной из наиболее популярных тем в сообществе специалистов Machine Learning. Однако, она появилась совсем недавно, поэтому степень зрелости существующих MLOps-решений невысока и пока отсутствуют отраслевые стандарты, которые могут использоваться как критерии выбора того или иного инструмента. Кроме того, у каждой компании могут быть свои уникальные потребности в MLOps-инструментах, а потому сложно выделить универсальный набор функциональных возможностей, который подойдет для любого случая. Например, здесь мы рассказываем, как реализовать полноценную MLOps-платформу на открытых инструментах.
Тем не менее, можно выделить 3 основные фактора, от которых зависит выбор средств реализации MLOps-концепции:
- команда – сколько людей вовлечено в ML-проект и каким образом выстроены процессы коммуникации между ними. Для небольшой команды, где один человек совмещает несколько ролей и все это сосредоточено в рамках одного рабочего пространства, в т.ч. физической локации, нет смысла разворачивать сложное и дорогое MLOps-решение. Возможно, будет достаточно простой связки Git с MLflow, о чем мы писали здесь.
- Инструментарий – непосредственно сами инструменты, с помощью которых реализуются возможности MLOps: MLflow, Git, Apache Spark и пр., о которых мы рассказываем в этой статье.
- Инфраструктура — вычислительная платформа, на которой будет работать инструментарий MLOps, например, Kubernetes, Google Cloud Platform и пр.
Оставив за рамками этой статьи организационный фактор, относящийся к команде специалистов, сосредоточимся на рассмотрении инструментария и инфраструктуры. Здесь возможны следующие варианты:
- готовые продукты от провайдеров, средства с открытым исходным кодом или разработка индивидуального решения. Последнее потенциально может дать большую выгоду и гибкую адаптацию под уникальные потребности, но требует высокой квалификации штатных MLOps-инженеров.
- инфраструктура от облачных провайдеров или самоуправляемая среда. Самые крупные провайдеры облачных услуг (AWS, Google Cloud Platform и Microsoft Azure) предлагают различные варианты поддержки машинного обучения, но надежные MLOps-решения пока отсутствуют. Впрочем, многие компании по-прежнему поддерживают свои собственные датацентры и используют эти среды для размещения инструментов MLOps.
Теперь рассмотрим, каковы преимущества и недостатки различных комбинаций из этих вариантов по внедрению MLOps-подхода, об основных шагах которого мы писали здесь.
Сравнение альтернатив и их комбинаций
Благодаря зрелости предлагаемых решений, готовый инструментарий в инфраструктуре облачного провайдера может реализовать наиболее эффективный способ развертывания MLOps в компании. Нет необходимости в самостоятельном привлечении дорогостоящих ML-инженеров: поддержка продукта и облачной инфраструктуры осуществляются поставщиками по гарантии. Однако, на практике, готовые решения от разных поставщиков не всегда хорошо сочетаются друг с другом и облачной инфраструктурой. Впрочем, возможно, этот вариант окажется лучшим для стартапов, производящих НЕ ML-решения. Например, сельскохозяйственные услуги, адаптированные к особенностям местности и погодным условиям регионов. В этом случае сотрудники могут использовать модели Machine Learning для прогнозирования погоды, но без погружения в тонкости MLOps. При развертывании готового решения в самоуправляемой среде проблема его интеграции в собственную инфраструктуру также может возникнуть. Впрочем, для крупной компании, чей основной продукт не AI/ML, но которая имеет собственную развитую вычислительную платформу, например, сеть ресторанов быстрого питания со своими системами планирования закупок.
В случае выбора MLOps-продукта с открытым исходным кодом и его размещения в инфраструктуре облачного провайдера проблемы с переносом индивидуального решения в облачную среду тоже могут возникнуть. Однако, такой вариант подходит для компаний, где есть штатные MLOps-инженеры, но необходимо сократить вычислительную платформу физически, например, чтобы с целью избавления от накладных расходов на ее эксплуатацию и поддержку.
Наконец, при развертывании продукта с открытым исходным кодом или собственного решения в самоуправляемой инфраструктуре, проблема взаимной адаптации фреймворков снимается. Этот вариант дает полный контроль над MLOps-компонентами, позволяя инженерам реализовать все, что им нужно на собственной вычислительной платформе. Однако, при том, что эта комбинация обеспечивает большую гибкость, она возлагает большую ответственность на команду специалистов, что может стоить очень дорого. Тем не менее, крупные корпорации, которые специализируются на ML или используют AI в качестве ключевого инструмента производства своих продуктов, активно используют эту комбинацию. Например, Apple, Google или Amazon, которые имеют собственную мощную вычислительную платформу и сильную команду талантливые Data Science специалистов, создающих уникальные ML и MLOps-решения. О том, как сделать выбор между двумя самыми популярными MLOps-фремворками, Mlflow и Kubeflow, читайте в нашей новой статье.
Как выбрать наиболее подходящие инструменты и инфраструктурные решения для внедрения MLOps в реальные проекты аналитики больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
