vLLM vs SGLang: какой движок выбрать для агентов и RAG

vLLM vs SGLang: какой движок выбрать?

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

Если вы обслуживаете много коротких диалогов, общий системный промпт — повод протестировать SGLang, но не повод отказываться от vLLM. Оба движка умеют повторно использовать результаты обработки промпта. Если вы запускаете простой API и времени на инфраструктуру мало, начните с vLLM. Менять его стоит лишь после того, как подтверждён выигрыш в качестве обслуживания или затратах.

RAG, или генерация с дополнением из найденных источников, добавляет извлечённые документы в промпт модели. Кэширование префиксов приносит пользу благодаря повторяющемуся началу промпта, а не самому наличию RAG.

Дата проверки: 14 октября 2026 года. Последними стабильными версиями, найденными при подготовке статьи, были vLLM 0.31.0 от 5 октября и SGLang 0.5.21 от 2 октября. Описание возможностей ниже опирается на актуальную документацию проектов; нужное сочетание функций проверьте на закреплённой у вас версии. Бенчмарки инференса для этого сравнения не запускались.

Лицензии проверены по лицензии vLLM и репозиторию SGLang. Лицензии на веса моделей, инфраструктура и работа инженеров — отдельные статьи расходов. У самих открытых движков нет тарифа на облачное обслуживание с оплатой за токены, который можно было бы сравнить.

Что умеют движки и где проходят их ограничения

vLLM: базовый выбор для обслуживания моделей

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

Начать с vLLM удобно благодаря понятному составу развёртывания: модель, официальный серверный образ, API и отдельные инструкции по установке на нужную платформу. Для продуктовой команды, которая создаёт API для поддержки клиентов, это управляемая отправная точка для оценки пропускной способности.

Главное ограничение — необходимость проверить конфигурацию целиком. Совместимая GPU — только начало: архитектура модели, квантизация, бэкенд внимания и нужные функции должны работать вместе. Для сервисов оценки важно конкретное исключение в работе кэша: по документации vLLM, запрос логарифмов вероятностей токенов промпта обходит кэш префиксов и запускает обработку промпта заново. Поэтому API оценки может вести себя иначе, чем чатовый API с тем же документом. Руководство по vLLM V1

Движок стоит $0. Выбирайте его для универсального обслуживания моделей и разнородного парка оборудования. Переходить на него с работающего SGLang незачем, если тот уже обеспечивает нужное качество обслуживания и в нём есть все необходимые возможности.

SGLang: с чего начать при повторяющемся контексте агентов

SGLang — открытый фреймворк инференса для языковых и мультимодальных моделей; среди его заявленных приоритетов — задачи ИИ-агентов. RadixAttention организует повторно используемое состояние промптов вокруг общих префиксов. Расширение HiCache добавляет за кэшем GPU уровни оперативной памяти хоста и хранилища. На практике привлекает документированный набор средств, позволяющих сохранять контекст и повторно использовать его в последующих запросах. Репозиторий SGLang, устройство HiCache

Представьте агента, который снова и снова читает один и тот же регламент поддержки, а затем обрабатывает разные вопросы клиентов. Это более веский повод проверить SGLang, чем просто множество одновременных запросов с несвязанными промптами.

Ограничения — локальность кэша и различия в возможностях бэкендов. Уровни HiCache в памяти GPU и оперативной памяти хоста принадлежат конкретному экземпляру сервера инференса. Хранилище становится общим только при соответствующей настройке выбранного бэкенда. Увеличение кэша в памяти хоста само по себе не создаёт общий кэш для всего парка серверов. Дополнительные уровни также требуют планирования памяти, передачи данных и сопровождения конфигурации. Границы совместного использования HiCache

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

Кэширование префиксов и RadixAttention: почему стоит сначала проверить SGLang

SGLang стоит проверять первым при ветвящихся запросах с повторяющимся контекстом; базовые возможности кэширования уже есть и у vLLM. Нельзя противопоставлять PagedAttention самой возможности кэшировать. PagedAttention отвечает за организацию памяти, а кэширование префиксов — за повторное использование вычислений. Automatic Prefix Caching в vLLM прямо рассчитан в том числе на повторные вопросы по длинным документам и многошаговые диалоги. Кэширование префиксов в vLLM

Prefill — обработка промпта до начала генерации. Decode — генерация новых токенов. Попадание в кэш позволяет избежать повторного prefill, но не отменяет decode: новый ответ всё равно нужно сгенерировать. Поэтому для длинного ответа при небольшом объёме общего входного контекста повторное использование префиксов может дать мало пользы в любом из движков.

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

