In che modo Veriff ha ridotto i tempi di distribuzione dell'80% utilizzando endpoint multimodello Amazon SageMaker | Servizi Web di Amazon

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

Veriff offre un'infrastruttura collaudata che consente ai propri clienti di avere fiducia nelle identità e negli attributi personali dei propri utenti in tutti i momenti rilevanti del loro percorso cliente. Veriff gode della fiducia di clienti come Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot e Wise.

Essendo una soluzione basata sull'intelligenza artificiale, Veriff deve creare ed eseguire decine di modelli di machine learning (ML) in modo economicamente vantaggioso. Questi modelli spaziano da modelli leggeri basati su alberi a modelli di visione artificiale con apprendimento profondo, che devono essere eseguiti su GPU per ottenere una bassa latenza e migliorare l'esperienza dell'utente. Veriff sta attualmente aggiungendo altri prodotti alla sua offerta, mirando a una soluzione iper-personalizzata per i suoi clienti. Il servizio di modelli diversi per clienti diversi aumenta la necessità di una soluzione di servizio di modelli scalabile.

In questo post, ti mostriamo come Veriff ha standardizzato il flusso di lavoro di distribuzione del modello utilizzando Amazon Sage Maker, riducendo costi e tempi di sviluppo.

Infrastrutture e sfide dello sviluppo

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

Alcuni di questi modelli richiedevano la distribuzione su istanze GPU. Consapevole del costo relativamente più elevato dei tipi di istanze supportate da GPU, Veriff ha sviluppato un soluzione personalizzata su Kubernetes per condividere le risorse di una determinata GPU tra diverse repliche del servizio. Una singola GPU in genere ha una VRAM sufficiente per contenere in memoria più modelli di visione artificiale di Veriff.

Sebbene la soluzione alleviasse i costi della GPU, presentava anche il vincolo che i data scientist dovevano indicare in anticipo la quantità di memoria GPU richiesta dal loro modello. Inoltre, DevOps era gravato dal provisioning manuale delle istanze GPU in risposta ai modelli di domanda. Ciò ha causato un sovraccarico operativo e un provisioning eccessivo delle istanze, che hanno comportato un profilo di costo non ottimale.

Oltre al provisioning della GPU, questa configurazione richiedeva anche ai data scientist di creare un wrapper API REST per ciascun modello, necessario per fornire un'interfaccia generica da utilizzare per altri servizi aziendali e per incapsulare la preelaborazione e la postelaborazione dei dati del modello. Queste API richiedevano codice di livello produttivo, il che rendeva difficile per i data scientist produrre modelli.

Il team della piattaforma di data science di Veriff ha cercato modi alternativi a questo approccio. L'obiettivo principale era supportare i data scientist dell'azienda in una migliore transizione dalla ricerca alla produzione fornendo pipeline di implementazione più semplici. L'obiettivo secondario era ridurre i costi operativi del provisioning delle istanze GPU.

Panoramica della soluzione

Veriff richiedeva una nuova soluzione che risolvesse due problemi:

• Consenti di creare facilmente wrapper API REST attorno ai modelli ML
• Consenti la gestione ottimale della capacità delle istanze GPU assegnate e, se possibile, automaticamente

Alla fine, il team della piattaforma ML è giunto alla decisione di utilizzarla Endpoint multimodello Sagemaker (MME). Questa decisione è stata guidata dal supporto di MME per NVIDIA Server di inferenza Triton (un server incentrato sul ML che semplifica il confezionamento di modelli come API REST; Veriff stava già sperimentando Triton), nonché la sua capacità di gestire in modo nativo il ridimensionamento automatico delle istanze GPU tramite semplici policy di ridimensionamento automatico.

Alla Veriff sono stati creati due MME, uno per la messa in scena e uno per la produzione. Questo approccio consente loro di eseguire fasi di test in un ambiente di staging senza influire sui modelli di produzione.

MME SageMaker

SageMaker è un servizio completamente gestito che offre a sviluppatori e data scientist la possibilità di creare, addestrare e distribuire rapidamente modelli ML. Gli MME di SageMaker forniscono una soluzione scalabile ed economica per l'implementazione di 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 degli endpoint rispetto all'utilizzo di endpoint a modello singolo. Riduce anche l'overhead di distribuzione perché SageMaker gestisce il caricamento e lo scaricamento dei modelli in memoria e li ridimensiona in base ai modelli di traffico dell'endpoint. Inoltre, tutti gli endpoint SageMaker in tempo reale beneficiano delle funzionalità integrate per gestire e monitorare i modelli, come l'inclusione varianti d'ombra, ridimensionamento automaticoe integrazione nativa con Amazon Cloud Watch (per maggiori informazioni, vd Metriche di CloudWatch per distribuzioni di endpoint multimodello).

Modelli di ensemble Triton personalizzati

Ci sono stati diversi motivi per cui Veriff ha deciso di utilizzare Triton Inference Server, i principali sono:

• Consente ai data scientist di creare API REST dai modelli disponendo i file degli artefatti del modello in un formato di directory standard (soluzione senza codice)
• È compatibile con tutti i principali framework AI (PyTorch, Tensorflow, XGBoost e altri)
• Fornisce ottimizzazioni server e di basso livello specifiche per ML come dosaggio dinamico di richieste

L'uso di Triton consente ai data scientist di distribuire modelli con facilità perché devono solo creare repository di modelli formattati invece di scrivere codice per creare API REST (Triton supporta anche Modelli Python se è richiesta una logica di inferenza personalizzata). Ciò riduce i tempi di distribuzione dei modelli e offre ai data scientist più tempo per concentrarsi sulla creazione di modelli invece che sulla loro distribuzione.

