В 2024 году ML-команды выбирали инференс-движок по принципу «лишь бы работало» — большинство останавливалось на vLLM как наиболее известном варианте и не задавало лишних вопросов. К 2026 году при аренде A100 от $1,8 в час и H100 от $4 в час разница в 30–50% по throughput — это уже не абстрактная метрика, а конкретная строка в бюджете проекта. Команды, обслуживающие более 100 RPS, превратили регулярный бенчмаркинг инференс-стека в операционную процедуру.
Для сравнения выбраны три наиболее распространённых движка: vLLM, Text Generation Inference (TGI) от HuggingFace и SGLang. Нагрузка одинаковая во всех прогонах: 256 параллельных запросов, prompt 1024 токена, output 256 токенов, температура 0,7. Это близко к типичному профилю RAG-сценария с генерацией развёрнутых ответов.
Как работает continuous batching и почему он определяет throughput
Классический inference-сервер обрабатывает запросы пачками фиксированного размера: набрал batch, прогнал через GPU, вернул ответы, набрал следующий. Проблема — токены генерируются с разной скоростью, и часть GPU-времени тратится на ожидание медленных запросов в пачке.
Continuous batching решает это иначе: новые запросы добавляются в обработку сразу, как только освобождается слот от завершившегося запроса. GPU никогда не простаивает. Все три движка реализуют continuous batching, но с разной агрессивностью приоритизации и управления KV-кешем — именно здесь расходятся их цифры throughput.
Llama 3.1 70B на двух H100: SGLang впереди
Тензорный параллелизм TP=2 — модель разрезается на два фрагмента, каждый живёт на своей GPU. Агрегированный throughput по output-токенам в секунду:
- SGLang 0.4.x: 3120 токенов/сек
- vLLM 0.7.x: 2840 токенов/сек
- TGI 3.x: 2410 токенов/сек
SGLang выигрывает за счёт continuous batching с приоритизацией коротких ответов и более агрессивного prefix caching. Prefix caching — механизм, при котором KV-кеш для повторяющегося префикса промта (системный промт, контекст из RAG) вычисляется один раз и повторно используется. На задачах с длинными системными промтами это снижает реальную нагрузку на вычисления, не отражаясь в «чистых» throughput-бенчмарках, но ощутимо влияя на cost-per-request.
vLLM немного позади SGLang. TGI отстаёт заметнее — это не фундаментальное ограничение движка, а следствие более консервативных default-настроек, которые HuggingFace намеренно выбирает для широкой совместимости. При тонкой настройке параметров TGI разрыв частично сокращается.
Mistral Codestral 22B на A100: различия сглаживаются
На одной GPU без параллелизма, FP16:
- SGLang: 2140 токенов/сек
- vLLM: 1980 токенов/сек
- TGI: 1840 токенов/сек
Разрыв между лидером и аутсайдером сокращается с 30% до 16%. Объяснение прямолинейно: инфраструктурные оптимизации, дающие преимущество SGLang, — координация между узлами, агрессивная балансировка батчей в условиях параллелизма — менее эффективны на одной GPU с меньшей моделью. Нет шардирования, нет multi-node координации, нет длинных KV-кешей. Для небольших команд с одной GPU-машиной выбор движка всё меньше определяется throughput и всё больше — удобством деплоя, качеством документации и размером сообщества.
FP8 на H100: 60% производительности за счёт квантизации
FP8 — формат представления чисел с плавающей точкой, использующий 8 бит вместо 16 (FP16). На H100 аппаратная поддержка FP8 реализована в Transformer Engine от NVIDIA. Вычисления ускоряются потому, что данные занимают вдвое меньше памяти: в KV-кеш помещается больше, больше токенов обрабатывается в одном проходе. Llama 3.1 70B в FP8 на H100 против FP16-базы:
- SGLang: 5280 токенов/сек (+69% к FP16)
- vLLM: 4710 токенов/сек (+66%)
- TGI: 3920 токенов/сек (+63%)
Качество вывода при FP8 на этих моделях практически неотличимо от FP16 — расхождения укладываются в статистический шум на стандартных бенчмарках. Команды, не использующие FP8 на H100, оставляют больше половины потенциальной производительности нетронутыми. Единственная причина не переходить — специфические модели с чувствительными к точности задачами, где требуется отдельная валидация: узкоспециализированные медицинские или финансовые модели, где малейший дрейф в точности имеет значение.
Structured generation и JSON-mode: нюанс в пользу SGLang
Помимо чистого throughput есть функциональная особенность, которая влияет на выбор для агентных сценариев. SGLang разрабатывался с фокусом на structured generation — constrained decoding, где модель должна генерировать строго определённые форматы: JSON по схеме, SQL-запросы, код в заданном синтаксисе.
Классический подход к structured generation — rejection sampling: генерировать токены и отбрасывать невалидные. SGLang реализует grammar-based constrained decoding, при котором невалидные токены маскируются до генерации. Это быстрее и надёжнее — модель не тратит вычисления на токены, которые всё равно будут отброшены. Для задач, где каждый ответ должен быть валидным JSON с фиксированной схемой, разница ощутима как в скорости, так и в надёжности.
vLLM и TGI также поддерживают structured generation, но реализация менее зрелая по состоянию на начало 2026 года. Если задача предполагает генерацию структурированных данных в продакшен-масштабе, SGLang здесь убедительнее.
Что выбрать под конкретный сценарий
SGLang лучше всего себя показывает на сценариях с structured generation, агрессивным prefix caching и высоким параллелизмом. Continuous batching реализован агрессивнее, чем у конкурентов. Минус — документация в стадии активного развития и меньшая аудитория, что усложняет отладку нетипичных случаев. Стоит проверять GitHub Issues перед переходом на конкретную версию.
vLLM — наиболее сбалансированный выбор для большинства команд. Обширная документация, большое сообщество, готовые рецепты деплоя для практически любой модели из HuggingFace Hub. По throughput немного уступает SGLang, но разница перекрывается предсказуемостью и легкостью эксплуатации. Для команды, которая только выстраивает инференс-инфраструктуру, vLLM — наименее рискованный старт.
TGI — оптимальный вариант для команд, уже находящихся в экосистеме HuggingFace. Глубокая интеграция с Hub упрощает загрузку и управление моделями, Enterprise Hub даёт корпоративные опции поддержки. Throughput ниже, но если инфраструктура уже на HuggingFace Inference Endpoints, стоимость перехода — инженерное время на миграцию и обучение — обычно превышает экономию от разницы в производительности.
За последние шесть месяцев все три движка прошли путь от обёртки над PyTorch до полноценной инфраструктурной платформы со своими механизмами квантизации, кешированием KV, балансировкой нагрузки и наблюдаемостью. Выбор инференс-движка теперь сопоставим по долгосрочным последствиям с выбором базы данных — он определяет операционный профиль продукта и стоимость миграции при смене решения.