Implementer BLOOM-176B og OPT-30B på Amazon SageMaker med store modelinferens Deep Learning Containers og DeepSpeed

De seneste par år har der været en rivende udvikling inden for deep learning. Selvom hardware er blevet forbedret, såsom med den seneste generation af acceleratorer fra NVIDIA og Amazon, støder brugere af avanceret maskinlæring (ML) stadig jævnligt på problemer med at implementere deres store deep learning-modeller til applikationer som naturlig sprogbehandling (NLP).

I et tidligere indlæg diskuterede vi muligheder og konfigurerbare indstillinger in Amazon SageMaker-modelimplementering der kan gøre det lettere at konkludere med disse store modeller. I dag annoncerer vi en ny Amazon SageMaker Deep Learning Container (DLC), som du kan bruge til at komme i gang med store modelslutninger på få minutter. Dette DLC pakker nogle af de mest populære open source-biblioteker til model parallel inferens, såsom DeepSpeed ​​og Hugging Face Accelerate.

I dette indlæg bruger vi en ny SageMaker large model inference DLC til at implementere to af de mest populære store NLP-modeller: BigScience's BLOOM-176B og Meta's OPT-30B fra Hugging Face-lageret. Især bruger vi Deep Java Library (DJL)-servering og tensor-parallelisme-teknikker fra DeepSpeed ​​for at opnå 0.1 sekunds latency pr. token i et tekstgenereringsbrug.

Du kan finde vores komplette eksempelnotesbøger i vores GitHub repository.

Inferensteknikker for store modeller

Sprogmodeller er for nylig eksploderet i både størrelse og popularitet. Med nem adgang fra modelzoologiske haver såsom Hugging Face og forbedret nøjagtighed og ydeevne i NLP-opgaver såsom klassificering og tekstgenerering, griber praktikere i stigende grad ud efter disse store modeller. Store modeller er dog ofte for store til at passe ind i hukommelsen på en enkelt accelerator. For eksempel kan BLOOM-176B-modellen kræve mere end 350 gigabyte acceleratorhukommelse, hvilket langt overstiger kapaciteten af ​​hardwareacceleratorer, der er tilgængelige i dag. Dette nødvendiggør brugen af ​​modelparallelle teknikker fra biblioteker som DeepSpeed ​​og Hugging Face Accelerate for at distribuere en model på tværs af flere acceleratorer til slutning. I dette indlæg bruger vi SageMaker stor model inferensbeholder at generere og sammenligne latency og gennemløbsydelse ved hjælp af disse to open source-biblioteker.

DeepSpeed ​​og Accelerate bruger forskellige teknikker til at optimere store sprogmodeller til slutninger. Den vigtigste forskel er DeepSpeeds brug af optimerede kerner. Disse kerner kan dramatisk forbedre inferensforsinkelse ved at reducere flaskehalse i modellens beregningsgraf. Optimerede kerner kan være svære at udvikle og er typisk specifikke for en bestemt modelarkitektur; DeepSpeed ​​understøtter populære store modeller som OPT og BLOOM med disse optimerede kerner. I modsætning hertil inkluderer Hugging Faces Accelerate-bibliotek ikke optimerede kerner i skrivende stund. Som vi diskuterer i vores resultatafsnit, er denne forskel ansvarlig for meget af den præstationsfordel, som DeepSpeed ​​har i forhold til Accelerate.

En anden forskel mellem DeepSpeed ​​og Accelerate er typen af ​​modelparallelisme. Accelerate bruger pipeline-parallelisme til at opdele en model mellem de skjulte lag i en model, hvorimod DeepSpeed ​​bruger tensor-parallelisme til at opdele lagene selv. Rørlednings-parallelisme er en fleksibel tilgang, der understøtter flere modeltyper og kan forbedre gennemløbet, når der bruges større batchstørrelser. Tensorparallelisme kræver mere kommunikation mellem GPU'er, fordi modellag kan spredes på tværs af flere enheder, men kan forbedre inferensforsinkelse ved at engagere flere GPU'er samtidigt. Du kan lære mere om parallelismeteknikker i Introduktion til modelparallelisme , Modelparallelisme.

Løsningsoversigt

For effektivt at være vært for store sprogmodeller har vi brug for funktioner og support på følgende nøgleområder:

