SGLang против vLLM: разница на реальной нагрузке

MAATRIX

Вы выбираете движок инференса под продакшн — не для одного личного чата, а под сервис, где одновременно висят десятки или сотни запросов, — и упираетесь в одну и ту же проблему: любая статья со сравнением vLLM и SGLang даёт готовую таблицу с цифрами токенов в секунду, а через полгода эти цифры устаревают вместе с версией движка. Разберём честно, в чём вообще разница в подходах этих двух серверов, и как получить актуальный для вашего конкретного случая ответ самостоятельно, а не переписывать чужой бенчмарк.

Что объединяет vLLM и SGLang и почему это не KoboldCpp

Первое, что стоит понять: vLLM и SGLang — это не конкуренты условному «локальному чату для одного пользователя». Это специализированные серверные движки инференса, спроектированные под один и тот же сценарий — обслуживание множества одновременных запросов с максимальной пропускной способностью GPU. Если вам нужно просто пообщаться с моделью на своей машине или на одном VPS с редкими запросами, разница между ними не будет заметна вообще — там определяющим фактором станет что-то другое: удобство интерфейса, поддержка форматов GGUF, простота установки.

Разница между vLLM и SGLang проявляется именно тогда, когда на сервер одновременно прилетает не один запрос, а десять, пятьдесят, двести. В этот момент вступают в игру две группы оптимизаций, которые оба движка реализуют по-своему:

1. Управление памятью GPU для параллельной обработки. Каждый одновременный запрос требует своего KV-кэша — промежуточного состояния внимания модели по уже сгенерированным токенам. Наивная реализация выделяет память под KV-кэш кусками фиксированного размера с запасом «на всякий случай», и на десятках параллельных сессий видеопамять кончается задолго до того, как GPU реально загружен вычислениями. Оба движка решают эту проблему похожими по духу, но разными по реализации механизмами постраничного (paged) управления памятью — идея близка к виртуальной памяти в операционных системах: кэш разбивается на блоки фиксированного размера, которые выделяются и освобождаются по требованию, а не резервируются заранее на весь возможный контекст.

1. Батчинг запросов ради пропускной способности. GPU эффективен, когда над одной операцией работает много данных одновременно. Если обрабатывать запросы по одному, видеокарта простаивает между операциями, ожидая следующий токен. Оба движка группируют одновременные запросы в батчи и умеют делать это динамически — непрерывно (continuous batching): новый запрос подхватывается в уже идущий батч, а завершившийся — выбрasывается из него, без ожидания, пока весь батч целиком не закончит генерацию.

Это общий класс архитектурных решений. Дальше начинаются различия — не в том, «что из этого работает», а в том, как именно каждый движок реализует эти идеи, какие у него внутренние структуры планировщика, и на каких паттернах нагрузки эти различия дают о себе знать.

В чём принципиальная разница подходов

vLLM исторически принёс в индустрию идею PagedAttention — постраничного управления KV-кэшем, которое легло в основу целого класса движков (в том числе повлияло и на архитектуру SGLang). Вокруг vLLM выросла одна из самых широких экосистем интеграций: он используется как референсный бэкенд во множестве фреймворков оркестрации, у него обширная поддержка форматов моделей и квантизаций, активное сообщество и частые релизы.

SGLang выделяется собственным подходом к планированию выполнения программ инференса — его RadixAttention нацелен на переиспользование префиксов KV-кэша между запросами с общим началом (например, одинаковый системный промпт у множества параллельных сессий чат-бота). Идея в том, чтобы не пересчитывать одно и то же начало контекста заново для каждого нового запроса, если оно совпадает с уже обработанным. SGLang также предлагает собственный DSL (язык описания) для построения сложных цепочек генерации — с ветвлением, параллельными вызовами модели внутри одного логического запроса — что делает его интересным выбором не только как голый inference-сервер, но и как рантайм под сложные агентные пайплайны.

Обе идеи — PagedAttention и RadixAttention — не взаимоисключающие. Оба проекта наблюдают друг за другом и постепенно заимствуют удачные решения оппонента, поэтому граница между «что умеет один, а другой нет» на конец августа 2026 года куда более размыта, чем была два-три года назад, когда движки только появились.

