Розгорніть BLOOM-176B і OPT-30B на Amazon SageMaker із великими контейнерами глибокого навчання та DeepSpeed.

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

У попередній публікації ми обговорювали можливості та настроювані параметри in Розгортання моделі Amazon SageMaker це може полегшити висновки з цими великими моделями. Сьогодні ми оголошуємо новий Amazon SageMaker Контейнер глибокого навчання (DLC), який можна використовувати, щоб за лічені хвилини почати розробку великих моделей. Це DLC Пакує деякі з найпопулярніших бібліотек з відкритим вихідним кодом для паралельного виведення моделі, таких як DeepSpeed ​​і Hugging Face Accelerate.

У цьому дописі ми використовуємо новий DLC SageMaker для визначення великої моделі для розгортання двох найпопулярніших великих моделей NLP: BigScience. БЛУМ-176Б і Мета ОПТ-30Б зі сховища Hugging Face. Зокрема, ми використовуємо техніку обслуговування Deep Java Library (DJL) і тензорний паралелізм від DeepSpeed, щоб досягти затримки 0.1 секунди на маркер у випадку використання генерації тексту.

Ви можете знайти наші повні приклади зошитів у нашому GitHub сховище.

Методи висновку великої моделі

Мовні моделі нещодавно вибухнули як у розмірі, так і в популярності. Завдяки легкому доступу з модельних зоопарків, таких як Hugging Face, і покращеній точності та продуктивності завдань НЛП, таких як класифікація та створення тексту, практики все частіше тягнуться до цих великих моделей. Однак великі моделі часто занадто великі, щоб поміститися в пам'ять одного прискорювача. Наприклад, для моделі BLOOM-176B може знадобитися понад 350 гігабайт пам'яті прискорювача, що значно перевищує ємність наявних сьогодні апаратних прискорювачів. Це вимагає використання методів паралельного моделювання з таких бібліотек, як DeepSpeed ​​і Hugging Face Accelerate, щоб розподілити модель між кількома прискорювачами для висновку. У цій публікації ми використовуємо Контейнер для висновків великої моделі SageMaker щоб створити та порівняти затримку та пропускну здатність за допомогою цих двох бібліотек з відкритим кодом.

DeepSpeed ​​і Accelerate використовують різні техніки для оптимізації великих мовних моделей для висновків. Ключовою відмінністю є DeepSpeed використання оптимізованих ядер. Ці ядра можуть значно покращити затримку логічного висновку шляхом зменшення вузьких місць у графі обчислень моделі. Оптимізовані ядра може бути важко розробити, і вони, як правило, специфічні для конкретної архітектури моделі; DeepSpeed ​​підтримує популярні великі моделі, такі як OPT і BLOOM, з цими оптимізованими ядрами. Навпаки, бібліотека Accelerate Hugging Face не містить оптимізованих ядер на момент написання. Як ми обговорюємо в нашому розділі результатів, ця різниця відповідає за більшу частину переваги продуктивності, яку DeepSpeed ​​має над Accelerate.

Другою відмінністю між DeepSpeed ​​і Accelerate є тип паралелізму моделі. Accelerate використовує конвеєрний паралелізм, щоб розділити модель між прихованими шарами моделі, тоді як DeepSpeed ​​використовує тензорний паралелізм, щоб розділити самі шари. Конвеєрний паралелізм — це гнучкий підхід, який підтримує більше типів моделей і може покращити пропускну здатність, якщо використовуються більші розміри пакетів. Тензорний паралелізм вимагає більшого зв’язку між графічними процесорами, оскільки рівні моделі можна розповсюджувати на кількох пристроях, але вони можуть покращити затримку логічного висновку шляхом одночасного залучення кількох графічних процесорів. Ви можете дізнатися більше про техніку паралелізму в Вступ до паралелізму моделей та Паралелізм моделі.

Огляд рішення

Для ефективного розміщення великих мовних моделей нам потрібні функції та підтримка в таких ключових областях:

