Зачем использовать WebAssembly для размещения scikit-learn в браузере?

Честно? Я не знаю. Но я действительно думаю, что WebAssembly - хорошая цель для развертывания ML / AI (в браузере и за его пределами).

В моей собственной академической работе и при работе с различными компаниями и больницами я часто сталкиваюсь с проблемой внедрения проверенных моделей в производство. Развертывание оказывается трудным; это одно из главных препятствий на пути внедрения множества полезных моделей в различных областях. Опробовав различные решения, мы решили использовать двоичные файлы WebAssembly для развертывания модели. Сейчас этот выбор не всегда понятен: многие специалисты по данным еще не слышали о WebAssembly, а если и слышали, то в основном связывают это с запуском задач в браузере. Кроме того, заинтересованные читатели быстро найдут такие проекты, как pyodide, который, хотя и очень интересен, ставит читателей на неверную ногу, предполагая, что развертывание модели может быть выполнено путем перемещения полного стека python в браузер: мы так не думаем об этом. . Мы просто рассматриваем WebAssembly как безопасную, портативную и эффективную цель компиляции для развертывания подогнанных моделей где угодно. В этой статье я попытаюсь объяснить наши аргументы в пользу этого выбора технологии.

Desiderata: чего бы мы хотели, запуская модели в производство?

Выбор технологии часто выигрывает от наличия хорошего набора желаний (требований, если хотите): что бы мы хотели, чтобы наша технология делала? Вот несколько вещей, которые мы рассмотрели при развертывании модели AI / ML:

Примечание. Я рассматриваю понятие «модель» довольно широко; это может включать предварительную и постобработку. Фактически, при генерации выводов часто «модель» - это просто набор операций, выполняемых над некоторыми входными данными, ведущих к некоторым выходным данным.

  1. Мы хотели бы минимально повлиять на методы работы тех, кто создает и проверяет модели. По сути, было бы здорово, если бы специалисты по данным / исследователи, которые создают и проверяют полезные модели, могли бы использовать свои предпочтительные инструменты также для развертывание. Это должно быть легко.
  2. Мы хотели бы, чтобы развернутые модели были эффективными с вычислительной точки зрения (т. е. быстрыми). Хотя во время обучения скорость выполнения может не быть большой проблемой (хотя скорость обучения вполне может быть), это будет проблемой, когда мы захотим многократно генерировать выводы. Если вы оцениваете модель тысячи раз в секунду, хорошо, если она работает быстро.
  3. Мы хотели бы, чтобы развернутые модели имели небольшой объем памяти. При развертывании было бы здорово, если бы выводы были эффективными не только с точки зрения времени, но и с точки зрения памяти. Небольшая и быстрая задача в конечном итоге улучшает взаимодействие с пользователем, снижает затраты и экономит значительное количество энергии.
  4. Мы хотели бы, чтобы развернутые модели были портативными. Нам не нужно перестраивать модели, когда мы перемещаем их с серверов на устройства IoT, на мобильные телефоны и веб-браузеры.
  5. Мы хотим, чтобы развернутые модели были безопасными и поддающимися проверке. Модель должна работать безопасно и изолированно, и должна быть возможность проверить, доступна ли правильная модель.
  6. Мы хотели бы иметь возможность легко экспериментировать с развернутыми моделями. После развертывания моделей должно быть возможно легко проводить A / B-тестирование различных версий модели.

Развертывание с использованием WebAssembly

Учитывая вышеприведенные пожелания, мы рассмотрели несколько технологий, варьирующихся от внедрения записных книжек jupyter в производство с использованием контейнеров докеров, до перестройки наших моделей в c или rust и компиляции исполняемых файлов для различных сред выполнения, до использования одного из постоянно растущих наборов продуктов, находящихся в настоящее время. предлагают упростить запуск моделей в производство (например, pyTorch, TFX, Lambda, Azure и т. д.). Все так или иначе провалилось. Контейнеры Docker позволяют просто копировать существующий стек Python, пакеты, модель и все остальное, но получающиеся контейнеры часто раздуваются и работают медленно. Восстановление производительно, но требует много времени. Существующие облачные сервисы показывают хорошие результаты по некоторым, но не по всем желательным. Итак, мы создали собственный процесс развертывания модели.

