Saavutage mudelite teenindamiseks hüperskaala jõudlus, kasutades Amazon SageMakeris asuvat NVIDIA Triton järeldusserverit

Masinõppe (ML) rakendusi on keeruline juurutada ja ühe järelduspäringu teenindamiseks on sageli vaja mitut ML-mudelit. Tüüpiline päring võib liikuda mitme mudeli vahel koos selliste etappidega nagu eeltöötlus, andmete teisendamine, mudelivaliku loogika, mudelite koondamine ja järeltöötlus. See on toonud kaasa levinud kujundusmustrite, nagu jadajärelduskonveierid, ansamblid (hajutuskogumine) ja äriloogika töövood, arengu, mille tulemuseks on kogu päringu töövoo realiseerimine suunatud atsüklilise graafikuna (DAG). Kuna aga töövood muutuvad keerukamaks, suurendab see nende rakenduste üldist reageerimisaega või latentsust, mis omakorda mõjutab üldist kasutajakogemust. Lisaks, kui neid komponente hostitakse erinevatel eksemplaridel, suurendab nende eksemplaride vaheline täiendav võrgulatentsus üldist latentsust. Vaatleme näidet populaarsest ML-i kasutusjuhtumist klienditoe virtuaalse assistendi jaoks. Tüüpiline taotlus võib läbida mitu etappi, mis hõlmavad kõnetuvastust, loomuliku keele töötlemist (NLP), dialoogi oleku jälgimist, dialoogipoliitikat, teksti genereerimist ja lõpuks tekst kõneks. Lisaks võite kasutaja interaktsiooni isikupärasemaks muutmiseks kasutada ka nüüdisaegseid trafopõhiseid NLP-mudeleid, nagu erinevad versioonid BERT, BARTja GPT. Lõpptulemus on nende mudelikomplektide pikad reageerimisajad ja kehv kliendikogemus.

Levinud muster lühemate reageerimisaegade saavutamiseks ilma üldist läbilaskevõimet kahjustamata on nende mudelite majutamine samal eksemplaril koos sellesse manustatud kerge äriloogikaga. Neid mudeleid saab lisaks kapseldada ühte või mitmesse konteinerisse samal eksemplaril, et tagada töötavate protsesside isolatsioon ja hoida latentsusaeg madal. Lisaks sõltub üldine latentsus ka järeldamisrakenduse loogikast, mudeli optimeerimisest, aluseks olevast infrastruktuurist (sealhulgas arvutus, salvestus ja võrgundus) ja aluseks olevast veebiserverist, mis võtab järelduspäringuid. NVIDIA Tritoni järeldusserver on avatud lähtekoodiga järelduste teenindamise tarkvara, mille funktsioonid maksimeerivad läbilaskevõimet ja riistvara kasutust ülimadala (ühekohalise millisekundilise) järelduste latentsusajaga. Sellel on laialdane tugi ML-i raamistikele (sh TensorFlow, PyTorch, ONNX, XGBoost ja NVIDIA TensorRT) ja infrastruktuuri taustaprogrammidele, sealhulgas GPU-d, CPU-d ja AWS Inferentia. Lisaks on integreeritud Triton Inference Server Amazon SageMaker, täielikult hallatav otsast lõpuni ML-teenus, mis pakub reaalajas järeldusvõimalusi, sealhulgas ühekordne ja mitme mudeliga hostimine. Need järeldusvõimalused hõlmavad mitme mudeli majutamist samas konteineris a taga üks lõpp-punktja hostimine mitu mudelit mitme konteineriga ühe lõpp-punkti taga.

2021. aasta novembris teatasime Triton Inference Serveri integreerimine SageMakerisse. AWS tegi tihedat koostööd NVIDIAga, et saaksite mõlemast maailmast parima ja hõlbustada mudeli juurutamist Tritoniga AWS-is.

