Александр Егоров

Проблема в том, что параметры современных нейросетей растут по экспоненте, а обрабатываемый контекст становится все длиннее. Из-за этого операционные расходы на генерацию текста превращаются в главный барьер для масштабирования сервисов. Обслуживать запросы к LLM в десятки раз сложнее и дороже, чем крутить классический поиск по ключевым словам. Чтобы не разориться на счетах и выжать максимум из дорогостоящих GPU, нужен специализированный софт. В этой статье мы подробно сравним три ведущих бэкенда для инференса: vLLM, LMDeploy и экосистему NVIDIA Triton Inference Server в связке с TensorRT-LLM. Мы разберем, как они управляют памятью, какие методы квантования используют и как распределяют запросы, а также оценим результаты их бенчмарков на актуальных архитектурах NVIDIA Hopper и Blackwell. Физика и экономика инференса LLM Чтобы понять архитектурные решения современных движков инференса, необходимо разобрать механику авторегрессионной генерации в моделях на базе архитектуры Transformer. Процесс инференса разделяется на две асимметричные фазы, каждая из которых создает свой профиль нагрузки на компоненты графического процессора. Prefill Первая фаза, известная как Prefill — обработка промпта или контекста. Она заключается в параллельном вычислении представлений для всех слов (токенов) пользовательского запроса. Математически все сводится к огромному количеству умножений матриц. Эта фаза эффективно утилизирует матричные тензорные ядра GPU и характеризуется высокой арифметической интенсивностью. Видеокарта на данном этапе работает на полную мощность, а главным ограничивающим фактором выступает чистая вычислительная сила чипа. Decode Вторая фаза — Decode — авторегрессионная генерация. По своей природе она принципиально отличается от первой. Генерация происходит строго последовательно: каждый новый токен вычисляется на основе всех предыдущих. Для генерации одного токена система вынуждена загружать все веса модели из глобальной видеопамяти (плашек High Bandwidth Memory или же HBM) в регистры потоковых мультипроцессоров (уровней L1–L3 Static Random Access Memory, далее SRAM). Поскольку объем вычислений на каждый байт загруженных данных минимален, фаза генерации жестко ограничена пропускной способностью памяти, оставляя вычислительные блоки GPU в состоянии простоя значительную часть времени. Пошаговый рабочий процесс Для общего понимания, отражу здесь общий процесс, где конкретно располагаются Prefill и Decode. Загрузка модели и весовых коэффициентов Перед началом логического вывода архитектура модели и ее вычисленные весовые коэффициенты загружаются с диска или удаленного хранилища в видеопамять GPU. Этот шаг выполняется один раз, перед обработкой любых запросов. В принципе, модель должна быть загружена с состоянием всех слоев, готовых к приему входных токенов. Подготовка ввода Вы отправляете в модель свой запрос. В частности, это текст, если мы говорим о чистых text-to-text моделях без дополнений в виде обработки аудио, видео и картинок. Токенизация Модель использует свой токенизатор для разделения вашего текста на токены (слова, подслова или специальные символы) и сопоставляет каждый токен с уникальным идентификатором (целым числом), используя файлы токенизатора и vocab из артефактов модели. Поиск по внедрению Каждый идентификатор токена используется для поиска изученного вектора внедрения из матрицы внедрения модели, которая также сохраняется среди артефактов модели. Эти векторы представляют токены таким образом, который может обработать нейронная сеть. Фаза предварительного заполнения Фаза предварительного заполнения, или Prefill, о котором как раз и шла речь чуть выше, происходит при однократной обработке моделью входных токенов. В этот момент она использует загруженные веса, чтобы настроить свое внутреннее состояние для генерации. При предварительном заполнении сохраняются тензоры ключей и значений для всех входных токенов. На последующих этапах декодирования они используются заново, чтобы избежать повторных вычислений по запросу. Этап декодирования И второй рассмотренный ранее этап — это декодирование, когда модель генерирует выходные токены один за другим. На каждом шаге она использует текущий контекст для прогнозирования следующего токена. Текущий контекст также сохраняется в кэше KV. Параметры выборки В дополнение к каждому шагу декодирования модель также присваивает значения вероятности возможным следующим токенам. Она использует параметры выборки (например, температуру, top_k, top_p), чтобы выбрать один токен из наиболее вероятных кандидатов. Это определяет, насколько креативным или целенаправленным будет результат. Детоксикация Когда полностью завершился этап создания выходных токенов, они обратно преобразуются в читаемый текст с использованием словаря токенизатора и мы получаем окончательный текст ответа. Рабочий процесс повторяет шаги декодирования до тех пор, пока не будет сгенерировано желаемое количество токенов или не будет выполнено специфическое условие остановки. Проблема фрагментации KV-кэша Вернемся к одному из ключевых механизмов оптимизации авторегрессионного декодирования, а именно к KV кэшу. Сохранение тензоров ключей и значений предотвращает необходимость пересчета всей последовательности на каждом шаге. Для понимания расчета, я подобрал очень удобный скрипт-пример: Ниже приведен пример работы шага Decode с использованием и без KV-кэша поэтапно. Сравнение масштабируемого точечного продукта с кэшированием KV и без него. emb_size означает размер для встраивания. Источник. Требуемый объем памяти для KV-кэша можно описать следующим математическим выражением: Здесь N_layers обозначает количество слоев трансформера, N_heads — количество голов внимания, D_head — размерность отдельной головы, L_sq — длину последовательности (включая контекст и сгенерированные токены), B — размер батча (количество одновременных запросов), а P_bytes — точность представления данных в байтах. Например, для базовых у большинства моделей FP16 и BF16 типов — это два байта. В ранних системах инференса, таких как FasterTransformer, память для KV-кэша выделялась в виде непрерывных линейных буферов, рассчитанных на максимально возможную длину последовательности, заданную гиперпараметрами модели. Подобный подход приводил к катастрофической деградации эффективности утилизации памяти из-за двух форм фрагментации. Внутренняя фрагментация возникала, когда запрос завершался задолго до достижения максимальной длины, оставляя заранее зарезервированную память пустой. Внешняя фрагментация формировалась из-за различной длины запросов, создавая в памяти пробелы, размер которых был недостаточен для размещения новых непрерывных буферов. Глубокое профилирование традиционных систем показало, что лишь от 20,4% до 38,2% выделенной видеопамяти фактически содержало полезные состояния токенов, тогда как остальной объем расходовался впустую. Это ограничение не позволяло увеличивать размер батча, критически снижая пропускную способность сервера. Ниже можно увидеть пример с резервированием места в памяти для одного запроса из 8 токенов с ограничением в 2 048. Источник. Как видно из рисунка, совсем небольшой запрос оставил 2 038 резервных слотов пустовать, неэффективно занимая при этом ячейки памяти. vLLM Проект vLLM, изначально разработанный в Лаборатории Sky Computing Калифорнийского университета в Беркли, произвел фундаментальный сдвиг в индустрии, представив архитектуру управления памятью PagedAttention. Решение напрямую адаптирует классические принципы виртуальной памяти и страничной организации из операционных систем для работы с тензорами внимания. Страничная организация памяти тензоров Алгоритм PagedAttention полностью отказывается от требования хранения KV-кэша в непрерывных участках видеопамяти. Вместо этого память квантуется на небольшие блоки-страницы фиксированного размера. Каждый из которых способен хранить ключи и значения для определенного количества токенов — обычно 16 токенов на блок. Такой размер эквивалентен примерно 12,8 КБ для модели класса 13B и является оптимальным компромиссом: он достаточно мал для минимизации потерь, но достаточно велик для эффективного запуска CUDA-ядер. Количество потребляемой VRAM традиционным способом и в рамках vLLM. Источник. Для маршрутизации видеопамяти vLLM поддерживает таблицу блоков, функционирующую аналогично таблице страниц виртуальной памяти. Она динамически транслирует логические позиции токенов запроса в адреса разрозненных физических блоков в HBM видеокарты. Эта архитектура приносит ряд качественных улучшений: внешняя фрагментация исключается математически, поскольку все физические блоки памяти имеют идентичный размер и могут быть выделены любому процессу; внутренняя фрагментация локализуется исключительно в рамках последнего, возможно, не полностью заполненного блока последовательности, что сводит потери памяти к околонулевым значениям; табличная маршрутизация позволяет нескольким логическим последовательностям ссылаться на одни и те же физические блоки памяти. Ниже представлен код и лог сравнительного анализа со стандартной библиотекой Hugging Face Transformers и использование платформы vLLM, показавший двукратное увеличение количества запросов в секунду по сравнению с традиционным методом пакетного вывода. Совместное использование памяти и кэширование префиксов Способность PagedAttention совместно использовать физическую память между различными сессиями открывает колоссальные возможности для оптимизации. В сценариях сложного декодирования, таких как лучевой поиск или параллельное сэмплирование, родительская последовательность ветвится на множество дочерних. В vLLM все ветви ссылаются на единый физический кэш префикса, а копирование блоков происходит только в момент модификации. Аналогичный подход применяется при обработке системных промптов: если множество пользователей взаимодействуют с агентом, имеющим объемный базовый контекст, этот контекст загружается в физические блоки памяти лишь единожды, сокращая потребление VRAM на порядок. Непрерывный батчинг и Chunked Prefill Важнейший компонент vLLM — это механизм диспетчеризации запросов. Традиционные системы ждали завершения обработки всего батча запросов перед загрузкой следующего. Технология Continuous Batching позволяет интегрировать новые запросы в освободившиеся слоты активного батча в процессе, не прерывая конвейер вычислений. При умеренной конкуренции пропускная способность масштабируется практически линейно до момента насыщения тензорных ядер или исчерпания VRAM. Однако непрерывный батчинг порождает проблему дисбаланса. Интеграция нового запроса требует проведения ресурсоемкой фазы Prefill, которая блокирует выполнение фазы Decode для уже обрабатываемых в батче запросов, вызывая резкие скачки задержки генерации. Для устранения этого конфликта vLLM реализует функцию Chunked Prefill. Алгоритм Chunked Prefill декомпозирует длинные входные промпты на блоки фиксированного размера, определяемого параметром max_num_batched_tokens. Планировщик отдает абсолютный приоритет фазе Decode, собирая все ожидающие операции декодирования в батч. Если в рамках установленного вычислительного бюджета остаются свободные слоты, планировщик заполняет их фрагментами фазы Prefill. Такое смешивание операций, привязанных к вычислениям на фазе Prefill, и операций, привязанных к памяти на этапе Decode, в рамках одного матричного шага радикально улучшает утилизацию GPU и выравнивает задержку между токенами — метрику Inter-Token Latency, или ITL. Настройка параметра позволяет управлять компромиссом: увеличение бюджета ускоряет Time To First Token (TTFT), но может повысить ITL-задержку. Прерывания и CPU Offloading В ситуациях экстремальной нагрузки, когда физическая память GPU полностью заполняется, vLLM применяет интеллектуальную политику прерывания запросов (preemption). Вместо того чтобы обрывать соединение или уничтожать вычисленный контекст, vLLM выгружает блоки KV-кэша менее приоритетных сессий в системную оперативную память хоста. При освобождении места на GPU данные оперативно возвращаются по шине PCIe. Несмотря на то, что пропускная способность PCIe существенно уступает HBM, асинхронный характер переноса блоков позволяет скрывать задержки и доводить исполнение запроса до конца. Кроссплатформенность Главное преимущество vLLM — это универсальность. Проект развивается как единая прослойка для работы с самыми разными аппаратными ускорителями. Помимо экосистемы NVIDIA CUDA, vLLM из коробки поддерживает решения от других производителей: AMD ROCm, Intel XPU, Google TPU, AWS Neuron и Intel Gaudi. Кроме того, платформу можно запускать на процессорах архитектур x86 и ARM (включая Apple Silicon), а также на системах IBM Z. Благодаря этому vLLM отлично подходит для гетерогенных дата-центров, где код не должен зависеть от конкретного производителя чипов. LMDeploy Однако кроссплатформенность нужна не всегда. Если в вашем распоряжении конкретный стек графических ускорителей и приоритетом является не всеядность бэкенда, а предельная скорость вычислений, стоит рассмотреть альтернативные решения. Одним из таких узкоспециализированных инструментов является LMDeploy — комплексный проект, разработанный командами MMRazor и MMDeploy в рамках консорциума InternLM. Этот инструментарий изначально проектировался с фокусом на глубокое сжатие моделей и достижение максимальной производительности. Сердцем экосистемы стал C++/CUDA-движок TurboMind. В профильных сценариях он демонстрирует показатели пропускной способности, превосходящие базовый vLLM до 1,8 раза. Архитектура конвейера TurboMind Движок TurboMind развивает идеи NVIDIA FasterTransformer. Фундаментом архитектуры служит модель Persistent Batch Inference. Процесс инференса рассматривается как непрерывно существующий батч с заранее аллоцированными слотами памяти. Запросы присоединяются к пулу при наличии свободных слотов и покидают его сразу после генерации EOS-токена, что позволяет слоту немедленно принять новый запрос. При наличии совпадений в кэше генерация начинается мгновенно, без повторного декодирования истории. Механизм управления KV-кэшем в TurboMind работает как пул памяти с классической политикой вытеснения Least Recently Used (LRU). Менеджер выступает в роли кэша верхнего уровня. При переполнении пула он не уничтожает сессию безвозвратно, как это происходит в vLLM. Вместо этого вытесненная последовательность сжимается до своей самой компактной формы — последовательности идентификаторов токенов. Если клиент возобновляет работу с данной сессией, идентификаторы заново пропускаются через контекстный декодер для восстановления тензоров внимания. Для пользователя этот процесс прозрачен, что создает иллюзию обладания «бесконечной» видеопамятью для хранения сессий. Для ускорения обработки длинных контекстов TurboMind применяет технологию Fast Context Decoding. Классические реализации внимания заменены на оптимизированные ядра Fused Multi-Head Attention (FMHA). Эта реализация позволяет оперировать ключами и запросами несовпадающей длины и использует систему косвенных указателей для адресации физически разрозненных фрагментов KV-кэша в пуле памяти. Дополнительно внедрены строгие барьеры синхронизации между потоками на стороне хоста для предотвращения зависаний NVIDIA Collective Communications Library (NCCL) при использовании тензорного параллелизма внутри одного процесса. Механизм Dynamic Split and Fuse Как альтернатива механизму Chunked Prefill из vLLM, LMDeploy реализует алгоритм Dynamic Split and Fuse. Логика данного механизма заключается в строгом контроле размера вычислительного окна параметром max_prefill_iters. Длинные запросы динамически фрагментируются, а короткие группируются таким образом, чтобы общий объем токенов в текущей матричной операции идеально соответствовал оптимальному размеру плитки для тензорных ядер. Это гарантирует непрерывную загрузку матрично-векторного вычислительного конвейера. Асинхронные операции загрузки и сохранения предвыбирают последующие плитки в shared memory параллельно с выполнением умножений на тензорных ядрах, что позволяет приблизиться к теоретическому потолку HBM. Агрессивное квантование и компрессия KV-кэша Главный плюс LMDeploy — глубоко оптимизированная система для работы с низкобитными форматами. В современном железе скорость генерации текста упирается именно в пропускную способность памяти. Поэтому сжатие весов модели и кэша дает кратный прирост производительности. Квантование весов INT4/AWQ TurboMind предоставляет высокопроизводительные CUDA-ядра для вычислений со смешанной точностью: INT4 для весов и FP16 для активации. Профилирование показывает, что инференс в 4-битном формате с алгоритмом AWQ (Activation-aware Weight Quantization) выполняется до 2,4 раз быстрее, чем в нативном формате FP16. Формат W8A8 SmoothQuant На архитектурах от Turing до Hopper движок реализует целочисленное квантование 8-бит для весов и активаций. Модель проходит процедуру предварительного сглаживания весов, после чего стандартные слои линейных преобразований заменяются на модули QRSMNorm и QLinear, после чего модель сохраняется. Для архитектур уровня B200 уже реализована поддержка новейшего формата MXFP4. Квантование KV-кэша (INT8/INT4) Размер KV-кэша в многопользовательской среде с множеством параллельных запросов быстро превышает размер самой модели. LMDeploy позволяет осуществлять онлайн-квантование тензоров KV-кэша в форматы INT8 или INT4. Как отмечают разработчики ядра, формат INT8 позволяет радикально сэкономить память при пренебрежимо малой потере точности генерации. Это даже заставило команду временно отказаться от разработки FP8 KV-кэша из-за низкого ROI в пользу целочисленного подхода. При этом стоит учитывать, что при квантовании кэша до INT4 падение точности становится заметным и требует более аккуратного тестирования. NVIDIA Triton Inference Server и TensorRT-LLM: аппаратная монополия и предельная оптимизация Комбинация NVIDIA Triton Inference Server и библиотеки TensorRT-LLM — флагманское решение для извлечения физического максимума производительности из графических процессоров от NVIDIA. TensorRT-LLM представляет собой низкоуровневую библиотеку с открытым исходным кодом, которая транслирует модели из формата PyTorch в глубоко оптимизированные статические графы, содержащие специализированные ядра под конкретную архитектуру GPU. Архитектура оптимизаций TensorRT-LLM Высокую производительность TRT-LLM обеспечивает симбиоз компилятора графов и кастомных CUDA-ядер, разрабатываемых инженерами NVIDIA Слияние слоев Компилятор trtllm-build анализирует граф модели и объединяет множество последовательных мелких операций в единое ядро. Это устраняет паразитные микросекундные задержки на запуск ядер и предотвращает циклы записи/чтения в глобальную память HBM, оставляя данные внутри быстрых регистров мультипроцессоров. Поддержка форматов FP8 и FP4 На архитектурах Hopper и Blackwell TensorRT-LLM автоматически активирует поддержку низкоточных вычислений с плавающей запятой. Использование FP8 не только сокращает потребление видеопамяти в два раза по сравнению с FP16, но и открывает доступ к инструкциям тензорных ядер удвоенной пропускной способности. В итоге скорость генерации на том же самом чипе вырастает ровно в 2 раза. А новейшая архитектура Blackwell идет еще дальше — она бесшовно работает с форматом MXFP4, вообще не теряя в качестве ответов. В целом такая поддержка есть и на vLLM. Чтобы оценить реальный прирост, мы провели небольшой тест производительности для модели Qwen3-Coder-Next-FP8. Мы сравнили ее работу на картах A100 (прошлое поколение Ampere) и H100 (актуальное поколение Hopper). Для запуска модели использовалась следующая команда: А это команда для тестирования: По итогам были получены следующие метрики, для A100 и H100 соответственно: Из полученных данных можно сказать, что H100 показывает превосходство над A100 по всем ключевым метрикам практически на порядок. МетрикаA100H100Улучшение на H100Время выполнения385,78 с57,82 с~6,6x быстрееRequest Throughput2,59 запр/с17,30 запр/с~6,6x вышеOutput Throughput331,80 ток/с2213,80 ток/с~6,6x вышеMean TTFT9087,82 мс2520,42 мс~3,6x быстрееMean TPOT521,39 мс68,88 мс~7,5x быстрее По этому тесту можно увидеть нативную аппаратную поддержку FP8 архитектуры Hopper через Tensor Cores нового поколения. В свою очередь архитектура Ampere нативной поддержки вычислений FP8 не имеет, поэтому как vLLM, так и TRT-LLM приходится выполнять эмулирование операции, что приводит к огромным накладным расходам и убивает всю производительность. Управление KV-кэшем корпоративного класса TensorRT-LLM применяет похожую с vLLM архитектуру страничного кэширования. Размер блока кэша не является жестко зафиксированным: пользователь может настроить его на любую степень двойки вплоть до 128 токенов при сборке модели. Более крупные блоки повышают эффективность вычислений, но снижают гранулярность переиспользования кэша. Интеллектуальное переиспользование префиксов в TRT-LLM реализовано через структуру радиксного дерева поиска. Система на лету определяет совпадения в истории промптов и связывает запросы. Для устранения рисков безопасности в мультитенантных средах, где потенциально возможна атака кражи промпта, внедрена функция KV Cache Salting. Пользователь может передать параметр cache_salt, например, ID пользователя, и система разрешит переиспользование физических блоков только в том случае, если совпадают и токены префикса, и значение соли. Более того, TRT-LLM реализует систему вытеснения блоков на основе приоритетов, позволяя приложению размечать важность различных частей промпта, а также предлагает API событий, транслирующий состояние кэша во внешние балансировщики нагрузки для маршрутизации запросов с учетом контекста. Более подробно это описано в статье Introducing New KV Cache Reuse Optimizations in NVIDIA TensorRT-LLM технического блога NVIDIA. Оркестрация через Triton Inference Server Triton Server служит мультифреймворковой оболочкой для управления скомпилированными графами TRT-LLM в промышленной среде. Типичный пайплайн LLM состоит из токенизатора, самой языковой модели и детокенизатора. Triton реализует сквозной конвейер двумя архитектурными способами. Ensemble Models Это декларативное описание DAG-графа зависимости через конфигурационные файлы config.pbtxt. Инференс ансамбля выполняется строго в высокопроизводительном слое C++ без копирования тензоров между этапами. Это обеспечивает максимальный показатель транзакций в секунду и почти 100% утилизацию GPU. Недостаток ансамблей — невозможность внедрения сложной условной логики (циклов, if-else). Business Logic Scripting Business Logic Scripting (BLS) — это интеграция моделей с помощью Python-скриптов, которая решает проблему с более сложными потоками выполнения. Метод позволяет разработчику программировать ветвления и динамический роутинг. Однако платой за такую гибкость становится производительность: из-за накладных расходов межпроцессного взаимодействия и ограничений Python GIL метрика Tokens Per Second может падать до двух раз, а утилизация GPU снижаться до 50%. Распределенный инференс и мульти-GPU Серверная часть TensorRT-LLM использует MPI для координации выполнения модели на нескольких графических процессорах и узлах. В настоящее время поддерживаются два различных режима для запуска модели на нескольких графических процессорах: режим лидера и режим оркестратора. В режиме лидера серверная часть TensorRT-LLM запускает один серверный процесс Triton для каждого графического процессора. Схема режима «Leader». Источник. В режиме «Orchestrator» серверная часть TensorRT-LLM запускает один серверный процесс Triton, который действует как оркестратор, и запускает один серверный процесс Triton для каждого графического процессора, который требуется каждой модели. Схема режима «Orchestrator». Источник. Второй метод может вызывать просадки в утилизации из-за избыточных затрат на коммуникацию между процессом-оркестратором и ведущим вычислительным узлом. Альтернативные архитектуры Отходя от конкретных инструментов, да и чтобы посмотреть на картину целиком, необходимо рассмотреть конкурирующие архитектурные концепции. В частности рассмотрим Text Generation Inference от Hugging Face и набирающий популярность подход дезагрегированного инференса. Движок TGI v3 написан на языках Rust и Python. В основе третьей версии лежит агрессивное кэширование префиксов с оптимизированной структурой радиксного дерева и глубокий рефакторинг слияния микроядер. Инженерная структура кэша позволяет достичь времени поиска совпадений порядка пяти микросекунд. На длинных промптах TGI v3 обрабатывает ответ всего за две секунды, избегая повторного префилла, в то время как неоптимизированная под данный паттерн версия vLLM тратит 27,5 секунд. Бенчмаркинг на NVIDIA H100 с использованием vLLM и Triton Воспользуемся готовыми наработками в рамках свежей статьи vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks от марта 2026 года. Сравнение идет также с SGLang, однако в текущей статье, данные по результатам на этом движке будут опущены. Тестирование проводилось на серверах bare-metal с видеокартой NVIDIA H100 80 ГБ. Анализировалась модель Llama-3.3-70B-Instruct в формате FP8. Throughput (Output Tokens per Second) Конкурентные запросыvLLM (ток/с)TensorRT-LLM Compiled (ток/с)1 запрос12013010 запросов65071050 запросов1,8502,100100 запросов2,4002,780 Анализ данных подтверждает технологическое доминирование TensorRT-LLM на аппаратной базе NVIDIA. При минимальной нагрузке отрыв TRT-LLM от vLLM составляет скромные 8%. Однако по мере масштабирования конкуренции до 100 запросов разрыв увеличивается почти до 14%, достигая 2 780 токенов в секунду. Time to First Token ConcurrencyvLLM p50vLLM p95TRT-LLM p50TRT-LLM p951 req45 мс68 мс38 мс55 мс10 req120 мс195 мс105 мс170 мс50 req380 мс720 мс340 мс620 мс100 req740 мс1,450 мс680 мс1,280 мс Показатель отзывчивости сервиса (TTFT) также на стороне TRT-LLM. На 95-м перцентиле при 100 одновременных запросах TensorRT-LLM выдает первый токен на 170 миллисекунд быстрее, чем vLLM. Тем не менее, эксплуатация TensorRT-LLM имеет очень серьезный инфраструктурный недостаток — время холодного старта. Из-за необходимости компиляции CUDA-графа, первая сборка движка TRT-LLM под конкретную модель на H100 занимает около 28 минут. В то же время vLLM готов к обработке запросов спустя 62 секунды. Повторные запуски скомпилированного движка TRT-LLM занимают 90 секунд, однако для инфраструктур с частой ротацией моделей время начальной компиляции может стать неприемлемым препятствием. Именно данная проблема привела к тому, что мы в Selectel как раз и решили уйти от использования Triton. Подытожив, можно сказать следующее: используйте vLLM, если вам нужен самый быстрый путь к продакшену и гибкость при обновлении модели; используйте TensorRT-LLM, если у вас есть одна модель для долгосрочного продакшену, а производительность имеет первостепенное значение. Бенчмаркинг на NVIDIA A100. vLLM, Triton, LMDeploy Следующее тестирование, проведенное уже с использованием NVIDIA A100 80 ГБ и квантованной Q4/AWQ модели Llama 3 70B, выявляет сильные стороны LMDeploy. В данном сценарии движок LMDeploy обеспечил наивысшую скорость генерации токенов, выдавая около 700 токенов в секунду при обслуживании 100 пользователей, сохраняя при этом самый низкий показатель TTFT. TensorRT-LLM продемонстрировал аналогичную пиковую пропускную способность, но при нагрузке в 100 одновременных запросов его TTFT катастрофически деградировал до более чем шести секунд, что говорит о необходимости ручного тюнинга планировщика с подбором max_num_tokens для избежания перегрузки очереди префилла. Движок vLLM показал стабильную пропускную способность на уровне 600–650 токенов в секунду. Его планировщик с алгоритмом PagedAttention и Chunked Prefill блестяще справился с контролем TTFT — показатель оставался стабильно низким на всем диапазоне нагрузок, защищая сервис от пиковых задержек. Возможности архитектур Blackwell и Hopper Данные внутренних бенчмарков NVIDIA демонстрируют потенциал TensorRT-LLM на сверхплотных моделях. При запуске массивной модели Llama 3.1 405B в формате FP8 на сборке Tensor Parallel 8, видеокарты H200 на 141 ГБ демонстрируют пропускную способность в 4 715 токенов в секунду для коротких входных/выходных последовательностей – 128 входных / 2 048 выходных. В то время как для сверхдлинных контекстов – 20 000 входных / 2 000 выходных – производительность ожидаемо снижается до 509 токенов в секунду из-за насыщения шины памяти KV-кэшем. Архитектура Blackwell переводит инференс на формат FP4. Запуск модели Llama 3.3 70B FP4 на платформе GB200 NVL72 продемонстрировало пропускную способность свыше 11 100 токенов в секунду на коротких запросах, что практически удваивает показатели предыдущего поколения за счет оптимизаций матричного умножения нового поколения. Для модели Llama 4 Maverick FP8 на H200 задокументированы показатели свыше 27 500 токенов в секунду при длине 128/2048. Это подчеркивает тот факт, что аппаратные оптимизации формата данных способны принести больший эффект, чем изменения в логике планировщика программного обеспечения. Заключение и рекомендации Развитие бэкендов для инференса LLM — классическая технологическая гонка: инновационные программные парадигмы по типу PagedAttention, Persistent Batching стремительно интегрируются конкурирующими проектами, в то время как производители кремния внедряют аппаратную поддержку низкоточных форматов FP8, FP4, а также новом NVFP4 на уровне архитектур самих GPU. На основании проведенного анализа можно дать следующие рекомендации по выбору платформы для инференса моделей: TensorRT-LLM и Triton Inference Server является ультимативным решением для развертывания устоявшихся моделей в высоконагруженных промышленных средах, эксплуатирующих графические процессоры NVIDIA архитектуры Hopper и Blackwell, где упор идет в достижение наилучших метрик моделей. За счет низкоуровневой компиляции графов, агрессивного слияния ядер и встроенной маршрутизации KV-кэша с учетом приоритетов, этот стек обеспечивает наивысшую пиковую пропускную способность и минимальное время до первого токена. Тем не менее, жесткая привязка к экосистеме NVIDIA и колоссальное время холодной сборки движка исключают его из сред, где сами модели могут или должны перезапускаться довольно часто. vLLM остается самым популярным решением для быстрого инференса моделей с высокими метриками качества. Его ключевое преимущество — гибкость в настройке и выборе фирмы производителя, а также отличная оптимизация самого инференса. Алгоритмы PagedAttention, Chunked Prefill дают высокую отказоустойчивость и стабильность задержек даже в сценариях с множеством больших конкурентных запросов. Несмотря на 6–13% отставание по сырой пропускной способности от специализированного кода TRT-LLM, мгновенный запуск и простота интеграции благодаря OpenAI compatible API делают vLLM лучшим выбором по умолчанию для большинства команд. LMDeploy с движком TurboMind выступает лучшим инструментом для развертывания компактных и средних моделей на ресурсоограниченном оборудовании. Интеграция механизма Dynamic Split and Fuse и превосходная реализация квантования W8A8 и AWQ позволяют TurboMind демонстрировать высочайшую плотность генерации токенов в секунду, превосходя конкурентов при использовании INT4 весов. Дополнительно, для задач обработки сверхдлинных промптов и реализации паттернов RAG с огромными контекстами, целесообразно рассматривать движок TGI v3. В нем архитектура кэширования префиксов позволяет сокращать задержки вычисления истории с нескольких десятков секунд до микросекунд.