Distribuisci BLOOM-176B e OPT-30B su Amazon SageMaker con inferenza di modelli di grandi dimensioni Deep Learning Containers e DeepSpeed

Gli ultimi anni hanno visto un rapido sviluppo nel campo del deep learning. Sebbene l'hardware sia migliorato, ad esempio con l'ultima generazione di acceleratori di NVIDIA e Amazon, i professionisti avanzati del machine learning (ML) riscontrano ancora regolarmente problemi nell'implementazione dei loro grandi modelli di deep learning per applicazioni come l'elaborazione del linguaggio naturale (NLP).

In un post precedente, abbiamo discusso funzionalità e impostazioni configurabili in Distribuzione del modello Amazon SageMaker che può rendere più semplice l’inferenza con questi modelli di grandi dimensioni. Oggi ne annunciamo una nuova Amazon Sage Maker Deep Learning Container (DLC) che puoi utilizzare per iniziare a eseguire l'inferenza di modelli di grandi dimensioni in pochi minuti. Questo DLC racchiude alcune delle librerie open source più popolari per l'inferenza parallela dei modelli, come DeepSpeed ​​e Hugging Face Accelerate.

In questo post, utilizziamo un nuovo DLC di inferenza di modelli di grandi dimensioni di SageMaker per distribuire due dei modelli di PNL di grandi dimensioni più popolari: BigScience BLOOM-176B e di Meta OPT-30B dal repository Hugging Face. In particolare, utilizziamo le tecniche di servizio e parallelismo tensore della Deep Java Library (DJL) di DeepSpeed ​​per ottenere una latenza di 0.1 secondi per token in un caso d'uso di generazione di testo.

Puoi trovare i nostri quaderni di esempio completi nel nostro Repository GitHub.

Tecniche di inferenza di modelli di grandi dimensioni

I modelli linguistici sono recentemente esplosi sia in termini di dimensioni che di popolarità. Con un facile accesso da zoo modello come Hugging Face e una migliore precisione e prestazioni nelle attività di PNL come la classificazione e la generazione di testo, i professionisti si rivolgono sempre più a questi modelli di grandi dimensioni. Tuttavia, i modelli di grandi dimensioni sono spesso troppo grandi per essere contenuti nella memoria di un singolo acceleratore. Ad esempio, il modello BLOOM-176B può richiedere più di 350 gigabyte di memoria dell'acceleratore, che supera di gran lunga la capacità degli acceleratori hardware oggi disponibili. Ciò richiede l'uso di tecniche parallele del modello da librerie come DeepSpeed ​​e Hugging Face Accelerate per distribuire un modello su più acceleratori per l'inferenza. In questo post utilizziamo il file Contenitore di inferenza di modello di grandi dimensioni SageMaker per generare e confrontare le prestazioni di latenza e throughput utilizzando queste due librerie open source.

DeepSpeed ​​e Accelerate utilizzano tecniche diverse per ottimizzare modelli linguistici di grandi dimensioni per l'inferenza. La differenza fondamentale è quella di DeepSpeed utilizzo di kernel ottimizzati. Questi kernel possono migliorare notevolmente la latenza di inferenza riducendo i colli di bottiglia nel grafico di calcolo del modello. I kernel ottimizzati possono essere difficili da sviluppare e sono tipicamente specifici per una particolare architettura del modello; DeepSpeed ​​supporta modelli di grandi dimensioni popolari come OPT e BLOOM con questi kernel ottimizzati. Al contrario, la libreria Accelerate di Hugging Face non include kernel ottimizzati al momento della scrittura. Come discusso nella nostra sezione dei risultati, questa differenza è responsabile di gran parte del vantaggio prestazionale che DeepSpeed ​​ha rispetto ad Accelerate.

Una seconda differenza tra DeepSpeed ​​e Accelerate è il tipo di parallelismo del modello. Accelerate utilizza il parallelismo della pipeline per partizionare un modello tra gli strati nascosti di un modello, mentre DeepSpeed ​​utilizza il parallelismo del tensore per partizionare gli strati stessi. Il parallelismo della pipeline è un approccio flessibile che supporta più tipi di modelli e può migliorare la produttività quando vengono utilizzate batch di dimensioni maggiori. Il parallelismo tensore richiede una maggiore comunicazione tra le GPU perché i livelli del modello possono essere distribuiti su più dispositivi, ma può migliorare la latenza di inferenza coinvolgendo più GPU contemporaneamente. Puoi saperne di più sulle tecniche di parallelismo in Introduzione al parallelismo dei modelli ed Parallelismo del modello.