• Побудова та тестування рішень – Враховуючи ітераційну природу розробки ML, нам потрібна здатність будувати, швидко повторювати та тестувати, як буде поводитися кінцева точка висновку, коли ці моделі розміщено на хості, включаючи здатність швидко виходити з ладу. Ці моделі, як правило, можна розмістити лише на більших екземплярах, таких як p4dn або g5, і, враховуючи розмір моделей, може знадобитися деякий час, щоб розкрутити екземпляр висновку та запустити будь-яку ітерацію тесту. Локальне тестування зазвичай має обмеження, оскільки для тестування потрібен аналогічний за розміром екземпляр, а ці моделі нелегко отримати.
• Розгортання та робота в масштабі – Файли моделі потрібно завантажити в екземпляри висновків, що саме по собі є проблемою, враховуючи розмір. Наприклад, Tar / Un-Tar для Bloom-176B займає приблизно 1 годину для створення та ще годину для завантаження. Нам потрібен альтернативний механізм для легкого доступу до файлів моделі.
• Завантаження моделі як синглтона – Для багатопроцесорного процесу нам потрібно переконатися, що модель завантажується лише один раз, щоб ми не зіткнулися з умовами змагання та додатково витрачали непотрібні ресурси. У цій публікації ми покажемо спосіб завантаження безпосередньо з Служба простого зберігання Amazon (Amazon S3). Однак це працює, лише якщо ми використовуємо налаштування за замовчуванням DJL. Крім того, будь-яке масштабування кінцевих точок має бути здатним розкручуватися за кілька хвилин, що вимагає перегляду способів завантаження та розповсюдження моделей.
• Фреймворки шардингу – Ці моделі, як правило, потрібно створювати, як правило, за допомогою механізму паралелізму тензорів або конвеєрного шардингу як типових методів шардингу, і ми маємо вдосконалені концепції, такі як шардинг ZeRO, побудований на основі тензорного шардингу. Додаткову інформацію про методи шардингу див Паралелізм моделі. Для цього ми можемо мати різні комбінації та використовувати фреймворки від NIVIDIA, DeepSpeed ​​та інших. Для цього потрібна можливість тестувати BYOC або використовувати контейнери 1P, ітерувати рішення та запускати порівняльні тести. Ви також можете протестувати різні варіанти хостингу, як-от асинхронний, безсерверний та інші.
• Вибір обладнання – Ваш вибір апаратного забезпечення визначається всіма вищезазначеними пунктами та подальшими моделями трафіку, потребами варіантів використання та розмірами моделей.

У цій публікації ми використовуємо оптимізовані ядра DeepSpeed ​​і методи тензорного паралелізму для розміщення BLOOM-176B і OPT-30B на SageMaker. Ми також порівнюємо результати Accelerate, щоб продемонструвати переваги продуктивності оптимізованих ядер і тензорного паралелізму. Додаткову інформацію про DeepSpeed ​​і Accelerate див DeepSpeed ​​Inference: ефективне визначення моделей трансформаторів у безпрецедентному масштабі та Неймовірно швидкий висновок BLOOM із DeepSpeed ​​і Accelerate.

У цьому прикладі ми використовуємо DJLServing як модель обслуговування. DJLServing — це високопродуктивне універсальне рішення для обслуговування моделей на основі глибокої бібліотеки Java (DJL), яка не залежить від мови програмування. Щоб дізнатися більше про DJL та DJLServing, див Розгортайте великі моделі на Amazon SageMaker за допомогою паралельного висновку моделі DJLServing і DeepSpeed.

Варто зазначити, що оптимізовані ядра можуть призвести до змін точності та модифікованого графіка обчислень, що теоретично може призвести до зміни поведінки моделі. Хоча це іноді може змінити результат висновку, ми не очікуємо, що ці відмінності істотно вплинуть на основні показники оцінки моделі. Тим не менш, практикам рекомендується підтвердити, що результати моделі відповідають очікуванням під час використання цих ядер.

Наступні кроки демонструють, як розгорнути модель BLOOM-176B у SageMaker за допомогою DJLServing і великого контейнера виведення моделі SageMaker. Повний приклад також доступний у нашому GitHub сховище.

Використання образу DLC DJLServing SageMaker

Скористайтеся наведеним нижче кодом, щоб використовувати образ DLC DJLServing SageMaker після заміни регіону вашим конкретним регіоном, у якому ви використовуєте ноутбук:

763104351884.dkr.ecr..amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113
# example uri might be like 763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113

Створіть наш файл моделі

Спочатку ми створюємо файл під назвою serving.properties який містить лише один рядок коду. Це говорить серверу моделі DJL використовувати механізм DeepSpeed. Файл містить такий код:

engine=DeepSpeed

serving.properties це файл, визначений DJLServing, який використовується для налаштування конфігурації для кожної моделі.

Далі створюємо свій model.py файл, який визначає код, необхідний для завантаження та подальшого обслуговування моделі. У нашому коді ми читаємо в TENSOR_PARALLEL_DEGREE змінна середовища (за замовчуванням 1). Це встановлює кількість пристроїв, на які розподіляються тензорні паралельні модулі. Зауважте, що DeepSpeed ​​надає кілька вбудованих визначень розділів, у тому числі для моделей BLOOM. Ми використовуємо його, вказуючи replace_method та relpace_with_kernel_inject. Якщо у вас є налаштована модель і вам потрібна DeepSpeed ​​для ефективного розділення, вам потрібно змінити її relpace_with_kernel_inject до false і додати injection_policy щоб розділ часу виконання працював. Для отримання додаткової інформації див Ініціалізація для висновку. Для нашого прикладу ми використали попередньо розділену модель BLOOM на DeepSpeed.

По-друге, в model.py файл, ми також завантажуємо модель з Amazon S3 після розкручування кінцевої точки. Модель завантажується в /tmp місця в контейнері, оскільки SageMaker відображає /tmp до Магазин еластичних блоків Amazon Том (Amazon EBS), який монтується, коли ми вказуємо параметр створення кінцевої точки VolumeSizeInGB. Для таких екземплярів, як p4dn, які попередньо зібрані з екземпляром volume, ми можемо продовжувати використовувати /tmp на контейнері. Перегляньте наступний код:

from djl_python import Input, Output
import os
import deepspeed
import torch
import torch.distributed as dist
import sys
import subprocess
import time
from glob import glob
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer
from transformers.models.opt.modeling_opt import OPTDecoderLayer

predictor = None

def check_config():
    local_rank = os.getenv('LOCAL_RANK')
    
    if not local_rank:
        return False
    return True
    
def get_model():

    if not check_config():
        raise Exception("DJL:DeepSpeed configurations are not default. This code does not support non default configurations") 
    
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model_dir = "/tmp/model"
    bucket = os.environ.get("MODEL_S3_BUCKET")
    key_prefix = os.environ.get("MODEL_S3_PREFIX")
    print(f"rank: {local_rank}")
    if local_rank == 0:
        if f"{model_dir}/DONE" not in glob(f"{model_dir}/*"):
            print("Starting Model downloading files")
            try:
                proc_run = subprocess.run(
                    ["aws", "s3", "cp", "--recursive", f"s3://{bucket}/{key_prefix}", model_dir]
                )
                print("Model downloading finished")
                # write file when download complete. Could use dist.barrier() but this makes it easier to check if model is downloaded in case of retry
                with open(f"{model_dir}/DONE", "w") as f:
                    f.write("download_complete")
                    
                proc_run.check_returncode() # to throw the error in case there was one
                
            except subprocess.CalledProcessError as e:
                print ( "Model download failed: Error:nreturn code: ", e.returncode, "nOutput: ", e.stderr )
                raise # FAIL FAST  
                               
    dist.barrier()
                
    
    tokenizer = AutoTokenizer.from_pretrained(model_dir)
    
    # has to be FP16 as Int8 model loading not yet supported
    with deepspeed.OnDevice(dtype=torch.float16, device="meta"):
        model = AutoModelForCausalLM.from_config(
            AutoConfig.from_pretrained(model_dir), torch_dtype=torch.bfloat16
        )
    model = model.eval()
    
    model = deepspeed.init_inference(
        model,
        mp_size=tensor_parallel,
        dtype=torch.int8,
        base_dir = model_dir,
        checkpoint=os.path.join(model_dir, "ds_inference_config.json"),
        replace_method='auto',
        replace_with_kernel_inject=True
    )

    model = model.module
    dist.barrier()
    return model, tokenizer