• Bygge og teste løsninger – I betragtning af den iterative karakter af ML-udvikling har vi brug for evnen til at bygge, hurtigt iterere og teste, hvordan inferens-endepunktet vil opføre sig, når disse modeller hostes, herunder evnen til at fejle hurtigt. Disse modeller kan typisk kun hostes på større forekomster som p4dn eller g5, og i betragtning af størrelsen af ​​modellerne, kan det tage et stykke tid at spinne en inferensforekomst op og køre enhver testiteration. Lokal test har normalt begrænsninger, fordi du har brug for en lignende instans i størrelse for at teste, og disse modeller er ikke lette at opnå.
• Udrulning og drift i skala – Modelfilerne skal indlæses på inferensforekomsterne, hvilket giver en udfordring i sig selv givet størrelsen. Tar / Un-Tar som et eksempel for Bloom-176B tager omkring 1 time at skabe og endnu en time at indlæse. Vi har brug for en alternativ mekanisme for at give nem adgang til modelfilerne.
• Indlæser modellen som singleton – For en proces med flere arbejdere skal vi sikre, at modellen kun indlæses én gang, så vi ikke løber ind i racerforhold og bruger unødvendige ressourcer yderligere. I dette indlæg viser vi en måde at indlæse direkte fra Amazon Simple Storage Service (Amazon S3). Dette virker dog kun, hvis vi bruger standardindstillingerne for DJL. Ydermere skal enhver skalering af endepunkterne kunne spinne op på få minutter, hvilket kræver genovervejelse af, hvordan modellerne kan indlæses og distribueres.
• Deling af rammer – Disse modeller skal typisk være , normalt ved en tensor-parallelisme-mekanisme eller ved pipeline-sharding som de typiske sharding-teknikker, og vi har avancerede koncepter som ZeRO-sharding bygget oven på tensor-sharding. For mere information om skæringsteknikker, se Modelparallelisme. For at opnå dette kan vi have forskellige kombinationer og bruge rammer fra NIVIDIA, DeepSpeed ​​og andre. Dette kræver evnen til at teste BYOC eller bruge 1P-beholdere og iterere over løsninger og køre benchmarking-tests. Du vil måske også teste forskellige hostingmuligheder som asynkron, serverløs og andre.
• Hardware valg – Dit valg af hardware bestemmes af alle de førnævnte punkter og yderligere trafikmønstre, brugsbehov og modelstørrelser.

I dette indlæg bruger vi DeepSpeeds optimerede kerner og tensorparallelismeteknikker til at hoste BLOOM-176B og OPT-30B på SageMaker. Vi sammenligner også resultater fra Accelerate for at demonstrere ydeevnefordelene ved optimerede kerner og tensorparallelisme. For mere information om DeepSpeed ​​og Accelerate, se DeepSpeed ​​Inference: Muliggør effektiv inferens af transformatormodeller i hidtil uset skala , Utrolig hurtig BLOOM-inferens med DeepSpeed ​​og Accelerate.

Vi bruger DJLServing som model serveringsløsning i dette eksempel. DJLServing er en højtydende universel modelserveringsløsning drevet af Deep Java Library (DJL), der er programmeringssprogsagnostisk. For at lære mere om DJL og DJLServing, se Implementer store modeller på Amazon SageMaker ved hjælp af DJLServing og DeepSpeed ​​model parallel inferens.

Det er værd at bemærke, at optimerede kerner kan resultere i præcisionsændringer og en modificeret beregningsgraf, hvilket teoretisk kan resultere i ændret modeladfærd. Selvom dette lejlighedsvis kan ændre slutningsresultatet, forventer vi ikke, at disse forskelle vil have en væsentlig indflydelse på en models grundlæggende evalueringsmetrikker. Ikke desto mindre rådes praktikere til at bekræfte, at modellens output er som forventet, når de bruger disse kerner.

De følgende trin viser, hvordan man implementerer en BLOOM-176B-model i SageMaker ved hjælp af DJLServing og en SageMaker-beholder til stor modelslutning. Det komplette eksempel er også tilgængeligt i vores GitHub repository.

Brug af DJLServing SageMaker DLC-billedet

Brug følgende kode til at bruge DJLServing SageMaker DLC-billedet efter at have erstattet regionen med din specifikke region, du kører notebook'en i:

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

Opret vores modelfil

Først opretter vi en fil kaldet serving.properties der kun indeholder én kodelinje. Dette fortæller DJL-modelserveren at bruge DeepSpeed-motoren. Filen indeholder følgende kode:

engine=DeepSpeed

serving.properties er en fil defineret af DJLServing, der bruges til at konfigurere konfiguration pr. model.

