Ускорение Llama 2 70B с помощью NVIDIA H100

Стремление к повышению производительности системы ответов Perplexity побуждает нас внедрять новейшие технологии, предлагаемые NVIDIA и AWS. В этом блоге мы рады поделиться результатами наших последних экспериментов: сравнением производительности вывода модели Llama 2 70B при различных аппаратных и программных настройках.

Наша платформа вывода LLM, pplx-api, построена на передовом стеке, использующем библиотеки с открытым исходным кодом. С момента начала публичного бета-тестирования pplx-api в октябре мы занимались решением задач масштабирования и оптимизацией конфигурации для достижения высокой производительности. Это привело нас к проведению экспериментов с целью поиска ответов на следующие ключевые вопросы:

Какой прирост производительности достигается при переходе с графических процессоров NVIDIA A100 на NVIDIA H100 при сохранении остальных настроек?

Каков прирост эффективности при использовании 8-битной квантованной арифметики с плавающей запятой (fp8), нативную поддержку которой обеспечивает H100? Каковы потери точности при такой квантовании?

Как тензорный параллелизм и размер пакета влияют на задержку и пропускную способность обработки токенов?

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

Мы провели следующий эксперимент в виде серии локальных тестов, чтобы исключить задержки сети.

Задержка (Latency): Общее время, необходимое серверу вывода для генерации полного ответа.

Пропускная способность (Throughput): Количество выходных токенов в секунду на графический процессор, которое сервер вывода может генерировать для всех пользователей и запросов.

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

Производительность масштабируется пропорционально размеру LLM. Большее количество параметров требует большего объема вычислений, что приводит к замедлению вывода. Например, Llama 2 13B работает быстрее, чем Llama 2 70B при прочих равных условиях. В этом эксперименте мы остановились на Llama 2 70B, так как стремимся оптимизировать работу с наиболее мощными моделями с открытым исходным кодом.

Объем входных и выходных токенов в каждой паре запрос/ответ может влиять на результаты измерений производительности. В целом, генерация выходных токенов является определяющим фактором общего времени ответа. Когда выборка данных предполагает только ответы "да/нет" от LLM, ответ генерируется быстрее по сравнению с выборками, требующими написания эссе. Наш набор данных состоит из синтетических запросов с 1024 входными токенами, вызывающих генерацию 512 выходных токенов. Это распределение было выбрано для соответствия наблюдаемому распределению трафика в нашем публичном развертывании Llama2 70B.

NVIDIA TensorRT-LLM (версия v0.5.0) — это библиотека с открытым исходным кодом для оптимизации вывода LLM. Она была выпущена в конце 2023 года, объединяет в себе множество оптимизаций вывода NVIDIA и предоставляет гибкий уровень настройки для ключевых параметров данного эксперимента: размера пакета, квантования и тензорного параллелизма.

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

Архитектура графического процессора девятого поколения Hopper (H100-HBM3-80GB / p5.48xlarge) содержит огромный список преимуществ по сравнению со своим предшественником Ampere (A100-SXM4-80GB / p4de.24xlarge), включая повышение скорости вычислений в 2-6 раз и увеличение пропускной способности памяти графического процессора почти в 2 раза. Пропускная способность памяти графического процессора является критическим показателем для вывода, поскольку основным узким местом задержки при умножении матриц является загрузка гигабайтов данных модели из памяти графического процессора в вычислительные регистры. Основываясь на этих данных, мы предположили, что прямое сравнение NVIDIA H100 и A100 покажет двукратное улучшение как по задержке, так и по пропускной способности.

Еще одно ключевое различие между NVIDIA H100 и A100 заключается в том, что тензорное ядро H100 нативно поддерживает инструкции с 8-битной плавающей запятой (fp8), что открывает возможности для дальнейших оптимизаций, описанных ниже. Именно поэтому мы используем fp8 и fp16 специально для H100.

Чтобы обеспечить постоянство объема памяти на GPU в ходе этого эксперимента, мы использовали узлы с 8x80GB памяти как для NVIDIA A100, так и для H100. Помимо возможности увеличения размера пакетов, память GPU важна, так как параметры модели загружаются в память GPU при запуске сервера для быстрого доступа. Например, если каждый из 70 миллиардов параметров в нашей модели является 16-битным числом с плавающей запятой, то размер модели составляет около 140 ГБ, что не помещается на одном графическом процессоре. Отсюда и возникает необходимость в тензорном параллелизме, который мы объясняем ниже.

