Расширенный поиск
Гайды / Руководства / AI и смарт-контракты
18-11-2025, 18:34

vLLM для высоконагруженного сервинга LLM: PagedAttention, continuous batching и снижение p95 latency

Когда LLM переезжают из ноутбука в прод, внезапно выясняется, что «модель работает» и «модель отбивает счёт за GPU» — это разные вещи. Нужен движок, который умеет держать высокую нагрузку, не падать по памяти и не раздувать latency p95. Одно из де-факто решений на сегодня — vLLM с его PagedAttention, continuous batching и гибким управлением KV-кэшем.

В этом гайде разберём, как строить продовый сервинг на vLLM: что делает движок «особенным», как работать с KV-кэшем, как влияют настройки top-k / top-p / temperature на стоимость и скорость, и какие метрики по latency p95 действительно важно мониторить. За базовой теорией и экономикой LLM можно дополнительно посмотреть в наш вики-гайд «Оптимизация стоимости LLM-нагрузок».

1. Что такое vLLM и зачем он нужен поверх «обычного» сервинга

vLLM — это open-source движок для высокопроизводительного сервинга LLM, построенный вокруг идеи PagedAttention и непрерывного батчинга запросов. Его цели:

  • минимизировать потери памяти на KV-кэш за счёт страничной модели (paged memory);
  • максимально загружать GPU через continuous batching — даже при тысячах мелких запросов;
  • дать гибкий API (включая OpenAI-compatible server), чтобы его можно было воткнуть в уже существующую инфраструктуру.

Согласно оригинальной работе по PagedAttention и vLLM, такой подход позволяет:

  • почти убрать потери памяти на KV-кэше (waste < 4% против 60–80% у «наивных» схем);
  • выигрывать по throughput у предыдущих систем (FasterTransformer, Orca) в среднем в 2–4 раза при сопоставимой latency.

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

2. PagedAttention и KV-кэш: решение проблем памяти в vLLM

В современном LLM-сервинге узким местом почти всегда оказывается KV-кэш — те самые key/value-тензоры для attention, которые нужно хранить для каждого токена в каждом запросе. Контекст растёт → KV-кэш раздувается → GPU-память забита, батчи нельзя увеличивать, latency p95 ползёт вверх.

2.1. Как выглядит «наивный» KV-кэш

Традиционный подход:

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

Результат — огромное количество «дыр» в GPU-памяти и необходимость либо ограничивать длину контекста, либо задушить batch size, чтобы всё помещалось.

2.2. Идея PagedAttention

PagedAttention в vLLM относит KV-кэш к GPU примерно так же, как ОС относится к оперативной памяти: через слои «виртуальных» и физических страниц.

Основные идеи:

  • KV-кэш каждой последовательности делится на страницы фиксированного размера (blocks/pages);
  • страницы не обязаны лежать в памяти непрерывно — достаточно таблицы соответствия «логический токен → физическая страница»;
  • когда одна последовательность завершилась, её страницы можно быстро переиспользовать для другой;
  • общие префиксы запросов могут шарить одни и те же страницы KV-кэша (prefix-sharing).

Так удаётся почти полностью избавиться от внешней/внутренней фрагментации и высвободить память под более крупные батчи и длинный контекст — без переписывания attention-ядер с нуля.

3. Continuous batching и планировщик: как vLLM влияет на latency p95

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

3.1. Prefill vs decode

С точки зрения планировщика, запрос проходит несколько фаз:

  • Prefill — нужно прогнать длинный ввод (инструкции, контекст RAG, историю диалога);
  • Decode — модель порождает выходной текст токен за токеном.

Prefill загружает математику по максимуму, decode — чаще упирается в память KV-кэша. vLLM умеет различать эти фазы и за счёт этого:

  • на prefill агрессивно батчит запросы, пока есть свободные ресурсы;
  • на decode подмешивает новые запросы в «паузы» между шагами у уже идущих сессий.

3.2. Continuous batching и p95

Continuous batching даёт сильный прирост по throughput, но при неправильных настройках может ухудшать latency p95 для отдельных запросов: новые запросы будут ждать, пока батч «донаберётся» или пока GPU освободится от тяжёлого контекста.

Типичные настройки, которые приходится подбирать:

  • максимальный размер батча (по токенам, а не по количеству запросов);
  • политика ожидания: сколько миллисекунд мы готовы подождать ради более плотного батча;
  • лимиты на max_tokens для ответа, чтобы один «болтливый» запрос не залочил GPU на полминуты.

С ФинОпс-точки зрения задача простая: найти точку, где черезput высокий, а latency p95 остаётся в разумных пределах (например, < 2–3 секунд для первых токенов и < 5–7 секунд для полного ответа в чат-сценариях).