Panoramica della soluzione

Per ospitare in modo efficace modelli linguistici di grandi dimensioni, abbiamo bisogno di funzionalità e supporto nelle seguenti aree chiave:

• Costruire e testare soluzioni – Data la natura iterativa dello sviluppo ML, abbiamo bisogno della capacità di costruire, iterare rapidamente e testare come si comporterà l’endpoint di inferenza quando questi modelli sono ospitati, inclusa la capacità di fallire velocemente. Questi modelli in genere possono essere ospitati solo su istanze più grandi come p4dn o g5 e, data la dimensione dei modelli, può essere necessario del tempo per avviare un'istanza di inferenza ed eseguire qualsiasi iterazione di test. Il test locale in genere presenta dei vincoli perché è necessaria un'istanza di dimensioni simili per eseguire il test e questi modelli non sono facili da ottenere.
• Distribuzione ed esecuzione su larga scala – I file del modello devono essere caricati sulle istanze di inferenza, il che rappresenta di per sé una sfida date le dimensioni. Tar/Un-Tar, ad esempio per Bloom-176B, richiede circa 1 ora per la creazione e un'altra ora per il caricamento. Abbiamo bisogno di un meccanismo alternativo per consentire un facile accesso ai file del modello.
• Caricamento del modello come singleton – Per un processo multi-lavoratore, dobbiamo garantire che il modello venga caricato una sola volta in modo da non incappare in condizioni di competizione e spendere ulteriormente risorse non necessarie. In questo post mostriamo un modo per caricare direttamente da Servizio di archiviazione semplice Amazon (Amazon S3). Tuttavia, questo funziona solo se utilizziamo le impostazioni predefinite del DJL. Inoltre, qualsiasi ridimensionamento degli endpoint deve essere in grado di avviarsi in pochi minuti, il che richiede di riconsiderare il modo in cui i modelli potrebbero essere caricati e distribuiti.
• Framework di partizionamento orizzontale – Questi modelli in genere devono essere , di solito mediante un meccanismo di parallelismo tensore o tramite lo sharding della pipeline come le tipiche tecniche di sharding, e disponiamo di concetti avanzati come lo sharding ZeRO costruito sopra lo sharding del tensore. Per ulteriori informazioni sulle tecniche di partizionamento orizzontale, fare riferimento a Parallelismo del modello. Per raggiungere questo obiettivo, possiamo avere varie combinazioni e utilizzare framework di NIVIDIA, DeepSpeed ​​e altri. Ciò richiede la capacità di testare BYOC o utilizzare contenitori 1P ed eseguire iterazioni sulle soluzioni ed eseguire test di benchmarking. Potresti anche voler testare varie opzioni di hosting come asincrono, serverless e altre.
• Selezione dell'hardware – La scelta dell'hardware è determinata da tutti i punti sopra menzionati e da ulteriori modelli di traffico, esigenze dei casi d'uso e dimensioni del modello.

In questo post, utilizziamo i kernel ottimizzati di DeepSpeed ​​e le tecniche di parallelismo del tensore per ospitare BLOOM-176B e OPT-30B su SageMaker. Confrontiamo anche i risultati di Accelerate per dimostrare i vantaggi prestazionali dei kernel ottimizzati e del parallelismo dei tensori. Per ulteriori informazioni su DeepSpeed ​​e Accelerate, fare riferimento a Inferenza DeepSpeed: Abilitazione di un'inferenza efficiente di modelli di trasformatori su scala senza precedenti ed Inferenza BLOOM incredibilmente veloce con DeepSpeed ​​e Accelerate.

