Как изменить архитектуру rpc сервера для асинхронной работы?
Я работаю над pet-проектом распознавания голосовых сообщений(перевода их в текст). Сейчас используется 2 сервиса связанных очередью сообщений(rabbitMQ): backend:
1) получает голосовые сообщения от клиентов
2) кладет сообщения в очередь запросов на распознавание
3) считывает результаты распознавания из очереди ответов и отсылает клиенту
model_server (Python)
1) считывает запросы на распознавание голоса из очереди запросов на распознавание
2) выбирает подходящую speech-to-text модель и распознает голос
3) кладет результат в очередь ответов
Я хочу реализовать поддержку нескольких моделей в model_server(как минимум распознающих различные языки) при этом обрабатывать запросы асинхронно и оптимально по памяти и времени(модели могут занимать много памяти и долго инициализироваться, поэтому желательно свести количество одновременно инициализированных моделей к минимуму).
На данный момент рассмотрел следующие варианты:
1) Создавать инстанс модели на каждый запрос на распознавание. Это позволяет асинхронно обрабатывать запросы, но требует непредсказуемо много памяти
2) Запускать N model_server-ов , каждый работает только с одной моделью, которая инициализируется один раз. Здесь также потенциально большой расход памяти + нужен сервис, распределяющий запросы на нужный model_server
3) (Текущая реализация) каждый model_server инициализирует одну модель, но обрабатывает запросы для всех моделей. Если текущая модель не подходит для запроса, то вместо нее инициализируется подходящая и запрос обрабатывается. При таком подходе количество моделей не зависит от числа запущенных model_server, но внутри model_server не получится обрабатывать запросы асинхронно, т.к. инстанс модели будет общим.
Вопрос - как лучше изменить архитектуру чтобы:
1) в систему можно было добавлять новые модели(например для разных языков) и это не требовало бы запуска дополнительных model_server-ов
2) model_server потребляет минимум ресурсов (примерно равный ресурсам, требующимся для работы наиболее "тяжелой" модели)
3) обработка длинных сообщений model_server-ом не критично замедляет обработку остальных(для этого предполагаю использовать асинхронную обработку)
Средний
Простой
Средний
