vLLM, SGLang и TGI: выбор inference-сервера для GPU VDS

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

vLLM, SGLang и Hugging Face Text Generation Inference (TGI) решают одну базовую задачу: загружают модель на GPU, принимают запросы по HTTP, формируют очереди, управляют KV cache и возвращают результат клиенту. При этом vLLM обычно выбирают как универсальную основу для OpenAI-совместимого API, а SGLang особенно интересен для нагрузки с повторяющимися префиксами, агентных сценариев и сложных схем генерации. TGI прежде всего имеет смысл оценивать в контексте уже работающих интеграций и их конкретной версии.

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

В статье рассматривается серверный инференс генеративных и мультимодальных моделей на виртуальных машинах с NVIDIA GPU. Обучение, дообучение и инференс только на CPU остаются за рамками.

Краткий вывод

• vLLM — универсальный вариант для команд, которым нужны широкий выбор моделей, развитый OpenAI-совместимый API, предсказуемое развёртывание и несколько схем параллелизма.
• SGLang — сильный кандидат для систем с повторяющимися префиксами, длинными диалогами, reasoning-моделями, агентными сценариями и высокой конкуренцией запросов. Он предоставляет много инструментов оптимизации, но требует внимательного подбора настроек под модель и нагрузку.
• TGI — вариант для существующих интеграций, если зафиксированная версия безопасна, поддерживает нужную модель и стабильно выполняет SLO. Для нового проекта его возможности и перспективы сопровождения нужно отдельно подтвердить.

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

Что сравнивает команда

На одиночном тестовом запросе различия между движками могут быть небольшими. Они становятся заметнее при одновременной работе пользователей с разной длиной промптов и ответов. Сервер должен планировать prefill входного контекста и decode новых токенов, не допуская неконтролируемого роста очереди и расхода VRAM.

Для GPU VDS особенно важны следующие критерии:

1. совместимость API с приложением и его SDK;
2. эффективность continuous batching при переменной нагрузке;
3. расход и повторное использование KV cache;
4. работа на одной или нескольких NVIDIA GPU;
5. доступные форматы весов и квантования;
6. метрики, диагностика и поддержка нужных моделей;
7. жизненный цикл проекта, контейнеров и зависимостей.

Сравнивать только количество токенов в секунду недостаточно. Сервер с высоким максимальным throughput может проиграть по времени до первого токена или давать резкие хвостовые задержки при заполнении очереди. Для инфраструктуры, рассчитанной на регулярное обновление моделей и оборудования, имеет значение поддержка новых архитектур и воспроизводимость обновлений.

Сравнение vLLM, SGLang и TGI

Таблица задаёт направление выбора, но не заменяет проверку конкретной модели. Один и тот же формат квантования может использовать разные ядра на разных поколениях GPU, а новая архитектура модели иногда сначала полноценно работает только в одном движке.

Совместимость с OpenAI API

OpenAI-совместимый API позволяет направить существующий клиент на собственный сервер, изменив базовый адрес и параметры аутентификации. Это упрощает миграцию приложений, использующих Chat Completions, потоковую выдачу и стандартную структуру сообщений.

Совместимость не означает полной идентичности облачному API. Отдельные параметры могут игнорироваться, отсутствовать или иметь особенности реализации. Поддержка tool calling, reasoning-полей, мультимодального контента и structured output зависит не только от сервера, но и от конкретной модели, её chat template и выбранного parser.

vLLM

vLLM предоставляет широкий API-контур. Для текстовых LLM доступны Completions, Chat Completions и Responses API. Сервер также может предоставлять отдельные интерфейсы для embeddings, аудиомоделей, классификации и reranking, если загруженная модель поддерживает соответствующую задачу.

Для chat-запросов необходим корректный шаблон диалога. Если в репозитории модели нет chat template, его придётся передать серверу отдельно. Иначе загрузка весов может пройти успешно, но запрос к /v1/chat/completions завершится ошибкой. Следует также проверять, не переопределяет ли файл generation_config.json sampling-параметры по умолчанию.

SGLang

SGLang поддерживает OpenAI-совместимые Chat Completions и Completions, потоковую генерацию, embeddings и мультимодальные запросы для подходящих моделей. Сильная сторона платформы — расширения для reasoning-моделей, structured output и вызова инструментов. Многие из них требуют указать соответствующий parser или параметры шаблона при запуске.

Это даёт больше контроля, но усложняет стандартизацию. Если команда обслуживает несколько семейств моделей, конфигурацию нужно тестировать для каждого из них: одинаковый клиентский запрос ещё не гарантирует одинаковую структуру reasoning- или tool-call-ответа.

