Come ridimensionare l'inferenza del machine learning per casi d'uso SaaS multi-tenant

Ripubblicato da Platone

Seguaci: 0

Questo post è stato scritto in collaborazione con Sowmya Manusani, Sr. Staff Machine Learning Engineer presso Zendesk

Zendesk è un'azienda SaaS che crea software di supporto, vendita e coinvolgimento dei clienti per tutti, basandosi sulla semplicità. Prospera facendo in modo che oltre 170,000 aziende in tutto il mondo servano le loro centinaia di milioni di clienti in modo efficiente. Il team di Machine Learning di Zendcaesk è responsabile del miglioramento dei team di Customer Experience per ottenere il meglio. Combinando la potenza dei dati e delle persone, Zendesk offre prodotti intelligenti che rendono i clienti più produttivi automatizzando il lavoro manuale.

Zendesk crea prodotti ML dal 2015, incluso Rispondi Bot, Previsione di soddisfazione, Spunti di contenuto, Macro suggerite, e tanti altri. Negli ultimi anni, con la crescita del deep learning, in particolare nella NLP, hanno visto molte opportunità per automatizzare i flussi di lavoro e assistere gli agenti nel supportare i propri clienti con le soluzioni Zendesk. Zendesk attualmente utilizza TensorFlow e PyTorch per creare modelli di deep learning.

Clienti come Zendesk hanno creato attività SaaS (Software as a Service) di successo e su larga scala su Amazon Web Services (AWS). Un fattore chiave per un modello di business SaaS di successo è la capacità di applicare la multi-tenancy nell'applicazione e nell'infrastruttura. Ciò consente efficienze in termini di costi ed operazioni poiché l'applicazione deve essere creata una sola volta, ma può essere utilizzata più volte e l'infrastruttura può essere condivisa. Vediamo molti clienti creare sistemi multi-tenant sicuri, convenienti e multi-tenant su AWS a tutti i livelli dello stack, dall'elaborazione, allo storage, al database, al networking, e ora vediamo clienti che devono applicarlo all'apprendimento automatico (ML ).

Fare il difficile compromesso tra riutilizzo del modello e iper-personalizzazione

La multi-tenancy per le aziende SaaS in genere significa che una singola applicazione viene riutilizzata tra molti utenti (clienti SaaS). Ciò crea efficienze in termini di costi e riduce i costi operativi. Tuttavia, i modelli di apprendimento automatico a volte devono essere personalizzati con un alto grado di specificità (iperpersonalizzati) per fare previsioni accurate. Ciò significa che il paradigma SaaS "crea una volta, usa molte volte" non può sempre essere applicato al ML se i modelli hanno specificità. Prendi ad esempio il caso d'uso delle piattaforme di assistenza clienti. La lingua che gli utenti includono in un ticket di supporto varia a seconda che si tratti di un problema di condivisione della corsa ("il viaggio ha richiesto troppo tempo") o di un problema di acquisto di vestiti ("scolorimento durante il lavaggio"). In questo caso d'uso, il miglioramento dell'accuratezza della previsione della migliore azione correttiva può richiedere la formazione di un modello di elaborazione del linguaggio naturale (NLP) su un set di dati specifico per un dominio aziendale o un settore verticale. Zendesk affronta esattamente questa sfida quando cerca di sfruttare il ML nelle proprie soluzioni. Avevano bisogno di creare migliaia di modelli ML altamente personalizzati, ciascuno su misura per un cliente specifico. Per risolvere questa sfida di distribuire migliaia di modelli a costi contenuti, Zendesk si è rivolta ad Amazon SageMaker.

In questo post, mostriamo come utilizzare alcune delle nuove funzionalità di Amazon Sage Maker, un servizio di machine learning completamente gestito, per creare una capacità di inferenza ML multi-tenant. Condividiamo anche un esempio del mondo reale di come Zendesk abbia ottenuto con successo lo stesso risultato implementando una via di mezzo tra la capacità di supportare l'iperpersonalizzazione nei propri modelli ML e l'uso condiviso ed economico dell'infrastruttura utilizzando gli endpoint multimodello SageMaker ( MME).

