En af de mest populære modeller, der er tilgængelige i dag, er XGBoost. Med evnen til at løse forskellige problemer såsom klassificering og regression er XGBoost blevet en populær mulighed, der også falder ind under kategorien træbaserede modeller. I dette indlæg dykker vi dybt for at se hvordan Amazon SageMaker kan betjene disse modeller vha NVIDIA Triton Inference Server. Realtidsinferensarbejdsbelastninger kan have varierende niveauer af krav og serviceniveauaftaler (SLA'er) med hensyn til latens og gennemløb og kan opfyldes ved hjælp af SageMaker real-time slutpunkter.
SageMaker leverer enkelt model endepunkter, som giver dig mulighed for at implementere en enkelt maskinlæringsmodel (ML) mod et logisk slutpunkt. For andre brugstilfælde kan du vælge at administrere omkostninger og ydeevne vha multi-model slutpunkter, som giver dig mulighed for at angive flere modeller til at være vært bag et logisk slutpunkt. Uanset hvilken mulighed du vælger, tillader SageMaker-endepunkter en skalerbar mekanisme for selv de mest krævende virksomhedskunder, mens de giver værdi i en overflod af funktioner, bl.a. skyggevarianter, automatisk skalering, og native integration med amazoncloudwatch (for mere information, se CloudWatch Metrics for Multi-Model Endpoint Deployment).
Triton understøtter forskellige backends som motorer til at understøtte kørsel og servering af forskellige ML-modeller til slutning. For enhver Triton-implementering er det afgørende at vide, hvordan backend-adfærden påvirker dine arbejdsbelastninger, og hvad du kan forvente, så du kan få succes. I dette indlæg hjælper vi dig med at forstå Forest Inference Library (FIL) backend, som er understøttet af Triton på SageMaker, så du kan træffe en informeret beslutning for dine arbejdsbelastninger og få den bedst mulige ydeevne og omkostningsoptimering.
Dybt dyk ned i FIL-backend
Triton understøtter FIL-backend at betjene træmodeller, som f.eks XGBoost, LightGBM, scikit-lære Tilfældig Skov, RAPIDS cuML Random Forest, og enhver anden model understøttet af Treelit. Disse modeller har længe været brugt til at løse problemer som klassifikation eller regression. Selvom disse typer modeller traditionelt har kørt på CPU'er, har disse modellers popularitet og slutningskrav ført til forskellige teknikker til at øge slutningsydelsen. FIL-backend'en bruger mange af disse teknikker ved at bruge cuML-konstruktioner og er bygget på C++ og CUDA-kernebiblioteket for at optimere inferensydelse på GPU-acceleratorer.
FIL-backend'en bruger cuML's biblioteker til at bruge CPU- eller GPU-kerner til at accelerere indlæringen. For at bruge disse processorer refereres der til data fra værtshukommelsen (f.eks. NumPy-arrays) eller GPU-arrays (uDF, Numba, cuPY eller et hvilket som helst bibliotek, der understøtter __cuda_array_interface__
) API. Efter at dataene er iscenesat i hukommelsen, kan FIL-backend'en køre behandling på tværs af alle tilgængelige CPU- eller GPU-kerner.
FIL-backend-trådene kan kommunikere med hinanden uden at bruge værtens delte hukommelse, men i ensemble-arbejdsbelastninger bør værtshukommelse overvejes. Følgende diagram viser en runtime-arkitektur for ensembleplanlægger, hvor du har mulighed for at finjustere hukommelsesområderne, inklusive CPU-adresserbar delt hukommelse, der bruges til kommunikation mellem Triton (C++) og Python-processen (Python-backend) til udveksling tensorer (input/output) med FIL-backend.
Triton Inference Server giver udviklere konfigurerbare muligheder for at justere deres arbejdsbelastninger og optimere modellens ydeevne. 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.
Der er en række andre FIL-specifikke tilgængelige muligheder som påvirker præstation og adfærd. Vi foreslår at starte med storage_type
. Når du kører backend på GPU, opretter FIL en ny hukommelse/datastruktur, der er en repræsentation af træet, for hvilket FIL kan påvirke ydeevne og fodaftryk. Dette kan konfigureres via miljøparameteren storage_type
, som har mulighederne tæt, sparsom og auto. At vælge den tætte indstilling vil forbruge mere GPU-hukommelse og resulterer ikke altid i bedre ydeevne, så det er bedst at tjekke. I modsætning hertil vil den sparsomme mulighed forbruge mindre GPU-hukommelse og kan muligvis yde lige så godt eller bedre end tæt. Hvis du vælger auto, vil modellen som standard blive tæt, medmindre det vil forbruge betydeligt mere GPU-hukommelse end sparsomt.
Når det kommer til modellens ydeevne, kan du overveje at lægge vægt på threads_per_tree
mulighed. En ting, som du måske overbetjener i virkelige scenarier, er det threads_per_tree
kan have en større indflydelse på gennemløbet end nogen anden parameter. Det er legitimt at indstille den til en hvilken som helst styrke på 2 fra 1-32. Den optimale værdi er svær at forudsige for denne parameter, men når serveren forventes at håndtere større belastning eller behandle større batchstørrelser, har den en tendens til at drage fordel af en større værdi, end når den behandler et par rækker ad gangen.
En anden parameter at være opmærksom på er algo
, som også er tilgængelig, hvis du kører på GPU. Denne parameter bestemmer den algoritme, der bruges til at behandle slutningsanmodningerne. De understøttede muligheder for dette er ALGO_AUTO
, NAIVE
, TREE_REORG
og BATCH_TREE_REORG
. Disse muligheder bestemmer, hvordan noder i et træ er organiseret og kan også resultere i præstationsforbedringer. Det ALGO_AUTO
indstilling er som standard NAIVE
til sparsom opbevaring og BATCH_TREE_REORG
til tæt opbevaring.
Endelig kommer FIL med Shapley-forklaring, som kan aktiveres ved at bruge treeshap_output
parameter. Du skal dog huske på, at Shapley-output skader ydeevnen på grund af dens outputstørrelse.
Model format
Der er i øjeblikket ikke noget standard filformat til at gemme skovbaserede modeller; hver ramme har en tendens til at definere sit eget format. For at understøtte flere inputfilformater importerer FIL data ved hjælp af open source Treelit bibliotek. Dette gør det muligt for FIL at understøtte modeller trænet i populære rammer, som f.eks XGBoost , LightGBM. Bemærk, at formatet på den model, du leverer, skal indstilles i model_type
konfigurationsværdi angivet i config.pbtxt
fil.
Config.pbtxt
Hver model i en modelopbevaring skal omfatte en modelkonfiguration, der giver de nødvendige og valgfrie oplysninger om modellen. Typisk er denne konfiguration tilvejebragt i en config.pbtxt
fil angivet som ModelConfig protobuf. For at lære mere om konfigurationsindstillingerne, se Model konfiguration. Følgende er nogle af modelkonfigurationsparametrene:
- max_batch_size – Dette bestemmer den maksimale batchstørrelse, der kan overføres til denne model. Generelt er den eneste grænse for størrelsen af batches, der sendes til en FIL-backend, den tilgængelige hukommelse til at behandle dem. For GPU-kørsler bestemmes den tilgængelige hukommelse af størrelsen på Tritons CUDA-hukommelsespulje, som kan indstilles via et kommandolinjeargument, når serveren startes.
- indgang – Indstillingerne i dette afsnit fortæller Triton, hvor mange funktioner man kan forvente for hver inputprøve.
- output – Indstillinger i dette afsnit fortæller Triton, hvor mange outputværdier der vil være for hver prøve. Hvis
predict_proba
indstilling er sat til sand, så returneres en sandsynlighedsværdi for hver klasse. Ellers vil en enkelt værdi blive returneret, hvilket angiver den forudsagte klasse for den givne prøve. - instansgruppe – Dette bestemmer, hvor mange forekomster af denne model, der oprettes, og om de vil bruge GPU eller CPU.
- model_type – Denne streng angiver hvilket format modellen er i (
xgboost_json
i dette eksempel, menxgboost
,lightgbm
ogtl_checkpoint
er også gyldige formater). - forudsige_proba – Hvis indstillet til sand, returneres sandsynlighedsværdier for hver klasse i stedet for blot en klasseforudsigelse.
- output_klasse – Dette er sat til sand for klassifikationsmodeller og falsk for regressionsmodeller.
- tærskel – Dette er en scoretærskel for at bestemme klassificering. Hvornår
output_class
er sat til sand, skal dette angives, selvom det ikke vil blive brugt, hvispredict_proba
er også sat til sand. - lagertype – Generelt bør brugen af AUTO til denne indstilling opfylde de fleste tilfælde. Hvis AUTO-lagring er valgt, vil FIL indlæse modellen ved hjælp af enten en sparsom eller tæt repræsentation baseret på modellens omtrentlige størrelse. I nogle tilfælde vil du måske udtrykkeligt indstille dette til SPARSE for at reducere hukommelsesfodaftrykket for store modeller.
Triton Inference Server på SageMaker
SageMaker tillader du kan implementere både enkeltmodel- og multimodelslutpunkter med NVIDIA Triton Inference Server. Følgende figur viser Triton Inference Server-arkitekturen på højt niveau. Det modelopbevaring er et filsystembaseret lager af de modeller, som Triton vil stille til rådighed for inferencing. Anmodninger om slutninger ankommer til serveren og dirigeres til den relevante planlægger pr. model. Triton redskaber flere planlægnings- og batch-algoritmer der kan konfigureres fra model til model. Hver models skemalægger udfører valgfrit batching af slutningsanmodninger og sender derefter anmodningerne til backend svarende til modeltypen. Backend'en udfører inferencing ved hjælp af de input, der er tilvejebragt i batch-anmodningerne, for at producere de ønskede output. Udgangene returneres derefter.
Når du konfigurerer dine automatiske skaleringsgrupper til SageMaker-slutpunkter, kan du overveje SageMakerVariantInvocationsPerInstance
som det primære kriterium til at bestemme skaleringsegenskaberne for din automatiske skaleringsgruppe. Derudover, afhængigt af om dine modeller kører på GPU eller CPU, kan du også overveje at bruge CPUUtilization eller GPUUtilization som yderligere kriterier. Bemærk, at for enkeltmodelslutpunkter, fordi de installerede modeller alle er ens, er det ret ligetil at sætte korrekte politikker for at opfylde dine SLA'er. For multi-model endepunkter anbefaler vi at implementere lignende modeller bag et givet endepunkt for at have mere stabil forudsigelig ydeevne. I brugstilfælde, hvor der bruges modeller af forskellige størrelser og krav, vil du måske adskille disse arbejdsbelastninger på tværs af flere multi-model slutpunkter eller bruge lidt tid på at finjustere din automatiske skaleringsgruppepolitik for at opnå den bedste balance mellem omkostninger og ydeevne.
For en liste over NVIDIA Triton Deep Learning Containers (DLC'er), der understøttes af SageMaker inference, henvises til Tilgængelige Deep Learning Containers-billeder.
SageMaker notebook gennemgang
ML-applikationer er komplekse og kan ofte kræve dataforbehandling. I denne notesbog dykker vi ned i, hvordan man implementerer en træbaseret ML-model som XGBoost ved hjælp af FIL-backend i Triton på et SageMaker multi-model slutpunkt. Vi dækker også, hvordan man implementerer en Python-baseret dataforbehandlings-inferenspipeline til din model ved hjælp af ensemble-funktionen i Triton. Dette vil give os mulighed for at sende rådata fra klientsiden og få både dataforbehandling og modelinferens til at ske i et Triton SageMaker-slutpunkt for optimal inferensydelse.
Triton model ensemble funktion
Triton Inference Server forenkler i høj grad implementeringen af AI-modeller i stor skala i produktionen. Triton Inference Server leveres med en praktisk løsning, der forenkler opbygningen af forbehandlings- og efterbehandlingspipelines. Triton Inference Server-platformen leverer ensembleplanlæggeren, som er ansvarlig for pipelining af modeller, der deltager i inferensprocessen, mens den sikrer effektivitet og optimerer gennemløbet. Brug af ensemblemodeller kan undgå omkostningerne ved at overføre mellemliggende tensorer og minimere antallet af anmodninger, der skal sendes til Triton.
I denne notesbog viser vi, hvordan man bruger ensemble-funktionen til at bygge en pipeline af dataforbehandling med XGBoost-modelinferens, og du kan ekstrapolere fra den for at tilføje tilpasset efterbehandling til pipelinen.
Indstil miljøet
Vi starter med at opsætte det ønskede miljø. Vi installerer de afhængigheder, der kræves for at pakke vores modelpipeline og køre inferenser ved hjælp af Triton Inference Server. Vi definerer også AWS identitets- og adgangsstyring (IAM) rolle, der vil give SageMaker adgang til modelartefakter og NVIDIA Triton Amazon Elastic Container Registry (Amazon ECR) billede. Se følgende kode:
Opret et Conda-miljø til forbehandlingsafhængigheder
Python-backend i Triton kræver, at vi bruger en Conda miljø for eventuelle yderligere afhængigheder. I dette tilfælde bruger vi Python-backend'en til at forbehandle de rå data, før vi fodrer dem ind i XGBoost-modellen, der kører i FIL-backend. Selvom vi oprindeligt brugte RAPIDS cuDF og cuML til at udføre dataforbehandlingen, bruger vi her Pandas og scikit-learn som forbehandlingsafhængigheder under inferens. Det gør vi af tre grunde:
- Vi viser, 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 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 samt forskellige hardwarekonfigurationer.
- Det fremhæver, hvordan RAPIDS-bibliotekerne (cuDF, cuML) er kompatible med deres CPU-modstykker (Pandas, scikit-learn). Vi kan for eksempel vise hvordan
LabelEncoders
oprettet i cuML kan bruges i scikit-learn og omvendt.
Vi følger instruktionerne fra Triton dokumentation til pakkeforbehandlingsafhængigheder (scikit-learn og Pandas), der skal bruges i Python-backend som en Conda-miljø TAR-fil. Bash-scriptet create_prep_env.sh opretter Conda-miljøets TAR-fil, så flytter vi den til forbehandlingsmodelbiblioteket. Se følgende kode:
Når vi har kørt det foregående script, genereres det preprocessing_env.tar.gz
, som vi kopierer til forbehandlingsmappen:
Konfigurer forbehandling med Triton Python-backend
Til forbehandling bruger vi Triton's Python backend at udføre forbehandling af tabeldata (kategorisk kodning) under inferens for rådataanmodninger, der kommer ind på serveren. For mere information om den forbehandling, der blev udført under træningen, henvises til træningsnotesbog.
Python-backend gør det muligt for forbehandling, efterbehandling og enhver anden tilpasset logik at blive implementeret i Python og serveret med Triton. Brug af Triton på SageMaker kræver, at vi først opsætter en model repository-mappe, der indeholder de modeller, vi ønsker at betjene. Vi har allerede opsat en model for Python-dataforbehandling kaldet preprocessing in cpu_model_repository
, gpu_model_repository
.
Triton har specifikke krav til modellagerlayout. Inden for 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. Værdien 1 repræsenterer version 1 af vores Python-forbehandlingsmodel. Hver model køres af en specifik backend, så inden for hver versionsundermappe skal der være den modelartefakt, der kræves af den pågældende backend. Til dette eksempel bruger vi Python-backend, som kræver, at den Python-fil, du serverer, hedder model.py, og filen skal implementeres visse funktioner. Hvis vi brugte en PyTorch-backend, ville en model.pt-fil være påkrævet, og så videre. For flere detaljer om navngivningskonventioner for modelfiler, se Model filer.
model.py Python-filen, vi bruger her, implementerer al den tabelformede dataforbehandlingslogik til at konvertere rådata til funktioner, der kan indlæses i vores XGBoost-model.
Hver Triton-model skal også levere en config.pbtxt
fil, der beskriver modelkonfigurationen. For at lære mere om konfigurationsindstillingerne, se Model konfiguration. Vores config.pbtxt fil angiver backend som python og alle inputkolonner for rådata sammen med forbehandlet output, som består af 15 funktioner. Vi specificerer også, at vi ønsker at køre denne Python-forbehandlingsmodel på CPU'en. Se følgende kode:
Opsæt en træbaseret ML-model til FIL-backend
Dernæst opsætter vi modelbiblioteket for en træbaseret ML-model som XGBoost, som vil bruge FIL-backend.
Det forventede layout for cpu_memory_repository
, gpu_memory_repository
ligner den, vi viste tidligere.
Her, FIL
er navnet på modellen. Vi kan give det et andet navn som xgboost
hvis vi vil. 1
er versionsundermappen, som indeholder modelartefakten. I dette tilfælde er det xgboost.json
model, som vi gemte. Lad os skabe dette forventede layout:
Vi skal have konfigurationsfilen config.pbtxt
beskriver modelkonfigurationen for den træbaserede ML-model, så FIL-backend'en i Triton kan forstå, hvordan den skal betjenes. For mere information henvises til den seneste generiske Triton konfigurationsmuligheder og de specifikke konfigurationsmuligheder for FIL-backend. Vi fokuserer på blot nogle få af de mest almindelige og relevante muligheder i dette eksempel.
Opret config.pbtxt
forum model_cpu_repository
:
Tilsvarende opsætning config.pbtxt
forum model_gpu_repository
(bemærk forskellen er USE_GPU = True
):
Opsæt en inferenspipeline af dataforbehandlingen Python-backend og FIL-backend ved hjælp af ensembler
Nu er vi klar til at opsætte inferenspipelinen til dataforbehandling og træbaseret modelinferens ved hjælp af en ensemble model. En ensemblemodel repræsenterer en pipeline af en eller flere modeller og forbindelsen af input- og outputtensorer mellem disse modeller. Her bruger vi ensemblemodellen til at bygge en pipeline af dataforbehandling i Python-backend efterfulgt af XGBoost i FIL-backend.
Det forventede layout for ensemble
model bibliotek ligner dem, vi viste tidligere:
Vi lavede ensemblemodellerne config.pbtxt efter vejledningen i Ensemble modeller. Vigtigt er det, at vi skal konfigurere ensembleplanlæggeren i config.pbtxt
, som specificerer datastrømmen mellem modeller inden for ensemblet. Ensembleplanlæggeren indsamler outputtensorerne i hvert trin og leverer dem som inputtensorer til andre trin i henhold til specifikationen.
Pak modellageret og upload til Amazon S3
Endelig ender vi med følgende model repository directory-struktur, der indeholder en Python-forbehandlingsmodel og dens afhængigheder sammen med XGBoost FIL-modellen og modelensemblet.
Vi pakker mappen og dens indhold som model.tar.gz
til upload til Amazon Simple Storage Service (Amazon S3). Vi har to muligheder i dette eksempel: Brug af en CPU-baseret instans eller en GPU-baseret instans. En GPU-baseret instans er mere velegnet, når du har brug for højere processorkraft og ønsker at bruge CUDA-kerner.
Opret og upload modelpakken til en CPU-baseret instans (optimeret til CPU) med følgende kode:
Opret og upload modelpakken til en GPU-baseret instans (optimeret til GPU) med følgende kode:
Opret et SageMaker-slutpunkt
Vi har nu modelartefakterne opbevaret i en S3-spand. I dette trin kan vi også levere 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
, SAGEMAKER_TRITON_THREAD_COUNT
til optimering af trådantal.
Vi bruger den foregående model til at oprette en slutpunktskonfiguration, hvor vi kan angive typen og antallet af forekomster, vi ønsker i slutpunktet
Vi bruger denne slutpunktskonfiguration til at oprette et SageMaker-slutpunkt og venter på, at implementeringen er færdig. Med SageMaker MME'er har vi mulighed for at være vært for flere ensemblemodeller ved at gentage denne proces, men vi holder os til én implementering for dette eksempel:
Status ændres til InService
når implementeringen er vellykket.
Kald din model hostet på SageMaker-slutpunktet
Efter endtpunktet kører, kan vi bruge nogle eksempler på rådata til at udføre inferens ved hjælp af JSON som nyttelastformat. Til slutningsanmodningsformatet bruger Triton KFServing
samfundsstandard slutningsprotokoller. Se følgende kode:
Den notesbog, der henvises til i bloggen, kan findes i GitHub repository.
Bedste praksis
Ud over mulighederne for at finjustere indstillingerne af FIL-backend, som vi nævnte tidligere, kan dataforskere også sikre, at inputdataene til backend er optimeret til behandling af motoren. Når det er muligt, indtast data i række-major-format i GPU-arrayet. Andre formater vil kræve intern konvertering og optage-cyklusser, hvilket reducerer ydeevnen.
På grund af den måde, FIL-datastrukturer vedligeholdes i GPU-hukommelsen, skal du være opmærksom på trædybden. Jo dybere trædybden er, jo større vil dit GPU-hukommelsesfodaftryk være.
Brug instance_group_count
parameter for at tilføje arbejdsprocesser og øge gennemløbet af FIL-backend, hvilket vil resultere i større CPU- og GPU-hukommelsesforbrug. Overvej desuden SageMaker-specifikke variabler, der er tilgængelige for at øge gennemløbet, såsom HTTP-tråde, HTTP-bufferstørrelse, batchstørrelse og maks. forsinkelse.
Konklusion
I dette indlæg dykkede vi dybt ind i den FIL-backend, som Triton Inference Server understøtter på SageMaker. Denne backend sørger for både CPU- og GPU-acceleration af dine træbaserede modeller, såsom den populære XGBoost-algoritme. Der er mange muligheder at overveje for at få den bedste ydeevne til inferens, såsom batchstørrelser, datainputformater og andre faktorer, der kan indstilles til at opfylde dine behov. SageMaker giver dig mulighed for at bruge denne funktion med enkelt- og multimodel-endepunkter for at balancere mellem ydeevne og omkostningsbesparelser.
Vi opfordrer dig til at tage oplysningerne i dette indlæg og se, om SageMaker kan opfylde dine hostingbehov for at betjene træbaserede modeller, der opfylder dine krav til omkostningsreduktion og arbejdsbyrdeydelse.
Den notesbog, der henvises til i dette indlæg, kan findes i SageMaker-eksemplerne GitHub repository. Desuden kan du finde den seneste dokumentation på FIL-backend på GitHub.
Om forfatterne
Raghu Ramesha er senior ML Solutions Architect hos Amazon SageMaker Service-teamet. Han fokuserer på at hjælpe kunder med at opbygge, implementere og migrere ML-produktionsarbejdsbelastninger til SageMaker i stor skala. Han har specialiseret sig i maskinlæring, kunstig intelligens og computersyn og har en mastergrad i datalogi fra UT Dallas. I sin fritid nyder han at rejse og fotografere.
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.
Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret databehandling og kunstig intelligens. Han fokuserer på dyb læring, herunder NLP og computer vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på Amazon SageMaker.
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.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoAiStream. Web3 Data Intelligence. Viden forstærket. Adgang her.
- Udmøntning af fremtiden med Adryenn Ashley. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/hosting-ml-models-on-amazon-sagemaker-using-triton-xgboost-lightgbm-and-treelite-models/
- :har
- :er
- :ikke
- :hvor
- $OP
- 1
- 100
- 11
- 13
- 200
- 23
- 24
- 7
- 8
- 9
- a
- evne
- Om
- fremskynde
- accelereret
- accelererende
- acceleratorer
- adgang
- Ifølge
- derfor
- Konto
- opnå
- tværs
- tilføje
- Desuden
- Yderligere
- adresse
- adresserbare
- Vedtagelsen
- Efter
- mod
- aftaler
- AI
- algoritme
- Alle
- tildelinger
- tillade
- tillader
- sammen
- allerede
- også
- Skønt
- altid
- Amazon
- Amazon SageMaker
- Amazon Web Services
- Amazon.com
- beløb
- an
- ,
- enhver
- api
- applikationer
- passende
- arkitektur
- ER
- områder
- argument
- Array
- kunstig
- kunstig intelligens
- AS
- hjælper
- At
- auto
- til rådighed
- undgå
- AWS
- Bagende
- Balance
- baseret
- bash
- grundlag
- Basketball
- BE
- fordi
- bliver
- været
- før
- begynde
- bag
- jf. nedenstående
- gavner det dig
- BEDSTE
- Bedre
- mellem
- større
- Blog
- krop
- både
- buffer
- bygge
- Bygning
- bygget
- men
- by
- C + +
- kaldet
- CAN
- kort
- tilfælde
- tilfælde
- Boligtype
- Årsag
- udfordringer
- lave om
- karakteristika
- kontrollere
- chip
- Vælg
- vælge
- By
- klasse
- klassificering
- kunde
- kunder
- Cloud
- kode
- Kolonner
- KOM
- kommer
- kommer
- Fælles
- kommunikere
- Kommunikation
- samfund
- kompatibel
- komplekse
- beregning
- computer
- Datalogi
- Computer Vision
- computing
- Konfiguration
- tilslutning
- Overvej
- betragtes
- forbruge
- forbrug
- Container
- Beholdere
- indeholder
- indhold
- kontrast
- kontrol
- Praktisk
- Konvertering
- konvertere
- Core
- Tilsvarende
- Koste
- omkostningsreduktion
- omkostningsbesparelser
- dæksel
- skabe
- oprettet
- skaber
- kriterier
- afgørende
- For øjeblikket
- skik
- Kunder
- cykler
- Dallas
- data
- Dato
- dag
- deal
- beslutning
- dyb
- dyb læring
- dybere
- Standard
- defaults
- Degree
- forsinkelse
- krævende
- krav
- Afhængigt
- indsætte
- indsat
- implementering
- implementering
- dybde
- Design
- detaljer
- Bestem
- bestemmes
- bestemmer
- bestemmelse
- udviklere
- forskel
- forskellige
- distribueret
- distribueret computing
- Gør det selv
- do
- dokumentation
- Er ikke
- gør
- Domæner
- færdig
- due
- grund
- i løbet af
- hver
- tidligere
- uddanne
- effektivitet
- effektivt
- enten
- at understrege
- muliggør
- tilskynde
- ende
- Endpoint
- Engine (Motor)
- Motorer
- sikre
- sikring
- Enterprise
- virksomheder
- Hele
- Miljø
- fejl
- Endog
- Hver
- eksempel
- eksempler
- udveksling
- forvente
- forventet
- Oplevelser
- eksport
- faktorer
- retfærdigt
- Falls
- falsk
- Feature
- Funktionalitet
- Fed
- fodring
- få
- Figur
- File (Felt)
- Filer
- Finde
- slut
- Fornavn
- flow
- Fokus
- fokuserer
- følger
- efterfulgt
- efter
- Fodspor
- Til
- formular
- format
- fundet
- Framework
- rammer
- bedrageri
- Gratis
- fra
- Endvidere
- gevinster
- Generelt
- genererer
- få
- Giv
- given
- GPU
- stærkt
- gruppe
- Gruppens
- vejledning
- ske
- Hård Ost
- Hardware
- Have
- he
- hjælpe
- hjælpe
- hjælper
- link.
- højt niveau
- Høj ydeevne
- højere
- højdepunkter
- hans
- hold
- besidder
- host
- hostede
- Hosting
- Hvordan
- How To
- Men
- HTML
- http
- HTTPS
- Hurt
- Identity
- id'er
- IDX
- if
- billede
- KIMOs Succeshistorier
- Påvirkninger
- gennemføre
- implementeret
- redskaber
- import
- in
- omfatter
- Herunder
- Forøg
- angiver
- oplysninger
- informeret
- indgang
- installere
- instans
- anvisninger
- integration
- Intelligens
- interesse
- interne
- ind
- IT
- ITS
- jpg
- json
- lige
- Holde
- Nøgle
- Venlig
- Kend
- stor
- Store virksomheder
- større
- Latency
- seneste
- Layout
- LÆR
- læring
- mindst
- Led
- legitim
- mindre
- Niveau
- niveauer
- Leverage
- biblioteker
- Bibliotek
- ligesom
- GRÆNSE
- Line (linje)
- Liste
- belastning
- logik
- logisk
- Lang
- maskine
- machine learning
- lave
- administrere
- mange
- herres
- Match
- max
- maksimal
- Kan..
- mekanisme
- Mød
- møde
- Hukommelse
- nævnte
- Merchant
- Metrics
- måske
- migrere
- tankerne
- ML
- tilstand
- model
- modeller
- Måned
- mere
- mest
- Mest Populære
- bevæge sig
- Multi-model slutpunkt
- flere
- skal
- navn
- navngivning
- indfødte
- Behov
- behov
- Ny
- NLP
- ingen
- noder
- notesbog
- nu
- nummer
- bedøvet
- Nvidia
- opnå
- of
- tilbyde
- Tilbud
- tit
- on
- ONE
- dem
- kun
- open source
- optimal
- optimering
- Optimer
- optimeret
- optimering
- Option
- Indstillinger
- or
- ordrer
- organisationer
- Organiseret
- oprindeligt
- OS
- Andet
- Ellers
- vores
- ud
- output
- uden for
- egen
- pakke
- emballage
- pandaer
- Parallel
- parameter
- parametre
- deltager
- særlig
- Bestået
- gennemløb
- sti
- Udfør
- ydeevne
- udfører
- tilladelse
- fotografering
- pipeline
- perron
- plato
- Platon Data Intelligence
- PlatoData
- spiller
- Vær venlig
- overflod
- politikker
- politik
- pool
- Populær
- popularitet
- mulig
- eventuelt
- Indlæg
- magt
- forudsige
- Forudsigelig
- forudsagde
- forudsigelse
- Forudsigelser
- tidligere
- primære
- Main
- problemer
- behandle
- Processer
- forarbejdning
- Processing Power
- processorer
- producere
- produktion
- projekter
- passende
- Proto
- give
- forudsat
- udbyder
- giver
- leverer
- Python
- pytorch
- tilfældig
- spænder
- hellere
- Raw
- klar
- virkelige verden
- realtid
- årsager
- anbefaler
- reducere
- benævnt
- Uanset
- region
- relaterede
- relevant
- erstatte
- Repository
- repræsentation
- repræsenterer
- repræsenterer
- anmode
- anmodninger
- kræver
- påkrævet
- Krav
- Kræver
- svar
- ansvarlige
- resultere
- Resultater
- roller
- Kør
- kører
- s
- sagemaker
- SageMaker Inference
- samme
- Besparelser
- skalerbar
- Scale
- skalering
- scenarier
- planlægning
- Videnskab
- forskere
- scikit-lære
- score
- Sektion
- se
- søger
- valgt
- send
- senior
- adskille
- tjener
- tjeneste
- Tjenesteudbyder
- Tjenester
- servering
- sæt
- indstilling
- indstillinger
- Shape
- delt
- bør
- Vis
- Shows
- side
- betydeligt
- lignende
- Simpelt
- enkelt
- Størrelse
- størrelser
- So
- løsninger
- Løsninger
- SOLVE
- Løsning
- nogle
- Kilde
- specialiseret
- specifikke
- specifikation
- specificeret
- tilbringe
- standard
- starte
- Starter
- Nystartede
- Tilstand
- Status
- steady
- Trin
- Steps
- opbevaring
- butik
- opbevaret
- ligetil
- String
- struktur
- vellykket
- sådan
- tyder
- egnede
- support
- Understøttet
- Understøtter
- Tag
- hold
- teknikker
- Teknologier
- Teknologier
- fortælle
- vilkår
- end
- at
- oplysninger
- deres
- Them
- derefter
- Der.
- Disse
- de
- ting
- denne
- dem
- selvom?
- tre
- tærskel
- kapacitet
- tid
- til
- i dag
- sammen
- øverste niveau
- traditionelt
- uddannet
- Kurser
- Overførsel
- Traveling
- træ
- Tendenser
- Triton
- sand
- to
- typen
- typer
- typisk
- forstå
- uploadet
- Uploading
- us
- brug
- anvendte
- Bruger
- ved brug af
- udnytter
- Ved hjælp af
- værdi
- Værdier
- forskellige
- udgave
- via
- vision
- W
- vente
- ønsker
- var
- ser
- Vej..
- we
- web
- webservices
- GODT
- var
- Hvad
- hvornår
- når
- hvorvidt
- som
- mens
- vilje
- med
- inden for
- uden
- Arbejde
- arbejdede
- arbejdstager
- virker
- ville
- XGBoost
- år
- Du
- Din
- zephyrnet
- Zip