Selles postituses vaatleme parimaid tavasid trafomudelite mastaabis juurutamiseks GPU-dele, kasutades SageMakeris Triton Inference Server. Esiteks alustame SageMakeri latentsusaja põhikontseptsioonide kokkuvõttega ja jõudluse häälestamise juhiste ülevaatega. Järgmisena anname ülevaate Tritonist ja selle funktsioonidest ning näite koodist SageMakeris juurutamiseks. Lõpuks viime läbi koormustestid kasutades SageMakeri järelduste soovitus ning tehke kokkuvõte Hugging Face'i populaarse trafomudeli koormustestimisest saadud arusaamadest ja järeldustest.

Saate vaadata märkmik kasutasime ise mudelite juurutamiseks ja koormustestide läbiviimiseks, kasutades koodi sees GitHub.

Jõudluse häälestamine ja optimeerimine SageMakeris mudelite esitamiseks

Jõudluse häälestamine ja optimeerimine on empiiriline protsess, mis hõlmab sageli mitut iteratsiooni. Häälestatavate parameetrite arv on kombineeritud ja konfiguratsiooniparameetrite väärtuste komplekt ei ole üksteisest sõltumatu. Parameetrite optimaalset häälestamist mõjutavad mitmesugused tegurid, sealhulgas kasuliku koormuse suurus, tüüp ja ML-mudelite arv järelduspäringu voograafikus, salvestustüüp, arvutuseksemplari tüüp, võrguinfrastruktuur, rakenduse kood, järeldusi teenindava tarkvara käitusaeg ja konfiguratsioon ning palju muud.

Kui kasutate ML-mudelite juurutamiseks SageMakerit, peate valima parima hinna ja kvaliteedi suhtega arvutuseksemplari, mis on keeruline ja korduv protsess, mis võib võtta nädalaid katsetamist. Esiteks peate oma mudelite ressursinõuete ja sisendandmete suuruse põhjal valima enam kui 70 valiku hulgast õige ML-i eksemplari tüübi. Järgmiseks peate mudeli valitud eksemplari tüübi jaoks optimeerima. Lõpuks peate pakkuma ja haldama infrastruktuuri, et käitada koormusteste ja häälestada pilvekonfiguratsiooni optimaalse jõudluse ja kulude saavutamiseks. Kõik see võib mudeli kasutuselevõttu ja turule jõudmist edasi lükata. Lisaks peate optimaalse juurutuse konfiguratsiooni valimiseks hindama kompromisse latentsusaja, läbilaskevõime ja kulude vahel. SageMakeri järelduste soovitus valib automaatselt õige arvutuseksemplari tüübi, eksemplaride arvu, konteineri parameetrid ja mudeli optimeerimised järelduste tegemiseks, et maksimeerida läbilaskevõimet, vähendada latentsust ja minimeerida kulusid.

Reaalajas järeldused ja latentsus SageMakeris

SageMakeri reaalajas järeldus on ideaalne järelduste tegemiseks, kus teil on reaalajas, interaktiivsed ja madala latentsusajaga nõuded. SageMakeri järelduste lõpp-punktide järeldamispäringute latentsusaja jälgimiseks on neli kõige sagedamini kasutatavat mõõdikut

• Konteiner latentsus – Aeg, mis kulub päringu saatmiseks, mudeli konteinerist vastuse toomiseks ja konteineris järelduste tegemiseks. See mõõdik on Amazon CloudWatchis saadaval osana Väljakutsumise mõõdikud avaldas SageMaker.
• Mudeli latentsus – Kõigi SageMakeri konteinerite koguaeg ühes järelduste torujuhe. See mõõdik on Amazon CloudWatchis saadaval osana Väljakutsumise mõõdikud avaldas SageMaker.
• Üldkulud latentsusaeg – Mõõdetakse ajast, mil SageMaker päringu saab, kuni kliendile vastuse tagastamiseni, millest on maha arvatud mudeli latentsusaeg. See mõõdik on Amazon CloudWatchis saadaval osana Väljakutsumise mõõdikud avaldas SageMaker.
• Otsast lõpuni latentsusaeg – Mõõdetakse ajast, mil klient saadab järelduspäringu, kuni vastuse saamiseni. Kliendid saavad selle Amazon CloudWatchis kohandatud mõõdikuna avaldada.

