Come Snorkel AI ha ottenuto risparmi sui costi di oltre il 40% dimensionando i carichi di lavoro di machine learning con Amazon EKS

Le startup di machine learning (ML) sono spesso utenti assidui di computer, perché addestrano modelli di grandi dimensioni utilizzando GPU di fascia alta e li implementano su larga scala per l'inferenza. Startup AWS collabora con le startup dall'inizio all'IPO e ha aiutato migliaia di fondatori e innovatori dell'intelligenza artificiale (IA) a creare le proprie attività su Amazon Elastic Kubernetes Service (Amazon EKS). Amazon EKS è una scelta popolare per creare e ospitare modelli di ML perché offre la flessibilità di Kubernetes con la sicurezza e la resilienza di un servizio gestito AWS ottimizzato per la creazione di carichi di lavoro containerizzati ad alta disponibilità.

Snorkel AI è una di queste aziende che trae vantaggio da Amazon EKS. Snorkel AI consente alle aziende Fortune 500, alle agenzie federali e agli innovatori di intelligenza artificiale di creare, adattare e distillare modelli di fondazione (FM) e modelli linguistici di grandi dimensioni (LLM) per funzionare con grande precisione su set di dati specifici dei domini. Con l'approccio incentrato sui dati di Snorkel per lo sviluppo dell'intelligenza artificiale, le organizzazioni hanno creato servizi di intelligenza artificiale pronti per la produzione per i casi d'uso quali l'elaborazione dei reclami assicurativi, la distribuzione finanziaria, l'analisi delle sperimentazioni cliniche e l'accelerazione della gestione proattiva dei pozzi per la perforazione offshore.

Negli ultimi mesi, il team di Snorkel ha lavorato duramente per affrontare le sfide uniche della progettazione di un'infrastruttura efficiente per supportare i carichi di lavoro di sviluppo ML senza aumentare le spese infrastrutturali, ridurre la velocità degli sviluppatori o compromettere l'esperienza utente. Il loro obiettivo finale era ridurre la spesa di elaborazione del cluster per Snorkel Flow, la loro piattaforma ML end-to-end, di più del 40%.

Una panoramica di Snorkel Flow

La piattaforma di sviluppo dati Snorkel Flow AI di Snorkel consente ai team di dati di creare rapidamente applicazioni di intelligenza artificiale utilizzando un ciclo iterativo di etichettatura programmatica, addestramento rapido dei modelli e analisi degli errori. Ogni progetto inizia quando gli utenti creano un numero limitato di funzioni di etichettatura.

Le funzioni di etichettatura utilizzano semplici euristiche, database esterni, modelli legacy o persino chiamate a modelli linguistici di grandi dimensioni per applicare etichette a porzioni di dati privi di etichetta in base all'intuizione codificata di esperti. Il debole algoritmo di supervisione della piattaforma combina queste funzioni basate su regole per determinare l'etichetta più probabile per ogni record. Gli utenti addestrano quindi un modello semplice basato su questi dati probabilistici e valutano l'impatto di ciascuna funzione di etichettatura. Nella fase di analisi, gli utenti esaminano le porzioni di dati in cui il modello ha prestazioni inferiori. Quindi creano o modificano le funzioni di etichettatura, addestrano rapidamente un altro modello e continuano il ciclo. Quando gli utenti sono soddisfatti della qualità delle loro etichette, creano un modello finale su un'architettura dello zoo di modelli, che va dalla regressione logistica ai FM, e lo esportano per l'implementazione.

A causa della natura di questo flusso di lavoro, l'infrastruttura di Snorkel Flow sperimenta diversi periodi di elevato utilizzo dell'elaborazione. I costi operativi sono naturalmente aumentati con l'aumento della base clienti e delle funzionalità dei prodotti ML di Snorkel Flow. Per raggiungere una crescita efficiente, Snorkel mirava a capire come aumentare i margini utilizzando un software ML all'avanguardia. Snorkel ha implementato le seguenti pratiche per ottenere una riduzione di oltre il 40% dei costi di elaborazione dei cluster.

Soluzioni per l'ottimizzazione dei costi del cloud 

Le startup Software-as-a-Service (SaaS) hanno spesso l'opportunità di ottimizzare la spesa per il cloud. È essenziale comprendere i fattori unici che determinano questi costi.

Per Snorkel, c'erano due fattori significativi:

1. I carichi di lavoro di sviluppo ML richiedono spesso hardware specializzato e costoso, come le GPU. In genere, questi carichi di lavoro sono di natura "frammentaria".
2. Le aziende Fortune 500 e le grandi agenzie federali utilizzano Snorkel, comprese le principali istituzioni finanziarie con reparti IT sofisticati che hanno requisiti specifici di implementazione e privacy dei dati, utilizzando una piattaforma containerizzata.

