Недавно WekaIO провела вебинар с Джулией Палмер из Gartner, на котором она рассказала о переосмыслении хранилища для рабочих нагрузок искусственного интеллекта (ИИ) и машинного обучения (МО). Она напомнила нам об этой цитате из Стюарта Бранда, которая может вызвать несколько пугающий, но метафорически точный визуальный образ:
“Как только новая технология накатывает на вас, если вы не являетесь частью парового катка, вы являетесь частью дороги”.
Это правда. В мире искусственного интеллекта появляются новые технологии, и если вы не примете их, вы останетесь позади. Исследование Gartner показало, что 85% компаний приступают к проектам ИИ, несмотря на тот факт, что рабочие нагрузки ИИ сопряжены с уникальными проблемами, с которыми раньше не сталкивались даже ветераны систем хранения данных. Это означает, что ИТ-инфраструктура находится в состоянии постоянных изменений, что может быть пугающим и захватывающим, но ИТ-специалистов нелегко напугать, поэтому они обычно готовы к трудностям, которые возникают на их пути.
Давайте поговорим здесь о том, как опередить события и узнать больше как о рабочих нагрузках ИИ / МО, так и о том, как переосмыслить ваше хранилище для их учета.
Gartner спросила более 3000 генеральных директоров и ИТ-директоров, что, по их мнению, является наиболее важной передовой технологией на современном технологическом рынке. Конечно, подавляющее большинство указали, что это искусственный интеллект и МО, и это технология № 1, в которую они инвестируют ресурсы на будущее, как для внутреннего, так и для внешнего использования. Фактически, двое из пяти уже внедрили некоторые элементы искусственного интеллекта в своих собственных компаниях, некоторые, в производственных средах. Однако самым захватывающим было то, что более 85% из них рассматривают возможность использования искусственного интеллекта в своих инфраструктурах в течение следующих двух лет. Послание Джулии для всех заключается в том, что вам лучше знать этапы конвейера ИИ / МО и быть готовыми включиться в свои собственные проекты, потому что искусственный интеллект вступает в полную силу!
Этапы конвейера машинного обучения (МО)
В конвейере МО много движущихся частей, особенно если учесть, что в конвейер постоянно поступают новые данные. Давайте посмотрим на различные этапы этого конвейера с точки зрения хранилища и посмотрим, что происходит на каждом этапе.
- Прием данных – данные собираются и отправляются в хранилища данных, где их необходимо классифицировать, а иногда и очищать. Во внешнем интерфейсе эта фаза требует большого объема данных и, следовательно, большой емкости.
- Подготовка данных – При использовании ИИ/МО выполняется множество операций с чрезвычайно высокой пропускной способностью, а этап подготовки данных требует много последовательных операций записи, поэтому ваша скорость записи должна быть достаточно высокой, чтобы не отставать.
- Обучение модели – Этот этап является очень ресурсоемкой частью конвейера ИИ/МО. На этом этапе процесс переходит от интенсивного использования данных к процессу, чувствительному к задержке. Задержки могут снижать скорость обучения модели и конечное время получения результата для проекта. Этот этап, вероятно, сопряжен с наибольшими трудностями, потому что здесь вам нужна высокая пропускная способность и низкая задержка.
- Вывод – На этом этапе вам нужна чрезвычайно низкая задержка. Возможно, у вас меньший ввод-вывод и смешанные рабочие нагрузки, но здесь уже именно это главное.
- Обработка и архивирование данных – Последним, но не менее важным этапом является обработка данных и активное архивирование. Как мы знаем, на данном этапе необходимо сохранить большой объем данных, потому что правильная настройка ИИ/МО хороша настолько, насколько это необходимо для тестирования и запуска моделей. Возможно, на этом этапе мы говорим уже о многопетабайтном масштабе активного архива.
Перед вами стоит задача определить, какой тип системы хранения вы будете использовать для обработки всех этих данных. Понадобятся ли вам пять разных и громоздких систем хранения? Иногда это так, если вы недостаточно продумали архитектуру в начале своего проекта. Что еще хуже, разным системам иногда требуется какой-то тип системы управления данными поверх них для перемещения данных и обеспечения контроля доступа. Итак, если вы думаете обо всех этапах как об отдельных системах, требующих развертывания отдельных и дополняющих друг друга архитектур хранения, вы окажетесь в мире страданий, о чем первые последователи ИИ/МО узнали на своём личном опыте.
В результате сейчас существуют уникальные стартапы, решающие эти задачи, минимизирующие архитектурные сложности и накладные расходы и максимизирующие выгоду от огромных наборов данных.
Требования к выбору хранилища для инфраструктур ИИ/МО
Существует шесть аспектов инфраструктуры хранения данных, которые необходимо учитывать по мере продвижения вперед:
1. Портативность — для большинства специалистов по ИИ/МО становится обязательным требованием возможность организации хранения данных в любом месте. Центры обработки данных больше не являются центром управления и потребления данных. В современных средах данные и хранилище могут находиться где угодно, однако большинство существующих сегодня решений для хранения данных разработаны с учетом единственного центра обработки данных. Те, кто ищет решения для хранения данных для своих рабочих нагрузок ИИ, должны всегда спрашивать о факторе переносимости. Данные могут по-прежнему размещаться в центре обработки данных, но велика вероятность того, что некоторые хранилища данных также будут размещены на границе или в других точках сбора. Очевидно, что переносимость решения является требованием №1; однако сами данные также должны быть переносимыми. Специалисты по ИИ должны использовать технологии, позволяющие перемещать данные из периферийных зон в облако, а может быть, даже из центра обработки данных в облако, и наоборот. Именно поэтому необходимо учитывать переносимость решений и переносимость данных, поскольку вы можете проводить обучение модели в общедоступном облаке, а выводы делать на границе, поэтому данные нуждаются в различных вариантах доставки.
2. Совместимость — этот аспект чрезвычайно важен, поскольку рабочие нагрузки ИИ/МО не происходят в изолированном пространстве. На самом деле, ИИ/МО должны поддерживать множество новых и современных библиотек. Проект ИИ/МО должен развиваться вместе с разработчиками или владельцами бизнеса (и обеспечиваться ими), поэтому он должен быть совместим с инструментами, которые вы используете для обеспечения. Кроме того, он должен изучить все API и справиться с рабочей нагрузкой в режиме самообслуживания. Наконец, ваша архитектура должна поддерживать контейнерные платформы, в основном приложения, ориентированные на Kubernetes. Если вы выбираете систему хранения, которая не является полностью встроенной, управляемой и способной развертываться в Kubernetes, вы, вероятно, обнаружите, что это решение не может поддерживаться в долгосрочной перспективе. По этой причине популярны программно-определяемые архитектуры.
3. Масштабируемость — люди постоянно говорят о больших масштабах, особенно для неструктурированных данных. Однако следует помнить, что архитектура также должна меняться, потому что, хотя большой масштаб очень важен, способность к уменьшению масштаба не менее важна. Многие проекты начинаются с малого, поэтому не стоит вкладывать средства в многопетабайтные решения, если на начальных этапах проекта требуется небольшая площадь. На самом деле, может оказаться, что вы только запускаете пробную концепцию какого-то инструмента и пытаетесь определить подходящее аппаратное обеспечение для его использования, поэтому вы хотите иметь возможность небольшого старта. Можно также начать с малого и развиваться по мере продвижения. Вы заметили, что мы не использовали здесь термин сетевое хранилище (NAS). Знаете почему? Потому что NAS — это вертикальная платформа, которая не может масштабироваться до размеров, необходимых для рабочих нагрузок ИИ/МО. Они могут прекрасно подходить для других рабочих нагрузок, но для ИИ/МО вам нужны архитектуры с масштабированием, и вам нужна распределенная файловая система, потому что когда мы говорим о масштабах в несколько петабайт (иногда десятки петабайт), вам нужна распределенная система, способная поддерживать миллиарды файлов. Кроме того, необходимо подумать о том, как будут масштабироваться метаданные. Вот почему распределенная горизонтальная конструкция — это то, что нужно, когда вы говорите о масштабируемости.
4. Производительность — В наши дни практически немыслимо, чтобы система не обеспечивала производительность. Рабочие нагрузки ИИ/МО требуют всё, что вы можете использовать для повышения производительности. Нагрузки с высокой пропускной способностью, большим вводом-выводом и случайным чтением / случайной записью требуют, чтобы нагрузки, ориентированные на пропускную способность, и нагрузки, ориентированные на задержки, гармонично сочетались друг с другом. Это очень сложно сделать. Вот почему нам нужны новые протоколы, нам нужны новые флэш-носители и нам нужно новое программное обеспечение, способное удовлетворить все эти требования. Кроме того, этап обучения ИИ/МО включает в себя очень дорогой компонент: графические процессоры. Для доставки данных им требуется быстрое хранилище; в противном случае графический процессор, потребляющий данные, ожидает, когда его загрузят с помощью ввода-вывода хранилища. Очевидно, что графические процессоры — это высокоэффективные ускорители обработки данных, которые могут помочь увеличить время получения результатов, но их использование экономически неэффективно, если они не загружаются данными в полном объеме. Кроме того, это не является экономически эффективным решением, если вы используете устаревшую файловую систему или платформу хранилища. Имейте в виду, что некоторые файловые системы хранения данных могут обеспечить очень впечатляющие показатели производительности при их тестировании, но вы должны убедиться, что выбранная вами система может обеспечить долговечность и производительность для достижения максимальной выгоды. Причина в том, что рабочие процессы ИИ/МО чаще всего нестабильны. Могут возникать скачки из-за различных действий, происходящих одновременно в одной и той же системе хранения, поэтому вам нужно обращать внимание на всю производительность. Производительность данных, конечно, важна, но также должна быть гарантирована масштабируемость производительности метаданных.
5. Программно определяемые модели — С точки зрения совместимости, ваша модель должна разворачиваться где угодно, поэтому выбор за программно-определяемыми архитектурами. Ваша программно-определяемая архитектура должна быть независимой от устройства, но при этом поддерживать новейшие аппаратные инновации. Например, когда NVMe впервые появилась на рынке, первыми сторонниками этой технологии были поставщики программно-определяемых хранилищ. Они первыми освоили новую технологию, поэтому являются хорошими партнерами для работы с рабочими нагрузками ИИ/МО, потому что они могут работать намного быстрее благодаря своей аппаратной независимости, что также упрощает развертывание программного обеспечения для управления данными в любом месте на границе, в ядре и в облаке.
6. Оптимизация затрат — Вам необходимо правильно распределить инвестиции в хранилище. Когда люди думают о хранилище для ИИ/МО, они, вероятно, думают о хранилище для самой требовательной фазы проекта, которая является фазой обучения, возможно, также вывода. Однако они часто не учитывают весь жизненный цикл хранения данных. Если они размещают все свои данные на одной платформе, это становится довольно большим и очень дорогим, что может оказаться непосильным испытанием для практиков, когда они поймут, что не могут поддерживать это. Это означает, что прикладным специалистам необходимо учитывать все этапы работы при выборе нового решения, включая действующий архив. Когда данные больше не нужны активно, их необходимо переместить в другие типы экономически эффективных решений для активного архивирования и глубокого архивирования. Эти решения должны быть такими же масштабируемыми, но не такими дорогими, если прикладные специалисты хотят максимизировать свою совокупную стоимость владения для всего процесса ИИ/МО. Программное обеспечение допускает такой тип многоуровневости в долгосрочной перспективе и может оказаться дорогостоящей частью решения, если не подумать об этом в первый день.
Заключение
Запуск любого проекта искусственного интеллекта – непростая задача, однако, затрачивая время и усилия на планирование всех этапов проекта в рамках конвейера искусственного интеллекта – включая обдумывание хранения на каждом этапе — можно обеспечить успех и свести к минимуму разочарование для всей команды.