Järgmine diagramm illustreerib neid komponente.

Konteineri latentsusaeg sõltub mitmest tegurist; järgmised on ühed kõige olulisemad:

• Alusprotokoll (HTTP(id)/gRPC), mida kasutatakse järeldusserveriga suhtlemiseks
• Uute TLS-ühenduste loomisega seotud üldkulud
• Päringu/vastuse kasuliku koormuse serialiseerimisaeg
• Taotlege aluseks oleva järeldusserveri pakutavaid järjekorda seadmise ja komplekteerimise funktsioone
• Taotlege aluseks oleva järeldusserveri pakutavaid ajastamisvõimalusi
• Järeldusserveri käitusaegne toimivus
• Eel- ja järeltöötlusteekide jõudlus enne mudeli ennustusfunktsiooni väljakutsumist
• ML-i raamistiku taustaprogrammi jõudlus
• Mudelispetsiifilised ja riistvarapõhised optimeerimised

Selles postituses keskendume peamiselt konteineri latentsuse optimeerimisele koos üldise läbilaskevõime ja kuludega. Täpsemalt uurime jõudluse häälestamist Triton Inference Server, mis töötab SageMakeri konteineris.

Kasutusjuhtumi ülevaade

NLP-mudelite juurutamine ja skaleerimine tootmisseadistuses võib olla üsna keeruline. NLP mudelid on sageli väga suured, sisaldades miljoneid mudeli parameetreid. Tootmistasemel NLP-rakenduste rangete jõudluse ja mastaapsuse nõuete täitmiseks on vaja optimaalseid mudelikonfiguratsioone.

Selles postituses võrdleme NLP-kasutusjuhtumit, kasutades SageMakeri reaalajas lõpp-punkti, mis põhineb Triton Inference Serveri konteineril, ja soovitame jõudluse optimeerimist meie ML-i kasutusjuhtumi jaoks. Kasutame suurt, eelkoolitatud trafopõhist Hugging Face'i BERT suur ümbriseta mudel, millel on umbes 336 miljonit mudeliparameetrit. Binaarse klassifikatsioonimudeli jaoks kasutatav sisendlause on polsterdatud ja kärbitud maksimaalse sisendjada pikkuseni 512 märgini. Järelduskoormustest simuleerib 500 kutset sekundis (maksimaalselt 30,000 XNUMX kutsumist minutis) ja ModelLatency vähem kui 0.5 sekundit (500 millisekundit).

Järgmine tabel võtab kokku meie võrdlusaluse konfiguratsiooni.

NVIDIA Tritoni järeldusserver

Triton Inference Server on spetsiaalselt loodud võimaldama mudelite skaleeritavat, kiiret ja hõlpsat juurutamist tootmisprotsessis. Triton toetab mitmesuguseid suuremaid tehisintellekti raamistikke, sealhulgas TensorFlow, TensorRT, PyTorch, XGBoost ja ONNX. Pythoni ja C++ kohandatud taustaprogrammiga saate kohandatud kasutusjuhtumite jaoks rakendada ka järelduste töökoormust.

Kõige tähtsam on see, et Triton pakub teie mudelite majutamiseks lihtsat konfiguratsioonipõhist seadistust, mis toob esile rikkaliku komplekti jõudluse optimeerimise funktsioone, mida saate kasutada vähese kodeerimisega.

Triton suurendab järelduste jõudlust, maksimeerides riistvara kasutamist erinevate optimeerimistehnikatega (kõige sagedamini kasutatakse mudelite samaaegset käitamist ja dünaamilist komplekteerimist). Optimaalsete mudelikonfiguratsioonide leidmine dünaamiliste partiisuuruste ja samaaegsete mudelieksemplaride arvu erinevatest kombinatsioonidest on Tritoni abil reaalajas järelduste tegemise võti.

