Comments 4
Уф. В текущем описании выглядит, пардон, как "типичный ML-проект": "Давайте для решения 1001 раз решенной задачи затащим в проект hypetechnologyX" (инвесторам это нравится)
Тащить для реализации очереди задач - лишнюю инфраструктурную сложность нууу.... эээ... такое себе. Я понимаю, решать с помощью RMQ задачу роутинга данных по 10 моделям, горизонтального масштабирования FastAPI-бэкенда, добавлять персистирующий уровень для выскодинамических окружений или там еще чего в этом духе - так нет же.
Не надо так.
Если проверенные и устойчивые инструменты используются по назначению, в этом нет ничего плохого.
В независимости от масштаба.
Если на стоимость владения решением пофиг, эксплуатировать собственное писево не планируется, но есть необходимость фигак-фигак-и-инвестору не включая голову - то пуркуа бы не па?
В остальных случаях имеет смысл озадачиться вопросами "А адекватен ли выбор инструмента решаемой задаче? А будут ли у пользователя специалисты по администрированию вот этого вот всего? А нужны ли нам в кодовой базе новые инфраструктурные-и-не-только зависимости или может быть полтораста строчек pure-python кода для организации очереди внутри приложения нам хватит?". Тут я не то, что "ответа" на эти вопросы - а и самих вопросов-то не увидел.
Чем-то похоже на недавно опубликованную мною статью. Похоже, тема реально хайповая
RabbitMQ как способ масштабирования ML проекта