Implementați BLOOM-176B și OPT-30B pe Amazon SageMaker cu modele mari de inferență Deep Learning Containers și DeepSpeed

Ultimii ani au cunoscut o dezvoltare rapidă în domeniul învățării profunde. Deși hardware-ul s-a îmbunătățit, cum ar fi cu cea mai recentă generație de acceleratoare de la NVIDIA și Amazon, practicienii avansati de învățare automată (ML) întâmpină în mod regulat probleme la implementarea modelelor lor mari de învățare profundă pentru aplicații precum procesarea limbajului natural (NLP).

Într-o postare anterioară, am discutat capabilități și setări configurabile in Implementarea modelului Amazon SageMaker care poate face mai ușoară inferența cu aceste modele mari. Astăzi, anunțăm un nou Amazon SageMaker Container de învățare profundă (DLC) pe care îl puteți folosi pentru a începe cu inferența modelului mare în câteva minute. Acest DLC include unele dintre cele mai populare biblioteci open-source pentru inferența paralelă a modelelor, cum ar fi DeepSpeed ​​și Hugging Face Accelerate.

În această postare, folosim un nou DLC de inferență pentru modele mari SageMaker pentru a implementa două dintre cele mai populare modele NLP mari: BigScience BLOOM-176B și a lui Meta OPT-30B din depozitul Hugging Face. În special, folosim tehnici de servire Deep Java Library (DJL) și de paralelism tensor de la DeepSpeed ​​pentru a obține o latență de 0.1 secunde per token într-un caz de utilizare pentru generarea de text.

Puteți găsi exemplele noastre de caiete complete în site-ul nostru GitHub depozit.

Tehnici de inferență pe modele mari

Modelele lingvistice au explodat recent atât ca dimensiune, cât și ca popularitate. Cu acces ușor de la grădini zoologice model, cum ar fi Hugging Face și o precizie și performanță îmbunătățite în sarcinile NLP, cum ar fi clasificarea și generarea de text, practicienii caută din ce în ce mai mult aceste modele mari. Cu toate acestea, modelele mari sunt adesea prea mari pentru a se încadra în memoria unui singur accelerator. De exemplu, modelul BLOOM-176B poate necesita mai mult de 350 de gigaocteți de memorie acceleratoare, ceea ce depășește cu mult capacitatea acceleratoarelor hardware disponibile în prezent. Acest lucru necesită utilizarea tehnicilor paralele de model din biblioteci precum DeepSpeed ​​și Hugging Face Accelerate pentru a distribui un model pe mai multe acceleratoare pentru inferență. În această postare, folosim Container de inferență model mare SageMaker pentru a genera și compara performanța latenței și a debitului folosind aceste două biblioteci open-source.

DeepSpeed ​​și Accelerate folosesc tehnici diferite pentru a optimiza modele mari de limbaj pentru inferență. Diferența cheie este cea a lui DeepSpeed utilizarea de nuclee optimizate. Aceste nuclee pot îmbunătăți în mod dramatic latența de inferență prin reducerea blocajelor în graficul de calcul al modelului. Nucleele optimizate pot fi dificil de dezvoltat și sunt de obicei specifice unei anumite arhitecturi de model; DeepSpeed ​​acceptă modele mari populare, cum ar fi OPT și BLOOM, cu aceste nuclee optimizate. În schimb, biblioteca Accelerate a lui Hugging Face nu include nuclee optimizate la momentul scrierii. După cum discutăm în secțiunea noastră de rezultate, această diferență este responsabilă pentru mare parte din avantajul de performanță pe care DeepSpeed ​​îl are față de Accelerate.

O a doua diferență între DeepSpeed ​​și Accelerate este tipul de paralelism al modelului. Accelerate folosește paralelismul conductei pentru a partiționa un model între straturile ascunse ale unui model, în timp ce DeepSpeed ​​folosește paralelismul tensorului pentru a împărți straturile în sine. Paralelismul conductelor este o abordare flexibilă care acceptă mai multe tipuri de model și poate îmbunătăți debitul atunci când sunt utilizate dimensiuni mai mari de loturi. Paralelismul tensorului necesită mai multă comunicare între GPU-uri, deoarece straturile de model pot fi răspândite pe mai multe dispozitive, dar pot îmbunătăți latența de inferență prin angajarea mai multor GPU-uri simultan. Puteți afla mai multe despre tehnicile de paralelism în Introducere în paralelismul modelului și Paralelism de model.

