Oppnå hosting med lav latens for beslutningstrebaserte ML-modeller på NVIDIA Triton Inference Server på Amazon SageMaker

Implementeringer av maskinlæringsmodeller (ML) kan ha svært krevende krav til ytelse og ventetid for bedrifter i dag. Brukstilfeller som svindeloppdagelse og annonseplassering er eksempler der millisekunder betyr noe og er avgjørende for suksess. Strenge servicenivåavtaler (SLAer) må oppfylles, og en typisk forespørsel kan kreve flere trinn som forbehandling, datatransformasjon, modellvalglogikk, modellaggregering og etterbehandling. I stor skala betyr dette ofte å opprettholde et stort trafikkvolum samtidig som det opprettholdes lav ventetid. Vanlige designmønstre inkluderer serielle inferensrørledninger, ensembler (scatter-gather) og forretningslogiske arbeidsflyter, som resulterer i å realisere hele arbeidsflyten for forespørselen som en rettet asyklisk graf (DAG). Men etter hvert som arbeidsflytene blir mer komplekse, kan dette føre til en økning i den totale responstiden, som igjen kan påvirke sluttbrukeropplevelsen negativt og sette forretningsmål i fare. Triton kan adressere disse brukstilfellene der flere modeller er satt sammen i en pipeline med inngangs- og utgangstensorer koblet mellom dem, og hjelper deg med å håndtere disse arbeidsbelastningene.

