Inferenza ML economicamente vantaggiosa con modelli multi-framework su Amazon SageMaker 

L’apprendimento automatico (ML) ha dimostrato di essere una delle applicazioni tecnologiche di maggior successo e diffusione, interessando un’ampia gamma di settori e incidendo su miliardi di utenti ogni giorno. Con questa rapida adozione del machine learning in ogni settore, le aziende si trovano ad affrontare sfide nel supportare previsioni a bassa latenza e con elevata disponibilità, massimizzando al contempo l’utilizzo delle risorse e riducendo i costi associati. Poiché ogni framework ML ha le proprie dipendenze e le fasi di distribuzione per ogni framework sono diverse, la distribuzione di modelli creati in framework diversi in produzione e la gestione di ciascuno degli endpoint diventano sempre più complesse.

Amazon Sage Maker Gli endpoint multi-container (MCE) ci consentono di raggruppare modelli su framework diversi e distribuirli sullo stesso host, creando un singolo endpoint. Puoi fornire contenitori per i diversi framework che stai utilizzando per creare i modelli e SageMaker prende tutti questi contenitori e li inserisce dietro un endpoint. Ad esempio, potresti caricare un modello PyTorch e un modello TensorFlow su due endpoint dedicati che servono casi d'uso uguali o completamente diversi ed entrambi questi modelli hanno traffico in entrata intermittente che non utilizza le risorse al limite. In uno scenario di questo tipo, potresti raggrupparli insieme utilizzando i contenitori in un unico endpoint utilizzando un MCE, migliorando l'utilizzo delle risorse e riducendo al tempo stesso i costi sostenuti per avere entrambi i modelli serviti da endpoint diversi.

Gli endpoint multi-contenitore forniscono una soluzione scalabile ed economica per distribuire fino a 15 modelli basati su diversi framework ML, server modelli e algoritmi che servono lo stesso caso d'uso o diversi, il che significa che è possibile avere modelli creati su diversi framework ML o intermediari attraversa tutti questi contenitori e modelli. È possibile accedere a tutti questi modelli individualmente tramite invocazione diretta o inseriti in una pipeline utilizzando l'invocazione seriale, dove l'output di un modello è l'input per quello successivo.

In questo post, discutiamo di come eseguire un'inferenza ML economicamente vantaggiosa con modelli multi-framework su SageMaker.

Modelli di invocazione MCE

L'invocazione diretta di SageMaker MCE è utile nei casi in cui hai inserito modelli non correlati in un endpoint MCE o stai eseguendo un test A/B tra i modelli dietro un endpoint MCE per valutarne le prestazioni. Puoi chiamare il contenitore specifico direttamente nella chiamata API e ottenere la previsione da quel modello.

Con l'invocazione seriale, puoi unire 2-15 contenitori e l'output di uno diventa l'input del contenitore successivo in sequenza. Questo è un caso d'uso ideale se, ad esempio, disponi di una pipeline di previsione in più fasi in cui un modello Scikit-learn viene utilizzato per una previsione intermedia e il risultato viene inviato a un modello TensorFlow per l'inferenza finale. Invece di distribuirli come endpoint diversi e un'altra applicazione o lavoro che li orchestra ed effettua più chiamate API, puoi distribuirli come SageMaker MCE, astraendo la logica e configurandoli per l'invocazione seriale, dove SageMaker gestisce il trasferimento dei dati tra un contenitore a un altro automaticamente ed emette l'output del contenitore finale al client che effettua la richiesta API.

L'invocazione seriale di SageMaker MCE è fondamentalmente diversa da una pipeline di inferenza seriale di SageMaker (maggiori dettagli nelle sezioni seguenti). Una pipeline di inferenza seriale è mirata maggiormente all'orchestrazione di flussi di lavoro ML complessi come la preelaborazione dei dati, la creazione di un insieme di modelli, l'implementazione di controlli condizionali per determinare quale modello invocare o la postelaborazione della previsione, coinvolgendo la logica aziendale prima che la previsione venga inviata alle applicazioni downstream . Al contrario, l'invocazione seriale di MCE è progettata per unire 2-14 modelli in una pipeline per l'inferenza, ciascun modello prendendo come input la previsione del modello precedente.

Tutti i contenitori in un MCE sono sempre in servizio e in memoria, quindi non è previsto alcun avvio a freddo durante il richiamo dell'endpoint. Gli MCE migliorano inoltre l'utilizzo degli endpoint e riducono i costi perché i modelli vengono distribuiti dietro un endpoint e condividono l'istanza di calcolo sottostante, invece di occupare ogni modello le singole risorse di calcolo.

Diamo un'occhiata ad alcuni casi d'uso e vediamo come utilizzare gli MCE SageMaker per ottimizzare l'inferenza ML.

Casi d'uso per gli MCE SageMaker

Supponiamo di avere due modelli per la classificazione del sentiment, uno per la lingua inglese e l'altro per la lingua tedesca, e che questi modelli servono aree geografiche diverse con traffico in arrivo in momenti diversi della giornata. Invece di avere due endpoint in esecuzione 24 ore su 7, XNUMX giorni su XNUMX, puoi distribuirli entrambi in un unico endpoint utilizzando un MCE e accedervi utilizzando l'invocazione diretta, ottimizzando così l'utilizzo delle risorse e i costi. Vedere il seguente codice:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