Dünaamiline komplekteerimine

Paljud praktikud kipuvad tegema järeldusi järjestikku, kui serverit kutsutakse mitme sõltumatu päringuga. Kuigi seadistamine on lihtsam, ei ole see tavaliselt parim tava kasutada GPU arvutusvõimsust. Selle probleemi lahendamiseks pakub Triton sisseehitatud optimeerimisi dünaamiline komplekteerimine ühendada need sõltumatud järelduspäringud serveri poolel, et moodustada läbilaskevõime suurendamiseks dünaamiliselt suurem partii. Järgmine diagramm illustreerib Tritoni käitusaja arhitektuuri.

Eelmises arhitektuuris jõuavad kõik päringud kõigepealt dünaamilise komplekti, enne kui sisenevad tegelikesse mudeliplaanija järjekordadesse, et oodata järeldusi. Saate määrata dünaamilise partii eelistatud suurused, kasutades eelistatud_partii_suurus seaded mudeli konfiguratsioonis. (Pange tähele, et moodustatud partii suurus peab olema väiksem kui max_partii_suurus mudel toetab.) Saate ka konfigureerida max_queue_delay_microseconds et määrata komplektis maksimaalne viivitusaeg, et oodata, kuni teised paketiga liituvad taotlused teie latentsusnõuete alusel.

Järgmine koodilõik näitab, kuidas saate selle funktsiooni lisada mudeli konfiguratsioonifailidele, et määrata tegeliku järelduse jaoks dünaamiline komplekteerimine eelistatud partii suurusega 16. Praeguste sätete korral käivitatakse mudeli eksemplar kohe, kui eelistatud partii suurus 16 on täidetud või kui esimesest päringust dünaamilise komplekti jõudmisest on möödunud 100 mikrosekundi viivitusaeg.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Mudelite samaaegne käitamine

Teine Tritonis pakutav oluline optimeerimine riistvara kasutamise maksimeerimiseks ilma täiendava latentsusaja lisakuludeta on mudeli samaaegne täitmine, mis võimaldab paralleelselt töötada mitmel mudelil või sama mudeli mitmel koopial. See funktsioon võimaldab Tritonil käsitleda korraga mitut järelduspäringut, mis suurendab järelduste läbilaskevõimet, kasutades riistvara muidu jõudeolekut.

Järgmisel joonisel on näidatud, kuidas saate hõlpsalt konfigureerida erinevaid mudeli juurutuspoliitikaid vaid mõne koodirea muudatustega. Näiteks konfiguratsioon A (vasakul) näitab, et saate edastada kahe mudeli eksemplari sama konfiguratsiooni bert-large-uncased kõigile saadaolevatele GPU-dele. Seevastu konfiguratsioon B (keskmine) näitab teistsugust konfiguratsiooni ainult GPU 0 jaoks, muutmata teiste GPU-de eeskirju. Saate juurutada ka erinevate mudelite eksemplare ühes GPU-s, nagu on näidatud konfiguratsioonis C (paremal).

Konfiguratsioonis C saab arvutuseksemplari käsitleda kahte samaaegset päringut DistilGPT-2 mudeli jaoks ja seitset samaaegset päringut mudeli jaoks. bert-large-uncased mudel paralleelselt. Nende optimeerimiste abil saab riistvararessursse teenindusprotsessis paremini ära kasutada, parandades seeläbi läbilaskevõimet ja pakkudes teie töökoormuse jaoks paremat kuluefektiivsust.

TensorRT

NVIDIA TensorRT on SDK suure jõudlusega sügava õppimise järelduste tegemiseks, mis töötab sujuvalt Tritoniga. TensorRT, mis toetab kõiki suuremaid süvaõppe raamistikke, sisaldab järelduste optimeerijat ja käitusaega, mis tagab väikese latentsuse ja suure läbilaskevõime, et võimsate optimeerimiste abil teha järeldusi suure andmemahuga.

