Esegui e ottimizza l'inferenza multimodello con gli endpoint multimodello Amazon SageMaker

Amazon Sage Maker multi-model endpoint (MME) consente di distribuire e ospitare in modo conveniente più modelli in un singolo endpoint e quindi ridimensionare orizzontalmente l'endpoint per ottenere la scalabilità. Come illustrato nella figura seguente, questa è una tecnica efficace per implementare la multi-tenancy di modelli all'interno dell'infrastruttura di machine learning (ML). Abbiamo visto aziende di software come servizio (SaaS) utilizzare questa funzionalità per applicare l'iperpersonalizzazione nei loro modelli ML ottenendo costi inferiori.

Per una panoramica di alto livello su come funziona l'MME, guarda il video del Summit AWS Ridimensionare il ML al livello successivo: ospitare migliaia di modelli su SageMaker. Per ulteriori informazioni sui casi d'uso iperpersonalizzati e multi-tenant abilitati da MME, fare riferimento a Come ridimensionare l'inferenza di machine learning per casi d'uso SaaS multi-tenant.

Nel resto di questo post, approfondiremo l'architettura tecnica di SageMaker MME e condividiamo le migliori pratiche per ottimizzare i tuoi endpoint multi-modello.

Casi d'uso più adatti per MME

Gli endpoint multimodello SageMaker sono adatti per ospitare un gran numero di modelli che puoi servire tramite un container di servizio condiviso e non è necessario accedere a tutti i modelli contemporaneamente. A seconda delle dimensioni della memoria dell'istanza dell'endpoint, è possibile che un modello venga occasionalmente scaricato dalla memoria a favore del caricamento di un nuovo modello per massimizzare l'uso efficiente della memoria, pertanto l'applicazione deve essere tollerante ai picchi di latenza occasionali sui modelli scaricati.

MME è progettato anche per il co-hosting di modelli che utilizzano lo stesso framework ML perché utilizzano il contenitore condiviso per caricare più modelli. Pertanto, se hai un mix di framework ML nel tuo parco modelli (come PyTorch e TensorFlow), gli endpoint dedicati SageMaker o l'hosting multi-container sono una scelta migliore.

Infine, MME è adatto per applicazioni che possono tollerare una penalità di latenza di avvio a freddo occasionale, perché i modelli vengono caricati alla prima chiamata e i modelli utilizzati di rado possono essere scaricati dalla memoria a favore del caricamento di nuovi modelli. Pertanto, se si dispone di una combinazione di modelli a cui si accede frequentemente e raramente, un endpoint multimodello può servire in modo efficiente questo traffico con meno risorse e maggiori risparmi sui costi.

Abbiamo anche visto alcuni scenari in cui i clienti implementano un cluster MME con una capacità di memoria aggregata sufficiente per adattarsi a tutti i loro modelli, evitando così del tutto gli offload dei modelli ma ottenendo comunque risparmi sui costi grazie all'infrastruttura di inferenza condivisa.

Contenitori da portata modello

Quando utilizzi SageMaker Inference Toolkit o un modello di SageMaker che serve un container compatibile con MME, il tuo container ha il Server multimodello (processo JVM) in esecuzione. Il modo più semplice per incorporare Multi Model Server (MMS) nel tuo contenitore di servizio modello consiste nell'usarlo Contenitori di servizio modello SageMaker compatibile con MME (cerca quelli con Tipo di lavoro=inferenza e CPU/GPU=CPU). MMS è uno strumento open source facile da usare per servire modelli di deep learning. Fornisce un'API REST con un server Web per servire e gestire più modelli su un singolo host. Tuttavia, non è obbligatorio utilizzare MMS; potresti implementare il tuo server modello purché implementi il ​​file API richieste da MME.