Il team di Snorkel desidera creare sistemi che consentano una scalabilità efficiente senza un aumento lineare dei costi dell'infrastruttura. Snorkel di conseguenza ha sviluppato una soluzione di dimensionamento automatico completa su misura per i propri carichi di lavoro ML su Amazon EKS per risolvere i problemi relativi alle spese del cloud. Questa soluzione non solo ha accelerato i carichi di lavoro che richiedono elaborazione a raffica, ma ha anche consentito di raggiungere gli obiettivi di riduzione dei costi.

Oltre alla soluzione di dimensionamento automatico, le strategie chiave che hanno contribuito alla riduzione di oltre il 40% delle spese per il cloud includono:

• Collaborazione con i leader tecnici e il team AWS per adottare Savings Plans tramite ottimizzazioni della configurazione del cloud.
• Dimensionamento corretto delle risorse tramite il monitoraggio dell'utilizzo dei nodi con Prometheus e la consulenza degli ingegneri di back-end per valutare le esigenze dei componenti della piattaforma.
• Passaggio a tipi di macchine virtuali (VM) convenienti su Amazon EKS e utilizzo di istanze Amazon Elastic Compute Cloud (Amazon EC2) multi-GPU per migliorare il rapporto prezzo/prestazioni.
• Istituzione di modifiche ai processi interni in cui gli ingegneri collaboravano con team rivolti ai clienti per ridurre al minimo l'elaborazione inattiva.

In questo post, Snorkel condivide il processo per affrontare queste sfide di scalabilità per facilitare la progettazione di un'infrastruttura migliore per i sistemi ML. Se non conosci Kubernetes, leggi il post Introduzione a Kubernetes di Snorkel per saperne di più sulle nozioni di base e sul machine learning su Kubernetes: saggezza appresa nel post di Snorkel per saperne di più sul suo percorso con Kubernetes fino ad ora.

Che aspetto ha Snorkel Flow su AWS

In pratica, l'interazione di Snorkel Flow con AWS segue la sequenza delineata di seguito. Poiché la piattaforma Snorkel Flow fa molto affidamento sui container, la migrazione ad AWS è stata quasi perfetta.

• Gli utenti accedono all'istanza di Snorkel Flow tramite il loro browser Web, che corrisponde a una regola in Amazon Route 53.
• Route 53 inoltra la richiesta a un Application Load Balancer.
• L'Application Load Balancer quindi inoltra la richiesta ai pod Snorkel Flow in esecuzione su un cluster EKS condiviso. Snorkel ha cambiato il tipo di istanza EC2 da m5 a m6a per ottimizzare i costi, ottenendo un risparmio di elaborazione del 10% con un impatto trascurabile sulle prestazioni in base al costo orario per la stessa CPU e RAM.
• Inoltre, sono passati da una singola istanza GPU g4dn.8xlarge a un'istanza multi-GPU g4dn.12xlarge, che consentiva di utilizzare un numero di pod GPU quattro volte maggiore.
• Ogni istanza di Snorkel Flow utilizza un volume Amazon Elastic File System (Amazon EFS) per archiviare i file su disco.
• Una coda Redis ospitata autonomamente su un pod sull'istanza EC2 contiene i processi in entrata, in attesa che i pod worker li raccolgano.
• I parametri EKS vengono inviati ad Amazon CloudWatch e gli script personalizzati monitorano i log per individuare anomalie nelle prestazioni del cluster.

Questa architettura ha prodotto un'esperienza stabile e veloce per gli utenti di Snorkel Flow.

Ripensare al dimensionamento

Prima dell'architettura descritta nella Figura 1, le prime iterazioni dell'infrastruttura di Snorkel utilizzavano risorse fisse. Gli utenti di Snorkel hanno dichiarato che il completamento di questi carichi di lavoro frenetici poteva richiedere troppo tempo e quindi influire negativamente sulla loro esperienza.

Il dimensionamento manuale delle risorse di calcolo si è dimostrato non scalabile e soggetto a errori, con conseguenti costi del cloud che sono rimasti elevati anche durante i periodi di basso utilizzo. È stato il peggio in assoluto: bassa efficienza dei costi del cloud e prestazioni più lente del necessario.

Per affrontare queste sfide, Snorkel ha implementato il dimensionamento automatico a più livelli nella propria infrastruttura, come discusso nelle sezioni seguenti.

Progettazione di un'infrastruttura dimensionabile tenendo conto dell'efficienza in termini di costi

La distribuzione Kubernetes di Snorkel Flow prevede una serie di implementazioni in esecuzione in un cluster EKS che contiene pod che eseguono vari componenti della piattaforma.