Тензорный параллелизм относится к количеству графических процессоров, используемых для запуска сервера вывода. Когда мы выделяем определенное количество графических процессоров, TensorRT-LLM объединяет их ресурсы, помогая достичь минимально необходимого объема памяти для работы Llama2 70B. Наша гипотеза заключается в том, что меньший тензорный параллелизм приведет к большей задержке (из-за использования меньшего количества ресурсов для обработки каждого пакета), но более высокой пропускной способности на каждый графический процессор (из-за лучшего использования ресурсов) по сравнению с более высоким тензорным параллелизмом.

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

Реализация квантования может привести к снижению точности. Поэтому мы оценили точность для разных уровней точности, сравнив их статистику перплексии — показатель того, насколько хорошо LLM предсказывает каждый следующий токен в предложении — на корпусе WikiText. Для 8-битной плавающей запятой и 8-битного веса с 8-битной активацией и SmoothQuant (w8a8 SQ) не было значительного изменения перплексии (< 1%) по сравнению с fp16 на WikiText, поэтому мы сочли возможным продолжить. Однако w4a16 показал существенное изменение перплексии на 7%, что потенциально объясняется еще более низкой точностью и необходимыми динамическими преобразованиями между int4 и fp16.

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

В случае с Llama 2 70B (у которой 80 слоев), fp16 с размером пакета 32 для размера контекста 4096, размер кэша KV составляет внушительные 40 ГБ. Это препятствует комфортному размещению Llama 2 70B fp16, чьи только одни веса занимают 140 ГБ, в 160 ГБ памяти GPU, доступной при тензорном параллелизме 2 (TP-2).

Мы изучили совместимые комбинации 4 переменных эксперимента и представляем наиболее показательные тенденции ниже.

Рисунок 1 — Задержка запросов при различном размере пакета в пяти различных конфигурациях, все с тензорным параллелизмом 8, который обеспечивает наилучшую задержку при наличии 8 графических процессоров. В рамках каждой конфигурации задержка обычно удваивается при увеличении размера пакета от 1 до 32 и удваивается снова от 32 до 128. При достаточно больших размерах пакетов H100 сокращает задержку примерно вдвое по сравнению с A100. A100 использует смешанную точность, поскольку архитектура не имеет нативной поддержки fp8. w8a8 со SmoothQuant (SQ) призван имитировать fp8.

Улучшение задержки за счет квантования составляет около 10% при сравнении H100 fp16 → fp8 и A100 fp16 → w8a8 со SmoothQuant. Однако w4a16 со смешанной точностью фактически работает лучше при малых размерах пакетов и хуже при больших размерах пакетов по сравнению с fp16. Это может быть связано с рядом факторов, включая менее оптимизированные вычислительные ядра, время преобразования между int4 и fp16, а также тот факт, что w4a16 все еще использует 16-битные числа с плавающей запятой для активаций, что не дает экономии в размерах кэша KV. Поскольку w4a16 также продемонстрировал более низкую точность, мы пришли к выводу, что следует использовать w8a8 SQ для A100 и fp8 для H100.

Рисунок 2 — Пропускная способность для конфигураций TP-8 с различной архитектурой, квантованием и размером пакета. Для каждой архитектуры и квантования размер пакета был выбран как максимальный, который соблюдает требование по задержке 25600 мс (20 токенов в секунду для 512 токенов), чтобы мы могли сравнивать конфигурации с похожей задержкой. При этом требовании H100 с BS-128 достигает 228% пропускной способности по сравнению с A100 BS-64 с использованием того же квантования (fp16) и даже имеет меньшую задержку ответа, несмотря на удвоенный размер пакета. Квантование с fp8 увеличивает этот показатель до 251%.

На наших первых двух рисунках мы представляем только конфигурации TP-8. H100 достигает 54% задержки и 184% пропускной способности по сравнению с A100, когда оба используют fp16 / BS-128 / TP-8, что улучшается до 49% задержки и 202% пропускной способности при использовании fp8 на H100. Это улучшение производительности можно объяснить увеличением вычислительной мощности и пропускной способности памяти между H100 и A100. Примечательно, что разница менее выражена при меньших размерах пакетов, где использование ресурсов может быть ниже.

По мере развития нашей платформы мы стремимся соблюдать определенные требования к задержке для наших пользователей, максимизируя пропускную способность. Таким образом, вместо сравнения A100 и H100 при одинаковом размере пакета, имеет больше смысла сравнивать их пропускную способность только в тех конфигурациях, где они удовлетворяют требованию по задержке. Мы установили порог задержки в 25600 мс для завершения 512 выходных токенов и обнаружили, что H100 / TP-8 / fp8 / BS-128 обеспечивает 251% пропускной способности по сравнению с A100 / TP-8 / fp16 / BS-64, так как он способен обрабатывать удвоенный размер пакета при меньшей задержке. Учитывая, что квантование обеспечивает экономию памяти GPU, теперь нам необходимо оценить, как тензорный параллелизм может добавить следующий уровень оптимизации.