Se utilizzate come parte della piattaforma MME, tutte le chiamate API di previsione, caricamento e scaricamento all'MMS o al proprio server modello vengono convogliate tramite il controller del piano dati MME. Le chiamate API dal controller del piano dati vengono effettuate sull'host locale solo per impedire l'accesso non autorizzato dall'esterno dell'istanza. Uno dei principali vantaggi dell'MMS è che consente un'interfaccia standardizzata per il caricamento, lo scaricamento e il richiamo di modelli con compatibilità su un'ampia gamma di framework di deep learning.

Configurazione avanzata di MMS

Se scegli di utilizzare MMS per la pubblicazione di modelli, considera le seguenti configurazioni avanzate per ottimizzare la scalabilità e il throughput delle tue istanze MME.

Aumenta il parallelismo di inferenza per modello

MMS crea uno o più processi di lavoro Python per modello in base al valore di default_lavoratori_per_modello parametro di configurazione. Questi lavoratori Python gestiscono ogni singola richiesta di inferenza eseguendo qualsiasi funzione di pre-elaborazione, previsione e post-elaborazione fornita dall'utente. Per ulteriori informazioni, vedere il gestore del servizio personalizzato Repository GitHub.

Avere più di un lavoratore modello aumenta il parallelismo delle previsioni che possono essere servite da un determinato modello. Tuttavia, quando un numero elevato di modelli è ospitato su un'istanza con un numero elevato di CPU, è necessario eseguire un test di carico dell'MME per trovare il valore ottimale per default_workers_per_model per prevenire qualsiasi esaurimento della memoria o delle risorse della CPU.

Design per i picchi di traffico

Ciascun processo MMS all'interno di un'istanza dell'endpoint dispone di una coda di richiesta che può essere configurata con dimensione_coda_lavoro parametro (il valore predefinito è 100). Ciò determina il numero di richieste che MMS metterà in coda quando tutti i processi di lavoro sono occupati. Utilizza questo parametro per ottimizzare la reattività delle istanze dell'endpoint dopo aver deciso il numero ottimale di lavoratori per modello.

In un rapporto ottimale lavoratore per modello, il valore predefinito di 100 dovrebbe essere sufficiente per la maggior parte dei casi. Tuttavia, per quei casi in cui il traffico della richiesta verso l'endpoint ha picchi insoliti, è possibile ridurre le dimensioni della coda se si desidera che l'endpoint non riesca a passare rapidamente il controllo all'applicazione o aumentare le dimensioni della coda se si desidera che l'endpoint assorba il picco .

Massimizza le risorse di memoria per istanza

Quando si utilizzano più processi di lavoro per modello, per impostazione predefinita ogni processo di lavoro carica la propria copia del modello. Ciò può ridurre la memoria dell'istanza disponibile per altri modelli. È possibile ottimizzare l'utilizzo della memoria condividendo un singolo modello tra i processi di lavoro impostando il parametro di configurazione preload_model=true. Qui stai scambiando un parallelismo di inferenza ridotto (a causa di una singola istanza del modello) con una maggiore efficienza della memoria. Questa impostazione insieme a più processi di lavoro può essere una buona scelta per i casi d'uso in cui la latenza del modello è bassa ma hai una preelaborazione e una postelaborazione più pesanti (eseguite dai processi di lavoro) per richiesta di inferenza.

Impostare i valori per le configurazioni avanzate MMS

MMS utilizza un file config.properties per memorizzare le configurazioni. MMS utilizza il seguente ordine per individuare questo file config.properties:

1. Se l' MMS_CONFIG_FILE è impostata la variabile di ambiente, MMS carica la configurazione dalla variabile di ambiente.
2. Se l' --mms-config parametro viene passato a MMS, carica la configurazione dal parametro.
3. Se c'è un config.properties nella cartella corrente in cui l'utente avvia l'MMS, carica il file config.properties file dalla directory di lavoro corrente.

Se non viene specificato nessuno dei precedenti, MMS carica la configurazione incorporata con i valori predefiniti.

Quello che segue è un esempio della riga di comando dell'avvio di MMS con un file di configurazione esplicito:

multi-model-server --start --mms-config /home/mms/config.properties

