vLLM проти SGLang 2026: ми протестували обидва на H100

vLLM проти SGLang 2026: ми протестували обидва на H100

У грудні 2025 року Hugging Face перевела TGI у режим технічної підтримки й тепер спрямовує команди до vLLM або SGLang для нових розгортань. Якщо ви сьогодні будуєте стек інференсу, реальне питання не «чи варто мені переходити з TGI?», а який із цих двох рушіїв дійсно відповідає вашому навантаженню.

Короткий підсумок

Обирайте vLLM, якщо вам потрібна найширша підтримка обладнання, найбільша спільнота та перевірений шлях до продакшену в AWS, GCP та Azure.

Обирайте SGLang, якщо ваше навантаження складається переважно з багатокрокових діалогів, структурованих виводів або пайплайнів із великою кількістю префіксів (наприклад, RAG), і вас влаштовує менша екосистема.

Тепер розберемося, де саме кожен із рушіїв має перевагу.

Як ми до цього дійшли? Вихід TGI

Text Generation Inference (TGI) роками забезпечував екосистему Hugging Face, але станом на грудень 2025 року він приймає лише виправлення помилок, без нових функцій. Власні сервіси Inference Endpoints від Hugging Face тепер за замовчуванням використовують vLLM, із SGLang як альтернативою.

Це залишає нам двох реальних претендентів для самостійного хостингу LLM. Обидва мають відкритий код, обидва підтримують API OpenAI і обидва працюють на GPU NVIDIA. Відмінності проявляються під навантаженням.

Вердикт: І vLLM, і SGLang готові до продакшену як заміна TGI. Якщо ви мігруєте, будь-який із них є безпечним вибором; решта цього посібника допоможе вам визначитися, який саме.

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

Результати тестів залежать від моделі, GPU та рівня конкурентності, тому нижче наведено дані незалежних тестів на однаковому обладнанні. Наведені дані взято з бенчмарків H100 від Spheron з використанням Llama 3.3 70B Instruct у форматі FP8 та тестів PremAI з Llama 3.1 8B.

Llama 3.3 70B на H100 (FP8)

Llama 3.1 8B на H100

На менших моделях розрив збільшується. PremAI виміряла показник SGLang на рівні приблизно 16 200 токенів/с проти 12 500 токенів/с у vLLM, що дає перевагу в пропускній здатності на 29% для SGLang. LMDeploy тут показав результати, подібні до SGLang, але це окрема тема.

Що означають ці цифри

На масштабі 70B різниця скромна (3–5%). На масштабі 8B вона значуща. Закономірність зрозуміла: RadixAttention від SGLang дає більший виграш, коли prefill становить більшу частку загальної вартості, що трапляється з меншими моделями та коротшими виводами.

Хвостова затримка розповідає схожу історію. TTFT p95 у SGLang стабільно був на 5–8% нижчим, ніж у vLLM, на всіх перевірених рівнях конкурентності. Якщо ви будуєте інтерфейс чату в реальному часі, де важливі кожні 50 мс, ця різниця накопичується для користувачів.

Вердикт: SGLang перемагає за сирою пропускною здатністю, особливо для менших моделей. vLLM близький до нього на масштабах 70B+. Для більшості продакшен-навантажень різниця становить одиниці відсотків, що важливо на масштабі, але не є вирішальним фактором ні в одному, ні в іншому випадку.

Кешування префіксів: RadixAttention проти автоматичного кешування префіксів

Обидва рушії кешують обчислення KV для повторюваних префіксів, але механізми відрізняються способами, які мають значення для певних навантажень. Якщо ви вже знайомі з кешуванням промптів на рівні API, уявіть це як серверну версію.

vLLM використовує хешування на рівні блоків. Він розбиває кеш KV на блоки фіксованого розміру, хешує їх і шукає збіги для нових запитів. Це передбачувано, ефективно та легко зрозуміло, але для влучень у кеш потрібні узгоджені межі блоків.

SGLang використовує радекс-дерево, індексоване на рівні токенів. Воно автоматично виявляє спільні префікси між запитами без ручного налаштування. Якщо 50 користувачів надсилають повідомлення в тій самій гілці розмови, SGLang автоматично знаходить і повторно використовує спільний префікс.

Де це дійсно має значення

RunPod протестував багатокрокові діалоги й виявив, що SGLang стабільно видавав ~30–31 токен/с за високої конкурентності, тоді як vLLM впав з 22 до 16 токенів/с зі зростанням тиску на кеш. Це суттєвий розрив для навантажень чат-ботів та агентів.

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

Вердикт: SGLang перемагає для динамічних багатокрокових навантажень. vLLM цілком достатній для пакетного інференсу та шаблонних промптів, де префікси передбачувані.

Структуровані виводи

Якщо вам потрібне примусове дотримання JSON-схеми або обмежена генерація, цей розділ дуже важливий. Обидва рушії підтримують структуровані виводи через бекенди граматики, такі як XGrammar та LLGuidance, але історія продуктивності дуже різниться.

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

Повторювані проти динамічних схем