Dernæst skaber vi vores model.py fil, som definerer den nødvendige kode for at indlæse og derefter betjene modellen. I vores kode læser vi i TENSOR_PARALLEL_DEGREE miljøvariabel (standardværdien er 1). Dette indstiller antallet af enheder, som de parallelle tensormoduler er fordelt over. Bemærk, at DeepSpeed ​​giver nogle få indbyggede partitionsdefinitioner, inklusive en for BLOOM-modeller. Vi bruger det ved at specificere replace_method , relpace_with_kernel_inject. Hvis du har en tilpasset model og har brug for DeepSpeed ​​til at partitionere effektivt, skal du ændre relpace_with_kernel_inject til false og tilføje injection_policy for at få runtime-partitionen til at fungere. For mere information, se Initialisering for inferens. Til vores eksempel brugte vi den præ-partitionerede BLOOM-model på DeepSpeed.

For det andet i model.py fil, indlæser vi også modellen fra Amazon S3 efter endtpunktet er blevet spundet op. Modellen er indlæst i /tmp plads på containeren, fordi SageMaker kortlægger /tmp til Amazon Elastic Block Store (Amazon EBS) volumen, der er monteret, når vi angiver parameteren for oprettelse af slutpunkt VolumeSizeInGB. For tilfælde som p4dn, der er forudbygget med volumen-forekomsten, kan vi fortsætte med at udnytte /tmp på containeren. Se følgende kode:

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 styrer runtime-installationen på alle pip-pakker, der er defineret i requirement.txt. Denne fil vil have:

awscli
boto3

Vi har lavet en mappe kaldet code og model.py, serving.propertiesog requirements.txt filer er allerede oprettet i denne mappe. For at se filerne kan du køre følgende kode fra terminalen:

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

Følgende figur viser strukturen af model.tar.gz.

Til sidst opretter vi modelfilen og uploader den til Amazon S3:

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

Download og gem modellen fra Hugging Face (valgfrit)

Vi har givet trinene i dette afsnit, hvis du vil downloade modellen til Amazon S3 og bruge den derfra. Trinene findes i Jupyter-filen på GitHub. Følgende skærmbillede viser et øjebliksbillede af trinene.

Opret en SageMaker-model

Vi opretter nu en SageMaker model. Vi bruger Amazon Elastic Container Registry (Amazon ECR) billede leveret af og modelartefakten fra det forrige trin for at skabe SageMaker-modellen. I modelopsætningen konfigurerer vi TENSOR_PARALLEL_DEGREE=8, hvilket betyder, at modellen er opdelt langs 8 GPU'er. Se følgende kode:

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

Når du har kørt den foregående celle i Jupyter-filen, ser du output svarende til følgende:

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

Opret et SageMaker-slutpunkt

Du kan bruge alle instanser med flere GPU'er til test. I denne demo bruger vi en p4d.24xlarge instans. Bemærk i den følgende kode, hvordan vi indstiller ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSecondsog VolumeSizeInGB parametre for at imødekomme den store modelstørrelse. Det VolumeSizeInGB parameter gælder for GPU-instanser, der understøtter EBS-volumenvedhæftningen.

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,
        },
    ],
)'

Til sidst opretter vi et SageMaker-slutpunkt:

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

Du ser det udskrevet i følgende kode:

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

Start af slutpunktet kan tage et stykke tid. Du kan prøve et par gange mere, hvis du løber ind i InsufficientInstanceCapacity fejl, eller du kan rejse en anmodning til AWS om at øge grænsen på din konto.

Ydeevnejustering

Hvis du har til hensigt at bruge dette indlæg og den tilhørende notesbog med en anden model, vil du måske udforske nogle af de justerbare parametre, som SageMaker, DeepSpeed ​​og DJL tilbyder. Iterativt at eksperimentere med disse parametre kan have en væsentlig indflydelse på latensen, gennemløbet og omkostningerne for din hostede store model. For at lære mere om indstillingsparametre såsom antal arbejdere, grad af tensorparallelisme, jobkøstørrelse og andre, se DJL Serving konfigurationer , Implementer store modeller på Amazon SageMaker ved hjælp af DJLServing og DeepSpeed ​​model parallel inferens.

Resultater

I dette indlæg brugte vi DeepSpeed ​​til at være vært for BLOOM-176B og OPT-30B på SageMaker ML-instanser. Følgende tabel opsummerer vores præstationsresultater, inklusive en sammenligning med Hugging Face's Accelerate. Latency afspejler antallet af millisekunder, det tager at producere en 256-tokens streng fire gange (batch_size=4) fra modellen. Gennemløbet afspejler antallet af tokens, der produceres pr. sekund for hver test. Til Hugging Face Accelerate brugte vi bibliotekets standardindlæsning med GPU-hukommelseskortlægning. Til DeepSpeed ​​brugte vi dens hurtigere checkpoint-indlæsningsmekanisme.