Utilizziamo DJLServing come soluzione di presentazione dei modelli in questo esempio. DJLServing è una soluzione di modelserving universale ad alte prestazioni basata sulla Deep Java Library (DJL) indipendente dal linguaggio di programmazione. Per ulteriori informazioni su DJL e DJLServing, fare riferimento a Distribuisci modelli di grandi dimensioni su Amazon SageMaker utilizzando DJLServing e l'inferenza parallela del modello DeepSpeed.

Vale la pena notare che i kernel ottimizzati possono comportare cambiamenti di precisione e un grafico di calcolo modificato, che teoricamente potrebbe comportare un cambiamento nel comportamento del modello. Anche se ciò potrebbe occasionalmente modificare il risultato dell’inferenza, non ci aspettiamo che queste differenze abbiano un impatto materiale sui parametri di valutazione di base di un modello. Tuttavia, si consiglia ai professionisti di confermare che i risultati del modello siano quelli previsti quando si utilizzano questi kernel.

I passaggi seguenti dimostrano come distribuire un modello BLOOM-176B in SageMaker utilizzando DJLServing e un contenitore di inferenza di modelli di grandi dimensioni SageMaker. L'esempio completo è disponibile anche nel ns Repository GitHub.

Utilizzando l'immagine DLC DJLServing SageMaker

Utilizza il seguente codice per utilizzare l'immagine DLC DJLServing SageMaker dopo aver sostituito la regione con la regione specifica in cui stai utilizzando il notebook:

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 il nostro file modello

Per prima cosa, creiamo un file chiamato serving.properties che contiene solo una riga di codice. Ciò indica al server del modello DJL di utilizzare il motore DeepSpeed. Il file contiene il seguente codice:

engine=DeepSpeed

serving.properties è un file definito da DJLServing che viene utilizzato per configurare la configurazione per modello.

Successivamente, creiamo il nostro model.py file, che definisce il codice necessario per caricare e quindi servire il modello. Nel nostro codice leggiamo il TENSOR_PARALLEL_DEGREE variabile di ambiente (il valore predefinito è 1). Imposta il numero di dispositivi su cui sono distribuiti i moduli tensore parallelo. Tieni presente che DeepSpeed ​​fornisce alcune definizioni di partizioni integrate, inclusa una per i modelli BLOOM. Lo usiamo specificando replace_method ed relpace_with_kernel_inject. Se disponi di un modello personalizzato e hai bisogno che DeepSpeed ​​sia partizionato in modo efficace, devi cambiare relpace_with_kernel_inject a false e aggiungere injection_policy per far funzionare la partizione di runtime. Per ulteriori informazioni, fare riferimento a Inizializzazione per l'inferenza. Per il nostro esempio, abbiamo utilizzato il modello BLOOM pre-partizionato su DeepSpeed.

In secondo luogo, nel model.py file, carichiamo il modello anche da Amazon S3 dopo che l'endpoint è stato avviato. Il modello viene caricato nel file /tmp spazio sul contenitore perché SageMaker mappa il file /tmp Vai all’email Negozio di blocchi elastici di Amazon (Amazon EBS) che viene montato quando specifichiamo il parametro di creazione dell'endpoint VolumeSizeInGB. Per istanze come p4dn, che sono precostruite con l'istanza del volume, possiamo continuare a sfruttare il file /tmp sul contenitore. Vedere il seguente codice:

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 gestisce l'installazione del runtime su qualsiasi pacchetto pip definito in requirement.txt. Questo file avrà:

awscli
boto3

Abbiamo creato una directory chiamata code e la model.py, serving.propertiese requirements.txt i file sono già creati in questa directory. Per visualizzare i file, è possibile eseguire il seguente codice dal terminale:

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

La figura seguente mostra la struttura del model.tar.gz.

Infine, creiamo il file del modello e lo carichiamo su Amazon S3:

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

Scarica e archivia il modello da Hugging Face (facoltativo)

Abbiamo fornito i passaggi in questa sezione nel caso in cui desideri scaricare il modello su Amazon S3 e utilizzarlo da lì. I passaggi sono forniti nel file Jupyter su GitHub. Lo screenshot seguente mostra un'istantanea dei passaggi.

Crea un modello SageMaker