Вибір бекенду також має значення:

Без примусової структуризації точність виводів падає до ~61% для складних схем. З нею точність зростає на 20–25 процентних пунктів. Тож це не опціонально для продакшен-воркфлоу агентів, і обраний вами рушій визначає, скільки пропускної здатності ви жертвуєте.

Вердикт: SGLang перемагає для структурованих виводів. Якщо ваш пайплайн покладається на примусове дотримання JSON-схеми (а так робить більшість воркфлоу агентів), підхід SGLang із перекриттям означає, що ви не платите податок на пропускну здатність.

Multi-LoRA та обслуговування донавчених моделей

Обидва рушії підтримують обслуговування кількох адаптерів LoRA з однієї базової моделі, що є критично важливим, якщо ви донавчаєте моделі для різних орендарів або задач.

SGLang розглядає multi-LoRA як першокласну функцію з нативним батчингом: запити, що targeting різні адаптери, можуть бути в одному батчі. vLLM також це підтримує, але реалізація SGLang була дещо більш відполірованою в останніх релізах.

Практична різниця? Якщо ви обслуговуєте 5–10 адаптерів LoRA з однієї базової моделі Llama 70B, обидва працюють. Якщо ж ви запускаєте 50+ адаптерів із гетерогенними патернами трафіку, нативний батчинг SGLang краще справляється з плануванням.

Вердикт: SGLang має невелику перевагу для multi-LoRA на масштабі. Для кількох адаптерів обидва рушії працюють однаково добре.

Спекулятивне декодування

Обидва рушії підтримують спекулятивне декодування, яке використовує малу «чернеткову» модель для передбачення токенів, які потім паралельно перевіряє основна модель. Результат — інференс у 2–3 рази швидший для сценаріїв, обмежених пам’яттю.

vLLM нещодавно представив Unified Parallel Drafting, і тепер спекулятивне декодування працює разом із структурованими виводами. Реалізація SGLang подібна за можливостями, з дещо кращою продуктивністю на помірних рівнях конкурентності.

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

Вердикт: Нічия. Обидва рушії забезпечують порівнянні прискорення завдяки спекулятивному декодуванню.

Підтримка обладнання та розгортання

Саме тут vLLM отримує значну перевагу.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (через vllm-xpu-kernels)
• AWS Trainium та Inferentia
• Google TPU
• Зріла документація Kubernetes із Helm-чартами, пробами запуску/готовності/живучості
• Інтеграція з NVIDIA Container Toolkit «з коробки»

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, через ROCm)
• Розгортання з орієнтацією на Docker
• Kubernetes можливий, але менш документований

Якщо ви розгортаєте щось інше, окрім NVIDIA або AMD, vLLM — ваш єдиний варіант. Зокрема в AWS підтримка Trainium дозволяє значно скоротити витрати на інференс, і SGLang не може працювати з цим обладнанням.

Для команд, що працюють на стандартних GPU NVIDIA, історія розгортання схожа. Обидва надають Docker-образи та ендпоінти, сумісні з OpenAI. Просто vLLM має більше перевірених продакшен-гайдів та Helm-чартів від спільноти.

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

Вердикт: vLLM перемагає за широтою підтримки обладнання та зрілістю розгортання. SGLang підходить, якщо ви використовуєте NVIDIA або AMD. Будь-де ще vLLM — єдиний вибір.

Розділене обслуговування

Обидва рушії підтримують розділення prefill (ресурсомістке за обчисленнями) та decode (ресурсомістке за пам’яттю) на різні пули воркерів. Це дозволяє масштабувати кожну фазу незалежно: більше воркерів prefill під час сплесків запитів із промптами, більше воркерів decode для довгої генерації.

SGLang підтримує Mooncake та NIXL як бекенди передачі даних для розділення та опублікував результати, що показують у 2,7 раза вищу пропускну здатність декодування на кластерах NVIDIA GB200 NVL72. Розділене обслуговування vLLM також функціональне, хоча менш широко документоване.

Ця функція найбільш важлива на дуже великому масштабі (96+ GPU). Якщо ви використовуєте кілька GPU, вам, ймовірно, це поки не потрібно.

Вердикт: SGLang має невелику перевагу в зрілості розділеного обслуговування. Обидва підтримують це; SGLang опублікував більше реальних результатів.

Коли використовувати кожен:框架 прийняття рішень

Чесна відповідь для багатьох команд: спробуйте обидва. Вони обидва мають відкритий код, обидва надають той самий API OpenAI, і перемикання між ними — це просто заміна контейнера. Запустіть своє реальне навантаження на кожному протягом дня та порівняйте метрики, важливі для вас.

Якщо ви маршрутизуєте трафік через кілька бекендів інференсу, LLM-шлюз може стояти перед будь-яким із рушіїв і обробляти аварійне перемикання, обмеження швидкості та спостережуваність.

Як Techsy підходить до вибору сервера інференсу

Коли ми допомагаємо командам впроваджувати функції на основі LLM, вибір рушія інференсу зводиться до трьох питань:

1. До якого обладнання ви прив’язані? Якщо це Trainium або TPU, то це vLLM. Для всього іншого підходять обидва.
2. Яка форма вашого навантаження? Багатокрокові чати та цикли агентів схиляють до кешування префіксів у SGLang. Пакетна обробка та прості завершення добре працюють на обох.
3. Скільки операційних ресурсів у вас є? Більша спільнота vLLM означає більше відповідей на StackOverflow та Helm-чартів, коли щось ламається о третій ночі.

Ми запускали продакшен-навантаження на обох. Вони дійсно близькі. Правильна відповідь залежить від ваших обмежень, а не від того, що один із них «кращий» абстрактно.

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

Вибір інструменту — це легша половина. Змусити його надійно працювати всередині реального продукту — ось де більшість команд застрягають, і саме це наша команда AI-інтеграції будує для клієнтів, від пайплайнів RAG до кастомних агентів.

Поширені запитання

Чи SGLang швидший за vLLM?

На менших моделях (7B–8B) SGLang демонструє приблизно на 29% вищу пропускну здатність на GPU H100. На моделях 70B+ розрив звужується до 3–5%. SGLang також має нижчу хвостову затримку (TTFT p95) на всіх перевірених рівнях конкурентності.

Чи можна використовувати vLLM та SGLang із форматом API OpenAI?

Так. Обидва надають ендпоінти, сумісні з OpenAI, «з коробки». Ви можете замінити один на інший без зміни коду клієнта. Ваші виклики /v1/chat/completions працюють ідентично на обох.

Чому Hugging Face застаріла TGI?

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

Чи підтримує SGLang GPU NVIDIA та AMD?

SGLang підтримує GPU NVIDIA (A100, H100, H200, B200) та GPU AMD (MI300X через ROCm). Він не підтримує GPU Intel, AWS Trainium, Inferentia або Google TPU. vLLM має ширше покриття обладнання.

Що таке RadixAttention і чому це важливо?

RadixAttention — це механізм кешування префіксів у SGLang. Він зберігає записи кешу KV у радекс-дереві, індексованому на рівні токенів, автоматично виявляючи спільні префікси між запитами. Це робить багатокрокові діалоги та пайплайни RAG значно швидшими, оскільки повторюваний контекст не потрібно перераховувати.

Який рушій кращий для структурованих JSON-виводів?

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

Чи можна обслуговувати кілька адаптерів LoRA з однієї базової моделі?

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

Що таке розділене обслуговування prefill/decode?

Це означає запуск фази prefill (обробка промпту) на окремих GPU-воркерах від фази decode (генерація токенів). Prefill обмежений обчисленнями; decode обмежений пам’яттю. Їх розділення дозволяє масштабувати кожну фазу незалежно. Обидва рушії підтримують це, причому SGLang має більше опублікованих продакшен-результатів.

Як мігрувати з TGI на vLLM або SGLang?

Оскільки всі три надають API, сумісні з OpenAI, міграція — це здебільшого заміна контейнера. Перенаправте своє розгортання Docker Compose або Kubernetes на новий образ, налаштуйте прапорці завантаження моделі та оновіть ендпоінти перевірки стану. Код клієнта залишається тим самим.

Чи варто використовувати vLLM або SGLang для пайплайну RAG?

SGLang є сильнішим вибором для RAG. Його RadixAttention автоматично кешує та повторно використовує довгі системні промпти та контексти документів, які пайплайни RAG постійно надсилають. Кешування на рівні блоків у vLLM також працює, але ви побачите кращі показники влучень у кеш із підходом SGLang на рівні токенів, коли шматки документів дещо відрізняються між запитами.

Фінальний вердикт

SGLang перемагає в більшій кількості категорій, але переваги vLLM — широта підтримки обладнання та зрілість екосистеми — це ті речі, які мають значення о третій ночі, коли вузол виходить з ладу.

Якщо ви використовуєте обладнання NVIDIA і ваше навантаження включає багатокрокові діалоги, агентів із структурованими виводами або пайплайни RAG із спільними префіксами, почніть із SGLang. Ви отримаєте кращу пропускну здатність і нижчу затримку там, де це важливо.

Якщо вам потрібна гнучкість мультихмари, підтримка обладнання, відмінного від NVIDIA, або комфорт від найбільшої спільноти обслуговування LLM з відкритим кодом, почніть із vLLM. Це безпечніший варіант за замовчуванням, який добре служитиме більшості команд.

У будь-якому разі обидва рушії є відмінними та швидко вдосконалюються. Оберіть один, розгорніть його, виміряйте своє реальне навантаження та переключіться, якщо цифри підкажуть вам це. API, сумісний з OpenAI, робить це перемикання безболісним.

Джерела

• Бенчмарки Spheron H100: vLLM проти TensorRT-LLM проти SGLang
• PremAI: Бенчмарки vLLM проти SGLang проти LMDeploy
• SqueezeBits: Продуктивність керованого декодування на vLLM та SGLang
• RunPod: SGLang проти vLLM — повторне використання кешу KV
• Офіційна документація SGLang
• Офіційна документація vLLM