Come mostrato nella Figura 2, per affrontare le sfide uniche legate all'utilizzo di carichi di lavoro di elaborazione complessi, il team di Snorkel ha introdotto un nuovo concetto per i pod Kubernetes: classificarli semanticamente come "fissi" o "flessibili".

• I pod fissi non possono essere spostati in sicurezza da un nodo all'altro, sia perché perderanno importanti stati in memoria (come i processi di elaborazione in corso senza checkpoint) sia per ridurre al minimo i tempi di inattività evitabili per i componenti fondamentali della piattaforma (ad esempio, l'orchestrator per il cluster Ray).
• I pod flessibili possono essere spostati in sicurezza su un nuovo nodo. Questa distinzione è significativa nel contesto del dimensionamento automatico, poiché il downscaling dei nodi implica lo spostamento dei pod dai nodi sottoutilizzati quando vengono terminati.

Questo framework fisso/flessibile offre a Snorkel uno strumento specifico del dominio per abilitare il downscaling automatizzato del cluster, che consente di attivare il cluster autoscaler su Amazon EKS senza che il reparto finanziario invii messaggi ogni ora.

L'approccio iniziale di Snorkel era quello di implementare podDisruptionBudgets sul cluster EKS per impedire al cluster autoscaler di spostare i pod flessibili durante il giorno e di spostare i pod fissi in ogni momento. Sebbene efficace, questo approccio ha lasciato il team di Snorkel insoddisfatto perché ha ridimensionato un numero di nodi molto inferiore a quello teoricamente ottimale.

Per risolvere questo problema, Snorkel ha implementato un'ottimizzazione della pianificazione dei pod che isolava i pod fissi in un piccolo gruppo fisso di nodi. Ha programmato i pod flessibili e i pod worker (considerati pod fissi ma effimeri, a causa del dimensionamento automatico dei nodi worker) nel restante gruppo flessibile di nodi.

Queste modifiche hanno consentito a Snorkel di ridurre in modo efficiente i nodi flessibili di notte, quando è diventato sicuro spostarsi all'interno dei pod flessibili e ridurre la stragrande maggioranza dei pod worker.

L'abilitazione di un downscaling efficiente della stragrande maggioranza dei nodi del cluster (ovvero i nodi flessibili) ha consentito a Snorkel di raggiungere l'obiettivo di ridurre i costi del cloud per l'hosting di Snorkel Flow di oltre il 40%.

Maggiori dettagli sulla soluzione di dimensionamento automatico di Snorkel

Snorkel divide l'implementazione della soluzione descritta nella sezione precedente in tre sforzi sequenziali:

1. Innanzitutto, Snorkel ha implementato il "dimensionamento automatico worker" un servizio di dimensionamento automatico personalizzato basato su Redis che consente ai pod worker di aumentare e ridursi in base ai processi nelle code dei worker.
2. In secondo luogo, hanno implementato il "dimensionamento automatico del cluster" riconfigurando le loro implementazioni Kubernetes per consentire al cluster autoscaler Kubernetes di ridimensionare i nodi, oltre a scalare i nodi verso l'alto.
3. In terzo luogo, Snorkel ha implementato le "ottimizzazioni del downscaling dei nodi" raggruppando i pod fissi in un piccolo gruppo di nodi fissi per evitare la loro interferenza con il downscaling dei nodi rimanenti.

Dimensionamento automatico dei worker

La piattaforma Snorkel Flow astrae l'elaborazione in un paradigma in cui i processi attendono nelle code Redis e i lavoratori vengono eseguiti come processi nei pod worker.

Snorkel ha implementato una soluzione di dimensionamento automatico dei worker (Figura 3) per i pod worker eseguendo una funzione ricorrente nell'API di back-end di Snorkel Flow. Ogni pochi secondi, questa funzione verifica l'idoneità all'upscaling e al downscaling del cluster Kubernetes e di Redis.

Se ci sono processi in attesa in una o più code pertinenti basate su Redis, la funzione chiederà all'API Kubernetes di fornire pod worker aggiuntivi per elaborare questi processi. Se la coda Redis è vuota e non ci sono processi in esecuzione nel registro dei processi, chiederà all'API Kubernetes di distruggere i pod worker per liberare le risorse di CPU e RAM riservate.

Come illustrato nella Figura 4, con l'implementazione di questo dimensionamento automatico dei worker, i pod worker di Snorkel Flow sono diventati transitori, comparendo nel cluster solo quando era necessario elaborare i lavori.

Dimensionamento automatico del cluster

La risorsa PodDisruptionBudget protegge determinati pod dall'interruzione (ad esempio, riavvii volontari) consentendo di specificare il numero massimo di repliche del pod che possono essere non disponibili in un dato momento. Come illustrato nella Figura 5, l'impostazione esplicita di questo valore su 0 per una distribuzione garantisce che il cluster autoscaler non riduca i nodi che eseguono i pod dell’implementazione.

