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

De siste årene har det vært en rivende utvikling innen dyp læring. Selv om maskinvaren har forbedret seg, for eksempel med den siste generasjonen av akseleratorer fra NVIDIA og Amazon, støter brukere av avansert maskinlæring (ML) fortsatt jevnlig på problemer med å distribuere sine store dyplæringsmodeller for applikasjoner som naturlig språkbehandling (NLP).

I et tidligere innlegg diskuterte vi funksjoner og konfigurerbare innstillinger in Amazon SageMaker-modellimplementering som kan gjøre slutninger med disse store modellene enklere. I dag annonserer vi en ny Amazon SageMaker Deep Learning Container (DLC) som du kan bruke for å komme i gang med store modellslutninger i løpet av få minutter. Dette DLC pakker noen av de mest populære åpen kildekode-bibliotekene for modellparallell slutning, som DeepSpeed ​​og Hugging Face Accelerate.

I dette innlegget bruker vi en ny SageMaker stor modell inferens DLC for å distribuere to av de mest populære store NLP-modellene: BigScience's BLOOM-176B og Meta's OPT-30B fra Hugging Face-lageret. Spesielt bruker vi Deep Java Library (DJL)-servering og tensorparallellisme-teknikker fra DeepSpeed ​​for å oppnå 0.1 sekunds latens per token i et tekstgenereringsbruk.

Du kan finne våre komplette eksempelnotatbøker i vår GitHub repository.

Inferensteknikker for store modeller

Språkmodeller har nylig eksplodert i både størrelse og popularitet. Med enkel tilgang fra modelldyrehager som Hugging Face og forbedret nøyaktighet og ytelse i NLP-oppgaver som klassifisering og tekstgenerering, strekker utøvere seg i økende grad etter disse store modellene. Imidlertid er store modeller ofte for store til å passe inn i minnet til en enkelt akselerator. For eksempel kan BLOOM-176B-modellen kreve mer enn 350 gigabyte akseleratorminne, noe som langt overgår kapasiteten til maskinvareakseleratorer som er tilgjengelige i dag. Dette nødvendiggjør bruk av modell parallelle teknikker fra biblioteker som DeepSpeed ​​og Hugging Face Accelerate for å distribuere en modell over flere akseleratorer for slutning. I dette innlegget bruker vi SageMaker stor modell inferensbeholder å generere og sammenligne ventetid og gjennomstrømningsytelse ved å bruke disse to åpen kildekode-bibliotekene.

DeepSpeed ​​og Accelerate bruker forskjellige teknikker for å optimalisere store språkmodeller for slutninger. Hovedforskjellen er DeepSpeeds bruk av optimaliserte kjerner. Disse kjernene kan forbedre inferensforsinkelsen dramatisk ved å redusere flaskehalser i beregningsgrafen til modellen. Optimaliserte kjerner kan være vanskelige å utvikle og er typisk spesifikke for en bestemt modellarkitektur; DeepSpeed ​​støtter populære store modeller som OPT og BLOOM med disse optimaliserte kjernene. I kontrast inkluderer ikke Hugging Faces Accelerate-bibliotek optimaliserte kjerner i skrivende stund. Som vi diskuterer i resultatdelen vår, er denne forskjellen ansvarlig for mye av ytelsesfordelen som DeepSpeed ​​har i forhold til Accelerate.

En annen forskjell mellom DeepSpeed ​​og Accelerate er typen modellparallellisme. Accelerate bruker pipeline-parallellisme for å dele en modell mellom de skjulte lagene i en modell, mens DeepSpeed ​​bruker tensor-parallellisme for å partisjonere selve lagene. Rørledningsparallellisme er en fleksibel tilnærming som støtter flere modelltyper og kan forbedre gjennomstrømningen når større batchstørrelser brukes. Tensorparallellisme krever mer kommunikasjon mellom GPUer fordi modelllag kan spres over flere enheter, men kan forbedre inferensforsinkelse ved å engasjere flere GPUer samtidig. Du kan lære mer om parallellitetsteknikker i Introduksjon til modellparallellisme og Modellparallellisme.

Løsningsoversikt

For effektivt å være vert for store språkmodeller trenger vi funksjoner og støtte på følgende nøkkelområder:

• Bygge og teste løsninger – Gitt den iterative karakteren til ML-utvikling, trenger vi muligheten til å bygge, raskt iterere og teste hvordan slutningsendepunktet vil oppføre seg når disse modellene er vert, inkludert evnen til å mislykkes raskt. Disse modellene kan vanligvis bare hostes på større forekomster som p4dn eller g5, og gitt størrelsen på modellene, kan det ta en stund å spinne opp en inferensforekomst og kjøre en hvilken som helst testiterasjon. Lokal testing har vanligvis begrensninger fordi du trenger en lignende forekomst i størrelse for å teste, og disse modellene er ikke enkle å få tak i.
• Utplassering og drift i stor skala – Modellfilene må lastes inn på slutningsforekomstene, noe som gir en utfordring i seg selv gitt størrelsen. Tar / Un-Tar som et eksempel for Bloom-176B tar omtrent 1 time å lage og en annen time å laste. Vi trenger en alternativ mekanisme for å gi enkel tilgang til modellfilene.
• Laster modellen som singleton – For en prosess med flere arbeidere, må vi sikre at modellen bare lastes én gang, slik at vi ikke støter på løpsforhold og bruker unødvendige ressurser ytterligere. I dette innlegget viser vi en måte å laste direkte fra Amazon enkel lagringstjeneste (Amazon S3). Dette fungerer imidlertid bare hvis vi bruker standardinnstillingene til DJL. Videre må enhver skalering av endepunktene kunne snurre opp i løpet av noen få minutter, noe som krever en ny vurdering av hvordan modellene kan lastes og distribueres.
• Deling av rammer – Disse modellene må vanligvis være , vanligvis av en tensor-parallellismemekanisme eller ved pipeline-sharding som de typiske sharding-teknikkene, og vi har avanserte konsepter som ZeRO-sharding bygget på toppen av tensor-sharding. For mer informasjon om skjæringsteknikker, se Modellparallellisme. For å oppnå dette kan vi ha ulike kombinasjoner og bruke rammeverk fra NIVIDIA, DeepSpeed ​​og andre. Dette krever muligheten til å teste BYOC eller bruke 1P-beholdere og iterere over løsninger og kjøre benchmarking-tester. Du vil kanskje også teste ulike vertsalternativer som asynkron, serverløs og andre.
• Valg av maskinvare – Ditt valg av maskinvare bestemmes av alle de nevnte punktene og ytterligere trafikkmønstre, bruksbehov og modellstørrelser.

I dette innlegget bruker vi DeepSpeeds optimaliserte kjerner og tensorparallellismeteknikker for å være vert for BLOOM-176B og OPT-30B på SageMaker. Vi sammenligner også resultater fra Accelerate for å demonstrere ytelsesfordelene til optimaliserte kjerner og tensorparallellisme. For mer informasjon om DeepSpeed ​​og Accelerate, se DeepSpeed ​​Inference: muliggjør effektiv inferens av transformatormodeller i enestående skala og Utrolig rask BLOOM-inferens med DeepSpeed ​​og Accelerate.

Vi bruker DJLServing som modellserveringsløsning i dette eksemplet. DJLServing er en høyytelses universell modellserveringsløsning drevet av Deep Java Library (DJL) som er programmeringsspråkagnostisk. For å lære mer om DJL og DJLServing, se Distribuer store modeller på Amazon SageMaker ved å bruke DJLServing og DeepSpeed ​​modell parallell inferens.

Det er verdt å merke seg at optimaliserte kjerner kan resultere i presisjonsendringer og en modifisert beregningsgraf, noe som teoretisk kan resultere i endret modellatferd. Selv om dette av og til kan endre slutningsresultatet, forventer vi ikke at disse forskjellene vil ha en vesentlig innvirkning på de grunnleggende evalueringsverdiene til en modell. Likevel anbefales utøvere å bekrefte at modellutdataene er som forventet når de bruker disse kjernene.

De følgende trinnene demonstrerer hvordan du distribuerer en BLOOM-176B-modell i SageMaker ved hjelp av DJLServing og en SageMaker-beholder for stor modell. Det komplette eksemplet er også tilgjengelig i vår GitHub repository.

Bruke DJLServing SageMaker DLC-bildet

Bruk følgende kode for å bruke DJLServing SageMaker DLC-bildet etter å ha erstattet regionen med din spesifikke region du kjører den bærbare datamaskinen 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

Lag vår modellfil

Først lager vi en fil som heter serving.properties som inneholder bare én kodelinje. Dette forteller DJL-modellserveren å bruke DeepSpeed-motoren. Filen inneholder følgende kode:

engine=DeepSpeed

serving.properties er en fil definert av DJLServing som brukes til å konfigurere konfigurasjon per modell.