Metriche chiave per monitorare le prestazioni dell'endpoint

Le metriche chiave che possono aiutarti a ottimizzare il tuo MME sono in genere correlate all'utilizzo della CPU e della memoria e alla latenza di inferenza. Le metriche a livello di istanza vengono emesse da MMS, mentre le metriche di latenza provengono dall'MME. In questa sezione, discutiamo le metriche tipiche che puoi utilizzare per comprendere e ottimizzare il tuo MME.

Metriche a livello di istanza dell'endpoint (metriche MMS)

Dal elenco delle metriche MMS, CPUUtilization e MemoryUtilization possono aiutarti a valutare se la tua istanza o il cluster MME hanno o meno le dimensioni corrette. Se entrambe le metriche hanno percentuali comprese tra il 50 e l'80%, il tuo MME ha le dimensioni giuste.

In genere, un utilizzo basso della CPU e un utilizzo elevato della memoria sono un'indicazione di un cluster MME con provisioning eccessivo perché indica che i modelli richiamati di rado non vengono scaricati. Ciò potrebbe essere dovuto a un numero superiore a quello ottimale di istanze di endpoint di cui è stato eseguito il provisioning per l'MME e pertanto è disponibile una memoria aggregata superiore a quella ottimale per i modelli a cui si accede raramente per rimanere in memoria. Al contrario, un utilizzo vicino al 100% di queste metriche significa che il provisioning del cluster è insufficiente, quindi è necessario modificare la policy di ridimensionamento automatico del cluster.

Metriche a livello di piattaforma (metriche MME)

Dal elenco completo delle metriche MME, una metrica chiave che può aiutarti a comprendere la latenza della tua richiesta di inferenza è ModelCacheHit. Questa metrica mostra il rapporto medio delle richieste di chiamata per le quali il modello era già stato caricato in memoria. Se questo rapporto è basso, indica che il tuo cluster MME ha un provisioning insufficiente perché probabilmente non c'è capacità di memoria aggregata sufficiente nel cluster MME per il numero di chiamate di modelli univoci, causando quindi lo scaricamento frequente dei modelli dalla memoria.

Lezioni dal campo e strategie per ottimizzare l'MME

Abbiamo visto i seguenti consigli da alcuni degli usi su larga scala di MME in un certo numero di clienti.

Il ridimensionamento orizzontale con istanze più piccole è migliore del ridimensionamento verticale con istanze più grandi

