Сравнение производительности сервинга Llama 3 на vLLM, LMDeploy, MLC-LLM, TensorRT-LLM и TGI

Давно хотел встретить такое свежее сравнение. На днях команда BentoML провела сравнительное тестирование производительности сервинга модели Llama 3 с использованием бэкендов вывода

vLLM, LMDeploy, MLC-LLM, TensorRT-LLM, и Hugging Face TGI Далее некоторые выдержки из публикации.

Модели Llama 3 8B и 70B с 4-битной квантизацией тестировали на инстансе BentoCloud GPU A100 80GB (gpu.a100.1x80) при трех уровнях нагрузки вывода (10, 50 и 100 одновременных пользователей).

Помимо включения общих методов оптимизации инференса, таких как непрерывный батчинг, flash attention и префикс-кэшинг, исследователи не настраивали параметры инференса (утилизация памяти GPU, максимальное количество последовательностей, размер блока постраничного KV-кэша и т.д.) для каждого отдельного бэкенда. Это связано с тем, что такой подход не масштабируется по мере увеличения количества обслуживаемых нами больших языковых моделей (LLM).

Ключевые метрики: время до первого токена (TTFT) и скорость генерации токенов (токенов в секунду).

Llama 3 70B Q4: Time to First Token (TTFT) of Different Backends
Llama 3 70B Q4: Time to First Token (TTFT) of Different Backends
Llama 3 70B Q4: Token Generate Rate for Different Backends
Llama 3 70B Q4: Token Generate Rate for Different Backends

Если коротко, LMDeploy рекомендуется для Llama 3 как обеспечивающий высокую скорость декодирования, низкую задержку и простоту использования. vLLM хорош для сценариев, где критична низкая задержка. MLC-LLM и TensorRT-LLM также показывают многообещающие результаты, но имеют некоторые ограничения на данный момент.

Результаты по Llama 3 8B:

  • LMDeploy: Показал лучшую производительность декодирования с точки зрения скорости генерации токенов, до 4000 токенов в секунду для 100 пользователей. Достиг лучшего в своем классе TTFT с 10 пользователями. Хотя TTFT постепенно увеличивается с ростом числа пользователей, он остается низким и стабильно входит в число лучших.
  • MLC-LLM: Показал производительность декодирования, аналогичную LMDeploy, с 10 пользователями. Достиг лучшего в своем классе TTFT с 10 и 50 пользователями. Однако он с трудом сохраняет эту эффективность при очень высоких нагрузках. Когда одновременность увеличивается до 100 пользователей, скорость декодирования и TFTT не успевают за LMDeploy.
  • vLLM: Достиг лучшего в своем классе TTFT при всех уровнях одновременных пользователей. Но производительность декодирования менее оптимальна по сравнению с LMDeploy и MLC-LLM, с 2300-2500 токенами в секунду, аналогично TGI и TRT-LLM.

Результаты Llama 3 70B с 4-битной квантизацией:

  • LMDeploy: Показал лучшую скорость генерации токенов, до 700 токенов при обслуживании 100 пользователей, сохраняя при этом самый низкий TTFT при всех уровнях одновременных пользователей.
  • TensorRT-LLM: Продемонстрировал производительность, аналогичную LMDeploy, с точки зрения скорости генерации токенов и поддерживал низкий TTFT при небольшом количестве одновременных пользователей. Однако TTFT значительно увеличился до более чем 6 секунд, когда количество одновременных пользователей достигло 100.
  • vLLM: Продемонстрировал стабильно низкий TTFT при всех уровнях одновременных пользователей, аналогично тому, что мы наблюдали с моделью 8B. Показал более низкую скорость генерации токенов по сравнению с LMDeploy и TensorRT-LLM, вероятно, из-за отсутствия оптимизации вывода для квантованных моделей.

Помимо производительности

При выборе бэкенда вывода для сервинга LLM важную роль в принятии решения играют и другие соображения, помимо производительности. Далее выделены ключевые аспекты, которые, по мнению инженеров BentoML, важно учитывать при выборе идеального бэкенда вывода.

Квантизация