4. Оптимизация sampling параметров: top-k, top-p, temperature для производительности

На первый взгляд параметры top-k, top-p, temperature про креативность, но у них есть и системный эффект: они влияют на скорость декодирования и иногда на стабильность latency.

4.1. top-k

top-k — ограничение числа токенов-кандидатов, среди которых выбирается следующий символ.

  • Очень маленький k (1–5) → модель почти детерминированная, но иногда «зацикливается» и выдаёт менее разнообразные ответы;
  • Слишком большой k (50–100) → максимум разнообразия, но больше вычислений и потенциально больше «шума» в ответах.

С точки зрения latency/стоимости разумные значения для продового сервинга — k в диапазоне 20–40 для креативных задач и 1–5 для аналитики и строго-форматных ответов.

4.2. top-p (nucleus sampling)

top-p задаёт суммарную вероятность «ядра» распределения. Модель сортирует токены по вероятности и выбирает минимальный набор, сумма вероятностей которого ≥ p.

  • Низкий p (0.7–0.8) → ответы более «скучные», но стабильные;
  • Высокий p (0.9–0.95) → больше разнообразия, но и больше риска «галлюцинаций».

Системно top-p чуть менее критичен, чем top-k, но в проде часто используют top-p 0.8–0.95 в паре с разумным k, чтобы держать баланс.

4.3. Temperature

Temperature размывает или заостряет распределение вероятностей:

  • 0.0–0.3 — почти детерминированный режим, полезен для кода, отчётов, структурированных ответов;
  • 0.7–1.0 — креативный режим для генерации идей, текстов, вариантов формулировок.

Для latency и стоимости temperature критична меньше, чем top-k/top-p, но экстремальные значения могут приводить к длинным или «залипшим» ответам, что ухудшает p95.

5. Архитектура продакшен-сервинга на vLLM: от API до мониторинга

Теперь соберём всё в «картинку»: как обычно выглядит продовый сервинг LLM на базе vLLM.

5.1. Базовая схема

  • API-шлюз:
    • принимает HTTP/gRPC запросы от клиентов;
    • делает авторизацию, rate-limits, базовую валидацию;
    • умеет стримить ответы (Server-Sent Events / WebSocket).
  • vLLM-кластер:
    • несколько инстансов vLLM, каждый с 1–N GPU;
    • конфиг по модели, KV-кэшу, батчингу и parallelism;
    • поддержка OpenAI-совместимого API, что упрощает миграцию.
  • Векторное хранилище / RAG-слой:
    • отвечает за поиск по документам, извлечение контекста;
    • может быть отдельным сервисом на базе Qdrant/Weaviate/Pinecone (см. наш обзор Qdrant: векторная БД для RAG).
  • Мониторинг и логирование:
    • Prometheus/Grafana/верующая в метрики система;
    • сбор latency p50/p95/p99, tokens/sec, util GPU, ошибок.

5.2. Пример конфигурации vLLM

Параметр Типовое значение Комментарий
model llama-3-8b-instruct (пример) Выбор конкретной модели зависит от задач и лицензий.
max_model_len 8k–16k Больше контекст — больше KV-кэш. Для многих задач 8k достаточно.
gpu_memory_utilization 0.8–0.9 На сколько процентов заполняем VRAM под модель + KV-кэш.
max_num_batched_tokens 4k–8k Ограничивает суммарное число токенов в батче.
tensor_parallel_size 1–2 Для больших моделей — распределённый inference по нескольким GPU.
enable_chunked_prefill true Делит длинный prefill на чанки, чтобы сгладить нагрузку.

6. Проектирование под vLLM: метрики latency p95, throughput и качество сервиса

6.1. Какие метрики смотреть

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

  • Latency:
    • p50/p95/p99 по времени до первого токена (TTFT);
    • p50/p95/p99 по времени до полного ответа;
    • отдельно — время очереди (queue time) и чистое время вычислений.
  • Throughput:
    • tokens/sec на GPU и на кластер;
    • QPS по типам запросов (чат, RAG, summarization и т.д.).
  • Ресурсы:
    • utilization GPU (по памяти и по compute);
    • количество активных контекстов и средняя длина последовательности;
    • ошибки OOM, timeouts, cancellations.

6.2. Более быстрый ответ vs более плотный батч

Ядро оптимизации — баланс между «хочу ответ быстрее» и «хочу обслужить больше запросов теми же GPU». Continuous batching позволяет сильно поднять throughput, но если агрессивно ждать наполнения батчей, пострадают пользователи, у которых latency уйдёт за разумные пределы.

Практичный подход:

  • зафиксировать SLO по p95 (например, TTFT < 1.5 секунды для чата);
  • подбирать параметры батчинга и sampling так, чтобы укладываться в SLO при максимальной загрузке;
  • для VIP-клиентов или критичных сценариев держать отдельный пул vLLM-нод с менее агрессивным батчингом.

7. Чек-лист: как запустить vLLM в прод и не утонуть в техническом долге

  • Определены сценарии использования (чат, RAG, агенты, batch-обработка) и требования по latency/качеству.
  • Выбран портфель моделей (малые/средние/крупные) и описан routing между ними.
  • Настроен vLLM-кластер с PagedAttention, continuous batching и разумными лимитами по max_model_len и batched tokens.
  • Есть отдельный RAG-слой (при необходимости) с векторной БД и фильтрацией по метаданным.
  • Везде используется стриминг ответов для лучшего UX, особенно при высокой нагрузке.
  • Собираются метрики p50/p95/p99, tokens/sec, queue time, GPU util; есть дашборды и алерты.
  • Промты и sampling-параметры (top-k/top-p/temperature) вынесены в конфиг и версионируются.
  • Реализован rate limiting и базовая защита от абьюза (очень длинные промты, чрезмерные max_tokens).
  • Проведено нагрузочное тестирование с реалистичным распределением запросов и длин контекстов.
  • Есть план масштабирования: добавление GPU/нод, разделение по пулам, резерв под пиковые нагрузки.

8. Вопросы и ответы: разбор сложных кейсов настройки vLLM

Чем vLLM отличается от «обычного» сервинга через Hugging Face Transformers?

Классический сервинг через Transformers или простые обёртки над PyTorch обычно:

  • резервирует KV-кэш большими непрерывными блоками под каждый запрос;
  • слабо поддерживает continuous batching — батчи формируются «кусками», а не непрерывным потоком;
  • хуже масштабируется по одновременным пользователям при длинном контексте.

vLLM решает эти проблемы за счёт PagedAttention и более умного планировщика: KV-кэш хранится в страничной модели, запросы постоянно подмешиваются к батчам, а throughput при тех же GPU ресурсах может вырасти в разы.

Как vLLM помогает снизить latency p95?

Напрямую vLLM «не ускоряет математику модели» — он делает более эффективным использование GPU:

  • за счёт страничного KV-кэша можно держать больше одновременных запросов без OOM и жёстких ограничений на контекст;
  • continuous batching позволяет сгладить всплески нагрузки и поднять throughput, не сильно ухудшая p95;
  • chunked prefill и разумное ограничение max_tokens не дают одному запросу «захватить» весь GPU.

В итоге при правильных настройках вы получаете более предсказуемую p95 и меньше «хвостов» в latency.

Какие значения top-k / top-p выбирать для продового сервинга?

Универсальной магической пары нет, но типичные значения для продуктовых сценариев такие:

  • аналитика, отчёты, код: top-k 1–5, top-p 0.7–0.9, temperature 0–0.3;
  • чат-боты и ассистенты: top-k 20–40, top-p 0.9–0.95, temperature 0.5–0.9;
  • сервис, где важна воспроизводимость (например, генерация шаблонных документов) — ближе к детерминированному режиму.

Важно не только качество текстов, но и стабильность длины ответов: слишком «расслабленные» настройки могут раздувать ответы и портить p95.

Как понять, сколько GPU нужно под vLLM для моего продукта?

Прикидка делается в несколько шагов:

  • оцените QPS и среднюю/максимальную длину запросов и ответов;
  • запустите нагрузочный тест на одной машине с vLLM и измерьте tokens/sec и latency p95;
  • рассчитайте, сколько таких инстансов нужно, чтобы выдержать QPS с запасом (обычно ×1.5–2 сверху);
  • учтите, что RAG-слой и векторная БД тоже вносят вклад в latency, и заложите запас.

Отдельно стоит посчитать экономику: иногда выгоднее держать несколько «средних» моделей на менее мощных GPU, чем одну огромную на H100.

Когда имеет смысл переходить на vLLM, а когда достаточно облачного API?

Если у вас небольшой продукт, десятки тысяч запросов в месяц и задача — быстро выйти в прод, чаще проще использовать готовый облачный API. vLLM имеет смысл, когда:

  • нагрузка измеряется миллионами запросов и токенов в день;
  • существенен счёт за токены, и self-hosted/DePIN-решение реально уменьшает расходы;
  • нужен контроль над инфраструктурой и конфигурацией моделей (включая кастомные модели и закрытые weights);
  • вы готовы инвестировать в команду и DevOps-процессы вокруг сервинга.

Полезные материалы

Материал носит исключительно информационный характер и не является индивидуальной инвестиционной рекомендацией (ФЗ-39). Криптовалюты не являются законным средством платежа в РФ (ФЗ-259).

Предыдущая Следующая

Комментариев нет