Prezentare generală a soluțiilor

Pentru a găzdui eficient modele de limbă mari, avem nevoie de funcții și asistență în următoarele domenii cheie:

• Construirea și testarea soluțiilor – Având în vedere natura iterativă a dezvoltării ML, avem nevoie de capacitatea de a construi, de a repeta rapid și de a testa modul în care punctul final de inferență se va comporta atunci când aceste modele sunt găzduite, inclusiv capacitatea de a eșua rapid. Aceste modele pot fi de obicei găzduite numai pe instanțe mai mari, cum ar fi p4dn sau g5 și, având în vedere dimensiunea modelelor, poate dura ceva timp pentru a porni o instanță de inferență și a rula orice iterație de testare. Testarea locală are de obicei constrângeri, deoarece aveți nevoie de o instanță similară ca dimensiune pentru a testa, iar aceste modele nu sunt ușor de obținut.
• Implementarea și rularea la scară – Fișierele model trebuie încărcate în instanțe de inferență, ceea ce reprezintă o provocare în sine, având în vedere dimensiunea. Tar / Un-Tar ca exemplu pentru Bloom-176B durează aproximativ 1 oră pentru a crea și încă o oră pentru a încărca. Avem nevoie de un mecanism alternativ pentru a permite accesul ușor la fișierele model.
• Se încarcă modelul ca singleton – Pentru un proces cu mai mulți lucrători, trebuie să ne asigurăm că modelul este încărcat o singură dată, astfel încât să nu ne confruntăm cu condiții de cursă și să cheltuim în continuare resurse inutile. În această postare, arătăm o modalitate de a încărca direct de la Serviciul Amazon de stocare simplă (Amazon S3). Cu toate acestea, acest lucru funcționează numai dacă folosim setările implicite ale DJL. În plus, orice scalare a punctelor finale trebuie să se poată rula în câteva minute, ceea ce necesită reconsiderarea modului în care modelele ar putea fi încărcate și distribuite.
• Fragmentarea cadrelor – Aceste modele trebuie de obicei să fie , de obicei printr-un mecanism de paralelism tensor sau prin sharding pipeline, ca tehnici tipice de sharding, și avem concepte avansate precum ZeRO sharding construit pe partea de sus a sharding tensor. Pentru mai multe informații despre tehnicile de fragmentare, consultați Paralelism de model. Pentru a realiza acest lucru, putem avea diverse combinații și folosi cadre de la NIVIDIA, DeepSpeed ​​și altele. Acest lucru necesită capacitatea de a testa BYOC sau de a utiliza containere 1P și de a repeta soluții și de a rula teste de evaluare comparativă. De asemenea, este posibil să doriți să testați diverse opțiuni de găzduire, cum ar fi asincron, fără server și altele.
• Selectarea hardware-ului – Alegerea ta în materie de hardware este determinată de toate punctele menționate mai sus și de modelele de trafic ulterioare, nevoile cazurilor de utilizare și dimensiunile modelului.

În această postare, folosim nucleele optimizate DeepSpeed ​​și tehnicile de paralelism tensor pentru a găzdui BLOOM-176B și OPT-30B pe SageMaker. De asemenea, comparăm rezultatele de la Accelerate pentru a demonstra beneficiile de performanță ale nucleelor ​​optimizate și paralelismului tensorului. Pentru mai multe informații despre DeepSpeed ​​și Accelerate, consultați DeepSpeed ​​Inference: Permiterea inferenței eficiente a modelelor de transformatoare la o scară fără precedent și Inferență BLOOM incredibil de rapidă cu DeepSpeed ​​și Accelerate.

