Комментарии 3
Готов поспорить, что в ближайшем будущем автор узнает про системы обмена сообщениями (например Rabbit MQ), и будет ему счастье.
Понятно, что для "честной" проверки пропускной способности надо включать сеть и веб-сервис в уравнение (и писать какие-то неизбежные велосипеды для этого), но в качестве бейслайна я бы использовал просто максимально быстрый локальный пре-процессинг (используя тот же multiprocessing) и батчи поверх.
Понятно, что тут неизбежно тоже возникают очереди, но в качестве наколеночного эрзац решения для проверки скорости ... подойдет `Dataset` и `Dataloader` из PyTorch, который под капотом это самое и делает.
Интерес представляет именно разделение оверхеда на сеть, препроцессинг и тупое "ожидание" видеокартой нового батча (что можно увидеть на примере того же Dataloader).
Внешние очереди были первой идеей, пришедшей в голову, но зачем они тут, если всё происходит внутри одного приложения? В данном случае multiprocessing queue отлично заменяет очередь и нет необходимости рядом держать такую сложную систему как RabbitMQ или подобное. Может вы имеете в виду полную замену REST сервиса на очереди, но в начале статьи описана инфраструктура в которой необходимо было произвести изменения и замена REST на что то другое не предполагалась.
Включать сеть в уравнение нам тоже не надо. Клиент и сервис приложения работают на одном хосте, в начале статьи есть небольшое описание инфраструктуры. Для большинства случаев данные до сервиса доставляются через kafka и предсказания так же улетают в kafka топик. Для нас важно сколько объектов мы прочитаем из топика и запишем по ним предсказаний за единиу времени.
На сколько я понял вы описываете решение в котором мы потоково обрабатываем данные, то есть подписываемся на очередь и загоняем поток в torch.Dataset, звучит интересно, но тут мы ответственны за предоставление быстрого http сервиса а не полноценной системы. Думаю в дальнейших статьях будет детальнее раскрыта инфраструктура и причины по которым мы используем http
но тут мы ответственны за предоставление быстрого http сервиса а не полноценной системы
Наверное в этом основное отличие наших сетапов, если ничего не надо кроме отправки условного файла в сетку, то наверное multiprocessing.queue действительно хорошее решение.
Просто когда есть много всяких разных воркеров разного толка наверное системы обмена сообщениями становятся интереснее.
так же улетают в kafka топик
Ну то есть оно как бы и является своеобразной очередью у вас)
загоняем поток в torch.Dataset
С помощью него и Dataloader можно просто на коленке оценить скорость работы инференса в идеальном мире, сервис бы на таком писать я бы не стал.
Оптимизация сервинга нейросетей