Un'altra caratteristica importante di Triton è che ti permette di costruire insiemi di modelli, che sono gruppi di modelli concatenati insieme. Questi gruppi possono essere gestiti come se fossero un unico modello Triton. Veriff attualmente utilizza questa funzionalità per distribuire la logica di preelaborazione e postelaborazione con ciascun modello ML utilizzando modelli Python (come menzionato in precedenza), garantendo che non vi siano discrepanze nei dati di input o nell'output del modello quando i modelli vengono utilizzati in produzione.

Di seguito è riportato l'aspetto di un tipico repository di modelli Triton per questo carico di lavoro:

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

Ulteriori dipendenze necessarie per eseguire i modelli Python sono dettagliate in a requirements.txt file e deve essere compresso con conda per creare un ambiente Conda (python_env.tar.gz). Per ulteriori informazioni, fare riferimento a Gestione del runtime e delle librerie Python. Inoltre, i file di configurazione per i passaggi Python devono puntare python_env.tar.gz usando il EXECUTION_ENV_PATH Direttiva.

La cartella del modello deve quindi essere compressa con TAR e rinominata utilizzando model_version.txt. Infine, il risultato <model_name>_<model_version>.tar.gz il file viene copiato in Servizio di archiviazione semplice Amazon (Amazon S3) collegato all'MME, consentendo a SageMaker di rilevare e servire il modello.

Versionamento del modello e distribuzione continua

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

• È gestito utilizzando Pantaloni.
• Strumenti di qualità del codice come Black e MyPy vengono applicati utilizzando Pants.
• Per ciascun modello vengono definiti unit test che verificano che l'output del modello sia l'output previsto per un dato input del modello.
• I pesi dei modelli vengono archiviati insieme ai repository di modelli. Questi pesi possono essere file binari di grandi dimensioni, quindi DVC viene utilizzato per sincronizzarli con Git in modalità versione.

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

1. Supera il controllo di qualità del codice.
2. Scarica i pesi del modello.
3. Costruisci l'ambiente Conda.
4. Avvia un server Triton utilizzando l'ambiente Conda e utilizzalo per elaborare le richieste definite negli unit test.
5. Costruisci il file TAR del modello finale (<model_name>_<model_version>.tar.gz).

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

Vantaggi in termini di costi e velocità di implementazione

L'utilizzo degli MME consente a Veriff di utilizzare un approccio monorepo per distribuire i modelli in produzione. In sintesi, il nuovo flusso di lavoro di distribuzione del modello di Veriff è costituito dai seguenti passaggi:

1. Crea un ramo nel monorepo con il nuovo modello o versione del modello.
2. Definire ed eseguire unit test in una macchina di sviluppo.
3. Spingere il ramo quando il modello è pronto per essere testato nell'ambiente di staging.
4. Unisci il ramo in quello principale quando il modello è pronto per essere utilizzato nella produzione.

Con questa nuova soluzione in atto, l'implementazione di un modello presso Veriff è una parte semplice del processo di sviluppo. Il tempo di sviluppo del nuovo modello è diminuito da 10 giorni a una media di 2 giorni.

Il provisioning dell'infrastruttura gestita e le funzionalità di scalabilità automatica di SageMaker hanno apportato a Veriff ulteriori vantaggi. Hanno usato il InvocazioniPerInstance Metrica CloudWatch per adattarsi ai modelli di traffico, risparmiando sui costi senza sacrificare l'affidabilità. Per definire il valore di soglia per il parametro, hanno eseguito test di carico sull'endpoint di staging per trovare il miglior compromesso tra latenza e costi.

Dopo aver distribuito sette modelli di produzione alle MME e aver analizzato la spesa, Veriff ha segnalato una riduzione dei costi del 75% nel servizio del modello GPU rispetto alla soluzione originale basata su Kubernetes. Anche i costi operativi sono stati ridotti, poiché gli ingegneri DevOps dell'azienda sono stati sollevati dall'onere del provisioning manuale delle istanze.

Conclusione

In questo post, abbiamo esaminato il motivo per cui Veriff ha scelto gli MME Sagemaker rispetto alla distribuzione del modello autogestito su Kubernetes. SageMaker si fa carico del lavoro pesante indifferenziato, consentendo a Veriff di ridurre i tempi di sviluppo del modello, aumentare l'efficienza ingegneristica e ridurre drasticamente i costi per l'inferenza in tempo reale, pur mantenendo le prestazioni necessarie per le operazioni business-critical. Infine, abbiamo presentato la pipeline CI/CD di distribuzione del modello semplice ma efficace di Veriff e il meccanismo di controllo delle versioni del modello, che può essere utilizzato come implementazione di riferimento per combinare le migliori pratiche di sviluppo software e gli MME SageMaker. Puoi trovare esempi di codice sull'hosting di più modelli utilizzando gli MME SageMaker su GitHub.

---

Informazioni sugli autori

Riccardo Borràs è un Senior Machine Learning presso Veriff, dove guida le attività di MLOps nell'azienda. Aiuta i data scientist a creare prodotti AI/ML più rapidi e migliori creando una piattaforma di data science presso l'azienda e combinando diverse soluzioni open source con i servizi AWS.

João Moura è un AI/ML Specialist Solutions Architect presso AWS, con sede in Spagna. Aiuta i clienti con modelli di deep learning, formazione su larga scala e ottimizzazione dell'inferenza e, più in generale, con la creazione di piattaforme ML su larga scala su AWS.

Miguel Ferreira lavora come Sr. Solutions Architect presso AWS con sede a Helsinki, Finlandia. L'intelligenza artificiale/ML è un suo interesse da sempre e ha aiutato diversi clienti a integrare Amazon SageMaker nei loro flussi di lavoro ML.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/