Folosim DJLServing ca soluție de servire model în acest exemplu. DJLServering este o soluție universală de servire a modelelor de înaltă performanță, alimentată de Deep Java Library (DJL), care este independentă de limbajul de programare. Pentru a afla mai multe despre DJL și DJLServing, consultați Implementați modele mari pe Amazon SageMaker folosind DJLServing și inferența paralelă a modelului DeepSpeed.

Este demn de remarcat faptul că nucleele optimizate pot duce la modificări de precizie și un grafic de calcul modificat, care ar putea duce, teoretic, la modificarea comportamentului modelului. Deși acest lucru ar putea schimba ocazional rezultatul inferenței, nu ne așteptăm ca aceste diferențe să aibă un impact material asupra valorilor de bază ale evaluării unui model. Cu toate acestea, practicienii sunt sfătuiți să confirme că rezultatele modelului sunt cele așteptate atunci când folosesc aceste nuclee.

Următorii pași demonstrează cum să implementați un model BLOOM-176B în SageMaker utilizând DJLServing și un container de inferență model mare SageMaker. Exemplul complet este disponibil și în pagina noastră GitHub depozit.

Utilizarea imaginii DJLServing SageMaker DLC

Utilizați următorul cod pentru a utiliza imaginea DJLServing SageMaker DLC după înlocuirea regiunii cu regiunea dvs. specifică în care rulați notebook-ul:

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

Creați fișierul nostru model

Mai întâi, creăm un fișier numit serving.properties care conține o singură linie de cod. Aceasta îi spune serverului model DJL să folosească motorul DeepSpeed. Fișierul conține următorul cod:

engine=DeepSpeed

serving.properties este un fișier definit de DJLServing care este utilizat pentru a configura configurația per model.

În continuare, ne creăm model.py fișier, care definește codul necesar pentru a încărca și apoi a servi modelul. În codul nostru, citim în TENSOR_PARALLEL_DEGREE variabilă de mediu (valoarea implicită este 1). Aceasta stabilește numărul de dispozitive peste care sunt distribuite modulele paralele tensor. Rețineți că DeepSpeed ​​oferă câteva definiții de partiții încorporate, inclusiv una pentru modelele BLOOM. O folosim prin specificare replace_method și relpace_with_kernel_inject. Dacă aveți un model personalizat și aveți nevoie de DeepSpeed ​​pentru a partiționa eficient, trebuie să îl schimbați relpace_with_kernel_inject la false și adăugați injection_policy pentru a face partiția de rulare să funcționeze. Pentru mai multe informații, consultați Inițializare pentru inferență. Pentru exemplul nostru, am folosit modelul BLOOM pre-partiționat pe DeepSpeed.

În al doilea rând, în model.py fișier, încărcăm și modelul de pe Amazon S3 după ce punctul final a fost rotit. Modelul este încărcat în /tmp spațiu pe container deoarece SageMaker mapează /tmp la Magazin Amazon Elastic Block (Amazon EBS) volum care este montat atunci când specificăm parametrul de creare a punctului final VolumeSizeInGB. Pentru cazuri precum p4dn, care sunt pre-construite cu instanța de volum, putem continua să folosim /tmp pe recipient. Vezi următorul cod:

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 gestionează instalarea runtime pe orice pachet pip definit în requirement.txt. Acest fișier va avea:

awscli
boto3

Am creat un director numit code si model.py, serving.properties, și requirements.txt fișierele sunt deja create în acest director. Pentru a vizualiza fișierele, puteți rula următorul cod de pe terminal:

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

Următoarea figură prezintă structura model.tar.gz.

În cele din urmă, creăm fișierul model și îl încărcăm pe Amazon S3:

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

Descărcați și stocați modelul din Hugging Face (Opțional)

Am furnizat pașii din această secțiune în cazul în care doriți să descărcați modelul pe Amazon S3 și să îl utilizați de acolo. Pașii sunt furnizați în fișierul Jupyter de pe GitHub. Următoarea captură de ecran arată un instantaneu al pașilor.

Creați un model SageMaker

