Покращуйте продуктивність моделей Falcon за допомогою Amazon SageMaker | Веб-сервіси Amazon

Яка оптимальна структура та конфігурація для розміщення великих мовних моделей (LLM) для генеративних додатків ШІ, що генерують текст? Незважаючи на велику кількість варіантів для обслуговування LLM, на це запитання важко відповісти через розмір моделей, різну архітектуру моделей, вимоги до продуктивності додатків тощо. The Amazon SageMaker Контейнер Large Model Inference (LMI). дозволяє легко обслуговувати LLM, об’єднуючи безліч різних фреймворків і методів, які оптимізують розгортання LLM. Контейнер LMI має потужний обслуговуючий стек під назвою Подача DJL що є агностиком до базового LLM. Він надає параметри конфігурації системного рівня, які можна налаштувати для отримання найкращої продуктивності інфраструктури хостингу для даного LLM. Він також має підтримку останніх оптимізацій, таких як безперервне дозування, також відоме як ітераційне дозування або постійне дозування, що забезпечує значне покращення пропускної здатності.

У більш ранньому після, ми показали, як можна використовувати контейнер LMI для розгортання сімейства моделей Falcon на SageMaker. У цій публікації ми демонструємо, як покращити пропускну здатність і затримку обслуговування Falcon-40B за допомогою таких методів, як безперервне пакетування. Ми також надаємо інтуїтивне розуміння параметрів конфігурації, наданих контейнером SageMaker LMI, що може допомогти вам знайти найкращу конфігурацію для вашої реальної програми.

Основи текстово-генеративного висновку для LLM

Давайте спочатку розглянемо кілька основ того, як виконувати висновок для LLM для генерації тексту.

Прохід вперед, активації та кеш KV

За наявності вхідної послідовності маркерів вони запускаються в a forward pass на всіх рівнях LLM (наприклад, Falcon), щоб створити наступний маркер. А forward pass означає процес передачі вхідних даних через нейронну мережу для отримання результату. У випадку генерації тексту, передача вперед передбачає подачу початкового початкового числа або контексту в мовну модель і генерування наступного символу або маркера в послідовності. Щоб створити послідовність тексту, процес часто виконується ітераційно, тобто він повторюється для кожного кроку або позиції у вихідній послідовності. На кожній ітерації модель генерує наступний символ або маркер, який стає частиною згенерованого тексту, і цей процес триває, доки не буде згенеровано необхідну довжину тексту.

Генерація тексту за допомогою таких мовних моделей, як Falcon або GPT autoregressive. Це означає, що модель генерує один токен за раз, обумовлюючи раніше згенеровані токени. Іншими словами, на кожній ітерації модель приймає раніше згенерований текст як вхідні дані та передбачає наступний токен на основі цього контексту. Як зазначено в vLLM: просте, швидке та дешеве обслуговування LLM за допомогою PagedAttention, у цьому процесі авторегресійного декодування всі вхідні маркери LLM виробляють свої тензори ключа уваги та значення, і ці тензори зберігаються в пам’яті GPU для генерації наступних маркерів. Ці кешовані тензори ключів і значень часто називаються KV cache.

Фази попереднього заповнення та декодування

У процесі авторегресійного декодування, подібному до того, що використовується для генерації тексту за допомогою таких мовних моделей, як Falcon, зазвичай є дві основні фази: prefill фаза і decode фаза. Ці етапи мають вирішальне значення для створення зв’язного та контекстуально відповідного тексту.

Фаза попереднього заповнення включає наступне:

• Початковий контекст – Фаза попереднього заповнення починається з початкового контексту або вихідного тексту, наданого користувачем. Цим початковим контекстом може бути речення, фраза або навіть одне слово. Він встановлює відправну точку для створення тексту та забезпечує контекст для того, що буде далі.
• Кондиціонування моделі – Наданий контекст використовується для обумовлення мовної моделі. Модель приймає цей контекст як вхідні дані та генерує наступну лексему (слово або символ) у послідовності на основі свого розуміння контексту.
• Генерація маркерів – Модель генерує один токен за раз, передбачаючи, що має бути далі в тексті. Цей токен додається до контексту, фактично розширюючи його.
• Ітеративний процес – Процес генерації токенів повторюється ітеративно. На кожному кроці модель генерує маркер, враховуючи оновлений контекст, який тепер включає маркери, згенеровані на попередніх кроках.

