Прискорення Llama 2 70B за допомогою NVIDIA H100

Прагнення до високої продуктивності в пошуковому рушії Perplexity спонукає нас впроваджувати найновіші технології від NVIDIA та AWS. У цьому блозі ми раді поділитися результатами наших останніх експериментів: порівнянням інференсу Llama 2 70B на різних параметрах апаратного та програмного забезпечення.

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

Який чистий приріст продуктивності від переходу наших графічних процесорів (GPU) з NVIDIA A100 на NVIDIA H100 за незмінності всіх інших параметрів?

Який приріст ефективності дає 8-бітне квантування з плавною комою (fp8), нативну підтримку якого додано в H100? Яка ціна цього квантування для точності?

Як тензорний паралелизм і розмір пакету (batch size) впливають на затримку та пропускну здатність токенів?

З огляду на вищесказане, яка конфігурація забезпечує найбільш масштабовний баланс продуктивності та економічної ефективності?

Ми провели наступний експеримент як серію локальних тестів (бенчмарків), щоб уникнути затримки мережі.

Затримка (Latency): загальний час, необхідний серверу інференсу для генерації повної відповіді.

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

Наведені нижче чинники впливають на ключові метрики, тому ми залишали їх незмінними в різних випробуваннях експерименту.

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

Кількість вхідних і вихідних токенів у кожній парі запит/відповідь може впливати на вимірювання продуктивності. Загалом генерація вихідних токенів домінує в загальному часі відповіді. Коли вибірка даних викликає в LLM лише відповіді «так/ні», відповідь є швидшою порівняно з вибірками, які вимагають від LLM написання есе. Наш набір даних складається із синтетичних запитів із 1024 вхідними токенами, які викликають 512 вихідних токенів. Цей розподіл було обрано відповідно до спостережуваного розподілу трафіку в нашому публічному розгортанні Llama2 70B.

NVIDIA TensorRT-LLM (випуск v0.5.0) — це бібліотека з відкритим вихідним кодом для оптимізації інференсу LLM. Випущена наприкінці 2023 року, вона поєднує численні оптимізації інференсу від NVIDIA та забезпечує гнучкий шар налаштування для ключових параметрів цього експерименту: розміру пакету, квантування та тензорного паралелізму.

Ми провели експерименти за 4 осями конфігурації: тензорний паралелизм, архітектура GPU, квантування та максимальний розмір пакету. Ці осі взаємопов'язані, оскільки кожна з них є компромісом щодо критично важливого ресурсного вузького місця — пам'яті графічного процесора.

Архітектура графічного процесора Hopper дев'ятого покоління (H100-HBM3-80GB / p5.48xlarge) містить <g2 величезний перелік функцій порівняно зі своїм попередником Ampere (A100-SXM4-80GB / p4de.24xlarge), зокрема у 2–6 разів вищу швидкість обчислень і майже вдвічі більшу пропускну здатність пам'яті GPU. Пропускна здатність пам'яті GPU є критичною метрикою для інференсу, оскільки основне «вузьке місце» затримки матричних множень під час інференсу полягає в завантаженні гігабайтів даних моделі з пам'яті GPU в обчислювальні регістри. З огляду на ці статистичні дані, ми висунули гіпотезу, що пряме порівняння NVIDIA H100 та A100 продемонструє дворазове покращення як затримки, так і пропускної здатності.

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

Щоб підтримувати стабільний обсяг пам'яті на один GPU в цьому експерименті, ми використовували вузли з 8x80GB пам'яті GPU як для NVIDIA A100, так і для H100. Окрім забезпечення більших розмірів пакетів, пам'ять GPU важлива тим, що параметри моделі завантажуються в неї під час запуску сервера для швидкого доступу. Наприклад, якщо кожен із 70 мільярдів параметрів нашої моделі є 16-бітним числом із плаваючою комою, то розмір моделі становить близько 140 ГБ, що не поміщається на одному GPU. Звідси й потреба в тензорному паралелізмі, який ми пояснюємо нижче.

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

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

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

Паралеризація за допомогою пакетної обробки (batching) — це класична стратегія витискання продуктивності з обмеженої ресурсами системи. Шляхом обробки кількох запитів під час кожного прямого проходу через нейронну мережу пакетна обробка збільшує пропускну здатність ціною певної затримки. Пакетна обробка також призводить до більшого споживання пам'яті GPU, оскільки розмір кешу KV, який керує механізмом уваги, зростає лінійно зі збільшенням розміру пакету.

У випадку Llama 2 70B (яка має 80 шарів), fp16 з розміром пакету 32 для розміру контексту 4096, розмір кешу KV досягає значних 40 ГБ. Через це Llama 2 70B fp16, чиї самі лише ваги займають 140 ГБ, не може вільно поміститися в 160 ГБ пам'яті GPU, доступної при тензорному паралелізмі 2 (TP-2).

Ми переглянули сумісні комбінації 4 змінних експерименту та нижче наводимо найцікавіші тенденції.

Рисунок 1. Затримка запитів із різним розміром пакету для п'яти різних конфігурацій, усі з тензорним паралелизмом 8, що забезпечує найкращу затримку за 8 доступних GPU. У межах кожної конфігурації затримка загалом подвоюється при збільшенні розміру пакету з 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 за однакових розмірів пакету. Подвоєння тензорного паралелізму зі спільним подвоєнням розміру пакету зберігає затримку відносно стабільною, оскільки кількість пакетів, оброблених на GPU, залишається незмінною.

Коли йдеться про квантування та архітектуру, є чіткі переможці: 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 компроміс між пропускною здатністю та затримкою.

Ці результати дають нам впевненість щодо повного переходу на GPU H100 у нашому апаратному стеку, який раніше працював на базі A100. Ми раді підтвердити приріст продуктивності, заявлений NVIDIA, і з нетерпінням чекаємо на їхні наступні прориви в галузі прискореного апаратного забезпечення.

Нашим наступним кордоном для оптимізації є дослідження точності та впливу на продуктивність структурованої розрідженості (structured sparsity) та точності int4, які можуть суттєво зменшити обсяг пам'яті GPU для Llama 2 70B та забезпечити до 2 разів кращу затримку. Ми раді продовжувати шлях неймовірно швидкого інференсу та сподіваємося надати нашим користувачам можливість створювати потужні додатки на базі нашої платформи.

У найближчій перспективі pplx-api скасує обмеження швидкості та запропонує більше кастомних моделей Perplexity LLM, зокрема модель LLM із підключенням до інтернету та обґрунтуванням фактів (grounding).

Зареєструйтеся в Perplexity Pro на perplexity.ai/pro. Отримайте доступ до нашого передового pplx-api та використовуйте ці розширені можливості у своїх проєктах. Дізнайтеся більше про pplx-api у нашому блозі.

Цікавитеся майбутнім штучного інтелекту? Ми наймаємо нових співробітників! Станьте частиною команди, що створює генеративну інфраструктуру LLM величезного масштабу. Перегляньте вакансії на сторінці Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

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

Ключові метрики:

Константи:

Модель штучного інтелекту

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

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

Змінні

Архітектура GPU

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

Квантування

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

Результати

Висновок

Що далі

Автори: