Давай деплой ML!
424 subscribers
50 photos
1 video
1 file
59 links
Пишу об ML инфраструктуре и алгоритмах, позволяющих ML системам работать эффективнее

Занимаюсь исследованиями по ML инфре, аспирант сколтеха
Download Telegram
Channel photo updated
Я - разработчик и создаю инфраструктуру для рекомендательных систем в одной из самых крупных ИТ-компаний, раньше делал платформу для MLOps и обучал AI-модели в других компаниях. Закончил ВМК МГУ, учусь в ШАДе и на ФКН в ВШЭ.

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

- Инфраструктура, облака и сервисы для разработки, обучения и инференса моделей
- AI-модели и их архитектура, кейсы в разработке и внедрении
- Проекты, задачи, команда, обучение, развитие и другие мысли и инсайты из моих будней

💬Комменты и реакции открыты, заходите с любыми идеями и обратной связью)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥43
Цена хайпа инференса

OpenAI тратит на инференс по разным оценкам 100-700k USD в день. А ещё такие нейронки нужно учить - и это тоже огромные затраты (которые кратно больше затрат на инференс)

Большие ИИ-модели требовательны к ресурсам.
Например, для инференса одной GPT2/3/3.5/4 - нужно 4 или 8 высокопроизводительных карт с быстрым соединением между ними. Реальное использование в проде LLM требует ~40-100 видеокарт под постоянную утилизацию. Подходят сервера dgx/hgx от nvidia по 8 карт с nvlink. Сейчас в России такие в достаточном количестве есть только у Сбера и Яндекса.

💰 Один сервер на 8 карт А100 стоит 200-300k USD (примерные оценки, без установки и поддержки), в итоге получается стоимость проекта только по железу от 200k USD и других вариантов при желании все разворачивать на своей инфре нет. Аренда тоже дорога - от 16k USD в месяц. Вывод понятен - GPT (и другие большие модели) отлично себя показывают, но для использования нужно учится резать косты

⚡️Я вижу две развилки:
Первый вариант - сжатие сети под конкретные задачи (с потерей качества).
Второй - появление отдельных компаний, которые будут инференсить тяжелые модели и давать их рынку по Pay as you go

В развитие обоих направлений верю, хотя в прод сейчас идут сильно сжатые модели (дообучение под задачу + квантизация в int4)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2🫡1
👨‍💻 Очень производительный брокер сообщений

Почти любой продакшен обрабатывает часть данных через брокеров сообщений. На слуху есть 3 фреймворка: Apache Kafka, Rabbit MQ, Apache Flink
Причем Kafka чаще всего используют в больших проектах

Недавно увидел Redpanda
Ребята написали хороший стриминг на c++, получив значительный буст в производительности
▶️ API взято из Kafka - что очень круто. То есть вы можете не переписывая свой код начать их использовать (в идеале)
▶️ Сборка в один бинарь (single binary). Полагается для отказоустойчивости на свою реализацию рафта и не зависит от, например, zookeeper как в Kafka
▶️ Архитектура - по треду на каждое cpu. Должны выжимать все с низлежащей машины. Попозже внимательно посмотрю в код
▶️ Есть UI. Очень похож на Kowl для Кафки. Даже свежее выглядит
▶️ Их уже используют стриминговые, трейдинговые и другие нагруженные кампаний, так что гарантии и цифры не только на бумаге

🛞 Здесь можно посмотреть бенчмарки
Крутое и наглядное сравнение. Обычно таких бенчмарков у проектов нет
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Зачем намеренно снижать скорость ответа ML сервиса?
🤔 Многие хотят, чтобы ML работал в режиме реального времени.
Это круто для MVP или тестов, но приводит к проблемам при выходе в продакшен:
необработанным запросам и доступностью на уровне 95-98%

Альтернативы:

Пересчет по таймеру
Скапливаем данные и иногда (раз в час/день/неделю) обрабатываем. Если что-то пойдет не так, вы сможете починить систему и обработать накопившиеся данные.
Самый простой и правильный способ для первой версии продукта

Обработка около реального времени. Брокеры сообщений
Пользуемся брокерами сообщений и поточными протоколами. Ускоряем предыдущий способ, делаем надежнее, добавляем больше железа.
Показываете MVP, и потом, когда бизнес часть проекта подтверждена, занимаетесь его улучшением
Самый использующийся подход

🛠 Если все таки надо реальное время - ограничивайте масштабы теста, чтобы нагрузка повышалась плавно, делайте нагрузочное тестирование и подключайте мониторинг с уведомлениями
1