TensorRT optimeerib graafikut, et minimeerida mäluruumi, vabastades tarbetut mälu ja kasutades seda tõhusalt. Lisaks ühendab TensorRT-i kompilatsioon mudeligraafiku hõredad toimingud, et moodustada suurem tuum, et vältida mitme väikese kerneli käivitamise ülekoormust. Kerneli automaatne häälestamine aitab teil riistvara täielikult ära kasutada, valides teie siht-GPU jaoks parima algoritmi. CUDA vood võimaldavad mudelitel paralleelselt töötada, et maksimeerida teie GPU kasutust parima jõudluse saavutamiseks. Viimaseks, kuid mitte vähemtähtsaks, saab kvantimistehnika täielikult ära kasutada Tensori tuumade segatäpseid kiirendusi, et käitada mudelit FP32, TF32, FP16 ja INT8 puhul, et saavutada parim järelduste jõudlus.

Triton SageMakeri hostimisel

SageMakeri hostimine teenused on SageMakeri funktsioonide komplekt, mille eesmärk on muuta mudeli juurutamine ja teenindamine lihtsamaks. See pakub mitmesuguseid võimalusi erinevateks kasutusjuhtudeks kohandatud ML-mudelite hõlpsaks juurutamiseks, automaatseks skaleerimiseks, jälgimiseks ja optimeerimiseks. See tähendab, et saate optimeerida oma juurutusi igat tüüpi kasutusmustrite jaoks, alates püsivast ja alati saadaval olevast serverita suvanditega kuni mööduvate, pikaajaliste või partii järelduste vajadusteni.

SageMakeri hostimise katuse all on ka SageMakeri järelduste süvaõppekonteinerite (DLC-de) komplekt, mis on pakitud koos vastava toetatud ML-raamistiku jaoks sobiva mudeliserveri tarkvaraga. See võimaldab teil saavutada suure järelduste jõudluse ilma mudeliserveri seadistamiseta, mis on sageli mudeli juurutamise kõige keerulisem tehniline aspekt ja üldiselt ei kuulu andmeteadlase oskuste hulka. Tritoni järeldusserver on nüüd olemas saadaval SageMakeri süvaõppe konteinerites (DLC).

See valikute laius, modulaarsus ja erinevate serveerimisraamistike kasutuslihtsus muudavad SageMakeri ja Tritoni võimsa vaste.

SageMaker Inference Recommender testide tulemuste võrdlemiseks

Kasutame katsete läbiviimiseks SageMaker Inference Recommenderit. SageMaker Inference Recommender pakub kahte tüüpi töid: vaike- ja täiustatud töid, nagu on näidatud järgmisel diagrammil.

Vaiketöö pakub soovitusi eksemplaritüüpide kohta, kasutades võrdlusuuringu jaoks ainult mudelit ja näidiskoormust. Lisaks näidissoovitustele pakub teenus ka käitusparameetreid, mis parandavad jõudlust. Vaikimisi töö soovitused on mõeldud eksemplari otsingu kitsendamiseks. Mõnel juhul võib see olla eksemplari perekond ja mõnel juhul võib see olla konkreetse eksemplari tüüp. Vaiketöö tulemused sisestatakse seejärel täpsemasse töösse.

Täiustatud töö pakub jõudluse edasiseks viimistlemiseks rohkem juhtelemente. Need juhtelemendid simuleerivad tegelikku keskkonda ja tootmisnõudeid. Nende juhtelementide hulgas on liiklusmuster, mille eesmärk on lavastada võrdlusaluste päringu muster. Saate määrata kaldteed või ühtlast liiklust, kasutades liiklusmustri mitut faasi. Näiteks an InitialNumberOfUsers 1, SpawnRate 1-st ja KestusSekundites 600-st võib põhjustada 10-minutilise rambiliikluse, kui alguses on 1 ja lõpus 10 samaaegset kasutajat. Lisaks on juhtnuppudel MaxInvocations ja Model Latency Thresholds määrake tootmislävi, nii et kui üks künnistest on ületatud, siis võrdlusuuringud peatuvad.

