Ускорення інференсу LLM: vLLM, PagedAttention і continuous batching

Ми використовуємо vLLM — open-source двигун для LLM-інференсу, який став стандартом у production. Ключове нововведення — PagedAttention: управління KV-кешем за аналогією з віртуальною пам'яттю ОС. Це усуває фрагментацію і збільшує throughput у 15–24 рази порівняно з наївною реалізацією на HuggingFace transformers — vLLM перевершує HF transformers за throughput у 20 разів. У нашій практиці vLLM дозволяє обробляти сотні запитів на секунду на існуючому обладнанні, забезпечуючи стабільний результат. Економія на GPU-витратах може досягати 2–3 разів, що особливо важливо при масштабуванні. Наприклад, один клієнт скоротив витрати на інференс з $15 000 до $5 000 на місяць після переходу на vLLM з AWQ. На відміну від стандартного HuggingFace transformers, vLLM використовує continuous batching і tensor parallelism, що дає приріст throughput до 20 разів. Якщо ви використовуєте LLM у production, ви стикаєтеся з проблемами високої затримки та неефективного використання GPU. vLLM вирішує їх на рівні архітектури. Замовте оптимізацію свого інференсу вже сьогодні.

Як PagedAttention вирішує проблему фрагментації KV-кеша?

vLLM використовує PagedAttention — механізм, що розбиває KV-кеш на сторінки фіксованого розміру (зазвичай 16 токенів). Сторінки виділяються на вимогу, можуть бути несуміжними. Це усуває фрагментацію, характерну для безперервного виділення пам'яті під кожну послідовність. Prefix sharing дозволяє економити VRAM при повторюваних system prompts. У результаті на тих же GPU досягається throughput 500–2000 tokens/sec. Механізм описаний у vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention.

У чому недоліки стандартного HuggingFace transformers?

HF transformers добре для експериментів, погано для production:

• Кожен запит обробляється незалежно — немає батчингу запитів.
• KV-кеш зберігається цілком для кожної послідовності — VRAM витрачається неефективно.
• Немає prefill/decode розділення.
• Throughput: ~10–50 tokens/sec на одному запиті.

vLLM на тих же GPU дає 500–2000 tokens/sec через concurrent batching. Причому continuous batching — ключова функція, яка об'єднує запити на етапі decode без очікування завершення попередніх.

Як розгорнути vLLM у production?

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model mistralai/Mistral-7B-Instruct-v0.3 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --max-num-seqs 256 \ --gpu-memory-utilization 0.90 \ --host 0.0.0.0 \ --port 8000 

from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="none") response = client.chat.completions.create( model="mistralai/Mistral-7B-Instruct-v0.3", messages=[{"role": "user", "content": "Explain transformer attention"}], max_tokens=500, temperature=0.7 ) 

Розподіл навантаження та квантизація

Tensor Parallelism для великих моделей

python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70b-instruct \ --tensor-parallel-size 4 \ --dtype bfloat16 \ --max-model-len 16384 \ --gpu-memory-utilization 0.95 

Квантизація AWQ для економії VRAM

python -m vllm.entrypoints.openai.api_server \ --model TheBloke/Mistral-7B-Instruct-v0.3-AWQ \ --quantization awq --dtype auto 

Результат: 7B модель в AWQ 4-bit займає ~4 GB VRAM замість ~14 GB у BF16. Зниження вартості інференсу до 70%. Для H100 доступна квантизація FP8, що дає дворазове прискорення відносно FP16.

Як працює speculative decoding?

Прискорення декодування через draft model: маленька модель (draft) генерує кілька токенів, велика (target) верифікує їх паралельно. При збігу — приймаємо всі токени за один forward pass.

python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70b-instruct \ --speculative-model meta-llama/Llama-3-8b-instruct \ --num-speculative-tokens 5 \ --tensor-parallel-size 4 

Приріст: 1.5–2.5x speedup для типових текстів при <1% зміні якості.

Як continuous batching підвищує throughput?

Continuous batching дозволяє серверу починати обробку нового запиту, не чекаючи завершення попередніх. vLLM реалізує це на рівні KV-кеша, динамічно додаючи та видаляючи послідовності з поточного forward pass. На відміну від статичного батчингу (коли запити накопичуються в буфері), continuous batching мінімізує idle-час GPU і дає приріст throughput до 50%.

Тюнінг продуктивності та бенчмарк

Як налаштувати vLLM для максимального throughput?

1. Встановіть vLLM і запустіть базовий сервер з параметрами за замовчуванням.
2. Перевірте latency і throughput при поточному навантаженні.
3. Збільште max_num_seqs до 256, потім до 512, контролюючи VRAM.
4. Налаштуйте block_size на 32 для кращого балансу фрагментації та швидкості.
5. Увімкніть квантизацію AWQ 4-bit для економії пам'яті.
6. Опціонально додайте speculative decoding, якщо latency важливіша за throughput.
7. Проведіть фінальне тестування з вашим робочим навантаженням.

# Параметри для максимального throughput (не latency) VLLM_CONFIG = { "max_num_seqs": 512, "max_num_batched_tokens": 32768, "block_size": 32, "swap_space": 4, } # Параметри для мінімальної latency (не throughput) VLLM_CONFIG_LATENCY = { "max_num_seqs": 32, "max_num_batched_tokens": 4096, "disable_async_output_proc": False, } 

Порівняння методів оптимізації

Бенчмарк продуктивності

На одному A100 80GB, Mistral-7B-Instruct, 500-токенні відповіді:

Що входить у роботу з оптимізації інференсу?

• Аудит поточної інфраструктури та пайплайну інференсу.
• Вибір конфігурації vLLM під конкретну модель і навантаження.
• Розгортання сервера з continuous batching, tensor parallelism і квантизацією.
• Тестування latency P99 і throughput (до 2000 tokens/sec).
• Документація з експлуатації та тюнінгу параметрів.
• Навчання команди: як моніторити, логувати, оновлювати модель.
• Технічна підтримка на етапі запуску.

Оцінимо ваш проект і запропонуємо оптимальне рішення. Наш досвід — 5+ років у MLOps, десятки продакшен-систем з LLM. Гарантуємо стабільну роботу під навантаженням. Для отримання консультації зв'яжіться з нами — розповімо, як vLLM вирішує вашу задачу.