Implementeer BLOOM-176B en OPT-30B op Amazon SageMaker met deep learning-containers voor grote modellen en DeepSpeed

De laatste jaren hebben we een snelle ontwikkeling doorgemaakt op het gebied van deep learning. Hoewel de hardware is verbeterd, zoals met de nieuwste generatie accelerators van NVIDIA en Amazon, ondervinden geavanceerde machine learning (ML)-beoefenaars nog regelmatig problemen bij het inzetten van hun grote deep learning-modellen voor toepassingen zoals natuurlijke taalverwerking (NLP).

In een eerdere post bespraken we mogelijkheden en configureerbare instellingen in Implementatie van Amazon SageMaker-model dat kan de conclusie met deze grote modellen gemakkelijker maken. Vandaag kondigen we een nieuwe Amazon Sage Maker Deep Learning Container (DLC) waarmee u binnen enkele minuten aan de slag kunt met grote modelinferentie. Deze DLC bundelt enkele van de meest populaire open-sourcebibliotheken voor parallelle inferentie van modellen, zoals DeepSpeed ​​en Hugging Face Accelerate.

In dit bericht gebruiken we een nieuwe SageMaker grootmodel inferentie-DLC om twee van de meest populaire grote NLP-modellen in te zetten: BigScience's BLOEI-176B en meta's OPT-30B uit de Hugging Face-repository. In het bijzonder gebruiken we Deep Java Library (DJL)-serving- en tensor-parallellismetechnieken van DeepSpeed ​​om 0.1 seconde latentie per token te bereiken in een gebruiksscenario voor het genereren van tekst.

U vindt onze volledige voorbeeldnotitieboekjes in onze GitHub-repository.

Inferentietechnieken voor grote modellen

Taalmodellen zijn de laatste tijd explosief gestegen, zowel in omvang als in populariteit. Met gemakkelijke toegang vanuit modeldierentuinen zoals Hugging Face en verbeterde nauwkeurigheid en prestaties bij NLP-taken zoals classificatie en tekstgeneratie, grijpen beoefenaars steeds meer naar deze grote modellen. Grote modellen zijn echter vaak te groot om in het geheugen van een enkele versneller te passen. Het BLOOM-176B-model kan bijvoorbeeld meer dan 350 gigabyte aan acceleratorgeheugen nodig hebben, wat veel groter is dan de capaciteit van hardwareversnellers die tegenwoordig beschikbaar zijn. Dit vereist het gebruik van parallelle modeltechnieken uit bibliotheken zoals DeepSpeed ​​en Hugging Face Accelerate om een ​​model te distribueren over meerdere versnellers voor gevolgtrekking. In dit bericht gebruiken we de SageMaker groot model inferentiecontainer om latentie- en doorvoerprestaties te genereren en te vergelijken met behulp van deze twee open-sourcebibliotheken.

DeepSpeed ​​en Accelerate gebruiken verschillende technieken om grote taalmodellen voor gevolgtrekking te optimaliseren. Het belangrijkste verschil is dat van DeepSpeed gebruik van geoptimaliseerde kernels. Deze kernels kunnen de inferentielatentie drastisch verbeteren door knelpunten in de berekeningsgrafiek van het model te verminderen. Geoptimaliseerde kernels kunnen moeilijk te ontwikkelen zijn en zijn typisch specifiek voor een bepaalde modelarchitectuur; DeepSpeed ​​ondersteunt populaire grote modellen zoals OPT en BLOOM met deze geoptimaliseerde kernels. Daarentegen bevat de Accelerate-bibliotheek van Hugging Face op het moment van schrijven geen geoptimaliseerde kernels. Zoals we in onze resultatensectie bespreken, is dit verschil verantwoordelijk voor een groot deel van het prestatievoordeel dat DeepSpeed ​​heeft ten opzichte van Accelerate.

Een tweede verschil tussen DeepSpeed ​​en Accelerate is het type parallellisme van het model. Accelerate gebruikt pijplijnparallellisme om een ​​model te verdelen tussen de verborgen lagen van een model, terwijl DeepSpeed ​​tensorparallellisme gebruikt om de lagen zelf te verdelen. Pijplijnparallellisme is een flexibele benadering die meer modeltypen ondersteunt en de doorvoer kan verbeteren wanneer grotere batchgroottes worden gebruikt. Tensor-parallellisme vereist meer communicatie tussen GPU's omdat modellagen over meerdere apparaten kunnen worden verspreid, maar de latentie van gevolgtrekkingen kan verbeteren door meerdere GPU's tegelijkertijd in te schakelen. U kunt meer leren over parallellismetechnieken in: Inleiding tot modelparallellisme en Modelparallellisme.

Overzicht oplossingen

Om effectief grote taalmodellen te hosten, hebben we functies en ondersteuning nodig op de volgende belangrijke gebieden:

• Oplossingen bouwen en testen – Gezien de iteratieve aard van ML-ontwikkeling, hebben we de mogelijkheid nodig om te bouwen, snel te herhalen en te testen hoe het inferentie-eindpunt zich zal gedragen wanneer deze modellen worden gehost, inclusief de mogelijkheid om snel te falen. Deze modellen kunnen meestal alleen worden gehost op grotere instanties zoals p4dn of g5, en gezien de grootte van de modellen, kan het even duren om een ​​inferentie-instantie op te starten en een testiteratie uit te voeren. Lokaal testen heeft meestal beperkingen omdat je een vergelijkbare instantie nodig hebt om te testen, en deze modellen zijn niet gemakkelijk te verkrijgen.
• Op schaal implementeren en uitvoeren – De modelbestanden moeten op de inferentie-instanties worden geladen, wat op zichzelf al een uitdaging is gezien de grootte. Tar / Un-Tar als voorbeeld voor de Bloom-176B duurt ongeveer 1 uur om te maken en nog een uur om te laden. We hebben een alternatief mechanisme nodig om gemakkelijke toegang tot de modelbestanden mogelijk te maken.
• Het model laden als singleton – Voor een proces met meerdere werknemers moeten we ervoor zorgen dat het model slechts één keer wordt geladen, zodat we niet in race-omstandigheden terechtkomen en onnodige middelen uitgeven. In dit bericht laten we een manier zien om rechtstreeks te laden van Amazon eenvoudige opslagservice (Amazon S3). Dit werkt echter alleen als we de standaardinstellingen van de DJL gebruiken. Bovendien moet elke schaling van de eindpunten in een paar minuten kunnen draaien, wat een heroverweging vereist van hoe de modellen kunnen worden geladen en gedistribueerd.
• Sharding-frameworks - Deze modellen moeten meestal zijn, meestal door een tensor-parallelisme of door pijplijn-sharding als de typische sharding-technieken, en we hebben geavanceerde concepten zoals ZeRO-sharding bovenop tensor-sharding gebouwd. Raadpleeg voor meer informatie over sharding-technieken: Modelparallellisme. Om dit te bereiken, kunnen we verschillende combinaties hebben en frameworks gebruiken van NIVIDIA, DeepSpeed ​​en anderen. Dit vereist de mogelijkheid om BYOC te testen of 1P-containers te gebruiken en oplossingen te herhalen en benchmarkingtests uit te voeren. Misschien wilt u ook verschillende hostingopties testen, zoals asynchroon, serverloos en andere.
• Hardware selectie – Uw keuze in hardware wordt bepaald door alle bovengenoemde punten en verdere verkeerspatronen, use case-behoeften en modelgroottes.

In dit bericht gebruiken we DeepSpeed's geoptimaliseerde kernels en tensor parallellisme-technieken om BLOOM-176B en OPT-30B op SageMaker te hosten. We vergelijken ook de resultaten van Accelerate om de prestatievoordelen van geoptimaliseerde kernels en tensorparallellisme aan te tonen. Raadpleeg voor meer informatie over DeepSpeed ​​en Accelerate: DeepSpeed-inferentie: efficiënte inferentie van transformatormodellen mogelijk maken op ongekende schaal en Ongelooflijk snelle BLOOM-inferentie met DeepSpeed ​​en Accelerate.

In dit voorbeeld gebruiken we DJLServering als de oplossing voor het serveren van modellen. DJLServering is een krachtige universele model-serving-oplossing aangedreven door de Deep Java Library (DJL) die programmeertaal-agnostisch is. Voor meer informatie over de DJL en DJLServering, zie: Implementeer grote modellen op Amazon SageMaker met behulp van DJLServering en DeepSpeed ​​model parallelle inferentie.

Het is vermeldenswaard dat geoptimaliseerde kernels kunnen resulteren in precisieveranderingen en een gewijzigde berekeningsgrafiek, wat theoretisch zou kunnen resulteren in veranderd modelgedrag. Hoewel dit af en toe de uitkomst van de gevolgtrekking kan veranderen, verwachten we niet dat deze verschillen een wezenlijke invloed zullen hebben op de basisevaluatiestatistieken van een model. Desalniettemin wordt beoefenaars geadviseerd om te bevestigen dat de modeluitvoer is zoals verwacht bij het gebruik van deze kernels.

De volgende stappen demonstreren hoe u een BLOOM-176B-model in SageMaker implementeert met behulp van DJLServering en een SageMaker grootmodel inferentiecontainer. Het complete voorbeeld is ook beschikbaar in onze GitHub-repository.

De DJLServering SageMaker DLC-afbeelding gebruiken

Gebruik de volgende code om de DJLServering SageMaker DLC-image te gebruiken nadat u de regio hebt vervangen door uw specifieke regio waarin u de notebook gebruikt:

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

Maak ons ​​modelbestand

Eerst maken we een bestand met de naam serving.properties die slechts één regel code bevat. Dit vertelt de DJL-modelserver om de DeepSpeed-engine te gebruiken. Het bestand bevat de volgende code:

engine=DeepSpeed

serving.properties is een bestand gedefinieerd door DJLServing dat wordt gebruikt om de configuratie per model te configureren.

Vervolgens maken we onze model.py bestand, dat de code definieert die nodig is om het model te laden en vervolgens te bedienen. In onze code lezen we in de TENSOR_PARALLEL_DEGREE omgevingsvariabele (de standaardwaarde is 1). Dit stelt het aantal apparaten in waarover de parallelle tensor-modules worden verdeeld. Merk op dat DeepSpeed ​​enkele ingebouwde partitiedefinities biedt, waaronder een voor BLOOM-modellen. We gebruiken het door te specificeren: replace_method en relpace_with_kernel_inject. Als je een aangepast model hebt en DeepSpeed ​​nodig hebt om effectief te partitioneren, moet je veranderen relpace_with_kernel_inject naar false en voeg injection_policy om de runtime-partitie te laten werken. Voor meer informatie, zie: Initialiseren voor gevolgtrekking. Voor ons voorbeeld hebben we het vooraf gepartitioneerde BLOOM-model op DeepSpeed ​​gebruikt.

Ten tweede, in de model.py bestand, laden we het model ook van Amazon S3 nadat het eindpunt is opgedraaid. Het model wordt geladen in de /tmp ruimte op de container omdat SageMaker de /tmp aan de Amazon elastische blokwinkel (Amazon EBS) volume dat wordt aangekoppeld wanneer we de parameter voor het maken van het eindpunt opgeven VolumeSizeInGB. Voor instanties zoals p4dn, die vooraf zijn gebouwd met de volume-instantie, kunnen we gebruik blijven maken van de /tmp op de container. Zie de volgende code:

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

DJLServering beheert de runtime-installatie op alle pip-pakketten gedefinieerd in requirement.txt. Dit bestand heeft:

awscli
boto3

We hebben een map gemaakt met de naam code en model.py, serving.properties en requirements.txt bestanden zijn al gemaakt in deze map. Om de bestanden te bekijken, kunt u de volgende code uitvoeren vanaf de terminal:

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

De volgende afbeelding toont de structuur van de model.tar.gz.

Ten slotte maken we het modelbestand en uploaden het naar Amazon S3:

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

Download en bewaar het model van Hugging Face (optioneel)

We hebben de stappen in dit gedeelte gegeven voor het geval u het model naar Amazon S3 wilt downloaden en vanaf daar wilt gebruiken. De stappen worden gegeven in het Jupyter-bestand op GitHub. De volgende schermafbeelding toont een momentopname van de stappen.

Een SageMaker-model maken

We maken nu een SageMaker-model. Wij gebruiken de Amazon Elastic Container-register (Amazon ECR) afbeelding geleverd door en het modelartefact uit de vorige stap om het SageMaker-model te maken. In de modelconfiguratie configureren we TENSOR_PARALLEL_DEGREE=8, wat betekent dat het model is verdeeld over 8 GPU's. Zie de volgende code:

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

Nadat u de voorgaande cel in het Jupyter-bestand hebt uitgevoerd, ziet u een uitvoer die lijkt op het volgende:

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

Een SageMaker-eindpunt maken

U kunt alle instanties met meerdere GPU's gebruiken om te testen. In deze demo gebruiken we een p4d.24xlarge instance. Merk in de volgende code op hoe we de . instellen ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds en VolumeSizeInGB parameters om de grote modelgrootte te accommoderen. De VolumeSizeInGB parameter is van toepassing op GPU-instanties die de EBS-volumebijlage ondersteunen.

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

Ten slotte maken we een SageMaker-eindpunt:

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

Je ziet het afgedrukt in de volgende code:

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

Het starten van het eindpunt kan even duren. Je kunt het nog een paar keer proberen als je de tegenkomt InsufficientInstanceCapacity fout, of u kunt een verzoek indienen bij AWS om de limiet in uw account te verhogen.

Prestatieafstemming

Als je van plan bent om dit bericht en de bijbehorende notebook met een ander model te gebruiken, wil je misschien enkele van de afstembare parameters verkennen die SageMaker, DeepSpeed ​​en de DJL bieden. Iteratief experimenteren met deze parameters kan een materiële impact hebben op de latentie, doorvoer en kosten van uw gehoste grote model. Raadpleeg voor meer informatie over afstemmingsparameters zoals het aantal werkers, de mate van tensorparallellisme, de grootte van de taakwachtrij en andere DJL-serverconfiguraties en Implementeer grote modellen op Amazon SageMaker met behulp van DJLServering en DeepSpeed ​​model parallelle inferentie.

Resultaten

In dit bericht hebben we DeepSpeed ​​gebruikt om BLOOM-176B en OPT-30B te hosten op SageMaker ML-instanties. De volgende tabel geeft een overzicht van onze prestatieresultaten, inclusief een vergelijking met Hugging Face's Accelerate. Latency geeft het aantal milliseconden weer dat nodig is om vier keer een string van 256 tokens te produceren (batch_size=4) uit het model. Doorvoer geeft het aantal tokens weer dat per seconde voor elke test wordt geproduceerd. Voor Hugging Face Accelerate gebruikten we de standaard laden van de bibliotheek met GPU-geheugentoewijzing. Voor DeepSpeed ​​hebben we het snellere laadmechanisme voor checkpoints gebruikt.

Vanuit latentieperspectief is DeepSpeed ​​ongeveer 3.4 keer sneller voor BLOOM-176B en 5.6 keer sneller voor OPT-30B dan Accelerate. De geoptimaliseerde kernels van DeepSpeed ​​zijn verantwoordelijk voor een groot deel van dit verschil in latentie. Gezien deze resultaten raden we aan om DeepSpeed ​​boven Accelerate te gebruiken als uw model naar keuze wordt ondersteund.

Het is ook vermeldenswaard dat de laadtijden van modellen met DeepSpeed ​​veel korter waren, waardoor het een betere optie is als u verwacht dat u snel uw aantal eindpunten moet opschalen. Accelerate's meer flexibele pijplijn parallellisme techniek kan een betere optie zijn als je modellen of model precisies hebt die niet ondersteund worden door DeepSpeed.

Deze resultaten tonen ook het verschil in latentie en doorvoer van verschillende modelgroottes. In onze tests genereert OPT-30B 2.4 keer het aantal tokens per tijdseenheid dan BLOOM-176B op een instantietype dat meer dan drie keer goedkoper is. Op basis van een prijs per doorvoereenheid is OPT-30B op een g5.24xl-instantie 8.9 keer beter dan BLOOM-176B op een p4d.24xl-instantie. Als u strikte latentie-, doorvoer- of kostenbeperkingen hebt, overweeg dan om het kleinst mogelijke model te gebruiken dat nog steeds aan functionele vereisten voldoet.

Opruimen

Als onderdeel van best practices wordt het altijd aanbevolen om inactieve instanties te verwijderen. De onderstaande code laat zien hoe u de instanties verwijdert.

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

Verwijder optioneel het modelcontrolepunt van uw S3

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

Conclusie

In dit bericht hebben we laten zien hoe u SageMaker-containers voor grote modelinferenties kunt gebruiken om twee grote taalmodellen te hosten, BLOOM-176B en OPT-30B. We gebruikten de parallelle technieken van DeepSpeed ​​met meerdere GPU's op een enkele SageMaker ML-instantie.

Voor meer details over Amazon SageMaker en de mogelijkheden voor het maken van grote modellen, zie: Amazon SageMaker ondersteunt nu de implementatie van grote modellen via configureerbare volumegrootte en time-outquota en Real-time gevolgtrekking.

Over de auteurs

Simon Zamarin is een AI / ML Solutions Architect die zich voornamelijk richt op het helpen van klanten om waarde uit hun data-assets te halen. In zijn vrije tijd brengt Simon graag tijd door met familie, leest hij sci-fi en werkt hij aan verschillende doe-het-zelfprojecten.

Rupinder Grewal is een Sr Ai/ML Specialist Solutions Architect bij AWS. Hij richt zich momenteel op het bedienen van modellen en MLOps op SageMaker. Voorafgaand aan deze functie heeft hij gewerkt als Machine Learning Engineer voor het bouwen en hosten van modellen. Naast zijn werk speelt hij graag tennis en fietst hij graag op bergpaden.

Frank Liu is een Software Engineer voor AWS Deep Learning. Hij richt zich op het bouwen van innovatieve deep learning-tools voor software-ingenieurs en wetenschappers. In zijn vrije tijd trekt hij graag met vrienden en familie.

Alan Tan is een Senior Product Manager bij SageMaker die leiding geeft aan de inferentie van grote modellen. Hij is gepassioneerd over het toepassen van Machine Learning op het gebied van Analytics. Buiten het werk geniet hij van het buitenleven.

Dhawal Patel is een Principal Machine Learning Architect bij AWS. Hij heeft gewerkt met organisaties variërend van grote ondernemingen tot middelgrote startups aan problemen met betrekking tot gedistribueerde computing en kunstmatige intelligentie. Hij richt zich op Deep learning inclusief NLP en Computer Vision domeinen. Hij helpt klanten bij het bereiken van high-performance modelinferentie op SageMaker.

Qing Lan is een Software Development Engineer bij AWS. Hij heeft aan verschillende uitdagende producten in Amazon gewerkt, waaronder hoogwaardige ML-inferentieoplossingen en een hoogwaardig logsysteem. Het team van Qing lanceerde met succes het eerste miljard-parametermodel in Amazon Advertising met een zeer lage latentie vereist. Qing heeft diepgaande kennis over de optimalisatie van de infrastructuur en de versnelling van Deep Learning.

Qingwei Li is Machine Learning Specialist bij Amazon Web Services. Hij behaalde zijn Ph.D. in Operations Research nadat hij de onderzoeksbeursrekening van zijn adviseur had verbroken en de beloofde Nobelprijs niet kon leveren. Momenteel helpt hij klanten in de financiële dienstverlening en de verzekeringssector bij het bouwen van machine learning-oplossingen op AWS. In zijn vrije tijd houdt hij van lezen en lesgeven.

Robert van Dusen is Senior Product Manager bij Amazon SageMaker. Hij leidt deep learning-modeloptimalisatie voor toepassingen zoals grote modelinferentie.

Siddharth Venkatesan is een Software Engineer in AWS Deep Learning. Hij richt zich momenteel op het bouwen van oplossingen voor grote modelinferentie. Voordat hij bij AWS kwam, werkte hij in de Amazon Grocery-organisatie aan het ontwikkelen van nieuwe betalingsfuncties voor klanten over de hele wereld. Buiten zijn werk houdt hij van skiën, het buitenleven en sport kijken.