Distribuera BLOOM-176B och OPT-30B på Amazon SageMaker med stor modellinferens Deep Learning Containers och DeepSpeed

De senaste åren har det skett en snabb utveckling inom området djupinlärning. Även om hårdvaran har förbättrats, till exempel med den senaste generationens acceleratorer från NVIDIA och Amazon, stöter utövare av avancerad maskininlärning (ML) fortfarande regelbundet på problem med att distribuera sina stora djupinlärningsmodeller för applikationer som naturlig språkbehandling (NLP).

I ett tidigare inlägg diskuterade vi funktioner och konfigurerbara inställningar in Amazon SageMaker-modellinstallation som kan göra slutsatser med dessa stora modeller lättare. Idag tillkännager vi en ny Amazon SageMaker Deep Learning Container (DLC) som du kan använda för att komma igång med stora modellinferenser på några minuter. Detta DLC paketerar några av de mest populära biblioteken med öppen källkod för modellparallell slutledning, såsom DeepSpeed ​​och Hugging Face Accelerate.

I det här inlägget använder vi en ny SageMaker stor modell inferens DLC för att distribuera två av de mest populära stora NLP-modellerna: BigScience's BLOOM-176B och Meta's OPT-30B från Hugging Face-förrådet. I synnerhet använder vi Deep Java Library (DJL)-serverings- och tensorparallellismtekniker från DeepSpeed ​​för att uppnå 0.1 sekunds latens per token i ett användningsfall för textgenerering.

Du kan hitta våra kompletta exempelanteckningsböcker i vår GitHub repository.

Stora modellinferenstekniker

Språkmodeller har nyligen exploderat i både storlek och popularitet. Med enkel åtkomst från modelldjurparker som Hugging Face och förbättrad noggrannhet och prestanda i NLP-uppgifter som klassificering och textgenerering, sträcker sig utövare alltmer efter dessa stora modeller. Men stora modeller är ofta för stora för att få plats i minnet av en enskild accelerator. Till exempel kan BLOOM-176B-modellen kräva mer än 350 gigabyte acceleratorminne, vilket vida överstiger kapaciteten hos hårdvaruacceleratorer som finns tillgängliga idag. Detta kräver att man använder parallella modelltekniker från bibliotek som DeepSpeed ​​och Hugging Face Accelerate för att fördela en modell över flera acceleratorer för slutledning. I det här inlägget använder vi SageMaker stor modell slutledningsbehållare för att generera och jämföra latens- och genomströmningsprestanda med dessa två bibliotek med öppen källkod.

DeepSpeed ​​och Accelerate använder olika tekniker för att optimera stora språkmodeller för slutledning. Den viktigaste skillnaden är DeepSpeeds användning av optimerade kärnor. Dessa kärnor kan dramatiskt förbättra slutledningslatens genom att minska flaskhalsar i modellens beräkningsgraf. Optimerade kärnor kan vara svåra att utveckla och är typiskt specifika för en viss modellarkitektur; DeepSpeed ​​stöder populära stora modeller som OPT och BLOOM med dessa optimerade kärnor. Däremot innehåller Hugging Faces Accelerate-bibliotek inte optimerade kärnor i skrivande stund. Som vi diskuterar i vårt resultatavsnitt är denna skillnad ansvarig för mycket av prestandafördelen som DeepSpeed ​​har jämfört med Accelerate.

En andra skillnad mellan DeepSpeed ​​och Accelerate är typen av modellparallellism. Accelerate använder pipeline-parallellism för att dela upp en modell mellan de dolda lagren i en modell, medan DeepSpeed ​​använder tensor-parallellism för att partitionera själva lagren. Pipeline parallellism är ett flexibelt tillvägagångssätt som stöder fler modelltyper och kan förbättra genomströmningen när större batchstorlekar används. Tensorparallellism kräver mer kommunikation mellan GPU:er eftersom modelllager kan spridas över flera enheter, men kan förbättra slutledningsfördröjningen genom att engagera flera GPU:er samtidigt. Du kan lära dig mer om parallellitetstekniker i Introduktion till modellparallellism och Modell Parallellism.

Lösningsöversikt

För att effektivt vara värd för stora språkmodeller behöver vi funktioner och support inom följande nyckelområden:

• Bygger och testar lösningar – Med tanke på den iterativa karaktären av ML-utveckling behöver vi förmågan att bygga, snabbt iterera och testa hur slutpunktens slutpunkt kommer att bete sig när dessa modeller är värd, inklusive förmågan att misslyckas snabbt. Dessa modeller kan vanligtvis bara finnas på större instanser som p4dn eller g5, och med tanke på storleken på modellerna kan det ta ett tag att snurra upp en slutledningsinstans och köra valfri testiteration. Lokal testning har vanligtvis begränsningar eftersom du behöver en liknande instans i storlek för att testa, och dessa modeller är inte lätta att få tag på.
• Installera och köra i stor skala – Modellfilerna måste laddas in på slutledningsinstanserna, vilket är en utmaning i sig med tanke på storleken. Tar / Un-Tar som ett exempel för Bloom-176B tar cirka 1 timme att skapa och ytterligare en timme att ladda. Vi behöver en alternativ mekanism för att ge enkel åtkomst till modellfilerna.
• Laddar modellen som singel – För en process med flera arbetare måste vi se till att modellen bara laddas en gång så att vi inte stöter på tävlingsförhållanden och spenderar ytterligare onödiga resurser. I det här inlägget visar vi ett sätt att ladda direkt från Amazon enkel lagringstjänst (Amazon S3). Detta fungerar dock bara om vi använder standardinställningarna för DJL. Dessutom måste eventuell skalning av ändpunkterna kunna snurra upp på några minuter, vilket kräver att man omprövar hur modellerna kan laddas och distribueras.
• Dela ramar – Dessa modeller behöver vanligtvis vara , vanligtvis av en tensor-parallellismmekanism eller genom pipeline-skärning som de typiska skärningsteknikerna, och vi har avancerade koncept som ZeRO-skärning byggd ovanpå tensor-skärning. För mer information om skärningstekniker, se Modell Parallellism. För att uppnå detta kan vi ha olika kombinationer och använda ramverk från NIVIDIA, DeepSpeed ​​och andra. Detta kräver förmågan att testa BYOC eller använda 1P-behållare och iterera över lösningar och köra benchmarking-tester. Du kanske också vill testa olika värdalternativ som asynkron, serverlös och andra.
• Val av hårdvara – Ditt val av hårdvara bestäms av alla ovan nämnda punkter och ytterligare trafikmönster, användningsfallsbehov och modellstorlekar.

I det här inlägget använder vi DeepSpeeds optimerade kärnor och tensorparallellismtekniker för att vara värd för BLOOM-176B och OPT-30B på SageMaker. Vi jämför också resultat från Accelerate för att visa prestandafördelarna med optimerade kärnor och tensorparallellism. För mer information om DeepSpeed ​​och Accelerate, se DeepSpeed ​​Inference: möjliggör effektiv slutledning av transformatormodeller i oöverträffad skala och Otroligt snabb BLOOM-inferens med DeepSpeed ​​och Accelerate.

Vi använder DJLServing som modellserveringslösning i detta exempel. DJLServing är en högpresterande universell modelltjänstlösning som drivs av Deep Java Library (DJL) som är agnostisk för programmeringsspråk. För att lära dig mer om DJL och DJLServing, se Distribuera stora modeller på Amazon SageMaker med hjälp av DJLServing och DeepSpeed ​​modell parallell slutledning.

Det är värt att notera att optimerade kärnor kan resultera i precisionsförändringar och en modifierad beräkningsgraf, vilket teoretiskt kan resultera i ändrat modellbeteende. Även om detta ibland kan förändra slutledningsresultatet, förväntar vi oss inte att dessa skillnader väsentligt påverkar de grundläggande utvärderingsmåtten för en modell. Icke desto mindre rekommenderas utövare att bekräfta att modellutgångarna är som förväntade när de använder dessa kärnor.

Följande steg visar hur man distribuerar en BLOOM-176B-modell i SageMaker med DJLServing och en SageMaker stor modell slutledningsbehållare. Det kompletta exemplet finns också tillgängligt i vår GitHub repository.

Använder DJLServing SageMaker DLC-bilden

Använd följande kod för att använda DJLServing SageMaker DLC-bilden efter att ha ersatt regionen med din specifika region där du kör notebook:en:

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

Skapa vår modellfil

Först skapar vi en fil som heter serving.properties som bara innehåller en kodrad. Detta talar om för DJL-modellservern att använda DeepSpeed-motorn. Filen innehåller följande kod:

engine=DeepSpeed

serving.properties är en fil definierad av DJLServing som används för att konfigurera konfigurationen per modell.

Därefter skapar vi vår model.py fil, som definierar koden som behövs för att ladda och sedan betjäna modellen. I vår kod läser vi in TENSOR_PARALLEL_DEGREE miljövariabel (standardvärdet är 1). Detta ställer in antalet enheter över vilka de parallella tensormodulerna är fördelade. Observera att DeepSpeed ​​tillhandahåller några få inbyggda partitionsdefinitioner, inklusive en för BLOOM-modeller. Vi använder det genom att specificera replace_method och relpace_with_kernel_inject. Om du har en anpassad modell och behöver DeepSpeed ​​för att partitionera effektivt måste du ändra relpace_with_kernel_inject till false och lägg till injection_policy för att få runtime-partitionen att fungera. För mer information, se Initiering för slutledning. Som vårt exempel använde vi den förpartitionerade BLOOM-modellen på DeepSpeed.

För det andra, i model.py fil, laddar vi också modellen från Amazon S3 efter att slutpunkten har snurrats upp. Modellen laddas in i /tmp utrymme på behållaren eftersom SageMaker kartlägger /tmp till Amazon Elastic Block Store (Amazon EBS) volym som monteras när vi anger parametern för att skapa endpoint VolumeSizeInGB. För instanser som p4dn, som är förbyggda med volyminstansen, kan vi fortsätta att utnyttja /tmp på behållaren. Se följande kod:

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 hanterar runtime-installationen på alla pip-paket som definieras i requirement.txt. Den här filen kommer att ha:

awscli
boto3

Vi har skapat en katalog som heter code och model.py, serving.propertiesoch requirements.txt filer har redan skapats i den här katalogen. För att se filerna kan du köra följande kod från terminalen:

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

Följande figur visar strukturen för model.tar.gz.

Slutligen skapar vi modellfilen och laddar upp den till Amazon S3:

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

Ladda ner och lagra modellen från Hugging Face (valfritt)

Vi har tillhandahållit stegen i det här avsnittet om du vill ladda ner modellen till Amazon S3 och använda den därifrån. Stegen finns i Jupyter-filen på GitHub. Följande skärmdump visar en ögonblicksbild av stegen.

Skapa en SageMaker-modell

Vi skapar nu en SageMaker modell. Vi använder Amazon Elastic Container Registry (Amazon ECR) bild tillhandahållen av och modellartefakten från föregående steg för att skapa SageMaker-modellen. I modellinställningen konfigurerar vi TENSOR_PARALLEL_DEGREE=8, vilket innebär att modellen är uppdelad längs 8 GPU:er. Se följande kod:

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 föregående cell i Jupyter-filen ser du utdata som liknar följande:

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

Skapa en SageMaker-slutpunkt

Du kan använda alla instanser med flera GPU:er för testning. I den här demon använder vi en p4d.24xlarge-instans. I följande kod, notera hur vi ställer in ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSecondsoch VolumeSizeInGB parametrar för att passa den stora modellstorleken. De VolumeSizeInGB parametern är tillämplig på GPU-instanser som stöder EBS-volymbifogningen.

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

Slutligen skapar vi en SageMaker-slutpunkt:

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

Du ser det utskrivet i följande kod:

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

Det kan ta ett tag att starta slutpunkten. Du kan prova några gånger till om du stöter på InsufficientInstanceCapacity fel, eller så kan du skicka en begäran till AWS om att höja gränsen på ditt konto.

Prestandajustering

Om du tänker använda det här inlägget och den medföljande anteckningsboken med en annan modell, kanske du vill utforska några av de inställbara parametrarna som SageMaker, DeepSpeed ​​och DJL erbjuder. Att iterativt experimentera med dessa parametrar kan ha en väsentlig inverkan på latensen, genomströmningen och kostnaden för din värdbaserade stora modell. För att lära dig mer om inställningsparametrar som antal arbetare, grad av tensorparallellism, jobbköstorlek och andra, se DJL Serveringskonfigurationer och Distribuera stora modeller på Amazon SageMaker med hjälp av DJLServing och DeepSpeed ​​modell parallell slutledning.

Resultat

I det här inlägget använde vi DeepSpeed ​​för att vara värd för BLOOM-176B och OPT-30B på SageMaker ML-instanser. Följande tabell sammanfattar våra prestationsresultat, inklusive en jämförelse med Hugging Face's Accelerate. Latensen återspeglar antalet millisekunder som det tar att producera en sträng med 256 token fyra gånger (batch_size=4) från modellen. Genomströmningen återspeglar antalet tokens som produceras per sekund för varje test. För Hugging Face Accelerate använde vi bibliotekets standardladdning med GPU-minnesmappning. För DeepSpeed ​​använde vi dess snabbare kontrollpunktsladdningsmekanism.

Ur ett latensperspektiv är DeepSpeed ​​cirka 3.4 gånger snabbare för BLOOM-176B och 5.6 gånger snabbare för OPT-30B än Accelerate. DeepSpeeds optimerade kärnor är ansvariga för mycket av denna skillnad i latens. Med tanke på dessa resultat rekommenderar vi att du använder DeepSpeed ​​framför Accelerate om din valda modell stöds.

Det är också värt att notera att modellladdningstiderna med DeepSpeed ​​var mycket kortare, vilket gör det till ett bättre alternativ om du räknar med att snabbt behöva skala upp ditt antal slutpunkter. Accelerates mer flexibla pipeline-parallellismteknik kan vara ett bättre alternativ om du har modeller eller modellprecision som inte stöds av DeepSpeed.

Dessa resultat visar också skillnaden i latens och genomströmning för olika modellstorlekar. I våra tester genererar OPT-30B 2.4 gånger antalet tokens per tidsenhet än BLOOM-176B på en instanstyp som är mer än tre gånger billigare. På basis av pris per enhetsgenomströmning är OPT-30B på en g5.24xl-instans 8.9 gånger bättre än BLOOM-176B på en p4d.24xl-instans. Om du har strikt latens, genomströmning eller kostnadsbegränsningar, överväg att använda den minsta möjliga modellen som fortfarande kommer att uppfylla funktionella krav.

Städa upp

Som en del av bästa praxis rekommenderas det alltid att ta bort inaktiva instanser. Koden nedan visar hur du tar bort instanserna.

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

Radera eventuellt modellkontrollpunkten från din S3

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

Slutsats

I det här inlägget visade vi hur man använder SageMaker stora modellinferensbehållare för att vara värd för två stora språkmodeller, BLOOM-176B och OPT-30B. Vi använde DeepSpeeds modellparallella tekniker med flera GPU:er på en enda SageMaker ML-instans.

För mer information om Amazon SageMaker och dess stora modellinferensmöjligheter, se Amazon SageMaker stöder nu distribution av stora modeller genom konfigurerbar volymstorlek och timeout-kvoter och Inferens i realtid.

Om författarna

Simon Zamarin är en AI / ML-lösningsarkitekt vars huvudsakliga fokus är att hjälpa kunder att extrahera värde från sina datatillgångar. På sin fritid tycker Simon om att spendera tid med familjen, läsa sci-fi och arbeta med olika DIY-husprojekt.

Rupinder Grewal är en Sr Ai/ML Specialist Solutions Architect med AWS. Han fokuserar för närvarande på servering av modeller och MLOps på SageMaker. Innan denna roll har han arbetat som Machine Learning Engineer med att bygga och hosta modeller. Utanför jobbet tycker han om att spela tennis och cykla på bergsstigar.

Frank Liu är mjukvaruingenjör för AWS Deep Learning. Han fokuserar på att bygga innovativa djupinlärningsverktyg för mjukvaruutvecklare och forskare. På fritiden tycker han om att vandra med vänner och familj.

Alan Tan är en senior produktchef med SageMaker som leder insatser för slutledning av stora modeller. Han brinner för att tillämpa maskininlärning på området Analytics. Utanför jobbet tycker han om att vara utomhus.

Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning inklusive NLP- och Computer Vision-domäner. Han hjälper kunder att uppnå högpresterande modellslutningar på SageMaker.

Qing Lan är en mjukvaruutvecklingsingenjör i AWS. Han har arbetat med flera utmanande produkter i Amazon, inklusive högpresterande ML-slutledningslösningar och högpresterande loggsystem. Qings team lanserade framgångsrikt den första miljardparametermodellen i Amazon Advertising med mycket låg latens som krävs. Qing har djupgående kunskaper om infrastrukturoptimering och Deep Learning-acceleration.

Qingwei Li är maskininlärningsspecialist på Amazon Web Services. Han fick sin doktorsexamen. i Operations Research efter att han bröt sin rådgivares forskningsbidragskonto och misslyckades med att leverera det Nobelpris han lovade. För närvarande hjälper han kunder inom finanssektorn och försäkringsbranschen att bygga maskininlärningslösningar på AWS. På fritiden gillar han att läsa och undervisa.

Robert Van Dusen är senior produktchef hos Amazon SageMaker. Han leder optimering av djupinlärningsmodeller för applikationer som stor modellinferens.

Siddharth Venkatesan är en mjukvaruingenjör inom AWS Deep Learning. Han fokuserar för närvarande på att bygga lösningar för stora modellinferenser. Innan han började på AWS arbetade han i Amazon Grocery-organisationen och byggde nya betalningsfunktioner för kunder över hela världen. Utanför jobbet tycker han om att åka skidor, att vara utomhus och att titta på sport.