L'implementazione di questa risorsa sulle istanze Snorkel Flow ospitate ha consentito al cluster autoscaler di ridimensionare in modo sicuro i nodi sottoutilizzati. Tuttavia, i risparmi sui costi realizzati da Snorkel sono stati marginali: non è stato ancora possibile ridurre la maggior parte dei nodi poiché tutti i pod Snorkel Flow erano protetti da un podDisruptionBudget associato.

Dopo un esame più attento, il team di Snorkel si è reso conto che questa protezione non deve necessariamente esistere sempre. I carichi di lavoro sono intensi e la maggior parte delle interazioni degli utenti con Snorkel Flow avviene durante la giornata lavorativa del cliente, il che significa che è sicuro allentare questa protezione al di fuori dell'orario lavorativo. Analogamente al dimensionamento automatico dei worker, Snorkel ha implementato una funzione ricorrente che disattivava podDisruptionBudgets durante la notte per i pod flessibili di un'istanza impostando il numero massimo di repliche di pod non disponibili su 1 o 0 (Figura 6). La precedente soluzione di dimensionamento automatico dei worker, combinata con le funzionalità ClusterAutoscaler e PodDisruptionBudget, era in grado di ridurre molti più nodi di lavoro sottoutilizzati rispetto a prima. I clienti che implementano Snorkel Flow nel proprio cloud possono configurarlo in base alle esigenze.

Ottimizzazioni del downscaling dei nodi

Nonostante questi miglioramenti, Snorkel ha notato che la maggior parte dei nodi sottoutilizzati non veniva affatto ridimensionata.

Dopo ulteriori indagini, Snorkel si rese conto che il problema derivava da pod fissi e flessibili che occupavano lo stesso nodo. Ciò era problematico perché un pod fisso, assegnato in modo pseudo-casuale a un nodo contenente pod flessibili, "bloccava" quel nodo e ne impediva il ridimensionamento, anche quando era sottoutilizzato. Questa mancanza di controllo sulla pianificazione dei pod fissi ha portato a periodi in cui la stragrande maggioranza dei nodi del cluster non poteva essere ridimensionata, anche se rappresentavano una potenza di calcolo molto maggiore di quella necessaria in quel momento.

Snorkel ha sfruttato la risorsa Kubernetes podAffinities per risolvere questo problema, il che gli ha permesso di limitare i nodi su cui un pod è idoneo all'esecuzione in base alle etichette di altri pod già in esecuzione su un determinato nodo. Hanno aggiunto etichette ai pod per distinguere tra pod fissi e flessibili e hanno aggiunto una stanza podAntiAffinity alla configurazione delle loro implementazioni per garantire che i pod fissi non siano pianificati sui nodi che eseguono pod flessibili e viceversa.

Questa implementazione di podAffinities ha permesso a Snorkel AI di dividere i nodi in due gruppi funzionali: il gruppo fisso di nodi contenente pod fissi, che non possono mai essere spostati in sicurezza tra i nodi (ad esempio, Redis a causa della cache) e il gruppo flessibile di nodi contenente pod "flessibili" che sono temporanei (come i pod worker) o sicuri da spostare al di fuori dell'orario di lavoro (ad esempio, durante la notte).

Sebbene sia possibile con un intervento manuale durante la manutenzione della piattaforma, Snorkel non può ridurre automaticamente i nodi fissi. Questa soluzione, tuttavia, consente loro di ridurre automaticamente i nodi flessibili perché ora hanno isolato i pod inamovibili nei nodi fissi.

Conclusioni

I team di Snorkel e Startup AWS sperano che la condivisione di questo processo di pensiero e di queste soluzioni aiuti altre startup a creare un'infrastruttura migliore per i carichi di lavoro ML, che stanno rapidamente diventando sempre più importanti man mano che ML, modelli linguistici di grandi dimensioni e altri FM stanno entrando nella produzione per le organizzazioni di tutto il mondo.

Stai partecipando ad AWS re:Invent 2023? Questa implementazione verrà evidenziata come parte della sessione di Snorkel Esplorare il futuro dell’IA: implementazione di modelli generativi su Amazon EKS(sessione CON312).Assicurati di dargli un'occhiata!

Grazie mille a David Hao, Edmond Liu e Alec Xiang per aver contribuito a trasformare questa visione tecnica in realtà per Snorkel. Un ringraziamento speciale ai suddetti, nonché a Matt Casey, Henry Ehrenberg, Anthony Bishopric e all'intero team di progettazione delle infrastrutture di Snorkel per il loro premuroso feedback su questo articolo.