Непрерывный батчинг LLM: как растёт пропускная способность

Непрерывный батчинг позволяет добавлять новые запросы в работу общего GPU между шагами генерации. Так ресурсы, освободившиеся после коротких задач, не простаивают в ожидании длинных. Этот подход к планированию описан в основополагающей статье об Orca, которую Yu и соавторы представили на OSDI в 2022 году. При одновременной нагрузке он может увеличить суммарное число токенов в секунду, но более загруженный сервер не обязательно отвечает быстрее каждому пользователю.

Для сервера, на котором одну модель используют несколько клиентов, практическая цель — выполнять больше работы в пределах допустимого времени ответа. График пропускной способности без ограничения по задержке не покажет, сколько клиентов сервер может обслуживать с приемлемым качеством.

Поддержка функций и настройки серверов, описанные ниже, проверены по актуальной документации разработчиков 25 октября 2026 года. Пример расписания иллюстрирует принцип работы и не является аппаратным бенчмарком.

Как работает непрерывный батчинг

При непрерывном батчинге состав активной группы меняется прямо во время генерации. Завершённый запрос покидает её, а ожидающий может занять его место, если планировщику хватает ресурсов. Этот подход также называют in-flight batching или iteration-level batching.

Большая языковая модель, или LLM, сначала обрабатывает промпт на этапе prefill, а затем генерирует продолжение на этапе decode. При обычном авторегрессионном декодировании каждый активный запрос на очередном шаге генерации выдаёт следующий токен — фрагмент текста. Планировщик определяет, какие запросы участвуют в следующем шаге. Подробнее об этих этапах — в руководстве по инференсу LLM.

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

У этой аналогии есть границы: планировщику GPU нужно также выделять ресурсы на обработку промптов и размещение данных в памяти. Свободный стул ещё не означает, что любой запрос из очереди можно принять немедленно.

Что предложили авторы Orca

В Orca единицей планирования стала итерация, а не запрос целиком. В статье Gyeong-In Yu и соавторов для OSDI 2022 описан подход, при котором движок выполняет одну итерацию модели, после чего состав батча пересматривается.

Дополняющий его метод — выборочный батчинг — объединяет в батч отдельные операции модели, учитывая при этом разную историю запросов, необходимую механизму внимания. Этот механизм связывает токен с предшествующим контекстом. Вместе два метода позволяют серверу чередовать работу над запросами разной длины. При планировании авторы также учитывают размер батча и доступную память для ключей и значений. Читать статью об Orca.

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

Статический, динамический и непрерывный батчинг: в чём разница

Главный вопрос — в какой момент новый запрос может присоединиться к уже выполняемой работе. Сам по себе приём нескольких одновременных HTTP-соединений ещё не означает, что модель выполняет запросы с непрерывным батчингом.

В документации NVIDIA по батчингу в Triton описан обычный динамический батчинг, включая настройки размера батча и задержки в очереди. Эти настройки решают другую задачу планирования, чем замена запросов в группе во время генерации LLM.

Динамический батчинг в vLLM: когда меняется состав группы

В документации движка для обслуживания LLM vLLM заявлен непрерывный батчинг. «Динамический батчинг» — менее точный термин. В объяснении непрерывного батчинга Hugging Face тоже использует названия динамическое планирование и динамический батчинг для замены завершённых запросов во время генерации. Вместо выводов по одному названию уточняйте, принимает ли движок новую работу между шагами генерации.

Потоковая передача — отдельная функция. Сервер может передавать клиенту токены по мере их появления, сохраняя фиксированный состав выполняемого батча. Здесь же речь о том, что новые запросы получают доступ к ресурсам, освободившимся после завершения предыдущих.

Пример расписания запросов

Короткая задача может освободить полезные ресурсы, пока длинная продолжает выполняться. Рассмотрим условный сервер с двумя местами для декодирования. Запросу A осталось 2 шага, B — 4, а C ждёт в очереди и требует 2 шага работы. В этом примере не учитываем prefill, накладные расходы планировщика и изменение длительности шага.

При фиксированном составе A и B начинают вместе. A завершается, но C ждёт окончания B, прежде чем сможет запуститься следующая группа. При непрерывном батчинге C может занять место A сразу после его завершения и выполняться параллельно с B.

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

Почему растёт пропускная способность и где мешает KV-кеш

Батчинг позволяет выполнить больше полезной работы при том же перемещении весов модели. Веса — это числовые параметры, которые модель усвоила при обучении и использует для расчёта ответа. Несколько запросов к одной модели могут совместно использовать передачу этих весов через память GPU, эффективнее задействуя доступные вычислительные ресурсы. Непрерывное планирование помогает сохранять полезный состав батча по мере завершения отдельных запросов. NVIDIA объясняет связь между батчингом, перемещением данных в памяти и использованием GPU.

GPU может оставаться занятым и при неэффективном батче. Важно, сколько полезной работы над запросами даёт эта активность, а не насколько заполнен график загрузки.

Но каждому активному запросу нужна и рабочая память. Его KV-кеш, то есть кеш ключей и значений, хранит состояние механизма внимания для уже обработанных токенов. Чем больше одновременных запросов и чем длиннее их история, тем выше нагрузка на эту память. В разборе KV-кеша объясняется, чем это состояние отличается от кеширования промптов для повторного использования.

Как PagedAttention помогает эффективнее использовать память

Непрерывный батчинг определяет, что выполняется, а PagedAttention — как хранится состояние механизма внимания. В статье о vLLM 2023 года Woosuk Kwon и соавторы описывают разбиение KV-состояния на блоки фиксированного размера, которые не обязаны располагаться рядом в физической памяти. Таблица соответствия блоков сохраняет логический порядок последовательности.

Так сокращаются потери памяти из-за фрагментации и лишнего дублирования. Более плотное размещение позволяет вместить рабочие данные большего числа запросов, а планировщик получает больше полезной работы на выбор. Авторы прямо указывают, что их подход к управлению памятью дополняет подход Orca к планированию.

Ограничением остаётся физический объём памяти. Более плотное размещение не позволит вместить неограниченное число длинных диалогов. В vLLM нехватка места в KV-кеше может вызвать вытеснение: запрос приостанавливается, а позже его состояние вычисляется заново. Это может увеличить время до завершения. Такое поведение описано в документации по оптимизации.

Как меняются задержки

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

• Время до первого токена, или TTFT: сколько пользователь ждёт начала ответа.
• Задержка между токенами: интервалы между токенами после начала потоковой передачи.
• Полное время ответа: сколько занимает выполнение запроса целиком.

Новому запросу не обязательно ждать, пока завершится весь фиксированный батч. Однако обработка нового большого промпта может конкурировать за ресурсы с уже декодируемыми запросами. Chunked prefill разбивает обработку промпта на небольшие части, чтобы планировщик мог чередовать её с текущей генерацией.

Например, документация vLLM описывает компромисс при выборе бюджета токенов на итерацию: меньшие значения помогают удерживать задержку между токенами, а большие позволяют обрабатывать больше prefill и улучшать TTFT. Поэтому бюджет нужно подбирать под нагрузку, а не бездумно выставлять на максимум. Рекомендации по настройке vLLM.

Непрерывный батчинг LLM при низкой и высокой нагрузке

При низкой нагрузке объединять в батчи может быть почти нечего, а при устойчивой перегрузке очередь никуда не исчезает. Разработчику, отправляющему запросы по одному, не стоит ожидать такого же выигрыша, как у клиентского сервиса с пересекающимися запросами. На другом полюсе нагрузка, превышающая возможности GPU, со временем увеличивает ожидание.

Для интерактивного приложения следите не только за медианой, но и за p95 — 95-м процентилем. Хорошее среднее значение может скрывать небольшую долю очень медленных сессий. Определите допустимые TTFT и интервалы между токенами исходя из пользовательского опыта, а затем измеряйте, какую нагрузку система выдерживает в этих пределах.

Серверы LLM с непрерывным батчингом: поддержка и ограничения

Все четыре сервера ниже документируют поддержку continuous batching или in-flight batching. Общая функция не делает взаимозаменяемыми их планировщики, бюджеты памяти и наборы поддерживаемых моделей.

Непрерывный батчинг в vLLM

vLLM сочетает непрерывное планирование запросов со страничным управлением KV-кешем. Обе функции прямо перечислены в документации. При эксплуатации стоит настраивать максимальное число последовательностей и число токенов, запланированных на итерацию, а не просто задавать желаемое количество одновременных API-соединений.

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