Наш процесс развертывания с использованием WebAssembly

Прежде чем проверять, «соответствует ли наш процесс развертывания с использованием WebAssembly желаемому, я думаю, мне следует объяснить необходимые шаги:

  1. Мы позволяем специалистам по обработке данных подбирать модели, используя свои любимые python или R пакеты / инструменты.
  2. Используя наши простые пакеты, например, пакет sclblpy для python, специалист по данным может загрузить сохраненную модель (или конвейер) прямо из предпочитаемой им рабочей области (см. Этот пост для простого примера).
  3. После загрузки модели мы автоматически «разлагаем» ее, т. Е. Удаляем все ненужные детали, и конвертируем только самое необходимое в двоичный файл WebAssembly. Этот шаг, по общему признанию, сложный, и нам потребовалось немало головной боли для создания, но, к счастью, его нужно сделать только один раз для каждого класса модели. После этого каждая модель известного класса моделей может быть автоматически оптимизирована и перенесена в WebAssembly. (Например: предположим, что вы подходите к модели линейной регрессии, используя scikit-learn. В этом случае сохраненный объект модели содержит много информации, которая не важна для вывода: мы эффективно разделяем объект на создать двоичный файл WebAssembly, содержащий только необходимые векторные операции).
  4. После создания .wasm двоичного файла, который следует стандарту WASI, чтобы сделать его полностью переносимым, его можно запускать где угодно. Мы часто заканчиваем размещением двоичного файла на наших серверах и созданием конечной точки REST для выполнения задачи вывода, но мы также развернули объекты модели в браузере и на периферии.

Итак, вот какой процесс у нас получился.

Что такое WebAssembly?

Думаю, будет полезно сделать небольшое отступление и объяснить WebAssembly. Согласно официальной странице WebAssembly, WebAssembly (сокращенно Wasm) - это двоичный формат инструкций для виртуальной машины на основе стека. Wasm разработан как переносимая цель компиляции для языков программирования, позволяющая развертывать в Интернете клиентские и серверные приложения . Теперь, хотя это правда, с появлением WASI и, среди прочего, потрясающих инструментов с открытым исходным кодом, предоставленных нашими друзьями из Wasmer, определение выглядит слишком ограниченным: двоичные файлы WASI можно запускать в любом месте. Итак, для нас WebAssembly - это цель компиляции, которая эффективно предоставляет исполняемые файлы, которые работают с собственной скоростью, в чрезвычайно маленьких и эффективных контейнерах практически в любом месте.

Итак, давайте проверим, подходит ли это…

Дезидерат 1: простота использования

В настоящее время мы можем преобразовывать модели в WebAssembly с помощью однострочного кода. Вот очень простой пример:

Мы можем сделать это практически для всех sklearn, statsmodels и xgboost. Сделать это можно с помощью пакета sclblpy.

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

Итак, да, мы думаем, что этот процесс достаточно прост.

Desideratum 2: вычислительно эффективный

Хотя WebAssembly обещает быть эффективным и быстрым, всегда полезно смотреть на реальные цифры. Мы подбираем модель BART для автоматической оценки собственности (AVM); См. Демонстрационное приложение здесь. Генерация 1000 апостериорных отрисовок при развертывании подогнанной модели с использованием контейнера Docker занимает чуть более 4,5 секунд для обхода (т. Е. Включая сетевую задержку). То же самое с использованием нашего развертывания WebAssembly постоянно занимает меньше секунды. Мы постоянно находим такое ускорение: см. Этот пост, чтобы узнать больше о тестах (мы также внимательно следим за WebGPU, быстро развивающимся дополнительным стандартом, который позволит нам добавить поддержку графического процессора в наши бинарные файлы WebAssembly, оптимизированные для ЦП) .

