Продакшн-розгортання vLLM: архітектура високопропускного обслуговування інференсу

Оновлено 11 грудня 2025 року

Оновлення за грудень 2025: Stripe досягла зниження витрат на інференс на 73% завдяки міграції на vLLM (50 млн щоденних API-запитів на 1/3 парку GPU). PagedAttention усуває 60-80% втрат пам'яті через фрагментацію KV-кешу. vLLM забезпечує пропускну здатність у 2-24 рази вищу порівняно з традиційним обслуговуванням. Використовується в продакшні Meta, Mistral AI, Cohere, IBM. OpenAI-сумісні API спрощують впровадження.

Команда ML-платформи Stripe спостерігала, як їхні витрати на інференс знизилися на 73% після міграції з Hugging Face Transformers на vLLM, обробляючи ті самі 50 мільйонів щоденних API-запитів на третині парку GPU.¹ Секрет ефективності vLLM криється в PagedAttention — алгоритмі, що працює з пам'яттю GPU як віртуальна пам'ять в операційних системах, усуваючи фрагментацію, яка марнує 60-80% пам'яті в традиційних системах інференсу.² Організації, що запускають продакшн-навантаження LLM, виявляють, що vLLM забезпечує покращення пропускної здатності в 2-24 рази порівняно зі звичайними фреймворками обслуговування, трансформуючи економіку розгортання великих мовних моделей у масштабі.³

Ландшафт обслуговування інференсу фрагментований на десятки варіантів: TensorRT-LLM обіцяє максимальну оптимізацію для NVIDIA, Hugging Face TGI пропонує звичну інтеграцію, а Ollama спрощує локальне розгортання. Проте vLLM став домінуючим вибором для продакшн-навантажень, забезпечуючи інференс у Meta, Mistral AI, Cohere та IBM.⁴ Поєднання PagedAttention, безперервної батчингу та OpenAI-сумісних API у фреймворку створює досвід розгортання, що балансує сиру продуктивність з операційною простотою. Розуміння архітектури vLLM та патернів розгортання відрізняє організації, які досягають економічно ефективного інференсу, від тих, хто потопає в рахунках за GPU.

PagedAttention трансформує керування пам'яттю

Традиційний інференс LLM виділяє суцільний блок пам'яті для кешу ключів-значень (KV) кожної послідовності, резервуючи простір для максимально можливої довжини послідовності незалежно від фактичного використання. Система, налаштована на 4096 токенів, виділяє цей повний обсяг навіть для відповідей зі 100 токенів, марнуючи 97% зарезервованої ємності. Помножте на сотні одночасних запитів — і пам'ять GPU заповнюється порожніми резервуваннями, поки фактичні послідовності чекають у черзі на ресурси.

PagedAttention переосмислює цю архітектуру, розділяючи пам'ять GPU на сторінки фіксованого розміру, зазвичай по 16 токенів кожна.⁵ Кожна послідовність підтримує список посилань на сторінки замість суцільного виділення, що забезпечує кілька проривних можливостей:

Несуцільне зберігання дозволяє блокам KV-кешу розподілятися по доступній пам'яті GPU. Системі більше не потрібні великі суцільні регіони, що усуває фрагментацію, яка переслідує традиційні алокатори. Послідовність з 2000 токенів зберігає свій кеш на 125 сторінках, розподілених там, де є місце.

Динамічне виділення надає пам'ять лише в міру зростання послідовностей. Перший токен виділяє одну сторінку. Сімнадцятий токен запускає виділення другої сторінки. Споживання пам'яті відстежує фактичне використання, а не теоретичні максимуми, що різко покращує ефективну ємність.

Спільне використання пам'яті дозволяє ідентичним префіксам промптів спільно використовувати сторінки KV-кешу між запитами. Десять користувачів, які задають варіації одного системного промпту, спільно використовують одну закешовану копію цього префіксу, зменшуючи споживання пам'яті на 90% для типових патернів. Продакшн-системи зі стандартизованими промптами бачать покращення утилізації понад 400%.⁶

Майже нульові втрати усувають внутрішню фрагментацію, характерну для статичного виділення. Традиційні системи марнують в середньому 4,1 токена на послідовність у частково заповнених блоках. Гранулярність на рівні сторінок PagedAttention зменшує втрати до часток сторінки, зазвичай менше 8 токенів на послідовність незалежно від довжини.

