Opnå hosting med lav latens til beslutningstræ-baserede ML-modeller på NVIDIA Triton Inference Server på Amazon SageMaker

Implementeringer af maskinlæringsmodeller (ML) kan have meget krævende krav til ydeevne og ventetid for virksomheder i dag. Brugssager som f.eks. opdagelse af svindel og annonceplacering er eksempler, hvor millisekunder betyder noget og er afgørende for virksomhedens succes. Strenge serviceniveauaftaler (SLA'er) skal opfyldes, og en typisk anmodning kan kræve flere trin, såsom forbehandling, datatransformation, modelvalgslogik, modelaggregering og efterbehandling. I stor skala betyder dette ofte, at man opretholder en enorm mængde trafik, mens man opretholder lav latenstid. Fælles designmønstre omfatter serielle inferenspipelines, ensembler (scatter-gather) og forretningslogiske arbejdsgange, som resulterer i at realisere hele forespørgslens arbejdsgang som en Directed Acyclic Graph (DAG). Men efterhånden som arbejdsgange bliver mere komplekse, kan dette føre til en stigning i de samlede svartider, hvilket igen kan påvirke slutbrugeroplevelsen negativt og bringe forretningsmål i fare. Triton kan løse disse brugssager, hvor flere modeller er sammensat i en pipeline med input- og outputtensorer forbundet mellem dem, hvilket hjælper dig med at håndtere disse arbejdsbelastninger.

Når du evaluerer dine mål i forhold til ML-modelslutning, kan mange muligheder overvejes, men få er så dygtige og beviste som Amazon SageMaker med Triton Inference Server. SageMaker med Triton Inference Server har været et populært valg for mange kunder, fordi det er specialbygget til at maksimere gennemløb og hardwareudnyttelse med ultralav (encifrede millisekunder) inferensforsinkelse. Det har en bred vifte af understøttede ML-frameworks (herunder TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, herunder NVIDIA GPU'er, CPU'er og AWS-inferens. Derudover er Triton Inference Server integreret med SageMaker, en fuldt administreret end-to-end ML-tjeneste, der giver mulighed for realtidsslutning til modelhosting.

I dette indlæg gennemgår vi implementeringen af ​​en arbejdsbelastning til SageMaker med Triton Inference Server.

Løsningsoversigt

Det er essentielt for ethvert projekt at have en liste over krav og et estimat af indsats for at tilnærme de samlede omkostninger ved projektet. Det er vigtigt at estimere investeringsafkastet (ROI), der understøtter en organisations beslutning. Nogle overvejelser, der skal tages i betragtning, når en arbejdsbyrde flyttes til Triton, omfatter:

Anstrengelsesestimering er nøglen i softwareudvikling, og dens måling er ofte baseret på ufuldstændige, usikre og støjende input. ML-arbejdsbelastninger er ikke anderledes. Flere faktorer vil påvirke en arkitektur for ML-inferens, hvoraf nogle omfatter:

• Kunde-side latensbudget – Den specificerer den maksimale acceptable ventetid på klientsiden tur-retur på et slutningssvar, almindeligvis udtrykt i percentiler. For arbejdsbelastninger, der kræver et forsinkelsesbudget tæt på titusvis af millisekunder, kan netværksoverførsler blive dyre, så brug af modeller ved kanten ville passe bedre.
• Data nyttelast distribution størrelse – Nyttelast, ofte omtalt som beskedtekst, er anmodningsdataene, der er transmitteret fra klienten til modellen, såvel som svardataene, der overføres fra modellen til klienten. Nyttelaststørrelsen har ofte stor indflydelse på latens og bør tages i betragtning.
• Dataformat – Dette angiver, hvordan nyttelasten sendes til ML-modellen. Formater kan læses af mennesker, såsom JSON og CSV, men der er også binære formater, som ofte er komprimerede og mindre i størrelse. Dette er en afvejning mellem komprimeringsoverhead og overførselsstørrelse, hvilket betyder, at CPU-cyklusser og latens tilføjes for at komprimere eller dekomprimere for at spare bytes, der overføres over netværket. Dette indlæg viser, hvordan man bruger både JSON og binære formater.
• Softwarestak og komponenter påkrævet – En stak er en samling af komponenter, der fungerer sammen for at understøtte en ML-applikation, inklusive operativsystem, runtimes og softwarelag. Triton kommer med indbyggede populære ML frameworks, kaldet backends, såsom ONNX, TensorFlow, FIL, OpenVINO, native Python og andre. Du kan også forfatter en tilpasset backend til dine egne hjemmedyrkede komponenter. Dette indlæg går over en XGBoost-model og dataforbehandling, som vi migrerer til henholdsvis de NVIDIA-leverede FIL- og Python Triton-backends.

Alle disse faktorer bør spille en afgørende rolle i evalueringen af, hvordan dine arbejdsbelastninger præsterer, men i dette tilfælde fokuserer vi på det arbejde, der er nødvendigt for at flytte dine ML-modeller til at blive hostet i SageMaker med Triton Inference Server. Specifikt bruger vi et eksempel på et svindeldetekteringsensemble sammensat af en XGBoost-model med forbehandlingslogik skrevet i Python.

NVIDIA Triton Inference Server

Triton Inference Server er designet fra bunden for at gøre det muligt for teams at implementere, køre og skalere trænede AI-modeller fra enhver ramme på GPU- eller CPU-baseret infrastruktur. Derudover er den blevet optimeret til at tilbyde højtydende inferens i skala med funktioner som dynamisk batching, samtidige kørsler, optimal modelkonfiguration, modelensemble og understøttelse af streaming-input.

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

Arbejdsbelastninger bør tage højde for de muligheder, som Triton leverer sammen med SageMaker-hosting for at maksimere de tilbudte fordele. For eksempel understøtter Triton HTTP såvel som en C API, som giver mulighed for fleksibilitet samt optimering af nyttelast, når det er nødvendigt. Som tidligere nævnt understøtter Triton flere populære rammer ud af boksen, herunder TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT. Disse rammer understøttes gennem Triton-backends, og i det sjældne tilfælde, at en backend ikke understøtter din use case, Triton giver dig mulighed for at implementere din egen og nemt integrere den.

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

NVIDIA Triton på SageMaker

SageMaker hosting tjenester er et sæt af SageMaker-funktioner, der har til formål at gøre modelimplementering og betjening lettere. Det giver en række muligheder for nemt at implementere, automatisk skalere, overvåge og optimere ML-modeller, der er skræddersyet til forskellige anvendelsestilfælde. Dette betyder, at du kan optimere dine udrulninger til alle typer brugsmønstre, fra vedvarende og altid tilgængelige med serverløse muligheder, til forbigående, langvarige eller batch-inferensbehov.

Under SageMaker hosting-paraplyen er også sættet af SageMaker inference Deep Learning Containers (DLC'er), som leveres færdigpakket med den passende model serversoftware til deres tilsvarende understøttede ML-ramme. Dette giver dig mulighed for at opnå høj slutningsydelse uden modelserveropsætning, hvilket ofte er det mest komplekse tekniske aspekt af modelimplementering og generelt ikke er en del af en dataforskers færdigheder. Triton-inferensserveren er nu til rådighed på SageMaker DLC'er.

Denne bredde af muligheder, modularitet og brugervenlighed af forskellige serveringsrammer gør SageMaker og Triton til et stærkt match.

NVIDIA FIL-backend-understøttelse

Med 22.05 version udgivelse af Triton, NVIDIA understøtter nu skovmodeller trænet af flere populære ML-frameworks, herunder XGBoost, LightGBM, Scikit-learn og cuML. Når du bruger FIL-backend til Triton, skal du sikre dig, at de modelartefakter, du angiver, understøttes. FIL understøtter f.eks model_type xgboost, xgboost_json, lightgbm eller treelite_checkpoint, der angiver, om den leverede model er i henholdsvis XGBoost binært format, XGBoost JSON-format, LightGBM-tekstformat eller Treelite binært format.

Denne backend-understøttelse er vigtig for os at bruge i vores eksempel, fordi FIL understøtter XGBoost-modeller. Den eneste overvejelse at kontrollere er at sikre, at den model, vi implementerer, understøtter binære eller JSON-formater.

Ud over at sikre, at du har det rigtige modelformat, bør andre overvejelser tages. FIL-backend til Triton giver udviklere konfigurerbare muligheder for at justere deres arbejdsbelastninger og optimere modelkørselsydelsen. Konfigurationen dynamic_batching tillader Triton at holde klient-side anmodninger og batch dem på serversiden, for effektivt at bruge FIL's parallelle beregninger til at udlede hele batchen sammen. Muligheden max_queue_delay_microseconds tilbyder en fejlsikker kontrol over, hvor længe Triton venter på at danne en batch. FIL leveres med Shapley-forklaring, som kan aktiveres af konfigurationen treeshap_output; Du skal dog huske på, at Shapley-output skader ydeevnen på grund af dens outputstørrelse. Et andet vigtigt aspekt er storage_type for at afveje mellem memory footprint og runtime. For eksempel kan brug af storage som SPARSE reducere hukommelsesforbruget, hvorimod DENSE kan reducere din modelkørsels ydeevne på bekostning af højere hukommelsesforbrug. Beslutningen om det bedste valg for hver af disse afhænger af din arbejdsbyrde og dit latensbudget, så vi anbefaler et dybere kig på alle muligheder i FIL backend FAQ og liste over tilgængelige konfigurationer i FIL.

Trin til at være vært for en model på triton

Lad os se på vores tilfælde af svindeldetektion som et eksempel på, hvad du skal overveje, når du flytter en arbejdsbyrde til Triton.

Identificer din arbejdsbyrde

I dette tilfælde har vi en model for opdagelse af bedrageri, der bruges under en detailkundes betalingsproces. Inferenspipelinen bruger en XGBoost-algoritme med forbehandlingslogik, der inkluderer dataforberedelse til forbehandling.

Identificer aktuelle og målpræstationsmålinger og andre mål, der kan være relevante

Du kan opleve, at din ende-til-ende-slutningstid tager for lang tid til at være acceptabel. Dit mål kunne være at gå fra titusvis af millisekunders latency til encifret latency for den samme mængde anmodninger og respektive gennemløb. Du bestemmer, at størstedelen af ​​tiden forbruges af dataforbehandling og XGBoost-modellen. Andre faktorer såsom netværk og nyttelaststørrelse spiller en minimal rolle i den overhead, der er forbundet med end-to-end-slutningstiden.

Arbejd baglæns for at afgøre, om Triton kan være vært for din arbejdsbyrde baseret på dine krav

For at afgøre, om Triton kan opfylde dine krav, vil du være opmærksom på to hovedområder af bekymring. Den første er at sikre, at Triton kan tjene med en acceptabel frontend-mulighed såsom HTTP eller C API.

Som tidligere nævnt er det også vigtigt at afgøre, om Triton understøtter en backend, der kan tjene dine artefakter. Triton understøtter en række backends der er skræddersyet til at understøtte forskellige rammer som PyTorch og TensorFlow. Kontroller, at dine modeller understøttes, og at du har det korrekte modelformat, som Triton forventer. For at gøre dette skal du først kontrollere, hvilke modelformater Triton-backend understøtter. I mange tilfælde kræver dette ingen ændringer for modellen. I andre tilfælde kan din model kræve transformation til et andet format. Afhængigt af kilden og målformatet findes der forskellige muligheder, såsom at transformere en Python pickle-fil for at bruge Treelites binære kontrolpunktformat.

For denne brugssituation bestemmer vi FIL-backend kan understøtte XGBoost-modellen uden behov for ændringer, og at vi kan bruge Python backend til forbehandlingen. Med ensemblefunktionen i Triton kan du optimere din arbejdsbyrde yderligere ved at undgå dyre netværksopkald mellem hostingforekomster.

Lav en plan og anslå den indsats, der kræves for at bruge Triton til hosting

Lad os tale om planen om at flytte dine modeller til Triton. Hver Triton-implementering kræver følgende:

• Modelartefakter krævet af Triton-backends
• Triton konfigurationsfiler
• En modelopbevaringsmappe med den rette struktur

Vi viser et eksempel på, hvordan man opretter disse implementeringsafhængigheder senere i dette indlæg.

Kør planen og valider resultaterne

Når du har oprettet de nødvendige filer og artefakter i det korrekt strukturerede modellager, skal du justere din implementering og teste den for at validere, at du nu har nået dine målmålinger.

På dette tidspunkt kan du bruge SageMaker Inference Recommend for at bestemme, hvilken type slutpunktforekomst der er bedst for dig baseret på dine krav. Derudover leverer Triton værktøjer til at lave build-optimeringer for at få bedre ydeevne.

Implementering

Lad os nu se på implementeringsdetaljerne. Til dette har vi udarbejdet to notesbøger, der giver et eksempel på, hvad der kan forventes. Det første notesbog viser træningen af ​​den givne XGBoost-model samt den forbehandlingslogik, der bruges til både træning og slutningstid. Det anden notesbog viser, hvordan vi forbereder de nødvendige artefakter til udrulning på Triton.

Den første notesbog viser en eksisterende notesbog, som din organisation har, som bruger HURTIGE suite af biblioteker og RAPIDS Conda-kernen. Denne instans kører på en G4DN-instanstype leveret af AWS, som er GPU-accelereret ved at bruge NVIDIA T4-processorer.

Forbehandlingsopgaver i dette eksempel drager fordel af GPU-acceleration og bruger i høj grad cuML- og cuDF-bibliotekerne. Et eksempel på dette er i den følgende kode, hvor vi viser kategorisk etiketkodning ved hjælp af cuML. Vi genererer også en label_encoders.pkl fil, som vi kan bruge til at serialisere indkoderne og bruge dem til forbehandling i inferenstiden.

Den første notesbog afsluttes med at træne vores XGBoost-model og gemme artefakterne i overensstemmelse hermed.

I dette scenarie eksisterede træningskoden allerede, og der kræves ingen ændringer for modellen på træningstidspunktet. Derudover, selvom vi brugte GPU-acceleration til forbehandling under træning, planlægger vi at bruge CPU'er til forbehandling på inferenstidspunkt. Vi forklarer mere senere i indlægget.

Lad os nu gå videre til den anden notesbog og huske, hvad vi har brug for til en vellykket Triton-implementering.

For det første har vi brug for de modelartefakter, der kræves af backends. Filerne, som vi skal oprette til dette ensemble inkluderer:

• Forbehandling af artefakter (model.py, label_encoders.pkl)
• XGBoost model artefakter (xgboost.json)

Python-backend i Triton kræver, at vi bruger et Conda-miljø som en afhængighed. I dette tilfælde bruger vi Python-backend'en til at forbehandle de rå data, før de føres ind i XGBoost-modellen, der køres i FIL-backend. Selvom vi oprindeligt brugte RAPIDS cuDF- og cuML-biblioteker til at udføre dataforbehandlingen (som nævnt tidligere ved hjælp af vores GPU), bruger vi her Pandas og Scikit-learn som forbehandlingsafhængigheder for inferenstid (ved hjælp af vores CPU). Det gør vi af tre grunde:

• For at vise, hvordan du opretter et Conda-miljø til dine afhængigheder, og hvordan du pakker det i format forventet af Tritons Python-backend.
• Ved at vise forbehandlingsmodellen, der kører i Python-backend på CPU'en, mens XGBoost-modellen kører på GPU'en i FIL-backend, illustrerer vi, hvordan hver model i Tritons ensemble-pipeline kan køre på en anden framework-backend og køre på forskellig hardware med forskellig konfigurationer.
• Det fremhæver, hvordan RAPIDS-bibliotekerne (cuDF, cuML) er kompatible med deres CPU-modstykker (Pandas, Scikit-learn). På denne måde kan vi vise hvordan LabelEncoders oprettet i cuML kan bruges i Scikit-learn og omvendt. Bemærk, at hvis du forventer at forbehandle store mængder tabeldata under inferenstiden, kan du stadig bruge RAPIDS til at GPU-accelerere det.

Husk, at vi skabte label_encoders.pkl fil i den første notesbog. Der er ikke andet at gøre for kategorikodning end at inkludere det i vores model.py fil til forbehandling.

For at oprette den model.py-fil, der kræves af Triton Python-backend, overholder vi formatering påkrævet af backend og inkludere vores Python-logik til at behandle den indkommende tensor og bruge den tidligere omtalte etiketkoder. Du kan gennemgå fil bruges til forbehandling.

For XGBoost-modellen skal der ikke gøres mere. Vi trænede modellen i den første notebook, og Tritons FIL-backend kræver ingen ekstra indsats for XGBoost-modeller.

Dernæst skal vi bruge Triton-konfigurationsfilerne. Hver model i Triton-ensemblet kræver en config.pbtxt fil. Derudover laver vi også en config.pbtxt fil for ensemblet som helhed. Disse filer giver Triton mulighed for at kende metadata om ensemblet med information såsom de input og output, vi forventer, samt hjælper med at definere den DAG, der er knyttet til ensemblet.

Til sidst, for at implementere en model på Triton, har vi brug for vores model repository mappe for at have den korrekte mappestruktur. Triton har specifikke krav til modellagerlayout. I top-niveau model repository bibliotek har hver model sin egen undermappe, der indeholder oplysningerne for den tilsvarende model. Hver modelmappe i Triton skal have mindst én numerisk undermappe, der repræsenterer en version af modellen. Til vores brugstilfælde skulle den resulterende struktur se ud som følgende.

Når vi har disse tre forudsætninger, opretter vi en komprimeret fil som pakke til implementering og uploader den til Amazon Simple Storage Service (Amazon S3).

Vi kan nu oprette en SageMaker-model fra det modellager, vi uploadede til Amazon S3 i det forrige trin.

I dette trin leverer vi også den ekstra miljøvariabel SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, som angiver navnet på den model, der skal indlæses af Triton. Værdien af ​​denne nøgle skal svare til mappenavnet i modelpakken, der er uploadet til Amazon S3. Denne variabel er valgfri i tilfælde af en enkelt model. I tilfælde af ensemblemodeller skal denne nøgle angives for at Triton kan starte op i SageMaker.

Derudover kan du indstille SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT og SAGEMAKER_TRITON_THREAD_COUNT til optimering af trådantal. Begge konfigurationsværdier hjælper med at justere antallet af tråde, der kører på dine CPU'er, så du muligvis kan opnå bedre udnyttelse ved at øge disse værdier for CPU'er med et større antal kerner. I de fleste tilfælde fungerer standardværdierne ofte godt, men det kan være værd at eksperimentere og se, om der kan opnås yderligere effektivitet for dine arbejdsbelastninger.

Med den foregående model opretter vi en endepunktskonfiguration, hvor vi kan angive typen og antallet af instanser, vi ønsker i endepunktet.

Til sidst bruger vi den foregående slutpunktskonfiguration til at oprette et nyt SageMaker-slutpunkt og venter på, at implementeringen er færdig. Status ændres til InService efter implementeringen er vellykket.

Det er det! Dit endepunkt er nu klar til test og validering. På dette tidspunkt vil du måske bruge forskellige værktøjer til at hjælpe med at optimere dine instanstyper og konfiguration for at få den bedst mulige ydeevne. Følgende figur giver et eksempel på de gevinster, der kan opnås ved at bruge FIL-backend til en XGBoost-model på Triton.

Resumé

I dette indlæg ledte vi dig gennem implementeringen af ​​en XGBoost-ensemble-arbejdsbelastning til SageMaker med Triton Inference Server. At flytte arbejdsbelastninger til Triton på SageMaker kan være et gavnligt investeringsafkast. Som med enhver vedtagelse af teknologi er en vurderingsproces og -plan nøglen, og vi detaljerede en fem-trins proces for at guide dig gennem, hvad du skal overveje, når du flytter dine arbejdsbyrder. Derudover dykkede vi dybt ned i de nødvendige trin for at implementere et ensemble, der bruger Python-forbehandling og en XGBoost-model på Triton på SageMaker.

SageMaker leverer værktøjerne til at fjerne de udifferentierede tunge løft fra hver fase af ML-livscyklussen og letter derved den hurtige eksperimentering og udforskning, der er nødvendig for fuldt ud at optimere dine modelimplementeringer. SageMaker-hostingunderstøttelse af Triton Inference Server muliggør arbejdsbelastninger med lav latens, høje transaktioner pr. sekund (TPS).

Du kan finde de notesbøger, der er brugt til dette eksempel på GitHub.

---

Om forfatteren

James Park er Solutions Architect hos Amazon Web Services. Han arbejder sammen med Amazon.com om at designe, bygge og implementere teknologiløsninger på AWS og har en særlig interesse for kunstig intelligens og maskinlæring. I sin fritid nyder han at opsøge nye kulturer, nye oplevelser og holde sig ajour med de nyeste teknologitrends.

Jiahong Liu er løsningsarkitekt på Cloud Service Provider-teamet hos NVIDIA. Han hjælper kunder med at anvende machine learning og AI-løsninger, der udnytter NVIDIA accelereret computing til at løse deres trænings- og inferensudfordringer. I sin fritid nyder han origami, gør-det-selv-projekter og at spille basketball.

Kshitiz Gupta er Solutions Architect hos NVIDIA. Han nyder at uddanne cloud-kunder om de GPU AI-teknologier, NVIDIA har at tilbyde, og at hjælpe dem med at accelerere deres maskinlærings- og deep learning-applikationer. Uden for arbejdet nyder han at løbe, vandre og se på dyrelivet.

Bruno Aguiar de Melo er softwareudviklingsingeniør hos Amazon.com, hvor han hjælper videnskabsteams med at opbygge, implementere og frigive ML-arbejdsbelastninger. Han er interesseret i instrumentering og kontrollerbare aspekter inden for ML-modellerings-/designfasen, der skal overvejes og måles med den indsigt, at modeludførelsesydelse er lige så vigtig som modelkvalitetsydelse, især i latency-begrænsede use cases. I sin fritid nyder han vin, brætspil og madlavning.

Eliuth Triana er en Developer Relations Manager hos NVIDIA. Han forbinder Amazon- og AWS-produktledere, udviklere og videnskabsmænd med NVIDIA-teknologer og produktledere for at accelerere Amazon ML/DL-arbejdsbelastninger, EC2-produkter og AWS AI-tjenester. Derudover er Eliuth en passioneret mountainbiker, skiløber og pokerspiller.