Deretter lager vi vår model.py fil, som definerer koden som trengs for å laste og deretter betjene modellen. I koden vår leser vi inn TENSOR_PARALLEL_DEGREE miljøvariabel (standardverdien er 1). Dette angir antall enheter som tensorparallelle moduler er fordelt over. Merk at DeepSpeed ​​gir noen få innebygde partisjonsdefinisjoner, inkludert en for BLOOM-modeller. Vi bruker det ved å spesifisere replace_method og relpace_with_kernel_inject. Hvis du har en tilpasset modell og trenger DeepSpeed ​​for å partisjonere effektivt, må du endre relpace_with_kernel_inject til false og legge til injection_policy for å få runtime-partisjonen til å fungere. For mer informasjon, se Initialiserer for inferens. For vårt eksempel brukte vi den forhåndspartisjonerte BLOOM-modellen på DeepSpeed.

For det andre, i model.py fil, laster vi også modellen fra Amazon S3 etter at endepunktet er spunnet opp. Modellen er lastet inn i /tmp plass på containeren fordi SageMaker kartlegger /tmp til Amazon Elastic Block Store (Amazon EBS) volum som er montert når vi spesifiserer parameteren for opprettelse av endepunkt VolumeSizeInGB. For tilfeller som p4dn, som kommer forhåndsbygd med volumforekomsten, kan vi fortsette å utnytte /tmp på beholderen. 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 administrerer kjøretidsinstallasjonen på alle pip-pakker definert i requirement.txt. Denne filen vil ha:

awscli
boto3

Vi har laget en katalog som heter code og model.py, serving.propertiesog requirements.txt filer er allerede opprettet i denne katalogen. For å se filene kan du kjø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 til model.tar.gz.

Til slutt lager vi modellfilen og laster den opp til Amazon S3:

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

Last ned og lagre modellen fra Hugging Face (valgfritt)

Vi har gitt trinnene i denne delen i tilfelle du vil laste ned modellen til Amazon S3 og bruke den derfra. Trinnene er gitt i Jupyter-filen på GitHub. Følgende skjermbilde viser et øyeblikksbilde av trinnene.

Lag en SageMaker-modell

Vi oppretter nå en SageMaker modell. Vi bruker Amazon Elastic Container Registry (Amazon ECR)-bilde levert av og modellartefakten fra forrige trinn for å lage SageMaker-modellen. I modelloppsettet konfigurerer vi TENSOR_PARALLEL_DEGREE=8, som betyr at modellen er partisjonert langs 8 GPUer. 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",
},

Etter at du har kjørt den foregående cellen i Jupyter-filen, ser du utdata som ligner på følgende:

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

Opprett et SageMaker-endepunkt

Du kan bruke alle forekomster med flere GPUer for testing. I denne demoen bruker vi en p4d.24xlarge-instans. I den følgende koden, legg merke til hvordan vi setter ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSecondsog VolumeSizeInGB parametere for å imøtekomme den store modellstørrelsen. De VolumeSizeInGB parameteren gjelder for GPU-forekomster som støtter EBS-volumvedlegget.

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 slutt lager vi et SageMaker-endepunkt:

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

Du ser det skrevet ut i følgende kode:

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

Det kan ta litt tid å starte endepunktet. Du kan prøve noen ganger til hvis du støter på InsufficientInstanceCapacity feil, eller du kan sende en forespørsel til AWS om å øke grensen på kontoen din.

Ytelsestuning

Hvis du har tenkt å bruke dette innlegget og den tilhørende notatboken med en annen modell, kan det være lurt å utforske noen av de justerbare parameterne som SageMaker, DeepSpeed ​​og DJL tilbyr. Iterativt eksperimentering med disse parameterne kan ha en vesentlig innvirkning på ventetiden, gjennomstrømmingen og kostnadene for den store modellen som er vert. For å lære mer om innstillingsparametere som antall arbeidere, grad av tensorparallellisme, jobbkøstørrelse og andre, se DJL-serveringskonfigurasjoner og Distribuer store modeller på Amazon SageMaker ved å bruke DJLServing og DeepSpeed ​​modell parallell inferens.

Resultater

I dette innlegget brukte vi DeepSpeed ​​til å være vert for BLOOM-176B og OPT-30B på SageMaker ML-forekomster. Tabellen nedenfor oppsummerer ytelsesresultatene våre, inkludert en sammenligning med Hugging Faces Accelerate. Latency reflekterer antall millisekunder det tar å produsere en 256-token streng fire ganger (batch_size=4) fra modellen. Gjennomstrømning gjenspeiler antall tokens produsert per sekund for hver test. For Hugging Face Accelerate brukte vi bibliotekets standardlasting med GPU-minnekartlegging. For DeepSpeed ​​brukte vi den raskere lastemekanismen for sjekkpunkt.