TGI

TGI предоставляет Messages API, совместимый с форматом Chat Completions, а также интерфейс обычных completions. Для существующих интеграций этого может быть достаточно. API-контракт нужно рассматривать как набор возможностей конкретной версии: перед обновлением SDK, модели или контейнера проверяйте поведение приложения на контрактных тестах.

При миграции с TGI на vLLM или SGLang тесты должны проверять HTTP-коды, streaming chunks, поля usage, stop sequences, tool calls и поведение при превышении контекста. Формально совместимый маршрут не исключает различий в деталях ответа.

Continuous batching и профиль нагрузки

Статический batch ожидает накопления заданного числа запросов и обрабатывает их совместно. Для интерактивного API это неудобно: запросы приходят неравномерно, имеют разную длину и заканчиваются в разное время. Continuous batching позволяет добавлять новые последовательности и освобождать завершённые непосредственно в ходе работы сервера.

Все три движка реализуют continuous batching. Разница проявляется в алгоритмах планирования, разбиении prefill на части, управлении памятью и взаимодействии с prefix cache.

vLLM хорошо подходит для смешанного потока запросов и располагает развитым планировщиком. Chunked prefill помогает распределять вычислительный бюджет между длинными входными контекстами и decode уже выполняющихся запросов.

SGLang также рассчитан на динамическое формирование батчей. Его преимущества могут быть заметнее, когда запросы содержат общие префиксы: системные инструкции, документы, few-shot-примеры или историю одной сессии.

TGI поддерживает continuous batching в поддерживаемых конфигурациях. При его оценке важны реальные лимиты очереди, размер батча, максимальная длина входа и поведение при длительном prefill.

Увеличение размера батча не гарантирует улучшения сервиса. Оно обычно повышает суммарную пропускную способность, но может ухудшить время до первого токена. Настройка должна исходить из SLO: чат чаще требует низкой задержки, тогда как фоновая генерация может обменять latency на throughput.

KV cache и повторяющиеся префиксы

Во время генерации модель сохраняет key и value для уже обработанных токенов. Без KV cache ей пришлось бы повторно вычислять attention для всей предыдущей последовательности на каждом шаге. Кэш ускоряет decode, но занимает значительную часть VRAM, особенно при длинном контексте и высокой конкуренции.

Важно различать обычный KV cache активного запроса и prefix caching. Первый нужен почти всегда. Второй позволяет повторно использовать уже вычисленный кэш, когда новый запрос начинается с той же последовательности токенов.

vLLM: PagedAttention и блочное управление

vLLM использует PagedAttention и размещает KV cache блоками, снижая потери памяти из-за резервирования непрерывных областей под последовательности разной длины. Automatic Prefix Caching сопоставляет блоки и переиспользует совпадающие префиксы.

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

SGLang: RadixAttention

RadixAttention организует кэш префиксов в структуре, рассчитанной на поиск и повторное использование общих последовательностей. Это особенно полезно для многошаговых агентов, ветвящихся диалогов, few-shot prompting и запросов к одному большому документу.

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

Длинный контекст и расход VRAM

Квантование весов не обязательно уменьшает KV cache. Если веса загружены в 4-битном формате, кэш может по-прежнему храниться в FP16, BF16, FP8 или другом типе, выбранном движком. Поэтому модель, которая легко помещается в память без нагрузки, может получить OOM при нескольких длинных запросах.

При расчёте GPU VDS нужно учитывать одновременно:

• веса модели и служебные буферы;
• KV cache для заданной длины контекста и concurrency;
• временную память attention- и GEMM-операций;
• CUDA graphs и внутренние пулы движка;
• запас на фрагментацию и отклонения реальной нагрузки.

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

Несколько GPU и tensor parallelism

Tensor parallelism делит слои и матричные операции одной модели между несколькими GPU. Он нужен, когда веса и рабочая память не помещаются на одном ускорителе либо одна GPU не обеспечивает требуемую скорость.

vLLM, SGLang и TGI могут поддерживать tensor parallelism, но возможные схемы и ограничения отличаются по моделям и версиям. У vLLM и SGLang доступны дополнительные режимы распределённого исполнения. Для TGI необходимо проверять возможности используемой версии и конкретной архитектуры модели.

На виртуальной машине важно убедиться, что все GPU доступны внутри одного экземпляра и корректно работают через NCCL. Производительность зависит от топологии: быстрый прямой обмен между ускорителями выгоднее связи только через PCIe. Виртуализация не должна скрывать критичные возможности peer-to-peer или создавать нестабильность при коллективных операциях.