Acum creăm un Modelul SageMaker. Noi folosim Registrul Amazon de containere elastice (Amazon ECR) imagine furnizată de și artefactul model de la pasul anterior pentru a crea modelul SageMaker. În configurarea modelului, configuram TENSOR_PARALLEL_DEGREE=8, ceea ce înseamnă că modelul este partiționat de-a lungul a 8 GPU-uri. Vezi următorul cod:

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

După ce rulați celula anterioară în fișierul Jupyter, vedeți rezultate similare cu următoarea:

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

Creați un punct final SageMaker

Puteți utiliza orice instanțe cu mai multe GPU-uri pentru testare. În această demonstrație, folosim o instanță p4d.24xlarge. În următorul cod, observați cum am setat ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds, și VolumeSizeInGB parametrii pentru a se potrivi cu dimensiunea mare a modelului. The VolumeSizeInGB parametrul este aplicabil instanțelor GPU care acceptă atașarea volumului 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,
        },
    ],
)'

În cele din urmă, creăm un punct final SageMaker:

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

Îl vezi tipărit în următorul cod:

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

Pornirea punctului final poate dura ceva timp. Puteți încerca încă de câteva ori dacă dați peste InsufficientInstanceCapacity eroare sau puteți trimite o solicitare către AWS pentru a crește limita din contul dvs.

Reglarea performanței

Dacă intenționați să utilizați această postare și notebook-ul însoțitor cu un alt model, poate doriți să explorați unii dintre parametrii reglabili pe care îi oferă SageMaker, DeepSpeed ​​și DJL. Experimentarea iterativă cu acești parametri poate avea un impact material asupra latenței, debitului și costului modelului mare găzduit. Pentru a afla mai multe despre parametrii de reglare, cum ar fi numărul de lucrători, gradul de paralelism tensor, dimensiunea cozii de joburi și altele, consultați Configurații de servire DJL și Implementați modele mari pe Amazon SageMaker folosind DJLServing și inferența paralelă a modelului DeepSpeed.

REZULTATE

În această postare, am folosit DeepSpeed ​​pentru a găzdui BLOOM-176B și OPT-30B pe instanțe SageMaker ML. Următorul tabel rezumă rezultatele noastre de performanță, inclusiv o comparație cu Accelerate de la Hugging Face. Latența reflectă numărul de milisecunde necesare pentru a produce un șir de 256 de jetoane de patru ori (batch_size=4) din model. Debitul reflectă numărul de jetoane produse pe secundă pentru fiecare test. Pentru Hugging Face Accelerate, am folosit încărcarea implicită a bibliotecii cu maparea memoriei GPU. Pentru DeepSpeed, am folosit mecanismul său mai rapid de încărcare a punctelor de control.

Din punct de vedere al latenței, DeepSpeed ​​este de aproximativ 3.4 ori mai rapid pentru BLOOM-176B și de 5.6 ori mai rapid pentru OPT-30B decât Accelerate. Nucleele optimizate ale DeepSpeed ​​sunt responsabile pentru o mare parte a acestei diferențe de latență. Având în vedere aceste rezultate, vă recomandăm să utilizați DeepSpeed ​​peste Accelerate dacă modelul dorit este acceptat.

De asemenea, merită remarcat faptul că timpii de încărcare a modelului cu DeepSpeed ​​au fost mult mai scurti, făcându-l o opțiune mai bună dacă anticipați că trebuie să vă măriți rapid numărul de puncte finale. Tehnica de paralelism a conductelor mai flexibilă a Accelerate poate fi o opțiune mai bună dacă aveți modele sau precizii de model care nu sunt acceptate de DeepSpeed.

Aceste rezultate demonstrează, de asemenea, diferența de latență și debit al diferitelor dimensiuni de model. În testele noastre, OPT-30B generează de 2.4 ori mai mult numărul de jetoane pe unitate de timp decât BLOOM-176B pe un tip de instanță care este de peste trei ori mai ieftin. Pe baza prețului pe unitate, OPT-30B pe o instanță g5.24xl este de 8.9 ori mai bun decât BLOOM-176B pe o instanță p4d.24xl. Dacă aveți limitări stricte de latență, debit sau costuri, luați în considerare utilizarea celui mai mic model posibil care va îndeplini totuși cerințele funcționale.