DJLServing керує інсталяцією середовища виконання будь-яких пакетів pip, визначених у requirement.txt. Цей файл матиме:

awscli
boto3

Ми створили каталог під назвою code і model.py, serving.properties та requirements.txt файлів уже створено в цьому каталозі. Щоб переглянути файли, ви можете запустити наступний код із терміналу:

mkdir -p code
cat code/model.py 
cat code/serving.properties 
cat code/requirements.txt 

На наступному малюнку показано структуру model.tar.gz.

Нарешті, ми створюємо файл моделі та завантажуємо його в Amazon S3:

tar cvfz model.tar.gz code
s3_code_artifact = sess.upload_data("model.tar.gz", bucket, s3_code_prefix)

Завантажте та збережіть модель із Hugging Face (необов’язково)

Ми надали кроки в цьому розділі, якщо ви хочете завантажити модель на Amazon S3 і використовувати її звідти. Ці кроки наведено у файлі Jupyter на GitHub. На наступному знімку екрана показано знімок кроків.

Створіть модель SageMaker

Тепер ми створюємо a Модель SageMaker. Ми використовуємо Реєстр контейнерів Amazon Elastic Зображення (Amazon ECR), надане та артефакт моделі з попереднього кроку для створення моделі SageMaker. У налаштуваннях моделі ми налаштовуємо TENSOR_PARALLEL_DEGREE=8, що означає, що модель розділена на 8 GPU. Перегляньте наступний код:

PrimaryContainer={
        "Image": inference_image_uri,
        "ModelDataUrl": s3_code_artifact,
        "Environment": {
            "MODEL_S3_BUCKET": bucket,
            "MODEL_S3_PREFIX": s3_model_prefix,
            "TENSOR_PARALLEL_DEGREE": "8",
},

Після запуску попередньої клітинки у файлі Jupyter ви побачите результат, подібний до такого:

{
    "ModelArn": "arn:aws:sagemaker:us-east-1::model/bloom-djl-ds-"
}

Створіть кінцеву точку SageMaker

Для тестування можна використовувати будь-які екземпляри з кількома графічним процесором. У цій демонстрації ми використовуємо екземпляр p4d.24xlarge. У наступному коді зверніть увагу на те, як ми встановили ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds та VolumeSizeInGB параметри для розміщення великого розміру моделі. The VolumeSizeInGB Параметр застосовний до екземплярів графічного процесора, що підтримують приєднання тому EBS.

endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.p4d.24xlarge",
            "InitialInstanceCount": 1,
            #"VolumeSizeInGB" : 200,
            "ModelDataDownloadTimeoutInSeconds": 2400,
            "ContainerStartupHealthCheckTimeoutInSeconds": 2400,
        },
    ],
)'

Нарешті, ми створюємо кінцеву точку SageMaker:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=f"{endpoint_name}", EndpointConfigName=endpoint_config_name
)

Ви бачите його надрукованим у такому коді:

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1::endpoint/bloom-djl-ds-"
}

Запуск кінцевої точки може зайняти деякий час. Ви можете спробувати ще кілька разів, якщо зіткнетеся з InsufficientInstanceCapacity або ви можете подати запит до AWS на збільшення ліміту у вашому обліковому записі.

Налаштування продуктивності

Якщо ви збираєтеся використовувати цю публікацію та супровідний ноутбук з іншою моделлю, ви можете вивчити деякі настроювані параметри, які пропонують SageMaker, DeepSpeed ​​і DJL. Ітераційне експериментування з цими параметрами може істотно вплинути на затримку, пропускну спроможність і вартість вашої розміщеної великої моделі. Щоб дізнатися більше про параметри налаштування, такі як кількість працівників, ступінь паралелізму тензорів, розмір черги завдань та інші, зверніться до Конфігурації обслуговування DJL та Розгортайте великі моделі на Amazon SageMaker за допомогою паралельного висновку моделі DJLServing і DeepSpeed.

результати

