ML Inference в production — final

1.

ML INFERENCE В
PRODUCTION
KARPOV.COURSES

2.

НА ТЕСТЕ — 200 МС. А В ПРОДЕ — 8
СЕКУНД?
На локальном тесте модель отвечала за 200 миллисекунд.
Что случилось между тестом и
Вы задеплоили её в production — и через час в чат пишут:
продакшеном? Разберём весь путь
«почему бот отвечает 8 секунд?» GPU не сломался.
запроса — от пользователя до GPU и
Модель та же самая — изменилось только количество
обратно — и вы научитесь чинить это
одновременных запросов.
сами.

3.

ПЛАН УРОКА
От модели к inference
Деплой модели
Как запрос проходит через систему
Нагрузка и мониторинг
Latency и throughput
Типичные ошибки
Runtime и batching
Autoscaling

4.

МОДЕЛЬ РАБОТАЕТ. А PRODUCTION?
Локально модель может отлично отвечать на запросы
Поэтому недостаточно просто
одного пользователя. Но в production появляются десятки
запустить модель. Нужно понимать,
и сотни одновременных запросов, требования к SLA и
сколько времени занимает запрос,
ограничения по стоимости инфраструктуры.
сколько запросов система
выдерживает одновременно и как она
ведёт себя при изменении нагрузки.

5.

ОТ МОДЕЛИ К PRODUCTION-СЕРВИСУ
1
Модель
2
Runtime
3
Inference
Обученная модель
Среда запуска
API для запросов
4
Scaling
Работа под нагрузкой

6.

PRODUCTION-СЕРВИС — ЭТО КУХНЯ
РЕСТОРАНА
Обучение модели — это как один раз обучить шеф-повара
Дальше в видео мы будем
новому рецепту: долго, дорого, зато один раз. Inference —
сравнивать production-сервис с
это линия поваров, которые потом готовят это блюдо на
кухней ресторана. Это поможет
каждый заказ за секунды. API — это стойка приёма
держать в голове, зачем нужна
заказов, а load balancer — хостес, которая распределяет
каждая часть системы — от load
заказы между свободными поварами.
balancer до GPU.

7.

ГДЕ ЗАКАНЧИВАЕТСЯ МОДЕЛЬ И
НАЧИНАЕТСЯ СЕРВИС
1/
Модель
4/
Inference-сервис
Веса и логика, необходимые для получения
Инфраструктура, которая принимает запросы,
результата
запускает модель и возвращает результат
Модель → Runtime → API → Пользователь

8.

КАК ЗАПРОС ПОПАДАЕТ В
МОДЕЛЬ

9.

ИЗ ЧЕГО СКЛАДЫВАЕТСЯ LATENCY
На каждом шаге к latency добавляются свои миллисекунды. А если реплик не хватает — сверху добавляются ещё время на
масштабирование и cold start новой реплики.

10.

ДВЕ ГЛАВНЫЕ МЕТРИКИ
1/ Latency
Вопрос на подумать:
Если кухня начнёт готовить сразу 10 заказов на одной сковородке
— время ожидания для первого гостя вырастет или упадёт? А что
2/ Throughput
3/ Баланс
будет с throughput всей кухни?

11.

ЧТО ВЛИЯЕТ НА ПРОИЗВОДИТЕЛЬНОСТЬ
1
MODEL
2
RUNTIME
3
BATCHING
Размер и архитектура модели
Среда исполнения
Как объединяются запросы
4
HARDWARE
5
SCALING
Какие ресурсы доступны
Сколько реплик модели
работает

12.

RUNTIME: ОДНА МОДЕЛЬ — РАЗНАЯ
ПРОИЗВОДИТЕЛЬНОСТЬ
ПОЧЕМУ СПОСОБ ЗАПУСКА ИМЕЕТ ЗНАЧЕНИЕ
vLLM — continuous batching и PagedAttention: эффективно использует память GPU, хорошо держит высокую нагрузку
SGLang — своя оптимизация под сложные сценарии (structured output, много обращений к модели подряд), быстрее там, где
vLLM не заточен
Ollama — проще всего развернуть, но рассчитан на единичные запросы, а не production-нагрузку
Рецепт (модель) один и тот же — техника готовки разная. Можно совмещать разные уровни оптимизации.

13.

BATCHING
1/
Один запрос — один запуск вычислений
2/
Больше throughput, но потенциально выше
latency
2/
Несколько запросов → один batch →
параллельная обработка
Static batching
Dynamic batching

14.

МАСШТАБИРОВАНИЕ

15.

КАК РАБОТАЕТ AUTOSCALING
Метрика — это загрузка GPU или длина очереди запросов на реплику

16.

COLD START

17.

ПРАКТИКА

18.

Тут будет screencast-1
Обзор возможностей платформы
Открыть ML Inference.
Показать список inference..
Открыть создание нового inference.
Выбрать модель из Hugging Face.
Показать параметры runtime.
Выбрать GPU.
Настроить replicas/scaling.
Запустить.

19.

ПРОВЕРЯЕМ LATENCY

20.

Тут будет screencast-2
Public URL
OpenAPI
Chatbox
Запрос
Latency
Несколько запросов
Рост latency

21.

LATENCY ПОД НАГРУЗКОЙ

22.

ВКЛЮЧАЕМ AUTOSCALING

23.

Тут будет screencast-3
Настройки autoscaling.
Min replicas.
Max replicas.
Метрику масштабирования.
Генерацию нагрузки.
Рост количества реплик.
Распределение запросов.
Изменение latency.

24.

СРАВНЕНИЕ ГРАФИКОВ

25.

МАСШТАБИРОВАНИЕ НЕ ВСЕГДА ДАЕТ
МГНОВЕННЫЙ ЭФФЕКТ
Дополнительные реплики не гарантируют снижение
latency при любой нагрузке.
При высокой concurrency:
1 → 32
нагрузка становится достаточно большой, чтобы дополнительные реплики начали реально
использоваться.
Low load → масштабирование почти не помогает
High load → масштабирование повышает capacity

26.

TRADEOFF: LATENCY, THROUGHPUT И
CAPACITY
Одна реплика
Три реплики
При росте concurrency:
Мы увеличиваем доступную
Throughput ↑
вычислительную capacity.
Latency ↑
При высокой нагрузке:
TTFT ↑
Throughput ↑
Latency ↓
Система постепенно упирается в
TTFT ↓
свою вычислительную capacity.
Horizontal scaling позволяет перенести точку насыщения системы вправо.
То есть мы можем обслуживать больше одновременных запросов, прежде чем latency
начнёт резко расти.

27.

ЧТО СМОТРЕТЬ В МОНИТОРИНГЕ
1
LATENCY
2
GPU UTILIZATION
Как быстро система отвечает на
Насколько эффективно используется
запросы прямо сейчас
вычислительный ресурс
3
REPLICAS
Сколько экземпляров модели
работает сейчас

28.

Тут будет screencast-4
Dashboard
Latency
GPU
Replicas
Logs

29.

ЧТО ЗАБИРАЕМ С СОБОЙ
Модель → production-сервис
Помните бота, который начал отвечать за 8 секунд?
Теперь вы знаете: скорее всего, не хватало реплик под
Latency и throughput нужно рассматривать вместе
Autoscaling помогает адаптироваться к нагрузке
Cold start нужно учитывать заранее
Мониторинг показывает реальное состояние сервиса
нагрузкой или batching был настроен неоптимально — и
вы умеете это чинить.

30.

СПАСИБО
ЗА ПРОСМОТР
Кирилл Веловатый
KARPOV.COURSES