Большие языковые модели (LLM) сейчас ограничены не столько обучением, сколько скоростью и стоимостью обслуживания токенов при реальном трафике. Это зависит от трёх деталей реализации:
* как среда выполнения обрабатывает запросы пакетами;
* как она совмещает предварительное заполнение и декодирование;
* как она хранит и повторно использует кэш KV.
В статье сравниваются шесть сред выполнения, которые часто встречаются в производственных стеках:
* vLLM;
* TensorRT LLM;
* Hugging Face Text Generation Inference (TGI v3);
* LMDeploy;
* SGLang;
* DeepSpeed Inference / ZeRO Inference.
1. vLLM
Дизайн
vLLM построена на основе PagedAttention. Вместо того чтобы хранить кэш KV каждой последовательности в большом непрерывном буфере, она разбивает KV на блоки фиксированного размера и использует слой косвенности, чтобы каждая последовательность указывала на список блоков.
Это даёт:
* очень низкую фрагментацию KV (сообщается о <4% отходов против 60–80% в наивных распределителях);
* высокую загрузку GPU при непрерывном пакетном выполнении;
* встроенную поддержку совместного использования префиксов и повторного использования KV на уровне блоков.
Недавние версии добавляют квантование KV (FP8) и интегрируют ядра в стиле FlashAttention.
Производительность
vLLM достигает в 14–24 раза более высокой пропускной способности, чем Hugging Face Transformers, и в 2,2–3,5 раза выше, чем ранний TGI для моделей LLaMA на графических процессорах NVIDIA.
Где используется
vLLM — это двигатель высокой производительности по умолчанию, когда вам нужен общий серверный бэкенд LLM с хорошей пропускной способностью, хорошим TTFT и гибкостью оборудования.
2. TensorRT LLM
Дизайн
TensorRT LLM — это движок на основе компиляции поверх NVIDIA TensorRT. Он генерирует объединённые ядра для каждой модели и формы и предоставляет API исполнителя, используемый такими фреймворками, как Triton.
Его подсистема KV является явной и многофункциональной:
* страничный кэш KV;
* квантованный кэш KV (INT8, FP8, некоторые комбинации всё ещё развиваются);
* кольцевой буфер кэша KV;
* повторное использование кэша KV, включая выгрузку KV на CPU и повторное использование его между запросами для сокращения TTFT.
Производительность
TensorRT LLM обладает широкими возможностями настройки, поэтому результаты различаются. Общие закономерности из публичных сравнений и тестов поставщиков:
* очень низкая задержка для одного запроса на графических процессорах NVIDIA, когда движки скомпилированы для конкретной модели и конфигурации;
* при умеренном параллелизме его можно настроить либо для низкого TTFT, либо для высокой пропускной способности; при очень высоком параллелизме профили, оптимизированные для пропускной способности, увеличивают P99 из-за агрессивного пакетного выполнения.
Где используется
Подходит для критически важных по задержке рабочих нагрузок и сред NVIDIA, где команды могут инвестировать в сборку движков и настройку для каждой модели.
3. Hugging Face TGI v3
Дизайн
Text Generation Inference (TGI) — это стек, ориентированный на серверы, с:
* сервером на основе Rust (HTTP и gRPC);
* непрерывным пакетным выполнением, потоковой передачей, защитными хуками;
* бэкендами для PyTorch и TensorRT и тесной интеграцией с Hugging Face Hub.
TGI v3 добавляет новый конвейер для длинных контекстов:
* фрагментированное предварительное заполнение для длинных входных данных;
* кэширование префиксов KV, чтобы длинные истории разговоров не пересчитывались при каждом запросе.
Производительность
Для обычных подсказок недавняя работа сторонних разработчиков показывает:
* vLLM часто опережает TGI по количеству токенов в секунду при высоком параллелизме из-за PagedAttention, но разница не так велика во многих настройках.
* TGI v3 обрабатывает примерно в 3 раза больше токенов и до 13 раз быстрее, чем vLLM для длинных подсказок в условиях с очень длинными историями и включенным кэшированием префиксов.
Где используется
Производственные стеки, уже использующие Hugging Face, особенно для рабочих нагрузок в чате с длинными историями, где кэширование префиксов даёт значительные преимущества в реальном мире.
4. LMDeploy
Дизайн
LMDeploy — это инструментарий для сжатия и развёртывания из экосистемы InternLM. Он предоставляет два движка:
* TurboMind: высокопроизводительные ядра CUDA для графических процессоров NVIDIA;
* движок PyTorch: гибкий запасной вариант.
Производительность
Оценки показывают:
* для 4-битных моделей Llama на A100 LMDeploy может достигать более высокой пропускной способности, чем vLLM, при сопоставимых ограничениях по задержке, особенно при высоком параллелизме.
* Также сообщается, что 4-битное выведение примерно в 2,4 раза быстрее, чем FP16 для поддерживаемых моделей.
Где используется
Развёртывания, ориентированные на NVIDIA, которые хотят максимальной пропускной способности и используют инструменты TurboMind и LMDeploy.
5. SGLang
Дизайн
SGLang — это:
* DSL для построения структурированных программ LLM, таких как агенты, рабочие процессы RAG и конвейеры инструментов;
* среда выполнения, которая реализует RadixAttention, механизм повторного использования KV, который использует префиксы с помощью структуры радикс-дерева.
Производительность
Ключевые идеи:
* SGLang достигает до 6,4 раз более высокой пропускной способности и до 3,7 раз более низкой задержки, чем базовые системы, такие как vLLM, LMQL и другие, для структурированных рабочих нагрузок.
* Улучшения наиболее значительны, когда происходит интенсивное повторное использование префиксов, например, в многоходовом чате или рабочих нагрузках по оценке с повторяющимся контекстом.
Где используется
Агентивные системы, конвейеры инструментов и тяжёлые приложения RAG, где многие вызовы используют большие префиксы запросов и повторное использование KV имеет значение на уровне приложений.
6. DeepSpeed Inference / ZeRO Inference
Дизайн
DeepSpeed предоставляет две части, актуальные для логического вывода:
* DeepSpeed Inference: оптимизированные ядра трансформатора плюс тензорный и конвейерный параллелизм;
* ZeRO Inference / ZeRO Offload: методы, которые выгружают веса модели, а в некоторых настройках кэш KV, на CPU или NVMe для запуска очень больших моделей на ограниченных графических процессорах.
Производительность
В примере с ZeRO Inference OPT 30B на одном V100 32GB:
* полная выгрузка на CPU достигает около 43 токенов в секунду;
* полная выгрузка на NVMe достигает около 30 токенов в секунду.
Эти цифры невелики по сравнению с временем выполнения LLM на GPU на A100 или H100, но они относятся к модели, которая изначально не помещается в 32 ГБ.
Где используется
Автономный или пакетный логический вывод или сервисы с низким QPS, где размер модели имеет большее значение, чем задержка и количество графических процессоров.
Выбор среды выполнения на практике
Для производственной системы выбор, как правило, сводится к нескольким простым шаблонам:
* Вам нужен надёжный движок по умолчанию с минимальными настройками: можно начать с vLLM. Он обеспечивает хорошую пропускную способность, разумный TTFT и надёжное управление KV на обычном оборудовании.
* Вы привержены NVIDIA и хотите точно контролировать задержку и KV: можно использовать TensorRT LLM, вероятно, за Triton или TGI. Планируйте создание сборок для каждой модели и настройку.
* Ваш стек уже использует Hugging Face, и вы заботитесь о длинных чатах: можно использовать TGI v3. Его длинный путь подсказок и кэширование префиксов очень эффективны для трафика в стиле чата.
* Вы хотите максимальной пропускной способности на GPU с квантованными моделями: можно использовать LMDeploy с TurboMind и заблокированным KV, особенно для моделей семейства 4-битных Llama.
* Вы создаёте агентов, цепочки инструментов или тяжёлые системы RAG: можно использовать SGLang и разрабатывать подсказки так, чтобы повторное использование KV через RadixAttention было высоким.
* Вы должны запускать очень большие модели на ограниченных графических процессорах: можно использовать DeepSpeed Inference / ZeRO Inference, принять более высокую задержку и рассматривать графический процессор как механизм пропускной способности с SSD в цикле.
В целом все эти движки сходятся к одной идее: кэш KV — это реальный ресурс с узким местом. Победителями становятся среды выполнения, которые рассматривают KV как первоклассную структуру данных, которую можно разбивать на страницы, квантовать, повторно использовать и выгружать, а не просто как большой тензор, помещённый в память GPU.
1. Какие особенности vLLM делают её подходящей для использования в качестве общего серверного бэкенда LLM?
Ответ: vLLM отличается низкой фрагментацией KV (менее 4% отходов), высокой загрузкой GPU при непрерывном пакетном выполнении и встроенной поддержкой совместного использования префиксов и повторного использования KV на уровне блоков. Недавние версии добавляют квантование KV (FP8) и интегрируют ядра в стиле FlashAttention.
2. Какие преимущества предлагает TensorRT LLM для сред NVIDIA?
Ответ: TensorRT LLM подходит для критически важных по задержке рабочих нагрузок и сред NVIDIA. Он обладает низкой задержкой для одного запроса на графических процессорах NVIDIA, когда движки скомпилированы для конкретной модели и конфигурации. При умеренном параллелизме его можно настроить либо для низкого TTFT, либо для высокой пропускной способности.
3. В чём заключается особенность Hugging Face TGI v3, которая позволяет ему эффективно обрабатывать длинные подсказки?
Ответ: TGI v3 добавляет новый конвейер для длинных контекстов: фрагментированное предварительное заполнение для длинных входных данных и кэширование префиксов KV, чтобы длинные истории разговоров не пересчитывались при каждом запросе. Это позволяет TGI v3 обрабатывать примерно в 3 раза больше токенов и до 13 раз быстрее, чем vLLM для длинных подсказок в условиях с очень длинными историями и включённым кэшированием префиксов.
4. Какие факторы следует учитывать при выборе между vLLM и TensorRT LLM для производственной системы?
Ответ: при выборе между vLLM и TensorRT LLM следует учитывать требования к задержке и пропускной способности, а также наличие инвестиций в сборку движков и настройку для каждой модели. vLLM подходит для общего серверного бэкенда LLM с хорошей пропускной способностью, хорошим TTFT и гибкостью оборудования. TensorRT LLM подходит для сред NVIDIA, где можно инвестировать в сборку движков и настройку для каждой модели.
5. Какие преимущества предлагает SGLang для агентивных систем и тяжёлых приложений RAG?
Ответ: SGLang достигает до 6,4 раз более высокой пропускной способности и до 3,7 раз более низкой задержки, чем базовые системы, такие как vLLM, LMQL и другие, для структурированных рабочих нагрузок. Улучшения наиболее значительны, когда происходит интенсивное повторное использование префиксов, например, в многоходовом чате или рабочих нагрузках по оценке с повторяющимся контекстом.