Uppnå värd med låg latens för beslutsträdbaserade ML-modeller på NVIDIA Triton Inference Server på Amazon SageMaker

Implementeringar av modeller för maskininlärning (ML) kan ha mycket krävande prestanda- och latenskrav för företag idag. Användningsfall som bedrägeriupptäckt och annonsplacering är exempel där millisekunder är viktiga och avgörande för affärsframgång. Strikta servicenivåavtal (SLA) måste uppfyllas och en typisk begäran kan kräva flera steg som förbearbetning, datatransformation, modellvalslogik, modellaggregering och efterbearbetning. I stor skala innebär detta ofta att man upprätthåller en enorm trafikvolym samtidigt som man bibehåller låg latens. Vanliga designmönster inkluderar seriella slutledningspipelines, ensembler (scatter-gather) och affärslogiska arbetsflöden, vilket resulterar i att hela arbetsflödet för begäran realiseras som en Directed Acyclic Graph (DAG). Men eftersom arbetsflöden blir mer komplexa kan detta leda till en ökning av de totala svarstiderna, vilket i sin tur kan påverka slutanvändarens upplevelse negativt och äventyra affärsmålen. Triton kan hantera dessa användningsfall där flera modeller är sammansatta i en pipeline med ingångs- och utgångstensorer kopplade mellan dem, vilket hjälper dig att hantera dessa arbetsbelastningar.

När du utvärderar dina mål i förhållande till ML-modellslutledning kan många alternativ övervägas, men få är så kapabla och beprövade som Amazon SageMaker med Triton Inference Server. SageMaker med Triton Inference Server har varit ett populärt val för många kunder eftersom den är specialbyggd för att maximera genomströmning och hårdvaruanvändning med ultralåg (ensiffriga millisekunder) slutledningslatens. Den har ett brett utbud av stödda ML-ramverk (inklusive TensorFlow, PyTorch, ONNX, XGBoost och NVIDIA TensorRT) och infrastrukturbackends, inklusive NVIDIA GPU:er, CPU:er och AWS slutledning. Dessutom är Triton Inference Server integrerad med SageMaker, en fullständigt hanterad end-to-end ML-tjänst, som tillhandahåller realtidsinferensalternativ för modellvärd.

I det här inlägget går vi igenom hur vi distribuerar en arbetsbelastning för bedrägeriupptäckande ensemble till SageMaker med Triton Inference Server.

Lösningsöversikt

Det är viktigt för alla projekt att ha en lista med krav och en ansträngningsuppskattning för att kunna uppskatta den totala kostnaden för projektet. Det är viktigt att uppskatta avkastningen på investeringen (ROI) som stöder beslutet i en organisation. Några överväganden att ta hänsyn till när en arbetsbörda flyttas till Triton inkluderar:

Ansträngningsuppskattning är nyckeln i mjukvaruutveckling, och dess mätning baseras ofta på ofullständiga, osäkra och bullriga indata. ML-arbetsbelastningar är inte annorlunda. Flera faktorer kommer att påverka en arkitektur för ML-inferens, varav några inkluderar:

• Fördröjningsbudget på klientsidan – Den anger den maximala acceptabla väntetiden på klientsidan tur och retur för ett slutledningssvar, vanligtvis uttryckt i percentiler. För arbetsbelastningar som kräver en latensbudget nära tiotals millisekunder, kan nätverksöverföringar bli dyra, så att använda modeller vid kanten skulle passa bättre.
• Data nyttolast distributionsstorlek – Nyttolast, ofta kallad meddelandetext, är förfrågningsdata som överförs från klienten till modellen, såväl som svarsdata som överförs från modellen till klienten. Nyttolaststorleken har ofta stor inverkan på latensen och bör tas i beaktande.
• Dataformat – Detta anger hur nyttolasten skickas till ML-modellen. Format kan vara läsbart för människor, såsom JSON och CSV, men det finns även binära format, som ofta är komprimerade och mindre i storlek. Detta är en kompromiss mellan komprimeringsoverhead och överföringsstorlek, vilket innebär att CPU-cykler och latens läggs till för att komprimera eller dekomprimera, för att spara byte som överförs över nätverket. Det här inlägget visar hur man använder både JSON och binära format.
• Mjukvarustack och komponenter krävs – En stack är en samling komponenter som fungerar tillsammans för att stödja en ML-applikation, inklusive operativsystem, körtider och mjukvarulager. Triton kommer med inbyggda populära ML-ramverk, kallade backends, såsom ONNX, TensorFlow, FIL, OpenVINO, native Python och andra. Du kan också skriva en anpassad backend för dina egna hemodlade komponenter. Det här inlägget går över en XGBoost-modell och dataförbehandling, som vi migrerar till NVIDIA-försedda FIL- respektive Python Triton-backends.