Здесь стоит сослаться на общую механику, о которой мы писали в контексте одного длинного диалога, а не множества параллельных сессий: принцип эффективного управления памятью для контекста разобран в статье про контекстное окно и память — там KV-кэш рассматривается применительно к одному растущему контексту. В продакшн-сценарии с vLLM и SGLang задача другая: не один длинный контекст, а множество одновременных, часто более коротких контекстов, конкурирующих за одну и ту же видеопамять GPU. Конкретная реализация — paged-блоки у одного движка, radix-дерево с переиспользованием префиксов у другого — и определяет, кто эффективнее использует память именно в вашем случае.

Почему нельзя просто взять готовое сравнение из интернета

Три причины, по которым любое найденное в сети «SGLang быстрее vLLM на X%» стоит воспринимать с большой осторожностью, а не как готовый вердикт:

Версии движков меняются быстрее, чем статьи. Оба проекта выпускают релизы с новыми оптимизациями планировщика, поддержкой новых форматов квантизации, изменениями в дефолтных параметрах батчинга каждые несколько недель. Бенчмарк полугодовой давности сравнивал версии, которых уже не существует в проде — с тех пор могли поменяться и алгоритмы, и дефолтные настройки, и даже то, какой из движков лидирует на конкретном типе нагрузки.

Тестовое железо и модель — не ваши. Публичные бенчмарки чаще всего гоняются на одной определённой видеокарте (обычно топовой, вроде H100) с одной определённой моделью на одном определённом наборе синтетических запросов. Если у вас другая карта, другая модель, другая длина промптов — цифры из чужого теста не переносятся на вашу конфигурацию напрямую, потому что узкое место (bottleneck) в системе может быть принципиально другим: где-то упирается видеопамять, где-то — пропускная способность памяти карты, где-то — сеть.

Синтетическая нагрузка не похожа на вашу реальную. Большинство публичных тестов гоняют одинаковые по длине запросы с одинаковым темпом поступления. Реальный продакшн так не выглядит почти никогда.

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

Это ключевой пункт, который решает больше, чем выбор конкретного движка. Прежде чем сравнивать vLLM и SGLang, опишите для себя реальный профиль нагрузки — от этого зависит, какая из оптимизаций каждого движка сыграет, а какая останется незамеченной:

• Много коротких запросов против немногих длинных. Чат-бот с короткими репликами создаёт совсем другую картину использования KV-кэша, чем сервис суммаризации документов, где каждый запрос — это несколько тысяч токенов контекста. Оптимизации переиспользования префикса дают эффект именно тогда, когда у запросов есть общая часть (общий системный промпт, общий шаблон инструкции) — на полностью разнородных по содержанию запросах этот выигрыш обнуляется.
• Равномерная нагрузка против пиковой. Сервис с ровным потоком запросов в течение суток ведёт себя иначе, чем сервис, где 90% трафика прилетает в узкое окно (например, рабочие часы одного часового пояса). Динамический батчинг у обоих движков рассчитан на пики, но эффективность конкретного планировщика на резком всплеске параллельных сессий — это то, что стоит проверить именно на инструменте нагрузочного тестирования, симулирующем ваш реальный трафик, а не на равномерном потоке одинаковых запросов.
• Длина генерируемого ответа. Запросы с коротким ответом (классификация, извлечение сущности) заканчиваются быстро и освобождают слот в батче почти сразу. Запросы с длинной генерацией (написание текста, код) держат слот дольше — при высокой параллельности это быстрее упирается в лимит видеопамяти, и то, насколько экономно движок укладывает KV-кэш, становится заметнее.

Составьте для себя таблицу-профиль вашей нагрузки прежде, чем открывать документацию любого из движков:

Совместимость с моделью и квантизацией — проверяйте отдельно

Второй фактор, который решает выбор чаще, чем абстрактная «скорость» — поддерживает ли движок именно вашу модель и именно нужный вам формат квантизации. Оба проекта развиваются быстро, и на момент публикации этой статьи ситуация с поддержкой конкретных архитектур (Mixture-of-Experts, мультимодальные модели, новые семейства весов) и форматов (AWQ, GPTQ, FP8, INT4 и другие) у vLLM и SGLang может отличаться — причём в любую сторону, в зависимости от того, какая команда быстрее добавила поддержку конкретной новинки.

Проверять это стоит не по статьям сравнения (они устаревают за недели), а напрямую:

# Актуальный список поддерживаемых архитектур моделей —
# смотрите в официальной документации на момент выбора,
# а не в кэше поисковика:
# vLLM: раздел supported models в docs.vllm.ai
# SGLang: раздел supported models в docs.sglang.ai

