Aplicațiile de învățare automată (ML) sunt complexe de implementat și necesită adesea capacitatea de a se hiperscala și au cerințe de latență foarte scăzută și bugete de cost stricte. Cazurile de utilizare precum detectarea fraudelor, recomandările de produse și predicția traficului sunt exemple în care milisecundele contează și sunt esențiale pentru succesul afacerii. Trebuie îndeplinite acorduri stricte de nivel de serviciu (SLA), iar o cerere tipică poate necesita mai mulți pași, cum ar fi preprocesarea, transformarea datelor, ingineria caracteristicilor, logica de selecție a modelului, agregarea modelului și postprocesarea.
Implementarea modelelor ML la scară cu costuri optimizate și eficiență de calcul poate fi o sarcină descurajantă și greoaie. Fiecare model are propriile merite și dependențe bazate pe sursele de date externe, precum și pe mediul de rulare, cum ar fi puterea CPU/GPU a resurselor de calcul subiacente. O aplicație poate necesita mai multe modele ML pentru a servi o singură cerere de inferență. În anumite scenarii, o solicitare poate circula pe mai multe modele. Nu există o abordare universală și este important ca practicienii ML să caute metode încercate și dovedite pentru a aborda provocările recurente de găzduire ML. Acest lucru a condus la evoluția modelelor de design pentru găzduirea modelelor ML.
În această postare, explorăm modele de design comune pentru construirea aplicațiilor ML Amazon SageMaker.
Modele de proiectare pentru construirea de aplicații ML
Să ne uităm la următoarele modele de design pe care să le folosiți pentru găzduirea aplicațiilor ML.
Aplicații ML bazate pe un singur model
Aceasta este o opțiune excelentă atunci când cazul dvs. de utilizare ML necesită un singur model pentru a servi o solicitare. Modelul este implementat pe o infrastructură de calcul dedicată, cu capacitatea de a se scala în funcție de traficul de intrare. Această opțiune este, de asemenea, ideală atunci când aplicația client are o cerință de inferență cu o latență scăzută (de ordinul milisecundelor sau secundelor).
Aplicații ML bazate pe mai multe modele
Pentru a face găzduirea mai rentabilă, acest model de design vă permite să găzduiți mai multe modele pe aceeași infrastructură de chiriași. Mai multe modele ML pot partaja resursele gazdă sau container, inclusiv stocarea în cache a celor mai utilizate modele ML în memorie, ceea ce duce la o mai bună utilizare a memoriei și a resurselor de calcul. În funcție de tipurile de modele pe care ați ales să le implementați, co-găzduirea modelului poate folosi următoarele metode:
- Gazduire cu mai multe modele – Această opțiune vă permite să găzduiți mai multe modele folosind un container de servire partajat pe un singur punct final. Această caracteristică este ideală atunci când aveți un număr mare de modele similare pe care le puteți servi printr-un container de servire partajat și nu trebuie să accesați toate modelele în același timp.
- Gazduire cu mai multe containere – Această opțiune este ideală atunci când aveți mai multe modele care rulează pe stive de servire diferite cu nevoi de resurse similare și când modelele individuale nu au suficient trafic pentru a utiliza întreaga capacitate a instanțelor punctului final. Găzduirea cu mai multe containere vă permite să implementați mai multe containere care folosesc modele sau cadre diferite pe un singur punct final. Modelele pot fi complet eterogene, cu propria lor stivă de servire independentă.
- Ansambluri model – În multe cazuri de utilizare în producție, adesea pot exista multe modele din amonte care alimentează intrări unui anumit model din aval. Aici sunt utile ansamblurile. Modelele de ansamblu implică amestecarea rezultatelor de la unul sau mai multe modele de bază pentru a reduce eroare de generalizare a predicției. Modelele de bază pot fi diverse și antrenate prin diferiți algoritmi. Ansamblurile de modele pot depăși modelele individuale, deoarece eroarea de predicție a modelului scade atunci când este utilizată abordarea ansamblului.
Următoarele sunt cazuri obișnuite de utilizare a modelelor de ansamblu și diagramele lor de model de proiectare corespunzătoare:
- împrăștiați-adunați – Într-un model scatter-gather, o solicitare de inferență este direcționată către un număr de modele. Un agregator este apoi utilizat pentru a colecta răspunsurile și a le distila într-un singur răspuns de inferență. De exemplu, un caz de utilizare pentru clasificarea imaginilor poate folosi trei modele diferite pentru a efectua sarcina. Modelul scatter-gather vă permite să combinați rezultatele din inferențe executate pe trei modele diferite și să alegeți cel mai probabil model de clasificare.
- Agregat model – Într-un model de agregare, se face o medie a rezultatelor din mai multe modele. Pentru modelele de clasificare, predicțiile modelelor multiple sunt evaluate pentru a determina clasa care a primit cele mai multe voturi și este tratată ca rezultatul final al ansamblului. De exemplu, într-o problemă de clasificare cu două clase pentru a clasifica un set de fructe ca portocale sau mere, dacă două modele votează pentru o portocală și un model votează pentru un măr, atunci rezultatul agregat va fi o portocală. Agregarea ajută la combaterea inexactității modelelor individuale și face ca rezultatul să fie mai precis.
- Selecția dinamică – Un alt model pentru modelele de ansamblu este de a efectua dinamic selecția modelului pentru atributele de intrare date. De exemplu, într-o intrare dată de imagini de fructe, dacă intrarea conține o portocală, se va folosi modelul A deoarece este specializat pentru portocale. Dacă intrarea conține un măr, se va folosi modelul B deoarece este specializat pentru mere.
- Aplicații ML de inferență în serie – Cu un model de inferență în serie, cunoscut și ca o conductă de inferență, cazurile de utilizare au cerințe pentru a preprocesa datele primite înainte de a invoca un model ML pre-antrenat pentru generarea de inferențe. În plus, în unele cazuri, deducțiile generate ar putea fi nevoie să fie procesate în continuare, astfel încât să poată fi consumate cu ușurință de aplicațiile din aval. O conductă de inferență vă permite să reutilizați același cod de preprocesare utilizat în timpul antrenamentului de model pentru a procesa datele solicitate de inferență utilizate pentru predicții.
- Logica de afaceri – Producția ML implică întotdeauna logica de afaceri. Tiparele logicii de afaceri implică tot ceea ce este necesar pentru a efectua o sarcină ML care nu este inferența modelului ML. Aceasta include încărcarea modelului de la Serviciul Amazon de stocare simplă (Amazon S3), de exemplu, căutări de baze de date pentru a valida intrarea, obținerea de funcții precalculate din magazinul de caracteristici și așa mai departe. După ce acești pași logici de afaceri sunt finalizați, intrările sunt transmise modelelor ML.
Opțiuni de inferență ML
Pentru implementarea modelului, este important să lucrați înapoi din cazul dvs. de utilizare. Care este frecvența predicției? Vă așteptați la trafic live către aplicația dvs. și un răspuns în timp real pentru clienții dvs.? Aveți multe modele instruite pentru diferite subseturi de date pentru același caz de utilizare? Fluctuează traficul de predicție? Este latența de inferență o problemă? Pe baza acestor detalii, toate modelele de proiectare precedente pot fi implementate folosind următoarele opțiuni de implementare:
- Inferință în timp real – Inferența în timp real este ideală pentru sarcinile de lucru de inferență în care aveți cerințe în timp real, interactive și cu latență scăzută. Sarcinile de lucru ML în timp real pot include o aplicație ML bazată pe un singur model, în care o aplicație necesită un singur model ML pentru a servi o singură solicitare sau o aplicație ML bazată pe mai multe modele, în care o aplicație necesită mai multe modele ML pentru a servi o singură cerere. cerere.
- Inferență în timp aproape real (asincron). – Cu inferențe în timp aproape real, puteți pune în coadă cererile primite. Acest lucru poate fi utilizat pentru a rula inferențe pe intrări care sunt de sute de MB. Funcționează în timp aproape real și permite utilizatorilor să utilizeze intrarea pentru inferență și să citească ieșirea de la punctul final dintr-o găleată S3. Poate fi la îndemână mai ales în cazurile cu NLP și viziune computerizată, unde există sarcini utile mari care necesită timpi mai lungi de preprocesare.
- Inferență în lot – Inferența în lot poate fi utilizată pentru a rula inferența offline pe un set de date mare. Deoarece rulează offline, inferența în lot nu oferă cea mai mică latență. Aici, cererea de inferență este procesată fie cu un declanșator programat, fie bazat pe evenimente a unui job de inferență în lot.
- Inferență fără server – Inferența fără server este ideală pentru sarcinile de lucru care au perioade de inactivitate între exploziile de trafic și pot tolera câteva secunde suplimentare de latență (pornire la rece) pentru prima invocare după o perioadă de inactivitate. De exemplu, un serviciu chatbot sau o aplicație pentru procesarea formularelor sau analiza datelor din documente. În acest caz, este posibil să doriți o opțiune de inferență online care să poată furniza și scala automat capacitatea de calcul în funcție de volumul solicitărilor de inferență. Și în timpul inactiv, ar trebui să poată opri complet capacitatea de calcul, astfel încât să nu fiți încărcat. Inferența fără server elimină greutățile nediferențiate ale selectării și gestionării serverelor prin lansarea automată a resurselor de calcul și extinderea lor în funcție de trafic.
Utilizați funcțiile de fitness pentru a selecta opțiunea potrivită de inferență ML
Este important să decizi opțiunea de găzduire potrivită, deoarece afectează utilizatorii finali redați de aplicațiile tale. În acest scop, împrumutăm conceptul de funcții de fitness, care a fost inventat de Neal Ford și colegii săi de la AWS Partner ThoughtWorks în munca lor Construirea arhitecturii evolutive. Funcțiile de fitness oferă o evaluare prescriptivă a diferitelor opțiuni de găzduire în funcție de obiectivele clientului. Funcțiile de fitness vă ajută să obțineți datele necesare pentru a permite evoluția planificată a arhitecturii dumneavoastră. Ei stabilesc valori măsurabile pentru a evalua cât de aproape este soluția dvs. de atingerea obiectivelor stabilite. Funcțiile de fitness pot și ar trebui să fie adaptate pe măsură ce arhitectura evoluează pentru a ghida un proces de schimbare dorit. Acest lucru oferă arhitecților un instrument pentru a-și ghida echipele, menținând în același timp autonomia echipei.
Există cinci funcții principale de fitness la care clienții le pasă atunci când vine vorba de selectarea opțiunii potrivite de inferență ML pentru găzduirea modelelor și aplicațiilor ML.
Funcția fitness | Descriere |
A costat |
Implementarea și menținerea unui model ML și a unei aplicații ML pe un cadru scalabil este un proces de afaceri critic, iar costurile pot varia foarte mult în funcție de alegerile făcute cu privire la infrastructura de găzduire a modelului, opțiunea de găzduire, cadrele ML, caracteristicile modelului ML, optimizări, politica de scalare, și altele. Sarcinile de lucru trebuie să utilizeze infrastructura hardware în mod optim pentru a se asigura că costul rămâne sub control. Această funcție de fitness se referă în mod specific la costul infrastructurii, care este o parte a costului total total de proprietate (TCO). Costurile de infrastructură sunt costurile combinate pentru stocare, rețea și calcul. De asemenea, este esențial să înțelegeți alte componente ale TCO, inclusiv costurile operaționale și costurile de securitate și conformitate. Costurile operaționale sunt costurile combinate de operare, monitorizare și întreținere a infrastructurii ML. Costurile operaționale sunt calculate ca numărul de ingineri necesar pe baza fiecărui scenariu și salariul anual al inginerilor, agregat pe o anumită perioadă. Clienții care folosesc soluții ML autogestionate Cloud Elastic de calcul Amazon (Amazon EC2), Serviciul Amazon de containere elastice (Amazon ECS) și Serviciul Amazon Elastic Kubernetes (Amazon EKS) trebuie să construiască singuri instrumente operaționale. Clienții care folosesc SageMaker suportă mult mai puțin TCO. Inferența SageMaker este un serviciu complet gestionat și oferă capabilități ieșite din cutie pentru implementarea modelelor ML pentru inferență. Nu trebuie să furnizați instanțe, să monitorizați starea instanțelor, să gestionați actualizările de securitate sau patch-urile, să emiteți valori operaționale sau să creați monitorizare pentru sarcinile de lucru de inferență ML. Are capabilități încorporate pentru a asigura disponibilitate și rezistență ridicate. SageMaker acceptă securitate cu criptare end-to-end în repaus și în tranzit, inclusiv criptarea volumului rădăcină și Magazin Amazon Elastic Block (Amazon EBS) volum, Cloud virtual virtual Amazon suport (Amazon VPC), AWS PrivateLink, chei gestionate de client, Gestionarea identității și accesului AWS (IAM) control al accesului cu granulație fină, AWS CloudTrail audituri, criptare internod pentru instruire, control al accesului bazat pe etichete, izolarea rețelei și proxy de aplicație interactivă. Toate aceste caracteristici de securitate sunt furnizate de la pachet în SageMaker și pot economisi întreprinderilor zeci de luni de efort de inginerie de dezvoltare pe o perioadă de 3 ani. SageMaker este un serviciu eligibil HIPAA și este certificat conform PCI, SOC, GDPR și ISO. SageMaker acceptă, de asemenea, puncte terminale FIPS. Pentru mai multe informații despre TCO, consultați Costul total de proprietate al Amazon SageMaker. |
Latența de inferență | Multe modele și aplicații ML sunt critice pentru latență, în care latența de inferență trebuie să fie în limitele specificate de un obiectiv de nivel de serviciu. Latența de inferență depinde de o multitudine de factori, inclusiv dimensiunea și complexitatea modelului, platforma hardware, mediul software și arhitectura de rețea. De exemplu, modelele mai mari și mai complexe pot dura mai mult pentru a rula inferența. |
Debit (tranzacții pe secundă) | Pentru inferența modelului, optimizarea debitului este crucială pentru reglarea performanței și atingerea obiectivului de afaceri al aplicației ML. Pe măsură ce continuăm să avansăm rapid în toate aspectele ML, inclusiv implementările de nivel scăzut ale operațiilor matematice în proiectarea cipurilor, bibliotecile specifice hardware-ului joacă un rol mai important în optimizarea performanței. Diferiți factori, cum ar fi dimensiunea încărcăturii utile, hopurile de rețea, natura hopurilor, caracteristicile graficului modelului, operatorii din model și procesorul, GPU-ul și profilul de memorie al instanțelor de găzduire a modelului afectează debitul modelului ML. |
Scalarea complexității configurației | Este esențial ca modelele sau aplicațiile ML să ruleze pe un cadru scalabil care poate face față cererii de trafic variabil. De asemenea, permite utilizarea maximă a resurselor CPU și GPU și previne supraprovizionarea resurselor de calcul. |
Model de trafic așteptat | Modelele sau aplicațiile ML pot avea diferite modele de trafic, variind de la trafic continuu în timp real în timp real până la vârfuri periodice de mii de solicitări pe secundă și de la modele de solicitări rare, imprevizibile, până la solicitări de lot offline pe seturi de date mai mari. Este recomandat să lucrați înapoi de la modelul de trafic așteptat pentru a selecta opțiunea de găzduire potrivită pentru modelul dvs. ML. |
Implementarea modelelor cu SageMaker
SageMaker este un serviciu AWS complet gestionat care oferă fiecărui dezvoltator și cercetător de date capacitatea de a construi, antrena și implementa rapid modele ML la scară. Cu inferența SageMaker, vă puteți implementa modelele ML pe punctele finale găzduite și puteți obține rezultate de inferență. SageMaker oferă o selecție largă de hardware și caracteristici pentru a satisface cerințele dvs. de sarcină de lucru, permițându-vă să selectați peste 70 de tipuri de instanțe cu accelerare hardware. SageMaker poate oferi, de asemenea, recomandări de tip de instanță de inferență folosind o nouă caracteristică numită SageMaker Inference Recommender, în cazul în care nu sunteți sigur care dintre ele ar fi cea mai optimă pentru volumul dvs. de lucru.
Puteți alege opțiuni de implementare pentru a satisface cel mai bine cazurile dvs. de utilizare, cum ar fi inferența în timp real, punctele finale asincrone, lot și chiar fără server. În plus, SageMaker oferă diverse strategii de implementare, cum ar fi canary, albastru verde, umbrăși testare A/B pentru implementarea modelului, împreună cu implementarea rentabilă cu mai multe modele, puncte finale cu mai multe containere și scalare elastică. Cu inferența SageMaker, puteți vizualiza valorile de performanță pentru punctele finale în Amazon CloudWatch, scala automat punctele finale pe baza traficului și actualizați-vă modelele în producție fără a pierde disponibilitatea.
SageMaker oferă patru opțiuni pentru a vă implementa modelul, astfel încât să puteți începe să faceți predicții:
- Inferință în timp real – Acesta este potrivit pentru sarcinile de lucru cu cerințe de latență în milisecunde, dimensiuni de încărcare utilă de până la 6 MB și timpi de procesare de până la 60 de secunde.
- Transformarea lotului – Acesta este ideal pentru predicții offline pentru loturi mari de date care sunt disponibile în avans.
- Inferență asincronă – Acesta este conceput pentru încărcături de lucru care nu au cerințe de latență sub secundă, dimensiuni de încărcare utilă de până la 1 GB și timpi de procesare de până la 15 minute.
- Inferență fără server – Cu inferența fără server, puteți implementa rapid modele ML pentru inferență fără a fi nevoie să configurați sau să gestionați infrastructura de bază. În plus, plătiți doar pentru capacitatea de calcul utilizată pentru a procesa cererile de inferență, ceea ce este ideal pentru sarcinile de lucru intermitente.
Următoarea diagramă vă poate ajuta să înțelegeți opțiunile de implementare a modelului de găzduire SageMaker împreună cu evaluările asociate funcției de fitness.
Să explorăm fiecare dintre opțiunile de implementare mai detaliat.
Inferență în timp real în SageMaker
Inferența în timp real SageMaker este recomandată dacă aveți trafic susținut și aveți nevoie de o latență mai mică și consecventă pentru solicitările dvs., cu dimensiuni de încărcare utilă de până la 6 MB și timpi de procesare de până la 60 de secunde. Implementați modelul dvs. în serviciile de găzduire SageMaker și obțineți un punct final care poate fi utilizat pentru inferență. Aceste puncte finale sunt complet gestionate și acceptă scalarea automată. Inferența în timp real este populară pentru cazurile de utilizare în care vă așteptați la un răspuns sincron cu latență scăzută, cu modele de trafic previzibile, cum ar fi recomandări personalizate pentru produse și servicii sau cazuri de utilizare pentru detectarea fraudei tranzacționale.
De obicei, o aplicație client trimite cereri către punctul final HTTPS SageMaker pentru a obține inferențe dintr-un model implementat. Puteți implementa mai multe variante ale unui model la același punct final HTTPS SageMaker. Acest lucru este util pentru testarea variațiilor unui model în producție. Scalare automată vă permite să ajustați dinamic numărul de instanțe furnizate pentru un model ca răspuns la modificările volumului dvs. de lucru.
Următorul tabel oferă îndrumări privind evaluarea inferenței în timp real SageMaker pe baza funcțiilor de fitness.
Funcția fitness | Descriere |
A costat |
Punctele finale în timp real oferă răspuns sincron la solicitările de inferență. Deoarece punctul final rulează întotdeauna și este disponibil pentru a oferi răspuns de inferență sincron în timp real, plătiți pentru utilizarea instanței. Costurile se pot adăuga rapid atunci când implementați mai multe puncte finale, mai ales dacă punctele finale nu utilizează pe deplin instanțele de bază. Alegerea instanței potrivite pentru modelul dvs. vă ajută să vă asigurați că aveți cea mai performantă instanță la cel mai mic cost pentru modelele dvs. Scalare automată este recomandată pentru a ajusta dinamic capacitatea în funcție de trafic pentru a menține performanța constantă și previzibilă la cel mai mic cost posibil. SageMaker extinde accesul la familiile de instanțe ML bazate pe Graviton2 și Graviton3. AWS Graviton procesoarele sunt construite personalizat de Amazon Web Services folosind nuclee Arm Neoverse pe 64 de biți pentru a oferi cele mai bune performanțe de preț pentru sarcinile de lucru în cloud care rulează pe Amazon EC2. Cu instanțe bazate pe Graviton, aveți mai multe opțiuni pentru optimizarea costurilor și a performanței atunci când implementați modelele dvs. ML pe SageMaker. SageMaker acceptă și Instanțe Inf1, oferind performanță ridicată și inferență ML rentabilă. Cu 1–16 cipuri AWS Inferentia de exemplu, instanțele Inf1 se pot scala în performanță și pot oferi un randament de până la trei ori mai mare și un cost pe deducție cu până la 50% mai mic în comparație cu instanțele bazate pe GPU AWS. Pentru a utiliza instanțe Inf1 în SageMaker, puteți compila modelele antrenate folosind Amazon SageMaker Neo și selectați instanțele Inf1 pentru a implementa modelul compilat pe SageMaker. De asemenea, puteți explora Planuri de economii pentru SageMaker pentru a beneficia de economii de costuri de până la 64% față de prețul la cerere. Când creați un punct final, SageMaker atașează un volum de stocare EBS la fiecare instanță de calcul ML care găzduiește punctul final. Mărimea volumului de stocare depinde de tipul instanței. Costul suplimentar pentru punctele finale în timp real include costul pentru o lună de GB de stocare asigurată, plus GB de date procesate în și GB de date procesate din instanța punctului final. |
Latența de inferență | Inferența în timp real este ideală atunci când aveți nevoie de un punct final persistent cu cerințe de latență în milisecunde. Acceptă dimensiuni de încărcare utilă de până la 6 MB și timpi de procesare de până la 60 de secunde. |
tranzitată |
O valoare ideală a debitului de inferență este subiectivă de factori cum ar fi modelul, dimensiunea de intrare a modelului, dimensiunea lotului și tipul de instanță a punctului final. Ca cea mai bună practică, examinați valorile CloudWatch pentru solicitările de intrare și utilizarea resurselor și selectați tipul de instanță adecvat pentru a obține un debit optim. O aplicație de afaceri poate fi optimizată fie cu randamentul, fie cu latența. De exemplu, loturile dinamice pot ajuta la creșterea debitului pentru aplicațiile sensibile la latență folosind inferențe în timp real. Cu toate acestea, există limite pentru dimensiunea lotului, fără de care latența de inferență ar putea fi afectată. Latența de inferență va crește pe măsură ce creșteți dimensiunea lotului pentru a îmbunătăți debitul. Prin urmare, inferența în timp real este o opțiune ideală pentru aplicațiile sensibile la latență. SageMaker oferă opțiuni de inferență asincronă și transformare în lot, care sunt optimizate pentru a oferi un randament mai mare în comparație cu inferența în timp real, dacă aplicațiile de afaceri pot tolera o latență puțin mai mare. |
Scalarea complexității configurației |
Suport pentru puncte finale SageMaker în timp real scalare automată afara din cutie. Când volumul de lucru crește, scalarea automată aduce mai multe instanțe online. Când volumul de lucru scade, scalarea automată elimină cazurile inutile, ajutându-vă să reduceți costul de calcul. Fără scalare automată, trebuie să faceți prevederi pentru traficul de vârf sau indisponibilitatea modelului de risc. Cu excepția cazului în care traficul către modelul dvs. este constant pe parcursul zilei, va exista o capacitate neutilizată în exces. Acest lucru duce la o utilizare scăzută și la risipa de resurse. Cu SageMaker, puteți configura diferite opțiuni de scalare pe baza modelului de trafic așteptat. Scalarea simplă sau scalarea urmăririi țintei este ideală atunci când doriți să scalați pe baza unei anumite valori CloudWatch. Puteți face acest lucru alegând o anumită valoare și setând valori de prag. Valorile recomandate pentru această opțiune sunt medii Dacă aveți nevoie de o configurație avansată, puteți seta o politică de scalare în etape pentru a ajusta dinamic numărul de instanțe de scalare în funcție de dimensiunea încălcării alarmei. Acest lucru vă ajută să configurați un răspuns mai agresiv atunci când cererea atinge un anumit nivel. Puteți utiliza o opțiune de scalare programată atunci când știți că cererea urmează un anumit program în zi, săptămână, lună sau an. Acest lucru vă ajută să specificați o programare unică sau o programare recurentă sau expresii cron împreună cu orele de început și de sfârșit, care formează limitele când începe și se oprește acțiunea de scalare automată. Pentru mai multe detalii, consultați Configurarea punctelor finale de inferență cu scalare automată în Amazon SageMaker și Testați încărcarea și optimizați un punct final Amazon SageMaker utilizând scalarea automată. |
Model de trafic | Inferența în timp real este ideală pentru sarcinile de lucru cu un model de trafic continuu sau regulat. |
Inferență asincronă în SageMaker
Inferența asincronă SageMaker este o nouă capacitate în SageMaker care pune în așteptare cererile primite și le procesează asincron. Această opțiune este ideală pentru solicitări cu dimensiuni mari de încărcare utilă (până la 1 GB), timpi lungi de procesare (până la 15 minute) și cerințe de latență aproape în timp real. Exemple de sarcini de lucru pentru inferența asincronă includ companiile de asistență medicală care procesează imagini sau videoclipuri biomedicale de înaltă rezoluție, cum ar fi ecocardiogramele pentru a detecta anomalii. Aceste aplicații primesc rafale de trafic de intrare la diferite momente ale zilei și necesită procesare aproape în timp real la costuri reduse. Timpii de procesare pentru aceste solicitări pot varia de ordinul minutelor, eliminând necesitatea de a rula inferențe în timp real. În schimb, încărcăturile utile de intrare pot fi procesate asincron dintr-un magazin de obiecte precum Amazon S3, cu așteptare automată și un prag de concurență predefinit. La procesare, SageMaker plasează răspunsul de inferență în locația Amazon S3 returnată anterior. Puteți alege opțional să primiți notificări de succes sau de eroare prin Serviciul de notificare simplă Amazon (Amazon SNS).
Următorul tabel oferă îndrumări privind evaluarea inferenței asincrone SageMaker pe baza funcțiilor de fitness.
Funcția fitness | Descriere |
A costat | Inferența asincronă este o alegere excelentă pentru sarcinile de lucru sensibile la costuri cu sarcini utile mari și trafic de explozie. Inferența asincronă vă permite să economisiți costuri prin scalarea automată a numărului de instanțe la zero atunci când nu există cereri de procesat, astfel încât să plătiți numai atunci când punctul final procesează cereri. Solicitările care sunt primite când există zero instanțe sunt puse în coadă pentru procesare după ce punctul final crește. |
Latența de inferență | Inferența asincronă este ideală pentru cerințele de latență în timp aproape real. Solicitările sunt plasate într-o coadă și procesate de îndată ce calculul este disponibil. Acest lucru duce de obicei la zeci de milisecunde în latență. |
tranzitată | Inferența asincronă este ideală pentru cazurile de utilizare fără latență, deoarece aplicațiile nu trebuie să compromită debitul. Solicitările nu sunt abandonate în timpul creșterilor de trafic, deoarece punctul final de inferență asincron pune în coadă solicitările în loc să le abandoneze. |
Scalarea complexității configurației |
SageMaker acceptă scalare automată pentru punctul final asincron. Spre deosebire de punctele finale găzduite în timp real, punctele finale de inferență asincrone acceptă reducerea la zero a instanțelor prin setarea capacității minime la zero. Pentru punctele finale asincrone, SageMaker vă recomandă insistent să creați o configurație de politică pentru scalarea de urmărire a țintei pentru un model (variantă) implementat. Pentru cazurile de utilizare care pot tolera o penalizare de pornire la rece de câteva minute, puteți, opțional, să micșorați numărul de instanțe ale punctului final la zero atunci când nu există solicitări restante și să măriți o copie de rezervă pe măsură ce sosesc cereri noi, astfel încât să plătiți doar pentru durata punctele finale procesează în mod activ solicitările. |
Model de trafic | Punctele finale asincrone pun în coadă cererile primite și le procesează asincron. Sunt o opțiune bună pentru tiparele de trafic intermitente sau rare. |
Inferență în lot în SageMaker
Transformarea batch SageMaker este ideală pentru predicții offline pentru loturi mari de date care sunt disponibile în avans. Caracteristica de transformare în lot este o metodă de înaltă performanță și de înaltă performanță pentru transformarea datelor și generarea de inferențe. Este ideal pentru scenariile în care aveți de-a face cu loturi mari de date, nu aveți nevoie de o latență sub secundă sau trebuie să preprocesați și să transformați datele de antrenament. Clienții din anumite domenii, cum ar fi publicitatea și marketingul sau asistența medicală, trebuie adesea să facă predicții offline pe seturi de date hiperscale, unde debitul mare este adesea obiectivul cazului de utilizare, iar latența nu este o problemă.
Când începe o lucrare de transformare în lot, SageMaker inițializează instanțe de calcul și distribuie volumul de lucru de inferență între ele. Eliberează resursele când lucrările sunt finalizate, astfel încât plătiți numai pentru ceea ce a fost folosit în timpul executării jobului. Când lucrarea este finalizată, SageMaker salvează rezultatele predicției într-o găleată S3 pe care o specificați. Sarcinile de inferență în lot sunt de obicei candidați buni pentru scalarea orizontală. Fiecare lucrător dintr-un cluster poate opera pe un subset diferit de date fără a fi nevoie să facă schimb de informații cu alți lucrători. AWS oferă mai multe opțiuni de stocare și de calcul care permit scalarea orizontală. Exemple de încărcături de lucru pentru transformarea batch SageMaker includ aplicații offline, cum ar fi aplicațiile bancare pentru prezicerea ratei clienților, unde o lucrare offline poate fi programată să ruleze periodic.
Următorul tabel oferă îndrumări privind evaluarea transformării batch SageMaker pe baza funcțiilor de fitness.
Funcția fitness | Descriere |
A costat | Transformarea batch SageMaker vă permite să executați predicții pe seturi de date în loturi mari sau mici. Sunteți taxat pentru tipul de instanță pe care îl alegeți, în funcție de durata de utilizare. SageMaker gestionează furnizarea de resurse la începutul lucrării și le eliberează când lucrarea este finalizată. Nu există costuri suplimentare de prelucrare a datelor. |
Latența de inferență | Puteți utiliza invocarea bazată pe evenimente sau programată. Latența poate varia în funcție de dimensiunea datelor de inferență, concurența jobului, complexitatea modelului și capacitatea instanței de calcul. |
tranzitată |
Lucrările de transformare în loturi pot fi efectuate pe o gamă largă de seturi de date, de la petaocteți de date la seturi de date foarte mici. Nu este nevoie să redimensionați seturi de date mai mari în bucăți mici de date. Puteți accelera lucrările de transformare în loturi utilizând valori optime pentru parametri precum MaxPayloadInMB, MaxConcurrentTransforms, Sau BatchStrategy. Valoarea ideală pentru Procesarea în loturi poate crește debitul și poate optimiza resursele, deoarece ajută la completarea unui număr mai mare de inferențe într-o anumită perioadă de timp, în detrimentul latenței. Pentru a optimiza implementarea modelului pentru un debit mai mare, indicația generală este de a crește dimensiunea lotului până când debitul scade. |
Scalarea complexității configurației | Transformarea batch SageMaker este utilizată pentru inferența offline care nu este sensibilă la latență. |
Model de trafic | Pentru inferența offline, o lucrare de transformare în lot este programată sau începută folosind un declanșator bazat pe evenimente. |
Inferență fără server în SageMaker
Inferența fără server SageMaker vă permite să implementați modele ML pentru inferență fără a fi nevoie să configurați sau să gestionați infrastructura de bază. Pe baza volumului de solicitări de inferență pe care modelul dvs. le primește, inferența fără server SageMaker furnizează, scalează și oprește automat capacitatea de calcul. În consecință, plătiți doar pentru timpul de calcul pentru a rula codul de inferență și pentru cantitatea de date procesate, nu pentru timpul inactiv. Puteți utiliza algoritmii încorporați ai SageMaker și containerele de servire a cadrului ML pentru a vă implementa modelul într-un punct final de inferență fără server sau puteți alege să vă aduceți propriul container. Dacă traficul devine previzibil și stabil, puteți actualiza cu ușurință de la un punct final de inferență fără server la un punct final în timp real SageMaker, fără a fi nevoie să faceți modificări imaginii containerului. Cu inferența fără server, beneficiați și de alte funcții SageMaker, inclusiv de metrici încorporate, cum ar fi numărul de invocari, erori, latența, valorile gazdei și erorile în CloudWatch.
Următorul tabel oferă îndrumări privind evaluarea inferenței fără server SageMaker pe baza funcțiilor de fitness.
Funcția fitness | Descriere |
A costat | Cu un model pay-as-you-run, inferența fără server este o opțiune rentabilă dacă aveți modele de trafic rare sau intermitente. Plătiți numai pentru durata pentru care punctul final procesează cererea și, prin urmare, puteți economisi costuri dacă modelul de trafic este intermitent. |
Latența de inferență |
Punctele finale fără server oferă o latență scăzută de inferență (de ordinul milisecundelor până la secunde), cu capacitatea de a scala instantaneu de la zeci la mii de inferențe în câteva secunde, pe baza tiparelor de utilizare, făcându-l ideal pentru aplicațiile ML cu trafic intermitent sau imprevizibil. Deoarece punctele finale fără server furnizează resurse de calcul la cerere, punctul final poate experimenta câteva secunde suplimentare de latență (pornire la rece) pentru prima invocare după o perioadă de inactivitate. Timpul de pornire la rece depinde de dimensiunea modelului dvs., de cât timp durează descărcarea modelului și de timpul de pornire al containerului. |
tranzitată | Când configurați punctul final fără server, puteți specifica dimensiunea memoriei și numărul maxim de invocări simultane. Inferența fără server SageMaker atribuie automat resursele de calcul proporțional cu memoria pe care o selectați. Dacă alegeți o dimensiune de memorie mai mare, containerul dvs. are acces la mai multe vCPU. Ca regulă generală, dimensiunea memoriei ar trebui să fie cel puțin la fel de mare ca dimensiunea modelului dvs. Dimensiunile de memorie pe care le puteți alege sunt 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB și 6144 MB. Indiferent de dimensiunea memoriei pe care o alegeți, punctele finale fără server au la dispoziție 5 GB de stocare pe disc efemeră. |
Scalarea complexității configurației | Punctele finale fără server lansează automat resurse de calcul și le scala în funcție de trafic, eliminând nevoia de a alege tipuri de instanțe sau de a gestiona politicile de scalare. Acest lucru elimină greutățile nediferențiate ale selectării și gestionării serverelor. |
Model de trafic | Inferența fără server este ideală pentru sarcinile de lucru cu modele de trafic rare sau intermitente. |
Modelați modele de design de găzduire în SageMaker
Punctele finale de inferență SageMaker folosesc containere Docker pentru găzduirea modelelor ML. Containerele vă permit să împachetați software-ul în unități standardizate care rulează constant pe orice platformă care acceptă Docker. Acest lucru asigură portabilitatea peste platforme, implementări de infrastructură imuabilă și gestionarea mai ușoară a schimbărilor și implementări CI/CD. SageMaker oferă containere gestionate pre-construite pentru cadre populare, cum ar fi Apache MXNet, TensorFlow, PyTorch, Sklearn și Hugging Face. Pentru o listă completă a imaginilor de containere SageMaker disponibile, consultați Imagini disponibile ale containerelor Deep Learning. În cazul în care SageMaker nu are un container acceptat, puteți, de asemenea, să vă creați propriul container (BYOC) și să vă împingeți propria imagine personalizată, instalând dependențele care sunt necesare pentru modelul dvs.
Pentru a implementa un model pe SageMaker, aveți nevoie de un container (containere de cadru gestionate de SageMaker sau BYOC) și de o instanță de calcul pentru a găzdui containerul. SageMaker acceptă mai multe opțiuni avansate pentru modele comune de găzduire a modelelor ML, unde modelele pot fi găzduite într-un singur container sau co-găzduite pe un container partajat.
O aplicație ML în timp real poate folosi un singur model sau mai multe modele pentru a servi o singură cerere de predicție. Următoarea diagramă prezintă diferite scenarii de inferență pentru o aplicație ML.
Să explorăm o opțiune de găzduire SageMaker potrivită pentru fiecare dintre scenariile de inferență precedente. Puteți consulta funcțiile de fitness pentru a evalua dacă este opțiunea potrivită pentru cazul de utilizare dat.
Găzduirea unei aplicații ML bazate pe un singur model
Există mai multe opțiuni pentru a găzdui aplicații ML bazate pe un singur model folosind serviciile de găzduire SageMaker, în funcție de scenariul de implementare.
Punct final cu un singur model
Punctele finale cu un singur model SageMaker vă permit să găzduiți un model pe un container găzduit pe instanțe dedicate pentru o latență scăzută și un randament ridicat. Aceste puncte finale sunt complet gestionate și acceptă scalarea automată. Puteți configura punctul final cu un singur model ca punct final prevăzut în care treceți în configurația infrastructurii punctului final, cum ar fi tipul și numărul de instanțe, sau un punct final fără server unde SageMaker lansează automat resurse de calcul și le scala în funcție de trafic, eliminând nevoia. pentru a alege tipurile de instanțe sau pentru a gestiona politicile de scalare. Punctele finale fără server sunt pentru aplicații cu trafic intermitent sau imprevizibil.
Următoarea diagramă prezintă scenarii de inferență cu un singur model.
Următorul tabel oferă îndrumări privind evaluarea funcțiilor de fitness pentru un punct final cu un singur model prevăzut. Pentru evaluări ale funcției de fitness a punctelor terminale fără server, consultați secțiunea punctelor terminale fără server din această postare.
Funcția fitness | Descriere |
A costat | Sunteți taxat pentru utilizarea tipului de instanță pe care îl alegeți. Deoarece punctul final funcționează și este întotdeauna disponibil, costurile se pot adăuga rapid. Alegerea instanței potrivite pentru modelul dvs. vă ajută să vă asigurați că aveți cea mai performantă instanță la cel mai mic cost pentru modelele dvs. Scalare automată este recomandată pentru a ajusta dinamic capacitatea în funcție de trafic pentru a menține performanța constantă și previzibilă la cel mai mic cost posibil. |
Latența de inferență | Un punct final cu un singur model oferă inferențe interactive și sincrone în timp real, cu cerințe de latență în milisecunde. |
tranzitată | Debitul poate fi afectat de diverși factori, cum ar fi dimensiunea de intrare a modelului, dimensiunea lotului, tipul instanței punctului final și așa mai departe. Se recomandă să revizuiți valorile CloudWatch pentru solicitările de intrare și utilizarea resurselor și să selectați tipul de instanță adecvat pentru a obține un debit optim. SageMaker oferă caracteristici pentru gestionarea resurselor și optimizarea performanței de inferență atunci când implementează modele ML. Poti optimizați performanța modelului folosind Neo, sau utilizați instanțe Inf1 pentru un proces mai bun al modelelor găzduite de SageMaker folosind o instanță GPU pentru punctul final. |
Scalarea complexității configurației | Scalare automată este acceptată imediat. SageMaker recomandă alegerea uneia potrivite configurația de scalare prin efectuarea teste de sarcină. |
Model de trafic | Un punct final cu un singur model este ideal pentru sarcinile de lucru cu modele de trafic previzibile. |
Co-găzduire mai multe modele
Când aveți de-a face cu un număr mare de modele, implementarea fiecăruia pe un punct final individual cu un container și o instanță dedicate poate duce la o creștere semnificativă a costurilor. În plus, devine dificil să gestionezi atât de multe modele în producție, în special atunci când nu trebuie să invoci toate modelele în același timp, dar totuși trebuie să fie disponibile în orice moment. Găzduirea în comun a mai multor modele pe aceleași resurse de calcul subiacente facilitează gestionarea implementărilor ML la scară și reduce costurile de găzduire prin utilizarea sporită a punctului final și a resurselor de calcul subiacente. SageMaker acceptă opțiuni avansate de co-găzduire a modelelor, cum ar fi punctul final cu mai multe modele (MME) pentru modele omogene și punctul final cu mai multe containere (MCE) pentru modele eterogene. Modelele omogene utilizează același cadru ML pe un container de servicii partajate, în timp ce modelele eterogene vă permit să implementați mai multe containere de servire care utilizează modele sau cadre diferite pe un singur punct final.
Următoarea diagramă prezintă opțiunile de co-găzduire a modelului folosind SageMaker.
Puncte finale cu mai multe modele SageMaker
SageMaker MME-uri vă permit să găzduiți mai multe modele folosind un container de servire partajat pe un singur punct final. Aceasta este o soluție scalabilă și rentabilă pentru a implementa un număr mare de modele care se adresează aceluiași caz de utilizare, cadru sau logică de inferență. MME-urile pot servi dinamic cereri pe baza modelului invocat de apelant. De asemenea, reduce costul general de implementare, deoarece SageMaker gestionează încărcarea modelelor în memorie și scalarea acestora în funcție de tiparele de trafic către acestea. Această caracteristică este ideală atunci când aveți un număr mare de modele similare pe care le puteți servi printr-un container de servire partajat și nu trebuie să accesați toate modelele în același timp. Punctele finale cu mai multe modele permit, de asemenea, partajarea timpului a resurselor de memorie între modelele dvs. Acest lucru funcționează cel mai bine atunci când modelele sunt destul de similare ca dimensiune și latență de invocare, permițând MME-urilor să utilizeze în mod eficient instanțele pentru toate modelele. SageMaker MME acceptă găzduirea atât a modelelor bazate pe CPU, cât și pe GPU. Folosind modele susținute de GPU, puteți reduce costurile de implementare a modelului prin utilizarea sporită a punctului final și a instanțelor de calcul accelerate subiacente. Pentru un caz de utilizare real al MME-urilor, consultați Cum să scalați inferența învățării automate pentru cazurile de utilizare SaaS multi-tenant.
Următorul tabel oferă îndrumări cu privire la evaluarea funcțiilor de fitness pentru MME.
Funcția fitness | Descriere |
A costat |
MME-urile permit utilizarea unui container de servire partajat pentru a găzdui mii de modele pe un singur punct final. Acest lucru reduce semnificativ costurile de găzduire prin îmbunătățirea utilizării punctelor finale în comparație cu utilizarea punctelor finale cu un singur model. De exemplu, dacă aveți 10 modele de implementat folosind o instanță ml.c5.large, bazată pe Prețuri SageMaker, costul de a avea 10 puncte finale persistente cu un singur model este: 10 * 0.102 USD = 1.02 USD pe oră. În timp ce cu un MME care găzduiește cele 10 modele, obținem economii de costuri de 10 ori mai mari: 1 * 0.102 USD = 0.102 USD pe oră. |
Latența de inferență |
În mod implicit, MME-urile memorează în cache modelele utilizate frecvent în memorie și pe disc pentru a oferi o inferență cu latență scăzută. Modelele stocate în cache sunt descărcate sau șterse de pe disc numai atunci când un container rămâne fără memorie sau spațiu pe disc pentru a găzdui un model nou vizat. MME-urile permit încărcarea leneșă a modelelor, ceea ce înseamnă că modelele sunt încărcate în memorie atunci când sunt invocate pentru prima dată. Aceasta optimizează utilizarea memoriei; cu toate acestea, provoacă creșteri ale timpului de răspuns la prima încărcare, rezultând o problemă de pornire la rece. Prin urmare, MME-urile sunt, de asemenea, potrivite pentru scenariile care pot tolera penalizări ocazionale de latență legate de pornirea la rece care apar atunci când se invocă modele utilizate rar. Pentru a îndeplini obiectivele de latență și debit ale aplicațiilor ML, instanțele GPU sunt preferate față de instanțele CPU (având în vedere puterea de calcul oferită de GPU-uri). Cu suportul MME pentru GPU, puteți implementa mii de modele de deep learning în spatele unui punct final SageMaker. MME-urile pot rula mai multe modele pe un nucleu GPU, pot partaja instanțe GPU în spatele unui punct final pe mai multe modele și pot încărca și descărca dinamic modele pe baza traficului de intrare. Cu aceasta, puteți economisi semnificativ costurile și puteți obține cele mai bune performanțe de preț. Dacă cazul dvs. de utilizare necesită tranzacții pe secundă (TPS) sau cerințe de latență semnificativ mai mari, vă recomandăm să găzduiți modelele pe puncte finale dedicate. |
tranzitată |
O valoare ideală a debitului de inferență MME depinde de factori precum modelul, dimensiunea sarcinii utile și tipul instanței punctului final. O cantitate mai mare de memorie de instanță vă permite să aveți mai multe modele încărcate și pregătite pentru a servi cererile de inferență. Nu trebuie să pierdeți timp încărcând modelul. O cantitate mai mare de vCPU vă permite să invocați mai multe modele unice simultan. MME-urile încarcă și descarcă dinamic modelul în și din memoria instanței, ceea ce poate afecta performanța I/O. SageMaker MME cu GPU funcționează folosind NVIDIA Triton Inference Server, care este un software de servire a inferențelor open-source care simplifică procesul de servire a inferențelor și oferă performanțe ridicate de inferență. SageMaker încarcă modelul în memoria containerului NVIDIA Triton pe o instanță accelerată GPU și servește cererea de inferență. Nucleul GPU este partajat de toate modelele dintr-o instanță. Dacă modelul este deja încărcat în memoria containerului, solicitările ulterioare sunt servite mai rapid, deoarece SageMaker nu trebuie să îl descarce și să îl încarce din nou. Se recomandă o testare și o analiză adecvată a performanței în implementările de producție de succes. SageMaker oferă valori CloudWatch pentru punctele finale cu mai multe modele, astfel încât să puteți determina utilizarea punctului final și rata de accesare a memoriei cache pentru a vă ajuta să optimizați punctul final. |
Scalarea complexității configurației | Punctele finale cu mai multe modele SageMaker acceptă pe deplin scalarea automată, care gestionează replicile modelelor pentru a asigura scalarea modelelor pe baza modelelor de trafic. Cu toate acestea, se recomandă o testare de încărcare adecvată pentru a determina dimensiunea optimă a instanțelor pentru scalarea automată a punctului final. Dimensionarea corectă a flotei MME este importantă pentru a evita descărcarea prea multor modele. Încărcarea a sute de modele pe câteva instanțe mai mari poate duce la limitare în unele cazuri, iar utilizarea mai multor instanțe și mai mici ar putea fi preferată. Pentru a profita de scalarea automată a modelului în SageMaker, asigurați-vă că aveți Configurarea scalării automate a instanței pentru a furniza capacitate suplimentară de instanță. Configurați politica dvs. de scalare la nivel de terminal, fie cu parametri personalizați, fie cu invocări pe minut (recomandat) pentru a adăuga mai multe instanțe la flota de terminale. Ratele de invocare utilizate pentru a declanșa un eveniment de scalare automată se bazează pe setul agregat de predicții din setul complet de modele deservite de punctul final. |
Model de trafic | MME-urile sunt ideale atunci când aveți un număr mare de modele de dimensiuni similare pe care le puteți servi printr-un container de servire partajat și nu trebuie să accesați toate modelele în același timp. |
Puncte finale cu mai multe containere SageMaker
SageMaker MCE-uri acceptă implementarea a până la 15 containere care utilizează diferite modele sau cadre pe un singur punct final și invocarea lor independent sau în secvență pentru inferență cu latență redusă și economii de costuri. Modelele pot fi complet eterogene, cu propria lor stivă de servire independentă. Găzduirea în siguranță a mai multor modele din cadre diferite pe o singură instanță vă poate economisi până la 90% din costuri.
Modelele de invocare MCE sunt după cum urmează:
- Conducte de inferență – Containerele dintr-un MME pot fi invocate într-o secvență liniară, cunoscută și ca a conductă de inferență în serie. Ele sunt de obicei folosite pentru a separa preprocesarea, inferența modelului și postprocesarea în containere independente. Ieșirea din containerul curent este transmisă ca intrare la următorul. Ele sunt reprezentate ca un singur model de conductă în SageMaker. O conductă de inferență poate fi implementată ca MME, unde unul dintre containerele din conductă poate servi dinamic cererile pe baza modelului invocat.
- Invocare directă - Cu invocare directă, o solicitare poate fi trimisă la un anumit container de inferență găzduit pe un MCE.
Următorul tabel oferă îndrumări cu privire la evaluarea funcțiilor de fitness pentru MCE.
Funcția fitness | Descriere |
A costat | MCE-urile vă permit să rulați până la 15 containere ML diferite pe un singur punct final și să le invocați independent, economisind astfel costuri. Această opțiune este ideală atunci când aveți mai multe modele care rulează pe stive de servire diferite cu nevoi de resurse similare și când modelele individuale nu au suficient trafic pentru a utiliza întreaga capacitate a instanțelor punctului final. Prin urmare, MCE-urile sunt mai rentabile decât un punct final cu un singur model. MCE-urile oferă răspuns de inferență sincron, ceea ce înseamnă că punctul final este întotdeauna disponibil și plătiți pentru timpul de funcționare al instanței. Costul poate crește în funcție de numărul și tipul de instanțe. |
Latența de inferență | MCE-urile sunt ideale pentru rularea aplicațiilor ML cu diferite cadre și algoritmi ML pentru fiecare model, care sunt accesate rar, dar care necesită totuși inferențe cu latență scăzută. Modelele sunt întotdeauna disponibile pentru inferență cu latență scăzută și nu există nicio problemă de pornire la rece. |
tranzitată | MCE-urile sunt limitate la până la 15 containere pe un punct final cu mai multe containere, iar inferența GPU nu este acceptată din cauza conflictului de resurse. Pentru punctele finale cu mai multe containere care utilizează modul de invocare directă, SageMaker nu numai că oferă metrici la nivel de instanță, așa cum o face cu alte puncte finale comune, dar acceptă și metrici per container. Ca cea mai bună practică, examinați valorile CloudWatch pentru solicitările de intrare și utilizarea resurselor și selectați tipul de instanță adecvat pentru a obține un debit optim. |
Scalarea complexității configurației | MCE-urile acceptă scalarea automată. Cu toate acestea, pentru a configura scalarea automată, se recomandă ca modelul din fiecare container să prezinte o utilizare similară a CPU și o latență la fiecare cerere de inferență. Acest lucru este recomandat deoarece, dacă traficul către punctul final cu mai multe containere trece de la un model de utilizare scăzută a procesorului la un model de utilizare ridicată a procesorului, dar volumul total al apelurilor rămâne același, punctul final nu se extinde și este posibil să nu existe suficiente instanțe. pentru a gestiona toate cererile către modelul de utilizare ridicată a CPU. |
Model de trafic | MCE-urile sunt ideale pentru încărcături de lucru cu modele de trafic continue sau regulate, pentru modele de găzduire în diferite cadre (cum ar fi TensorFlow, PyTorch sau Sklearn) care ar putea să nu aibă suficient trafic pentru a satura întreaga capacitate a unei instanțe de punct final. |
Găzduirea unei aplicații ML bazate pe mai multe modele
Multe aplicații de afaceri trebuie să utilizeze mai multe modele ML pentru a servi o singură cerere de predicție consumatorilor lor. De exemplu, o companie de vânzare cu amănuntul care dorește să ofere recomandări utilizatorilor săi. Aplicația ML în acest caz de utilizare poate dori să folosească diferite modele personalizate pentru a recomanda diferite categorii de produse. Dacă compania dorește să adauge personalizare recomandărilor prin utilizarea informațiilor individuale ale utilizatorului, numărul de modele personalizate crește și mai mult. Găzduirea fiecărui model personalizat pe o instanță de calcul distinctă nu este doar prohibitivă, dar duce și la subutilizarea resurselor de găzduire, dacă nu toate modelele sunt utilizate frecvent. SageMaker oferă opțiuni eficiente de găzduire pentru aplicații ML bazate pe mai multe modele.
Următoarea diagramă arată opțiunile de găzduire cu mai multe modele pentru un singur punct final folosind SageMaker.
Conducta de inferență în serie
O conductă de inferență este un model SageMaker care este compus dintr-o secvență liniară de 2-15 containere care procesează cererile de inferențe asupra datelor. Utilizați o conductă de inferență pentru a defini și a implementa orice combinație de algoritmi încorporați SageMaker preantrenați și propriii algoritmi personalizați ambalate în containere Docker. Puteți utiliza o conductă de inferență pentru a combina sarcinile de preprocesare, predicții și postprocesare ale științei datelor. Ieșirea dintr-un container este transmisă ca intrare la următorul. Când definiți containerele pentru un model de conductă, specificați și ordinea în care sunt rulați containerele. Ele sunt reprezentate ca un singur model de conductă în SageMaker. Conducta de inferență poate fi implementată ca MME, unde unul dintre containerele din conductă poate servi dinamic cererile pe baza modelului invocat. De asemenea, puteți rula un transformarea lotului job cu o conductă de inferență. Conductele de inferență sunt gestionate în totalitate.
Următorul tabel oferă îndrumări privind evaluarea funcțiilor de fitness pentru găzduirea modelului ML folosind o conductă de inferență în serie.
Funcția fitness | Descriere |
A costat | Conducta de inferență în serie vă permite să rulați până la 15 containere ML diferite pe un singur punct final, ceea ce duce la rentabilitatea găzduirii containerelor de inferență. Nu există costuri suplimentare pentru utilizarea acestei funcții. Plătiți numai pentru instanțele care rulează pe un punct final. Costul poate crește în funcție de numărul și tipul de instanțe. |
Latența de inferență | Când o aplicație ML este implementată ca o conductă de inferență, datele dintre diferite modele nu părăsesc spațiul containerului. Procesarea caracteristicilor și inferențe rulează cu o latență scăzută, deoarece containerele sunt amplasate în același loc pe aceleași instanțe EC2. |
tranzitată | În cadrul unui model de conductă de inferență, SageMaker gestionează invocările ca o secvență de solicitări HTTP. Primul container din conductă gestionează cererea inițială, apoi răspunsul intermediar este trimis ca cerere către al doilea container și așa mai departe, pentru fiecare container din conductă. SageMaker returnează clientului răspunsul final. Debitul este subiectiv de factori precum modelul, dimensiunea de intrare a modelului, dimensiunea lotului și tipul de instanță a punctului final. Ca cea mai bună practică, examinați valorile CloudWatch pentru solicitările de intrare și utilizarea resurselor și selectați tipul de instanță adecvat pentru a obține un debit optim. |
Scalarea complexității configurației | Conductele de inferență seriale acceptă scalarea automată. Cu toate acestea, pentru a configura scalarea automată, se recomandă ca modelul din fiecare container să prezinte o utilizare similară a CPU și o latență la fiecare cerere de inferență. Acest lucru este recomandat deoarece, dacă traficul către punctul final cu mai multe containere trece de la un model de utilizare scăzută a CPU la un model de utilizare ridicată a CPU, dar volumul total al apelurilor rămâne același, punctul final nu se extinde și este posibil să nu existe suficiente instanțe pentru gestionează toate cererile către modelul de utilizare ridicată a CPU. |
Model de trafic |
Conductele de inferență în serie sunt ideale pentru modele de trafic previzibile cu modele care rulează secvenţial pe același punct final. |
Implementarea ansamblurilor de modele (Triton DAG):
SageMaker oferă integrare cu NVIDIA Triton Inference Server prin Containere Triton Inference Server. Aceste containere includ NVIDIA Triton Inference Server, suport pentru cadre ML obișnuite și variabile de mediu utile care vă permit să optimizați performanța pe SageMaker. Cu imaginile containerului NVIDIA Triton, puteți servi cu ușurință modele ML și puteți beneficia de optimizări de performanță, loturi dinamice și suport pentru mai multe cadre oferite de NVIDIA Triton. Triton ajută la maximizarea utilizării GPU și CPU, scăzând și mai mult costul de inferență.
În cazurile de utilizare în afaceri în care aplicațiile ML folosesc mai multe modele pentru a servi o solicitare de predicție, dacă fiecare model folosește un cadru diferit sau este găzduit pe o instanță separată, poate duce la creșterea volumului de lucru și a costurilor, precum și la o creștere a latenței generale. SageMaker NVIDIA Triton Inference Server acceptă implementarea modelelor din toate cadrele majore, cum ar fi TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT și formatele de model Python/C++ și multe altele. Ansamblul de modele Triton reprezintă o conductă de unul sau mai multe modele sau logica de preprocesare și postprocesare și conexiunea tensorilor de intrare și de ieșire între aceștia. O singură cerere de inferență către un ansamblu declanșează rularea întregii conducte. Triton are, de asemenea, mai mulți algoritmi încorporați de programare și loturi care combină cereri individuale de inferență pentru a îmbunătăți debitul de inferență. Aceste decizii de programare și loturi sunt transparente pentru clientul care solicită inferențe. Modelele pot fi rulate pe procesoare sau GPU pentru o flexibilitate maximă și pentru a suporta cerințe de calcul eterogene.
Găzduirea mai multor modele susținute de GPU pe terminale cu mai multe modele este acceptată prin SageMaker Triton Inference Server. NVIDIA Triton Inference Server a fost extins pentru a implementa un Contract MME API, pentru a se integra cu MME-uri. Puteți utiliza NVIDIA Triton Inference Server, care creează o configurație de depozit de model pentru diferite backend-uri cadru, pentru a implementa un MME cu scalare automată. Această caracteristică vă permite să scalați sute de modele hiperpersonalizate care sunt reglate fin pentru a satisface experiențe unice ale utilizatorului final în aplicațiile AI. De asemenea, puteți utiliza această caracteristică pentru a obține performanțe de preț necesare pentru aplicația dvs. de inferență folosind GPU-uri fracționate. Pentru a afla mai multe, consultați Rulați mai multe modele de deep learning pe GPU cu punctele finale cu mai multe modele Amazon SageMaker.
Următorul tabel oferă îndrumări privind evaluarea funcțiilor de fitness pentru găzduirea modelului ML folosind MME-uri cu suport GPU pe containerele de inferență Triton. Pentru evaluări ale funcțiilor de fitness ale punctelor finale cu un singur model și fără server, consultați secțiunile anterioare din această postare.
Funcția fitness | Descriere |
A costat | SageMaker MME cu suport GPU folosind Triton Inference Server oferă o modalitate scalabilă și rentabilă de a implementa un număr mare de modele de deep learning în spatele unui punct final SageMaker. Cu MME, mai multe modele partajează instanța GPU din spatele unui punct final. Acest lucru vă permite să eliminați costul în creștere liniar al găzduirii mai multor modele și să reutilizați infrastructura pentru toate modelele. Plătiți pentru timpul de funcționare al instanței. |
Latența de inferență |
SageMaker cu Triton Inference Server este conceput special pentru a maximiza debitul și utilizarea hardware-ului cu o latență de inferență ultra-scăzută (milisecunde cu o singură cifră). Are o gamă largă de cadre ML acceptate (inclusiv TensorFlow, PyTorch, ONNX, XGBoost și NVIDIA TensorRT) și backend-uri de infrastructură, inclusiv GPU-uri, procesoare și procesoare NVIDIA Inferentia AWS. Cu suportul MME pentru GPU folosind SageMaker Triton Inference Server, puteți implementa mii de modele de deep learning în spatele unui punct final SageMaker. SageMaker încarcă modelul în memoria containerului NVIDIA Triton pe o instanță accelerată GPU și servește cererea de inferență. Nucleul GPU este partajat de toate modelele dintr-o instanță. Dacă modelul este deja încărcat în memoria containerului, solicitările ulterioare sunt servite mai rapid, deoarece SageMaker nu trebuie să îl descarce și să îl încarce din nou. |
tranzitată |
MME-urile oferă capabilități pentru rularea mai multor modele de deep learning sau ML pe GPU, în același timp, cu Triton Inference Server. Acest lucru vă permite să utilizați cu ușurință sistemul multi-cadru NVIDIA Triton, care servește inferențe de înaltă performanță cu implementarea modelului gestionat complet SageMaker. Triton acceptă toate inferențele bazate pe NVIDIA GPU, x86, Arm® CPU și AWS Inferentia. Oferă loturi dinamice, rulări simultane, configurație optimă a modelului, ansamblu de model și intrări audio și video în flux pentru a maximiza debitul și utilizarea. Alți factori, cum ar fi dimensiunea rețelei și a încărcăturii utile, pot juca un rol minim în costul general asociat cu inferența. |
Scalarea complexității configurației |
MME-urile pot scala orizontal folosind o politică de scalare automată și pot furniza instanțe de calcul GPU suplimentare pe baza unor valori precum Cu serverul de inferență Triton, puteți construi cu ușurință un container personalizat care include modelul dvs. cu Triton și îl puteți aduce la SageMaker. SageMaker Inference va gestiona solicitările și va scala automat containerul pe măsură ce gradul de utilizare crește, facilitând implementarea modelului cu Triton pe AWS. |
Model de trafic |
MME-urile sunt ideale pentru modele de trafic previzibile cu modele rulate ca DAG-uri pe același punct final. SageMaker se ocupă de modelarea traficului către punctul final MME și menține copii optime ale modelului pe instanțele GPU pentru performanță la cel mai bun preț. Acesta continuă să direcționeze traficul către instanța în care este încărcat modelul. Dacă resursele instanței ating capacitatea din cauza utilizării mari, SageMaker descarcă modelele cel mai puțin utilizate din container pentru a elibera resurse pentru a încărca modelele utilizate mai frecvent. |
Cele mai bune practici
Luați în considerare următoarele bune practici:
- Coeziune ridicată și cuplare scăzută între modele – Găzduiți modelele în același container care are o coeziune ridicată (conduce funcționalitatea unei singure afaceri) și încapsulați-le împreună pentru o actualizare ușoară și gestionabilă. În același timp, decuplați acele modele unele de altele (găzduiți-le în containere diferite), astfel încât să puteți actualiza cu ușurință un model fără a afecta alte modele. Găzduiește mai multe modele care folosesc containere diferite în spatele unui punct final și invocă apoi independent sau adaugă logica de preprocesare și postprocesare a modelului ca o conductă de inferență serială.
- Latența de inferență – Grupați modelele care sunt bazate pe funcționalitatea unei singure afaceri și găzduiți-le într-un singur container pentru a minimiza numărul de hopuri și, prin urmare, pentru a minimiza latența generală. Există și alte avertismente, cum ar fi dacă modelele grupate folosesc mai multe cadre; ați putea alege, de asemenea, să găzduiți în mai multe containere, dar să rulați pe aceeași gazdă pentru a reduce latența și a minimiza costurile.
- Grupați logic modelele ML cu coeziune ridicată – Grupul logic poate consta din modele omogene (de exemplu, toate modelele XGBoost) sau eterogene (de exemplu, câteva XGBoost și câteva BERT). Poate consta în modele care sunt partajate în mai multe funcționalități de afaceri sau pot fi specifice pentru îndeplinirea unei singure funcționalități de afaceri.
- Modele comune – Dacă grupul logic constă din modele partajate, ușurința de a actualiza modelele și latența vor juca un rol major în arhitectura punctelor finale SageMaker. De exemplu, dacă latența este o prioritate, este mai bine să plasați toate modelele într-un singur container în spatele unui singur punct final SageMaker pentru a evita mai multe hopuri. Dezavantajul este că, dacă oricare dintre modele trebuie să fie actualizat, va avea ca rezultat actualizarea tuturor punctelor finale relevante SageMaker care găzduiesc acest model.
- Modele nedistribuite – Dacă grupul logic constă numai din modele specifice caracteristicilor de business și nu este partajat cu alte grupuri, complexitatea ambalajului și dimensiunile latenței vor deveni esențiale de realizat. Este recomandabil să găzduiți aceste modele într-un singur container în spatele unui singur punct final SageMaker.
- Utilizarea eficientă a hardware-ului (CPU, GPU) – Grupați modelele bazate pe CPU și găzduiți-le pe aceeași gazdă, astfel încât să puteți utiliza eficient procesorul. În mod similar, grupați modelele bazate pe GPU, astfel încât să le puteți utiliza și scala eficient. Există sarcini de lucru hibride care necesită atât CPU, cât și GPU pe aceeași gazdă. Găzduirea modelelor numai CPU și GPU pe aceeași gazdă ar trebui să fie determinată de cerințele de coeziune ridicată și de latență a aplicației. În plus, costul, capacitatea de scalare și raza exploziei la impact în caz de defecțiune sunt dimensiunile cheie de analizat.
- Funcții de fitness – Utilizați funcțiile de fitness ca ghid pentru selectarea unei opțiuni de găzduire ML.
Concluzie
Când vine vorba de găzduire ML, nu există o abordare universală. Practicanții ML trebuie să aleagă modelul de design potrivit pentru a-și aborda provocările de găzduire ML. Evaluarea funcțiilor de fitness oferă îndrumări prescriptive pentru selectarea opțiunii potrivite de găzduire ML.
Pentru mai multe detalii despre fiecare dintre opțiunile de găzduire, consultați următoarele postări din această serie:
Despre autori
Dhawal Patel este arhitect principal de învățare automată la AWS. El a lucrat cu organizații, de la întreprinderi mari până la startup-uri mijlocii, pe probleme legate de calculul distribuit și inteligența artificială. El se concentrează pe învățarea profundă, inclusiv pe domeniile NLP și Computer Vision. El îi ajută pe clienți să obțină inferențe de model de înaltă performanță pe SageMaker.
Deepali Rajale este manager de cont tehnic de specialitate AI/ML la Amazon Web Services. Lucrează cu clienții întreprinderi, oferind îndrumări tehnice pentru implementarea soluțiilor de învățare automată cu cele mai bune practici. În timpul liber, îi place drumețiile, filmele și petrecerea timpului cu familia și prietenii.
Saurabh Trikande este Senior Product Manager pentru Amazon SageMaker Inference. Este pasionat de lucrul cu clienții și este motivat de obiectivul democratizării învățării automate. El se concentrează pe provocările de bază legate de implementarea de aplicații ML complexe, modele ML multi-locatari, optimizări ale costurilor și de a face implementarea modelelor de învățare profundă mai accesibilă. În timpul liber, lui Saurabh îi place să facă drumeții, să învețe despre tehnologii inovatoare, să urmeze TechCrunch și să petreacă timpul cu familia sa.
- Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
- Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
- Sursa: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- capacitate
- Capabil
- Despre Noi
- accelerat
- acces
- accesate
- accesibil
- găzdui
- Cont
- precis
- Obține
- realizarea
- peste
- Acțiune
- activ
- plus
- Suplimentar
- În plus,
- adresa
- avansa
- avansat
- Avantaj
- Promovare
- afecta
- După
- agregare
- Agregator
- agresiv
- acorduri
- AI
- AI / ML
- alarmă
- algoritmi
- TOATE
- Permiterea
- permite
- deja
- mereu
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- sumă
- analiză
- analiza
- și
- și infrastructură
- anual
- O alta
- Apache
- api
- Apple
- aplicație
- aplicatii
- abordare
- adecvat
- Apps
- arhitectură
- ARM
- artificial
- inteligență artificială
- aspecte
- evaluare
- asociate
- atribute
- audio
- audituri
- Auto
- Automata
- Automat
- în mod automat
- disponibilitate
- disponibil
- in medie
- AWS
- înapoi
- sprijinit
- Bancar
- de bază
- bazat
- deoarece
- deveni
- devine
- înainte
- în spatele
- fiind
- beneficia
- CEL MAI BUN
- Cele mai bune practici
- Mai bine
- între
- biomedicale
- Bloca
- Imprumut
- limitele
- Cutie
- încălcarea
- Pauză
- aduce
- Aduce
- Bugete
- construi
- Clădire
- construit
- construit-in
- afaceri
- Aplicații pentru afaceri
- Procesul de afaceri
- întreprinderi
- Cache
- calculată
- apel
- denumit
- apelant
- candidaţilor
- capacități
- Capacitate
- pasă
- caz
- cazuri
- categorii
- cauze
- sigur
- Certificate
- provocări
- Schimbare
- Modificări
- Caracteristici
- încărcat
- chatbot
- verifica
- cip
- alegere
- alegeri
- Alege
- alegere
- clasă
- clasificare
- Clasifica
- client
- clientii
- Închide
- Cloud
- Grup
- cod
- inventat
- colegii
- colecta
- combaterea
- combinaţie
- combina
- combinate
- Comun
- Companii
- companie
- comparație
- Completă
- complet
- complex
- complexitate
- conformitate
- componente
- compuse
- compromis
- puterea de calcul
- Calcula
- calculator
- Computer Vision
- tehnica de calcul
- concept
- Îngrijorare
- concurent
- Configuraţie
- conexiune
- consistent
- consumate
- Consumatorii
- Recipient
- Containere
- conține
- continua
- continuă
- continuu
- Control
- Nucleu
- Corespunzător
- A costat
- economii
- cost-eficiente
- Cheltuieli
- ar putea
- crea
- creează
- critic
- crucial
- Curent
- personalizat
- client
- clienţii care
- DAG
- de date
- de prelucrare a datelor
- știința datelor
- om de știință de date
- Baza de date
- seturi de date
- zi
- abuzive
- Deciziile
- dedicat
- adânc
- învățare profundă
- Mod implicit
- definire
- livra
- Cerere
- cererile
- democratizarea
- În funcție
- depinde de
- implementa
- dislocate
- Implementarea
- desfășurarea
- implementări
- Amenajări
- modele de design
- proiectat
- detaliu
- detalii
- Detectare
- Determina
- Dezvoltator
- Dezvoltare
- diagrame
- diferit
- dificil
- Dimensiuni
- direcționa
- distinct
- distribuite
- calcul distribuit
- diferit
- Docher
- documente
- Nu
- domenii
- Dont
- jos
- Descarca
- dezavantaj
- condus
- scăzut
- scăparea
- în timpul
- dinamic
- fiecare
- Mai devreme
- mai ușor
- cu ușurință
- Eficace
- în mod eficient
- eficacitate
- eficiență
- eficient
- eficient
- efort
- oricare
- eliminarea
- permite
- permite
- criptare
- un capăt la altul
- Punct final
- Inginerie
- inginerii
- suficient de
- asigura
- asigură
- Afacere
- Companii
- Întreg
- Mediu inconjurator
- eroare
- Erori
- mai ales
- evaluat
- evaluări
- Chiar
- eveniment
- tot
- evoluţie
- exemplu
- exemple
- schimb
- Exponatele
- aștepta
- de aşteptat
- experienţă
- Experiențe
- explora
- expresii
- extern
- suplimentar
- Față
- factori
- Eșec
- destul de
- familii
- familie
- mai repede
- Caracteristică
- DESCRIERE
- hrănire
- puțini
- final
- First
- prima dată
- fitness
- FLOTA
- Flexibilitate
- debit
- fluctua
- se concentrează
- următor
- urmează
- vad
- formă
- formulare
- fracționar
- Cadru
- cadre
- fraudă
- detectarea fraudei
- Gratuit
- Frecvență
- frecvent
- Prietenii lui
- din
- Fructe
- Complet
- complet
- funcţie
- funcționalități
- funcționalitate
- funcții
- mai mult
- GDPR
- General
- generată
- generator
- obține
- Da
- dat
- scop
- Goluri
- bine
- GPU
- unități de procesare grafică
- grafic
- mare
- mai mare
- foarte mult
- grup
- Grupului
- Crește
- ghida
- manipula
- Mânere
- la indemana
- Piese metalice
- având în
- Sănătate
- de asistență medicală
- ajutor
- ajutor
- ajută
- aici
- Înalt
- performanta ridicata
- Rezoluție înaltă
- superior
- Lovit
- Orizontală
- gazdă
- găzduit
- găzduire
- costuri de gazduire
- servicii de gazduire
- Cum
- Totuși
- HTML
- HTTPS
- sute
- Hibrid
- ideal
- Identitate
- Idle
- imagine
- Clasificarea imaginilor
- imagini
- imuabil
- Impactul
- afectate
- Impacturi
- punerea în aplicare a
- implementat
- Punere în aplicare a
- important
- îmbunătăţi
- îmbunătățirea
- in
- include
- include
- Inclusiv
- Intrare
- Crește
- a crescut
- Creșteri
- crescând
- independent
- independent
- individ
- informații
- Infrastructură
- inițială
- inovatoare
- tehnologii inovatoare
- intrare
- Instalarea
- instanță
- in schimb
- integra
- integrare
- Inteligență
- interactiv
- implica
- ISO
- izolare
- IT
- Loc de munca
- Locuri de munca
- Cheie
- chei
- Cunoaște
- cunoscut
- mare
- mai mare
- Latență
- lansa
- lansează
- lansare
- conduce
- conducere
- Conduce
- AFLAȚI
- învăţare
- Părăsi
- Led
- Nivel
- biblioteci
- ridicare
- Limitat
- Limitele
- Listă
- trăi
- încărca
- încărcare
- loturile
- locaţie
- Lung
- mai lung
- Uite
- care pierde
- Lot
- Jos
- maşină
- masina de învățare
- făcut
- Principal
- menține
- susține
- major
- face
- FACE
- Efectuarea
- administra
- gestionate
- administrare
- manager
- gestionează
- de conducere
- multe
- Marketing
- matematic
- materie
- Maximaliza
- maxim
- mijloace
- Întâlni
- Memorie
- metodă
- Metode
- metric
- Metrici
- ar putea
- minim
- minim
- minute
- Amestecarea
- ML
- mod
- model
- Modele
- monitor
- Monitorizarea
- Lună
- luni
- mai mult
- cele mai multe
- motivat
- Filme
- Punct final cu mai multe modele
- multiplu
- multitudine
- Natură
- necesar
- Nevoie
- nevoilor
- reţea
- Nou
- următor
- nlp
- notificare
- notificări
- număr
- Nvidia
- obiect
- obiectiv
- Obiectivele
- obținerea
- ocazional
- oferi
- promoții
- Offline
- ONE
- on-line
- open-source
- funcionar
- opereaza
- de operare
- operațional
- Operațiuni
- Operatorii
- optimă
- optimizare
- Optimizați
- optimizate
- Optimizează
- optimizarea
- Opțiune
- Opţiuni
- Portocaliu
- comandă
- organizații
- Altele
- remarcabil
- global
- propriu
- proprietate
- pachet
- ambalaje
- parametrii
- parte
- special
- partener
- Trecut
- pasionat
- Patch-uri
- Model
- modele
- Plătește
- Vârf
- Efectua
- performanță
- efectuarea
- perioadă
- periodic
- perioadele
- personalizare
- Personalizat
- alege
- conducte
- Loc
- Locuri
- planificat
- Planurile
- platformă
- Platforme
- Plato
- Informații despre date Platon
- PlatoData
- Joaca
- la care se adauga
- Politicile
- Politica
- Popular
- posibil
- Post
- postări
- putere
- practică
- practicile
- predictibil
- estimarea
- prezicere
- Predictii
- preferat
- în prealabil
- preţ
- Principal
- prioritate
- privat
- Problemă
- probleme
- proces
- Procesat
- procese
- prelucrare
- procesoare
- Produs
- manager de produs
- producere
- Produse
- Profil
- adecvat
- furniza
- prevăzut
- furnizează
- furnizarea
- dispoziţie
- împuternicit
- scop
- Împinge
- pirtorh
- repede
- gamă
- variind
- repede
- rată
- tarife
- ajunge
- aTINGE
- Citeste
- gata
- real
- lumea reală
- în timp real
- a primi
- primit
- primește
- recomanda
- Recomandare
- Recomandări
- recomandat
- recomandând
- recomandă
- recurente
- reduce
- reduce
- se referă
- Fără deosebire
- regulat
- legate de
- Lansări
- rămășițe
- depozit
- reprezentate
- reprezintă
- solicita
- cereri de
- necesita
- necesar
- cerință
- Cerinţe
- Necesită
- resursă
- Resurse
- răspuns
- REST
- rezultat
- rezultând
- REZULTATE
- cu amănuntul
- Returnează
- revizuiască
- Risc
- Rol
- rădăcină
- Traseul
- Regula
- Alerga
- funcţionare
- SaaS
- sagemaker
- SageMaker Inference
- salariu
- acelaşi
- Economisiți
- economisire
- Economie
- scalabil
- Scară
- cântare
- scalare
- scenarii
- programa
- programată
- Ştiinţă
- Om de stiinta
- Al doilea
- secunde
- Secțiune
- secțiuni
- în siguranță,
- securitate
- selectarea
- selecţie
- senior
- sensibil
- Secvenţă
- de serie
- serie
- servi
- serverless
- Servere
- servește
- serviciu
- Servicii
- servire
- set
- instalare
- câteva
- fasonarea
- Distribuie
- comun
- Ture
- să
- Emisiuni
- semnificativ
- semnificativ
- asemănător
- asemănător
- simplu
- singur
- Mărimea
- dimensiuni
- mic
- mai mici
- So
- Software
- soluţie
- soluţii
- unele
- Surse
- Spaţiu
- specialist
- de specialitate
- specific
- specific
- specificată
- viteză
- Cheltuire
- piroane
- stabil
- stivui
- Stive
- Începe
- început
- începe
- lansare
- Startup-urile
- constant
- Pas
- paşi
- Încă
- opriri
- depozitare
- stoca
- strategii
- de streaming
- Strict
- tare
- ulterior
- succes
- de succes
- astfel de
- suficient
- potrivit
- a sustine
- Suportat
- Sprijină
- apare
- tabel
- Lua
- ia
- Ţintă
- vizate
- Sarcină
- sarcini
- echipă
- echipe
- TechCrunch
- Tehnic
- Tehnologii
- chiriaş
- tensorflow
- test
- Testarea
- lor
- se
- astfel
- prin urmare
- mii
- trei
- prag
- Prin
- de-a lungul
- debit
- timp
- ori
- la
- împreună
- de asemenea
- instrument
- Total
- tps
- Urmărire
- trafic
- Tren
- dresat
- Pregătire
- tranzacțional
- Tranzacții
- Transforma
- Transformare
- transformare
- tranzit
- transparent
- declanşa
- Triton
- ÎNTORCĂ
- Tipuri
- tipic
- tipic
- în
- care stau la baza
- înţelege
- unic
- de unităţi
- imprevizibil
- nefolosit
- Actualizează
- actualizări
- upgrade-ul
- modernizate
- uptime
- Folosire
- utilizare
- carcasa de utilizare
- Utilizator
- utilizatorii
- obișnuit
- folosi
- utilizate
- VALIDA
- valoare
- Valori
- Variantă
- diverse
- de
- Video
- Video
- Vizualizare
- Virtual
- viziune
- volum
- Vot
- voturi
- Deșeuri
- web
- servicii web
- săptămână
- Ce
- Ce este
- care
- în timp ce
- larg
- Gamă largă
- voi
- în
- fără
- Apartamente
- a lucrat
- lucrător
- muncitorii
- de lucru
- fabrică
- lume
- ar
- XGBoost
- an
- Tu
- Ta
- zephyrnet
- zero