Фаза попереднього заповнення триває до тих пір, поки не буде виконано задану умову зупинки. Цією умовою може бути максимальна довжина згенерованого тексту, певний маркер, який сигналізує про кінець тексту, або будь-який інший критерій, встановлений користувачем або програмою.

Фаза декодування включає наступне:

• Завершення – Після фази попереднього заповнення у вас є частково згенерований текст, який може бути неповним або обрізаним у певний момент. Фаза декодування відповідає за завершення тексту, щоб зробити його зв’язним і граматично правильним.
• Продовження з останньої лексеми – На етапі декодування модель починається з останнього токена, згенерованого на етапі попереднього заповнення. Він використовує цей маркер як початковий контекст і генерує наступний маркер для продовження тексту.
• Ітеративне завершення – Як і на етапі попереднього заповнення, процес генерації токенів знову повторюється. Модель генерує один маркер за раз, обумовлюючи попередні маркери в послідовності.
• Умова зупинки – Фаза декодування також має умову зупинки, яка може бути такою ж, як і на фазі попереднього заповнення, як-от досягнення максимальної довжини або виявлення маркера кінця тексту. Коли ця умова виконується, процес генерації припиняється.

Комбінація фаз попереднього заповнення та декодування дозволяє авторегресійним моделям генерувати текст, який базується на початковому контексті та виробляє послідовні, контекстуально відповідні та контекстуально послідовні послідовності тексту.

Відноситься до Розподілена система обслуговування для генераторних моделей на основі трансформаторів для детального пояснення процесу.

Оптимізація пропускної здатності за допомогою динамічного пакетування

Поки що ми говорили лише про один вхід. На практиці ми очікуємо працювати з кількома запитами, що надходять випадковим чином від клієнтів додатків для висновку одночасно або в шаховому порядку. Традиційним способом базове пакетування можна використовувати для збільшення пропускної здатності та використання обчислювальних ресурсів GPU. Пакетування — це ефективне поєднання числових представлень більш ніж одного запиту в пакеті та виконання паралельних прогонів авторегресійних проходів вперед. Це інтелектуальне дозування здійснюється з боку подачі. Сервер DJLServing SageMaker LMI можна налаштувати для пакетного об’єднання кількох запитів для їх паралельної обробки, встановивши такі параметри в обслуговуючі.властивості:

• max_batch_delay = 100 – Максимальна затримка пакетної агрегації в мілісекундах. Стандартне значення становить 100 мілісекунд.
• розмір партії = 32 – динамічний розмір партії. За замовчуванням 1.

Це в основному показує, що DJLServing буде ставити запити в чергу на 100 мілісекунд за раз, або якщо кількість запитів, які поставлено в чергу, досягає вказаного batch_size, пакет буде заплановано для виконання на серверній частині для висновку. Це відомо як dynamic batching. Це динамічно, оскільки розмір пакету може змінюватися в різних пакетах залежно від кількості запитів, доданих за цей час. Однак, оскільки запити можуть мати різні характеристики (наприклад, деякі запити можуть мати форму 20 маркерів введення та 500 маркерів виводу, тоді як інші можуть бути зворотними, з 500 маркерами введення, але лише 20 для виведення), деякі запити можуть завершити обробку швидше, ніж інші в одній партії. Це може призвести до недостатнього використання графічного процесора під час очікування, поки всі поточні запити в пакеті завершать етап декодування, навіть якщо в черзі є додаткові запити, які очікують на обробку. Наступна діаграма ілюструє цей процес.

Оптимізація пропускної здатності за допомогою безперервного дозування

з continuous batching, також відомий як iterative or rolling пакетування, ми використовуємо відмінності між етапами попереднього заповнення та декодування. Для активації безперервного пакетування DJServing надає такі додаткові конфігурації відповідно до serving.properties:

• двигун=MPI – радимо використовувати механізм MPI для безперервного пакетування.
• option.rolling_batch=auto або lmi-dist – ми рекомендуємо використовувати auto, оскільки він автоматично вибере найбільш відповідний алгоритм пакетної обробки разом з іншими оптимізаціями в майбутньому.
• option.max_rolling_batch_size=32 – це обмежує кількість одночасних запитів. За замовчуванням 32.

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

Розмір цього кешу можна налаштувати за допомогою наступного параметра:

Коли попереднє заповнення завершено, ми об’єднуємо нові запити та старі призупинені запити в новий поточний пакет, який може продовжувати етап декодування паралельно. Зауважте, що старі призупинені запити можуть продовжувати етап декодування там, де вони зупинилися, а нові запити починатимуться з першого нового маркера.

Можливо, ви вже зрозуміли, що безперервне пакетування — це майже подібний підхід, за допомогою якого ми природно розпаралелюємо завдання в нашому повсякденному житті. У нас є повідомлення, електронні листи, телефонні сповіщення (потенційно нові запити), які надходять у випадковий час (аналогічно численним запитам, які надходять у випадковому порядку для графічних процесорів). Усе це відбувається, поки ми виконуємо наші завдання під час польоту — пишемо електронні листи, кодуємо, беремо участь у зустрічах (аналогічно поточним завданням обробки в графічних процесорах). У разі логічних перерв ми призупиняємо наші завдання під час польоту та перевіряємо наші сповіщення, щоб вирішити, чи потрібні якісь дії з нашого боку, і якщо вони потрібні, ми додаємо їх до наших завдань у польоті (реальна поточна партія) або помістіть це в список справ (чергу).

Зібравши все разом: як думати про використання пам’яті GPU

Рекомендується провести навантажувальне тестування моделі, щоб побачити, яка конфігурація є найбільш економічно ефективною для вашого бізнес-випадку використання. Щоб зрозуміти, давайте візуалізуємо відбиток пам’яті графічних процесорів під час завантаження моделі та під час послідовної обробки послідовних запитів. У цьому дописі припустимо, що ми завантажуємо модель Falcon-40B в один із типів екземплярів G5, які встановлено з графічним процесором NVIDIA A10G, кожен з якого має 24 ГБ пам’яті. Зауважте, що подібне розуміння стосується типів екземплярів p3, p4 і p5, які постачаються з серіями GPU V100, A100 і H100.

Нижче наведено огляд отримання приблизного значення загальної пам’яті, необхідної для обслуговування Falcon-40B:

• Розмір моделі = Кількість параметрів моделі (40 мільярдів для Falcon-40B) x 4 байти на параметр (для FP32) = 160 ГБ
• Приблизний загальний обсяг пам’яті, необхідний для завантаження Falcon-40B для висновку = Розмір моделі (=160 ГБ) + KV Cache (Attention Cache) (=*20 ГБ) + Додаткові витрати пам’яті за допомогою ML Frameworks (приблизно 2 ГБ)

Для Falcon-40B, якщо ми стискаємо модель шляхом квантування моделі до типу даних bfloat16 (2 байти), розмір моделі стає приблизно 80 ГБ. Як ви можете бачити, це все ще більше, ніж пам'ять, підтримувана одним прискорювачем, тому нам потрібно прийняти техніку розбиття моделі (шардингу) зі спеціальним тензорний паралельність (TP) підійти та розділити модель на кілька прискорювачів. Припустімо, що ми вибрали g5.24xlarge, який має 4 пристрої GPU A10G. Якщо ми налаштуємо DJLServing (serving.properties) за допомогою наступного, ми можемо очікувати, що 80 ГБ ваг моделі буде розподілено порівну між усіма 4 GPU:

з tensor_parallel_degree встановлено на 4, приблизно 20 ГБ із 24 ГБ пам’яті графічного процесора (приблизно 84%) вже використовується ще до того, як буде оброблено один запит. Решта 16% GPU буде використано для кешу KV для вхідних запитів. Цілком можливо, що для вашого бізнес-сценарію та його вимог до затримки та пропускної здатності 2–3 ГБ пам’яті, що залишилася, буде більш ніж достатньо. Якщо ні, ви можете збільшити розмір екземпляра до g5.48xlarge, який має 8 графічних процесорів і використовує tensor_parallel_degree зі значенням 8. У такому випадку лише приблизно 10 ГБ із доступних 24 ГБ пам’яті кожного графічного процесора використовується для ваг моделі, і ми мати близько 60% графічного процесора, що залишився, для активацій і кешу KV. Інтуїтивно зрозуміло, що ця конфігурація може дозволити нам мати вищу пропускну здатність. Крім того, оскільки тепер ми маємо більший буфер, ми можемо збільшити max_rolling_batch_prefill_tokens та max_rolling_batch_size параметри для подальшої оптимізації пропускної здатності. Разом ці два параметри керуватимуть попереднім розподілом попередніх заповнень активації та кешу KV для моделі. Більше число для цих двох параметрів буде пов’язано з більшою пропускною здатністю, припускаючи, що у вас достатньо буфера для кешу KV у пам’яті GPU.

Безперервне дозування за допомогою PagedAttention

PagedAttention — це новий алгоритм оптимізації, розроблений Каліфорнійським університетом у Берклі, який покращує безперервний процес пакетування, дозволяючи кешу уваги (кешу KV) бути несуміжним шляхом розподілу пам’яті на сторінки або блоки фіксованого розміру. Це засновано на концепціях віртуальної пам’яті та сторінок, які використовуються операційними системами.

Відповідно до vLLM папері, кеш уваги кожної послідовності маркерів розділений на блоки та зіставлений із фізичними блоками через таблицю блоків. Під час обчислення уваги ядро ​​PagedAttention може використовувати таблицю блоків для ефективного отримання блоків із фізичної пам’яті. Це призводить до значного зменшення втрати пам’яті та дозволяє збільшити розмір пакета, збільшити використання графічного процесора та збільшити пропускну здатність.

Порівняння продуктивності

Щоб забезпечити ефективне навантажувальне тестування вашої конфігурації розгортання, рекомендується почати з розгляду бізнес-сценарію та чіткого визначення характеристик вхідних і вихідних даних для програми на основі LLM. Наприклад, якщо ви працюєте над узагальненим випадком використання кол-центру, вхідні дані можуть складатися з більшого тексту, наприклад стенограми чату між агентом служби підтримки клієнтів і клієнтом із 500 маркерів, але результат може бути відносно меншим, близько 100 лексеми, що представляють короткий зміст транскрипту. З іншого боку, якщо ви працюєте над сценарієм генерації коду, вхідні дані можуть бути короткими, як-от 15 токенів, наприклад «написати ефективну реалізацію на Python для опису всіх ресурсів EC2, включаючи розбиття на сторінки», але вихід може бути значно більше, досягаючи 500 жетонів. Також важливо розглянути, чи є досягнення меншої затримки чи максимізація пропускної здатності головним пріоритетом для вашого конкретного сценарію.

Отримавши повне розуміння бізнес-сценарію, ви зможете проаналізувати та визначити оптимальну конфігурацію для свого хостингового середовища. У цьому контексті середовище розміщення охоплює різні ключові елементи, включаючи тип екземпляра та інші параметри конфігурації, такі як tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, і більше. Наша мета полягає в тому, щоб визначити найефективнішу установку для підтримки наших вимог щодо часу відгуку, пропускної здатності та якості вихідних даних моделі.

У нашому аналізі ми порівнювали продуктивність, щоб проілюструвати переваги безперервного пакетування перед традиційним динамічним пакетуванням. Ми використовували конфігурації, детально описані в наступній таблиці в serving.properties для динамічного та ітеративного пакетування, використовуючи контейнер LMI на SageMaker.

Динамічне пакетування	Безперервне дозування	Безперервне пакетування з PagedAttention
двигун=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 розмір партії=4 max_batch_delay=100 option.trust_remote_code = true	двигун = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = авто option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = False	двигун = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = авто option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Правда

