Как выбрать бэкенд для инференса LLM: vLLM, LMDeploy или Triton с TensorRT-LLM

Выбор бэкенда для инференса больших языковых моделей сводится к трём сценариям. Нужен быстрый старт и совместимость с сотнями моделей - берите vLLM. Строите высоконагруженный продакшен с жёсткими требованиями к latency и мониторингу - разворачивайте Triton Inference Server с TensorRT-LLM. Работаете на ограниченном железе и хотите выжать максимум из квантования - LMDeploy даст лучшие цифры по throughput на низкобитных форматах.

Главные метрики для сравнения: throughput в запросах в секунду, время до первого токена (TTFT) и межтокеновая задержка (ITL). На практике разница между бэкендами на одном и том же GPU может достигать 40% по throughput и двукратной по памяти. В этом разборе - архитектурные причины таких разрывов, бенчмарки на H100 и B200, и чек-лист из пяти вопросов, который за пять минут определит ваш инструмент.

Мы уже тестировали запуск моделей в экстремально плотных конфигурациях, например, Qwen3.6 27B с тернарной квантизацией на RTX 3090, и разбирали, как GLM-5.2 на 8× GB10 достигает 1200 токенов/с на prefill. Выбор бэкенда напрямую влияет на то, увидите ли вы такие цифры в своей инфраструктуре.

Ключевые критерии выбора бэкенда для инференса LLM

Универсального бэкенда нет. Каждый инструмент - это компромисс между производительностью, гибкостью и сложностью эксплуатации.

Метрики, на которые смотрят в первую очередь:

• Throughput - количество запросов в секунду при заданном SLA по latency. Ключевая метрика для batch-обработки и API-сервисов.
• Time to First Token (TTFT) - задержка до появления первого токена ответа. Критична для интерактивных чат-ботов и стриминга.
• Inter-Token Latency (ITL) - среднее время между токенами в потоке вывода. Определяет «плавность» чтения ответа пользователем.
• Memory efficiency - сколько запросов параллельно умещается в память GPU без деградации latency.

Факторы выбора делятся на аппаратные и сценарные. Аппаратные: поколение GPU (Hopper, Blackwell, Ada Lovelace), объём VRAM, пропускная способность памяти. Сценарные: средняя длина входного контекста, соотношение prefill/decode, пиковые нагрузки, требования к мониторингу.

Для стримингового чат-бота с контекстом 4K токенов и SLA 200 мс на TTFT оптимален vLLM. Для batch-обработки тысяч документов в очереди - Triton с TensorRT-LLM. Для запуска модели 70B на одной A10 - LMDeploy с W4A16. Ошибка выбора на старте проекта обходится в месяцы переписывания инфраструктуры.

Архитектурные особенности: как бэкенды управляют памятью и запросами

Производительность инференса упирается в два узких места: пропускную способность памяти GPU и эффективность планировщика запросов. Три бэкенда решают эти проблемы принципиально разными способами.

PagedAttention в vLLM: виртуальная память для KV-кэша

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

KV-кэш нарезается на блоки фиксированного размера (pages), которые хранятся несмежно в физической памяти GPU. Планировщик vLLM выделяет блоки по мере необходимости и освобождает сразу после завершения запроса. Результат: утилизация памяти вырастает с 20-40% до 90%+ на смешанных нагрузках. Блоки можно разделять между запросами с одинаковым префиксом - например, при системном промпте в чат-боте - что кратно увеличивает эффективный размер батча.

Плата за гибкость - накладные расходы на трансляцию адресов блоков в ядре attention. На практике они не превышают 2-3% от времени инференса.

Кэширование и батчинг в LMDeploy: ставка на низкобитные форматы

LMDeploy от команды InternLM изначально проектировался под эффективную работу с квантованными моделями. Его ключевая особенность - TurboMind, движок инференса с непрерывным батчингом (continuous batching), который динамически добавляет новые запросы в обрабатываемый батч, не дожидаясь завершения текущих.

Архитектура LMDeploy заточена под формат W4A16: веса модели хранятся в 4 битах, активации - в 16 битах. Для этого используется собственный квантователь и оптимизированные GEMM-ядра, которые на лету декомпрессируют веса в регистры тензорных ядер. KV-кэш тоже квантуется - до 8 или 4 бит - с минимальной потерей точности. На Llama-3-70B в W4A16 LMDeploy помещает вдвое больше параллельных запросов в память H100, чем vLLM с FP16.

Дополнительный выигрыш даёт механизм кэширования блоков KV-кэша на хосте (CPU RAM) с асинхронной подкачкой в GPU. Для сценариев с длинными сессиями, где контекст накапливается, но активно используется только последний фрагмент, это снижает потребление VRAM на 30-50%.