Lõpuks soovituse mõõdikud sisaldab läbilaskevõimet, latentsust maksimaalsel läbilaskevõimel ja kulu ühe järelduse kohta, nii et neid on lihtne võrrelda.

Kasutame katsete läbiviimiseks SageMaker Inference Recommenderi täpsemat töötüüpi, et saada täiendavat kontrolli liiklusmustrite üle ja täpsustada serveerimiskonteineri konfiguratsiooni.

Katse seadistamine

Kasutame meie kasutusjuhtumis kirjeldatud NLP-profiili võrdlemiseks SageMaker Inference Recommenderi kohandatud koormustesti funktsiooni. Esmalt määratleme järgmised NLP mudeli ja ML ülesandega seotud eeldused. SageMaker Inference Recommender kasutab seda teavet järelduse Dockeri kujutise tõmbamiseks Amazoni elastsete konteinerite register (Amazon ECR) ja registreerige mudel SageMakeri mudeliregistris.

Liiklusmustri konfiguratsioonid SageMaker Inference Recommenderis võimaldavad meil määratleda kohandatud koormustesti erinevad faasid. Koormustest algab kahe algse kasutajaga ja iga minut sünnitab kaks uut kasutajat kokku 25 minutiks (1500 sekundiks), nagu on näidatud järgmises koodis:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Katsetame sama mudeli koormustestimist kahes erinevas olekus. PyTorchil põhinevad katsed kasutavad standardset muutmata PyTorchi mudelit. TensorRT-põhiste katsete jaoks teisendame PyTorchi mudeli eelnevalt TensorRT mootoriks.

Kasutame nende kahe mudeli puhul erinevaid toimivuse optimeerimise funktsioonide kombinatsioone, mille kokkuvõte on esitatud järgmises tabelis.

Katsetulemused ja tähelepanekud

Tegime koormustestid kolme eksemplaritüübi jaoks samas g4dn perekonnas: ml.g4dn.xlarge, ml.g4dn.2xlarge ja ml.g4dn.12xlarge. Kõigil g4dn-i eksemplaritüüpidel on juurdepääs NVIDIA T4 Tensor Core GPU-dele ja 2. põlvkonna Intel Cascade Lake protsessoritele. Eksemplaritüüpide valiku loogika seisnes selles, et saadaval oli nii ainult ühe GPU-ga eksemplar kui ka eksemplar, millel on juurdepääs mitmele GPU-le – ml.g4dn.12xlarge puhul neljale. Lisaks soovisime testida, kas eksemplari vCPU võimsuse suurendamine ainult ühe saadaoleva GPU-ga tooks kaasa kulu-jõudluse suhte paranemise.

Vaatame kõigepealt individuaalse optimeerimise kiirendamist. Järgmine graafik näitab, et TensorRT optimeerimine vähendab mudeli latentsust 50% võrreldes PyTorchi algse latentsusega eksemplaris ml.g4dn.xlarge. See latentsusaja vähenemine kasvab mitme GPU-ga ml.g4dn.12xlarge eksemplaridel üle kolme korra. Samal ajal on 30% läbilaskevõime paranemine mõlemal juhul ühtlane, mille tulemuseks on pärast TensorRT optimeerimiste rakendamist parem kuluefektiivsus.

Dünaamilise pakkimise abil saame läbilaskevõimet peaaegu kaks korda parandada, kasutades sama riistvaraarhitektuuri kõigis katsetes ml.g2dn.xlarge, ml.g4dn.4xlarge ja ml.g2dn.4xlarge ilma märgatava latentsusaja suurenemiseta.

Sarnaselt võimaldab mudeli samaaegne täitmine saavutada umbes 3–4-kordse läbilaskevõime paranemise, maksimeerides GPU kasutust ml.g4dn.xlarge eksemplaril ja umbes 2 korda täiustuse nii ml.g4dn.2xlarge eksemplaril kui ka mitme GPU-ga ml eksemplaril. g4dn.12xlarge. See läbilaskevõime suurenemine toimub ilma latentsusaja lisakuludeta.

