Проблема масштабирования AI-ассистента: ограничения VRAM/CPU

Я и моя команда работаем над проектом AI-ассистента и столкнулись с проблемой масштабирования, для решения которой хотели бы попросить совета у сообщества. Моя основная специализация — backend и DevOps, поэтому я могу быть не до конца осведомлен о тонкостях в области ML.

Краткий контекст проекта: Мы разрабатываем ассистента, который подключается к звонкам в Google Meet. Его функционал включает транскрибацию речи в реальном времени, создание саммари по итогам встречи, выделение поставленных задач и пополнение базы знаний. Также ассистент способен отвечать на вопросы по базе знаний непосредственно во время звонка.

Текущая архитектура и стек: Система реализована на Python и разворачивается на платформе Runpod с использованием GPU A5000 (24 ГБ VRAM). Для подключения к Google Meet используется связка Selenium и undetected_chromedriver. Обработка аудиопотоков осуществляется через PulseAudio.

Используемые модели:

• Транскрибация: faster-whisper-large-v3-turbo-ct2
• Детекция голоса (VAD): silero-vad
• Синтез речи (TTS): silero-models

В текущей реализации для каждого экземпляра бота, подключающегося к звонку, создается отдельный процесс, который запускает собственный экземпляр Chrome и загружает в память свой набор ML-моделей.

Описание проблемы При использовании модели faster-whisper мы столкнулись с ограничением по видеопамяти. Система стабильно обслуживает 8-9 одновременных звонков, однако при попытке запустить десятый экземпляр происходит сбой из-за нехватки VRAM.

В качестве решения мы попробовали заменить модель транскрибации на gigaam-v2-rnnt в формате ONNX, что должно было снизить потребление VRAM. Однако это привело к новой проблеме: теперь, начиная с 7-го экземпляра, новые процессы не запускаются. Видеопамять при этом остается доступной, но, по всей видимости, мы столкнулись с ограничением по CPU или оперативной памяти.

Я рассматривал вариант изменения архитектуры в сторону микросервисов — вынести обработку моделей в отдельный, централизованный сервис. Он бы принимал аудиопотоки от всех ботов и возвращал результат. Однако существуют опасения, что передача аудиоданных по сети между сервисами внесет недопустимую задержку, что критично для функции ответа в реальном времени.

Основной вопрос заключается в том, можно ли оптимизировать текущую архитектуру? Например, существует ли механизм для совместного использования одной, уже загруженной в VRAM, копии модели несколькими Python-процессами? Если да, то какие инструменты или подходы следует изучить?

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