У цьому дописі ми використовували DeepSpeed ​​для розміщення BLOOM-176B і OPT-30B на примірниках SageMaker ML. У наведеній нижче таблиці підсумовуються наші результати продуктивності, включаючи порівняння з Accelerate від Hugging Face. Затримка відображає кількість мілісекунд, необхідних для створення рядка з 256 маркерів чотири рази (batch_size=4) від моделі. Пропускна здатність відображає кількість токенів, вироблених за секунду для кожного тесту. Для Hugging Face Accelerate ми використовували стандартне завантаження бібліотеки з відображенням пам’яті GPU. Для DeepSpeed ​​ми використали швидший механізм завантаження контрольних точок.

З точки зору затримки, DeepSpeed ​​приблизно в 3.4 рази швидше для BLOOM-176B і в 5.6 разів швидше для OPT-30B, ніж Accelerate. Оптимізовані ядра DeepSpeed ​​значною мірою відповідають за цю різницю в затримці. Враховуючи ці результати, ми рекомендуємо використовувати DeepSpeed ​​замість Accelerate, якщо обрана вами модель підтримується.

Варто також зазначити, що час завантаження моделі з DeepSpeed ​​був набагато коротшим, що робить його кращим варіантом, якщо ви очікуєте, що потрібно буде швидко збільшити кількість кінцевих точок. Більш гнучка техніка паралелізму конвеєрів Accelerate може бути кращим варіантом, якщо у вас є моделі або точність моделі, які не підтримуються DeepSpeed.

Ці результати також демонструють різницю в затримці та пропускній здатності моделей різних розмірів. У наших тестах OPT-30B генерує в 2.4 рази більше токенів за одиницю часу, ніж BLOOM-176B на типі екземпляра, який більш ніж утричі дешевший. За ціною за одиницю пропускної здатності OPT-30B на примірнику g5.24xl у 8.9 разів кращий, ніж BLOOM-176B на примірнику p4d.24xl. Якщо у вас є суворі обмеження щодо затримки, пропускної спроможності чи вартості, подумайте про використання найменшої моделі, яка все ж відповідатиме функціональним вимогам.

Прибирати

У рамках передових практик завжди рекомендується видаляти неактивні екземпляри. Наведений нижче код показує, як видалити екземпляри.

# - Delete the end point
sm_client.delete_endpoint(EndpointName=endpoint_name)

# - In case the end point failed we still want to delete the model
sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name)
sm_client.delete_model(ModelName=model_name)

За бажанням можна видалити контрольну точку моделі з вашого S3

!aws s3 rm --recursive s3:///{s3_model_prefix}

Висновок

У цьому дописі ми продемонстрували, як використовувати великі контейнери виведення моделі SageMaker для розміщення двох великих мовних моделей, BLOOM-176B і OPT-30B. Ми використовували методи паралельної моделі DeepSpeed ​​із кількома графічними процесорами в одному екземплярі SageMaker ML.

Щоб отримати докладніші відомості про Amazon SageMaker і його можливості створення великих моделей, див Amazon SageMaker тепер підтримує розгортання великих моделей за допомогою настроюваного розміру тому та квот часу очікування та Висновок у реальному часі.

Про авторів

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

Рупіндер Гревал є старшим архітектором рішень Ai/ML в AWS. Зараз він зосереджується на обслуговуванні моделей і MLO на SageMaker. До цієї посади він працював інженером машинного навчання, створюючи та розміщуючи моделі. Поза роботою він любить грати в теніс і їздити на велосипеді гірськими стежками.

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

Алан Тан є старшим менеджером із продуктів у компанії SageMaker, яка займається розробкою великих моделей. Він захоплений застосуванням машинного навчання в галузі аналітики. Поза роботою любить відпочивати на природі.

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

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

Цінвей Лі є спеціалістом з машинного навчання в Amazon Web Services. Отримав ступінь доктора філософії. в дослідженні операцій після того, як він зламав грантовий рахунок свого радника і не вручив обіцяну Нобелівську премію. Зараз він допомагає клієнтам у сфері фінансових послуг і страхування створювати рішення машинного навчання на AWS. У вільний час любить читати та викладати.

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

Сіддхарт Венкатесан є розробником програмного забезпечення в AWS Deep Learning. Зараз він зосереджується на розробці рішень для виведення великих моделей. До AWS він працював в організації Amazon Grocery, розробляючи нові платіжні функції для клієнтів у всьому світі. Поза роботою він любить кататися на лижах, гуляти на природі та дивитися спортивні змагання.