Triton Inference Server + TensorRT-LLM: продакшен-оркестровка

Связка Triton и TensorRT-LLM - это не просто движок инференса, а платформа промышленного класса. Triton берёт на себя оркестровку: приём запросов по gRPC/HTTP, динамический батчинг, очереди, мониторинг через Prometheus, A/B-тестирование моделей. TensorRT-LLM компилирует модель под конкретное железо NVIDIA с максимальными оптимизациями.

Компиляция TensorRT-LLM включает: фьюзинг слоёв attention и MLP, оптимизацию под тензорные ядра Hopper (FP8) и Blackwell (FP4), планирование вычислений с учётом иерархии кэшей GPU. Результат - прирост throughput на 20-35% относительно vLLM на той же модели и том же GPU. Плата - время компиляции модели, которое для 70B может занимать 20-40 минут, и жёсткая привязка к конкретному GPU: скомпилированный engine для H100 не запустится на A100.

Динамический батчер Triton агрегирует запросы в окне настраиваемой длительности, максимизируя утилизацию GPU без превышения latency SLO. Планировщик TensorRT-LLM управляет KV-кэшем через собственный менеджер памяти с поддержкой paged attention, но с более агрессивным preemption - вытеснением менее приоритетных запросов в CPU-память при пиковых нагрузках.

Бенчмарки: throughput, TTFT и ITL на GPU Hopper и Blackwell

Цифры, приведённые ниже, получены на стандартных бенчмарках с моделями Llama-3-70B и Mixtral 8x7B. Нагрузка - смешанная: входной контекст 1K-4K токенов, генерация 256 токенов ответа.

Производительность на GPU Hopper (H100)

H100 с 80 ГБ HBM3 остаётся рабочей лошадкой инференса в 2026 году. На Llama-3-70B в FP16 картина следующая:

LMDeploy выигрывает по throughput за счёт вдвое большего батча при том же объёме VRAM. Triton+TensorRT-LLM лидирует по latency благодаря FP8 и агрессивным оптимизациям графа вычислений. vLLM отстаёт по цифрам, но запускается одной командой без компиляции.

На Mixtral 8x7B (MoE-архитектура) разрыв между Triton и vLLM сокращается до 10-15%: узким местом становится пропускная способность памяти при пересылке экспертных весов, а не качество планировщика.

Тестирование на Blackwell (B200): задел на будущее

B200 с 192 ГБ HBM3e и поддержкой FP4 меняет правила игры. На Llama-3-70B в FP4:

Прирост Triton на B200 достигает 35% благодаря нативной поддержке FP4 тензорными ядрами Blackwell. LMDeploy на B200 пока не показывает сопоставимых результатов - его W4A16-ядра не задействуют FP4-акселерацию аппаратно.

Практический вывод: если вы планируете закупку B200 в ближайшие полгода, инвестируйте в Triton+TensorRT-LLM сейчас. Переход с vLLM на Triton на Blackwell даёт больший прирост, чем на Hopper.

Квантование и работа на ограниченных ресурсах

Не у всех есть кластер из восьми H100. Для команд, работающих на A10, L40S или потребительских RTX 4090, поддержка квантования - главный критерий выбора.

LMDeploy лидирует по зрелости низкобитного инференса. Его конвейер квантования поддерживает W4A16 и W8A8 из коробки, с калибровкой на датасете из 128 сэмплов за 10-15 минут. KV-кэш квантуется в 8 или 4 бита с раздельным выбором точности для ключей и значений. На практике это означает запуск Llama-3-70B на одной L40S с 48 ГБ: LMDeploy в W4A16 даёт 6-8 токенов/с decode при контексте 4K, vLLM в FP16 на этой же карте просто не запустится.

vLLM активно догоняет: с версии 0.6.0 появилась нативная поддержка FP8-инференса на H100, а AWQ и GPTQ работают через бэкенд Marlin. Проблема в том, что Marlin-ядра оптимизированы под архитектуры Ampere и новее - на Turing (T4) производительность падает в 1.5-2 раза. LMDeploy на T4 сохраняет приемлемые 70-80% от теоретического пика.

Triton+TensorRT-LLM поддерживает FP8, INT8 и INT4 через компиляцию модели. Качество квантования высокое, но процесс трудоёмкий: калибровка требует репрезентативного датасета из 500+ сэмплов для сохранения точности модели в пределах 1% от FP16. Для быстрого прототипирования на ограниченном железе этот оверхед неоправдан.