Alla dessa faktorer bör spela en viktig roll för att utvärdera hur dina arbetsbelastningar presterar, men i det här användningsfallet fokuserar vi på det arbete som behövs för att flytta dina ML-modeller till SageMaker med Triton Inference Server. Specifikt använder vi ett exempel på en bedrägeriupptäckningsensemble som består av en XGBoost-modell med förbearbetningslogik skriven i Python.

NVIDIA Triton Inference Server

Triton Inference Server har designats från grunden för att göra det möjligt för team att distribuera, köra och skala utbildade AI-modeller från vilket ramverk som helst på GPU- eller CPU-baserad infrastruktur. Dessutom har den optimerats för att erbjuda högpresterande slutledning i skala med funktioner som dynamisk batchning, samtidiga körningar, optimal modellkonfiguration, modellensemble och stöd för streaming-ingångar.

Följande diagram visar ett exempel på en NVIDIA Triton-ensemblepipeline.

Arbetsbelastningar bör ta hänsyn till de möjligheter som Triton tillhandahåller tillsammans med SageMaker-värd för att maximera fördelarna som erbjuds. Till exempel stöder Triton HTTP såväl som en C API, som möjliggör flexibilitet samt optimering av nyttolast vid behov. Som tidigare nämnts stöder Triton flera populära ramverk direkt, inklusive TensorFlow, PyTorch, ONNX, XGBoost och NVIDIA TensorRT. Dessa ramverk stöds av Tritons backends, och i det sällsynta fall att en backend inte stöder ditt användningsfall, Triton låter dig implementera din egen och enkelt integrera den.

Följande diagram visar ett exempel på NVIDIA Triton-arkitekturen.

NVIDIA Triton på SageMaker

SageMaker-värd tjänster är en uppsättning SageMaker-funktioner som syftar till att göra modelldistribution och betjäning enklare. Det ger en mängd olika alternativ för att enkelt distribuera, automatiskt skala, övervaka och optimera ML-modeller som är skräddarsydda för olika användningsfall. Detta innebär att du kan optimera dina distributioner för alla typer av användningsmönster, från beständiga och alltid tillgängliga med serverlösa alternativ till övergående, långvariga eller batch slutledningsbehov.

Under SageMakers värdparaply finns också uppsättningen SageMaker inference Deep Learning Containers (DLC), som kommer förpackade med lämplig modell av servermjukvara för deras motsvarande stödda ML-ramverk. Detta gör att du kan uppnå hög slutledningsprestanda utan modellserverinstallation, vilket ofta är den mest komplexa tekniska aspekten av modelldistribution och i allmänhet inte är en del av en datavetares kompetensuppsättning. Triton inferensserver är nu tillgänglig på SageMaker DLC:er.

Denna bredd av alternativ, modularitet och användarvänlighet för olika serveringsramverk gör SageMaker och Triton till en kraftfull matchning.

NVIDIA FIL backend-stöd

Med 22.05 version version av Triton, NVIDIA stöder nu skogsmodeller som tränats av flera populära ML-ramverk, inklusive XGBoost, LightGBM, Scikit-learn och cuML. När du använder FIL-backend för Triton bör du se till att modellartefakterna som du tillhandahåller stöds. Till exempel stöder FIL model_type xgboost, xgboost_json, lightgbm, eller treelite_checkpoint, som indikerar om den tillhandahållna modellen är i binärt XGBoost-format, XGBoost JSON-format, LightGBM-textformat respektive Treelite-binärt format.

Detta backend-stöd är viktigt för oss att använda i vårt exempel eftersom FIL stöder XGBoost-modeller. Det enda man bör kontrollera är att se till att modellen som vi distribuerar stöder binära eller JSON-format.

Förutom att se till att du har rätt modellformat bör andra hänsyn tas. FIL-backend för Triton ger konfigurerbara alternativ för utvecklare att justera sina arbetsbelastningar och optimera modellkörningsprestanda. Konfigurationen dynamic_batching tillåter Triton att hålla förfrågningar på klientsidan och batcha dem på serversidan, för att effektivt kunna använda FIL:s parallella beräkningar för att sluta sig till hela batchen tillsammans. Alternativet max_queue_delay_microseconds erbjuder en felsäker kontroll av hur länge Triton väntar på att bilda en batch. FIL kommer med Shapley-förklaring, som kan aktiveras av konfigurationen treeshap_output; Du bör dock komma ihåg att Shapley-utgångar skadar prestandan på grund av dess utdatastorlek. En annan viktig aspekt är storage_type för att kompromissa mellan minnesfotavtryck och körtid. Att till exempel använda lagring som SPARSE kan minska minnesförbrukningen, medan DENSE kan minska din modellkörningsprestanda på bekostnad av högre minnesanvändning. Att bestämma det bästa valet för var och en av dessa beror på din arbetsbelastning och din latensbudget, så vi rekommenderar en djupare titt på alla alternativ i FIL backend FAQ och lista över tillgängliga konfigurationer i FIL.