Fra et latensperspektiv er DeepSpeed ​​omtrent 3.4 ganger raskere for BLOOM-176B og 5.6 ganger raskere for OPT-30B enn Accelerate. DeepSpeeds optimaliserte kjerner er ansvarlige for mye av denne forskjellen i ventetid. Gitt disse resultatene anbefaler vi å bruke DeepSpeed ​​fremfor Accelerate hvis modellen du velger, støttes.

Det er også verdt å merke seg at modellens lastetider med DeepSpeed ​​var mye kortere, noe som gjør det til et bedre alternativ hvis du forventer å raskt skalere opp antallet endepunkter. Accelerates mer fleksible pipeline-parallellismeteknikk kan være et bedre alternativ hvis du har modeller eller modellpresisjoner som ikke støttes av DeepSpeed.

Disse resultatene viser også forskjellen i latens og gjennomstrømning for forskjellige modellstørrelser. I våre tester genererer OPT-30B 2.4 ganger antall tokens per tidsenhet enn BLOOM-176B på en instanstype som er mer enn tre ganger billigere. På en pris per enhetsgjennomstrømningsbasis er OPT-30B på en g5.24xl-forekomst 8.9 ganger bedre enn BLOOM-176B på en p4d.24xl-forekomst. Hvis du har strenge latens-, gjennomstrømnings- eller kostnadsbegrensninger, bør du vurdere å bruke den minste modellen som er mulig som fortsatt vil oppfylle funksjonelle krav.

Rydd opp

Som en del av beste praksis anbefales det alltid å slette inaktive forekomster. Koden nedenfor viser deg hvordan du sletter forekomstene.

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

Slett eventuelt modellsjekkpunktet fra din S3

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

konklusjonen

I dette innlegget demonstrerte vi hvordan du bruker SageMaker store modellslutningsbeholdere for å være vert for to store språkmodeller, BLOOM-176B og OPT-30B. Vi brukte DeepSpeeds modellparallelle teknikker med flere GPUer på en enkelt SageMaker ML-forekomst.

For mer informasjon om Amazon SageMaker og dens store modellslutningsfunksjoner, se Amazon SageMaker støtter nå distribusjon av store modeller gjennom konfigurerbare volumstørrelser og tidsavbruddskvoter og Slutning i sanntid.

Om forfatterne

Simon Zamarin er en AI / ML-løsningsarkitekt som har hovedfokus på å hjelpe kunder med å hente ut verdi fra dataenes eiendeler. På fritiden liker Simon å tilbringe tid med familien, lese sci-fi og jobbe med forskjellige DIY-husprosjekter.

Rupinder Grewal er en Sr Ai/ML spesialistløsningsarkitekt med AWS. Han fokuserer for tiden på servering av modeller og MLOps på SageMaker. Før denne rollen har han jobbet som maskinlæringsingeniør med å bygge og hoste modeller. Utenom jobben liker han å spille tennis og sykle på fjellstier.

Frank Liu er programvareingeniør for AWS Deep Learning. Han fokuserer på å bygge innovative dype læringsverktøy for programvareingeniører og forskere. På fritiden liker han å vandre med venner og familie.

Alan Tan er en senior produktsjef med SageMaker som leder innsatsen for store modellslutninger. Han brenner for å bruke maskinlæring på området Analytics. Utenom jobben liker han å være ute.

Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring inkludert NLP- og Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.

Qing Lan er en programvareutviklingsingeniør i AWS. Han har jobbet med flere utfordrende produkter i Amazon, inkludert høyytelses ML-slutningsløsninger og høyytelses loggingssystem. Qings team lanserte den første milliardparametermodellen i Amazon Advertising med svært lav ventetid. Qing har inngående kunnskap om infrastrukturoptimalisering og Deep Learning-akselerasjon.

Qingwei Li er maskinlæringsspesialist hos Amazon Web Services. Han fikk sin doktorgrad. i Operations Research etter at han brøt sin rådgivers forskningsbevilgningskonto og ikke klarte å levere Nobelprisen han lovet. For tiden hjelper han kunder i finans- og forsikringsbransjen med å bygge maskinlæringsløsninger på AWS. På fritiden liker han å lese og undervise.

Robert Van Dusen er senior produktsjef hos Amazon SageMaker. Han leder dyplæringsmodelloptimalisering for applikasjoner som stor modellslutning.

Siddharth Venkatesan er programvareingeniør i AWS Deep Learning. Han fokuserer for tiden på å bygge løsninger for store modellslutninger. Før AWS jobbet han i Amazon Grocery-organisasjonen med å bygge nye betalingsfunksjoner for kunder over hele verden. Utenom jobben liker han å gå på ski, friluftsliv og se på sport.