Пример конфигурации для запуска Mixtral 8x7B на RTX 4090 (24 ГБ): LMDeploy с квантованием экспертов в W4A16 и attention-слоёв в FP16. Потребление VRAM - 19 ГБ, decode - 12-15 токенов/с. vLLM на этой же карте требует оффлоадинга части экспертов в CPU, что роняет скорость до 2-3 токенов/с.

Сценарии использования: когда выбирать vLLM, LMDeploy или Triton

Три типовых сценария закрывают 90% случаев выбора бэкенда в 2026 году.

vLLM: гибкость и скорость прототипирования

vLLM - стандарт де-факто для исследовательских команд и стартапов. Запуск модели из Hugging Face Hub занимает одну команду: vllm serve meta-llama/Llama-3-70B. Поддержка OpenAI-совместимого API означает, что любой код, написанный под GPT-4, переключается на локальную модель сменой эндпоинта.

Активное сообщество (35K+ звёзд на GitHub) гарантирует, что новая архитектура моделей - будь то Mamba, Jamba или экзотический MoE - получит поддержку в vLLM в течение недель после релиза. Для сравнения, тестирование новых MoE-моделей вроде Kimi K3 на vLLM занимает часы, а на Triton - дни с учётом компиляции.

Ограничения: vLLM не даёт максимального throughput на фиксированном железе. Если вам нужно выжать 50 запросов в секунду с H100, Triton даст на 20-25% больше. Но для 80% команд, у которых инференс - часть продукта, а не продукт сам по себе, эта разница некритична.

Triton + TensorRT-LLM: продакшен без компромиссов

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

Ключевые преимущества: нативный мониторинг через Prometheus (latency по перцентилям, утилизация GPU, размер очереди), динамическое масштабирование через Kubernetes HPA на основе кастомных метрик Triton, A/B-тестирование моделей без простоя сервиса. Модельный ансамбль позволяет собрать конвейер «препроцессинг → LLM → постпроцессинг» в одном инференс-пайплайне.

Ограничения: сложность начальной настройки. Развёртывание Triton с TensorRT-LLM требует написания model configuration (config.pbtxt), компиляции engine под конкретный GPU, настройки кэширования и политик батчинга. Типичное время от нуля до продакшена - 1-2 недели силами senior ML-инженера. Привязка к экосистеме NVIDIA: скомпилированный engine не переносится между поколениями GPU.

Для команд, которые уже прошли путь от экспериментов к продакшену, мы разбирали опыт Databricks по выбору инференс-обвязки - их выводы подтверждают: на масштабе 1000+ запросов в секунду оверхед Triton окупается за счёт стабильности latency под нагрузкой.

LMDeploy: эффективность на низкобитных форматах

LMDeploy занимает нишу, которую vLLM и Triton только начинают осваивать: инференс на потребительских GPU и edge-устройствах. Если вы разворачиваете LLM на RTX 3090/4090, A10, L40S или Jetson Orin - LMDeploy даст максимальную производительность.

Дополнительное преимущество - поддержка китайских моделей (InternLM, Qwen, DeepSeek) из коробки, часто с оптимизированными ядрами под конкретные архитектуры. Для команд, работающих с этими моделями, LMDeploy - безальтернативный выбор на старте.

Ограничения: меньшее сообщество (5K+ звёзд на GitHub), документация на китайском и английском с фрагментарным покрытием, отставание в поддержке bleeding-edge архитектур. Если вы экспериментируете с новыми подходами к attention вроде Mamba-2 или RWKV-7, vLLM получит поддержку быстрее.

Итоговое сравнение и чек-лист для выбора

Сводная таблица по ключевым параметрам на июль 2026 года:

Чек-лист из пяти вопросов для выбора:

1. Какой у вас GPU? Потребительский (RTX 3090/4090, A10) - LMDeploy. Серверный (H100, B200) - vLLM или Triton.
2. Какой объём трафика? Менее 100 запросов в секунду - vLLM. Более 500 - Triton. Между ними - зависит от требований к latency.
3. Насколько критичен мониторинг? Нужны дашборды, алерты, перцентили latency - Triton. Достаточно логов - vLLM или LMDeploy.
4. Как часто меняются модели? Каждую неделю новые эксперименты - vLLM. Стабильный продакшен с релизами раз в квартал - Triton.
5. Есть ли MLOps-команда? Нет выделенных инженеров под инференс - vLLM. Есть команда, готовая настраивать и поддерживать - Triton.

Правильный бэкенд, выбранный под задачу, а не «потому что все используют», экономит десятки тысяч долларов на GPU и месяцы разработки. Начните с vLLM для прототипа, перейдите на LMDeploy, если упираетесь в память, и мигрируйте на Triton, когда throughput станет узким местом бизнеса.

Подписаться на канал