Steg för att vara värd för en modell på triton

Låt oss titta på vårt användningsfall för upptäckt av bedrägeri som ett exempel på vad man bör tänka på när man flyttar en arbetsbörda till Triton.

Identifiera din arbetsbelastning

I det här användningsfallet har vi en modell för att upptäcka bedrägerier som används under en detaljkunds kassaprocess. Slutledningspipelinen använder en XGBoost-algoritm med förbearbetningslogik som inkluderar dataförberedelse för förbearbetning.

Identifiera aktuella och målprestandamått och andra mål som kan gälla

Du kanske upptäcker att din slutledningstid tar för lång tid för att vara acceptabel. Ditt mål kan vara att gå från tiotals millisekunders latens till ensiffrig latens för samma volym av förfrågningar och respektive genomströmning. Du bestämmer att huvuddelen av tiden förbrukas av dataförbearbetning och XGBoost-modellen. Andra faktorer som nätverk och nyttolaststorlek spelar en minimal roll i den omkostnad som är förknippad med slutledningstiden från slut till ände.

Arbeta bakåt för att avgöra om Triton kan vara värd för din arbetsbelastning baserat på dina krav

För att avgöra om Triton kan uppfylla dina krav, vill du uppmärksamma två huvudsakliga problemområden. Det första är att säkerställa att Triton kan fungera med ett acceptabelt gränssnittsalternativ som HTTP eller C API.

Som nämnts tidigare är det också viktigt att avgöra om Triton stöder en backend som kan tjäna dina artefakter. Triton stöder ett antal backends som är skräddarsydda för att stödja olika ramverk som PyTorch och TensorFlow. Kontrollera att dina modeller stöds och att du har rätt modellformat som Triton förväntar sig. För att göra detta, kontrollera först för att se vilka modellformat som Tritons backend stöder. I många fall kräver detta inga ändringar för modellen. I andra fall kan din modell kräva omvandling till ett annat format. Beroende på källan och målformatet finns det olika alternativ, som att transformera en Python pickle-fil för att använda Treelites binära kontrollpunktsformat.

För detta användningsfall bestämmer vi FIL backend kan stödja XGBoost-modellen utan att några ändringar behövs och att vi kan använda Python-backend för förbearbetningen. Med ensemblefunktionen i Triton kan du optimera din arbetsbelastning ytterligare genom att undvika kostsamma nätverkssamtal mellan värdinstanser.

Skapa en plan och uppskatta den ansträngning som krävs för att använda Triton som värd

Låt oss prata om planen att flytta dina modeller till Triton. Varje Triton-distribution kräver följande:

• Modellartefakter som krävs av Tritons backends
• Triton konfigurationsfiler
• En modellförrådsmapp med rätt struktur

Vi visar ett exempel på hur man skapar dessa distributionsberoenden senare i det här inlägget.

Kör planen och validera resultaten

När du har skapat de nödvändiga filerna och artefakterna i det korrekt strukturerade modellförrådet måste du justera din distribution och testa den för att verifiera att du nu har nått dina målvärden.

Vid det här laget kan du använda SageMaker Inference Recommender för att avgöra vilken typ av slutpunktsinstans som är bäst för dig baserat på dina krav. Dessutom tillhandahåller Triton verktyg för att göra byggnadsoptimeringar för att få bättre prestanda.

Genomförande

Låt oss nu titta på implementeringsdetaljerna. För detta har vi förberett två anteckningsböcker som ger ett exempel på vad som kan förväntas. De första anteckningsboken visar träningen av den givna XGBoost-modellen samt den förbearbetningslogik som används för både träning och slutledningstid. De andra anteckningsboken visar hur vi förbereder de artefakter som behövs för utplacering på Triton.

Den första anteckningsboken visar en befintlig anteckningsbok som din organisation har som använder FORS svit med bibliotek och RAPIDS Conda-kärnan. Den här instansen körs på en G4DN-instans som tillhandahålls av AWS, som är GPU-accelererad genom att använda NVIDIA T4-processorer.