Fra et latensperspektiv er DeepSpeed ​​omkring 3.4 gange hurtigere for BLOOM-176B og 5.6 gange hurtigere for OPT-30B end Accelerate. DeepSpeeds optimerede kerner er ansvarlige for meget af denne forskel i latency. I betragtning af disse resultater anbefaler vi at bruge DeepSpeed ​​frem for Accelerate, hvis din valgte model understøttes.

Det er også værd at bemærke, at modelindlæsningstider med DeepSpeed ​​var meget kortere, hvilket gør det til en bedre mulighed, hvis du forventer at skulle hurtigt opskalere dit antal endepunkter. Accelerates mere fleksible pipeline-parallelisme-teknik kan være en bedre mulighed, hvis du har modeller eller modelpræcision, der ikke understøttes af DeepSpeed.

Disse resultater viser også forskellen i latenstid og gennemløb af forskellige modelstørrelser. I vores test genererer OPT-30B 2.4 gange antallet af tokens pr. tidsenhed end BLOOM-176B på en instanstype, der er mere end tre gange billigere. På basis af pris pr. enhedsgennemløb er OPT-30B på en g5.24xl-instans 8.9 gange bedre end BLOOM-176B på en p4d.24xl-instans. Hvis du har strenge latens-, gennemløbs- eller omkostningsbegrænsninger, så overvej at bruge den mindst mulige model, som stadig vil opfylde funktionelle krav.

Ryd op

Som en del af bedste praksis anbefales det altid at slette inaktive forekomster. Nedenstående kode viser dig, hvordan du sletter forekomsterne.

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

Slet eventuelt modelkontrolpunktet fra din S3

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

Konklusion

I dette indlæg demonstrerede vi, hvordan man bruger SageMaker store modelinferensbeholdere til at være vært for to store sprogmodeller, BLOOM-176B og OPT-30B. Vi brugte DeepSpeeds model parallelle teknikker med flere GPU'er på en enkelt SageMaker ML instans.

For flere detaljer om Amazon SageMaker og dens store modelslutningsmuligheder, se Amazon SageMaker understøtter nu implementering af store modeller gennem konfigurerbar volumenstørrelse og timeout-kvoter , Realtidsslutning.

Om forfatterne

Simon Zamarin er en AI/ML Solutions Architect, hvis hovedfokus er at hjælpe kunder med at udvinde værdi fra deres dataaktiver. I sin fritid nyder Simon at bruge tid med familien, læse sci-fi og arbejde på forskellige DIY-husprojekter.

Rupinder Grewal er en Sr Ai/ML Specialist Solutions Architect hos AWS. Han fokuserer i øjeblikket på servering af modeller og MLOps på SageMaker. Før denne rolle har han arbejdet som Machine Learning Engineer ved at bygge og hoste modeller. Uden for arbejdet nyder han at spille tennis og cykle på bjergstier.

Frank Liu er softwareingeniør for AWS Deep Learning. Han fokuserer på at bygge innovative deep learning-værktøjer til softwareingeniører og videnskabsmænd. I sin fritid nyder han at vandre med venner og familie.

Alan Tan er en Senior Product Manager med SageMaker, der leder indsatsen på store modelslutninger. Han brænder for at anvende Machine Learning til området Analytics. Uden for arbejdet nyder han udendørslivet.

Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret computing og kunstig intelligens. Han fokuserer på Deep learning, herunder NLP og Computer Vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.

Qing Lan er softwareudviklingsingeniør i AWS. Han har arbejdet på adskillige udfordrende produkter i Amazon, herunder højtydende ML-inferensløsninger og højtydende logningssystem. Qings team lancerede med succes den første Billion-parameter model i Amazon Advertising med meget lav forsinkelse påkrævet. Qing har indgående viden om infrastrukturoptimering og Deep Learning acceleration.

Qingwei Li er Machine Learning Specialist hos Amazon Web Services. Han fik sin ph.d. i Operations Research, efter at han brød sin rådgivers forskningsbevillingskonto og undlod at levere den nobelpris, han lovede. I øjeblikket hjælper han kunder i finans- og forsikringsbranchen med at bygge maskinlæringsløsninger på AWS. I sin fritid kan han godt lide at læse og undervise.

Robert Van Dusen er Senior Product Manager hos Amazon SageMaker. Han leder dyb læringsmodeloptimering til applikationer såsom stor modelslutning.

Siddharth Venkatesan er softwareingeniør i AWS Deep Learning. Han fokuserer i øjeblikket på at bygge løsninger til store modelslutninger. Før AWS arbejdede han i Amazon Grocery-organisationen med at bygge nye betalingsfunktioner til kunder over hele verden. Uden for arbejdet nyder han at stå på ski, udendørs og se sport.