КабинетПоиск
Системный дизайн ML-сервисов

Requirements and SLA

Требования и SLA

актуальноТекущий рабочий стандарт

Направления: Инженерия ИИ · Системный дизайн ML

Числа, которые нужно зафиксировать до архитектуры: , пропускная способность, доступность, стоимость запроса.

Ключевые тезисы

  • Задержку измеряют перцентилями: p50 обманчиво, отвечают за p95 и p99.
  • Требование «ответ за 50 мс» отсекает половину архитектур ещё до выбора модели.
  • Доступность 99.9% — это 43 минуты простоя в месяц; закладывайте деградацию, а не отказ.

Какую задачу решает

Проектирование ML-системы начинается не с модели, а с чисел: сколько запросов в секунду, какая допустимая на 99-м перцентиле, какая доступность, какой бюджет. Эти четыре величины определяют почти все дальнейшие решения — от выбора модели до архитектуры .

Порядок здесь принципиален. Если сначала обучить лучшую модель, а потом выяснить, что она не укладывается в 50 миллисекунд, работу придётся переделывать. Требования, зафиксированные до разработки, сужают пространство решений и часто сразу отсекают целые классы моделей — и это экономия, а не ограничение.

Как раскладывается бюджет задержки

: 200 мс на p99 для поиска с переранжированием. Раскладка: сеть и балансировщик 20 мс, получение 30 мс, кандидатогенерация 40 мс, модели 80 мс, постобработка и сериализация 30 мс. Отсюда сразу видно: на модель есть 80 мс, и это исключает большой cross-encoder по 100 кандидатам, но допускает его по 20. Такая раскладка, сделанная до разработки, экономит недели: она заранее говорит, какую модель имеет смысл обучать.

Подробный разбор

2 подтемы — объяснения, формулы, примеры и интерактивные графики.

ТребованиеКак формулируетсяЧто меняет
p99 < 100 мсархитектуру и размер модели
Пропускная способность2 000 RPS в пикечисло реплик и
Доступность99.9%резервирование и фолбэк
Стоимость≤ 0.02 ₽ за запросжелезо и
Свежесть данных не старше 5 минутстриминг или
На практике

Требование к p99, а не к среднему: пользователь замечает именно долгие ответы. Хвост задержек почти всегда тяжёлый, поэтому среднее выглядит обманчиво хорошо.

  • Сеть и балансировщик: 5–15 мс.
  • Получение из онлайн-хранилища: 5–20 мс.
  • модели: то, что осталось.
  • Сериализация и логирование: 2–5 мс.

Часто выясняется, что на саму модель остаётся 30 мс — и это сразу отсекает тяжёлые . Такой расчёт нужно делать до обучения, а не после.

Где применяется

  • Начало проектаРазговор, который определяет всё остальное.
  • Выбор модели в 20 мс отсекает большие до начала экспериментов.
  • Пиковая нагрузка задаёт число реплик и тип железа.
  • ПриёмкаКритерий готовности, зафиксированный заранее, а не подогнанный под результат.

Плюсы, минусы и альтернативы

Плюсы

  • Отсекает заведомо нереализуемые решения до вложения времени.
  • Даёт объективный критерий готовности.
  • Переводит разговор с заказчиком в измеримые величины.
  • Бюджет показывает, где именно оптимизировать.

Минусы

  • Требования часто неизвестны заказчику, и их приходится выводить вместе.
  • Слишком жёсткие требования на старте могут отсечь хорошие решения.
  • Требования меняются, и систему приходится пересматривать.

Брать, если

  • Перед проектированием любой системы, работающей в реальном времени.
  • При выборе между моделями разной стоимости.

Не брать, если

  • Исследовательская стадия, где вопрос стоит «решается ли задача в принципе».

Чем заменяют

Serving ArchitectureактуальноАрхитектура инференса · Системный дизайн ML-сервисовТребования зафиксированы — следующий шаг архитектура .Cost ModelактуальноЭкономика сервиса · Системный дизайн ML-сервисовОсновное ограничение экономическое, а не техническое.
Тема также относится к главам:Практика MLПродакшен

