Migliora la ricerca di alto valore con Hugging Face e gli endpoint di inferenza asincrona Amazon SageMaker

Ripubblicato da Platone

Seguaci: 0

Molti dei nostri clienti AWS forniscono ricerca, analisi e business intelligence come servizio. Questo tipo di ricerca e business intelligence consente ai clienti finali di stare al passo con mercati e concorrenti, identificare opportunità di crescita e affrontare i problemi in modo proattivo. Ad esempio, alcuni dei nostri clienti del settore dei servizi finanziari effettuano ricerche su azioni, hedge fund e società di gestione degli investimenti per aiutarli a comprendere le tendenze e identificare le strategie di portafoglio. Nel settore sanitario, una parte sempre più ampia della ricerca sanitaria è ora basata sull’informazione. Gran parte della ricerca comporta l’analisi di dati inizialmente raccolti per scopi diagnostici, terapeutici o per altri progetti di ricerca e ora utilizzati per nuovi scopi di ricerca. Queste forme di ricerca sanitaria hanno portato a un’efficace prevenzione primaria per evitare nuovi casi, alla prevenzione secondaria per la diagnosi precoce e alla prevenzione per una migliore gestione della malattia. I risultati della ricerca non solo migliorano la qualità della vita ma aiutano anche a ridurre le spese sanitarie.

I clienti tendono a digerire le informazioni provenienti da fonti pubbliche e private. Quindi applicano modelli di elaborazione del linguaggio naturale (NLP) consolidati o personalizzati per riassumere e identificare una tendenza e generare approfondimenti basati su queste informazioni. I modelli di PNL utilizzati per questo tipo di attività di ricerca si occupano di modelli di grandi dimensioni e di solito comportano articoli lunghi da riassumere considerando la dimensione del corpus e endpoint dedicati, che al momento non sono ottimizzati in termini di costi. Queste applicazioni ricevono un'ondata di traffico in entrata in diversi orari della giornata.

Riteniamo che i clienti trarrebbero grandi vantaggi dalla possibilità di ridimensionare fino a zero e aumentare la propria capacità di inferenza in base alle necessità. Ciò ottimizza i costi di ricerca e non compromette comunque la qualità delle inferenze. Questo post discute di come abbracciare il viso insieme Amazon Sage Maker l'inferenza asincrona può aiutare a raggiungere questo obiettivo.

Puoi creare modelli di riepilogo del testo con più framework di deep learning come TensorFlow, PyTorch e Apache MXNet. Questi modelli in genere hanno un grande carico utile di input di più documenti di testo di varie dimensioni. I modelli avanzati di deep learning richiedono una preelaborazione ad alta intensità di calcolo prima dell'inferenza del modello. I tempi di elaborazione possono durare fino a pochi minuti, il che rimuove la possibilità di eseguire l'inferenza in tempo reale passando i payload su un'API HTTP. È invece necessario elaborare i payload di input in modo asincrono da un archivio oggetti come Servizio di archiviazione semplice Amazon (Amazon S3) con accodamento automatico e soglia di concorrenza predefinita. Il sistema dovrebbe essere in grado di ricevere notifiche sullo stato e ridurre i costi inutili ripulendo le risorse una volta completate le attività.

SageMaker aiuta i data scientist e gli sviluppatori a preparare, creare, addestrare e distribuire rapidamente modelli di machine learning (ML) di alta qualità riunendo un'ampia gamma di funzionalità create appositamente per il ML. SageMaker fornisce i contenitori di model-serving open source più avanzati per XGBoost (contenitore, SDK), Scikit-Impara (contenitore, SDK), PyTorch (contenitore, SDK), Flusso Tensore (contenitore, SDK) e Apache MXNet (contenitore, SDK).

SageMaker offre quattro opzioni per distribuire modelli ML addestrati per generare inferenze su nuovi dati.

Inferenza in tempo reale gli endpoint sono adatti per carichi di lavoro che devono essere elaborati con requisiti di bassa latenza nell'ordine da ms a secondi.
Trasformazione batch è ideale per previsioni offline su grandi batch di dati.
Inferenza serverless di Amazon SageMaker (in modalità di anteprima e non consigliata per carichi di lavoro di produzione al momento della stesura di questo documento) è un'opzione di inferenza appositamente creata che semplifica la distribuzione e la scalabilità dei modelli ML. L'inferenza serverless è ideale per carichi di lavoro che presentano periodi di inattività tra gli sbalzi di traffico e possono tollerare gli avvii a freddo.
Inferenza asincrona gli endpoint accodano le richieste in entrata. Sono ideali per carichi di lavoro in cui le dimensioni delle richieste sono elevate (fino a 1 GB) e i tempi di elaborazione dell'inferenza sono dell'ordine di minuti (fino a 15 minuti). L'inferenza asincrona ti consente di risparmiare sui costi ridimensionando automaticamente il conteggio delle istanze a zero quando non ci sono richieste da elaborare.