Итак, да, модель WebAssembly развертывается быстро. Тем не менее, хорошо понимать, почему это часто может быть намного быстрее, чем существующие выводы, основанные на rили python. Частично повышение скорости связано с переходом на скомпилированный язык более низкого уровня (т.е. строгая типизация, лучшее управление памятью, сильная оптимизация компилятора и т. Д.). Однако эти улучшения - только часть истории: развертывание модели WebAssembly также позволяет нам избавиться от многих задействованных «слоев»:

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

Desideratum 3: след памяти

Мы хотим, чтобы модели были небольшими с точки зрения памяти. И, учитывая анализ слоев, представленных выше, не просто «пакет» модели должен быть маленьким; было бы неплохо, если бы вся среда выполнения была как можно меньше и эффективнее. Продолжая демонстрацию AVM, это, кажется, работает хорошо: в R мы снизили размер самой модели BART до ~ 40 МБ, а время выполнения до ~ 80 МБ (и то, и другое потребовало некоторых усилий). Используя развертывание WebAssembly, мы получили модельный «пакет» размером чуть более 3 МБ и временем выполнения всего 10 МБ. Итого ~ 120 МБ против 13 МБ. Да, при развертывании модели WebAssembly требуется мало памяти.

Desideratum 4: портативность

Маленький и быстрый открывает новые возможности. Переносимость моделей WebAssembly позволяет запускать их на серверах, в браузерах, или на периферии. Это порождает новые сценарии использования: мы развернули модели распознавания объектов на дронах (чтобы облетать гавани и распознавать состояние обслуживания грузовых контейнеров). Мы также запускали рекомендательные модели в браузере пользователя, и мы можем отправлять модели в больницы (для целей радиологической диагностики) вместо отправки конфиденциальных данных пациента на центральные серверы. Переносимость. Проверить.

Desideratum 5: безопасный и поддающийся проверке

Довольно часто возникает вопрос: «Как мы можем гарантировать, что возвращенные выводы действительны»? Одним из преимуществ использования двоичных файлов WebAssembly является то, что мы можем тщательно проверять входные и выходные данные модели и консолидировать функциональность. Полученный двоичный файл впоследствии можно проверить с помощью простых контрольных сумм; мы можем быть уверены, что нужная модель будет доставлена ​​в нужное место.

Помимо проверки, мы, очевидно, хотим, чтобы пакет модели не причинял никакого вреда окружающей вычислительной среде; к счастью, это то, для чего был разработан WebAssembly; он по своей сути изолирован и безопасен.

Так что да, это тоже сработает.

Desideratum 6: Легкое экспериментирование

Когда разрыв в развертывании ликвидирован, мир не останавливается. Часто развернутая модель - это всего лишь один экземпляр всех моделей, которые можно было бы придумать для конкретной проблемы. Было бы здорово, если бы можно было легко тестировать разные версии модели. Бинарные файлы WebAssembly упрощают этот процесс: настройка A / B-тестов с двумя бинарными файлами (или даже настройка адаптивных схем, таких как выборка Томпсона по нескольким конкурирующим моделям) проста, если модель является автономной, ее легко доставить и легко запускать, упаковывать.

Правильная песочница и портативность упрощают эксперименты.

Заворачивать

У нас большой опыт запуска моделей в производство. Основываясь на этом опыте, мы закончили разработку новой платформы, которая упрощает развертывание модели через WebAssembly; для нас это все галочки. При этом техническое решение никогда не решит полностью проблему развертывания модели. Каждый раз, когда мы пытаемся преодолеть разрыв между обучением и проверкой моделей и их практическим использованием, мы сталкиваемся с организационными, юридическими, финансовыми и этическими вопросами. Мы не можем утверждать, что все эти проблемы можно легко решить. Но мы действительно думаем, что технически проблема развертывания разрешима, и WebAssembly предоставляет идеальное средство для решения связанных с этим проблем.

Отказ от ответственности

Приятно отметить мое личное участие в этом: я профессор Data Science в Jheronimus Academy of Data Science и один из соучредителей Scailable. Таким образом, без сомнения, я кровно заинтересован в Scailable; Я заинтересован в том, чтобы он разрастался, чтобы мы наконец смогли внедрить ИИ в производство и выполнить свои обещания. Высказанные здесь мнения являются моими собственными.