vLLM Production Deployment: Побудова високопропускної архітектури для інференс-сервінгу
Оновлено 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) кожної послідовності, резервуючи простір для максимально можливої довжини послідовності незалежно від фактичного використання. Система, налаштована на 4,096 токенів, виділяє весь цей обсяг навіть для 100-токенових відповідей, марнуючи 97% зарезервованої ємності. Помножте на сотні одночасних запитів, і пам'ять GPU заповнюється пустими резерваціями, поки фактичні послідовності чекають у черзі на ресурси.
PagedAttention переосмислює цю архітектуру, розділяючи пам'ять GPU на блоки фіксованого розміру, зазвичай по 16 токенів кожен.⁵ Кожна послідовність підтримує список посилань на сторінки замість суміжного виділення, що забезпечує декілька проривних можливостей:
Несуміжне зберігання дозволяє блокам KV кешу розкидатися по доступній пам'яті GPU. Системі більше не потрібні великі суміжні регіони, що усуває фрагментацію, яка мучить традиційні алокатори. Послідовність з 2,000 токенів зберігає свій кеш на 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 трансформує движок інференсу в повноцінну систему сервінгу з чотирма критичними доповненнями.⁹
Маршрутизація запитів направляє вхідні запити до відповідних backend інстансів на основі ключів маршрутизації, ID сесій або префіксного співставлення. Інтелектуальна маршрутизація максимізує повторне використання KV кешу, відправляючи пов'язані запити до інстансів, які вже зберігають релевантний контекст. Розмова з кількома поворотами маршрутизується послідовно до одного backend, уникаючи надлишкового обчислення префіксу між інстансами.
Спільне використання KV кешу розширює ефективність пам'яті PagedAttention через кілька інстансів vLLM за допомогою проекту LMCache. Backend ділять обчислені блоки KV кешу через високошвидкісні з'єднання, забезпечуючи попадання в кеш навіть коли запити маршрутизуються до різних інстансів. Системи з повторюваними навантаженнями бачать зменшення затримки в 3-10 разів та покращення пропускної здатності в 2-5 разів від спільного використання кешу між інстансами.¹⁰
Інтеграція спостережуваності експонує метрики через Prometheus та візуалізацію через дашборди Grafana. Метрики за запитом захоплюють час до першого токену (TTFT), час між токенами (TBT) та наскрізну затримку. Метрики за інстанс відстежують утилізацію GPU, тиск пам'яті, глибину черги та частоту попадання в кеш. Операційні команди отримують видимість вузьких місць продуктивності та дані планування ємності.
Горизонтальне масштабування додає та видаляє інстанси vLLM на основі сигналів попиту. Розгортання Kubernetes використовують Horizontal Pod
