Комментарии 4
Здравствуйте, нормальная реализация должна поддерживать складывание запросов в очередь, инференс вне потока веб-сервера и поллинг результата. Ваша «архитектура» совсем не жизнеспособна за пределами линейной регрессии и минимальной нагрузки.
Это может работать только с внешним диспетчером очереди, который будет в вашу архитектуру джобы закидывать. Зачем ей тогда RestAPI?
И еще нет батчинга, что для ряда моделей дает буст.
Здравствуйте, вы правы, этот код не жизнеспособен за пределами очень простых моделей и минимального количества пользователей. Но цель этой статьи показать основную идею для тех, кто хотел бы начать или продолжить реализацию Model Serving инструмента. При дальнейшей реализации, разработчики уже смогут добавить очередь, gpu поддержку, репликацию, батчинг и т.д., все, что нужно для полноценной работы. Поэтому, я рекомендовал использвать bentoml и seldon core и не брать этот код в production.
RestAPI здесь нужен затем, что servingml server, работает не зависимо от клиента, где цель клиента только в том, чтобы передать архив проекта на сервер, который уже сам должен распределять задачи. Опять же, это не я придумал, а рассказал, то как работают данные фреймворки, в первую очередь mlrun.
Сам же servingml server может быть доведен до того, чтобы использовать его в kubernetes, добавив в helm.
Этот код не может быть в production
советую использовать seldon core с его экосистемой
используйте bentoml
Можете пожалуйста пояснить чего в servingml принципиально не хватает чтобы пользоваться им в продуктивной среде?
Выше @ivankudryavtsev высказал несколько замечаний, хотелось бы услышать Вашу точку зрения на этот счет
Как работают Model Serving инструменты изнутри. Пишем свой на Python и Docker с нуля