In questo esempio, abbiamo due modelli (englishModel ed germanModel) e definiamo i contenitori in SageMaker create_model costruire e definire il InferenceExecutionConfig come 'Diretto'. Ora possiamo chiamare l'endpoint per l'inferenza e definire il file TargetContainerHostname sia come englishModel or germanModel a seconda del client che effettua la chiamata API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Puoi anche utilizzare l'invocazione diretta all'interno di MCE per eseguire test A/B per confrontare le prestazioni tra i modelli.

Il diagramma seguente illustra la nostra architettura.

Allo stesso modo, in altri casi d'uso ML, quando il modello addestrato viene utilizzato per elaborare una richiesta, il modello riceve i dati in un formato che deve essere preelaborato (ad esempio, messo in evidenza) prima di poter essere passato all'algoritmo per l'inferenza. Quando gli algoritmi ML sono concatenati insieme, l'output di un modello funge da input per quello successivo prima di raggiungere il risultato finale. In questo caso, puoi creare una pipeline seriale SageMaker MCE, in cui i contenitori comunicano tra loro nella sequenza definita nel create_model costruire invece di distribuire ciascuno dei modelli in endpoint diversi e scrivere una logica indipendente per facilitare il flusso di dati tra tutti questi modelli e chiamate API. Il diagramma seguente illustra questa architettura.

Per questo caso d'uso, utilizziamo il seguente codice:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

In questo esempio, abbiamo due contenitori di elaborazione (Processing-1 ed Processing-2) per l'elaborazione delle funzionalità e le trasformazioni dei dati e due contenitori di inferenza (Inference-1 ed Inference-2) per eseguire previsioni del modello ML sui dati preelaborati. IL PipelineModel L'istanza consente di definire la pipeline di inferenza composta da una sequenza lineare di quattro contenitori che elaborano le richieste di inferenza sui dati. I contenitori si trovano nella stessa istanza, consentendoti di eseguire l'inferenza con bassa latenza.

Scala gli endpoint multi-modello per un gran numero di modelli

I vantaggi degli endpoint multimodello SageMaker aumentano in base alla portata del consolidamento del modello. Puoi notare un risparmio sui costi quando si ospitano due modelli con un endpoint e, per i casi d'uso con centinaia o migliaia di modelli, il risparmio è molto maggiore.

Anche il ridimensionamento degli endpoint MCE è semplice utilizzando il file SageMakerVariantInvocationsPerInstance metrica predefinita, che fornisce il numero medio di volte al minuto in cui ciascuna istanza di un endpoint del modello viene richiamata per definire un TargetScaling politica. SageMaker regola dinamicamente il numero di istanze fornite per un modello in risposta ai cambiamenti nel carico di lavoro. Quando il carico di lavoro aumenta, la scalabilità automatica porta più istanze online e carica i modelli e i contenitori di destinazione per continuare a soddisfare le richieste. Quando il carico di lavoro diminuisce, la scalabilità automatica rimuove le istanze non necessarie e scarica i contenitori del modello in modo che i contenitori non consumino le risorse e non paghi per le istanze che non stai utilizzando. Il tempo necessario per completare la prima richiesta rispetto a un determinato modello presenta una latenza aggiuntiva (chiamata avvio a freddo) da cui scaricare il modello Servizio di archiviazione semplice Amazon (Amazon S3) e caricarlo in memoria. Le chiamate successive terminano senza alcun sovraccarico aggiuntivo poiché il modello è già caricato. Vedere il seguente codice:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Seguendo la configurazione della policy di esempio precedente, utilizziamo il file SageMakerVariantInvocationsPerInstance metrica predefinita per regolare il numero di istanze varianti in modo che ogni istanza abbia un InvocationsPerInstance metrica di 70.

Possiamo anche ridimensionare gli MCE SageMaker in base alla nostra metrica personalizzata, come ad esempio CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization, o DiskUtilization, per aumentare o ridurre il numero di istanze in base all'utilizzo di una risorsa specifica. Per ulteriori informazioni, fare riferimento a Ridimensiona automaticamente i modelli Amazon SageMaker.

È consigliabile che il modello in ciascun contenitore presenti requisiti di calcolo e latenza simili su ciascuna richiesta di inferenza, perché se il traffico verso MCE passa da un modello di utilizzo elevato della CPU a un modello di utilizzo basso della CPU, ma il volume complessivo delle chiamate rimane lo stesso, l'endpoint non è scalabile e potrebbero non esserci istanze sufficienti per gestire tutte le richieste al modello di utilizzo elevato della CPU.

MCE sicuri