Ora creiamo un Modello SageMaker. Noi usiamo il Registro dei contenitori Amazon Elastic (Amazon ECR) fornita da e l'artefatto del modello del passaggio precedente per creare il modello SageMaker. Nella configurazione del modello, configuriamo TENSOR_PARALLEL_DEGREE=8, il che significa che il modello è partizionato lungo 8 GPU. Vedere il codice seguente:

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

Dopo aver eseguito la cella precedente nel file Jupyter, viene visualizzato un output simile al seguente:

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

Crea un endpoint SageMaker

Puoi utilizzare qualsiasi istanza con più GPU per i test. In questa demo utilizziamo un'istanza p4d.24xlarge. Nel codice seguente, nota come impostiamo il file ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSecondse VolumeSizeInGB parametri per adattarsi alle grandi dimensioni del modello. Il VolumeSizeInGB il parametro è applicabile alle istanze GPU che supportano il collegamento del volume 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,
        },
    ],
)'

Infine, creiamo un endpoint SageMaker:

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

Lo vedi stampato nel seguente codice:

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

L'avvio dell'endpoint potrebbe richiedere del tempo. Puoi provare un paio di volte se ti imbatti nel InsufficientInstanceCapacity errore oppure puoi inoltrare una richiesta ad AWS per aumentare il limite nel tuo account.

Ottimizzazione delle prestazioni

Se hai intenzione di utilizzare questo post e il notebook di accompagnamento con un modello diverso, potresti voler esplorare alcuni dei parametri sintonizzabili offerti da SageMaker, DeepSpeed ​​e DJL. La sperimentazione iterativa di questi parametri può avere un impatto sostanziale sulla latenza, sulla velocità effettiva e sui costi del modello di grandi dimensioni ospitato. Per ulteriori informazioni sull'ottimizzazione di parametri come il numero di lavoratori, il grado di parallelismo del tensore, la dimensione della coda dei lavori e altri, fare riferimento a Configurazioni di servizio DJL ed Distribuisci modelli di grandi dimensioni su Amazon SageMaker utilizzando DJLServing e l'inferenza parallela del modello DeepSpeed.

Risultati

In questo post, abbiamo utilizzato DeepSpeed ​​per ospitare BLOOM-176B e OPT-30B su istanze SageMaker ML. La tabella seguente riassume i nostri risultati prestazionali, incluso un confronto con Accelerate di Hugging Face. La latenza riflette il numero di millisecondi necessari per produrre una stringa da 256 token quattro volte (batch_size=4) dal modello. Il throughput riflette il numero di token prodotti al secondo per ciascun test. Per Hugging Face Accelerate abbiamo utilizzato il caricamento predefinito della libreria con la mappatura della memoria della GPU. Per DeepSpeed, abbiamo utilizzato il suo meccanismo di caricamento del checkpoint più veloce.

Dal punto di vista della latenza, DeepSpeed ​​è circa 3.4 volte più veloce per BLOOM-176B e 5.6 volte più veloce per OPT-30B rispetto ad Accelerate. I kernel ottimizzati di DeepSpeed ​​sono responsabili di gran parte di questa differenza di latenza. Considerati questi risultati, ti consigliamo di utilizzare DeepSpeed ​​anziché Accelerate se il tuo modello preferito è supportato.

Vale anche la pena notare che i tempi di caricamento del modello con DeepSpeed ​​erano molto più brevi, rendendolo un'opzione migliore se prevedi di dover aumentare rapidamente il numero di endpoint. La tecnica di parallelismo della pipeline più flessibile di Accelerate potrebbe rappresentare un'opzione migliore se disponi di modelli o precise caratteristiche di modello non supportati da DeepSpeed.

Questi risultati dimostrano anche la differenza in termini di latenza e throughput di diverse dimensioni del modello. Nei nostri test, OPT-30B genera 2.4 volte il numero di token per unità di tempo rispetto a BLOOM-176B su un tipo di istanza che è più di tre volte più economico. In base al prezzo per unità di throughput, OPT-30B su un'istanza g5.24xl è 8.9 volte migliore di BLOOM-176B su un'istanza p4d.24xl. Se hai limitazioni rigorose in termini di latenza, velocità effettiva o costi, prendi in considerazione l'utilizzo del modello più piccolo possibile che soddisferà comunque i requisiti funzionali.

ripulire

Come parte delle migliori pratiche, è sempre consigliabile eliminare le istanze inattive. Il codice seguente mostra come eliminare le istanze.

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

Facoltativamente, elimina il punto di controllo del modello dal tuo S3

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

Conclusione

In questo post, abbiamo dimostrato come utilizzare i contenitori di inferenza di modelli di grandi dimensioni SageMaker per ospitare due modelli linguistici di grandi dimensioni, BLOOM-176B e OPT-30B. Abbiamo utilizzato le tecniche di modello parallelo di DeepSpeed ​​con più GPU su una singola istanza di SageMaker ML.

Per ulteriori dettagli su Amazon SageMaker e le sue funzionalità di inferenza di modelli di grandi dimensioni, fare riferimento a Amazon SageMaker ora supporta la distribuzione di modelli di grandi dimensioni tramite dimensioni del volume configurabili e quote di timeout ed Inferenza in tempo reale.

Circa gli autori

Simone Zamarin è un architetto di soluzioni AI / ML il cui obiettivo principale è aiutare i clienti a estrarre valore dalle loro risorse di dati. Nel tempo libero, Simon ama passare il tempo con la famiglia, leggere fantascienza e lavorare a vari progetti di case fai da te.

Rupinder Grewal è un Senior Specialist Solutions Architect di Ai/ML con AWS. Attualmente si concentra sulla pubblicazione di modelli e MLOp su SageMaker. Prima di questo ruolo ha lavorato come Machine Learning Engineer, costruendo e ospitando modelli. Al di fuori del lavoro gli piace giocare a tennis e andare in bicicletta sui sentieri di montagna.

Franco Liu è un ingegnere software per AWS Deep Learning. Si concentra sulla creazione di strumenti innovativi di deep learning per ingegneri e scienziati del software. Nel tempo libero ama fare escursioni con amici e famiglia.

Alan Tan è un Senior Product Manager con SageMaker che guida gli sforzi sull'inferenza di modelli di grandi dimensioni. È appassionato di applicare il Machine Learning all'area dell'analisi. Al di fuori del lavoro, ama la vita all'aria aperta.

Dhawal Patel è un Principal Machine Learning Architect presso AWS. Ha lavorato con organizzazioni che vanno dalle grandi imprese alle startup di medie dimensioni su problemi legati all'informatica distribuita e all'intelligenza artificiale. Si concentra sull'apprendimento profondo, inclusi i domini della PNL e della visione artificiale. Aiuta i clienti a ottenere l'inferenza del modello ad alte prestazioni su SageMaker.

Qing Lan è un ingegnere di sviluppo software in AWS. Ha lavorato su diversi prodotti impegnativi in ​​Amazon, tra cui soluzioni di inferenza ML ad alte prestazioni e sistema di registrazione ad alte prestazioni. Il team di Qing ha lanciato con successo il primo modello di miliardi di parametri in Amazon Advertising con una latenza molto bassa richiesta. Qing ha una conoscenza approfondita dell'ottimizzazione dell'infrastruttura e dell'accelerazione del Deep Learning.

QingweiLi è uno specialista in machine learning presso Amazon Web Services. Ha conseguito il dottorato di ricerca. in Ricerca Operativa dopo che ha rotto il conto dell'assegno di ricerca del suo consulente e non è riuscito a consegnare il premio Nobel che aveva promesso. Attualmente aiuta i clienti nel settore dei servizi finanziari e assicurativi a creare soluzioni di machine learning su AWS. Nel tempo libero gli piace leggere e insegnare.

Roberto Van Dusen è Senior Product Manager di Amazon SageMaker. Dirige l'ottimizzazione del modello di deep learning per applicazioni come l'inferenza di modelli di grandi dimensioni.

Siddharth Venkatesan è un ingegnere software in AWS Deep Learning. Attualmente si concentra sulla creazione di soluzioni per l'inferenza di modelli di grandi dimensioni. Prima di AWS ha lavorato nell'organizzazione Amazon Grocery sviluppando nuove funzionalità di pagamento per clienti in tutto il mondo. Al di fuori del lavoro, gli piace sciare, stare all'aria aperta e guardare gli sport.