Рисунок 3 — Задержка при варьировании размера пакета и тензорного параллелизма для H100 fp8. Задержка обычно удваивается при увеличении размера пакета от 1 до 32 и удваивается снова от 32 до 128. TP-2 стабильно работает примерно в два раза медленнее, чем TP-8 при равных размерах пакетов. Удвоение тензорного параллелизма при одновременном удвоении размера пакета сохраняет задержку относительно стабильной, так как количество пакетов, обрабатываемых на каждый графический процессор, остается равномерным.

Что касается квантования и архитектуры, здесь есть явные лидеры: H100 доминирует над A100, а квантование с пониженной точностью улучшает использование памяти, задержку и пропускную способность. Однако размер пакета и тензорный параллелизм представляют собой компромисс в наших ключевых показателях. Больший размер пакета оптимизирует пропускную способность ценой увеличения задержки и потребления памяти. С другой стороны, более высокий тензорный параллелизм увеличивает общий пул доступной памяти и оптимизирует задержку, но снижает пропускную способность из-за затрат на синхронизацию при распределенном умножении матриц и по причине блокировки большего количества ресурсов GPU.

Рисунок 4 — Пропускная способность при варьировании размера пакета и тензорного параллелизма для H100 fp8. Самая высокая пропускная способность достигается при TP-2 BS-128, что составляет 460% по сравнению с базовым уровнем A100/TP-8/fp16/BS-64. Однако TP-2 BS-128 также является самым медленным результатом на рисунке 3.

Конфигурация нашего эксперимента, обеспечивающая максимальную пропускную способность, — это H100 / fp8 / TP-2 / BS-128, со скоростью 767 выходных токенов в секунду на GPU. Это 460% улучшения по сравнению с A100 / fp16 / TP-8 / BS-64. Однако это происходит ценой удвоенной задержки — ближе к 42000 мс для 512 выходных токенов — поэтому она может не подходить в качестве промышленной конфигурации. Результаты TP-4 BS-128 (626 ток/сек/GPU при времени ответа 26188 мс) и TP-2 BS-32 (435 ток/сек/GPU при времени ответа 18821 мс) могут представлять собой лучшие компромиссы по нашим ключевым показателям.

Наши результаты показывают, что:

Мы достигаем 54% задержки и 184% пропускной способности при использовании H100 по сравнению с A100 в той же конфигурации, что улучшается до 49% и 202% соответственно, когда H100 использует преимущества своей нативной поддержки fp8.

При максимизации пропускной способности с учетом ограничения по задержке, H100 / fp8 / TP-8 / BS-128 обеспечивает 251% пропускной способности по сравнению с A100 / fp16 / TP-8 / BS-64, так как он может обрабатывать удвоенный пакет с большей скоростью.

Используя H100 с TP-2 и fp8, мы можем достичь 373% пропускной способности от A100 / fp16 / TP-8 / BS-128, при увеличении задержки менее чем на 10%.

Размер пакета и тензорный параллелизм создают компромисс между пропускной способностью и задержкой для оператора системы вывода LLM.

Эти результаты дают нам уверенность в полном переходе на графические процессоры H100 в нашем ранее работавшем на A100 аппаратном стеке. Мы рады подтвердить заявленные NVIDIA показатели производительности и с нетерпением ждем их следующих прорывов в области ускоренного оборудования.

Наш следующий рубеж оптимизации — исследование точности и влияния на производительность структурной разреженности и точности int4, что может значительно сократить объем памяти GPU для Llama 2 70B и обеспечить до 2-кратного улучшения задержки. Мы рады продолжать путь к молниеносному выводу и надеемся дать нашим пользователям возможность создавать мощные приложения на базе нашей платформы.

В ближайшей перспективе pplx-api отменит ограничения по частоте запросов и предложит больше пользовательских LLM от Perplexity, включая LLM с доступом к Интернету и проверкой фактов.

Подпишитесь на Perplexity Pro по адресу perplexity.ai/pro. Получите доступ к нашему передовому pplx-api и используйте эти расширенные возможности в своих проектах. Узнайте больше о pplx-api в нашем блоге.

Хотите формировать будущее ИИ? Мы нанимаем сотрудников! Станьте частью команды, создающей инфраструктуру для крупномасштабных генеративных LLM. Ознакомьтесь с возможностями на странице Perplexity Careers.

Аараш Хейдари, Григорий Алексеев, Кевин Ху, Денис Ярац

Экспериментальная установка

Ключевые показатели:

Константы:

Модель ИИ

Набор данных входных/выходных токенов

Версия программного обеспечения

Переменные

Архитектура графического процессора

Тензорный параллелизм

Квантование

Размер пакета (Batch Size)

Результаты

Заключение

Что дальше

Авторы: