vLLM (Високопродуктивний рушій інференсу)(Високопродуктивний рушій інференсу vLLM)

1. Огляд концепції та системна проблема

Традиційні бібліотеки глибокого навчання (чистий PyTorch або Hugging Face Transformers) створювалися для досліджень, а не для високонавантаженого продакшену. При спробі одночасно обслуговувати десятки користувачів виникає катастрофічне марнування ресурсів відеопам'яті:

• Неперервна статична алокація: щоб обробити запит, фреймворк виділяє неперервний блок VRAM під максимальну довжину вікна (наприклад, 8 192 токени), навіть якщо користувач задав питання з трьох слів.
• Внутрішня та зовнішня фрагментація: понад 60–80% наддорогої пам'яті відеокарт A100/H100 простоює пустою, заблокована «про всяк випадок».
• Блокуючий батчинг: якщо один запит вимагає генерації 10 токенів, а сусідній — 2000, перший змушений чекати другого для завершення обчислювального блоку.

vLLM (розроблений у лабораторії LMSYS / UC Berkeley) вирішив цю проблему раз і назавжди. Завдяки алгоритму PagedAttention та ітераційному неперервному плануванню, vLLM перетворився на промисловий стандарт самохостингу мовних моделей, що дозволяє витискати максимальну пропускну здатність із кожного графічного прискорювача.

2. Архітектурна таксономія та ментальна модель

Архітектурний стек vLLM будується навколо оптимізації доступу до пам'яті та багатопоточності:

┌─────────────────────────────────────────────────────────────┐
│                    vLLM ENGINE ARCHITECTURE                 │
├─────────────────────────────────────────────────────────────┤
│ 1. Async Frontend Layer:                                    │
│    • OpenAI Compatible HTTP Server (FastAPI / Uvicorn)      │
│    • Streaming Response Manager (Server-Sent Events)        │
├─────────────────────────────────────────────────────────────┤
│ 2. Continuous Batching Scheduler:                           │
│    • Iteration-level scheduling (No static batch pauses)    │
│    • Automatic Prompt Prefix Caching (KV-Cache sharing)     │
├─────────────────────────────────────────────────────────────┤
│ 3. Memory Subsystem (PagedAttention Engine):                │
│    • Physical Blocks Pool (Сторінки пам'яті по 16 токенів)  │
│    • Block Table (Таблиця відповідності логічних і фізичних)│
├─────────────────────────────────────────────────────────────┤
│ 4. Compute Subsystem: Custom CUDA / ROCm Kernels, FP8, TP   │
└─────────────────────────────────────────────────────────────┘

1. Рушій PagedAttention:
   • Розбиває KV-кеш послідовності на невеликі сторінки фіксованого розміру (зазвичай 16 або 32 токени).
   • Фізичні сторінки можуть розміщуватися у будь-якому місці VRAM без необхідності бути суміжними, що повністю ліквідує зовнішню фрагментацію.
2. Неперервний батчинг (Continuous Batching):
   • Обчислення плануються на рівні однієї ітерації генерації токена. Як тільки запит закінчує відповідь, його сторінки негайно звільняються, а на його місце одразу встає новий запит із черги.
3. Автоматичне префіксне кешування (Automatic Prefix Caching - APC):
   • Якщо сотні запитів починаються з однакового системного промпту або однакових файлів кодової бази, vLLM зберігає ці сторінки кешу і перевикористовує їх між різними користувачами з нульовими витратами обчислень.
4. Розподілений паралелізм (Distributed Execution):
   • Підтримка Tensor Parallelism (TP) та Pipeline Parallelism (PP) на базі протоколів NCCL для безшовного розділення моделей між 2, 4 або 8 відеокартами.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл обробки запиту сервером vLLM:

1. Прийом запиту через OpenAI API: Клієнт надсилає POST-запит на /v1/chat/completions.
2. Токенізація та перевірка наявності префіксу: Токенізатор розбиває текст на ідентифікатори. Диспетчер пам'яті перевіряє хеш перших токенів: якщо системний промпт уже завантажений у Paged-кеш іншим користувачем, ці сторінки повторно не обчислюються (Cache Hit).
3. Виділення фізичних сторінок пам'яті: Блок-менеджер виділяє рівно стільки сторінок по 16 токенів, скільки потрібно для збереження вхідного контексту.
4. Ітеративний крок генерації (Model Forward Step): Кастомні високошвидкісні CUDA-кернели зчитують фрагментовані сторінки KV-кешу паралельно і виконують розрахунок наступного токена.
5. Стрімінг та динамічне виділення пам'яті: Згенерований токен миттєво відправляється клієнту через SSE. Якщо поточна сторінка заповнилася, блок-менеджер виділяє рівно одну нову сторінку на 16 токенів із пулу.
6. Очищення ресурсів: Після появи токена завершення або розриву з'єднання клієнтом усі виділені сторінки миттєво повертаються в пул вільної пам'яті.

4. Практичні інженерні сценарії в продакшені

01. Розгортання корпоративного AI-кластера на 500 співробітників

Компанія будує внутрішній сервіс для допомоги розробникам:

• Сервер із 4 відеокартами NVIDIA A100 (80GB).
• Запуск команди:

  vllm serve Qwen/Qwen2.5-Coder-32B-Instruct --tensor-parallel-size 4 --enable-prefix-caching
  

• Сервер підтримує одночасну роботу сотень інженерів у Cursor та VS Code із затримкою першого токена менше 100 мс.

02. Високонавантажена RAG-система з мільйонним потоком документів

Пакетна індексація та інтерактивний пошук по базі знань:

• Завдяки Continuous Batching сервер паралельно обробляє 128 запитів користувачів, демонструючи сумарну пропускну здатність понад 3 500 токенів на секунду на одну ноду.

03. Примусова структурована генерація JSON (Guided Decoding)

Сервіс вимагає абсолютно точного дотримання складної схеми Zod:

• vLLM інтегрує синтаксичні рушії граматик (Outlines / Guidance).
• На рівні логітів маскуються всі токени, які порушують правила синтаксису JSON, гарантуючи 100% валідність відповіді без збоїв парсера.

5. Підводні камені, типові помилки та безпека

• Помилки OOM через gpu_memory_utilization: За замовчуванням vLLM бронює 90% доступної пам'яті під кеш. Якщо паралельно запустити інший процес або виставити коефіцієнт 0.98, сплеск активацій під час довгого префіллу призведе до падіння процесу з помилкою CUDA Out of Memory.
• Відсутність вбудованої аутентифікації: vLLM створювався як обчислювальний рушій. Запуск його напряму в публічний інтернет без зовнішнього зворотного проксі (Nginx/Caddy) та валідації API-ключів відкриває безконтрольний доступ до ваших GPU.
• Вразливості при некоректній зупинці процесів (Zombie Processes): При використанні тензорного паралелізму аварійне завершення головного процесу Python може залишити дочірні процеси NCCL заблокованими у відеопам'яті. Потрібно очищати залишки через pkill -f vllm.
• Висока чутливість до версій драйверів CUDA: vLLM використовує екстремально оптимізовані скомпільовані ядра C++/CUDA. Невідповідність між версією PyTorch, драйвером NVIDIA та версією CUDA Toolkit може спричинити збої компіляції під час старту.