Пакет описывает совместно обрабатываемые запросы, а continuous batching — правила изменения его состава во времени. Один и тот же предел числа запросов ещё не задаёт правило допуска и расход KV-кэша.
Практический смысл
Почему это важно
Ответы имеют разную длину. Ожидание самого длинного запроса перед заменой всего пакета оставляет возможности 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, планировщика и оборудования.
Граница применимости: Граница переноса двух исследовательских результатов на текущую поставку; совместимость устанавливается по её документации и испытанию.
Граница терминов
Не путать
Непрерывное пакетирование меняет расписание, TTFT измеряет ожидание начала ответа в заданной точке наблюдения. Более полный пакет не доказывает меньший клиентский TTFT при той же входной нагрузке.
Перед спецификацией
Что проверить
- Зафиксируйте точную версию движка и способ изменения состава пакета между шагами.
- Задайте распределение входных и выходных длин, включая смесь коротких и длинных ответов.
- Проверьте отдельные ограничения числа активных запросов, токенов и KV-памяти.
- Измерьте паузы decode, когда в очередь приходят длинные входы prefill.
- Проследите освобождение KV после обычного завершения, отмены и ошибки запроса.
- Сравнивайте tokens/s вместе с TTFT, ITL, ошибками и длиной очереди под одной нагрузкой.
- Не записывайте поддержку chunked prefill или prefix sharing по одному названию планировщика.
Открытые основания
Первоисточники
Orca: A Distributed Serving System for Transformer-Based Generative Models
USENIX · USENIX OSDI 2022, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Iteration-level scheduling и selective batching; результат статьи не переносится на любой движок.
Открыть первоисточникEfficient Memory Management for Large Language Model Serving with PagedAttention
Woosuk Kwon и соавторы · arXiv:2309.06180, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен.
Открыть первоисточникService Level Objectives
Google Site Reliability Engineering · Site Reliability Engineering, Chapter 4
Определяет SLI, SLO и SLA и объясняет user-centric latency, error rate, throughput и percentiles.
Открыть первоисточникvLLM online serving benchmark: benchmark_serving.py
vLLM Project · репозиторий vLLM, тег v0.5.4, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Клиентские метрики; точные timestamps, chunks и знаменатели проверить в этой версии и её request adapter.
Открыть первоисточник