È possibile che si verifichi una limitazione delle chiamate di modello durante l'esecuzione di richieste elevate al secondo (RPS) su un numero inferiore di istanze dell'endpoint. Esistono limiti interni al numero di chiamate al secondo (caricamenti e scaricamenti che possono verificarsi contemporaneamente su un'istanza), quindi è sempre meglio avere un numero maggiore di istanze più piccole. L'esecuzione di un numero maggiore di istanze più piccole significa una capacità aggregata totale maggiore di questi limiti per l'endpoint.

Un altro vantaggio del ridimensionamento orizzontale con istanze più piccole è che si riduce il rischio di esaurire la CPU dell'istanza e le risorse di memoria durante l'esecuzione di MMS con livelli di parallelismo più elevati, insieme a un numero maggiore di modelli in memoria (come descritto in precedenza in questo post).

Evitare il thrashing è una responsabilità condivisa

thrashing in MME è quando i modelli vengono frequentemente scaricati dalla memoria e ricaricati a causa di memoria insufficiente, sia in una singola istanza che in aggregazione nel cluster.

Dal punto di vista dell'utilizzo, dovresti dimensionare correttamente le singole istanze dell'endpoint e dimensionare correttamente la dimensione complessiva del cluster MME per garantire che sia disponibile una capacità di memoria sufficiente per istanza e anche in aggregato per il cluster per il tuo caso d'uso. Anche la flotta di router della piattaforma MME massimizzerà la cache hit.

Non essere aggressivo con il cestino che impacchetta troppi modelli su meno istanze di memoria più grandi

La memoria non è l'unica risorsa di cui essere a conoscenza nell'istanza. Altre risorse come la CPU possono essere un fattore vincolante, come mostrato nei seguenti risultati del test di carico. In alcuni altri casi, abbiamo anche osservato che altre risorse del kernel come gli ID di processo si esauriscono in un'istanza, a causa di una combinazione di troppi modelli caricati e del framework ML sottostante (come TensorFlow) che genera thread per modello che erano multipli di quelli disponibili vCPU.

Il seguente test delle prestazioni mostra un esempio di vincolo della CPU che influisce sulla latenza del modello. In questo test, un endpoint a istanza singola con un'istanza di grandi dimensioni, pur disponendo di memoria più che sufficiente per mantenere tutti e quattro i modelli in memoria, ha prodotto latenze del modello relativamente peggiori sotto carico rispetto a un endpoint con quattro istanze più piccole.

latenza del modello di endpoint a istanza singola

CPU dell'endpoint a istanza singola e utilizzo della memoria

latenza del modello di endpoint a quattro istanze

CPU dell'endpoint a quattro istanze e utilizzo della memoria

Per ottenere prestazioni ed efficienza in termini di costi, dimensiona correttamente il tuo cluster MME con un numero maggiore di istanze più piccole che complessivamente offrono la memoria e la capacità della CPU ottimali, pur essendo relativamente alla pari con i costi con un numero inferiore di istanze di memoria più grandi.

Modello mentale per l'ottimizzazione dell'MME

Ci sono quattro parametri chiave che dovresti sempre considerare quando ridimensioni correttamente il tuo MME:

• Il numero e le dimensioni dei modelli
• Il numero di modelli univoci richiamati in un determinato momento
• Il tipo e la dimensione dell'istanza
• Il conteggio delle istanze dietro l'endpoint

Inizia con i primi due punti, perché informano il terzo e il quarto. Ad esempio, se non ci sono abbastanza istanze dietro l'endpoint per il numero o la dimensione dei modelli univoci che hai, la memoria aggregata per l'endpoint sarà bassa e vedrai un tasso di hit della cache inferiore e un thrashing a livello di endpoint perché l'MME caricherà e scaricherà frequentemente i modelli dentro e fuori la memoria.

Allo stesso modo, se le chiamate per i modelli univoci sono superiori alla memoria aggregata di tutte le istanze dietro l'endpoint, vedrai un hit di cache inferiore. Ciò può verificarsi anche se la dimensione delle istanze (in particolare la capacità di memoria) è troppo piccola.

Anche il ridimensionamento verticale con istanze di memoria molto grandi potrebbe causare problemi perché, sebbene i modelli possano adattarsi alla memoria, altre risorse come i processi CPU e kernel e i limiti dei thread potrebbero essere esauriti. Carica il ridimensionamento orizzontale di prova in pre-produzione per ottenere il numero e le dimensioni ottimali di istanze per il tuo MME.

Sommario

In questo post, hai una comprensione più profonda della piattaforma MME. Hai appreso per quali casi d'uso tecnici MME è adatto e hai esaminato l'architettura della piattaforma MME. Hai acquisito una comprensione più profonda del ruolo di ciascun componente all'interno dell'architettura MME e di quali componenti puoi influenzare direttamente le prestazioni. Infine, hai esaminato più in dettaglio i parametri di configurazione che puoi regolare per ottimizzare l'MME per il tuo caso d'uso e le metriche che dovresti monitorare per mantenere prestazioni ottimali.

Per iniziare con MME, rivedere Endpoint multimodello Amazon SageMaker che utilizzano XGBoost ed Ospita più modelli in un contenitore dietro un endpoint.

L'autore

Syed Jaffry è un Principal Solutions Architect con AWS. Lavora con una vasta gamma di aziende di organizzazioni di medie dimensioni, grandi imprese, servizi finanziari e ISV per aiutarle a creare e gestire applicazioni AI/ML scalabili e convenienti nel cloud.

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.