Panoramica della soluzione

In questo post, distribuiamo a Modello PEGASO da cui è stato pre-addestrato il riepilogo del testo Abbracciare il viso a Servizi di hosting SageMaker. Utilizziamo il modello così come proviene da Hugging Face per semplicità. Tuttavia, puoi ottimizzare il modello in base a un set di dati personalizzato. Puoi anche provare altri modelli disponibili in Hub del modello del viso che abbraccia. Forniamo anche un endpoint di inferenza asincrono che ospita questo modello, da cui è possibile ottenere previsioni.

Il gestore di inferenza dell'endpoint di inferenza asincrona prevede un articolo come carico utile di input. Il testo riassuntivo dell'articolo è l'output. L'output viene archiviato nel database per analizzare le tendenze o essere alimentato a valle per ulteriori analisi. Questa analisi a valle ricava approfondimenti sui dati che aiutano con la ricerca.

Dimostriamo come gli endpoint di inferenza asincrona consentono di avere concorrenza definita dall'utente e notifiche di completamento. Configuriamo il ridimensionamento automatico delle istanze dietro l'endpoint per ridurlo a zero quando il traffico diminuisce e aumentarlo quando la coda delle richieste si riempie.

Usiamo anche Amazon Cloud Watch parametri per monitorare la dimensione della coda, il tempo di elaborazione totale e le chiamate elaborate.

Nel diagramma seguente vengono mostrati i passaggi coinvolti durante l'esecuzione dell'inferenza utilizzando un endpoint di inferenza asincrona.

Il nostro pre-addestrato PEGASUS Il modello ML viene prima ospitato sull'endpoint di dimensionamento.
L'utente carica l'articolo da riepilogare in un bucket S3 di input.
L'endpoint di inferenza asincrona viene richiamato utilizzando un'API.
Una volta completata l'inferenza, il risultato viene salvato nel bucket S3 di output.
An Servizio di notifica semplice Amazon (Amazon SNS) viene inviata una notifica all'utente che lo informa dell'esito positivo o negativo dell'operazione.

Creare un endpoint di inferenza asincrono

Creiamo l'endpoint di inferenza asincrona simile a un endpoint ospitato in tempo reale. I passaggi includono la creazione di un modello SageMaker, seguita dalla configurazione dell'endpoint e dalla distribuzione dell'endpoint. La differenza tra i due tipi di endpoint è che la configurazione dell'endpoint di inferenza asincrona contiene un file AsyncInferenceConfig sezione. Qui specifichiamo il percorso di output S3 per i risultati della chiamata dell'endpoint e facoltativamente includiamo argomenti SNS per le notifiche di successo e fallimento. Specifichiamo inoltre il numero massimo di invocazioni simultanee per istanza come determinato dal cliente. Vedere il seguente codice:

