Come Veriff ha ridotto i tempi di implementazione dell’80% utilizzando i punti endpoint multi-modello di Amazon SageMaker

Come Veriff ha ridotto dell'80% i tempi di implementazione utilizzando i punti endpoint multi-modello di Amazon SageMaker

Veriff è una piattaforma di verifica dell’identità partner per organizzazioni innovative orientate alla crescita, tra cui pionieri nei servizi finanziari, FinTech, criptovalute, giochi, mobilità e mercati online. Forniscono tecnologia avanzata che combina l’automazione alimentata da intelligenza artificiale con il feedback umano, approfondite informazioni e competenze.

Veriff offre un’infrastruttura comprovata che consente ai loro clienti di avere fiducia nelle identità e nelle attribuzioni personali dei loro utenti in tutti i momenti rilevanti del percorso del cliente. Veriff è fidato dai clienti come Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot e Wise.

Come soluzione alimentata dall’intelligenza artificiale, Veriff ha bisogno di creare e eseguire decine di modelli di apprendimento automatico (ML) in modo economico. Questi modelli vanno da modelli leggeri basati su alberi a modelli di deep learning per visione artificiale, che devono essere eseguiti su GPU per ridurre la latenza e migliorare l’esperienza utente. Attualmente Veriff sta anche aggiungendo più prodotti alla sua offerta, puntando a una soluzione iper-personalizzata per i suoi clienti. Servire modelli diversi per clienti diversi aumenta la necessità di una soluzione di servizio di modelli scalabile.

• Crea la tua Applicazione Full-stack AI con ReactPy
• Ricercatori di CMU e Google DeepMind presentano AlignProp un approccio basato su retropropagazione diretta per migliorare modelli di diffusione testo-immagine per la funzione di ricompensa desiderata.
• Le immagini mediche non funzionano con la pelle scura. I ricercatori lo hanno risolto

In questo articolo, ti mostriamo come Veriff ha standardizzato il loro flusso di lavoro di distribuzione dei modelli utilizzando Amazon SageMaker, riducendo i costi e il tempo di sviluppo.

Sfide infrastrutturali e di sviluppo

L’architettura di backend di Veriff si basa su un modello a microservizi, con servizi in esecuzione su diversi cluster Kubernetes ospitati su infrastrutture AWS. Questo approccio è stato inizialmente utilizzato per tutti i servizi aziendali, compresi i microservizi che eseguono modelli di apprendimento automatico per visione artificiale costosi.

Alcuni di questi modelli richiedevano l’esecuzione su istanze GPU. Consapevoli del costo relativamente più elevato dei tipi di istanze supportate da GPU, Veriff ha sviluppato una soluzione personalizzata su Kubernetes per condividere le risorse di una GPU tra diverse repliche di servizi. Tipicamente, una singola GPU ha abbastanza memoria VRAM da contenere più modelli di visione artificiale di Veriff in memoria.

Anche se la soluzione ha contribuito a ridurre i costi delle GPU, è stata imposta la restrizione che gli scienziati dei dati dovevano indicare in precedenza quanto spazio di memoria GPU avrebbe richiesto il loro modello. Inoltre, il reparto DevOps era gravato dalla fornitura manuale di istanze GPU in risposta ai pattern di domanda. Ciò ha comportato un onere operativo e un sovrapprovvigionamento di istanze, con conseguente profilo dei costi non ottimale.

Oltre alla fornitura di GPU, questa configurazione richiedeva anche agli scienziati dei dati di creare un wrapper REST API per ogni modello, necessario per fornire un’interfaccia generica per gli altri servizi aziendali e per incapsulare preprocessing e postprocessing dei dati del modello. Queste API richiedevano codice di produzione di grado, il che rendeva difficile per gli scienziati dei dati rendere i modelli pronti per la produzione.

Il team della piattaforma di scienza dei dati di Veriff ha cercato alternative a questo approccio. L’obiettivo principale era quello di supportare gli scienziati dei dati aziendali con una transizione migliore dalla fase di ricerca alla produzione, fornendo pipeline di distribuzione più semplici. L’obiettivo secondario era quello di ridurre i costi operativi della fornitura di istanze GPU.

Panoramica della soluzione

Veriff aveva bisogno di una nuova soluzione che risolvesse due problemi:

• Consentire la creazione semplificata di wrapper REST API attorno ai modelli di apprendimento automatico
• Consentire la gestione ottimale e, se possibile, automatica della capacità delle istanze GPU fornite

