En av de mest populära modellerna som finns tillgängliga idag är XGBoost. Med möjligheten att lösa olika problem som klassificering och regression har XGBoost blivit ett populärt alternativ som även hamnar i kategorin trädbaserade modeller. I det här inlägget dyker vi djupt för att se hur Amazon SageMaker kan tjäna dessa modeller med hjälp av NVIDIA Triton Inference Server. Arbetsbelastningar för slutledningar i realtid kan ha olika nivåer av krav och servicenivåavtal (SLA) när det gäller latens och genomströmning, och kan uppfyllas med SageMaker realtidsslutpunkter.
SageMaker tillhandahåller enda modellslutpunkter, som låter dig distribuera en enda maskininlärningsmodell (ML) mot en logisk slutpunkt. För andra användningsfall kan du välja att hantera kostnader och prestanda med hjälp av flermodell slutpunkter, som låter dig specificera flera modeller som ska vara värd bakom en logisk slutpunkt. Oavsett vilket alternativ du väljer tillåter SageMaker-slutpunkter en skalbar mekanism för även de mest krävande företagskunder samtidigt som de ger värde i en uppsjö av funktioner, inklusive skuggvarianter, automatisk skalning, och inbyggd integration med amazoncloudwatch (för mer information, se CloudWatch Metrics for Multi-Model Endpoint Deployment).
Triton stöder olika backends som motorer för att stödja körning och servering av olika ML-modeller för slutledning. För varje Triton-distribution är det avgörande att veta hur backend-beteendet påverkar dina arbetsbelastningar och vad du kan förvänta dig så att du kan bli framgångsrik. I det här inlägget hjälper vi dig att förstå Forest Inference Library (FIL) backend, som stöds av Triton på SageMaker, så att du kan fatta ett välgrundat beslut för dina arbetsbelastningar och få bästa möjliga prestanda och kostnadsoptimering.
Djupdyk in i FIL-backend
Triton stöder FIL backend att servera trädmodeller, som t.ex XGBoost, LightGBM, scikit lära Slumpmässig skog, RAPIDS cuML Random Forest, och alla andra modeller som stöds av Treelit. Dessa modeller har länge använts för att lösa problem som klassificering eller regression. Även om dessa typer av modeller traditionellt har körts på processorer, har dessa modellers popularitet och slutledningskrav lett till olika tekniker för att öka slutledningsprestanda. FIL-backend använder många av dessa tekniker genom att använda cuML-konstruktioner och är byggd på C++ och CUDA-kärnbiblioteket för att optimera slutledningsprestanda på GPU-acceleratorer.
FIL-backend använder cuMLs bibliotek för att använda CPU- eller GPU-kärnor för att påskynda inlärningen. För att kunna använda dessa processorer refereras data från värdminnet (till exempel NumPy-matriser) eller GPU-matriser (uDF, Numba, cuPY eller något bibliotek som stöder __cuda_array_interface__
) API. Efter att data är iscensatt i minnet kan FIL-backend köra bearbetning över alla tillgängliga CPU- eller GPU-kärnor.
FIL-backend-trådarna kan kommunicera med varandra utan att använda värdens delade minne, men i ensemble-arbetsbelastningar bör värdminne övervägas. Följande diagram visar en runtime-arkitektur för ensembleschemaläggning där du har möjlighet att finjustera minnesområdena, inklusive CPU-adresserbart delat minne som används för kommunikation mellan Triton (C++) och Python-processen (Python-backend) för utbyte tensorer (ingång/utgång) med FIL-backend.
Triton Inference Server tillhandahåller konfigurerbara alternativ för utvecklare att justera sina arbetsbelastningar och optimera modellens prestanda. 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 över hur länge Triton väntar på att bilda en batch.
Det finns ett antal andra FIL-specifika tillgängliga alternativ som påverkar prestation och beteende. Vi föreslår att börja med storage_type
. När du kör backend på GPU skapar FIL en ny minnes-/datastruktur som är en representation av trädet för vilket FIL kan påverka prestanda och fotavtryck. Detta är konfigurerbart via miljöparametern storage_type
, som har alternativen tät, sparsam och auto. Att välja det täta alternativet kommer att förbruka mer GPU-minne och resulterar inte alltid i bättre prestanda, så det är bäst att kontrollera. Däremot kommer det sparsamma alternativet att förbruka mindre GPU-minne och kan möjligen prestera lika bra eller bättre än tätt. Om du väljer automatiskt kommer modellen att som standard bli tät om det inte kommer att förbruka betydligt mer GPU-minne än sparsamt.
När det kommer till modellprestanda kan du överväga att betona threads_per_tree
alternativ. En sak som du kan överserva i verkliga scenarier är det threads_per_tree
kan ha en större inverkan på genomströmningen än någon annan parameter. Att ställa in den till valfri styrka 2 från 1–32 är legitimt. Det optimala värdet är svårt att förutsäga för denna parameter, men när servern förväntas hantera högre belastning eller bearbeta större batchstorlekar, tenderar den att dra nytta av ett högre värde än när den bearbetar några rader åt gången.
En annan parameter att vara medveten om är algo
, som också är tillgängligt om du kör på GPU. Denna parameter bestämmer algoritmen som används för att bearbeta slutledningsbegäranden. Alternativen som stöds för detta är ALGO_AUTO
, NAIVE
, TREE_REORG
och BATCH_TREE_REORG
. Dessa alternativ bestämmer hur noder i ett träd är organiserade och kan också resultera i prestandavinster. De ALGO_AUTO
alternativet är som standard NAIVE
för sparsam förvaring och BATCH_TREE_REORG
för tät förvaring.
Slutligen kommer FIL med Shapley-förklaring, som kan aktiveras genom att använda treeshap_output
parameter. Du bör dock komma ihåg att Shapley-utgångar skadar prestandan på grund av dess utdatastorlek.
Modellformat
Det finns för närvarande inget standardfilformat för att lagra skogsbaserade modeller; varje ram tenderar att definiera sitt eget format. För att stödja flera indatafilformat importerar FIL data med öppen källkod Treelit bibliotek. Detta gör det möjligt för FIL att stödja modeller som tränats i populära ramverk, som t.ex XGBoost och LightGBM. Observera att formatet på modellen du tillhandahåller måste ställas in i model_type
konfigurationsvärde som anges i config.pbtxt
fil.
Config.pbtxt
Varje modell i en modellförråd måste inkludera en modellkonfiguration som ger den obligatoriska och valfria informationen om modellen. Vanligtvis tillhandahålls denna konfiguration i en config.pbtxt
fil specificerad som ModelConfig protobuf. För att lära dig mer om konfigurationsinställningarna, se Modellkonfiguration. Följande är några av modellens konfigurationsparametrar:
- max_batch_size – Detta bestämmer den maximala batchstorleken som kan överföras till denna modell. I allmänhet är den enda gränsen för storleken på batcher som skickas till en FIL-backend det tillgängliga minnet för att bearbeta dem. För GPU-körningar bestäms det tillgängliga minnet av storleken på Tritons CUDA-minnespool, som kan ställas in via ett kommandoradsargument när servern startas.
- ingång – Alternativen i det här avsnittet talar om för Triton hur många funktioner som kan förväntas för varje ingångsprov.
- produktion – Alternativen i det här avsnittet talar om för Triton hur många utgångsvärden det kommer att finnas för varje prov. Om
predict_proba
alternativet är satt till sant, då returneras ett sannolikhetsvärde för varje klass. Annars kommer ett enda värde att returneras, vilket indikerar klassen som förutspås för det givna provet. - instansgrupp – Detta avgör hur många instanser av den här modellen som kommer att skapas och om de kommer att använda GPU eller CPU.
- modell typ – Denna sträng indikerar vilket format modellen är i (
xgboost_json
i detta exempel, menxgboost
,lightgbm
ochtl_checkpoint
är också giltiga format). - predict_proba – Om satt till sant, kommer sannolikhetsvärden att returneras för varje klass snarare än bara en klassförutsägelse.
- output_class – Detta är satt till sant för klassificeringsmodeller och falskt för regressionsmodeller.
- tröskelvärde – Detta är en poängtröskel för att bestämma klassificering. När
output_class
är inställd på sant måste detta tillhandahållas, även om det inte kommer att användas ompredict_proba
är också satt till sant. - lagringstyp – Generellt sett bör användning av AUTO för denna inställning uppfylla de flesta användningsfall. Om AUTO-lagring väljs kommer FIL att ladda modellen med antingen en sparsam eller tät representation baserat på modellens ungefärliga storlek. I vissa fall kanske du uttryckligen vill ställa in detta på SPARSE för att minska minnesavtrycket för stora modeller.
Triton Inference Server på SageMaker
SageMaker tillåter du kan distribuera både enstaka modell- och multimodellslutpunkter med NVIDIA Triton Inference Server. Följande figur visar Triton Inference Server-arkitekturen på hög nivå. De modellförråd är ett filsystembaserat arkiv av modellerna som Triton kommer att göra tillgängliga för slutledning. Slutledningsbegäranden anländer till servern och dirigeras till lämplig schemaläggare per modell. Triton redskap flera schemaläggnings- och batchalgoritmer som kan konfigureras på modell för modell. Varje modells schemaläggare utför valfritt batchning av slutledningsförfrågningar och skickar sedan förfrågningarna till backend motsvarande modelltypen. Backend utför slutledning med hjälp av de ingångar som tillhandahålls i de batchade förfrågningarna för att producera de begärda utgångarna. Utgångarna returneras sedan.
När du konfigurerar dina automatiska skalningsgrupper för SageMaker-slutpunkter, kanske du vill överväga SageMakerVariantInvocationsPerInstance
som det primära kriteriet för att bestämma skalningsegenskaperna för din automatiska skalningsgrupp. Dessutom, beroende på om dina modeller körs på GPU eller CPU, kan du också överväga att använda CPUUtilization eller GPUUtilization som ytterligare kriterier. Observera att för slutpunkter för enstaka modeller, eftersom de installerade modellerna alla är desamma, är det ganska enkelt att ställa in korrekta policyer för att uppfylla dina SLA:er. För flermodellslutpunkter rekommenderar vi att du använder liknande modeller bakom en given slutpunkt för att få mer stabil förutsägbar prestanda. I användningsfall där modeller av varierande storlek och krav används, kanske du vill separera dessa arbetsbelastningar över flera flermodellslutpunkter eller ägna lite tid åt att finjustera din automatiska skalningsgrupppolicy för att få bästa balans mellan kostnad och prestanda.
För en lista över NVIDIA Triton Deep Learning Containers (DLC) som stöds av SageMaker inference, se Tillgängliga bilder för Deep Learning Containers.
SageMaker anteckningsbok genomgång
ML-applikationer är komplexa och kan ofta kräva förbearbetning av data. I den här anteckningsboken fördjupar vi oss i hur man distribuerar en trädbaserad ML-modell som XGBoost med FIL-backend i Triton på en SageMaker multi-model endpoint. Vi täcker också hur man implementerar en Python-baserad dataförbehandlingspipeline för din modell med hjälp av ensemblefunktionen i Triton. Detta kommer att tillåta oss att skicka in rådata från klientsidan och få både dataförbearbetning och modellinferens att ske i en Triton SageMaker-slutpunkt för optimal slutledningsprestanda.
Triton modell ensemble funktion
Triton Inference Server förenklar distributionen av AI-modeller i stor skala i produktionen. Triton Inference Server kommer med en bekväm lösning som förenklar byggandet av förbearbetnings- och efterbearbetningspipelines. Triton Inference Server-plattformen tillhandahåller ensembleplaneraren, som är ansvarig för pipelining av modeller som deltar i inferensprocessen samtidigt som effektiviteten säkerställs och genomströmningen optimeras. Genom att använda ensemblemodeller kan man undvika överkostnaderna med att överföra mellantensorer och minimera antalet förfrågningar som måste skickas till Triton.
I den här anteckningsboken visar vi hur man använder ensemblefunktionen för att bygga en pipeline av dataförbearbetning med XGBoost-modellinferens, och du kan extrapolera från den för att lägga till anpassad efterbearbetning till pipelinen.
Ställ in miljön
Vi börjar med att sätta upp den miljö som krävs. Vi installerar de beroenden som krävs för att paketera vår modellpipeline och köra inferenser med hjälp av Triton Inference Server. Vi definierar också AWS identitets- och åtkomsthantering (IAM) roll som ger SageMaker tillgång till modellartefakterna och NVIDIA Triton Amazon Elastic Container Registry (Amazon ECR) bild. Se följande kod:
Skapa en Conda-miljö för förbearbetningsberoenden
Python-backend i Triton kräver att vi använder en Conda miljö för eventuella ytterligare beroenden. I det här fallet använder vi Python-backend för att förbehandla rådata innan vi matar in den i XGBoost-modellen som körs i FIL-backend. Även om vi ursprungligen använde RAPIDS cuDF och cuML för att göra förbearbetningen av data, använder vi här Pandas och scikit-learn som förbearbetningsberoenden under slutledning. Vi gör detta av tre anledningar:
- Vi visar 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:n medan XGBoost körs på GPU i FIL-backend, illustrerar vi hur varje modell i Tritons ensemblepipeline kan köras på ett annat ramverksbackend samt olika hårdvarukonfigurationer.
- Den belyser hur RAPIDS-biblioteken (cuDF, cuML) är kompatibla med sina CPU-motsvarigheter (Pandas, scikit-learn). Vi kan till exempel visa hur
LabelEncoders
skapad i cuML kan användas i scikit-learn och vice versa.
Vi följer instruktionerna från Triton dokumentation för paketering av förbearbetningsberoenden (scikit-learn och Pandas) som ska användas i Python-backend som en TAR-fil för Conda-miljö. Bash-manuset create_prep_env.sh skapar TAR-filen för Conda-miljön, sedan flyttar vi den till förbearbetningsmodellkatalogen. Se följande kod:
När vi kört föregående skript genereras det preprocessing_env.tar.gz
, som vi kopierar till förbearbetningskatalogen:
Ställ in förbearbetning med Triton Python-backend
För förbearbetning använder vi Tritons Python-backend att utföra förbearbetning av tabelldata (kategorisk kodning) under slutledning för rådataförfrågningar som kommer till servern. För mer information om förbearbetningen som gjordes under utbildningen, se träningsanteckningsbok.
Python-backend möjliggör förbearbetning, efterbearbetning och all annan anpassad logik som kan implementeras i Python och serveras med Triton. Att använda Triton på SageMaker kräver att vi först konfigurerar en modellförrådsmapp som innehåller de modeller vi vill betjäna. Vi har redan satt upp en modell för Python-dataförbearbetning som kallas förbearbetning i cpu_model_repository
och gpu_model_repository
.
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. Värdet 1 representerar version 1 av vår Python-förbearbetningsmodell. Varje modell körs av en specifik backend, så inom varje versionsunderkatalog måste det finnas den modellartefakt som krävs av den backend. För det här exemplet använder vi Python-backend, som kräver att Python-filen du serverar ska heta model.py, och filen måste implementeras vissa funktioner. Om vi använde en PyTorch-backend skulle en model.pt-fil krävas, och så vidare. För mer information om namnkonventioner för modellfiler, se Modellfiler.
Smakämnen modell.py Python-filen som vi använder här implementerar all tabelldataförbehandlingslogik för att konvertera rådata till funktioner som kan matas in i vår XGBoost-modell.
Varje Triton-modell måste också ge en config.pbtxt
fil som beskriver modellkonfigurationen. För att lära dig mer om konfigurationsinställningarna, se Modellkonfiguration. Vår config.pbtxt fil specificerar backend som python och alla indatakolumner för rådata tillsammans med förbehandlad utdata, som består av 15 funktioner. Vi anger också att vi vill köra denna Python-förbearbetningsmodell på CPU:n. Se följande kod:
Konfigurera en trädbaserad ML-modell för FIL-backend
Därefter satte vi upp modellkatalogen för en trädbaserad ML-modell som XGBoost, som kommer att använda FIL-backend.
Den förväntade layouten för cpu_memory_repository
och gpu_memory_repository
liknar den vi visade tidigare.
Här, FIL
är modellens namn. Vi kan ge det ett annat namn som xgboost
om vi vill. 1
är versionens underkatalog, som innehåller modellartefakten. I det här fallet är det xgboost.json
modell som vi sparat. Låt oss skapa den här förväntade layouten:
Vi måste ha konfigurationsfilen config.pbtxt
beskriver modellkonfigurationen för den trädbaserade ML-modellen, så att FIL-backend i Triton kan förstå hur man servar den. För mer information, se den senaste generikan Triton konfigurationsalternativ och de specifika konfigurationsalternativen för FIL backend. Vi fokuserar på bara några av de vanligaste och mest relevanta alternativen i detta exempel.
Skapa config.pbtxt
för model_cpu_repository
:
På samma sätt, ställ in config.pbtxt
för model_gpu_repository
(observera att skillnaden är USE_GPU = True
):
Konfigurera en slutledningspipeline för dataförbehandlingen Python-backend och FIL-backend med hjälp av ensembler
Nu är vi redo att ställa in slutledningspipeline för dataförbehandling och trädbaserad modellinferens med hjälp av en ensemble modell. En ensemblemodell representerar en pipeline av en eller flera modeller och anslutningen av ingångs- och utgångstensorer mellan dessa modeller. Här använder vi ensemblemodellen för att bygga en pipeline av dataförbearbetning i Python-backend följt av XGBoost i FIL-backend.
Den förväntade layouten för ensemble
modellkatalogen liknar de vi visade tidigare:
Vi skapade ensemblemodellerna config.pbtxt följa anvisningarna i Ensemble modeller. Viktigt är att vi måste ställa in ensembleschemaläggaren i config.pbtxt
, som anger dataflödet mellan modeller inom ensemblen. Ensembleschemaläggaren samlar in utgångstensorerna i varje steg och tillhandahåller dem som ingångstensorer för andra steg enligt specifikationen.
Paketera modellförrådet och ladda upp till Amazon S3
Slutligen slutar vi med följande modellförvarskatalogstruktur, som innehåller en Python-förbearbetningsmodell och dess beroenden tillsammans med XGBoost FIL-modellen och modellensemblen.
Vi paketerar katalogen och dess innehåll som model.tar.gz
för uppladdning till Amazon enkel lagringstjänst (Amazon S3). Vi har två alternativ i det här exemplet: att använda en CPU-baserad instans eller en GPU-baserad instans. En GPU-baserad instans är mer lämplig när du behöver högre processorkraft och vill använda CUDA-kärnor.
Skapa och ladda upp modellpaketet för en CPU-baserad instans (optimerad för CPU) med följande kod:
Skapa och ladda upp modellpaketet för en GPU-baserad instans (optimerad för GPU) med följande kod:
Skapa en SageMaker-slutpunkt
Vi har nu modellartefakterna lagrade i en S3-hink. I det här steget kan vi också tillhandahålla 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.
Vi använder den föregående modellen för att skapa en slutpunktskonfiguration där vi kan specificera vilken typ och antal instanser vi vill ha i slutpunkten
Vi använder denna slutpunktskonfiguration för att skapa en SageMaker-slutpunkt och väntar på att distributionen ska slutföras. Med SageMaker MMEs har vi möjlighet att vara värd för flera ensemblemodeller genom att upprepa den här processen, men vi håller oss till en distribution för detta exempel:
Status kommer att ändras till InService
när distributionen är framgångsrik.
Anropa din modell på SageMaker-slutpunkten
Efter att slutpunkten har körts kan vi använda lite rådataexempel för att utföra slutledning med JSON som nyttolastformat. För formatet för inferensbegäran använder Triton KFServing
gemenskapsstandard slutledningsprotokoll. Se följande kod:
Anteckningsboken som hänvisas till i bloggen finns i GitHub repository.
Bästa praxis
Förutom alternativen för att finjustera inställningarna för FIL-backend som vi nämnde tidigare, kan datavetare också säkerställa att indata för backend är optimerad för bearbetning av motorn. När det är möjligt, mata in data i rad-huvudformat i GPU-matrisen. Andra format kräver intern konvertering och tar upp cykler, vilket minskar prestandan.
På grund av hur FIL-datastrukturer underhålls i GPU-minnet, var uppmärksam på träddjupet. Ju djupare träddjupet är, desto större blir ditt GPU-minne.
Använd instance_group_count
parameter för att lägga till arbetsprocesser och öka genomströmningen av FIL-backend, vilket kommer att resultera i större CPU- och GPU-minnesförbrukning. Tänk dessutom på SageMaker-specifika variabler som är tillgängliga för att öka genomströmningen, såsom HTTP-trådar, HTTP-buffertstorlek, batchstorlek och maxfördröjning.
Slutsats
I det här inlägget dyker vi djupt in i FIL-backend som Triton Inference Server stöder på SageMaker. Denna backend ger både CPU- och GPU-acceleration av dina trädbaserade modeller som den populära XGBoost-algoritmen. Det finns många alternativ att överväga för att få bästa möjliga prestanda för slutledning, såsom batchstorlekar, datainmatningsformat och andra faktorer som kan anpassas för att möta dina behov. SageMaker låter dig använda den här kapaciteten med endpoints för enstaka och flera modeller för att balansera prestanda och kostnadsbesparingar.
Vi uppmuntrar dig att ta informationen i det här inlägget och se om SageMaker kan möta dina värdbehov för att tjäna trädbaserade modeller och uppfylla dina krav på kostnadsreduktion och arbetsbelastningsprestanda.
Anteckningsboken som refereras till i det här inlägget finns i SageMaker-exemplen GitHub repository. Dessutom kan du hitta den senaste dokumentationen om FIL-backend på GitHub.
Om författarna
Raghu Ramesha är senior ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att bygga, distribuera och migrera ML-produktionsarbetsbelastningar till SageMaker i stor skala. Han är specialiserad på domäner för maskininlärning, AI och datorseende och har en magisterexamen i datavetenskap från UT Dallas. På fritiden tycker han om att resa och fotografera.
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.
Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning, inklusive NLP och datorseende domäner. Han hjälper kunder att uppnå högpresterande modellslutledning på Amazon SageMaker.
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.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoAiStream. Web3 Data Intelligence. Kunskap förstärkt. Tillgång här.
- Minting the Future med Adryenn Ashley. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/hosting-ml-models-on-amazon-sagemaker-using-triton-xgboost-lightgbm-and-treelite-models/
- : har
- :är
- :inte
- :var
- $UPP
- 1
- 100
- 11
- 13
- 200
- 23
- 24
- 7
- 8
- 9
- a
- förmåga
- Om oss
- accelerera
- accelererad
- accelererande
- acceleratorer
- tillgång
- Enligt
- i enlighet med detta
- Konto
- Uppnå
- tvärs
- lägga till
- Dessutom
- Annat
- adress
- adresserbar
- Anta
- Efter
- mot
- avtal
- AI
- algoritm
- Alla
- tilldelningar
- tillåter
- tillåter
- längs
- redan
- också
- Även
- alltid
- amason
- Amazon SageMaker
- Amazon Web Services
- Amazon.com
- mängd
- an
- och
- vilken som helst
- api
- tillämpningar
- lämpligt
- arkitektur
- ÄR
- områden
- Argumentet
- array
- konstgjord
- artificiell intelligens
- AS
- assist
- At
- bil
- tillgänglig
- undvika
- AWS
- backend
- Balansera
- baserat
- bash
- grund
- Basketboll
- BE
- därför att
- blir
- varit
- innan
- börja
- bakom
- nedan
- fördel
- BÄST
- Bättre
- mellan
- större
- Blogg
- kropp
- båda
- buffert
- SLUTRESULTAT
- Byggnad
- byggt
- men
- by
- C + +
- kallas
- KAN
- kortet
- Vid
- fall
- Kategori
- Orsak
- utmaningar
- byta
- egenskaper
- ta
- chip
- Välja
- välja
- Stad
- klass
- klassificering
- klient
- klienter
- cloud
- koda
- Kolonner
- COM
- kommer
- kommande
- Gemensam
- kommunicera
- Kommunikation
- samfundet
- kompatibel
- komplex
- beräkning
- dator
- Datavetenskap
- Datorsyn
- databehandling
- konfiguration
- anslutning
- Tänk
- anses
- konsumera
- konsumtion
- Behållare
- Behållare
- innehåller
- innehåll
- Däremot
- kontroll
- Bekväm
- Konvertering
- konvertera
- Kärna
- Motsvarande
- Pris
- kostnadsminskning
- kostnadsbesparingar
- täcka
- skapa
- skapas
- skapar
- kriterier
- avgörande
- För närvarande
- beställnings
- Kunder
- cykler
- Dallas
- datum
- Datum
- dag
- behandla
- Beslutet
- djup
- djupt lärande
- djupare
- Standard
- defaults
- Examen
- fördröja
- krävande
- krav
- beroende
- distribuera
- utplacerade
- utplacera
- utplacering
- djup
- Designa
- detaljer
- Bestämma
- bestämd
- bestämd
- bestämmande
- utvecklare
- Skillnaden
- olika
- distribueras
- distribuerad databehandling
- diy
- do
- dokumentation
- inte
- gör
- domäner
- gjort
- duva
- grund
- under
- varje
- Tidigare
- utbilda
- effektivitet
- effektivt
- antingen
- betona
- möjliggör
- uppmuntra
- änden
- Slutpunkt
- Motor
- Motorer
- säkerställa
- säkerställa
- Företag
- företag
- Hela
- Miljö
- fel
- Även
- Varje
- exempel
- exempel
- utbyte
- förvänta
- förväntat
- Erfarenheter
- export
- faktorer
- ganska
- Falls
- falsk
- Leverans
- Funktioner
- Fed
- matning
- få
- Figur
- Fil
- Filer
- hitta
- slut
- Förnamn
- flöda
- Fokus
- fokuserar
- följer
- följt
- efter
- Fotavtryck
- För
- formen
- format
- hittade
- Ramverk
- ramar
- bedrägeri
- Fri
- från
- Vidare
- resultat
- Allmänt
- genererar
- skaffa sig
- Ge
- ges
- GPU
- kraftigt
- Grupp
- Gruppens
- vägleda
- hända
- Hård
- hårdvara
- Har
- he
- hjälpa
- hjälpa
- hjälper
- här.
- högnivå
- högpresterande
- högre
- höjdpunkter
- hans
- hålla
- innehar
- värd
- värd
- värd
- Hur ser din drömresa ut
- How To
- Men
- html
- http
- HTTPS
- Hurt
- Identitet
- ids
- IDX
- if
- bild
- Inverkan
- Konsekvenser
- genomföra
- genomföras
- redskap
- import
- in
- innefattar
- Inklusive
- Öka
- pekar på
- informationen
- informeras
- ingång
- installera
- exempel
- instruktioner
- integrering
- Intelligens
- intresse
- inre
- in
- IT
- DESS
- jpg
- json
- bara
- Ha kvar
- Nyckel
- Snäll
- Vet
- Large
- Stora företag
- större
- Latens
- senaste
- Layout
- LÄRA SIG
- inlärning
- t minst
- Led
- legitim
- mindre
- Nivå
- nivåer
- Hävstång
- bibliotek
- Bibliotek
- tycka om
- BEGRÄNSA
- linje
- Lista
- läsa in
- Logiken
- logisk
- Lång
- Maskinen
- maskininlärning
- göra
- hantera
- många
- master
- Match
- max
- maximal
- Maj..
- mekanism
- Möt
- möte
- Minne
- nämnts
- Merchant
- Metrics
- kanske
- migrera
- emot
- ML
- Mode
- modell
- modeller
- Månad
- mer
- mest
- Mest populär
- flytta
- Multi-Model Endpoint
- multipel
- måste
- namn
- namngivning
- nativ
- Behöver
- behov
- Nya
- nlp
- Nej
- noder
- anteckningsbok
- nu
- antal
- numpy
- Nvidia
- få
- of
- erbjudanden
- Erbjudanden
- Ofta
- on
- ONE
- ettor
- endast
- öppen källkod
- optimala
- optimering
- Optimera
- optimerad
- optimera
- Alternativet
- Tillbehör
- or
- beställa
- organisationer
- Organiserad
- ursprungligen
- OS
- Övriga
- annat
- vår
- ut
- produktion
- utanför
- egen
- paket
- förpackning
- pandor
- Parallell
- parameter
- parametrar
- deltagande
- särskilt
- Godkänd
- passerar
- bana
- Utföra
- prestanda
- utför
- tillstånd
- fotografi
- rörledning
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- i
- snälla du
- uppsjö
- Strategier
- policy
- poolen
- Populära
- popularitet
- möjlig
- eventuellt
- Inlägg
- kraft
- förutse
- Förutsägbar
- förutsagda
- förutsägelse
- Förutsägelser
- tidigare
- primär
- Principal
- problem
- process
- processer
- bearbetning
- Process kraft
- processorer
- producera
- Produktion
- projekt
- rätt
- proto
- ge
- förutsatt
- leverantör
- ger
- tillhandahålla
- Python
- pytorch
- slumpmässig
- som sträcker sig
- snarare
- Raw
- redo
- verkliga världen
- realtid
- skäl
- rekommenderar
- minska
- avses
- Oavsett
- region
- relaterad
- relevanta
- ersätta
- Repository
- representation
- representerar
- representerar
- begära
- förfrågningar
- kräver
- Obligatorisk
- Krav
- Kräver
- respons
- ansvarig
- resultera
- Resultat
- Roll
- Körning
- rinnande
- s
- sagemaker
- SageMaker Inference
- Samma
- Besparingar
- skalbar
- Skala
- skalning
- scenarier
- schemaläggning
- Vetenskap
- vetenskapsmän
- scikit lära
- göra
- §
- se
- söker
- vald
- sända
- senior
- separat
- tjänar
- service
- Leverantör
- Tjänster
- portion
- in
- inställning
- inställningar
- Forma
- delas
- skall
- show
- Visar
- sida
- signifikant
- liknande
- Enkelt
- enda
- Storlek
- storlekar
- So
- lösning
- Lösningar
- LÖSA
- Lösa
- några
- Källa
- specialiserat
- specifik
- specifikation
- specificerade
- spendera
- standard
- starta
- Starta
- Startups
- Ange
- status
- stadig
- Steg
- Steg
- förvaring
- lagra
- lagras
- okomplicerad
- Sträng
- struktur
- framgångsrik
- sådana
- föreslå
- lämplig
- stödja
- Som stöds
- Stöder
- Ta
- grupp
- tekniker
- Tekniken
- Teknologi
- tala
- villkor
- än
- den där
- Smakämnen
- den information
- deras
- Dem
- sedan
- Där.
- Dessa
- de
- sak
- detta
- de
- fastän?
- tre
- tröskelvärde
- genomströmning
- tid
- till
- i dag
- tillsammans
- toppnivå
- traditionellt
- tränad
- Utbildning
- Överföra
- Traveling
- träd
- Trender
- Triton
- sann
- två
- Typ
- typer
- typiskt
- förstå
- uppladdad
- uppladdning
- us
- användning
- Begagnade
- Användare
- med hjälp av
- Återvinnare
- Använda
- värde
- Värden
- olika
- version
- via
- syn
- W
- vänta
- vill
- var
- tittar
- Sätt..
- we
- webb
- webbservice
- VÄL
- były
- Vad
- när
- närhelst
- om
- som
- medan
- kommer
- med
- inom
- utan
- Arbete
- arbetade
- arbetstagaren
- fungerar
- skulle
- XGBoost
- år
- Om er
- Din
- zephyrnet
- Postnummer