Endpoint multimodello SageMaker

Gli endpoint multimodello SageMaker consentono di distribuire più modelli dietro un singolo endpoint di inferenza che può contenere una o più istanze. Ogni istanza è progettata per caricare e servire più modelli fino alla sua capacità di memoria e CPU. Con questa architettura, un'azienda SaaS può abbattere il costo in aumento lineare dell'hosting di più modelli e ottenere il riutilizzo dell'infrastruttura coerente con il modello multi-tenancy applicato altrove nello stack dell'applicazione.

Il diagramma seguente illustra l'architettura di un endpoint multimodello SageMaker.

L'endpoint multimodello SageMaker carica dinamicamente i modelli da Servizio di archiviazione semplice Amazon (Amazon S3) quando viene richiamato, invece di scaricare tutti i modelli alla prima creazione dell'endpoint. Di conseguenza, una chiamata iniziale a un modello potrebbe vedere una latenza di inferenza maggiore rispetto alle inferenze successive, che vengono completate con una latenza bassa. Se il modello è già caricato nel contenitore quando viene richiamato, il passaggio di download viene ignorato e il modello restituisce le inferenze con bassa latenza. Ad esempio, supponi di avere un modello che viene utilizzato solo poche volte al giorno. Viene caricato automaticamente su richiesta, mentre i modelli a cui si accede di frequente vengono mantenuti in memoria e richiamati con una latenza costantemente bassa.

Diamo un'occhiata più da vicino a come Zendesk ha utilizzato SageMaker MME per ottenere un'implementazione ML conveniente e iperscalabile con la loro funzione ML Macro consigliate.

Perché Zendesk ha creato modelli iper-personalizzati

I clienti di Zendesk sono diffusi a livello globale in diversi settori verticali con diverse semantiche dei ticket di supporto. Pertanto, per servire al meglio i propri clienti, spesso devono creare modelli personalizzati addestrati sui dati dei ticket di supporto specifici del cliente per identificare correttamente intenti, macro e altro.

Nell'ottobre 2021 hanno rilasciato una nuova funzionalità di ML NLP, Suggested Macros, che consiglia macro (azioni predefinite) in base a migliaia di previsioni del modello specifiche del cliente. Il team ML di Zendesk ha creato un modello di classificazione NLP basato su TensorFlow addestrato dalla cronologia precedente del contenuto del biglietto e delle macro per cliente. Con questi modelli disponibili, si consiglia una previsione macro ogni volta che un agente visualizza il ticket (come mostrato nella schermata seguente), che aiuta l'agente a servire i clienti rapidamente. Poiché le macro sono specifiche per i clienti, Zendesk ha bisogno di modelli specifici per i clienti per fornire previsioni accurate.

Sotto il cofano delle Macro suggerite di Zendesk

I modelli Macro suggeriti sono reti neurali basate su NLP che hanno una dimensione di circa 7-15 MB. La sfida principale è mettere in produzione migliaia di questi modelli con soluzioni convenienti, affidabili e scalabili.

Ogni modello ha modelli di traffico diversi, con un minimo di due richieste al secondo e un picco di centinaia di richieste al secondo, che servono milioni di previsioni al giorno con una latenza del modello di circa 100 millisecondi quando il modello è disponibile in memoria. Gli endpoint SageMaker vengono distribuiti in più regioni AWS, servendo migliaia di richieste al minuto per endpoint.

Grazie alla sua capacità di ospitare più modelli su un singolo endpoint, SageMaker ha aiutato Zendesk a ridurre le spese generali di implementazione e creare una soluzione conveniente rispetto all'implementazione di un singolo modello di endpoint per cliente. Il compromesso qui è un minor controllo sulla gestione per modello; tuttavia, questa è un'area in cui Zendesk sta collaborando con AWS per migliorare gli endpoint multimodello.