Для RAG с длинным контекстом нужен ещё один вопрос: контекст пригоден для повторного использования или он просто длинный? Повторные вопросы по неизменному руководству хорошо подходят для кэширования. В поисковом продукте, который для каждого запроса собирает разные фрагменты в разном порядке, общим может остаться лишь короткий системный префикс. Измеряйте эти сценарии отдельно, прежде чем вкладываться в иерархическое хранилище.

По документации SGLang, RadixAttention включён по умолчанию; отключением управляет --disable-radix-cache. HiCache настраивается отдельно. В любом движке проверяйте фактически применённую конфигурацию, а не судите о поведении кэша по названию проекта. Параметры сервера SGLang

Возможности для агентов: паритет по JSON, проверка адаптеров и черновых моделей

Сама по себе потребность в JSON не даёт преимущества ни одному движку. Оба поддерживают генерацию с ограничениями по схеме. Пусть модель выбирает значения, но структуру ограничивайте, а результат проверяйте до выполнения действия.

Структурированный вывод JSON

vLLM поддерживает JSON Schema через response_format и параметры structured_outputs. У SGLang тоже есть поддержка JSON Schema; бэкендом грамматических ограничений по умолчанию служит XGrammar. Это ограничения на этапе декодирования, а не просто просьба к модели «вернуть JSON». Структурированный вывод в vLLM, структурированный вывод в SGLang

Для агента поддержки схема может требовать указать действие и идентификатор обращения. Но она не установит, принадлежит ли обращение пользователю, который отправил запрос, и обоснованно ли выбранное действие. Эти проверки должны оставаться в коде приложения. Проверяйте реальные схемы, режим рассуждения и потоковую выдачу совместно: поддержка каждого из этих компонентов по отдельности ещё не доказывает, что нужное сочетание работает корректно.

Итог: для обычных задач с JSON — паритет. Оставайтесь на уже используемом движке, пока запросы с характерными для вашего приложения схемами не выявят конкретную разницу.

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

В обоих проектах спекулятивное декодирование — способ настройки производительности, а не гарантия ускорения. Черновой механизм предлагает токены, а целевая модель проверяет их. Удачные предложения, которые проходят проверку, могут сократить объём последовательной генерации; при этом подготовка черновика, проверка и использование памяти тоже имеют цену.

В документации vLLM описаны EAGLE, предсказание нескольких токенов, отдельные черновые модели, методы на основе n-грамм и суффиксов. SGLang также документирует EAGLE, предсказание нескольких токенов, черновые модели и NGRAM. Совместимость чернового механизма, целевой модели, оборудования и интенсивности нагрузки важнее отметки о наличии функции. Методы vLLM, методы SGLang

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

Multi-LoRA: настройка поведения под отдельных клиентов

Оба движка умеют обслуживать несколько LoRA-адаптеров — небольших добавок к весам, полученных при дообучении и меняющих поведение общей базовой модели. vLLM регистрирует адаптеры через --lora-modules и позволяет ограничивать число одновременно используемых адаптеров и их ранг. В SGLang есть --lora-paths и --max-loras-per-batch; документированное значение по умолчанию — 8 адаптеров на батч. Это не ограничение на общее число клиентов. LoRA в vLLM, LoRA в SGLang

Для сервиса генерации текстов с настройками под каждого клиента проверяйте ожидаемое распределение запросов по адаптерам, включая ещё не загруженные адаптеры и частые переключения. Опция перекрытия загрузки с вычислениями в SGLang может скрыть время передачи данных. Но документация также предупреждает, что она может уменьшить возможности объединения prefill в батчи для нескольких адаптеров и увеличить время до первого токена. Больше настроек не означает автоматически больше пропускной способности.

Лучший выбор — движок, работу с адаптерами в котором вы уже проверили. Одной поддержки multi-LoRA недостаточно для перехода. SGLang стоит протестировать, если узкое место — загрузка адаптеров или нагрузка, сильно зависящая от кэша. Для TPU сверяйтесь с матрицей возможностей самого бэкенда: в руководстве SGLang-JAX multi-LoRA всё ещё отмечен как функция в разработке. Матрица возможностей SGLang для TPU

Поддержка оборудования: для разнородного парка начните с vLLM

Оба проекта заявляют поддержку NVIDIA, AMD, TPU и CPU. Реальные границы поддержки определяет сочетание бэкенда и модели. Общий список оборудования проекта не гарантирует, что любая конфигурация GPU, адаптер или метод декодирования переносится без изменений.