Tensor parallelism имеет цену: после распределённых операций ускорители обмениваются данными. Если модель помещается в одну GPU, две независимые реплики за балансировщиком иногда дают больший совокупный throughput, чем одна TP-конфигурация на двух GPU. TP чаще оправдан для модели, которая иначе не помещается, или когда приоритетом является задержка одного крупного запроса.

Для такого развёртывания нужен VPS-сервер с GPU, на котором все необходимые ускорители доступны в одной виртуальной машине. Перед арендой проверьте модель и объём памяти каждой GPU, число ускорителей, тип межсоединения, доступность Docker с NVIDIA Container Toolkit, поддерживаемые драйверы, объём RAM и скорость локального хранилища для загрузки весов.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Квантование: экономия памяти без универсального рецепта

Квантование снижает точность представления весов, уменьшая их размер и объём обмена с памятью. Оно может позволить разместить более крупную модель или увеличить пространство под KV cache. Но более низкая разрядность не гарантирует большего числа токенов в секунду: результат зависит от наличия оптимизированного ядра для формата и GPU.

vLLM поддерживает широкий набор методов, включая разные FP8- и INT-сценарии, AWQ, GPTQ и compressed-tensors. SGLang также работает с распространёнными квантованными checkpoint и предоставляет параметры выбора метода. В обоих случаях совместимость определяется архитектурой модели, поколением GPU, backend и версией движка.

Для TGI матрицу совместимости следует проверять по конкретной версии. Отдельный checkpoint может не поддерживать tensor parallelism, конкретную архитектуру GPU или нужное attention-ядро. Перед сохранением существующего контура необходимо проверить сочетание модели, формата весов, GPU, драйвера и параметров шардинга.

Сравнивать нужно готовые артефакты, а не только число бит. Предварительно квантованная модель с подходящими kernels часто предпочтительнее преобразования весов при каждом старте. После квантования необходимо проверить качество на собственном наборе запросов: средняя скорость не покажет деградацию structured output, tool calling, кода или рассуждений.

Поддержка NVIDIA GPU и эксплуатация

Все три сервера могут работать на NVIDIA GPU и используют CUDA-экосистему. В production должны быть согласованы драйвер хоста, CUDA runtime контейнера, PyTorch, NCCL, архитектура GPU и inference-сервер. Контейнер может включать пользовательские библиотеки CUDA, но драйвер остаётся частью хостовой системы. Слишком старый драйвер не исправляется установкой нового runtime внутри контейнера.

На новых поколениях GPU нельзя считать, что образ, работавший на предыдущей архитектуре, запустится без изменений. Возможны ошибки вида no kernel image is available, сбои при инициализации attention backend или переключение на менее производительную реализацию.

При переносе inference-сервиса на другую GPU это следует считать отдельным миграционным этапом. До переключения трафика проверьте запуск модели, корректность NCCL, доступный объём KV cache, скорость prefill и decode, а также стабильность на длительной нагрузке. Для зафиксированной версии любого движка такую проверку особенно важно проводить заранее.

Inference-сервер должен предоставлять метрики очереди, latency, токенов, использования кэша и ошибок. У vLLM, SGLang и TGI есть механизмы наблюдаемости, однако названия и детализация показателей различаются. Дашборды нельзя переносить между движками механически.

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

Как провести честный тест на своём GPU VDS

Публичный benchmark полезен для формирования шорт-листа, но не отвечает, какой сервер лучше для конкретного приложения. Тестировать нужно одинаковую модель, checkpoint, dtype или формат квантования, лимит контекста и набор sampling-параметров.

1. Подготовьте распределение запросов. Включите короткие чаты, длинные промпты, типичные ответы и крайние случаи. Если приложение работает с общим документом или системным промптом, сохраните эту повторяемость.
2. Разделите холодный и прогретый запуск. Время загрузки весов важно для перезапуска, но его не нужно смешивать со steady-state throughput.
3. Увеличивайте concurrency ступенчато. Проверяйте не только максимальную нагрузку, но и точку, после которой очередь начинает расти без восстановления.
4. Собирайте перцентили. Нужны p50, p95 и p99 для времени до первого токена и полной задержки, а не только среднее значение.
5. Измеряйте goodput. Считайте число запросов или токенов, уложившихся в SLO. Высокий throughput бесполезен, если значительная часть пользователей получает ответ слишком поздно.
6. Следите за памятью и ошибками. Фиксируйте VRAM, OOM, отклонённые запросы, перезапуски worker и тайм-ауты NCCL.
7. Проверьте качество. Сопоставьте ответы исходной и квантованной модели, включая JSON, tool calls и задачи, критичные для продукта.
8. Оцените жизненный цикл. Для каждого кандидата зафиксируйте порядок обновления, поддержку запланированных моделей и GPU, а также процедуру отката.