Förbearbetningsuppgifter i det här exemplet drar nytta av GPU-acceleration och använder cuML- och cuDF-biblioteken mycket. Ett exempel på detta är i följande kod, där vi visar kategorisk etikettkodning med cuML. Vi genererar också en label_encoders.pkl fil som vi kan använda för att serialisera kodarna och använda dem för förbearbetning under slutledningstid.

Den första anteckningsboken avslutas med att träna vår XGBoost-modell och spara artefakterna därefter.

I det här scenariot fanns träningskoden redan och inga ändringar behövs för modellen vid träningstillfället. Dessutom, även om vi använde GPU-acceleration för förbearbetning under träning, planerar vi att använda processorer för förbearbetning vid slutledningstidpunkt. Vi förklarar mer senare i inlägget.

Låt oss nu gå vidare till den andra anteckningsboken och komma ihåg vad vi behöver för en framgångsrik Triton-distribution.

Först behöver vi modellartefakterna som krävs av backends. Filerna som vi behöver skapa för denna ensemble inkluderar:

• Förbearbetning av artefakter (model.py, label_encoders.pkl)
• XGBoost modellartefakter (xgboost.json)

Python-backend i Triton kräver att vi använder en Conda-miljö som ett beroende. I det här fallet använder vi Python-backend för att förbehandla rådata innan den matas in i XGBoost-modellen som körs i FIL-backend. Även om vi ursprungligen använde RAPIDS cuDF- och cuML-bibliotek för att göra dataförbearbetningen (som hänvisades till tidigare med vår GPU), använder vi här Pandas och Scikit-learn som förbearbetningsberoenden för slutledningstid (med vår CPU). Vi gör detta av tre anledningar:

• För att visa hur du skapar en Conda-miljö för dina beroenden och hur du paketerar den i format förväntat av Tritons Python-backend.
• Genom att visa förbearbetningsmodellen som körs i Python-backend på CPU medan XGBoost-modellen körs på GPU i FIL-backend, illustrerar vi hur varje modell i Tritons ensemblepipeline kan köras på en annan ramverksbackend, och köras på olika hårdvara med olika konfigurationer.
• Det belyser hur RAPIDS-biblioteken (cuDF, cuML) är kompatibla med sina CPU-motsvarigheter (Pandas, Scikit-learn). På så sätt kan vi visa hur LabelEncoders skapad i cuML kan användas i Scikit-learn och vice versa. Observera att om du förväntar dig att förbehandla stora mängder tabelldata under slutledningstiden kan du fortfarande använda RAPIDS för att GPU-accelerera det.

Kom ihåg att vi skapade label_encoders.pkl fil i den första anteckningsboken. Det finns inget mer att göra för kategorikodning annat än att inkludera den i vår model.py fil för förbearbetning.

För att skapa model.py-filen som krävs av Triton Python-backend, följer vi formatering som krävs av backend och inkludera vår Python-logik för att bearbeta den inkommande tensorn och använda etikettkodaren som refererades till tidigare. Du kan granska fil används för förbearbetning.

För XGBoost-modellen behöver inget mer göras. Vi tränade modellen i den första bärbara datorn och Tritons FIL-backend kräver ingen extra ansträngning för XGBoost-modeller.

Därefter behöver vi Triton-konfigurationsfilerna. Varje modell i Triton-ensemblen kräver en config.pbtxt fil. Dessutom skapar vi också en config.pbtxt fil för ensemblen som helhet. Dessa filer tillåter Triton att känna till metadata om ensemblen med information som in- och utdata vi förväntar oss samt hjälpa till att definiera DAG som är associerad med ensemblen.

Slutligen, för att distribuera en modell på Triton, behöver vi vår modellförrådsmapp för att ha rätt mappstruktur. Triton har specifika krav för modellförvarslayout. Inom katalogen över modellförrådet på toppnivå har varje modell sin egen underkatalog som innehåller informationen för motsvarande modell. Varje modellkatalog i Triton måste ha minst en numerisk underkatalog som representerar en version av modellen. För vårt användningsfall bör den resulterande strukturen se ut som följande.

När vi har dessa tre förutsättningar skapar vi en komprimerad fil som paketering för distribution och laddar upp den till Amazon enkel lagringstjänst (Amazon S3).

Vi kan nu skapa en SageMaker-modell från modellförrådet vi laddade upp till Amazon S3 i föregående steg.