Дві конфігурації були протестовані для Falcon-40B із типом даних FP16, розгорнутим на ml.g5.48xlarge у кількох різних сценаріях, які представляють реальні програми:

• Невелика кількість вхідних токенів із великою кількістю токенів, що генеруються – У цьому сценарії кількість вхідних токенів було зафіксовано на рівні 32 і згенеровано 128 нових токенів.

Стратегія пакетування	Пропускна здатність (токенів/с)	Затримка p90 (сек.)
Динамічне пакетування	5.53	58.34
Безперервне дозування	56.04	4.74
Безперервне пакетування з PagedAttention	59.18	4.76

• Великий вхід із невеликою кількістю токенів, що генеруються – Тут ми фіксуємо кількість вхідних токенів на 256 і пропонуємо LLM підсумувати вхідні дані до 32 токенів.

Стратегія пакетування	Пропускна здатність (токенів/с)	Затримка p90 (сек.)
Динамічне пакетування	19.96	59.31
Безперервне дозування	46.69	3.88
Безперервне пакетування з PagedAttention	44.75	2.67

Ми бачимо, що безперервне пакетування за допомогою PagedAttention забезпечує підвищення пропускної здатності в 10 разів у сценарії 1 і в 2.3 рази у сценарії 2 порівняно з використанням динамічного пакетування на SageMaker під час використання контейнера LMI.

Висновок

У цій публікації ми розглянули, як LLM використовують пам’ять, і пояснили, як безперервне пакетування покращує пропускну здатність за допомогою контейнера LMI на SageMaker. Ми продемонстрували переваги безперервного дозування для Falcon-40B за допомогою контейнера LMI на SageMaker, показавши результати тестування. Ви можете знайти код на GitHub репо.

---

Про авторів

Абхі Шивадітья є старшим архітектором рішень в AWS, який працює зі стратегічними глобальними корпоративними організаціями, щоб сприяти впровадженню послуг AWS у таких сферах, як штучний інтелект, розподілені обчислення, мережі та зберігання. Його досвід полягає в глибокому навчанні в областях обробки природної мови (NLP) і комп’ютерного зору. Abhi допомагає клієнтам ефективно розгортати високопродуктивні моделі машинного навчання в екосистемі AWS.

Дхавал Патель є головним архітектором машинного навчання в AWS. Він працював з організаціями, починаючи від великих підприємств і закінчуючи стартапами середнього розміру, над проблемами, пов’язаними з розподіленими обчисленнями та штучним інтелектом. Він зосереджується на глибокому навчанні, включаючи домени НЛП та комп’ютерного зору. Він допомагає клієнтам досягти високопродуктивної моделі висновку на SageMaker.

Pinak Panigrahi працює з клієнтами над створенням рішень на основі машинного навчання для вирішення стратегічних бізнес-завдань на AWS. Коли він не займається машинним навчанням, його можна знайти в поході, читанні книги або перегляді спортивних змагань.

Абхі Содхані обіймає посаду старшого архітектора рішень AI/ML в AWS, де він спеціалізується на пропонуванні клієнтам технічної експертизи та вказівок щодо рішень Generative AI та ML. Його основна увага полягає в тому, щоб допомогти Digital Native Businesss реалізувати весь потенціал технологій Generative AI і ML, дозволяючи їм ефективно досягати своїх бізнес-цілей. Окрім професійних зусиль, Абхі демонструє сильну пристрасть до інтелектуальних занять, таких як читання, а також до участі в діяльності, яка сприяє фізичному та психічному благополуччю, наприклад до йоги, медитації.

Цин Лан є інженером з розробки програмного забезпечення в AWS. Він працював над декількома складними продуктами в Amazon, включаючи високоефективні рішення ML inference та високоефективну систему журналювання. Команда Ціна успішно запустила першу модель із мільярдами параметрів у Amazon Advertising із дуже малою затримкою. Qing має глибокі знання щодо оптимізації інфраструктури та прискорення глибокого навчання.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/