SGLang

SGLang поддерживает непрерывный батчинг и предоставляет явные настройки допуска запросов. В документации по аргументам сервера описаны --max-running-requests, --chunked-prefill-size и бюджет памяти для весов модели и пула KV-кеша, которым управляет --mem-fraction-static.

Эти настройки отвечают на разные вопросы: сколько запросов может выполняться, какая часть обработки промпта попадает в один фрагмент и как распределяется память. Повышение лимита запросов не снимает остальных ограничений. Для выбора движка в целом пригодится сравнение vLLM и SGLang, после чего стоит проверить конкретную модель и сочетание запросов, с которыми предстоит работать.

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM прямо указывает, что in-flight batching, continuous batching и iteration-level batching — названия одного подхода. В документации этой функции описана совместная обработка последовательностей на этапе обработки контекста и на этапе генерации; в описанной реализации используются упакованные входные тензоры.

Лимит запросов и бюджет токенов — разные ограничения. В документации планировщика PyTorch также разделены резервирование ресурсов, включая ёмкость KV-кеша, и выбор выполняемых запросов из тех, для которых ресурсов достаточно. Планировщик in-flight batching не может принять работу, которая не проходит эти проверки.

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference поддерживает непрерывный батчинг, но переход в режим сопровождения меняет выбор для нового развёртывания. Согласно документации, проект теперь принимает небольшие исправления, улучшения документации и небольшие изменения по сопровождению, а для дальнейшего использования рекомендует другие движки, в том числе vLLM и SGLang.

Уже работающая установка TGI не теряет батчинг из-за этого статуса. Для нового стека обслуживания моделей я бы начал оценку с активно развиваемых альтернатив. Если существующее развёртывание выполняет поставленные задачи, планируйте миграцию под конкретную потребность в поддержке или функциональности.

Какие ожидания завышены

Непрерывный батчинг не даёт универсального коэффициента ускорения. В статьях об Orca и PagedAttention оценивались конкретные системы и нагрузки. Эти результаты не выделяют универсальный выигрыш, который можно перенести на произвольную модель, GPU или API провайдера.

Ожидание тоже не исчезает. Запросу в очереди по-прежнему нужны обработка промпта, память и очередь на выполнение по правилам планировщика. Длинные промпты, высокая одновременная нагрузка и нехватка места в кеше остаются ограничениями.

Наконец, более высокая суммарная скорость выдачи токенов ещё не доказывает, что чат-продукт стал лучше. Если пользователи дольше ждут первого токена или сталкиваются с заметными паузами в потоке ответа, дополнительная пропускная способность может достигаться за пределами допустимого для продукта режима работы.

Что изменить в работе уже в понедельник

Разработчикам стоит оценить обслуживание нескольких клиентов на общем сервере, если запросы пересекаются; эксплуатационным командам — настраивать его в пределах допустимых задержек; тем, кто выбирает провайдера, — запрашивать замеры при конкуренции за ресурсы. Инструмент для одного пользователя с редкими запросами может подождать. У сервиса с очередью клиентов и ответами разной длины уже есть конкретная причина действовать. Переход от локального использования к общему серверу разобран в сравнении Ollama и vLLM.

1. 1

   Определите требования к отклику до увеличения числа одновременных запросов

   Зафиксируйте допустимые время до первого токена, интервалы между токенами и полное время ответа для реального рабочего сценария. Фоновому инструменту подготовки сводок и ассистенту поддержки в реальном времени нужны разные пределы допустимых задержек.

2. 2

   Воспроизведите характерное сочетание запросов

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

3. 3

   Измеряйте пропускную способность вместе с очередью и задержками

   Измеряйте суммарное число выходных токенов в секунду, число завершённых и ожидающих запросов, сбои, TTFT и интервалы между токенами. vLLM предоставляет соответствующие метрики, включая vllm:num_requests_waiting, vllm:time_to_first_token_seconds и vllm:inter_token_latency_seconds; они описаны в документации по эксплуатационным метрикам.

4. 4

   Выберите максимальную нагрузку, при которой соблюдаются требования

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

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

Чтобы получать практические разборы инфраструктуры ИИ и советы о том, что менять в своём стеке, подпишитесь на рассылку.