Архитектура сервинга важна не потому, что модель нужно где-то запустить, а потому, что именно здесь качество ответа упирается в задержку, стоимость и устойчивость.
Глава разбирает онлайновый, пакетный и потоковый вывод как разные рабочие контракты с разными очередями, зависимостями и правилами деградации.
Такой взгляд помогает обсуждать маршрутизацию, резервные сценарии и автомасштабирование как часть качества продукта, а не только инфраструктуры.
Практическая польза главы
Архитектура контура
Разделить критический путь, вычислительный слой и деградацию как части одной рабочей системы.
Экономика вывода
Обсуждать пакетирование, маршрутизацию CPU/GPU и автомасштабирование через баланс задержки и стоимости.
Резервные сценарии
Заранее продумать облегчённую модель, кешированный ответ и безопасные значения по умолчанию.
Режимы вывода
Понять, когда выбирать онлайновый, пакетный или потоковый контур под разные нагрузки.
Связанная глава
Хранилище признаков и сервинг моделей
Плоскость признаков и данных часто влияет на хвостовую задержку сильнее, чем сама модель.
моделей — это место, где сталкивается с очередями, кешами, тайм-аутами и стоимостью инфраструктуры. Именно здесь ограничения по превращаются в конкретный для каждого слоя. Большинство ML- и AI-систем проигрывают не из-за слабой модели, а из-за непродуманного контура выполнения и отсутствия управляемой деградации.
Режимы вывода
Онлайн-вывод
Синхронный пользовательский путь, где каждая миллисекунда влияет на восприятие продукта, поэтому режимы деградации должны быть готовы заранее.
Пакетный вывод
Массовый пересчёт оценок, догрузка пропущенных данных и ночные обновления. Главные риски здесь — накопление очереди, устаревшие результаты и конкуренция за общие ресурсы.
Потоковый вывод
Оценка событий по мере их поступления почти в реальном времени. Такой режим даёт более свежие результаты, но резко усложняет работу с состоянием, порядком событий и перегрузкой потока.
Архитектура контура вывода по слоям
Диаграмма показывает рабочий контур вывода по слоям: от входа трафика и маршрутизации до выполнения модели, формирования ответа и режимов деградации.
Что держать под контролем
Контур вывода полезно смотреть не только как цепочку сервисов, но и как баланс задержки, стоимости и устойчивости на каждом слое.
Бюджет задержек
Экономика вывода
Устойчивость
Как проходит запрос в контуре вывода
Ниже сравниваются два укрупнённых пути выполнения: онлайновый путь, чувствительный к задержке, и пакетно-потоковый контур для массовой или событийной обработки.
Как запрос проходит через контур вывода
Сравнение онлайн-пути и пакетно-потокового контура
Активный шаг
1. Приём и маршрутизация
Шлюз или маршрутизатор принимает запрос, проверяет правила арендатора и решает, можно ли пустить его дальше.
Путь, чувствительный к задержке
- Онлайн-путь жёстко ограничен задержкой.
- Критичны хвостовая задержка и запасной сценарий.
- Любая медленная зависимость сразу бьёт по UX.
Декомпозиция бюджета задержек
Маршрутизация запроса
5-15 ms
, правила арендаторов и выбор маршрута должны занимать заметно меньше времени, чем сам путь вывода.
Получение признаков и контекста
20-60 ms
Именно здесь обычно прячется : промахи кеша, медленное и лишние внешние обращения.
Выполнение модели
30-90 ms
Выбор CPU или GPU, окно и размер модели определяют , хвостовую задержку и общий контур затрат.
Постобработка
10-30 ms
Проверки, применение порогов, форматирование ответа, цитаты и продуктовые фильтры тоже живут на критическом пути.
Политика выполнения
Маршрутизация CPU/GPU
Тяжёлые модели и пути с высокой пропускной способностью часто выгоднее держать на GPU, но короткие всплески запросов нередко лучше обслуживать на CPU или облегчённой моделью.
Окна пакетирования
Пакетирование снижает стоимость одного запроса, но почти всегда ухудшает хвостовую задержку. Поэтому нужен жёсткий максимум ожидания и отдельные правила для разных классов трафика.
Контроль допуска
Очередь должна заранее ограничивать или сбрасывать низкоприоритетный трафик, прежде чем весь контур начнёт задыхаться под общей нагрузкой.
Прогретые пулы и автомасштабирование
Если тяжёлый контур прогревается слишком долго, без заранее подготовленной тёплой ёмкости даст красивый график и плохой пользовательский опыт.
Режимы деградации
- Кешированный ответ или недавняя оценка для путей чтения, чувствительных к задержке.
- Упрощённый набор признаков, если деградирует хранилище признаков или одна из внешних зависимостей.
- Облегчённая модель вместо основного тяжёлого GPU-контура.
- Заранее определённый с , если ни один путь вывода не подтвердился вовремя.
Метрики экономической эффективности
- стоимость 1 000 запросов или одной успешно решённой задачи
- загрузка GPU и эффективность пакетирования
- доля трафика на облегчённой модели и частота перехода в резервный сценарий
- время ожидания в очереди, тайм-ауты и процент отклонённых запросов
Ключевые компромиссы
- Ставка на GPU повышает пропускную способность, но делает планирование ёмкости и прогнозирование затрат сложнее.
- Большое окно пакетирования удешевляет вывод, но почти всегда ухудшает p99 и интерактивный пользовательский сценарий.
- Агрессивное кеширование помогает переживать пики, но повышает риск устаревшего ответа и может скрыть деградацию основного пути.
- Единый стек сервинга уменьшает дублирование, но увеличивает радиус поражения между разными моделями и поверхностями продукта.
Частые ошибки
Рекомендации
Связанные главы
- Хранилище признаков и сервинг моделей - Глава про плоскость признаков и согласованность офлайн- и онлайн-контуров, от которых часто зависит основная хвостовая задержка.
- Выпуск моделей, калибровка и контуры экспериментов - Как поэтапный запуск меняет не только веса модели, но и конфигурацию сервинга, маршрутизацию и рабочий бюджет задержек.
- История появления Google TPU и их эволюции - Почему экономика ускорителей и выбор железа напрямую влияют на архитектуру сервинга.
- ML Ops Pipeline - Как контур вывода встраивается в более широкий жизненный цикл модели, мониторинг и переобучение.