Теперь Кью работает в режиме чтения

Мы сохранили весь контент, но добавить что-то новое уже нельзя

Как подключить нейронную сеть к веб-приложению?

Программирование+4
Анонимный вопрос
  ·   · 3,0 K
Openstack DevOps and IBM/Informix Certified DBA...  · 21 апр 2022
Как развернуть модель машинного обучения
Если вы являетесь аналитиком, вы можете не разбираться в архитектуре веб-приложений, поэтому позвольте мне сначала проиллюстрировать это. Извините, если это чрезмерное упрощение и человеческое объяснение! Но я видел достаточно «развертываний модели ML», которые на самом деле представляют собой просто XGBoost, обернутый во Flask, и знаю, что это настоящая проблема.
Пользователь (здесь слева) использует браузер, в котором работают только Javascript, HTML и CSS. Это фронтэнд. Он может совершать вызовы на внутренний сервер для получения результатов, которые он затем может обрабатывать и отображать. Бэкенд-сервер должен как можно скорее отвечать на запросы внешнего интерфейса; но серверной части может потребоваться взаимодействие с базами данных, сторонними API и микросервисами. Серверная часть также может создавать медленные задания, такие как задания машинного обучения, по запросу пользователя, которые он должен помещать в очередь. (Имейте в виду, что обычно пользователь должен как-то аутентифицировать себя).
Теперь давайте поговорим об архитектуре распределенного веб-приложения.
В общем, мы хотим запускать как можно больше серверных экземпляров для масштабируемости. Вот почему на диаграмме выше из «сервера» выходят пузырьки; они представляют «больше таких». Таким образом, каждый экземпляр должен оставаться без состояния: закончить обработку HTTP-запроса и выйти. Не храните ничего в памяти между запросами, потому что первый запрос клиента может быть отправлен на один сервер, а последующий запрос — на другой.
Плохо, если у нас есть долго работающая конечная точка: она свяжет один из наших серверов (скажем… выполнение какой-то задачи машинного обучения), оставив его неспособным обрабатывать запросы других пользователей. Нам нужно поддерживать отзывчивость веб-сервера и передавать ему длительные задачи с каким-то общим постоянством, чтобы, когда пользователь проверяет ход выполнения или запрашивает результат, любой сервер мог сообщить об этом. Кроме того, работы и их части должны выполняться параллельно таким количеством workers, на которое есть ресурсы.
Ответ — очередь «первым пришел — первым вышел» (FIFO). Серверная часть просто ставит задания в очередь. Workers выбирают и обрабатывают задания из очереди, выполняя обучение или логические выводы и сохраняя модели или прогнозы в базе данных по завершении.
С библиотекой MLQ буквально все, что вам нужно для внутреннего веб-сервера, — конечная точка для постановки задания в очередь, конечная точка для проверки хода выполнения задания и конечная точка для обслуживания результата задания, если задание завершено.
Архитектура для настоящего развертывания модели машинного обучения такова:
Бэкенд-сервер получает запрос от веб-браузера пользователя. Он завернут в JSON, но семантически будет примерно таким: «Завтра среда, и сегодня мы продали 10 единиц. Сколько звонков в службу поддержки нам следует ожидать завтра?»
Серверная часть помещает задание {среда, 10} в очередь (какое-то место, отделенное от самой серверной части, например, Redis в случае MLQ). Очередь отвечает: «Спасибо, давайте назовем это заданием с идентификатором 562».
Бэкэнд отвечает пользователю: «Я сделаю этот расчет. У него ID 562. Пожалуйста, подождите». После этого серверная часть может свободно обслуживать других пользователей.
Веб-браузер пользователя начинает отображать счетчик «подождите».
Workers — по крайней мере, те, которые в данный момент не обрабатывают другое задание — постоянно опрашивают очередь на наличие заданий. Возможно, Workers  существуют на другом сервере/компьютере, но они также могут быть разными потоками/процессами на том же компьютере. Workers  могут иметь графические процессоры, тогда как внутреннему серверу, вероятно, это не нужно.
В конце концов, worker возьмет задание, удалит его из очереди и обработает (например, запустит {Wednesday, 10} через какую-нибудь модель XGBoost). Это сохранит прогноз в базе данных. Представьте, что этот шаг занимает 5 минут.
Между тем, веб-браузер пользователя каждые 30 секунд опрашивает серверную часть, чтобы узнать, выполнена ли еще задача 562. Серверная часть проверяет, есть ли в базе данных результат, сохраненный с идентификатором = 562, и отвечает соответствующим образом. Любой из наших многочисленных горизонтальных бэкэндов может обслуживать запрос пользователя. Вы можете подумать, что общая база данных — это единственная точка отказа, и вы будете правы! Но отдельно мы подготовили реплики и какой-то механизм аварийного переключения, возможно, сегментирование/балансировку нагрузки, так что все в порядке.
Через пять минут с лишним пользователь опрашивает результат, и мы можем его обслужить.
Здесь нужно немного больше, в основном для обеспечения отказоустойчивости и постоянства (что, если рабочий процесс отключится на полпути к выполнению задания? Что, если ввод пользователя будет ненужным и приведет к сбою задания?) Но это основы. Вот очень простой рабочий шаблон для MLQ. Он просто ждет, пока не получит задание, затем запускает функцию с параметрами задания и сохраняет результат. Вы можете запускать столько этих вещей параллельно, сколько хотите, на одном и том же сервере или на распределенных серверах. Если вы посмотрите в репозиторий, вы найдете полный код для этого с моделью Nietzche/Tensorflow RNN.
Есть несколько хороших доступных фреймворков очередей или вещей, которые делают подходящие очереди, включая Celery, Dask, ZeroMQ, родной Redis и библиотеку, которую я недавно сделал, чтобы быть простой в использовании версией всего этого для развертывания побочных проектов без сложностей: MLQ . Кафка тоже вещь, но постоянные читатели знают, что я не поклонник сверхархитектурных проектов на основе Java. MLQ незрелый; Я не пытаюсь продать это здесь. Вместо этого используйте Celery для серьезных проектов.
На этой неделе я провел некоторое время с NVIDIA и спросил об их каноническом решении для организации очереди заданий (в частности, в моем случае, чтобы я мог сделать ферму графических процессоров доступной для всех на работе с ноутбуком Jupyter, чтобы все они не пытались отправлять задания). в то же время). Его пока нет, но меня уверили, что над ним работают. А до тех пор единственным способом будет вручную свернуть решение с помощью системы очередей.
(Также, возможно, представляет интерес с этой встречи: все согласились, что MXNet — действительно хороший фреймворк, возможно, лучший — но, к сожалению, он может исчезнуть).
Смотри также https://yandex.ru/q/question/chto_delat_posle_togo_kak_obuchil_model_2615a559/?answer_id=9d2c4c73-71a... Читать дальше