Per gli MCE con invocazione diretta, più contenitori sono ospitati in una singola istanza condividendo memoria e un volume di archiviazione. È importante proteggere i contenitori, mantenere la corretta mappatura delle richieste ai contenitori di destinazione e fornire agli utenti l'accesso corretto ai contenitori di destinazione. Puoi limitare invoke_endpoint accesso a un insieme limitato di contenitori all'interno di un MCE utilizzando il file sagemaker:TargetContainerHostname Gestione dell'identità e dell'accesso di AWS (IAM) chiave di condizione. SageMaker utilizza Ruoli IAM per fornire policy basate sull'identità IAM da utilizzare per specificare le azioni e le risorse consentite o negate e le condizioni in base alle quali le azioni sono consentite o negate. Le seguenti policy mostrano come limitare le chiamate a contenitori specifici all'interno di un endpoint:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Monitora gli endpoint multimodello utilizzando i parametri Amazon CloudWatch

Per trovare un compromesso tra prezzo e prestazioni, ti consigliamo di testare gli endpoint multi-modello con modelli e traffico rappresentativo dalla tua stessa applicazione. SageMaker fornisce metriche aggiuntive in Amazon Cloud Watch per endpoint multimodello in modo da poter determinare l'utilizzo dell'endpoint e la percentuale di riscontri nella cache e ottimizzare l'endpoint. Le metriche sono le seguenti:

• ModelLoadingWaitTime – L'intervallo di tempo in cui una richiesta di chiamata attende il download o il caricamento del modello di destinazione per eseguire l'inferenza.
• ModelloUnloadingTime – L'intervallo di tempo necessario per scaricare il modello attraverso il container UnloadModel Chiamata API.
• ModelloDownloadingTime – L'intervallo di tempo necessario per scaricare il modello da Amazon S3.
• ModelloLoadingTime – L'intervallo di tempo necessario per caricare il modello attraverso il contenitore LoadModel Chiamata API.
• ModelCacheHit - Il numero di InvokeEndpoint richieste inviate all'endpoint in cui il modello era già caricato. Prendendo il Average la statistica mostra il rapporto tra richieste in cui il modello era già caricato.
• Conteggio modello caricato – Il numero di modelli caricati nei contenitori nell'endpoint. Questa metrica viene emessa per istanza. IL Average la statistica con un periodo di 1 minuto indica il numero medio di modelli caricati per istanza e il Sum La statistica indica il numero totale di modelli caricati in tutte le istanze nell'endpoint. I modelli tracciati da questa metrica non sono necessariamente univoci perché puoi caricare un modello in più contenitori nell'endpoint.

Esistono anche molti altri parametri utilizzati da ciascun contenitore in esecuzione su un'istanza, ad esempio Invocations indicando il numero di InvokeEndpoint richieste inviate a un contenitore all'interno di un endpoint, ContainerLatency fornendo il tempo impiegato da un endpoint affinché il contenitore di destinazione o tutti i contenitori in un'invocazione seriale rispondano come visualizzato da SageMaker e CPUUtilization ed MemoryUtilizaton indicando le unità CPU e la percentuale di memoria.

Conclusione

Nel post abbiamo discusso di come gli endpoint multi-contenitore SageMaker possano essere utili per ottimizzare i costi e l'utilizzo delle risorse. Esempi di quando utilizzare gli MCE includono, ma non sono limitati a, quanto segue:

• Modelli di hosting su framework diversi (come TensorFlow, PyTorch e Scikit-learn) che non hanno traffico sufficiente per saturare la piena capacità di un'istanza
• Hosting di modelli dallo stesso framework con diversi algoritmi ML (come raccomandazioni, previsioni o classificazione) e funzioni di gestione
• Confronti di architetture simili eseguite su versioni di framework differenti (come TensorFlow 1.x e TensorFlow 2.x) per scenari come test A/B

Gli MCE SageMaker supportano la distribuzione fino a 15 contenitori su endpoint in tempo reale e il loro richiamo indipendente per inferenza a bassa latenza e risparmi sui costi. I modelli possono essere completamente eterogenei, con il proprio stack di servizio indipendente. Puoi richiamare questi contenitori in sequenza o in modo indipendente per ogni richiesta. L'hosting sicuro di più modelli, provenienti da framework diversi, su una singola istanza potrebbe farti risparmiare fino al 90% sui costi rispetto all'hosting di modelli in endpoint dedicati a istanza singola.

Circa gli autori

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 un'inferenza del modello ad alte prestazioni su Amazon SageMaker.

Vikram Elango è un Senior AI/ML Specialist Solutions Architect presso Amazon Web Services, con sede in Virginia, Stati Uniti. Vikram aiuta i clienti globali del settore finanziario e assicurativo con leadership di progettazione e pensiero per creare e distribuire applicazioni di machine learning su larga scala. Attualmente si concentra sull'elaborazione del linguaggio naturale, sull'intelligenza artificiale responsabile, sull'ottimizzazione dell'inferenza e sulla scalabilità del machine learning in tutta l'azienda. Nel tempo libero gli piace viaggiare, fare escursioni, cucinare e campeggiare con la sua famiglia.

Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti ed è motivato dall'obiettivo di democratizzare l'apprendimento automatico. Si concentra sulle sfide principali relative all'implementazione di applicazioni ML complesse, modelli ML multi-tenant, ottimizzazioni dei costi e rendere più accessibile l'implementazione di modelli di deep learning. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.