AsyncInferenceConfig={ "OutputConfig": { "S3OutputPath": f"s3://{bucket}/{bucket_prefix}/output", # Optionally specify Amazon SNS topics for notifications "NotificationConfig": { "SuccessTopic": success_topic, "ErrorTopic": error_topic, } }, "ClientConfig": { "MaxConcurrentInvocationsPerInstance": 2 #increase this value up to throughput peak for ideal performance } }

Per dettagli sull'API per creare una configurazione endpoint per l'inferenza asincrona, vedere Creare un endpoint di inferenza asincrono.

Richiamare l'endpoint di inferenza asincrona

Lo screenshot seguente mostra un breve articolo che utilizziamo come carico utile di input:

Il codice seguente carica l'articolo come file input.json file su Amazon S3:

sm_session.upload_data( input_location, bucket=sm_session.default_bucket(), key_prefix=prefix, extra_args={"ContentType": "text/plain"})

Utilizziamo l'URI Amazon S3 per il file payload di input per richiamare l'endpoint. L'oggetto risposta contiene la posizione di output in Amazon S3 per recuperare i risultati dopo il completamento:

response = sm_runtime.invoke_endpoint_async(EndpointName=endpoint_name, InputLocation=input_1_s3_location)
output_location = response['OutputLocation']

Lo screenshot seguente mostra l'output di esempio dopo il riepilogo:

Per dettagli sull'API per richiamare un endpoint di inferenza asincrona, vedere Richiamare un endpoint di inferenza asincrona.

Accoda le richieste di chiamata con la concorrenza definita dall'utente

L'endpoint di inferenza asincrona accoda automaticamente le richieste di chiamata. Si tratta di una coda completamente gestita con varie metriche di monitoraggio e non richiede alcuna ulteriore configurazione. Utilizza il MaxConcurrentInvocationsPerInstance parametro nella configurazione dell'endpoint precedente per elaborare le nuove richieste dalla coda dopo il completamento delle richieste precedenti. MaxConcurrentInvocationsPerInstance è il numero massimo di richieste simultanee inviate dal client SageMaker al contenitore del modello. Se non viene fornito alcun valore, SageMaker sceglie un valore ottimale per te.

Istanze di ridimensionamento automatico all'interno dell'endpoint di inferenza asincrona

Impostiamo la politica di ridimensionamento automatico con una capacità minima pari a zero e una capacità massima di cinque istanze. A differenza degli endpoint ospitati in tempo reale, gli endpoint di inferenza asincrona supportano la riduzione delle istanze a zero impostando la capacità minima su zero. Noi usiamo il ApproximateBacklogSizePerInstance metrica per la configurazione della policy di dimensionamento con un backlog di coda target di cinque per istanza per un ulteriore dimensionamento. Impostiamo il periodo di raffreddamento per ScaleInCooldown a 120 secondi e il ScaleOutCooldown a 120 secondi. Il valore per ApproximateBacklogSizePerInstance viene scelto in base al traffico e alla tua sensibilità alla velocità di scalabilità. Quanto più velocemente si aumenta, tanto minori saranno i costi da sostenere, ma più è probabile che sarà necessario aumentarla nuovamente quando arrivano nuove richieste. Quanto più lentamente si aumenta, tanto maggiori saranno i costi da sostenere, ma è meno probabile che tu abbia arriva una richiesta quando sei sottodimensionato.

client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services resource_id='endpoint/' + endpoint_name + '/variant/' + 'variant1' # This is the format in which application autoscaling references the endpoint response = client.register_scalable_target(
ServiceNamespace='sagemaker', #
ResourceId=resource_id,
ScalableDimension='sagemaker:variant:DesiredInstanceCount',
MinCapacity=0,
MaxCapacity=5
) response = client.put_scaling_policy(
PolicyName='Invocations-ScalingPolicy',
ServiceNamespace='sagemaker', # The namespace of the AWS service that provides the resource.
ResourceId=resource_id, # Endpoint name
ScalableDimension='sagemaker:variant:DesiredInstanceCount', # SageMaker supports only Instance Count
PolicyType='TargetTrackingScaling', # 'StepScaling'|'TargetTrackingScaling'
TargetTrackingScalingPolicyConfiguration={ 'TargetValue': 5.0, # The target value for the metric. 'CustomizedMetricSpecification': { 'MetricName': 'ApproximateBacklogSizePerInstance', 'Namespace': 'AWS/SageMaker', 'Dimensions': [{'Name': 'EndpointName', 'Value': endpoint_name }], 'Statistic': 'Average',
}, 'ScaleInCooldown': 120, # ScaleInCooldown - The amount of time, in seconds, after a scale-in activity completes before another scale in activity can start. 'ScaleOutCooldown': 120 # ScaleOutCooldown - The amount of time, in seconds, after a scale-out activity completes before another scale out activity can start.
# 'DisableScaleIn': True|False - indicates whether scale in by the target tracking policy is disabled.
# If the value is true, scale-in is disabled and the target tracking policy won't remove capacity from the scalable resource.
}
)

Per dettagli sull'API per ridimensionare automaticamente un endpoint di inferenza asincrona, vedere Scalabilità automatica di un endpoint di inferenza asincrona.

Configurare le notifiche dall'endpoint di inferenza asincrona

Creiamo due argomenti SNS separati per le notifiche di successo ed errore per ogni risultato di chiamata dell'endpoint:

sns_client = boto3.client('sns')
response = sns_client.create_topic(Name="Async-Demo-ErrorTopic2")
error_topic = response['TopicArn']
response = sns_client.create_topic(Name="Async-Demo-SuccessTopic2")
success_topic = response['TopicArn']

Altre opzioni per le notifiche includono il controllo periodico dell'output del bucket S3 o l'utilizzo delle notifiche del bucket S3 per inizializzare un file AWS Lambda funzione sul caricamento del file. Le notifiche SNS sono incluse nella sezione di configurazione dell'endpoint come descritto in precedenza.

Per dettagli su come impostare le notifiche da un endpoint di inferenza asincrona, vedere Controlla i risultati della previsione.

Monitorare l'endpoint di inferenza asincrona