Una delle funzionalità multimodello di SageMaker è il caricamento lento dei modelli, ovvero i modelli vengono caricati in memoria quando vengono richiamati per la prima volta. Questo serve per ottimizzare l'utilizzo della memoria; tuttavia, provoca picchi di tempo di risposta al primo carico, che possono essere visti come un problema di avvio a freddo. Per le macro suggerite, questa è stata una sfida; tuttavia, Zendesk ha superato questo problema implementando una funzionalità di precaricamento oltre al provisioning dell'endpoint SageMaker per caricare i modelli in memoria prima di servire il traffico di produzione. In secondo luogo, MME scarica dalla memoria i modelli utilizzati di rado, quindi per ottenere una bassa latenza costante su tutti i modelli ed evitare che i "vicini rumorosi" abbiano un impatto su altri modelli meno attivi, Zendesk sta collaborando con AWS per aggiungere nuove funzionalità, discusse più avanti nel post, per abilitare gestione più esplicita per modello. Inoltre, come soluzione provvisoria, Zendesk ha dimensionato correttamente la flotta MME per ridurre al minimo lo scarico di troppi modelli. In questo modo, Zendesk è in grado di fornire previsioni a tutti i propri clienti con una bassa latenza, circa 100 millisecondi, e ottenere comunque un risparmio sui costi del 90% rispetto agli endpoint dedicati.

Ridimensionando correttamente l'MME, Zendesk ha osservato durante i test di carico che avere un numero maggiore di istanze più piccole (bias sul ridimensionamento orizzontale) dietro MME era una scelta migliore rispetto a un minor numero di istanze di memoria più grandi (ridimensionamento verticale). Zendesk ha osservato che il raggruppamento di troppi modelli (oltre 500 modelli TensorFlow nel loro caso) su una singola istanza di memoria di grandi dimensioni non funzionava bene perché la memoria non è l'unica risorsa su un'istanza che può essere un collo di bottiglia. Più specificamente, hanno osservato che TensorFlow ha generato più thread (3 x vCPU di istanza totali) per modello, quindi il caricamento di oltre 500 modelli su una singola istanza ha causato la violazione dei limiti del livello del kernel sul numero massimo di thread che potevano essere generati su un'istanza. Un altro problema con l'utilizzo di istanze di dimensioni inferiori e maggiori si è verificato quando Zendesk ha riscontrato una limitazione (come meccanismo di sicurezza) in alcune istanze dietro MME perché la frequenza di chiamata univoca del modello al secondo superava la frequenza Server multimodello (MMS) su una singola istanza potrebbe essere gestito in sicurezza senza oscurare l'istanza. Questo è stato un altro problema che è stato risolto con l'uso di istanze sempre più piccole.

Dal punto di vista dell'osservabilità, che è una componente cruciale di qualsiasi applicazione di produzione, Amazon Cloud Watch metriche come chiamate, CPU, utilizzo della memoria e metriche specifiche per più modelli come modelli caricati in memoria, tempo di caricamento del modello, tempo di attesa del caricamento del modello e hit della cache del modello sono informative. In particolare, la ripartizione della latenza del modello ha aiutato Zendesk a comprendere il problema dell'avvio a freddo e il suo impatto.

Sotto il cofano del ridimensionamento automatico MME

Dietro ogni endpoint multimodello, ci sono istanze di hosting del modello, come illustrato nel diagramma seguente. Queste istanze caricano ed eliminano più modelli da e verso la memoria in base ai modelli di traffico verso i modelli.