Алгоритм черпає пряме натхнення з віртуальної пам'яті операційних систем, застосовуючи десятиліття досліджень керування пам'яттю до інференсу на GPU. Так само як сучасні операційні системи відображають віртуальні адреси на фізичні сторінки пам'яті, PagedAttention відображає логічні позиції KV-кешу на фізичні блоки пам'яті GPU. Накладні витрати на трансляцію додають мікросекунди до кожного обчислення уваги, але економлять гігабайти ємності пам'яті.

Безперервний батчинг максимізує утилізацію GPU

Статичний батчинг чекає на фіксовану кількість запитів перед їх спільною обробкою, створюючи сплески затримки при частковому заповненні батчів та падіння пропускної здатності при нерівномірному надходженні запитів. Розмір батчу 32 означає, що 31-й запит чекає ще одного надходження перед початком обробки, потенційно додаючи секунди затримки в періоди низького трафіку.

Безперервний батчинг у vLLM повністю усуває межі батчів.⁷ Планувальник працює на рівні ітерацій, а не запитів, приймаючи рішення на кожному прямому проході, а не на кожному батчі. Коли послідовність завершує генерацію, її слот негайно приймає новий запит без очікування завершення сусідніх послідовностей. GPU обробляє будь-яку наявну роботу в кожен момент, заповнюючи прогалини, які статичний батчинг залишає порожніми.

Реалізація вимагає ретельної координації між керуванням пам'яттю та плануванням:

Планування на рівні ітерацій оцінює чергу запитів на кожному кроці декодера. Завершені послідовності звільняють свої слоти, запити в очікуванні займають доступну ємність, і наступна ітерація продовжується з оптимально заповненим батчем. Варіація затримки між запитами поглинається, а не підсилюється.

Обробка витіснення керує ситуаціями, коли тиск на пам'ять змушує виселяти послідовності. Запити з нижчим пріоритетом створюють контрольні точки стану свого KV-кешу та звільняють пам'ять GPU для послідовностей з вищим пріоритетом. Коли ємність повертається, витіснені послідовності відновлюються з контрольних точок, а не перезапускаються з нуля.

Кешування префіксів визначає запити зі спільними префіксами та направляє їх до інстансів, які вже містять відповідні сторінки KV-кешу. Система підтримки клієнтів, де кожен запит починається з однакового контексту в 500 токенів, обслуговує наступні токени з закешованого стану, усуваючи надлишкове обчислення префікса.

Бенчмарки демонструють вплив: vLLM досягає пропускної здатності 793 токени на секунду порівняно з 41 токеном на секунду у Ollama при еквівалентних конфігураціях, з P99 затримкою 80 мс проти 673 мс.⁸ Архітектура безперервного батчингу підтримує ці переваги на всіх рівнях конкурентності від 1 до 256 одночасних користувачів.

Продакшн-архітектура масштабується на кластери

Однонодові розгортання vLLM обробляють значний трафік, але продакшн-системи вимагають оркестрації на рівні кластера для надійності, масштабу та ефективності. vLLM production-stack перетворює рушій інференсу на повноцінну систему обслуговування з чотирма критичними доповненнями.⁹

Маршрутизація запитів направляє вхідні запити до відповідних бекенд-інстансів на основі ключів маршрутизації, ідентифікаторів сесій або збігу префіксів. Інтелектуальна маршрутизація максимізує повторне використання KV-кешу, надсилаючи пов'язані запити до інстансів, які вже містять відповідний контекст. Розмова з кількома турами послідовно направляється до одного бекенду, уникаючи надлишкового обчислення префікса між інстансами.

Спільне використання KV-кешу поширює ефективність пам'яті PagedAttention на кілька інстансів vLLM через проект LMCache. Бекенди спільно використовують обчислені блоки KV-кешу через високошвидкісні з'єднання, забезпечуючи влучання в кеш навіть коли запити направляються до різних інстансів. Системи з повторюваними навантаженнями бачать зменшення затримки в 3-10 разів та покращення пропускної здатності в 2-5 разів від крос-інстансного спільного використання кешу.¹⁰

Інтеграція спостережуваності надає метрики через Prometheus та візуалізацію через дашборди Grafana. Метрики на рівні запиту фіксують час до першого токена (TTFT), час між токенами (TBT) та наскрізну затримку. Метрики на рівні інстансу відстежують утилізацію GPU, тиск на пам'ять, глибину черги та показники влучань у кеш. Операційні команди отримують видимість вузьких місць продуктивності та дані для планування ємності.

