Непрерывная пакетная обработка позволяет серверу vLLM принимать новый запрос, пока другие запросы всё ещё генерируют токены. Фиксированный пакет ожидает завершения всех участников, прежде чем сможет сформировать следующий пакет; при непрерывной пакетной обработке активный набор пересматривается на каждом шаге планирования. Это различие важно, когда промпты и выходные данные имеют разную длину. Короткие запросы могут присоединяться к работе GPU, не дожидаясь самого длинного ответа в предыдущей группе.
Для команды, занимающейся инференсом, полезный вопрос заключается не в том, включена ли непрерывная пакетная обработка в списке функций. Важно, повышает ли ваш фактический набор запросов число завершённых ответов в секунду, не выводя время до первого токена, время в очереди или частоту ошибок за пределы целевых показателей сервиса. В этом руководстве объясняются механизм, важные ограничения и бенчмарк, который можно запустить до выбора мощности GPU.
Как работает непрерывная пакетная обработка vLLM
В текущей архитектуре V1 vLLM планировщик на каждом шаге заполняет бюджет токенов запросами, которые выполняются и ожидают. Запрос отслеживает, сколько токенов уже вычислено; планировщик назначает работу, чтобы сократить этот разрыв. Тот же цикл обрабатывает разбитое на части предварительное заполнение, кэширование префиксов и спекулятивное декодирование. Это более точная ментальная модель, чем схема одного статического пакета, выполняющегося до завершения. Описание планировщика см. в обзоре архитектуры vLLM.
Представьте три поступающих запроса: короткий ответ в чате, промпт с длинным документом и ещё один короткий чат. При фиксированном пакете второй короткий чат может ждать границы пакета длинного запроса. При непрерывной пакетной обработке он может быть рассмотрен на последующем шаге планирования, пока первые запросы остаются активными. Приём всё ещё ограничен бюджетом токенов, лимитами последовательностей и доступным пространством KV-кэша. Непрерывная пакетная обработка не гарантирует нулевую очередь или более быстрый результат для каждого запроса.
PagedAttention решает другую часть задачи: хранение KV-кэша внимания и управление им блоками. Этот механизм помогает движку гибче использовать память, тогда как планировщик решает, какие запросы получают вычислительные ресурсы. Разделение этих ролей помогает диагностировать, вызвана ли низкая пропускная способность планированием, давлением на KV-кэш, длинными промптами или узким местом выше по цепочке. Механизм работы с памятью описан в документе о проектировании PagedAttention в vLLM.
Параметры, формирующие пакет
| Параметр | Что он ограничивает | За чем следить при его изменении |
|---|---|---|
max_num_batched_tokens |
Токены, обрабатываемые за одну итерацию планировщика | Пропускная способность, время до первого токена, межтокенная задержка и продвижение длинных промптов |
max_num_seqs |
Последовательности, обрабатываемые за одну итерацию | Выполняющиеся запросы, запас памяти и хвостовая задержка |
| Разбитое на части предварительное заполнение | Разделяет длительное предварительное заполнение между шагами планирования | Задержка для длинных промптов и влияние на запросы декодирования |
| Лимит очереди или приёма | Запросы, которым разрешено ожидать или выполняться | Время в очереди, частота отклонений и то, достигает ли перегрузка вызывающих клиентов |
| Ёмкость KV-кэша | Активный контекст, помещающийся на GPU | Вытеснение, повторные вычисления и сбои из-за нехватки памяти |
Эти настройки взаимодействуют. Увеличение бюджета токенов может повысить пропускную способность для одной нагрузки и ухудшить интерактивную задержку для другой. Увеличение числа принятых последовательностей может повысить конкурентность, но также потребляет больше KV-кэша. На результат влияют версия, архитектура модели, длины контекста и оборудование. Прочтите справочник по конфигурации планировщика, чтобы узнать поведение установленного выпуска vLLM, затем изменяйте по одному параметру за раз.
Когда KV-кэш не может вместить новую работу, vLLM может вытеснить выполняющийся запрос и позднее повторно вычислить его прогресс. Рост числа вытеснений — предупреждение о том, что простое добавление новых запросов в пакет не бесплатно. В обзоре архитектуры объясняются правила планирования и вытеснения.
Бенчмарк, соответствующий production-трафику
Не сравнивайте настройки непрерывной пакетной обработки с одним коротким промптом, отправляемым так быстро, как это позволяет клиент. Сформируйте три группы запросов на основе собственных журналов или трассировки, безопасной с точки зрения конфиденциальности:
- Короткие интерактивные чаты с краткими промптами и ответами.
- Запросы с длинным контекстом, с большими предварительными заполнениями и умеренной длиной выходных данных.
- Запросы агентов или RAG с повторяющимися префиксами, различной длиной выходных данных, отменами и всплесками.
Сохраняйте неизменными ревизию модели, токенизатор, тип GPU, версию vLLM и трассировку запросов между запусками. Изменяйте предлагаемую частоту запросов от уровня ниже ожидаемой нагрузки до точки, в которой время в очереди или ошибки становятся неприемлемыми. Официальное vllm bench serve
руководство описывает элементы управления частотой запросов и набором данных. Записывайте точную команду, конфигурацию и версию трассировки, чтобы сравнение можно было повторить.
Для каждого запуска записывайте число завершённых запросов в секунду, выходных токенов в секунду, p50 и p95 времени до первого токена, p95 межтокенной задержки, p95 сквозной задержки, время в очереди, сбои и максимальный уровень использования памяти GPU. В справочнике производственных метрик vLLM приведены метрики для выполняющихся и ожидающих запросов, а также гистограммы времени в очереди, времени до первого токена и вытеснений. Полезная оценочная таблица:
| Запуск | Предлагаемые запросы/с | Завершённые запросы/с | p95 первого токена | p95 очереди | p95 от начала до конца | Доля ошибок | Вытеснения |
|---|---|---|---|---|---|---|---|
| Базовый уровень | измерено | измерено | измерено | измерено | измерено | измерено | измерено |
| Изменение бюджета токенов | измерено | измерено | измерено | измерено | измерено | измерено | измерено |
| Изменение лимита последовательностей | измерено | измерено | измерено | измерено | измерено | измерено | измерено |
Заполните эту таблицу измерениями: не существует универсального процентного прироста, который можно перенести из другой модели или от другого провайдера. Выбирайте конфигурацию, которая обеспечивает целевые показатели задержки и надёжности при наименьшей стоимости принятого ответа, а не ту, что изолированно демонстрирует наивысшую пропускную способность в токенах.
Диагностика неудовлетворительного результата
Если непрерывная пакетная обработка кажется неэффективной, найдите ограничение, прежде чем менять очередной флаг.
Число ожидающих запросов растёт, хотя памяти GPU достаточно. Проверьте лимиты допуска, слишком малый лимит последовательностей, токенизацию на CPU и параллелизм на стороне клиента. Планировщик не может заполнить GPU запросами, которые до него не доходят.
Время до первого токена растёт на длинных промптах. В бенчмарке отделите трафик с преобладанием prefill от трафика с преобладанием decode. Проверьте настройки chunked prefill и бюджета токенов, а также сравнивайте распределение длинных промптов, а не только среднее значение.
Пропускная способность растёт, но задержка p95 ухудшается. Возможно, сервер принимает больше одновременной работы, чем допускает целевой уровень интерактивного сервиса. Ограничьте допуск, используйте тайм-аут очереди или отдельный пул обслуживания и повторите тест при той же предлагаемой нагрузке.
Растёт число вытеснений или событий нехватки памяти. Активные контексты могут не помещаться в KV-кэш GPU. Уменьшите параллелизм или лимиты контекста, выберите GPU с достаточной памятью либо пересмотрите выбор модели и точности. Не считайте вытесненный запрос бесплатным событием планирования.
Загрузка GPU низкая, даже когда запросы ожидают. Прежде чем связывать узкое место с непрерывной пакетной обработкой, проверьте CPU, сеть, хранилище, загрузку модели и темп подачи запросов клиентом. Наше руководство по развёртыванию vLLM охватывает более широкий регламент эксплуатации сервинга; эта статья посвящена поведению планировщика и измерениям.
Как выбор GPU влияет на решение
Непрерывная пакетная обработка может улучшить использование GPU, но не может заставить модель поместиться в памяти, которой у него нет. Оцените веса, KV-кэш при ожидаемом параллелизме и длине контекста, накладные расходы среды выполнения и запас безопасности. Затем проведите бенчмарк на конфигурации GPU, которую планируете арендовать. GPU на 80 ГБ и GPU с большим объёмом памяти могут демонстрировать разное поведение при допуске и вытеснении для одной и той же модели и трассы запросов.
Flatkey GPU Compute предлагает варианты аренды, включая H100 SXM, H200, B200, B300, A100 80GB и RTX 5090. Конфигурацию, регион, доступность и цену необходимо подтвердить для выбранной аренды. При сравнении вариантов подготовьте трассу бенчмарка, целевую задержку, ревизию модели и оценку памяти. Это позволяет обсуждать ёмкость с точки зрения выполненной работы, а не заявленных характеристик GPU.
Практический контрольный список для принятия решения
Прежде чем выбрать конфигурацию непрерывной пакетной обработки vLLM, ответьте на следующие вопросы:
- Соответствует ли основной сценарий трафика целевым показателям задержки p95 первого токена и от начала до конца?
- Что происходит при всплеске выше обычной частоты запросов: ограниченная очередь, отклонение или резкий скачок задержки?
- Стабильны ли вытеснения и давление на KV-кэш при предполагаемой длине контекста?
- Воспроизводим ли результат для точной ревизии модели и конфигурации GPU, которые вы планируете использовать?
- Превосходит ли стоимость принятого ответа альтернативу после учёта повторных попыток и простаивающих мощностей?
Часто задаваемые вопросы
Означает ли непрерывная пакетная обработка vLLM, что каждый запрос выполняется немедленно?
Нет. Новый запрос может быть рассмотрен на шаге планирования, но ему всё равно может потребоваться ждать бюджета токенов, слота последовательности или ёмкости KV-кэша. Прежде чем обещать целевой уровень интерактивной задержки, отслеживайте показатели выполняющихся и ожидающих запросов вместе с гистограммами времени в очереди.
Является ли непрерывная пакетная обработка vLLM тем же самым, что и chunked prefill?
Нет. Непрерывная пакетная обработка описывает, как запросы со временем входят в запланированную работу и выходят из неё. Chunked prefill разбивает работу prefill длинного промпта, чтобы она могла разделять бюджет токенов между шагами. В текущем планировщике они работают вместе, но настройка одного параметра не заменяет измерение другого.
Следует ли максимизировать размер пакета?
Не обязательно. Больший пакет может повысить пропускную способность, одновременно увеличивая время в очереди, время до первого токена или давление из-за вытеснений. Запустите ту же трассу при той же предлагаемой нагрузке и сравните все целевые показатели сервиса, включая сбои и стоимость принятого ответа.
Непрерывная пакетная обработка vLLM — это метод планирования, а не результат бенчмарка. Наилучшей является конфигурация, чью пропускную способность, задержку, поведение памяти и режим отказов вы можете объяснить собственными измерениями.