Квантизация обменивает точность на производительность, представляя веса целыми числами с меньшим количеством бит. Этот метод в сочетании с оптимизацией бэкендов вывода обеспечивает более быстрый вывод и меньший объем памяти. В результате BentoML смогли загрузить веса модели Llama 3 с 70B параметрами на один GPU A100 80GB, тогда как в противном случае потребовалось бы несколько GPU.

  • LMDeploy: Поддерживает 4-битную AWQ, 8-битную квантизацию и 4-битную квантизацию KV.
  • vLLM: Пока не полностью поддерживается. Пользователям необходимо квантовать модель через AutoAWQ или найти предварительно квантованные модели на Hugging Face. Производительность не оптимизирована.
  • TensorRT-LLM: Поддерживает квантизацию через modelopt, обратите внимание, что квантованные типы данных реализованы не для всех моделей.
  • TGI: Поддерживает AWQ, GPTQ и квантизацию bits-and-bytes.
  • MLC-LLM: Поддерживает 3-битную и 4-битную групповую квантизацию. Поддержка квантизации AWQ все еще экспериментальная.

Архитектуры моделей

Возможность использовать один и тот же бэкенд вывода для различных архитектур моделей обеспечивает гибкость инженерных команд. Это позволяет переключаться между различными большими языковыми моделями по мере появления новых улучшений, без необходимости миграции базовой инфраструктуры вывода.

  • LMDeploy: Поддерживается около 20 моделей движком TurboMind. Модели, требующие скользящего окна внимания, например Mistral, Qwen 1.5, пока не полностью поддерживаются.
  • vLLM: Поддерживается более 30 моделей.
  • TensorRT-LLM: Поддерживается более 30 моделей.
  • TGI: Поддерживается более 20 моделей.
  • MLC-LLM: Поддерживается более 20 моделей.

Требования к железу

Возможность работы на различном оборудовании обеспечивает экономию средств и гибкость при выборе подходящего оборудования в зависимости от требований к выводу. Это также предлагает альтернативы во время текущего дефицита GPU, помогая эффективно преодолевать ограничения поставок.

  • LMDeploy: Оптимизирован только для Nvidia CUDA.
  • vLLM: Nvidia CUDA, AMD ROCm, AWS Neuron, CPU.
  • TensorRT-LLM: Поддерживает только Nvidia CUDA.
  • TGI: Nvidia CUDA, AMD ROCm, Intel Gaudi, AWS Inferentia.
  • MLC-LLM: Nvidia CUDA, AMD ROCm, Metal, Android, IOS, WebGPU.

Удобства разработки

Бэкенд вывода для продакшена должен обеспечивать стабильные релизы и упрощать рабочие процессы для непрерывного развёртывания. Кроме того, удобная для разработчиков серверная часть должна иметь чётко определённые интерфейсы, которые поддерживают быструю разработку и высокую сопровождаемость кода, что важно для создания приложений искусственного интеллекта, работающих на основе больших языковых моделей (LLM).

  • Стабильные релизы: LMDeploy, TensorRT-LLM, vLLM и TGI предлагают стабильные релизы. MLC-LLM в настоящее время не имеет стабильных релизов с тегами, только ночные сборки; одно из возможных решений - сборка из исходного кода.
  • Компиляция модели: TensorRT-LLM и MLC-LLM требуют явного шага компиляции модели, прежде чем бэкенд вывода будет готов. Этот шаг потенциально может привести к дополнительным задержкам холодного старта во время развертывания.
  • Документация: LMDeploy, vLLM и TGI были легко изучаемы благодаря их исчерпывающей документации и примерам. MLC-LLM представил умеренную кривую обучения, в основном из-за необходимости понимания шагов компиляции модели. TensorRT-LLM был самым сложным для настройки в нашем тесте. Без достаточного количества качественных примеров нам пришлось читать документацию TensorRT-LLM, tensorrtllm_backend и Triton Inference Server, конвертировать чекпойнты, создавать TRT-движок и писать много конфигураций.

Подробнее

На этом пока все. Подписывайтесь на мой ТГ-канал, где я делюсь своими находками и опытом. Задавайте вопросы в комментариях и лично ТГ.

11
Начать дискуссию