Pull to refresh

Comments 12

3 секунды на ответ — это же офигеть как много

Согласен, но если требуется обработать большой батч задач (скажем 100-200 тысяч), то лямбда справится лучше кластера, так как гораздо быстрее смасштабируется.
OpenFaas идет вместе с похожими примерами (Tesseract OCR, Text-to-Speech, Inception, Colorization и тд.), но на ответ уходит миллисекунд 100 в среднем. Возможно, дело в том, что все данные сразу находятся в образе и в контейнере и не выкачиваются каждый раз.
Думаю, стоит уточнить, что оплата взымается как за запрос, так и за время исполнения запроса: aws.amazon.com/lambda/pricing. При использовании 512 Mb оперативы нужно заплатить 0.2 * 10e-6$ за запрос + ~0.8 * 10e-6$ за каждые 100ms выполнения (с округлением в большую сторону). Что, впрочем, все равно дешево.

Ну и раз уж разговор про deep learning, то стоит также отметить, что GPU-инстансов в AWS Lamda пока не завезли. Весь inference – на CPU.
Может проще зайти с другой стороны? K8S в том же облаке и регионе, в нем крутится под(ы) c REST/gRPC endpoints, а тонкая lambda используется лишь для принятия запросов и отправке их на инференс. И тут уже и GPU можно использовать, и проблема Cold Start снимается навсегда.
Что бы не выставлять наружу K8S напрямую. Аутентификация, валидация и так далее — это тоже расходы.
Но в целом я с вами абсолютно согласен — Serverless, на мой взгляд, лишь красивый способ продать излишки вычислительных мощностей сверх-мелкой розницей. И без этого вполне можно обойтись: нечего баловать.
каталоги готовых решений

а поделитесь ссылками на каталоги?
для TensorFlow формат .pb родной?

pb родной. Каталог моделей есть здесь (https://github.com/tensorflow/models) и здесь (https://github.com/tensorflow/hub)

Спасибо за статью, хотел бы заметить что вы не уточнили одно очень важное ограничение ламбд, а именно эфемерное хранилище не может превышать 512 мб, следовательно если ваша модель больше, ваша ламбда сломается во время запуска.
Мне не совсем понятно зачем закачивать модель с s3 в эфемерное хранилище, скорость чтения с s3 штука непредсказуемая и может выстрелить вам ногу. Смотрите у нас есть след ограничение:


Size of code/dependencies that you can zip into a deployment package (uncompressed .zip/.jar size).: 250mb

Если ваша модель в сжатом виде не превосходит данного ограничения, то просто пакуем ее с кодом ламбды и в рантайме пользуемся из /var/task/YOUR_LAMBDA.


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


На мой взгляд не хватает разъяснений о Serverless.com который никакого отношения к AWS не имеет ибо является фремворком среди других фреймворков FaaS таких как SAM, Zappa, Claudia JS, итд.

Большое спасибо за комментарий. По поводу ограничения в 500мб я согласен, в текущей имплементации оно есть. Если модель помещается вместе с кодом, то в идеале лучше ее класть туда, но проблем с S3 я на высоких нагрузках не наблюдал. По поводу Serverless.com и контейнеризации я согласен, спасибо за обратную связь.
Sign up to leave a comment.