High-Load Serving Patterns

Нагруженная выдача модели: когда модель стала сервисом

В ноутбуке модель выглядит просто: вызвал функцию, получил ответ. В продукте всё сложнее: запросы приходят неравномерно, пользователи не хотят ждать, GPU дорогие, часть запросов длиннее других, а при перегрузе сервис не должен развалиться. Поэтому выдача модели как сервиса - это не только “ускорить модель”, а правильно организовать очередь, маршрутизацию, приоритеты, батчинг, отмену запросов и безопасное обновление версий модели.

Главная идея блока: хороший ML-сервис оптимизируют не под одну красивую цифру, а под баланс. Можно сильнее загрузить GPU, но ухудшить ожидание пользователя. Можно объединять больше запросов в батч, но увеличить задержку. Можно включить повторы при ошибках, но создать вторую волну нагрузки. Поэтому сначала спрашиваем: кому отвечаем, за какое время, сколько стоит ошибка и что делаем, если система перегружена.

Задержка: важен хвост, а не только среднее

Среднее время ответа часто обманывает. Представь, что 90 запросов отвечают за 100 мс, а 10 запросов ждут по 5 секунд. Среднее ещё может выглядеть терпимо, но реальные пользователи регулярно видят зависания и таймауты. Поэтому в нагруженных сервисах смотрят не только среднее, но и “хвосты” распределения: p95 и p99, то есть насколько медленны самые неприятные 5% или 1% запросов.

Как живёт один запрос

Запрос обычно не идёт сразу в модель. Сначала входной слой принимает запрос и проверяет лимиты. Потом маршрутизатор решает, на какую модель или копию модели отправить работу. Очередь временно хранит запросы. Планировщик решает, какие запросы объединить в батч и какой машине отдать. Исполнитель держит модель в памяти и считает ответ. Для LLM или генеративных задач результат может идти постепенно: токен за токеном или превью за превью. Если пользователь ушёл или дедлайн истёк, запрос надо уметь отменить, иначе GPU продолжит делать бесполезную работу.

• Admission control, или входной лимит. Если система уже перегружена, лучше честно отказать, дать упрощённый ответ или попросить повторить позже, чем принять всё и уронить p99 всем пользователям.
• Очередь. Очередь полезна только пока ожидание меньше пользовательского дедлайна. После этого она превращается в фабрику таймаутов.
• Планировщик. Короткие интерактивные запросы, длинные фоновые задачи и платящие пользователи не должны бесконтрольно конкурировать за одну и ту же GPU.
• Потоковая выдача. Для LLM первый токен часто важнее полного времени до конца ответа: пользователь видит, что система начала работать.
• Отмена. Если пользователь закрыл страницу, нужно освобождать место в очереди, память под контекст и слот в батче.

Батчинг: полезный, но опасный компромисс

Батчинг означает: не считать каждый запрос отдельно, а объединять несколько запросов и прогонять их вместе. Это часто лучше загружает GPU. Но батч не бесплатный: иногда надо ждать, пока батч соберётся; запросы внутри батча могут быть разной длины; длинная генерация может задержать короткую. Поэтому батчинг почти всегда меняет баланс между “дёшево и много” и “быстро для конкретного пользователя”.

Что делать при перегрузе

Перегруз должен быть заранее продуманным сценарием, а не пожаром. Хороший сервис знает, кого обслуживать первым, где ограничивать очередь, когда включать более дешёвую модель, когда возвращать ответ из кеша, когда переводить задачу в фоновый режим и когда честно отказать. Важно не только добавить машины, а не дать системе самой усилить проблему.

• Обратное давление. Верхний слой должен понимать, что нижний слой занят. Иначе запросы будут бесконечно копиться.
• Приоритеты. Интерактивный пользователь, платный пользователь и ночная фоновая обработка не должны иметь одинаковое право на ресурс.
• Мягкая деградация. Можно временно взять меньшую модель, сократить контекст, снизить разрешение, вернуть кешированный ответ или поставить задачу в фон.
• Масштабирование. Сигналом должны быть не только CPU/GPU, но и очередь, хвосты задержки, таймауты и время прогрева новых копий модели.
• Безопасная выкатка. Новая версия модели или новая настройка батчинга может улучшить среднюю скорость, но ухудшить p99. Поэтому нужны canary-проверка на малой доле трафика, сравнение метрик и быстрый откат.

Кейс Meta простыми словами: проблема была не только в модели

Полезный пример - Meta Engineering post про ads inference. В рекламной системе один пользовательский запрос может запускать много обращений к разным моделям. Модели часто обновляются, копии моделей разложены по множеству машин, железо неоднородное, а ответ нужен быстро. Проблема была не в том, что “одна модель медленная”. Проблема была в том, что нагрузка распределялась неровно: часть машин или копий моделей становилась перегруженной, и именно они портили хвосты задержки.

Что они делали по сути: лучше решали, куда отправить запрос; лучше размещали копии моделей по машинам; считали нагрузку не только на сервер в целом, но и на конкретную модель; учитывали пропускную способность памяти как отдельный ресурс; аккуратнее переводили трафик между версиями моделей; заранее оценивали, сколько копий модели понадобится при будущем трафике. По их отчёту это позволило обслуживать больше работы теми же ресурсами, снизить таймауты и улучшить p99. Но главный урок не в процентах, а в логике: узкое место было в распределении нагрузки, обновлении моделей и модели ресурсов, а не только в скорости отдельных ядер вычисления или среды исполнения.

Как это обсуждать на собеседовании

На собеседовании по нагруженному ML-сервиса обычно проверяют не знание всех фреймворков, а умение рассуждать под ограничениями. Хороший ответ начинается с уточнений: это интерактивный продукт или фоновая обработка? Как быстро пользователь ждёт ответ? Что хуже: таймаут, устаревший ответ, дорогой запасной режим или немного худшее качество? Есть ли платные пользователи? Бывают ли пики нагрузки? Разные ли модели делят одну и ту же GPU?

• “Как обслужить долгую генерацию?” Сделай задачу асинхронной: статус задачи, очередь с лимитом, частичное превью, отмена, таймаут, повтор только по правилам и запасной режим.
• “Почему батчинг ухудшил UX?” Запросы начали ждать сбор батча, короткие ответы оказались за длинными, p99 вырос, а средняя пропускная способность при этом могла улучшиться.
• “GPU недогружена, но очередь растёт. Что проверять?” Передачу данных, CPU-предобработку, планировщик, размер батча, пропускную способность памяти, прогрев worker-ов, загрузку модели, блокировки и давление на downstream-сервисы.
• “Как приоритизировать платных пользователей?” Разделить очереди и квоты, зарезервировать часть ёмкости, задать отдельные SLO и заранее описать поведение при перегрузе.
• “Какие дашборды нужны?” Очередь, p50/p95/p99, таймауты и отмены, запросы или токены в секунду, память и загрузка GPU, размеры батчей, цена запроса и сигналы регресса качества.