Når du evaluerer målene dine i forhold til ML-modellslutning, kan mange alternativer vurderes, men få er så dyktige og beviste som Amazon SageMaker med Triton Inference Server. SageMaker med Triton Inference Server har vært et populært valg for mange kunder fordi den er spesialbygd for å maksimere gjennomstrømming og maskinvareutnyttelse med ultralav (ensifret millisekunder) inferensforsinkelse. Den har et bredt spekter av støttede ML-rammeverk (inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, inkludert NVIDIA GPUer, CPUer og AWS slutning. I tillegg er Triton Inference Server integrert med SageMaker, en fullstendig administrert ende-til-ende ML-tjeneste, som gir sanntidsslutningsalternativer for modellhosting.

I dette innlegget går vi gjennom distribusjonen av en arbeidsbelastning for svindeldeteksjonsensemblet til SageMaker med Triton Inference Server.

Løsningsoversikt

Det er essensielt for ethvert prosjekt å ha en liste over krav og et anslag på innsats, for å tilnærme den totale kostnaden for prosjektet. Det er viktig å estimere avkastningen på investeringen (ROI) som støtter beslutningen til en organisasjon. Noen hensyn å ta i betraktning når du flytter en arbeidsmengde til Triton inkluderer:

Anstrengelsesestimering er nøkkelen i programvareutvikling, og målingen er ofte basert på ufullstendige, usikre og støyende inndata. ML arbeidsbelastninger er ikke annerledes. Flere faktorer vil påvirke en arkitektur for ML-inferens, hvorav noen inkluderer:

• Budsjett for ventetid på klientsiden – Den spesifiserer den maksimale akseptable ventetiden på klientsiden tur-retur for et slutningssvar, vanligvis uttrykt i persentiler. For arbeidsbelastninger som krever et ventebudsjett nær titalls millisekunder, kan nettverksoverføringer bli dyre, så bruk av modeller på kanten vil passe bedre.
• Data nyttelast distribusjon størrelse – Nyttelast, ofte referert til som meldingstekst, er forespørselsdataene som overføres fra klienten til modellen, samt svardataene som er overført fra modellen til klienten. Nyttelaststørrelsen har ofte stor innvirkning på ventetiden og bør tas i betraktning.
• Dataformat – Dette spesifiserer hvordan nyttelasten sendes til ML-modellen. Formatet kan være lesbart for mennesker, for eksempel JSON og CSV, men det finnes også binære formater, som ofte er komprimerte og mindre i størrelse. Dette er en avveining mellom komprimeringsoverhead og overføringsstørrelse, noe som betyr at CPU-sykluser og latens legges til for å komprimere eller dekomprimere, for å spare byte som overføres over nettverket. Dette innlegget viser hvordan du bruker både JSON og binære formater.
• Programvarestabel og komponenter kreves – En stabel er en samling komponenter som fungerer sammen for å støtte en ML-applikasjon, inkludert operativsystem, kjøretider og programvarelag. Triton kommer med innebygde populære ML-rammeverk, kalt backends, slik som ONNX, TensorFlow, FIL, OpenVINO, native Python og andre. Du kan også forfatter en tilpasset backend for dine egne hjemmelagde komponenter. Dette innlegget går over en XGBoost-modell og dataforbehandling, som vi migrerer til henholdsvis NVIDIA-leverte FIL- og Python Triton-backends.

Alle disse faktorene bør spille en viktig rolle i å evaluere hvordan arbeidsbelastningene dine presterer, men i dette tilfellet fokuserer vi på arbeidet som trengs for å flytte ML-modellene dine til å bli vert i SageMaker med Triton Inference Server. Spesifikt bruker vi et eksempel på et svindeloppdagelsesensemble sammensatt av en XGBoost-modell med forbehandlingslogikk skrevet i Python.

NVIDIA Triton Inference Server

Triton Inference Server er designet fra grunnen av for å gjøre det mulig for team å distribuere, kjøre og skalere trente AI-modeller fra ethvert rammeverk på GPU- eller CPU-basert infrastruktur. I tillegg har den blitt optimert for å tilby høyytelses inferens i skala med funksjoner som dynamisk batching, samtidige kjøringer, optimal modellkonfigurasjon, modellensemble og støtte for streaming-innganger.

Følgende diagram viser et eksempel på en NVIDIA Triton-ensemble-pipeline.

Arbeidsbelastninger bør ta hensyn til mulighetene som Triton gir sammen med SageMaker-hosting for å maksimere fordelene som tilbys. For eksempel støtter Triton HTTP så vel som en C API, som gir mulighet for fleksibilitet så vel som nyttelastoptimalisering ved behov. Som tidligere nevnt støtter Triton flere populære rammeverk ut av esken, inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT. Disse rammeverkene støttes gjennom Triton-backends, og i det sjeldne tilfellet at en backend ikke støtter brukstilfellet ditt, Triton lar deg implementere din egen og integrere den enkelt.

Følgende diagram viser et eksempel på NVIDIA Triton-arkitekturen.

NVIDIA Triton på SageMaker

SageMaker hosting tjenester er settet med SageMaker-funksjoner som tar sikte på å gjøre modelldistribusjon og visning enklere. Den gir en rekke alternativer for enkelt å distribuere, automatisk skalere, overvåke og optimalisere ML-modeller skreddersydd for ulike bruksområder. Dette betyr at du kan optimalisere distribusjonene dine for alle typer bruksmønstre, fra vedvarende og alltid tilgjengelige med serverløse alternativer, til forbigående, langvarige eller batch-inferensbehov.

Under SageMaker-vertsparaplyen er også settet med SageMaker inference Deep Learning Containers (DLC-er), som leveres ferdigpakket med passende modellserverprogramvare for deres tilsvarende støttede ML-rammeverk. Dette lar deg oppnå høy slutningsytelse uten modellserveroppsett, som ofte er det mest komplekse tekniske aspektet ved modelldistribusjon og generelt ikke er en del av en dataforskers ferdigheter. Triton-inferensserveren er nå tilgjengelig på SageMaker DLC-er.

Denne bredden av alternativer, modulariteten og brukervennligheten til forskjellige serveringsrammer gjør SageMaker og Triton til en kraftig match.

NVIDIA FIL-støtte for backend

Med 22.05 versjonsutgivelse av Triton, NVIDIA støtter nå skogmodeller trent av flere populære ML-rammeverk, inkludert XGBoost, LightGBM, Scikit-learn og cuML. Når du bruker FIL-backend for Triton, bør du sørge for at modellartefaktene du oppgir støttes. FIL støtter for eksempel model_type xgboost, xgboost_json, lightgbmeller treelite_checkpoint, som indikerer om den oppgitte modellen er i henholdsvis XGBoost binært format, XGBoost JSON-format, LightGBM-tekstformat eller Treelite binært format.

Denne backend-støtten er viktig for oss å bruke i vårt eksempel fordi FIL støtter XGBoost-modeller. Den eneste vurderingen å sjekke er å sikre at modellen vi distribuerer støtter binære eller JSON-formater.

I tillegg til å sikre at du har riktig modellformat, bør andre hensyn tas. FIL-backend for Triton gir konfigurerbare alternativer for utviklere for å justere arbeidsbelastningen og optimalisere modellkjøringsytelsen. Konfigurasjonen dynamic_batching lar Triton holde forespørsler på klientsiden og batch dem på serversiden, for effektivt å bruke FILs parallelle beregning for å slutte hele partiet sammen. Valget max_queue_delay_microseconds tilbyr en feilsikker kontroll over hvor lenge Triton venter med å danne en batch. FIL kommer med Shapley-forklaring, som kan aktiveres av konfigurasjonen treeshap_output; Du bør imidlertid huske på at Shapley-utganger skader ytelsen på grunn av utdatastørrelsen. Et annet viktig aspekt er storage_type for å bytte mellom minnefotavtrykk og kjøretid. For eksempel kan bruk av lagring som SPARSE redusere minneforbruket, mens DENSE kan redusere ytelsen til modellen din på bekostning av høyere minnebruk. Å bestemme det beste valget for hver av disse avhenger av arbeidsbelastningen og ventebudsjettet ditt, så vi anbefaler en dypere titt på alle alternativene i FIL backend FAQ og liste over konfigurasjoner tilgjengelig i FIL.

Fremgangsmåte for å være vert for en modell på triton

La oss se på brukssaken vår for svindeloppdagelse som et eksempel på hva du bør vurdere når du flytter en arbeidsmengde til Triton.

Identifiser arbeidsmengden din

I dette tilfellet har vi en modell for oppdagelse av svindel som brukes under betalingsprosessen til en detaljkunde. Inferensrørledningen bruker en XGBoost-algoritme med forbehandlingslogikk som inkluderer dataforberedelse for forbehandling.

Identifiser nåværende og målytelsesberegninger og andre mål som kan gjelde

Du kan oppleve at ende-til-ende-slutningstiden din tar for lang tid til å være akseptabel. Målet ditt kan være å gå fra titalls millisekunders ventetid til ensifret ventetid for samme volum av forespørsler og respektive gjennomstrømming. Du bestemmer at mesteparten av tiden forbrukes av dataforbehandling og XGBoost-modellen. Andre faktorer som nettverk og nyttelaststørrelse spiller en minimal rolle i overheaden knyttet til ende-til-ende-slutningstiden.

Arbeid bakover for å finne ut om Triton kan være vert for arbeidsmengden din basert på dine krav

For å finne ut om Triton kan oppfylle dine krav, vil du være oppmerksom på to hovedområder av bekymring. Den første er å sikre at Triton kan tjene med et akseptabelt grensesnittalternativ som HTTP eller C API.

Som nevnt tidligere, er det også viktig å finne ut om Triton støtter en backend som kan tjene artefaktene dine. Triton støtter en rekke backends som er skreddersydd for å støtte ulike rammeverk som PyTorch og TensorFlow. Kontroller at modellene dine støttes og at du har riktig modellformat som Triton forventer. For å gjøre dette, sjekk først for å se hvilke modellformater Triton-backend støtter. I mange tilfeller krever dette ingen endringer for modellen. I andre tilfeller kan modellen din kreve transformasjon til et annet format. Avhengig av kilden og målformatet finnes det ulike alternativer, for eksempel transformering av en Python pickle-fil for å bruke Treelites binære sjekkpunktformat.

For denne brukssaken bestemmer vi FIL-backend kan støtte XGBoost-modellen uten behov for endringer og at vi kan bruke Python-backend for forbehandlingen. Med ensemblefunksjonen til Triton kan du optimalisere arbeidsmengden ytterligere ved å unngå kostbare nettverkssamtaler mellom vertsinstanser.

Lag en plan og anslå innsatsen som kreves for å bruke Triton til hosting

La oss snakke om planen for å flytte modellene dine til Triton. Hver Triton-distribusjon krever følgende:

• Modellartefakter som kreves av Triton-backends
• Triton konfigurasjonsfiler
• En modelldepotmappe med riktig struktur

Vi viser et eksempel på hvordan du oppretter disse distribusjonsavhengighetene senere i dette innlegget.

Kjør planen og valider resultatene

Etter at du har opprettet de nødvendige filene og artefaktene i det riktig strukturerte modelllageret, må du justere distribusjonen og teste den for å bekrefte at du nå har nådd målberegningene dine.

På dette tidspunktet kan du bruke SageMaker Inference Recommender for å finne ut hvilken endepunktforekomsttype som er best for deg basert på dine krav. I tillegg tilbyr Triton verktøy for å gjøre byggeoptimaliseringer for å få bedre ytelse.

Gjennomføring

La oss nå se på implementeringsdetaljene. Til dette har vi utarbeidet to notatbøker som gir et eksempel på hva som kan forventes. De første notatbok viser opplæringen av den gitte XGBoost-modellen samt forbehandlingslogikken som brukes til både trening og slutningstid. De andre notatbok viser hvordan vi forbereder gjenstandene som trengs for utplassering på Triton.

Den første notatblokken viser en eksisterende notatbok organisasjonen din har som bruker RAPIDS pakke med biblioteker og RAPIDS Conda-kjernen. Denne forekomsten kjører på en G4DN-forekomsttype levert av AWS, som er GPU-akselerert ved å bruke NVIDIA T4-prosessorer.

Forbehandlingsoppgaver i dette eksemplet drar nytte av GPU-akselerasjon og bruker cuML- og cuDF-bibliotekene i stor grad. Et eksempel på dette er i følgende kode, hvor vi viser kategorisk etikettkoding ved bruk av cuML. Vi genererer også en label_encoders.pkl fil som vi kan bruke til å serialisere koderne og bruke dem til forhåndsbehandling under slutningstid.

Den første notatboken avsluttes med å trene vår XGBoost-modell og lagre artefaktene deretter.

I dette scenariet eksisterte treningskoden allerede og ingen endringer er nødvendige for modellen på treningstidspunktet. I tillegg, selv om vi brukte GPU-akselerasjon for forbehandling under trening, planlegger vi å bruke prosessorer for forbehandling på inferenstidspunkt. Vi forklarer mer senere i innlegget.

La oss nå gå videre til den andre bærbare og huske hva vi trenger for en vellykket Triton-distribusjon.

Først trenger vi modellartefaktene som kreves av backends. Filene vi må lage for dette ensemblet inkluderer:

• Forbehandler artefakter (model.py, label_encoders.pkl)
• XGBoost modellartefakter (xgboost.json)

Python-backend i Triton krever at vi bruker et Conda-miljø som en avhengighet. I dette tilfellet bruker vi Python-backend til å forhåndsbehandle rådataene før de mates inn i XGBoost-modellen som kjøres i FIL-backend. Selv om vi opprinnelig brukte RAPIDS cuDF- og cuML-biblioteker for å gjøre dataforbehandlingen (som referert tidligere ved å bruke vår GPU), bruker vi her Pandas og Scikit-learn som forbehandlingsavhengigheter for slutningstid (ved hjelp av vår CPU). Vi gjør dette av tre grunner:

• For å vise hvordan du lager et Conda-miljø for dine avhengigheter og hvordan du pakker det inn i forventet format av Tritons Python-backend.
• Ved å vise forbehandlingsmodellen som kjører i Python-backend på CPU-en mens XGBoost-modellen kjører på GPU i FIL-backend, illustrerer vi hvordan hver modell i Tritons ensemble-pipeline kan kjøre på en annen ramme-backend, og kjøre på forskjellig maskinvare med forskjellig konfigurasjoner.
• Den fremhever hvordan RAPIDS-bibliotekene (cuDF, cuML) er kompatible med CPU-motpartene (Pandas, Scikit-learn). På denne måten kan vi vise hvordan LabelEncoders opprettet i cuML kan brukes i Scikit-learn og omvendt. Merk at hvis du forventer å forhåndsbehandle store mengder tabelldata i løpet av inferenstiden, kan du fortsatt bruke RAPIDS til å GPU-akselerere det.

Husk at vi opprettet label_encoders.pkl fil i den første notatboken. Det er ikke noe mer å gjøre for kategorikoding annet enn å inkludere den i vår model.py fil for forhåndsbehandling.

For å lage model.py-filen som kreves av Triton Python-backend, følger vi formatering som kreves av backend og inkluderer vår Python-logikk for å behandle den innkommende tensoren og bruke etikettkoderen som er referert til tidligere. Du kan se gjennom fil brukes til forbehandling.

For XGBoost-modellen trenger ingenting mer å gjøres. Vi trente modellen i den første bærbare datamaskinen, og Tritons FIL-backend krever ingen ekstra innsats for XGBoost-modeller.

Deretter trenger vi Triton-konfigurasjonsfilene. Hver modell i Triton-ensemblet krever en config.pbtxt fil. I tillegg lager vi også en config.pbtxt fil for ensemblet som helhet. Disse filene lar Triton vite metadata om ensemblet med informasjon som innganger og utganger vi forventer, i tillegg til å hjelpe med å definere DAG knyttet til ensemblet.

Til slutt, for å distribuere en modell på Triton, trenger vi modelllagermappen vår for å ha riktig mappestruktur. Triton har spesifikke krav til modelllageroppsett. Innenfor modelllagerkatalogen på toppnivå har hver modell sin egen underkatalog som inneholder informasjonen for den tilsvarende modellen. Hver modellkatalog i Triton må ha minst én numerisk underkatalog som representerer en versjon av modellen. For vårt brukstilfelle bør den resulterende strukturen se ut som følgende.

Etter at vi har disse tre forutsetningene, lager vi en komprimert fil som pakke for distribusjon og laster den opp til Amazon enkel lagringstjeneste (Amazon S3).

Vi kan nå lage en SageMaker-modell fra modelllageret vi lastet opp til Amazon S3 i forrige trinn.

I dette trinnet gir vi også den ekstra miljøvariabelen SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, som spesifiserer navnet på modellen som skal lastes av Triton. Verdien av denne nøkkelen skal samsvare med mappenavnet i modellpakken lastet opp til Amazon S3. Denne variabelen er valgfri for en enkelt modell. Når det gjelder ensemblemodeller, må denne nøkkelen spesifiseres for at Triton skal starte opp i SageMaker.

I tillegg kan du stille inn SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT og SAGEMAKER_TRITON_THREAD_COUNT for å optimalisere trådantallet. Begge konfigurasjonsverdiene hjelper til med å justere antall tråder som kjører på CPU-ene dine, slik at du muligens kan få bedre utnyttelse ved å øke disse verdiene for CPUer med et større antall kjerner. I de fleste tilfeller fungerer standardverdiene ofte bra, men det kan være verdt å eksperimentere for å se om du kan oppnå ytterligere effektivitet for arbeidsbelastningene dine.

Med den foregående modellen lager vi en endepunktkonfigurasjon der vi kan spesifisere typen og antall forekomster vi ønsker i endepunktet.

Til slutt bruker vi den foregående endepunktkonfigurasjonen til å opprette et nytt SageMaker-endepunkt og venter på at distribusjonen skal fullføres. Status endres til InService etter at distribusjonen er vellykket.

Det er det! Endepunktet ditt er nå klart for testing og validering. På dette tidspunktet vil du kanskje bruke ulike verktøy for å optimalisere forekomsttypene og konfigurasjonen for å få best mulig ytelse. Følgende figur gir et eksempel på gevinstene som kan oppnås ved å bruke FIL-backend for en XGBoost-modell på Triton.

Oppsummering

I dette innlegget ledet vi deg gjennom distribusjon av en XGBoost-ensemble-arbeidsmengde til SageMaker med Triton Inference Server. Å flytte arbeidsbelastninger til Triton på SageMaker kan være en fordelaktig avkastning på investeringen. Som med all bruk av teknologi, er en vurderingsprosess og en plan nøkkelen, og vi har detaljert en fem-trinns prosess for å veilede deg gjennom hva du bør vurdere når du flytter arbeidsmengdene dine. I tillegg gikk vi dypt inn i trinnene som trengs for å distribuere et ensemble som bruker Python-forbehandling og en XGBoost-modell på Triton på SageMaker.

SageMaker gir verktøyene for å fjerne de udifferensierte tunge løftene fra hvert trinn i ML-livssyklusen, og letter dermed den raske eksperimenteringen og utforskningen som trengs for å optimalisere modelldistribusjonene dine. SageMaker-vertsstøtte for Triton Inference Server muliggjør arbeidsbelastninger med lav latens, høye transaksjoner per sekund (TPS).

Du kan finne notatbøkene som ble brukt for dette eksemplet på GitHub.

---

Om forfatteren

James Park er løsningsarkitekt hos Amazon Web Services. Han jobber med Amazon.com for å designe, bygge og distribuere teknologiløsninger på AWS, og har en spesiell interesse for AI og maskinlæring. På fritiden liker han å oppsøke nye kulturer, nye opplevelser og holde seg oppdatert med de nyeste teknologitrendene.

Jiahong Liu er løsningsarkitekt i Cloud Service Provider-teamet hos NVIDIA. Han hjelper klienter med å ta i bruk maskinlæring og AI-løsninger som utnytter NVIDIA-akselerert databehandling for å møte deres trenings- og slutningsutfordringer. På fritiden liker han origami, DIY-prosjekter og å spille basketball.

Kshitiz Gupta er løsningsarkitekt hos NVIDIA. Han liker å utdanne skykunder om GPU AI-teknologiene NVIDIA har å tilby og hjelpe dem med å akselerere maskinlærings- og dyplæringsapplikasjonene deres. Utenom jobben liker han å løpe, gå på fotturer og se på dyrelivet.

Bruno Aguiar de Melo er programvareutviklingsingeniør hos Amazon.com, hvor han hjelper vitenskapsteam med å bygge, distribuere og frigi ML-arbeidsbelastninger. Han er interessert i instrumentering og kontrollerbare aspekter innenfor ML-modellerings-/designfasen som må vurderes og måles med innsikten om at modellutførelsesytelse er like viktig som modellkvalitetsytelse, spesielt i brukstilfeller med begrenset ventetid. På fritiden liker han vin, brettspill og matlaging.

Eliuth Triana er en Developer Relations Manager hos NVIDIA. Han kobler Amazon- og AWS-produktledere, utviklere og forskere med NVIDIA-teknologer og produktledere for å akselerere Amazon ML/DL-arbeidsmengder, EC2-produkter og AWS AI-tjenester. I tillegg er Eliuth en lidenskapelig terrengsyklist, skiløper og pokerspiller.