Видеолекции

Тайм-кода именно на эту тему в записях нет. Но глава «Системный дизайн ML-сервисов» разобрана в курсах целиком — с той оговоркой, что место в записи придётся искать самому.

Курс: Системный дизайн ML7 записейКурс: Прикладной MLOps11 записей

Связанные темы

Инференс и эксплуатация

Serving Architecture85%

Архитектура инференса · Системный дизайн ML-сервисов

Модель внутри приложения, отдельный сервис или платформа инференса — три уровня связанности.

Caching85%

Кеширование · Системный дизайн ML-сервисов

Не считать то, что уже посчитано: кеш предсказаний, признаков и эмбеддингов.

Batching and Queues85%

Батчинг и очереди · Системный дизайн ML-сервисов

Собирать запросы в пачки, чтобы загрузить GPU, и сглаживать всплески нагрузки очередью.

Scaling85%

Масштабирование · Системный дизайн ML-сервисов

Горизонтальное и вертикальное масштабирование инференса и правильные метрики автоскейлинга.

GPU Inference85%

GPU-инференс · Системный дизайн ML-сервисов

Как выжать из видеокарты пропускную способность и не переплачивать.

Reliability85%

Отказоустойчивость · Системный дизайн ML-сервисов

Что происходит, когда модель недоступна, отвечает медленно или выдаёт мусор.

Observability85%

Наблюдаемость · Системный дизайн ML-сервисов

Логи, метрики и трассировки, по которым можно восстановить, что произошло с конкретным запросом.

Cost Model85%

Экономика сервиса · Системный дизайн ML-сервисов

Стоимость одного предсказания и точка, где модель перестаёт окупаться.

LLM Serving85%

Обслуживание LLM · Системный дизайн ML-сервисов

Отдельная инженерная дисциплина: KV-кеш, непрерывный батчинг, потоковая отдача и контроль стоимости.

Model Deployment85%

Деплой моделей · MLOps

Доставка модели пользователю: онлайн-сервис, батч-скоринг или встраивание в приложение.

Monitoring85%

Мониторинг · MLOps

Наблюдение за инфраструктурой, данными и качеством предсказаний после релиза.

Docker85%

Docker · MLOps

Контейнеризация фиксирует окружение целиком: код, зависимости, системные библиотеки.

Kubernetes85%

Kubernetes · MLOps

Оркестрация контейнеров: масштабирование, самовосстановление, обновления без простоя.

Кому эта тема нужна

Профильная компетенция для ролей: ML Engineer, Data Engineer, MLOps-инженер.

Усиливает профиль: LLM-инженер, Продуктовый инженер, Инженер рекомендаций.

Спрашивают на собеседовании: Сбер — Промышленный ML и MLOps, Т-Банк — ML-инженерия и продакшен, МТС — Речь и разговорный ИИ, ЮMoney — Антифрод платежей, Самокат — Логистика и сроки доставки, Авиасейлс — Ранжирование предложений, 2ГИС — Геопоиск и навигация, BI.ZONE — Антифрод и защита от автоматизации, Cloud.ru — Модели как сервис.

Добавить в учебную программу
Проверить себя

Тема встречается в тестах по направлениям — ошибки приведут обратно на эту страницу.

Тест: MLOps и инженерия24Тест: Дизайн ML-систем22
Тема в работе целиком

Разбор архитектуры, где эта тема — один из кирпичей: требования, развилки, цифры и режимы отказа.

Кейс: Рекомендации за 50 мс
Следующий шагПроверить себя: MLOps и инженерияТема встречается в этом тесте 1 раз. Ошибка приведёт обратно на эту страницу — с объяснением, что именно не сошлось.Перейти →
Serving Architecture →

Глава «Системный дизайн ML-сервисов» последний раз правилась . Нашли ошибку — напишите.