Veelgi parem, saame riistvararessursse maksimaalselt ära kasutades integreerida kõik need optimeerimised, et tagada parim jõudlus. Järgmine tabel ja graafikud võtavad kokku oma katsetes saadud tulemused.

[1] Esialgne eksemplaride arv ülaltoodud tabelis on soovitatav arv eksemplare, mida automaatse skaleerimise poliitikaga kasutada, et säilitada teie töökoormuse läbilaskevõime ja latentsusnõuded.

[2] Ülaltoodud tabelis on tunni hind arvutatud eksemplari tüübi esialgse eksemplari arvu ja hinna alusel.

Tulemused kinnitavad enamasti erinevate jõudluse optimeerimise funktsioonide eeldatavat mõju.

• TensorRT-i kompileerimisel on kõigi eksemplaritüüpide jaoks kõige usaldusväärsem mõju. Tehingute arv minutis eksemplari kohta kasvas 30–35% ja kulud vähenesid pidevalt ligikaudu 25% võrreldes TensorRT mootori jõudlusega PyTorchi vaikeseadega BERT (pt-base). TensorRT mootori suuremat jõudlust täiendavad ja kasutavad ära teised testitud jõudluse häälestamise funktsioonid.
• Kahe mudeli laadimine igale GPU-le (eksemplarirühmale) kahekordistas kõik mõõdetud mõõdikud peaaegu rangelt. Kutsumiste arv minutis eksemplari kohta kasvas ligikaudu 80–90%, mis andis kulude vähenemise 50% ulatuses, peaaegu nagu kasutaksime kahte GPU-d. Tegelikult, Amazon CloudWatch Meie g4dn.2xlarge katsete mõõdikud (näitena) kinnitavad, et nii CPU kui ka GPU kasutus kahekordistub, kui konfigureerime kahe mudeli eksemplarirühma.

Täiendavad jõudluse ja kulude optimeerimise näpunäited

Selles postituses esitatud võrdlusalus kriimustas lihtsalt võimalike funktsioonide ja tehnikate pinda, mida saate Tritoniga järelduste toimivuse parandamiseks kasutada. Need ulatuvad andmete eeltöötlustehnikatest, nagu binaarsete kasulike koormuste saatmine mudeliserverisse või suuremate partiidega kasulike koormuste saatmine, Tritoni natiivsete funktsioonideni, nagu järgmised:

• Mudeli soojendus, mis hoiab ära esialgsed aeglased järelduspäringud, initsialiseerides mudeli täielikult enne esimese järelduspäringu saamist.
• Vastuste vahemälu, mis salvestab korduvad päringud vahemällu.
• Modellide komplekteerimine, mis võimaldab luua ühest või mitmest mudelist koosneva konveieri ja ühendada nende mudelite vahel sisend- ja väljundtensorid. See avab võimaluse lisada iga päringu töötlemisvoogu eel- ja järeltöötlusetappe või isegi järeldusi teiste mudelite põhjal.

Loodame tulevases postituses neid tehnikaid ja funktsioone testida ja võrrelda, nii et olge kursis!

Järeldus

Selles postituses uurisime mõnda parameetrit, mida saate kasutada oma SageMakeri reaalajas lõpp-punkti jõudluse maksimeerimiseks PyTorchi BERT-mudelite teenindamiseks Triton Inference Serveriga. Nende parameetrite viimistlemiseks kasutasime võrdlustestide läbiviimiseks SageMaker Inference Recommenderit. Need parameetrid on sisuliselt seotud TensorRT-põhise mudeli optimeerimisega, mille tulemusel paraneb reageerimisaeg peaaegu 50% võrreldes optimeerimata versiooniga. Lisaks suurendas mudelite samaaegne käitamine ja Tritoni dünaamilise partiide kasutamine läbilaskevõime peaaegu 70%. Nende parameetrite peenhäälestus tõi kaasa ka järelduskulude üldise vähenemise.