Ancora una volta, il team della piattaforma di apprendimento automatico si è orientato sulla decisione di utilizzare Sagemaker multi-model endpoints (MME). Questa decisione è stata motivata dal supporto di MME al Triton Inference Server di NVIDIA (un server focalizzato sull’apprendimento automatico che semplifica l’incapsulamento dei modelli come REST API; Veriff ha già sperimentato Triton), nonché dalla capacità di gestire in modo nativo il dimensionamento automatico delle istanze GPU tramite politiche di autoscaling semplici.

Sono state create due MME da Veriff, una per l’ambiente di test e una per la produzione. Questo approccio consente loro di eseguire i passaggi di prova in un ambiente di test senza influire sui modelli di produzione.

SageMaker MMEs

SageMaker è un servizio completamente gestito che offre agli sviluppatori e ai data scientist la possibilità di creare, addestrare e distribuire modelli di machine learning rapidamente. Le MME (Multi-Model Endpoints) di SageMaker forniscono una soluzione scalabile ed economica per distribuire un gran numero di modelli per l’inferenza in tempo reale. Le MME utilizzano un contenitore di servizio condiviso e una flotta di risorse che possono utilizzare istanze accelerate come le GPU per ospitare tutti i tuoi modelli. Ciò riduce i costi di hosting massimizzando l’utilizzo dei punti di passaggio rispetto all’utilizzo dei singoli punti quelli di modello. Riduce inoltre l’overhead di distribuzione perché SageMaker si occupa del caricamento e dello scaricamento dei modelli in memoria e della loro scalabilità in base ai modelli di traffico del punto finale. Inoltre, tutti i punti finali in tempo reale di SageMaker beneficiano di capacità integrate per gestire e monitorare i modelli, come ad esempio l’inclusione di varianti di ombra, auto scaling e integrazione nativa con Amazon CloudWatch (per ulteriori informazioni, consulta Metriche CloudWatch per le distribuzioni di endpoint multi-modello).

Modelli di ensemble personalizzati con Triton

Ci sono diverse ragioni per cui Veriff ha deciso di utilizzare Triton Inference Server, le principali sono:

• Consente ai data scientist di creare API REST dai modelli, organizzando i file di artefatti del modello in un formato di directory standard (soluzione senza codice)
• È compatibile con tutti i principali framework di intelligenza artificiale (PyTorch, Tensorflow, XGBoost e altri)
• Fornisce ottimizzazioni specifiche per l’apprendimento automatico a basso livello e del server come la batching dinamica delle richieste

Utilizzando Triton, i data scientist possono distribuire i modelli con facilità perché devono solo costruire repository di modelli formattati anziché scrivere codice per creare API REST (Triton supporta anche modelli Python se è necessaria una logica di inferenza personalizzata). Ciò riduce il tempo di distribuzione del modello e offre ai data scientist più tempo per concentrarsi sulla creazione di modelli anziché sulla loro distribuzione.

Un’altra caratteristica importante di Triton è che consente di creare modelli di ensemble, che sono gruppi di modelli concatenati insieme. Questi ensemble possono essere eseguiti come se fossero un singolo modello Triton. Attualmente Veriff utilizza questa funzionalità per distribuire la logica di preelaborazione e postelaborazione con ogni modello ML utilizzando modelli Python (come accennato in precedenza), garantendo che non ci siano discrepanze nei dati di input o nell’output del modello quando i modelli vengono utilizzati in produzione.

Di seguito è riportato un esempio di come appare di solito un repository di modelli Triton per questo carico di lavoro:

Il file model.py contiene il codice di preelaborazione e postelaborazione. I pesi del modello addestrato si trovano nella directory screen_detection_inferencer, nella versione del modello 1 (in questo esempio, il modello è in formato ONNX, ma può essere anche TensorFlow, PyTorch o altri formati). La definizione del modello di ensemble si trova nella directory screen_detection_pipeline, dove gli input e gli output tra le fasi sono mappati in un file di configurazione.

Le dipendenze aggiuntive necessarie per eseguire i modelli Python sono dettagliate in un file requirements.txt e devono essere confezionate conda per creare un ambiente Conda (python_env.tar.gz). Per ulteriori informazioni, consulta Gestione del Runtime Python e delle librerie. Inoltre, i file di configurazione per le fasi Python devono puntare a python_env.tar.gz utilizzando la direttiva EXECUTION_ENV_PATH.

La cartella del modello deve quindi essere compressa TAR e rinominata utilizzando model_version.txt. Infine, il file risultante <model_name>_<model_version>.tar.gz viene copiato nel bucket di Amazon Simple Storage Service (Amazon S3) collegato a MME, consentendo a SageMaker di rilevare e servire il modello.