• NVIDIA: у vLLM есть инструкции по установке на GPU с CUDA; репозиторий SGLang перечисляет семейства ускорителей для дата-центров и RTX. Образы текущей версии должны быть совместимы с драйвером хоста. Установка vLLM на GPU, список оборудования SGLang
• AMD: оба проекта документируют развёртывание с ROCm. SGLang перечисляет Instinct MI300X, MI325X, MI350X и MI355X и предлагает отдельное руководство по установке. Используйте совместимый образ ROCm и конфигурацию для нужной модели. Руководство SGLang для AMD
• Google TPU: vLLM отсылает к отдельной установке tpu-inference. Руководство SGLang для TPU использует отдельный бэкенд SGLang-JAX и перечисляет v6e и v7. Это самостоятельные варианты развёртывания, для которых нужно отдельно проверять набор возможностей. Установка vLLM на TPU, руководство SGLang для TPU
• CPU: среди вариантов для CPU vLLM документирует Intel/AMD x86 и ARM AArch64. Руководство по серверу SGLang на CPU ориентировано именно на Intel AMX в процессорах Xeon Scalable четвёртого поколения и новее. Формулировка «CPU поддерживаются» не означает одинаковый охват. Руководство vLLM для CPU, руководство SGLang для CPU

При следующем развёртывании решающим может оказаться конкретное различие: vLLM 0.31.0 выпускает образ с CUDA 12.9 наряду с основным образом на CUDA 13.0. Текущее руководство по установке SGLang требует CUDA 13 и указывает, что линейка образов с CUDA 12 закончилась на версии 0.5.19. Если ваш парк пока нельзя перевести на совместимые драйверы, разберитесь с этим до сравнения пропускной способности. Артефакты релиза vLLM, установка SGLang

OpenAI-совместимые серверы: перенести клиент проще, чем рабочую нагрузку

К обоим движкам можно подключить клиент, использующий chat completions в формате OpenAI. В документации обоих есть /v1/chat/completions и /v1/completions, поэтому часть интеграционного кода приложения менять не придётся. Однако это не делает взаимозаменяемыми все эндпоинты, расширения, парсеры вызовов инструментов и особенности поведения моделей. Сервер vLLM, API SGLang

Шаблон чата превращает сообщения с указанными ролями в последовательность токенов, которую ожидает модель. При сравнении движков сохраняйте этот шаблон. Иначе можно незаметно для себя сравнить два разных промпта. Версия модели, токенизатор, настройки сэмплирования и ограничение длины ответа тоже должны совпадать.

Если у вас уже есть клиент vLLM, перед миграцией или обновлением проверьте старые поля управления форматом вывода. Согласно документации, guided_json и связанные поля удалены в 0.12.0. Актуальный код должен использовать поддерживаемый формат structured_outputs или response_format. Устаревшее тело запроса легко принять за несовместимость движков. Примечание о миграции vLLM

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

Как запустить движки в облаке с GPU

Начните с контейнера закреплённой версии и небольшой модели для проверки запуска, затем подставьте рабочую модель и нужный объём памяти. Примеры ниже адаптируют документированные Docker-команды и команды запуска проектов для Linux-хоста с GPU NVIDIA, установленными Docker и NVIDIA container runtime, а также драйвером, совместимым с образом. Примеры сверены с документацией, но не запускались на арендованной GPU. Docker для vLLM, быстрый старт SGLang

Модель Qwen/Qwen3-0.6B ниже нужна для проверки связки компонентов. Это не рекомендация по качеству ответов вашего агента. Запускайте движки по очереди на одном и том же порту. Ограничение контекста здесь задано для примера и не равно заявленному максимуму модели.

Контейнер vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

Контейнер SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

После инициализации выполните этот запрос на хосте с GPU:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

В примерах порт хоста привязан к loopback-интерфейсу. Прежде чем открывать доступ удалённым пользователям, поставьте перед сервером шлюз приложения с аутентификацией. Для vLLM это особенно важно: в документации указано, что --api-key проверяет аутентификацию не на всех маршрутах HTTP-сервера. Область действия аутентификации vLLM

Готовый воркер vLLM в Runpod

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

Для SGLang описанный здесь воспроизводимый путь запуска в облаке — официальный контейнер на совместимом хосте с GPU. Упрощённый вариант Runpod выше относится именно к воркеру vLLM, который документирует Runpod.

Стоимость: одинаковые GPU обходятся одинаково