Parim viis õigete väärtuste tuletamiseks on katsetamine. Et aga alustada empiiriliste teadmiste loomist jõudluse häälestamise ja optimeerimise kohta, saate jälgida erinevate Tritoniga seotud parameetrite kombinatsioone ja nende mõju jõudlusele ML-mudelites ja SageMaker ML-i eksemplarides.

SageMaker pakub tööriistu ML-i elutsükli igast etapist eristamata raskete raskuste eemaldamiseks, hõlbustades sellega kiiret katsetamist ja uurimist, mis on vajalik teie mudeli juurutamise täielikuks optimeerimiseks.

Koormustestimiseks ja juurutamiseks kasutatava sülearvuti leiate aadressilt GitHub. Saate värskendada Tritoni konfiguratsioone ja SageMaker Inference Recommenderi sätteid, et need sobiksid kõige paremini teie kasutusjuhtumiga, et saavutada kulutõhusad ja kõige paremini toimivad järelduste töökoormused.

Autoritest

Vikram Elango on AI/ML spetsialistilahenduste arhitekt ettevõttes Amazon Web Services, mis asub USA Virginias. Vikram aitab finants- ja kindlustussektori klientidel projekteerimisel ja läbimõeldud juhtimisel luua ja juurutada laiaulatuslikult masinõpperakendusi. Praegu on ta keskendunud loomuliku keele töötlemisele, vastutustundlikule tehisintellektile, järelduste optimeerimisele ja ML-i skaleerimisele kogu ettevõttes. Vabal ajal meeldib talle perega reisida, matkata, süüa teha ja telkida.

João Moura on AI/ML-i spetsialistilahenduste arhitekt ettevõttes Amazon Web Services. Ta keskendub peamiselt NLP kasutusjuhtudele ja aitab klientidel optimeerida süvaõppe mudeli koolitust ja juurutamist. Samuti on ta aktiivne madala koodiga ML-lahenduste ja ML-le spetsialiseerunud riistvara pooldaja.

Mohan Gandhi on AWS-i vanemtarkvarainsener. Ta on olnud AWS-is viimased 9 aastat ja töötanud erinevate AWS-teenustega, nagu EMR, EFA ja RDS Outpostsis. Praegu on ta keskendunud SageMakeri järelduskogemuse täiustamisele. Vabal ajal meeldib talle matkata ja maratone joosta.

Dhawal Patel on AWS-i peamine masinõppearhitekt. Ta on töötanud hajutatud andmetöötluse ja tehisintellektiga seotud probleemide lahendamisel organisatsioonidega alates suurettevõtetest kuni keskmise suurusega idufirmadeni. Ta keskendub süvaõppele, sealhulgas NLP ja Computer Vision domeenidele. Ta aitab klientidel teha SageMakeris suure jõudlusega mudeli järeldusi.

Santosh Bhavani on Amazon SageMaker Elastic Inference meeskonna vanemtehniline tootejuht. Ta keskendub sellele, et aidata SageMakeri klientidel kiirendada mudeli järeldusi ja juurutamist. Vabal ajal meeldib talle reisida, tennist mängida ja palju Pu'eri teed juua.

Jiahong Liu on lahenduse arhitekt NVIDIA pilveteenuse pakkuja meeskonnas. Ta abistab kliente masinõppe ja AI-lahenduste kasutuselevõtul, mis võimendavad NVIDIA kiirendatud andmetöötlust, et lahendada nende koolitus- ja järeldusprobleemid. Vabal ajal naudib ta origamit, isetegemisprojekte ja korvpalli mängimist.

• Münditark. Euroopa parim Bitcoini ja krüptobörs.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. TASUTA PÄÄS.
• CryptoHawk. Altcoini radar. Tasuta prooviversioon.
• Allikas: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/