Пакет описывает совместно обрабатываемые запросы, а continuous batching — правила изменения его состава во времени. Один и тот же предел числа запросов ещё не задаёт правило допуска и расход KV-кэша.
GPU, ускорители и инфраструктура LLM
Непрерывное пакетирование генерации
Определение
Непрерывное пакетирование генерации — планирование на уровне итерации: после каждого шага сервер может изменить состав обслуживаемой группы запросов. Завершённый ответ освобождает место, и следующий запрос может войти в работу, не дожидаясь самого длинного соседа.
Также ищут: Continuous batching · iteration-level batching · непрерывный batching LLM
Зачем это знать
Ответы имеют разную длину. Ожидание самого длинного запроса перед заменой всего пакета оставляет возможности GPU неиспользованными. Но более плотное расписание требует контроля KV-кэша, очереди и задержек: максимальный поток токенов сам по себе не означает удобный диалог.
Связи из словаря
Карта понятия
Непрерывное пакетирование генерации
Доказательная часть
Что подтверждено
Orca предлагает планирование на уровне итерации: после очередного шага система может изменить набор запросов для следующего шага. Планирование не обязано ждать завершения генерации у всего исходного пакета.
Граница применимости: Iteration-level scheduling в исследовательской системе Orca, OSDI 2022; точная реализация современного движка проверяется отдельно.
При планировании по итерациям короткий завершённый запрос можно удалить из активного набора и допустить другой, не ожидая самого длинного ответа. Освободившееся место используется только при наличии очереди и доступных ресурсов.
Граница применимости: Модель обслуживания Orca; допуск новых запросов остаётся решением планировщика, а не обязательством заполнить каждое место.
Лимит одновременно активных запросов не задаёт расход памяти без их длин. При одинаковом числе запросов накопленные последовательности могут занимать разный KV-кэш; допуск должен учитывать и токены, и фактическое размещение состояния.
Граница применимости: Вывод из итерационного допуска Orca и хранения KV в PagedAttention; одинаковые модель и формат кэша, разные длины активных последовательностей.
Если обработка нового длинного входа и шаги уже начатых ответов используют один GPU и общее расписание, работа prefill может задержать следующий decode. Само слово continuous не доказывает ограничение этой паузы; политику допуска и разбиения входа нужно проверить.
Граница применимости: Вывод для совместного serving без доказанного независимого ресурса prefill; chunked prefill и конкретный приоритет движка не предполагаются.
Активный запрос сохраняет состояние уже обработанного контекста между шагами. Замена состава пакета поэтому связана с выделением, освобождением и возможным совместным использованием KV-блоков; одна перестановка списка запросов не решает нехватку памяти.
Граница применимости: Вывод из Orca и PagedAttention; shared prefix и другие способы экономии учитываются только при реально включённом и проверенном механизме.
Уплотнение расписания может увеличить объём выполненной работы и одновременно ухудшить ожидание отдельного запроса. Выбирать политику пакетирования следует по одной и той же смеси длин, входной нагрузке и целям TTFT и ITL, а не только по tokens/s.
Граница применимости: Эксплуатационный вывод из результатов Orca и пользовательского SLO; универсального выигрыша по всем метрикам не заявлено.
Механизм из Orca и управление памятью из PagedAttention описывают конкретные системы и эксперименты. Их наличие в литературе не подтверждает, что выбранная версия serving-движка поддерживает ту же комбинацию модели, формата KV, планировщика и оборудования.
Граница применимости: Граница переноса двух исследовательских результатов на текущую поставку; совместимость устанавливается по её документации и испытанию.
В vLLM v0.31.0 (движок V1) при включённом chunked prefill планировщик сначала выделяет токены для decode, затем использует остаток бюджета max_num_batched_tokens для prefill. Длинный вход, не помещающийся в этот бюджет, обрабатывается частями.
Граница применимости: vLLM v0.31.0, V1, chunked prefill включён; описание политики этой версии.
Для этой политики документация vLLM связывает меньший max_num_batched_tokens с меньшей задержкой между токенами (ITL), а больший — с меньшим временем до первого токена (TTFT): в пакет помещается больше токенов prefill.
Граница применимости: vLLM v0.31.0, V1, chunked prefill включён; направление настройки, а не гарантия результата на любой нагрузке.
Граница терминов
Не путать
Непрерывное пакетирование меняет расписание, TTFT измеряет ожидание начала ответа в заданной точке наблюдения. Более полный пакет не доказывает меньший клиентский TTFT при той же входной нагрузке.
Перед спецификацией
Что проверить
- Зафиксируйте точную версию движка и способ изменения состава пакета между шагами.
- Задайте распределение входных и выходных длин, включая смесь коротких и длинных ответов.
- Проверьте отдельные ограничения числа активных запросов, токенов и KV-памяти.
- Измерьте паузы decode, когда в очередь приходят длинные входы prefill.
- Проследите освобождение KV после обычного завершения, отмены и ошибки запроса.
- Сравнивайте tokens/s вместе с TTFT, ITL, ошибками и длиной очереди под одной нагрузкой.
- Не записывайте поддержку chunked prefill или prefix sharing по одному названию планировщика.
Открытые основания
Первоисточники
- Efficient Memory Management for Large Language Model Serving with PagedAttention
Открыт редактором 7 сентября 2026 года, заголовок документа сверен.
- Service Level Objectives
Определяет SLI, SLO и SLA и объясняет user-centric latency, error rate, throughput и percentiles.
Утверждения: 06
- Optimization and Tuning — Chunked Prefill
Сверено с официальным документом на теге v0.31.0. Условия относятся к включённому chunked prefill; универсальное значение настройки не предлагается.
- vLLM online serving benchmark: benchmark_serving.py
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Клиентские метрики; точные timestamps, chunks и знаменатели проверить в этой версии и её request adapter.