Versionamento del modello e distribuzione continua

Come evidenziato dalla sezione precedente, la creazione di un repository di modelli Triton è semplice. Tuttavia, eseguire tutti i passaggi necessari per distribuirlo manualmente è noioso e soggetto a errori. Per superare questo problema, Veriff ha creato un monorepo che contiene tutti i modelli da distribuire su MME, in cui i data scientist collaborano seguendo un approccio simile a Gitflow. Questo monorepo ha le seguenti caratteristiche:

• È gestito utilizzando Pants.
• Sono applicati strumenti di qualità del codice come Black e MyPy utilizzando Pants.
• Sono definite test unitari per ogni modello, che verificano che l’output del modello sia l’output atteso per un determinato input di modello.
• I pesi del modello sono memorizzati insieme ai repository del modello. Questi pesi possono essere grandi file binari, quindi viene utilizzato DVC per sincronizzarli con Git in modo versionato.

Questo monorepo è integrato con uno strumento di integrazione continua (CI). Ad ogni nuova push nel repo o nuovo modello, vengono eseguiti i seguenti passaggi:

1. Passare il controllo di qualità del codice.
2. Scaricare i pesi del modello.
3. Compilare l’ambiente Conda.
4. Avviare un server Triton utilizzando l’ambiente Conda e usarlo per elaborare le richieste definite nei test unitari.
5. Creare il file TAR finale del modello (<model_name>_<model_version>.tar.gz).

Questi passaggi assicurano che i modelli abbiano la qualità richiesta per la distribuzione, quindi ad ogni push su un branch del repository, il file TAR risultante viene copiato (in un altro passaggio CI) nel bucket di staging di S3. Quando vengono eseguite push nel branch principale, il file del modello viene copiato nel bucket di produzione di S3. Il seguente diagramma rappresenta questo sistema CI/CD.

Vantaggi in termini di costi e velocità di distribuzione

L’utilizzo di MME consente a Veriff di utilizzare un approccio di monorepo per distribuire modelli in produzione. In sintesi, il nuovo flusso di lavoro per la distribuzione dei modelli di Veriff consiste nei seguenti passaggi:

1. Crea un branch nel monorepo con il nuovo modello o la nuova versione del modello.
2. Definisci ed esegui i test unitari su una macchina di sviluppo.
3. Esegui la push del branch quando il modello è pronto per essere testato nell’ambiente di staging.
4. Unisci il branch principale quando il modello è pronto per essere utilizzato in produzione.

Con questa nuova soluzione in atto, la distribuzione di un modello presso Veriff è una parte semplice del processo di sviluppo. Il tempo di sviluppo di nuovi modelli è diminuito da 10 giorni a una media di 2 giorni.

Le funzionalità di provisioning dell’infrastruttura gestita e di scalabilità automatica di SageMaker hanno portato a Veriff benefici aggiuntivi. Hanno utilizzato la metrica CloudWatch InvocationsPerInstance per scalare in base ai modelli di traffico, risparmiando sui costi senza sacrificare l’affidabilità. Per definire il valore di soglia per la metrica, hanno effettuato test di carico sull’endpoint di staging per trovare il miglior compromesso tra latenza e costo.

Dopo aver distribuito sette modelli di produzione su MME e analizzato la spesa, Veriff ha riportato una riduzione dei costi del 75% nella fornitura di modelli GPU rispetto alla soluzione basata su Kubernetes originale. Anche i costi operativi sono stati ridotti, perché il carico di provisioning di istanze manualmente è stato tolto agli ingegneri DevOps dell’azienda.

Conclusioni

In questo post, abbiamo esaminato perché Veriff ha scelto Sagemaker MME anziché la distribuzione di modelli autogestiti su Kubernetes. SageMaker si occupa delle attività pesanti non differenziate, consentendo a Veriff di ridurre il tempo di sviluppo del modello, aumentare l’efficienza ingegneristica e ridurre drasticamente i costi per l’inferenza in tempo reale mantenendo le prestazioni necessarie per le operazioni critiche per l’attività. Infine, abbiamo mostrato il semplice ma efficace flusso di lavoro di distribuzione del modello CI/CD e il meccanismo di versionamento del modello di Veriff, che possono essere utilizzati come implementazione di riferimento per combinare le migliori pratiche di sviluppo del software e Sagemaker MME. Puoi trovare esempi di codice su come ospitare più modelli utilizzando SageMaker MME su GitHub.