I det här steget tillhandahåller vi även den ytterligare miljövariabeln SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, som anger namnet på modellen som ska laddas av Triton. Värdet på denna nyckel bör matcha mappnamnet i modellpaketet som laddats upp till Amazon S3. Denna variabel är valfri för en enskild modell. När det gäller ensemblemodeller måste denna nyckel anges för att Triton ska starta i SageMaker.

Dessutom kan du ställa in SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT och SAGEMAKER_TRITON_THREAD_COUNT för att optimera antalet trådar. Båda konfigurationsvärdena hjälper till att justera antalet trådar som körs på dina processorer, så att du möjligen kan få bättre utnyttjande genom att öka dessa värden för processorer med ett större antal kärnor. I de flesta fall fungerar standardvärdena ofta bra, men det kan vara värt att experimentera och se om ytterligare effektivitet kan uppnås för dina arbetsbelastningar.

Med den föregående modellen skapar vi en slutpunktskonfiguration där vi kan specificera vilken typ och antal instanser vi vill ha i slutpunkten.

Slutligen använder vi den föregående slutpunktskonfigurationen för att skapa en ny SageMaker-slutpunkt och väntar på att distributionen ska slutföras. Statusen ändras till InService efter att distributionen har lyckats.

Det är allt! Din slutpunkt är nu redo för testning och validering. Vid det här laget kanske du vill använda olika verktyg för att optimera dina instanstyper och konfiguration för att få bästa möjliga prestanda. Följande figur ger ett exempel på de vinster som kan uppnås genom att använda FIL-backend för en XGBoost-modell på Triton.

Sammanfattning

I det här inlägget ledde vi dig genom att distribuera en XGBoost-ensemble-arbetsbelastning till SageMaker med Triton Inference Server. Att flytta arbetsbelastningar till Triton på SageMaker kan vara en fördelaktig avkastning på investeringen. Som med all användning av teknik är en granskningsprocess och en plan nyckeln, och vi detaljerade en process i fem steg för att guida dig genom vad du ska tänka på när du flyttar dina arbetsbelastningar. Dessutom gick vi djupt in i stegen som behövs för att distribuera en ensemble som använder Python-förbearbetning och en XGBoost-modell på Triton på SageMaker.

SageMaker tillhandahåller verktygen för att ta bort de odifferentierade tunga lyften från varje steg i ML-livscykeln, och underlättar därigenom de snabba experimenterande och utforskningar som behövs för att helt optimera dina modellinstallationer. SageMaker-värdstöd för Triton Inference Server möjliggör arbetsbelastningar med låg latens och höga transaktioner per sekund (TPS).

Du kan hitta de anteckningsböcker som används för detta exempel på GitHub.

---

Om författaren

James Park är en lösningsarkitekt på Amazon Web Services. Han arbetar med Amazon.com för att designa, bygga och distribuera tekniklösningar på AWS och har ett särskilt intresse för AI och maskininlärning. På fritiden tycker han om att söka nya kulturer, nya upplevelser och att hålla sig uppdaterad med de senaste tekniktrenderna.

Jiahong Liu är en lösningsarkitekt på Cloud Service Provider-teamet på NVIDIA. Han hjälper kunder att ta till sig maskininlärning och AI-lösningar som utnyttjar NVIDIAs accelererade datoranvändning för att hantera deras utbildnings- och slutledningsutmaningar. På sin fritid tycker han om origami, gör-det-själv-projekt och att spela basket.

Kshitiz Gupta är lösningsarkitekt på NVIDIA. Han tycker om att utbilda molnkunder om GPU AI-teknikerna NVIDIA har att erbjuda och hjälpa dem med att accelerera deras maskininlärning och djupinlärning. Utanför jobbet tycker han om att springa, vandra och titta på vilda djur.

Bruno Aguiar de Melo är en mjukvaruutvecklingsingenjör på Amazon.com, där han hjälper vetenskapsteam att bygga, distribuera och släppa ML-arbetsbelastningar. Han är intresserad av instrumentering och kontrollerbara aspekter inom ML-modellerings-/designfasen som måste beaktas och mätas med insikten att modellexekveringsprestanda är lika viktigt som modellkvalitetsprestanda, särskilt i latens-begränsade användningsfall. På fritiden tycker han om vin, brädspel och matlagning.

Eliuth Triana är en Developer Relations Manager på NVIDIA. Han kopplar samman Amazon- och AWS-produktledare, utvecklare och forskare med NVIDIA-teknologer och produktledare för att påskynda Amazon ML/DL-arbetsbelastningar, EC2-produkter och AWS AI-tjänster. Dessutom är Eliuth en passionerad mountainbike-, skid- och pokerspelare.