Monitoriamo l'endpoint di inferenza asincrona con parametri CloudWatch aggiuntivi integrati specifici per l'inferenza asincrona. Ad esempio, monitoriamo la lunghezza della coda in ogni istanza con ApproximateBacklogSizePerInstance e la lunghezza totale della coda con ApproximateBacklogSize.

Per un elenco completo delle metriche, fare riferimento a Monitoraggio degli endpoint di inferenza asincrona.

Possiamo ottimizzare la configurazione dell'endpoint per ottenere l'istanza più conveniente con prestazioni elevate. Ad esempio, possiamo utilizzare un'istanza con Amazon Elastic Inference o AWS Inferentia. Possiamo anche aumentare gradualmente il livello di concorrenza fino al picco di throughput, regolando al tempo stesso altri parametri del server modello e del contenitore.

Grafici CloudWatch

Abbiamo simulato un traffico di 10,000 richieste di inferenza che fluiscono in un periodo verso l'endpoint di inferenza asincrona abilitato con la policy di ridimensionamento automatico descritta nella sezione precedente.

Lo screenshot seguente mostra i parametri delle istanze prima che le richieste iniziassero ad arrivare. Iniziamo con un endpoint live con zero istanze in esecuzione:

Il grafico seguente mostra come BacklogSize ed BacklogSizePerInstance i parametri cambiano quando viene avviato il dimensionamento automatico e il carico sull'endpoint viene condiviso da più istanze di cui è stato effettuato il provisioning come parte del processo di dimensionamento automatico.

Come mostrato nello screenshot seguente, il numero di istanze è aumentato man mano che il conteggio delle inferenze aumentava:

Lo screenshot seguente mostra come il ridimensionamento riporta l'endpoint allo stato iniziale di zero istanze in esecuzione:

ripulire

Una volta completate tutte le richieste, possiamo eliminare l'endpoint in modo simile all'eliminazione degli endpoint ospitati in tempo reale. Tieni presente che se impostiamo la capacità minima degli endpoint di inferenza asincrona su zero, non verranno addebitati costi per l'istanza dopo la riduzione a zero.

Se hai abilitato la scalabilità automatica per il tuo endpoint, assicurati di annullare la registrazione dell'endpoint come destinazione scalabile prima di eliminarlo. Per fare ciò, esegui il seguente codice:

response = client.deregister_scalable_target(ServiceNamespace='sagemaker',ResourceId='resource_id',ScalableDimension='sagemaker:variant:DesiredInstanceCount')

Ricorda di eliminare l'endpoint dopo l'uso poiché ti verranno addebitate le istanze utilizzate in questa demo.

sm_client.delete_endpoint(EndpointName=endpoint_name)

È inoltre necessario eliminare gli oggetti S3 e gli argomenti SNS. Se hai creato altre risorse AWS da utilizzare e agire sulle notifiche SNS, potresti voler eliminare anche quelle.

Conclusione

In questo post, abbiamo dimostrato come utilizzare la nuova funzionalità di inferenza asincrona di SageMaker per elaborare un tipico carico utile di input di grandi dimensioni che fa parte di un'attività di riepilogo. Per l'inferenza, abbiamo utilizzato un modello di Hugging Face e lo abbiamo distribuito sull'endpoint di inferenza asincrona. Abbiamo spiegato le sfide comuni del traffico burst, dei tempi elevati di elaborazione dei modelli e dei grandi carichi utili coinvolti nell'analisi della ricerca. La capacità intrinseca dell'endpoint di inferenza asincrona di gestire code interne, limiti di concorrenza predefiniti, configurare notifiche di risposta e ridimensionarsi automaticamente fino a zero ci ha aiutato ad affrontare queste sfide. Il codice completo per questo esempio è disponibile su GitHub.

Per iniziare con l'inferenza asincrona di SageMaker, dai un'occhiata Inferenza asincrona.

Informazioni sugli autori

Dinesh Kumar Subramani è un Senior Solutions Architect con il team UKIR SMB, con sede a Edimburgo, in Scozia. È specializzato in intelligenza artificiale e machine learning. A Dinesh piace lavorare con i clienti di tutti i settori per aiutarli a risolvere i loro problemi con i servizi AWS. Al di fuori del lavoro, ama passare il tempo con la sua famiglia, giocare a scacchi e ascoltare musica di tutti i generi.

Raghu Ramesha è un ML Solutions Architect presso il team di assistenza Amazon SageMaker. Il suo obiettivo è aiutare i clienti a creare, distribuire e migrare carichi di lavoro di produzione ML su SageMaker su larga scala. È specializzato in ambiti di machine learning, intelligenza artificiale e visione artificiale e ha conseguito un master in informatica presso l'UT di Dallas. Nel tempo libero gli piace viaggiare e fotografare.