Горизонтальне масштабування додає та видаляє інстанси vLLM на основі сигналів попиту. Розгортання Kubernetes використовують Horizontal Pod Autoscaler з користувацькими метриками, націленими на глибину черги або перцентилі затримки. Шар маршрутизатора автоматично виявляє нові інстанси та перебалансовує трафік, забезпечуючи еластичну ємність, що відстежує фактичний попит.

Розгортання слідує стандартним патернам Kubernetes через Helm charts:

# values.yaml для vLLM production-stack
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

Розгорнутий стек надає OpenAI-сумісний API через Kubernetes service, забезпечуючи пряму заміну для застосунків, які наразі викликають ендпоінти OpenAI або Azure OpenAI. Існуючі кодові бази потребують лише зміни URL ендпоінта для міграції з хмарних API на самостійно розміщений інференс.

Вимоги до інфраструктури формують рішення щодо розгортання

Ефективність пам'яті vLLM дозволяє запускати більші моделі на менших конфігураціях GPU, але вибір обладнання все одно визначає характеристики продуктивності. Розуміння взаємозв'язку між розміром моделі, пам'яттю GPU та пропускною здатністю інформує рішення про закупівлі.

Пам'ять GPU обмежує максимальний розмір моделі та ємність конкурентних батчів. Модель з 70B параметрів у FP16 вимагає 140 ГБ лише для ваг, що потребує багато-GPU тензорного паралелізму на будь-якому поточному обладнанні. Та сама модель у квантизації INT4 вміщується в 35 ГБ, розгортається на одному A100 80GB або H100 зі значним запасом для KV-кешу. Пропускна здатність пам'яті часто обмежує пропускну здатність більше, ніж сире обчислення, що робить GPU з HBM3 непропорційно ефективними.

Тензорний паралелізм розділяє шари моделі між кількома GPU в межах одного вузла, необхідний для моделей, що перевищують пам'ять одного GPU. vLLM підтримує ступені тензорного паралелізму, що відповідають кількості GPU, автоматично шардуючи шари уваги та прямого поширення. 8-GPU вузол, що працює з тензорним паралелізмом 8, обслуговує модель з 405B параметрів, яка інакше вимагала б кількох вузлів з повільнішим конвеєрним паралелізмом.

Мережева фабрика стає критичною для багатовузлових розгортань. Конвеєрний паралелізм між вузлами вимагає з'єднань з низькою затримкою та високою пропускною здатністю між етапами. Мережі InfiniBand або RoCE з пропускною здатністю 200-400 Gbps підтримують ефективне багатовузлове обслуговування, тоді як стандартний Ethernet вносить затримку, що суттєво погіршує час до першого токена.

Пропускна здатність сховища впливає на продуктивність холодного старту при завантаженні ваг моделі. Модель з 70B параметрів у FP16 вимагає передачі 140 ГБ зі сховища до пам'яті GPU перед обслуговуванням перших запитів. NVMe-сховище з швидкістю 7 ГБ/с завантажує модель за 20 секунд; мережеве сховище зі швидкістю 500 МБ/с займає 5 хвилин. Продакшн-системи або підтримують теплі резервні інстанси, або впроваджують стратегії кешування моделей для мінімізації впливу холодного старту.

Introl допомагає організаціям проектувати інфраструктуру vLLM по всій нашій глобальній зоні покриття, підбираючи конфігурації обладнання до вимог навантаження при оптимізації економічної ефективності.¹¹ Наші інженери розгорнули інфраструктуру інференсу, що обслуговує мільярди запитів щомісяця, розуміючи нюанси, які відрізняють функціональні розгортання від високооптимізованих систем.

Порівняння vLLM з альтернативами

Екосистема обслуговування інференсу пропонує кілька фреймворків, кожен з унікальними сильними сторонами. Вибір правильного інструменту вимагає відповідності можливостей фреймворку характеристикам навантаження.

TensorRT-LLM забезпечує максимальну продуктивність на обладнанні NVIDIA через агресивну оптимізацію ядер та компіляцію графів. Бенчмарки показують, що TensorRT-LLM досягає 10000+ вихідних токенів на секунду на H100 з квантизацією FP8, з часом до першого токена близько 100 мс.¹² Компроміс: складне налаштування, що вимагає конвертації контрольних точок, побудови двигуна та розширеної конфігурації через TensorRT-LLM, tensorrtllm_backend та Triton Inference Server. Найбільше виграють організації з виділеними командами ML-інфраструктури та стабільними розгортаннями моделей.

**Hugging Fa

[Контент скорочено для перекладу]