A curăța

Ca parte a celor mai bune practici, este întotdeauna recomandat să ștergeți instanțe inactive. Codul de mai jos vă arată cum să ștergeți instanțele.

# - 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)

Opțional, ștergeți punctul de verificare a modelului de pe S3

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

Concluzie

În această postare, am demonstrat cum să folosiți containerele de inferență pentru modele mari SageMaker pentru a găzdui două modele mari de limbaj, BLOOM-176B și OPT-30B. Am folosit tehnicile paralele model DeepSpeed ​​cu mai multe GPU-uri pe o singură instanță SageMaker ML.

Pentru mai multe detalii despre Amazon SageMaker și capacitățile sale mari de inferență ale modelului, consultați Amazon SageMaker acceptă acum implementarea modelelor mari prin dimensiunea volumului configurabil și cote de expirare și Inferință în timp real.

Despre autori

Simon Zamarin este un arhitect de soluții AI/ML al cărui obiectiv principal este să îi ajute pe clienți să extragă valoare din activele lor de date. În timpul liber, lui Simon îi place să petreacă timpul cu familia, să citească SF și să lucreze la diverse proiecte de bricolaj.

Rupinder Grewal este un arhitect specializat în soluții Sr Ai/ML cu AWS. În prezent, se concentrează pe servirea modelelor și a MLOps-ului pe SageMaker. Înainte de acest rol, a lucrat ca inginer de învățare automată, construind și găzduind modele. În afara serviciului, îi place să joace tenis și să meargă cu bicicleta pe traseele montane.

Frank Liu este inginer software pentru AWS Deep Learning. El se concentrează pe construirea de instrumente inovatoare de deep learning pentru inginerii software și oamenii de știință. În timpul liber, îi place drumețiile cu prietenii și familia.

Alan Tan este manager de produs senior, iar SageMaker conduce eforturile pentru inferența modelelor mari. Este pasionat de aplicarea Machine Learning-ului în domeniul Analytics. În afara serviciului, se bucură de aer liber.

Dhawal Patel este arhitect principal de învățare automată la AWS. El a lucrat cu organizații, de la întreprinderi mari până la startup-uri mijlocii, pe probleme legate de calculul distribuit și inteligența artificială. El se concentrează pe învățarea profundă, inclusiv pe domeniile NLP și Computer Vision. El îi ajută pe clienți să obțină inferențe de model de înaltă performanță pe SageMaker.

Qing Lan este inginer de dezvoltare software în AWS. El a lucrat la mai multe produse provocatoare în Amazon, inclusiv soluții de inferență ML de înaltă performanță și un sistem de înregistrare de înaltă performanță. Echipa Qing a lansat cu succes primul model cu miliard de parametri în Amazon Advertising, cu o latență foarte scăzută necesară. Qing are cunoștințe aprofundate despre optimizarea infrastructurii și accelerarea Deep Learning.

Qingwei Li este specialist în învățare automată la Amazon Web Services. Și-a primit doctoratul. în Cercetare operațională, după ce a spart contul de grant de cercetare al consilierului său și nu a reușit să dea Premiul Nobel pe care l-a promis. În prezent, ajută clienții din industria serviciilor financiare și a asigurărilor să construiască soluții de învățare automată pe AWS. În timpul liber, îi place să citească și să predea.

Robert Van Dusen este Senior Product Manager cu Amazon SageMaker. El conduce optimizarea modelelor de învățare profundă pentru aplicații precum inferența modelului mare.

Siddharth Venkatesan este inginer software în AWS Deep Learning. În prezent, se concentrează pe construirea de soluții pentru inferența modelelor mari. Înainte de AWS, a lucrat în organizația Amazon Grocery, creând noi funcții de plată pentru clienții din întreaga lume. În afara serviciului, îi place să schieze, în aer liber și să urmărească sporturi.