Клиент генератора нагрузки не должен становиться узким местом. Его лучше запускать отдельно от inference-сервера или как минимум контролировать CPU, сетевые лимиты и число соединений. Для streaming-запросов необходимо измерять момент получения первого содержательного фрагмента, а не только установление HTTP-соединения.

Полезно дополнительно провести два теста prefix caching. Первый должен содержать точно совпадающие префиксы, второй — похожие по смыслу, но различающиеся на уровне токенов. Это покажет, получает ли приложение реальную выгоду от кэша или ожидаемый эффект существует только в искусственном benchmark.

Когда выбирать vLLM, SGLang или TGI

vLLM

vLLM подходит как базовый вариант для большинства новых API-сервисов. Его стоит предпочесть, если команде важны широкий OpenAI-совместимый интерфейс, большая экосистема, разнообразие моделей и возможность постепенно переходить от одной GPU к более сложным схемам.

• чат и генерация текста с обычным или смешанным трафиком;
• единая платформа для нескольких классов моделей;
• развёртывание на одной GPU с дальнейшим масштабированием;
• использование разных форматов квантования;
• проект, который будет переходить на новые модели и поколения NVIDIA GPU.

SGLang

SGLang стоит рассматривать в первую очередь, если нагрузка хорошо использует prefix caching или приложение выходит за пределы простого stateless-чата. К таким сценариям относятся агентные циклы, многотуровые сессии, ветвление генерации, повторное применение документов и reasoning-модели со специальными parsers.

• много общих префиксов и ветвящихся диалогов;
• гибкие механизмы планирования и распределённого запуска;
• функции для structured output, tools и reasoning;
• возможность подбирать конфигурацию для высоконагруженного сценария.

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

TGI

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

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

Практичный путь для действующего TGI-контура — поднять vLLM и SGLang параллельно для контрактного и нагрузочного тестирования. Затем трафик можно переключать постепенно, сравнивая ответы и метрики на одинаковых запросах. Подготовленный альтернативный контур уменьшает зависимость от одной зафиксированной конфигурации.

Что проверить перед вводом в эксплуатацию

Независимо от движка необходимо зафиксировать версию контейнера, digest образа, модель, revision checkpoint, tokenizer, chat template и параметры запуска. Использование плавающего тега образа или незакреплённой ревизии модели делает повторный запуск непредсказуемым.

Публичный inference-порт не следует открывать в интернет без защиты. Сервер размещают в приватной сети либо за reverse proxy или API gateway с TLS, аутентификацией, ограничением размера запроса, rate limiting и тайм-аутами. Служебные маршруты управления кэшем и профилирования должны быть недоступны внешним клиентам.

Перед production-запуском проверьте:

• готовность и health endpoint после загрузки модели;
• обычный и streaming-ответ через выбранный SDK;
• поведение при слишком длинном контексте;
• лимиты одновременных запросов и очереди;
• восстановление после OOM или падения worker;
• перезапуск виртуальной машины и повторную загрузку весов;
• работу всех GPU и отсутствие NCCL-ошибок;
• алерты по VRAM, latency, очереди и доле ошибок;
• корректное завершение запросов при rolling update;
• процедуру отката на предыдущий образ.

Если инфраструктура сервиса растёт и возникает вопрос о выделении ресурсов под один критичный контур, полезно сопоставить возможности VPS и выделенного сервера. Для LLM-инференса решающими могут оказаться не только CPU и RAM, но и число GPU, их топология, доступность VRAM и требования к изоляции.

Итоги

Для новых inference-сервисов на NVIDIA GPU VDS основными кандидатами обычно становятся vLLM и SGLang. vLLM служит универсальной отправной точкой с широким API, развитой экосистемой и набором режимов исполнения. SGLang особенно интересен там, где важны повторяющиеся префиксы, сложное планирование, reasoning-модели и агентные процессы.

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

Окончательное решение следует принимать после воспроизводимого теста на той же GPU VDS, где будет работать production. Одновременно оценивайте качество ответов, время до первого токена, скорость decode, goodput, хвостовые задержки, расход VRAM, устойчивость при длинном контексте и жизненный цикл выбранного стека. Именно профиль реального трафика, а не название сервера или одиночный benchmark, определяет наиболее эффективную конфигурацию.