# Практическая проверка — попытка запуска с вашей моделью
# и вашим форматом квантизации на тестовом окружении:
vllm serve /path/to/your-model --quantization awq --max-model-len 8192

sglang.launch_server --model-path /path/to/your-model --quantization awq

Если сервер стартует и отвечает на тестовый запрос без ошибок о неподдерживаемой архитектуре или неизвестном формате весов — совместимость подтверждена практически, а не по чужому обещанию из README. Про частые ошибки старта vLLM на этой стадии мы отдельно разбирали в статье про установку и настройку vLLM на VPS — многие из этих граблей (несовпадение версии CUDA, драйвера, формата чекпоинта) актуальны и для SGLang, потому что оба движка используют схожий стек PyTorch/CUDA под капотом.

Зрелость экосистемы меняется быстрее, чем кажется

Третий фактор — который сложнее всего зафиксировать в статье надолго, потому что он буквально меняется неделя от недели: активность разработки, размер сообщества, качество документации, скорость реакции на баг-репорты. На конец августа 2026 года оба проекта — vLLM и SGLang — активно развиваются, оба принимают вклад от крупных лабораторий и облачных провайдеров, у обоих регулярный цикл релизов.

Что стоит проверить непосредственно перед принятием решения, а не полагаться на репутацию годичной давности:

• Дата последнего релиза и частота коммитов в основной ветке репозитория на GitHub.
• Открытые issue, помеченные как критические баги, и как быстро они закрываются.
• Есть ли в changelog последних релизов упоминание вашей модели, вашего формата квантизации, вашего сценария (например, поддержка нужного вам параллелизма — tensor parallelism, pipeline parallelism).
• Активность в официальном канале сообщества (Discord/Slack проекта) — насколько быстро там отвечают на вопросы по продакшн-эксплуатации, а не только по установке.

Устаревшее сравнение двухлетней давности могло застать один из проектов на ранней стадии, с урезанным набором функций — за прошедшее время расклад мог полностью перевернуться.

Как честно замерить оба варианта на своей нагрузке

Единственный способ получить ответ, который останется верным именно для вас, — прогнать оба движка через один и тот же сценарий, максимально приближенный к реальному профилю вашего трафика. Подход методически похож на честное измерение производительности диска, которое мы разбирали в статье про fio: там ключевая мысль в том, чтобы тестировать не абстрактным синтетическим паттерном, а тем, который реально соответствует вашей нагрузке (случайное чтение мелкими блоками вместо последовательной записи, если у вас база данных, а не архив). Для инференса LLM принцип тот же — синтетический бенчмарк на равномерном потоке одинаковых по длине запросов может дать один победитель, а ваш реальный трафик с пиками и разной длиной промптов — другой.

Практический план собственного бенчмарка:

1. Соберите репрезентативный набор запросов. Не сто одинаковых промптов — а выборка из реальных логов (если сервис уже работает) или максимально честная имитация ожидаемого профиля: распределение длин промптов, распределение длин ответов, доля запросов с общим префиксом.
2. Разверните оба движка на одинаковом железе. Одна и та же видеокарта, одна и та же модель, один и тот же формат квантизации — иначе сравнение бессмысленно с самого начала.
3. Нагружайте параллельными запросами, а не последовательными. Инструмент нагрузочного тестирования должен слать запросы с той же конкурентностью, что и ожидаемый пик реального трафика — иначе вы измеряете задержку одного запроса, а не пропускную способность под нагрузкой, что для этих движков принципиально разные вещи.
4. Снимайте не только среднюю задержку, но и хвостовые перцентили (p95, p99). Под реальной нагрузкой именно хвостовые задержки чаще всего определяют субъективное качество сервиса для пользователей — движок со средней задержкой ниже, но с более длинным хвостом на пике, может проигрывать в реальном опыте.
5. Повторите тест на нескольких профилях нагрузки, а не на одном — если у вас бывают и равномерный дневной трафик, и резкие пики, проверьте оба сценария отдельно, потому что победитель может смениться между ними.
6. Зафиксируйте версии обоих движков, драйвера CUDA и модели на момент теста — чтобы результат можно было воспроизвести и пересмотреть при следующем крупном релизе любого из движков.

Такой тест занимает день-два, но даёт ответ, который относится именно к вашей нагрузке — а не к синтетическому сценарию из чужой статьи, написанной для другой модели на другой видеокарте.

Частые вопросы