SageMaker continua a instradare le richieste di inferenza per un modello all'istanza in cui il modello è già caricato in modo tale che le richieste vengano servite dalla copia del modello memorizzata nella cache (vedere il diagramma seguente, che mostra il percorso della richiesta per la prima richiesta di previsione rispetto alla richiesta di previsione memorizzata nella cache sentiero). Tuttavia, se il modello riceve molte richieste di chiamata e sono presenti istanze aggiuntive per l'endpoint multimodello, SageMaker instrada alcune richieste a un'altra istanza per soddisfare l'aumento. Per sfruttare il ridimensionamento automatico del modello in SageMaker, assicurati di averlo fatto impostazione del ridimensionamento automatico dell'istanza per fornire capacità di istanza aggiuntiva. Configura la tua policy di dimensionamento a livello di endpoint con parametri personalizzati o chiamate al minuto (consigliato) per aggiungere più istanze al parco di endpoint.

Casi d'uso più adatti per MME

Gli endpoint multimodello SageMaker sono adatti per ospitare un gran numero di modelli simili che puoi servire tramite un container di servizio condiviso e non è necessario accedere a tutti i modelli contemporaneamente. MME è più adatto per modelli simili per dimensioni e latenze di chiamata. Sono accettabili alcune variazioni nelle dimensioni del modello; ad esempio, i modelli di Zendesk vanno da 10 a 50 Mb, il che funziona bene, ma le variazioni di dimensioni di un fattore 10, 50 o 100 volte maggiori non sono adatte. Modelli più grandi possono causare un numero maggiore di caricamenti e scaricamenti di modelli più piccoli per ospitare spazio di memoria sufficiente, il che può comportare una maggiore latenza sull'endpoint. Le differenze nelle caratteristiche prestazionali dei modelli più grandi potrebbero anche consumare risorse come la CPU in modo non uniforme, il che potrebbe influire su altri modelli sull'istanza.

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 un'occasionale penalizzazione della latenza di avvio a freddo perché i modelli utilizzati di rado possono essere scaricati a favore dei modelli invocati di frequente. Se si dispone di una lunga coda di modelli a cui si accede raramente, un endpoint multimodello può servire in modo efficiente questo traffico e consentire notevoli risparmi sui costi.

Sommario

In questo post, hai appreso come SaaS e multi-tenancy sono correlati al ML e in che modo gli endpoint multi-modello SageMaker consentono multi-tenancy ed efficienza in termini di costi per l'inferenza ML. Hai appreso del caso d'uso multi-tenant di Zendesk dei modelli ML per cliente e di come hanno ospitato migliaia di modelli ML in SageMaker MME per la loro funzione Macro suggerite e hai ottenuto un risparmio del 90% sui costi di inferenza rispetto agli endpoint dedicati. I casi d'uso di iperpersonalizzazione possono richiedere migliaia di modelli ML e MME è una scelta conveniente per questo caso d'uso. Continueremo ad apportare miglioramenti in MME per consentirti di ospitare modelli con bassa latenza e con controlli più granulari per ogni modello personalizzato. Per iniziare con MME, vedere Ospita più modelli in un contenitore dietro un endpoint.

Informazioni sugli autori

Syed Jaffry è Sr. Solutions Architect con AWS. Lavora con una vasta gamma di aziende, dalle organizzazioni di medie dimensioni alle grandi imprese, dai servizi finanziari agli ISV, aiutandole a creare e gestire applicazioni sicure, resilienti, scalabili e ad alte prestazioni nel cloud.

Sowmya Manusani è un Senior Staff Machine Learning Engineer presso Zendesk. Lavora alla produzione di funzionalità di Machine Learning basate sulla NLP incentrate sul miglioramento della produttività degli agenti per migliaia di clienti Zendesk Enterprise. Ha esperienza nella creazione di pipeline di formazione automatizzate per migliaia di modelli personalizzati e nel servirli utilizzando applicazioni sicure, resilienti, scalabili e ad alte prestazioni. Nel tempo libero le piace risolvere enigmi e provare a dipingere.

Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti e rendere più accessibile l'apprendimento automatico. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.

Deepti Ragha è un ingegnere di sviluppo software nel team di Amazon SageMaker. Il suo attuale lavoro si concentra sulla creazione di funzionalità per ospitare modelli di machine learning in modo efficiente. Nel tempo libero le piace viaggiare, fare escursioni e coltivare piante.