При одинаковом объёме арендованных ресурсов ни один движок не дешевле. На 14 октября 2026 года страница цен Runpod указывала для Pods тариф $1.79 в час за A100 PCIe с 80 GB памяти. Это цена выделенной GPU, а не тариф воркера Serverless. Именно её используем как общую стоимость инфраструктуры в расчёте ниже. Цены Runpod

Если принять для бюджета 730 часов в месяце, одна постоянно выделенная GPU стоит $1,306.70 в месяц и с vLLM, и с SGLang. Две — $2,613.40 в месяц. В эти суммы не входят хранилище, сетевые расходы, резервирование и работа инженеров.

Возьмём одинаковую условную нагрузку службы поддержки: 50,000 запросов в месяц, в каждом — 2,000 входных и 200 выходных токенов. Получаем 100 миллионов входных и 10 миллионов выданных выходных токенов. Если такая нагрузка помещается на одну GPU при нужном времени ответа, расходы на GPU у любого из движков составят $0.13067 на 1,000 выданных выходных токенов. В знаменателе — выходные токены, хотя оплаченные ресурсы также обрабатывают входные.

Это расчёт затрат, а не замер пропускной способности. Если одна GPU не справляется с нагрузкой, результат для одной GPU неприменим.

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

При бюджете миграции 8 часов и условной ставке $100 в час переход обойдётся в $800. Отказ от одной такой GPU окупит его примерно за 0.61 месяца, без учёта разницы в дальнейшей эксплуатации. Если не удаётся убрать реплику или получить улучшение сервиса, которому можно присвоить денежную ценность, «быстрее» может вообще не дать финансового результата.

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

Производительность: сколько полезной работы укладывается в допустимую задержку

Это сравнение vLLM и SGLang не определяет универсального победителя по пропускной способности. Опубликованный проектом результат относится к конкретной модели, оборудованию, точности вычислений, длинам запросов и версии. Ускорение вычислительного ядра не равно ускорению всей системы обслуживания запросов, а скорость prefill не равна скорости выдачи выходных токенов. Ни то ни другое не оправдывает общий вывод «SGLang быстрее» или «vLLM быстрее».

Начните с инструментов самих проектов: CLI для бенчмарков vLLM и руководства по бенчмаркам обслуживания запросов SGLang. Для сравнения нужны прогоны и с прогретым, и с холодным кэшем, а также профиль нагрузки вашего продукта.

Отдельно измерьте четыре сценария: короткие диалоги с неизменным общим системным промптом; повторные вопросы по одному длинному документу; длинные RAG-промпты с меняющимися найденными фрагментами; реальное сочетание схем вывода, вызовов инструментов и адаптеров. Сохраняйте не только число одновременных запросов, но и время их поступления. Одновременный всплеск и равномерный поток могут выявить разные узкие места.

Фиксируйте завершённые запросы, выданные выходные токены, ошибки и время до первого токена. Также смотрите на задержки p95 и p99 — 95-й и 99-й перцентили: хорошее среднее значение может скрывать очень медленные ответы в хвосте распределения. Ответы, не прошедшие проверки схемы или корректности в приложении, считайте ошибками, а не полезной пропускной способностью.

Побеждает самое дешёвое развёртывание, которое укладывается в заданные критерии приёмки. Заявление о скорости на другой модели или старой версии — повод провести такое сравнение, а не готовый ответ.

Как сменить движок: сохранить контракт и возможность отката

Меняйте слой обслуживания моделей, только если измеренная выгода превышает расходы на миграцию и эксплуатацию. Если меняется лишь бэкенд генерации, данные приложения и хранилище для поиска обычно можно оставить на месте. Основная работа связана с упаковкой модели, расширениями запросов, разбором ответов и поведением системы при развёртывании.

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

Если вы пока не решили, нужен ли вам вообще общий сервер моделей для рабочего сервиса, прочитайте сравнение Ollama и vLLM. Оно посвящено предыдущему этапу выбора: удобной локальной работе с моделью или серверному обслуживанию одновременно поступающих запросов.

Следующий шаг: запишите характерный пиковый трафик, задайте максимально допустимое время ответа и долю ошибок, затем сравните закреплённые версии движков на одном оборудовании. И только после этого расширяйте парк серверов.

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

Используйте чек-лист аудита бизнес-процессов для внедрения ИИ, чтобы определить, какому процессу нужен общий сервер моделей, и подпишитесь на рассылку, чтобы следить за дальнейшими изменениями инструментов.