Batching в инференсе: пропускная способность и очередь

Batching объединяет часть работы нескольких запросов, чтобы эффективнее использовать вычисления. Для пакетной обработки это естественный режим. Для живого чата настройка требует баланса: рост суммарной производительности может сопровождаться более длинным ожиданием отдельного пользователя.

Статическая и непрерывная обработка

В простом статическом batch группа обрабатывается как набор. При разной длине запросов часть работы может завершиться раньше другой. Continuous batching позволяет управлять активными последовательностями по мере выполнения. Архитектура такого планирования и paged cache описана в документации Transformers. 1

Это объясняет механизм, но не гарантирует ускорение конкретного приложения. Важны распределение длин, размер модели, память и политика планировщика. Для коротких редких запросов эффект может отличаться от плотного потока длинных задач.

Выберите целевую метрику

Для ночной обработки цель может звучать как «закончить очередь до 7:00». Для ассистента: «показать первый токен в установленное время». Для публичного API: «обработать заданный поток с допустимым p95 и долей ошибок». Одна настройка не обязана быть лучшей во всех трёх случаях.

Разделяйте входные и выходные токены. Длинный вход создаёт другой профиль вычислений, чем длинный ответ. Не оценивайте очередь только числом запросов: десять коротких вопросов и десять больших документов могут сильно различаться по работе.

Нагрузка	Что ограничивать	Что наблюдать
Интерактивный чат	Активные последовательности и длину	Первый токен и очередь
Пакетная обработка	Память и общий объём	Время завершения и ошибки
Смешанный сервис	Приоритеты и квоты	Влияние фоновых задач на чат

Постройте кривую нагрузки

Начните с малого потока и постепенно увеличивайте его. Для каждой ступени сохраните суммарную скорость, p50 и p95 задержек, очередь, память и ошибки. Продолжайте достаточно долго, чтобы увидеть устойчивое состояние, а не короткий всплеск после прогрева.

Обычно для принятия решения важна точка, после которой очередь перестаёт успевать очищаться. Максимальная кратковременная скорость до этой точки не равна безопасной рабочей нагрузке. Оставьте запас, соответствующий реальным колебаниям потока.

Память ограничивает параллельность

Каждая активная последовательность хранит своё состояние. Увеличение лимита может привести к нехватке cache и изменению поведения планировщика. Поэтому настройка batching связана с расчётом VRAM.

Не выбирайте предел по числу сотрудников компании. Используйте измеренную активность и разрешённые размеры запросов. Отдельно проверьте несколько длинных запросов одновременно: средний профиль может скрывать такой пик.

Защитите сервис от неконтролируемой очереди

У приложения должны быть лимиты, таймауты и понятная реакция на перегрузку. Если очередь бесконечна, пользователь может ждать дольше допустимого, а повторные отправки только увеличат нагрузку. Полезно возвращать явный статус и делать повторные операции идемпотентными там, где это возможно.

Наблюдайте отмену запросов: прекращается ли работа, когда клиент закрыл соединение, или генерация продолжается без пользы? Для платного API такой сценарий влияет на себестоимость, а для внутреннего сервиса расходует общий ресурс.

Что закрепить после настройки

Сохраните версии ПО, параметры лимитов и профиль теста. В vLLM есть метрики очереди и задержек, позволяющие наблюдать поведение системы после запуска. 2 Конкретные названия метрик проверяются для используемой версии.

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