Această postare este scrisă împreună cu Jad Chamoun, director de inginerie la Forethought Technologies, Inc. și Salina Wu, inginer senior ML la Forethought Technologies, Inc.
Chibzuire este o suită AI generativă lider pentru serviciul clienți. La baza suitei sale se află inovația SuportGPT™ tehnologia care folosește învățarea automată pentru a transforma ciclul de viață al asistenței pentru clienți — creșterea deflexiunii, îmbunătățirea CSAT și creșterea productivității agenților. SupportGPT™ folosește sisteme de ultimă generație de recuperare a informațiilor (IR) și modele de limbaje mari (LLM) pentru a genera peste 30 de milioane de interacțiuni cu clienții anual.
Cazul de utilizare principal al SupportGPT este îmbunătățirea calității și eficienței interacțiunilor și operațiunilor de asistență pentru clienți. Folosind sisteme IR de ultimă generație alimentate de modele de încorporare și de clasare, SupportGPT poate căuta rapid informații relevante, oferind răspunsuri precise și concise la întrebările clienților. Forethought utilizează modele ajustate pentru fiecare client pentru a detecta intențiile clienților pentru a rezolva interacțiunile cu clienții. Integrarea modelelor de limbaj mari ajută la umanizarea interacțiunii cu agenții automatizați, creând o experiență de asistență mai captivantă și mai satisfăcătoare.
SupportGPT ajută, de asemenea, agenții de asistență pentru clienți, oferind sugestii de completare automată și creând răspunsuri adecvate la biletele clienților care se aliniază cu cele ale companiei, pe baza răspunsurilor anterioare. Prin utilizarea modelelor lingvistice avansate, agenții pot aborda preocupările clienților mai rapid și mai precis, rezultând o satisfacție mai mare a clienților.
În plus, arhitectura SupportGPT permite detectarea lacunelor în bazele de cunoștințe de asistență, ceea ce îi ajută pe agenți să furnizeze informații mai precise clienților. Odată ce aceste lacune sunt identificate, SupportGPT poate genera automat articole și alt conținut pentru a umple aceste goluri de cunoștințe, asigurându-se că baza de cunoștințe de asistență rămâne centrată pe client și actualizată.
În această postare, împărtășim cum folosește Forethought Amazon SageMaker puncte finale cu mai multe modele în cazurile de utilizare a IA generativă pentru a economisi peste 66% din costuri.
Provocări ale infrastructurii
Pentru a ajuta la introducerea pe piață a acestor capabilități, Forethought își scalează eficient sarcinile de lucru ML și oferă soluții hiperpersonalizate adaptate cazului de utilizare specific al fiecărui client. Această hiperpersonalizare este realizată prin ajustarea fină a modelelor de încorporare și a clasificatoarelor pe datele clienților, asigurând rezultate precise de regăsire a informațiilor și cunoștințe de domeniu care răspund nevoilor unice ale fiecărui client. Modelele personalizate de completare automată sunt, de asemenea, reglate fin pe datele clienților pentru a îmbunătăți și mai mult acuratețea și relevanța răspunsurilor generate.
Una dintre provocările semnificative în procesarea AI este utilizarea eficientă a resurselor hardware, cum ar fi GPU-urile. Pentru a face față acestei provocări, Forethought folosește punctele finale multimodel (MME) SageMaker pentru a rula mai multe modele AI pe un singur punct final de inferență și la scară. Deoarece hiperpersonalizarea modelelor necesită antrenarea și implementarea modelelor unice, numărul de modele crește liniar cu numărul de clienți, ceea ce poate deveni costisitor.
Pentru a obține echilibrul corect de performanță pentru inferență și cost în timp real, Forethought a ales să folosească MME-uri SageMaker, care acceptă accelerarea GPU. MME-urile SageMaker îi permit Forethought să ofere soluții de înaltă performanță, scalabile și rentabile, cu o latență sub secundă, abordând mai multe scenarii de asistență pentru clienți la scară.
SageMaker și Forethought
SageMaker este un serviciu complet gestionat care oferă dezvoltatorilor și cercetătorilor de date capacitatea de a construi, antrena și implementa rapid modele ML. SageMaker MME oferă o soluție scalabilă și rentabilă pentru implementarea unui număr mare de modele pentru inferență în timp real. MME-urile folosesc un container de servire partajat și o flotă de resurse care pot folosi instanțe accelerate, cum ar fi GPU-urile, pentru a găzdui toate modelele dvs. Acest lucru reduce costurile de găzduire prin maximizarea utilizării punctelor finale în comparație cu utilizarea punctelor finale cu un singur model. De asemenea, reduce costul general de implementare, deoarece SageMaker gestionează încărcarea și descărcarea modelelor în memorie și scalarea acestora în funcție de tiparele de trafic ale punctului final. În plus, toate punctele finale în timp real SageMaker beneficiază de capabilități încorporate de gestionare și monitorizare a modelelor, cum ar fi inclusiv variante de umbră, scalare automată, și integrarea nativă cu Amazon CloudWatch (pentru mai multe informații, consultați Valori CloudWatch pentru implementări de puncte finale cu mai multe modele).
Pe măsură ce Forethought a crescut pentru a găzdui sute de modele care necesitau și resurse GPU, am văzut o oportunitate de a crea o arhitectură mai rentabilă, mai fiabilă și mai gestionabilă prin intermediul MME-urilor SageMaker. Înainte de a migra la SageMaker MME, modelele noastre au fost implementate pe Kubernetes Serviciul Amazon Elastic Kubernetes (Amazon EKS). Deși Amazon EKS a oferit capabilități de gestionare, a fost imediat evident că gestionam infrastructura care nu a fost special adaptată pentru inferență. A trebuit să gestionăm noi înșine inferența modelului pe Amazon EKS, ceea ce a reprezentat o povară pentru eficiența ingineriei. De exemplu, pentru a împărți resursele GPU costisitoare între mai multe modele, am fost responsabili pentru alocarea fracțiilor rigide de memorie modelelor care au fost specificate în timpul implementării. Am dorit să abordăm următoarele probleme cheie cu infrastructura noastră existentă:
- Cost ridicat – Pentru a ne asigura că fiecare model are suficiente resurse, am fi foarte conservatori în ceea ce privește câte modele să se potrivească pentru fiecare caz. Acest lucru a dus la costuri mult mai mari pentru găzduirea modelului decât era necesar.
- Fiabilitate scăzută – În ciuda faptului că sunt conservatori în alocarea memoriei, nu toate modelele au aceleași cerințe și, ocazional, unele modele ar arunca erori din memorie (OOM).
- Management ineficient – A trebuit să gestionăm diferite manifeste de implementare pentru fiecare tip de model (cum ar fi clasificatoare, încorporare și completare automată), care a fost consumatoare de timp și predispusă la erori. De asemenea, a trebuit să menținem logica pentru a determina alocarea memoriei pentru diferite tipuri de modele.
În cele din urmă, aveam nevoie de o platformă de inferență care să ne asumăm sarcinile grele legate de gestionarea modelelor noastre în timpul execuției, pentru a îmbunătăți costurile, fiabilitatea și gestionarea deservirii modelelor noastre. MME-urile SageMaker ne-au permis să răspundem acestor nevoi.
Prin încărcarea și descărcarea modelelor inteligente și dinamice și prin capacitățile sale de scalare, MME-urile SageMaker au oferit o soluție mult mai puțin costisitoare și mai fiabilă pentru găzduirea modelelor noastre. Acum suntem capabili să potrivim mult mai multe modele per instanță și nu trebuie să ne facem griji cu privire la erorile OOM, deoarece MME-urile SageMaker gestionează în mod dinamic încărcarea și descărcarea modelelor. În plus, implementările sunt acum la fel de simple ca apelarea API-urilor Boto3 SageMaker și atașarea politicilor adecvate de scalare automată.
Următoarea diagramă ilustrează arhitectura noastră moștenită.
Pentru a începe migrarea către SageMaker MME, am identificat cele mai bune cazuri de utilizare pentru MME și care dintre modelele noastre ar beneficia cel mai mult de pe urma acestei schimbări. MME-urile sunt utilizate cel mai bine pentru următoarele:
- Modele despre care se așteaptă să aibă o latență scăzută, dar care pot rezista la o pornire la rece (când sunt încărcate pentru prima dată)
- Modele care sunt numite des și în mod constant
- Modele care necesită resurse GPU parțiale
- Modele care împărtășesc cerințe comune și logica de inferență
Am identificat modelele noastre de încorporare și modelele de limbaj de completare automată drept cei mai buni candidați pentru migrarea noastră. Pentru a organiza aceste modele în MME-uri, am crea un MME pentru fiecare tip de model sau sarcină, unul pentru modelele noastre de încorporare și altul pentru modelele de limbaj de completare automată.
Aveam deja un strat API pe deasupra modelelor noastre pentru managementul modelului și inferența. Sarcina noastră a fost să reluăm modul în care acest API a fost implementat și gestionat inferența asupra modelelor sub capotă cu SageMaker, cu modificări minime la modul în care clienții și echipele de produs interacționau cu API-ul. De asemenea, trebuia să ne ambalăm modelele și logica de inferență personalizată pentru a fi compatibile cu NVIDIA Triton Inference Server folosind MME-uri SageMaker.
Următoarea diagramă ilustrează noua noastră arhitectură.
Logica de inferență personalizată
Înainte de a migra la SageMaker, codul de inferență personalizat al Forethought (preprocesare și postprocesare) rula în stratul API atunci când era invocat un model. Obiectivul a fost transferul acestei funcționalități în modelul în sine pentru a clarifica separarea responsabilităților, a modulariza și simplifica codul acestora și a reduce sarcina pe API.
Încorporări
Modelele de încorporare ale Forethought constau din două artefacte de model PyTorch, iar cererea de inferență determină ce model să apeleze. Fiecare model necesită text preprocesat ca intrare. Principalele provocări au fost integrarea unui pas de preprocesare și găzduirea a două artefacte de model per definiție de model. Pentru a răspunde nevoii de mai mulți pași în logica de inferență, Forethought a dezvoltat un model de ansamblu Triton cu doi pași: un proces de preprocesare Python backend și un apel de model PyTorch backend. Modelele de ansamblu permit definirea și ordonarea pașilor în logica de inferență, fiecare pas fiind reprezentat de un model Triton de orice tip de backend. Pentru a asigura compatibilitatea cu backend-ul Triton PyTorch, artefactele modelului existente au fost convertite în format TorchScript. Au fost create modele Triton separate pentru fiecare definiție de model, iar stratul API al Forethought a fost responsabil pentru determinarea TargetModel
pentru a invoca pe baza cererii primite.
Completare automată
Modelele de autocompletare (secvență la secvență) au prezentat un set distinct de cerințe. Mai exact, trebuia să permitem capacitatea de a trece prin mai multe apeluri de model și de a stoca intrări substanțiale în cache pentru fiecare apel, totul menținând o latență scăzută. În plus, aceste modele au necesitat atât pași de preprocesare, cât și pași de postprocesare. Pentru a răspunde acestor cerințe și a obține flexibilitatea dorită, Forethought a dezvoltat modele MME de completare automată utilizând backend-ul Triton Python, care oferă avantajul scrierii modelului ca cod Python.
Benchmarking
După ce au fost determinate formele modelului Triton, am implementat modele la punctele finale de punere în scenă și am efectuat compararea resurselor și a performanței. Scopul nostru principal a fost să determinăm latența pentru pornirea la rece față de modelele în memorie și modul în care latența a fost afectată de dimensiunea cererii și concurența. Am vrut, de asemenea, să știm câte modele s-ar putea încadra pe fiecare instanță, câte modele ar determina extinderea instanțelelor cu politica noastră de scalare automată și cât de repede s-ar întâmpla extinderea. În conformitate cu tipurile de instanțe pe care le folosim deja, ne-am făcut benchmarking-ul cu instanțe ml.g4dn.xlarge și ml.g4dn.2xlarge.
REZULTATE
Următorul tabel rezumă rezultatele noastre.
Solicitați dimensiune | Latența de pornire la rece | Latența de inferență în cache | Latență simultană (5 solicitări) |
Mic (30 de jetoane) | 12.7 secunde | 0.03 secunde | 0.12 secunde |
Mediu (250 de jetoane) | 12.7 secunde | 0.05 secunde | 0.12 secunde |
Mare (550 de jetoane) | 12.7 secunde | 0.13 secunde | 0.12 secunde |
În mod remarcabil, latența pentru cererile de pornire la rece este semnificativ mai mare decât latența pentru cererile de inferență stocate în cache. Acest lucru se datorează faptului că modelul trebuie să fie încărcat de pe disc sau Serviciul Amazon de stocare simplă (Amazon S3) când se face o cerere de pornire la rece. Latența pentru cererile simultane este, de asemenea, mai mare decât latența pentru cererile individuale. Acest lucru se datorează faptului că modelul trebuie să fie partajat între solicitările concurente, ceea ce poate duce la dispute.
Următorul tabel compară latența modelelor vechi și a modelelor SageMaker.
Solicitați dimensiune | Modele moștenite | Modele SageMaker |
Mic (30 de jetoane) | 0.74 secunde | 0.24 secunde |
Mediu (250 de jetoane) | 0.74 secunde | 0.24 secunde |
Mare (550 de jetoane) | 0.80 secunde | 0.32 secunde |
În general, modelele SageMaker sunt o alegere mai bună pentru găzduirea modelelor de completare automată decât modelele vechi. Ele oferă o latență, scalabilitate, fiabilitate și securitate mai scăzute.
Utilizarea resurselor
În încercarea noastră de a determina numărul optim de modele care s-ar putea potrivi în fiecare caz, am efectuat o serie de teste. Experimentul nostru a implicat încărcarea modelelor în punctele noastre finale folosind un tip de instanță ml.g4dn.xlarge, fără nicio politică de scalare automată.
Aceste instanțe speciale oferă 15.5 GB de memorie și ne-am propus să atingem aproximativ 80% utilizarea memoriei GPU per instanță. Având în vedere dimensiunea fiecărui artefact de model de codificator, am reușit să găsim numărul optim de codificatoare Triton de încărcat pe o instanță pentru a atinge utilizarea țintită a memoriei GPU. În plus, având în vedere că fiecare dintre modelele noastre de înglobare corespunde cu două modele de codificator Triton, am putut găzdui un număr stabilit de modele de încorporare per instanță. Ca rezultat, am calculat numărul total de instanțe necesare pentru a servi toate modelele noastre de încorporare. Această experimentare a fost crucială în optimizarea utilizării resurselor noastre și în îmbunătățirea eficienței modelelor noastre.
Am efectuat analize comparative similare pentru modelele noastre de completare automată. Aceste modele aveau aproximativ 292.0 MB fiecare. Pe măsură ce am testat câte modele s-ar potrivi pe o singură instanță ml.g4dn.xlarge, am observat că am reușit să potrivim doar patru modele înainte ca instanța noastră să înceapă să descarce modele, în ciuda modelelor având o dimensiune mică. Principalele noastre preocupări au fost:
- Cauza creșterii utilizării memoriei CPU
- Motivul pentru care modelele se descarcă atunci când am încercat să încărcăm încă un model în loc de modelul cel mai puțin folosit recent (LRU).
Am reușit să identificăm cauza principală a creșterii utilizării memoriei care provine din inițializarea mediului nostru de rulare CUDA în modelul nostru Python, care a fost necesar pentru a muta modelele și datele noastre pe și de pe dispozitivul GPU. CUDA încarcă multe dependențe externe în memoria CPU atunci când timpul de execuție este inițializat. Deoarece backend-ul Triton PyTorch gestionează și retrage datele în mișcare pe și în afara dispozitivului GPU, nu am întâlnit această problemă pentru modelele noastre de încorporare. Pentru a rezolva acest lucru, am încercat să folosim instanțe ml.g4dn.2xlarge, care aveau aceeași cantitate de memorie GPU, dar de două ori mai multă memorie CPU. În plus, am adăugat câteva optimizări minore în codul nostru backend Python, inclusiv ștergerea tensoarelor după utilizare, golirea memoriei cache, dezactivarea gradienților și colectarea gunoiului. Cu tipul de instanță mai mare, am reușit să potrivim 10 modele per instanță, iar utilizarea memoriei CPU și GPU a devenit mult mai aliniată.
Următoarea diagramă ilustrează această arhitectură.
Scalare automată
Am atașat politici de scalare automată atât înglobărilor noastre, cât și MME-urilor de completare automată. Politica noastră pentru punctul final de încorporare a vizat o utilizare medie a memoriei GPU de 80% folosind valori personalizate. Modelele noastre de completare automată au observat un model de trafic ridicat în timpul orelor de lucru și trafic minim peste noapte. Din acest motiv, am creat o politică de scalare automată bazată pe InvocationsPerInstance
astfel încât să putem scala în funcție de tiparele de trafic, economisind costuri fără a sacrifica fiabilitatea. Pe baza analizei comparative privind utilizarea resurselor, ne-am configurat politicile de scalare cu o țintă de 225 InvocationsPerInstance
.
Implementați logica și pipeline
Crearea unui MME pe SageMaker este simplă și similară cu crearea oricărui alt punct final pe SageMaker. După ce punctul final este creat, adăugarea unor modele suplimentare la punctul final este la fel de simplă ca mutarea artefactului modelului pe calea S3 pe care o țintește punctul final; în acest moment, putem face cereri de inferență noului nostru model.
Am definit o logică care să preia metadatele modelului, să formateze punctul final în mod determinist pe baza metadatelor și să verifice dacă punctul final a existat. Dacă nu a făcut-o, creăm punctul final și adăugăm artefactul modelului Triton la patch-ul S3 pentru punctul final (formatat și determinist). De exemplu, dacă metadatele modelului au indicat că este un model de completare automată, ar crea un punct final pentru modelele de completare automată și o cale S3 asociată pentru artefactele modelului de completare automată. Dacă punctul final ar exista, am copia artefactul modelului pe calea S3.
Acum că aveam modelele noastre pentru modelele noastre MME și funcționalitatea pentru implementarea modelelor noastre în MME, aveam nevoie de o modalitate de a automatiza implementarea. Utilizatorii noștri trebuie să specifice ce model doresc să implementeze; ne ocupăm de ambalarea și implementarea modelului. Codul de inferență personalizat împachetat cu modelul este versiuneat și trimis către Amazon S3; în pasul de ambalare, tragem codul de inferență în funcție de versiunea specificată (sau cea mai recentă versiune) și folosim fișiere YAML care indică structurile de fișiere ale modelelor Triton.
O cerință pentru noi a fost ca toate modelele noastre MME să fie încărcate în memorie pentru a evita orice latență de pornire la rece în timpul solicitărilor de inferență de producție de încărcare în modele. Pentru a realiza acest lucru, punem la dispoziție suficiente resurse pentru a se potrivi tuturor modelelor noastre (conform benchmarking-ului precedent) și apelăm fiecare model din MME la o cadență orară.
Următoarea diagramă ilustrează conducta de implementare a modelului.
Următoarea diagramă ilustrează conducta de încălzire a modelului.
Invocarea modelului
Stratul nostru API existent oferă o abstractizare pentru ca apelanții să facă inferențe asupra tuturor modelelor noastre ML. Acest lucru însemna că trebuia doar să adăugăm funcționalități la stratul API pentru a apela SageMaker MME cu modelul țintă corect, în funcție de cererea de inferență, fără nicio modificare a codului de apelare. Codul de inferență SageMaker preia cererea de inferență, formatează intrările Triton definite în modelele noastre Triton și invocă MME-urile folosind Boto3.
Cost beneficii
Forethought a făcut progrese semnificative în reducerea costurilor de găzduire a modelelor și atenuarea erorilor OOM de model, datorită migrării la MME-uri SageMaker. Înainte de această modificare, instanțe ml.g4dn.xlarge rulează în Amazon EKS. Odată cu trecerea la MME-uri, am descoperit că ar putea găzdui 12 modele de încorporare per instanță, obținând în același timp o utilizare de 80% a memoriei GPU. Acest lucru a dus la o scădere semnificativă a cheltuielilor noastre lunare. Pentru a o pune în perspectivă, am realizat o economie de costuri de până la 80%. Mai mult, pentru a gestiona un trafic mai mare, am luat în considerare extinderea replicilor. Presupunând un scenariu în care folosim trei replici, am constatat că economiile noastre de costuri ar fi în continuare substanțiale chiar și în aceste condiții, oscilând în jurul valorii de 43%.
Călătoria cu SageMaker MME s-a dovedit a fi benefică din punct de vedere financiar, reducându-ne cheltuielile, asigurând în același timp performanța optimă a modelului. Anterior, modelele noastre de limbaj de completare automată au fost implementate în Amazon EKS, necesitând un număr variabil de instanțe ml.g4dn.xlarge în funcție de alocarea memoriei per model. Acest lucru a dus la un cost lunar considerabil. Cu toate acestea, odată cu migrarea noastră recentă la SageMaker MME, am reușit să reducem substanțial aceste costuri. Acum găzduim toate modelele noastre pe instanțe ml.g4dn.2xlarge, oferindu-ne posibilitatea de a împacheta modele mai eficient. Acest lucru a redus semnificativ cheltuielile noastre lunare și acum am realizat economii de costuri în intervalul 66–74%. Această mișcare a demonstrat cât de eficientă utilizarea resurselor poate duce la economii financiare semnificative folosind MME-urile SageMaker.
Concluzie
În această postare, am analizat modul în care Forethought utilizează punctele finale multi-model SageMaker pentru a reduce costurile pentru inferența în timp real. SageMaker preia ridicarea greutății nediferențiate, astfel încât Forethought poate crește eficiența ingineriei. De asemenea, permite Forethought să scadă drastic costul pentru inferența în timp real, menținând în același timp performanța necesară pentru operațiunile critice pentru afaceri. Procedând astfel, Forethought este capabil să ofere o ofertă diferențiată pentru clienții lor folosind modele hiperpersonalizate. Utilizați SageMaker MME pentru a vă găzdui modelele la scară și pentru a reduce costurile de găzduire prin îmbunătățirea utilizării punctelor finale. De asemenea, reduce costul general de implementare, deoarece Amazon SageMaker gestionează încărcarea modelelor în memorie și scalarea acestora în funcție de tiparele de trafic către punctul final. Puteți găsi exemple de cod pentru găzduirea mai multor modele folosind SageMaker MME GitHub.
Despre Autori
Jad Chamoun este director de inginerie de bază la Forethought. Echipa sa se concentrează pe ingineria platformei care acoperă ingineria datelor, infrastructura de învățare automată și infrastructura cloud. Îl poți găsi pe LinkedIn.
Salina Wu este inginer Sr. Machine Learning Infrastructure la Forethought.ai. Ea lucrează îndeaproape cu echipa de învățare automată pentru a construi și a menține infrastructurile de instruire, de servire și de date end-to-end. Este motivată în special de introducerea de noi modalități de îmbunătățire a eficienței și de reducere a costurilor în spațiul ML. Când nu este la serviciu, Salinei îi place să facă surfing, ceramică și să fie în natură.
James Park este arhitect de soluții la Amazon Web Services. El lucrează cu Amazon.com pentru a proiecta, construi și implementa soluții tehnologice pe AWS și are un interes deosebit pentru AI și învățarea automată. În timpul liber, îi place să caute noi culturi, experiențe noi și să fie la curent cu cele mai recente tendințe tehnologice. Îl puteți găsi pe LinkedIn.
Sunil Padmanabhan este arhitect de soluții de pornire la AWS. În calitate de fost fondator de startup și CTO, este pasionat de învățarea automată și se concentrează pe a ajuta startup-urile să utilizeze AI/ML pentru rezultatele lor de afaceri și să proiecteze și să implementeze soluții ML/AI la scară.
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.
- Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
- EVM Finance. Interfață unificată pentru finanțare descentralizată. Accesați Aici.
- Grupul Quantum Media. IR/PR amplificat. Accesați Aici.
- PlatoAiStream. Web3 Data Intelligence. Cunoștințe amplificate. Accesați Aici.
- Sursa: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :are
- :este
- :nu
- :Unde
- $UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- capacitate
- Capabil
- Despre Noi
- abstracție
- rezumate
- accelerat
- Conform
- precizie
- precis
- precis
- Obține
- realizat
- realizarea
- peste
- adăuga
- adăugat
- adăugare
- plus
- Suplimentar
- În plus,
- adresa
- adresare
- avansat
- Avantaj
- După
- Agent
- agenţi
- AI
- ai cazuri de utilizare
- AI / ML
- vizează
- alinia
- aliniat
- TOATE
- alocare
- permite
- permite
- deja
- de asemenea
- Cu toate ca
- Amazon
- Amazon SageMaker
- Amazon Web Services
- Amazon.com
- sumă
- an
- și
- Anual
- O alta
- răspunsuri
- Orice
- api
- API-uri
- aparent
- adecvat
- aproximativ
- arhitectură
- SUNT
- în jurul
- bunuri
- artificial
- inteligență artificială
- AS
- asistă
- asociate
- At
- Auto
- automatizarea
- Automata
- în mod automat
- in medie
- evita
- departe
- AWS
- Backend
- Sold
- de bază
- bazat
- BE
- a devenit
- deoarece
- deveni
- fost
- înainte
- începe
- fiind
- analiza comparativă
- benefică
- beneficia
- CEL MAI BUN
- Mai bine
- între
- stimularea
- atât
- aduce
- construi
- construit-in
- povară
- afaceri
- dar
- by
- Cache
- calculată
- apel
- denumit
- apel
- apeluri
- CAN
- candidaţilor
- capacități
- caz
- cazuri
- satisface
- Provoca
- contesta
- provocări
- Schimbare
- Modificări
- verifica
- alegere
- a ales
- clientii
- îndeaproape
- Cloud
- infrastructura cloud
- cod
- rece
- Colectare
- COM
- venire
- Comun
- Compania
- comparație
- compatibilitate
- compatibil
- calculator
- Computer Vision
- tehnica de calcul
- preocupările
- concurent
- Condiții
- efectuat
- configurat
- conservator
- considerabil
- luate în considerare
- luand in considerare
- Recipient
- conţinut
- convertit
- Nucleu
- corecta
- corespunde
- A costat
- economii
- cost-eficiente
- costisitor
- Cheltuieli
- ar putea
- acoperire
- crea
- a creat
- Crearea
- crucial
- CTO
- personalizat
- client
- datele despre consumator
- Satisfactia clientului
- Serviciu clienți
- Relații Clienți
- clienţii care
- personalizate
- de date
- Data
- Refuzați
- scădea
- adânc
- învățare profundă
- definit
- definire
- livra
- livrarea
- demonstrat
- În funcție
- implementa
- dislocate
- Implementarea
- desfășurarea
- implementări
- Amenajări
- dorit
- În ciuda
- Determina
- determinat
- determină
- determinarea
- dezvoltat
- Dezvoltatorii
- dispozitiv
- FĂCUT
- diferit
- diferențiat
- Director
- a descoperit
- distinct
- distribuite
- calcul distribuit
- face
- domeniu
- domenii
- Dont
- dramatic
- în timpul
- dinamic
- dinamic
- fiecare
- eficiență
- eficient
- eficient
- Încorporarea
- permite
- permite
- un capăt la altul
- Punct final
- captivant
- inginer
- Inginerie
- spori
- consolidarea
- suficient de
- asigura
- asigurare
- Companii
- Mediu inconjurator
- Erori
- Chiar
- Fiecare
- exemplu
- existent
- de aşteptat
- cheltuieli
- scump
- experienţă
- Experiențe
- experiment
- extern
- mai repede
- Fișier
- Fişiere
- umple
- financiar
- financiar
- Găsi
- First
- potrivi
- FLOTA
- Flexibilitate
- se concentrează
- următor
- Pentru
- format
- Fost
- găsit
- fondator
- patru
- din
- complet
- funcționalitate
- mai mult
- În plus
- lacune
- genera
- generată
- generativ
- AI generativă
- obtinerea
- gif
- dat
- Oferirea
- scop
- GPU
- unități de procesare grafică
- gradienți
- HAD
- mână
- manipula
- Mânere
- Manipularea
- întâmpla
- Piese metalice
- Avea
- având în
- he
- greu
- ridicare de greutati
- ajutor
- ajutor
- ajută
- Înalt
- performanta ridicata
- superior
- -l
- lui
- capotă
- gazdă
- găzduire
- costuri de gazduire
- ORE
- casă
- Cum
- Totuși
- HTML
- http
- HTTPS
- sute
- identificat
- if
- ilustrează
- imediat
- îmbunătăţi
- îmbunătățirea
- in
- Inc
- Inclusiv
- Intrare
- Crește
- indica
- indicată
- informații
- Infrastructură
- infrastructură
- inovatoare
- intrare
- intrări
- instanță
- in schimb
- integrarea
- integrare
- Inteligență
- interacţiune
- interacţiuni
- interes
- în
- introducerea
- invocat
- invocă
- implicat
- problema
- IT
- ESTE
- în sine
- călătorie
- jpg
- doar
- păstrare
- Cheie
- Cunoaște
- cunoştinţe
- limbă
- mare
- Întreprinderi mari
- mai mare
- Latență
- Ultimele
- strat
- conduce
- conducere
- învăţare
- cel mai puțin
- Led
- Moştenire
- mai puțin
- Pârghie
- pîrghii
- ridicare
- încărca
- încărcare
- loturile
- logică
- Jos
- LOWER
- maşină
- masina de învățare
- făcut
- Principal
- menține
- Mentine
- face
- administra
- gestionate
- administrare
- gestionează
- de conducere
- multe
- Piață
- maximizarea
- a însemnat
- Memorie
- Metadata
- Metrici
- Migrarea
- migrațiune
- milion
- minim
- minor
- atenuant
- ML
- model
- Modele
- monitor
- lunar
- mai mult
- În plus
- cele mai multe
- motivat
- muta
- în mişcare
- mult
- Punct final cu mai multe modele
- multiplu
- trebuie sa
- nativ
- Natură
- necesar
- Nevoie
- necesar
- nevoilor
- Nou
- nlp
- acum
- număr
- Nvidia
- obiectiv
- of
- de pe
- oferi
- oferind
- promoții
- de multe ori
- on
- dată
- ONE
- afară
- Operațiuni
- Oportunitate
- optimă
- optimizarea
- or
- comandă
- organizații
- Altele
- al nostru
- ne
- afară
- rezultate
- peste
- peste noapte
- Ambalaj
- pachet
- ambalate
- ambalaje
- special
- în special
- pasionat
- Plasture
- cale
- Model
- modele
- performanță
- perspectivă
- conducte
- platformă
- Plato
- Informații despre date Platon
- PlatoData
- Punct
- Politicile
- Politica
- Post
- putere
- alimentat
- prezentat
- precedent
- în prealabil
- primar
- Principal
- anterior
- probleme
- proces
- prelucrare
- Produs
- producere
- productivitate
- adecvat
- dovedit
- furniza
- prevăzut
- furnizează
- dispoziţie
- împins
- pune
- Piton
- pirtorh
- calitate
- interogări
- căutare
- repede
- gamă
- variind
- Clasat
- ajunge
- în timp real
- realizat
- recent
- recent
- reduce
- reduce
- reducerea
- legate de
- relevanţa
- încredere
- de încredere
- rămășițe
- reprezentate
- solicita
- cereri de
- necesar
- cerință
- Cerinţe
- Necesită
- resursă
- Resurse
- răspunsuri
- responsabilităţi
- responsabil
- rezultat
- rezultând
- REZULTATE
- revizuite
- dreapta
- rigid
- rădăcină
- Alerga
- funcţionare
- sacrificare
- sagemaker
- SageMaker Inference
- acelaşi
- satisfacție
- Economisiți
- economisire
- Economie
- văzut
- scalabilitate
- scalabil
- Scară
- intensifice
- cântare
- scalare
- scenariu
- scenarii
- oamenii de stiinta
- Caută
- securitate
- caută
- senior
- distinct
- Secvenţă
- serie
- servi
- serviciu
- Servicii
- servire
- set
- câteva
- Umbră
- forme
- Distribuie
- comun
- ea
- semnificativ
- semnificativ
- asemănător
- simplu
- simplifica
- singur
- Mărimea
- mic
- inteligent
- So
- soluţie
- soluţii
- REZOLVAREA
- unele
- Spaţiu
- specific
- specific
- specificată
- cui
- înscenare
- Începe
- început
- lansare
- Startup-urile
- de ultimă oră
- Pas
- paşi
- Încă
- depozitare
- simplu
- pași
- substanțial
- astfel de
- suită
- a sustine
- sisteme
- tabel
- aborda
- adaptate
- Lua
- ia
- Ţintă
- vizate
- obiective
- Sarcină
- echipă
- echipe
- Tehnologii
- Tehnologia
- testat
- teste
- decât
- mulțumesc
- acea
- lor
- Lor
- Acestea
- ei
- acest
- trei
- Prin
- bilete
- timp
- consumă timp
- la
- indicativele
- top
- Total
- trafic
- Tren
- dresat
- Pregătire
- transfer
- Transforma
- tranziţie
- Tendinţe
- încercat
- Triton
- De două ori
- Două
- tip
- Tipuri
- în
- unic
- us
- Folosire
- utilizare
- carcasa de utilizare
- utilizat
- utilizatorii
- utilizări
- folosind
- Utilizand
- versiune
- foarte
- viziune
- vs
- vrea
- dorit
- a fost
- Cale..
- modalități de
- we
- web
- servicii web
- au fost
- cand
- dacă
- care
- în timp ce
- cu
- fără
- Apartamente
- a lucrat
- fabrică
- face griji
- ar
- scris
- wu
- yaml
- Tu
- Ta
- zephyrnet