vLLM — открытый движок для высокопроизводительного сервинга LLM, ориентированный на снижение задержек и стоимости инференса за счёт оптимизаций памяти и планировщика. Ключевые идеи vLLM: PagedAttention (страничное управление KV-кэшем), непрерывный батчинг (подмешивание новых запросов между шагами декода), а также совместимость с OpenAI-совместимым API для быстрой интеграции в продукты.
Связанные страницы: Model serving, Cost optimization LLM, Model evaluation, Evals, KV cache, Prefill cache, Контекстное окно, Top-k, Top-p, Prompt injection.
Где vLLM уместен
- Прод-чат с LLM: стриминг, короткие ответы, много одновременных пользователей.
- RAG: быстрый декод с контролем контекста и цитированием источников.
- Агентные пайплайны: инструментальные вызовы, жёсткие SLO по p95.
- API-сервисы: OpenAI-совместимое REST/WS API, биллинг по токенам.
Ценность vLLM — черезput/tokens·s при стабильной p95. Экономический эффект подробно в FinOps-гайде.
Архитектура vLLM (в общих чертах)
| Компонент | Роль | Что важно в проде |
|---|---|---|
| LLM Engine | Управляет планированием префилла/декода и памятью | Непрерывный батчинг, контроль очередей, приоритеты |
| PagedAttention | «Страничный» KV-кэш (блоки фиксированного размера) | Меньше фрагментации, быстрые вставки/высвобождение, paged-KV |
| Scheduler | Подмешивает последовательности между шагами | ↑ утилизация GPU без head-of-line blocking |
| Weights/Model Manager | Загрузка/эвикт весов, мультимодельность | Sticky-роутинг, тёплый пул, ограничения по памяти |
| Serving Layer | OpenAI-совместимый сервер, стриминг, токенизация | Совместимость SDK, стоп-последовательности, лимиты |
| Telemetry | Метрики/трейсы | p50/p95/p99, tokens·s, cache hit-rate, GPU util |
Префилл vs декод. Префилл (обработка контекста) выполняется пакетно и кэшируется (см. prefill-кэш), декод — итеративно. vLLM активно переиспользует KV-состояние через PagedAttention.
PagedAttention и управление памятью
Задача. Классические реализации держат KV-кэш как длинные непрерывные буферы → фрагментация и дорогие копирования. Решение vLLM. KV разбивается на страницы блоков; последовательности получают/возвращают блоки по мере роста/завершения. Выигрыши:
- Меньше копирований и «дырок» в памяти.
- Более предсказуемый footprint KV (легче планировать p95).
- Удобно комбинировать с paged-KV (горячее на GPU, холодное — на CPU), см. serving.
Практика: подбирайте размер блока KV под модель и нагрузку, следите за hit-rate кэша и временем evict/fetch.
Непрерывный батчинг и планирование
Непрерывный батчинг в vLLM позволяет добавлять новые запросы во время декода без перезапуска шага для уже идущих последовательностей:
- Снижает пустые такты GPU.
- Улучшает баланс префилл/декод под смешанные длины запросов.
- Сокращает p95/p99 и повышает tokens·s (черезput).
Рекомендации:
- Включайте admission control (лимиты на prefill_tokens/decode_tokens), см. Model serving.
- Сегментируйте очереди по SLO (короткие/длинные).
- Используйте стоп-последовательности и max_new_tokens (см. FinOps).
Функции сервинга и совместимость
- OpenAI-совместимый API (chat/completions), стриминг токенов.
- Мульти-GPU: тензорный/пиплайн-параллелизм, распределённый запуск.
- Спекулятивный декод: «черновая» модель предлагает токены, «большая» подтверждает — ускорение на длинных ответах.
- LoRA/адаптеры: обслуживание нескольких адаптеров без перезапуска модели (полезно для персонализации).
- Квантование: поддержка популярных форматов (INT8/INT4, AWQ/GPTQ — зависит от модели/бэкенда).
- Стоп-правила/формат: жёсткие стоп-последовательности, контроль JSON-вывода.
Совместим с экосистемой Hugging Face; на проде проверьте токенизаторы и дистрибутивы весов.
Сценарии применения
- SaaS-ассистент: низкая задержка, высокий параллелизм, биллинг по токенам, sticky-роутинг по клиентам.
- RAG-сервис: умеренный k ретрива, хороший prefill-hit, цитирование источников; см. экономию токенов.
- Агентные графы: короткие шаги + инструментальные вызовы; ограничивайте циклы/перезапуски.
Наблюдаемость и метрики
Мониторьте:
- Latency p50/p95/p99 отдельно по префиллу/декоду.
- Tokens·s (скорость генерации), throughput (RPS).
- KV-footprint и cache hit-rate (prefill/KV).
- Queue time и долю таймаутов/отказов.
- ASR/PLR по безопасностным evals (см. Evals, Prompt leakage).
Полезны экспорты в Prometheus и трассировка «запрос → ретрив → генерация».
Практики FinOps с vLLM
- Режьте T_in: компактный системный пролог, минимум few-shot, цитирование вместо длинных пересказов.
- Держите T_out под контролем: max_new_tokens, стоп-последовательности.
- Prefill-кэш и общий «пролог» для повторяющихся сценариев (см. prefill-кэш).
- KV-политики: горячее на GPU, холодное на CPU, грамотный TTL/LRU.
- Маршрутизация по моделям: дешёвая по умолчанию; эскалация при низкой уверенности/ошибке формата.
- Спекулятивный декод + FlashAttention/оптимизированные ядра → ↑ tokens·s.
- Admission control и «бюджеты токенов» на ключ/тенанта.
Детали — на странице оптимизации стоимости.
Развёртывание и безопасность
- Kubernetes/Helm: горизонтальный масштаб по подам, node-affinity под GPU.
- Мультимодельность: отдельные деплойменты под «тёплые» наборы весов, sticky-роутинг по профилям клиентов.
- Межсервисная аутентификация: mTLS/OIDC; не передавайте сырые ключи в логи.
- Изоляция кэшей: не шарьте префиксы между уровнями доверия; разграничение KV по тенантам.
- TEE/аттестация: для конфиденциальных пайплайнов — см. Confidential Compute.
Сравнение с альтернативами
| Решение | Сильные стороны | Ограничения/риски | Когда выбрать |
|---|---|---|---|
| vLLM | PagedAttention, непрерывный батчинг, OpenAI-API, хорошая утилизация | Требует тюнинга KV-блоков и очередей; чувствителен к токенизаторам | Массовый прод-чат/RAG с упором на tokens·s и p95 |
| TGI (HF) | Удобная интеграция с HF-стеком, зрелый сервер | Меньше фокуса на paged-KV; иные точки тюнинга | Быстрый старт на HF-моделях/платформах |
| TensorRT-LLM | Максимум производительности на NVIDIA, ядра/оптимизации | Завязка на стек NVIDIA, сборка сложнее | Жёсткие SLO, «выжать максимум» из GPU |
| FasterTransformer | Библиотека ускорений низкого уровня | Нужна своя обвязка сервинга | Кастом-сервинг/исследование ядёр |
Реальные системы часто гибридны: vLLM как фронт сервинга, «тяжёлые» ответы — через специализированные бэкенды.
Чек-лист продакшен-запуска
- Определите SLO: p95, tokens·s, timeout, стоимость/ответ.
- Выберите размер KV-блока и стратегию paged-KV; включите непрерывный батчинг.
- Настройте стоп-последовательности и max_new_tokens по сценариям.
- Включите спекулятивный декод для длинных ответов.
- Организуйте prefill-кэш прологов; изоляцию кэшей по тенантам.
- Введите admission control (лимиты токенов), budgets-as-code.
- Подключите метрики и трейсы; заведите «золотой» набор evals.
- Пропишите политику обновления весов и отката; подписи артефактов (supply-chain).
Частые ошибки
- Слишком большой k в RAG → рост T_in, p95 и стоимости без выигрыша качества.
- Отсутствие стоп-последовательностей → «болтовня» и timeouts.
- Общий префикс без prefill-кэша → переплата за одни и те же токены.
- Смешанные модели/токенизаторы в одном пуле → нестабильность формата вывода.
- Неучтённый KV-footprint → OOM при пиках; нет paged-KV/ограничения длины.
- Логи с сырыми промптами и ключами → повышенный PLR.
FAQ
В чём практическая разница PagedAttention?
В KV-кэше вместо длинных буферов используются страницы блоков. Это снижает фрагментацию, упрощает эвикт/аллоц и повышает стабильность p95 при смешанных длинах запросов.
Нужен ли спекулятивный декод всегда?
Полезен на длинных ответах и больших моделях. На коротких репликах выигрыш невелик; проверяйте по своим метрикам.
Как обслуживать множество LoRA-адаптаций?
Держите базовую модель «тёплой», а адаптеры подключайте динамически; ограничивайте число одновременно активных адаптеров и валидируйте версии.
Как контролировать стоимость?
Сократите T_in/T_out, используйте prefill/KV-кэши, непрерывный батчинг, роутинг по моделям и спекулятивный декод. Подробно — в FinOps-гайде.
Какую метрику считать ключевой?
Tokens·s (скорость генерации) при удержании p95 и доли успешных ответов. Без стабильной p95 высокий throughput бесполезен.