85-95 токенов в секунду при батче равном восьми и p95 задержке в 450 миллисекунд. Это не теоретические выкладки из пейперов, а реальные цифры инференса Llama-3-70B в честном FP8 на одной карте H100. Если ваша текущая self-hosted инсталляция выдает радикально меньше, вы греете воздух в серверной, а не утилизируете железо за тридцать тысяч долларов. В production-ml все сводится к математике утилизации памяти, и выбор движка для сервинга определяет, будете ли вы масштабировать бизнес или закупать лишние стойки с GPU.
vLLM, TGI или Triton: что выбрать для self-hosted LLM-инференса в 2026
Рынок сервинга больших языковых моделей консолидировался, оставив позади зоопарк кастомных скриптов. Долгое время HuggingFace со своим TGI (Text Generation Inference) задавали стандарт. Они первыми популяризовали continuous batching и переписали роутинг на Rust. Но TGI стал жертвой собственного лицензионного перехода и накопленного архитектурного долга. Монолитность их пайплайна сделала интеграцию новых техник квантования мучительно медленной, а потолок пропускной способности стал очевиден под по-настоящему высокой нагрузкой.
Затем пришел vLLM и демократизировал PagedAttention. В авторегрессионной генерации вы почти никогда не упираетесь в вычислительную мощность тензорных ядер. Главное узкое горлышко — пропускная способность видеопамяти и фрагментация KV-кэша. До vLLM системы резервировали память под кэш непрерывными кусками под максимальную длину контекста. Результат — до 60% видеопамяти просто простаивало из-за внутренней фрагментации. PagedAttention решил это, нарезав KV-кэш на блоки, аналогично страницам виртуальной памяти в классических ОС. Фрагментация упала почти до нуля, а continuous batching позволил подкидывать новые запросы в батч на уровне итерации токена, не дожидаясь завершения самых длинных генераций.
Для чисто генеративной нагрузки vLLM сегодня — это безальтернативная база.
Но здесь начинается хайп, и инженеры начинают тащить NVIDIA Triton Inference Server туда, где ему не место. Triton — это монструозный энтерпрайз-комбайн. Его классический dynamic batching собирает запросы в статичный батч за заданное временное окно. Для моделей вроде ResNet или BERT это работает отлично, но для LLM с непредсказуемой длиной ответа это смерть для latency. Да, у Triton появился бэкенд vLLM, который проксирует continuous batching. Но оборачивать чистую генерацию текста в gRPC/HTTP оверхед Тритона — это чистый инжиниринговый мазохизм. Вы теряете прозрачность шедулера vLLM, усложняете деплой и не получаете взамен ни одного лишнего токена в секунду.
Тритон нужен строго в одном случае: если у вас сложный мультифреймворковый ансамбль.
Представьте пайплайн: на вход летит аудио, вы прогоняете его через Whisper в формате ONNX, сырой текст отправляется в Llama-3 через бэкенд vLLM, а результат фильтруется классификатором токсичности на базе TensorRT. Вот здесь Triton сияет. Он берет на себя shared memory между моделями, оркестрацию очередей и пре/пост-процессинг на C++. В любой другой ситуации, где у вас просто торчит ручка чата — вам хватит голого сервера vLLM.
from vllm import LLM, SamplingParams
# Пример конфигурации vLLM, выжимающей максимум из H100
llm = LLM(
model="meta-llama/Meta-Llama-3-70B-Instruct",
quantization="fp8",
tensor_parallel_size=1,
gpu_memory_utilization=0.95,
max_num_batched_tokens=8192,
enforce_eager=False # Включаем CUDA graphs для снижения оверхеда CPU
)
Отдельный разговор — TensorRT-LLM. Технически это самая быстрая вещь на рынке. За счет глубоко оптимизированных fused kernels и in-flight batching, заточенного конкретно под архитектуры Hopper и Ada Lovelace, TRT-LLM дает прирост пропускной способности на 20-40% поверх vLLM. Но цена этого ускорения — эксплуатационный ад. Вам придется компилировать движок (engine) под конкретный размер батча, конкретную длину последовательности и точную архитектуру GPU. Поменяли карту с A100 на H100? Перекомпиляция. Изменились требования к размеру контекста? Перекомпиляция. Это стопроцентный вендор-лок под инфраструктуру NVIDIA.
Подбор сервинга — это всегда трейд-офф между стоимостью поддержки и утилизацией железа. У нас в MoranaLabs мы решаем это сугубо прагматично. Если мы ставим edge-решение или изолированный on-prem сервер для диалоговых агентов и RAG — мы разворачиваем чистый vLLM и тюним параметры CUDA graphs и утилизации памяти. Если периметр клиента требует сложного пайплайна с транскрибацией, эмбеддерами и строгим бюджетом по задержке, вся логика упаковывается в Triton. К TensorRT-LLM мы прикасаемся только тогда, когда нагрузка такова, что 30% прироста скорости экономят клиенту миллионы на закупке новых кластеров, а его MLOps-команда готова поддерживать матрицу компиляций. Индустриальный ИИ не терпит фанатизма — он требует метрик.