В датасаенсе есть два вида инференса - батчевый и реалтайм. Батчевый используется там, где нет жесткого требования по времени ответа модели и можно сразу обсчитывать большой объем данных. В реалтаймовом подходе важно как можно быстрее дать ответ модели по точечному объекту - это может быть какой то текст, картинка или даже аудиофайл. Мы сфокусировались на проблеме скорости ответа и загруженности железа в реалтаймовом инференсе. Решили ее. Об этом и пойдет доклад.
Если вы запускаете реалтайм инференс то обязательно озадачьтесь вопросом “как увеличить пропускную способность модели”.
На самом деле увеличить пропускную способность модели не сложно: надо разбить вычисление на этапы, каждый этап вынести в подпроцесс, заскейлить нужное число процессов, добавить батчирование в модель и вы получите нужны результат.
Правда придется пописать немного или даже много кода, порешать несколько подводных камней питона. Либо вы можете взять готовое решение - библиотека aqueduct. Но опять же, это не обязательно, можно все кейсы порешать самостоятельно.

Краткий рассказ о возможностях библиотеки / cli-инструмента INSTLD (https://github.com/pomponchik/instld).
Фичи:

1. Позволяет запускать скрипты без предварительной установки библиотек
2. Позволяет в одном проекте использовать две разные версии одной библиотеки, либо 2 с несовместимыми между собой зависимостями.
3. Позволяет использовать одновременно несколько виртуальных окружений.
4. Позволяет узнать, какие именно библиотеки реально используются в коде проекта.
5. Дает опцию устанавливать библиотеки прямо в рантайме.

Библиотека полезна прежде всего тем разработчикам, которые часто распространяют свои скрипты в виде файлов, а также системным администраторам, и тем, кто пишет скрипты для одноразового запуска. Кроме того, тем, кто часто сталкивается с проблемой несовместимости между собой библиотек.

Предмет доклада: построение приложения знакомств с нуля посредством python, а именно фреймворка FastAPI. Доклад может быть полезен, так как я покажу пример оптимизации нагрузки на backend, а именно как мы перешли с простой инфраструктуры на распределенную с использование очередей. Очевидным плюсом решения является возможность показать как обрабатывать большее количество пользователей и запросов и как мы в дальнейшем можем легко масштабироваться.