Dette innlegget er skrevet sammen med Jad Chamoun, Director of Engineering i Forethought Technologies, Inc. og Salina Wu, Senior ML Engineer hos Forethought Technologies, Inc.
Fortenkt er en ledende generativ AI-suite for kundeservice. Kjernen i suiten er det innovative Støtter GPT™ teknologi som bruker maskinlæring for å transformere kundestøttens livssyklus – øker avbøyningen, forbedrer CSAT og øker agentproduktiviteten. SupportGPT™ utnytter state-of-the-art systemer for informasjonsinnhenting (IR) og store språkmodeller (LLM) for å drive over 30 millioner kundeinteraksjoner årlig.
SupportGPTs primære bruksområde er å forbedre kvaliteten og effektiviteten til kundestøtteinteraksjoner og operasjoner. Ved å bruke state-of-the-art IR-systemer drevet av innebygginger og rangeringsmodeller, kan SupportGPT raskt søke etter relevant informasjon, og levere nøyaktige og konsise svar på kundespørsmål. Forethought bruker finjusterte modeller per kunde for å oppdage kundehensikter for å løse kundeinteraksjoner. Integreringen av store språkmodeller hjelper til med å humanisere interaksjonen med automatiserte agenter, og skaper en mer engasjerende og tilfredsstillende støtteopplevelse.
SupportGPT bistår også kundestøtteagenter ved å tilby autofullføringsforslag og lage passende svar på kundebilletter som stemmer overens med selskapets basert på tidligere svar. Ved å bruke avanserte språkmodeller kan agenter løse kundenes bekymringer raskere og mer nøyaktig, noe som resulterer i høyere kundetilfredshet.
I tillegg gjør SupportGPTs arkitektur det mulig å oppdage hull i støttekunnskapsbaser, noe som hjelper agenter med å gi mer nøyaktig informasjon til kundene. Når disse hullene er identifisert, kan SupportGPT automatisk generere artikler og annet innhold for å fylle disse kunnskapshullene, og sikre at støttekunnskapsbasen forblir kundesentrert og oppdatert.
I dette innlegget deler vi hvordan Forethought bruker Amazon SageMaker endepunkter for flere modeller i generative AI-brukstilfeller for å spare over 66 % i kostnader.
Infrastrukturutfordringer
For å bidra til å bringe disse egenskapene til markedet, skalerer Forethought effektivt sine ML-arbeidsmengder og gir hyper-personlige løsninger skreddersydd for hver kundes spesifikke brukssituasjon. Denne hyper-personaliseringen oppnås gjennom å finjustere innbyggingsmodeller og klassifiserere på kundedata, for å sikre nøyaktige resultater for informasjonsinnhenting og domenekunnskap som imøtekommer hver klients unike behov. De tilpassede autofullføringsmodellene er også finjustert på kundedata for ytterligere å forbedre nøyaktigheten og relevansen til svarene som genereres.
En av de betydelige utfordringene i AI-behandling er effektiv utnyttelse av maskinvareressurser som GPUer. For å takle denne utfordringen bruker Forethought SageMaker multi-model endpoints (MME) for å kjøre flere AI-modeller på ett enkelt slutningsendepunkt og skala. Fordi hyperpersonalisering av modeller krever at unike modeller trenes opp og distribueres, skalerer antallet modeller lineært med antall klienter, noe som kan bli kostbart.
For å oppnå den rette balansen mellom ytelse for sanntidsslutning og kostnader, valgte Forethought å bruke SageMaker MME-er, som støtter GPU-akselerasjon. SageMaker MME-er gjør det mulig for Forethought å levere høyytelses, skalerbare og kostnadseffektive løsninger med sekundær ventetid, og adresserer flere kundestøttescenarier i stor skala.
SageMaker og Forethought
SageMaker er en fullstendig administrert tjeneste som gir utviklere og dataforskere muligheten til å bygge, trene og distribuere ML-modeller raskt. SageMaker MMEer gir en skalerbar og kostnadseffektiv løsning for å distribuere et stort antall modeller for sanntidsslutning. MME-er bruker en delt serveringsbeholder og en flåte med ressurser som kan bruke akselererte forekomster som GPU-er til å være vert for alle modellene dine. Dette reduserer hostingkostnadene ved å maksimere endepunktutnyttelsen sammenlignet med å bruke enkeltmodellende endepunkter. Det reduserer også distribusjonskostnader fordi SageMaker administrerer lasting og lossing av modeller i minnet og skalerer dem basert på endepunktets trafikkmønstre. I tillegg drar alle SageMaker sanntidsendepunkter nytte av innebygde muligheter for å administrere og overvåke modeller, for eksempel inkludert skyggevarianter, automatisk skalering, og innfødt integrasjon med Amazon CloudWatch (for mer informasjon, se CloudWatch Metrics for Multi-Model Endpoint Deployment).
Etter hvert som Forethought vokste til å være vert for hundrevis av modeller som også krevde GPU-ressurser, så vi en mulighet til å skape en mer kostnadseffektiv, pålitelig og håndterbar arkitektur gjennom SageMaker MME-er. Før vi migrerte til SageMaker MMEer, ble modellene våre distribuert på Kubernetes på Amazon Elastic Kubernetes-tjeneste (Amazon EKS). Selv om Amazon EKS ga administrasjonsfunksjoner, var det umiddelbart tydelig at vi administrerte infrastruktur som ikke var spesielt skreddersydd for slutninger. Forethought måtte administrere modellslutninger på Amazon EKS selv, noe som var en belastning for ingeniøreffektiviteten. For eksempel, for å dele dyre GPU-ressurser mellom flere modeller, var vi ansvarlige for å allokere stive minnefraksjoner til modeller som ble spesifisert under distribusjon. Vi ønsket å løse følgende hovedproblemer med vår eksisterende infrastruktur:
- Høy kostnad – For å sikre at hver modell hadde nok ressurser, ville vi være veldig konservative med hensyn til hvor mange modeller som skal passe per instans. Dette resulterte i mye høyere kostnader for modellhosting enn nødvendig.
- Lav pålitelighet – Til tross for at de er konservative i minneallokeringen vår, har ikke alle modellene de samme kravene, og noen ganger vil noen modeller kaste ut av minnet (OOM) feil.
- Ineffektiv ledelse – Vi måtte administrere ulike distribusjonsmanifester for hver type modell (som klassifiserere, innebygginger og autofullføring), noe som var tidkrevende og utsatt for feil. Vi måtte også opprettholde logikken for å bestemme minneallokeringen for ulike modelltyper.
Til syvende og sist trengte vi en slutningsplattform for å ta på seg det tunge løftet med å administrere modellene våre under kjøretid for å forbedre kostnadene, påliteligheten og administrasjonen av å betjene modellene våre. SageMaker MMEs tillot oss å møte disse behovene.
Gjennom sin smarte og dynamiske modelllasting og lossing, og dens skaleringsmuligheter, ga SageMaker MMEs en betydelig rimeligere og mer pålitelig løsning for å være vert for modellene våre. Vi er nå i stand til å passe mange flere modeller per instans og trenger ikke å bekymre oss for OOM-feil fordi SageMaker MME-er håndterer lasting og lossing av modeller dynamisk. I tillegg er distribusjoner nå så enkelt som å kalle opp Boto3 SageMaker APIer og legge ved de riktige retningslinjene for automatisk skalering.
Følgende diagram illustrerer vår gamle arkitektur.
For å starte migreringen til SageMaker MMEer, identifiserte vi de beste brukstilfellene for MMEer og hvilke av modellene våre som ville ha størst nytte av denne endringen. MME-er brukes best til følgende:
- Modeller som forventes å ha lav ventetid, men som tåler en kald starttid (når den først lastes inn)
- Modeller som kalles ofte og konsekvent
- Modeller som trenger delvise GPU-ressurser
- Modeller som deler felles krav og slutningslogikk
Vi identifiserte våre innebyggingsmodeller og autofullføringsspråkmodeller som de beste kandidatene for migreringen vår. For å organisere disse modellene under MME-er, ville vi opprette en MME per modelltype eller oppgave, en for våre innebyggingsmodeller og en annen for autofullføringsspråkmodeller.
Vi hadde allerede et API-lag på toppen av modellene våre for modellstyring og inferens. Vår oppgave var å omarbeide hvordan denne API-en ble distribuert og håndtere inferens på modeller under panseret med SageMaker, med minimale endringer i hvordan klienter og produktteam samhandlet med API. Vi trengte også å pakke våre modeller og tilpassede inferenslogikk for å være kompatible med NVIDIA Triton Inference Server ved å bruke SageMaker MME-er.
Følgende diagram illustrerer vår nye arkitektur.
Egendefinert slutningslogikk
Før migrering til SageMaker, kjørte Forethoughts egendefinerte slutningskode (forbehandling og etterbehandling) i API-laget når en modell ble påkalt. Målet var å overføre denne funksjonaliteten til selve modellen for å tydeliggjøre separasjonen av ansvar, modularisere og forenkle koden deres, og redusere belastningen på API.
Innebygging
Forethoughts innebyggingsmodeller består av to PyTorch-modellartefakter, og slutningsforespørselen bestemmer hvilken modell som skal kalles. Hver modell krever forhåndsbehandlet tekst som input. Hovedutfordringene var å integrere et forbehandlingstrinn og imøtekomme to modellartefakter per modelldefinisjon. For å møte behovet for flere trinn i slutningslogikken, utviklet Forethought en Triton-ensemblemodell med to trinn: en Python-forbehandlingsprosess for backend og et PyTorch-backend-modellkall. Ensemblemodeller gjør det mulig å definere og bestille trinn i inferenslogikken, med hvert trinn representert av en Triton-modell av hvilken som helst backend-type. For å sikre kompatibilitet med Triton PyTorch-backend, ble de eksisterende modellartefaktene konvertert til TorchScript-format. Separate Triton-modeller ble opprettet for hver modelldefinisjon, og Forethoughts API-lag var ansvarlig for å bestemme passende TargetModel
å påkalle basert på den innkommende forespørselen.
Autofullfør
Autofullføringsmodellene (sekvens til sekvens) presenterte et distinkt sett med krav. Spesifikt trengte vi å aktivere muligheten til å gå gjennom flere modellanrop og hurtigbufre betydelige innganger for hver samtale, alt mens vi opprettholder lav ventetid. I tillegg nødvendiggjorde disse modellene både forbehandlings- og etterbehandlingstrinn. For å møte disse kravene og oppnå ønsket fleksibilitet, utviklet Forethought autofullfør MME-modeller ved å bruke Triton Python-backend, som gir fordelen med å skrive modellen som Python-kode.
Benchmarking
Etter at Triton-modellformene ble bestemt, distribuerte vi modeller for å iscenesette endepunkter og gjennomførte ressurs- og ytelsesbenchmarking. Hovedmålet vårt var å bestemme ventetiden for kaldstart vs in-memory-modeller, og hvordan ventetiden ble påvirket av forespørselsstørrelse og samtidighet. Vi ønsket også å vite hvor mange modeller som kunne passe på hver forekomst, hvor mange modeller som ville føre til at forekomstene skaleres opp med vår automatiske skaleringspolicy, og hvor raskt oppskaleringen vil skje. I tråd med forekomsttypene vi allerede brukte, gjorde vi vår benchmarking med ml.g4dn.xlarge og ml.g4dn.2xlarge forekomster.
Resultater
Tabellen nedenfor oppsummerer resultatene våre.
Be om størrelse | Kaldstartsforsinkelse | Bufret slutningsforsinkelse | Samtidig ventetid (5 forespørsler) |
Liten (30 tokens) | 12.7 sekunder | 0.03 sekunder | 0.12 sekunder |
Medium (250 tokens) | 12.7 sekunder | 0.05 sekunder | 0.12 sekunder |
Stor (550 tokens) | 12.7 sekunder | 0.13 sekunder | 0.12 sekunder |
Merkbart at latensen for kaldstartforespørsler er betydelig høyere enn latensen for bufrede slutningsforespørsler. Dette er fordi modellen må lastes fra disk eller Amazon enkel lagringstjeneste (Amazon S3) når en kaldstartforespørsel er gjort. Latenstiden for samtidige forespørsler er også høyere enn latensen for enkeltforespørsler. Dette er fordi modellen må deles mellom samtidige forespørsler, noe som kan føre til krangel.
Tabellen nedenfor sammenligner ventetiden til de eldre modellene og SageMaker-modellene.
Be om størrelse | Eldre modeller | SageMaker-modeller |
Liten (30 tokens) | 0.74 sekunder | 0.24 sekunder |
Medium (250 tokens) | 0.74 sekunder | 0.24 sekunder |
Stor (550 tokens) | 0.80 sekunder | 0.32 sekunder |
Samlet sett er SageMaker-modellene et bedre valg for å være vert for autofullføringsmodeller enn de eldre modellene. De tilbyr lavere ventetid, skalerbarhet, pålitelighet og sikkerhet.
Ressursbruk
I vår søken etter å finne det optimale antallet modeller som kunne passe på hver forekomst, gjennomførte vi en serie tester. Eksperimentet vårt innebar å laste modeller inn i endepunktene våre ved å bruke en ml.g4dn.xlarge-forekomsttype, uten noen retningslinjer for automatisk skalering.
Disse spesielle forekomstene tilbyr 15.5 GB minne, og vi hadde som mål å oppnå omtrent 80 % GPU-minnebruk per forekomst. Med tanke på størrelsen på hver kodermodellartefakt, klarte vi å finne det optimale antallet Triton-kodere å laste på en forekomst for å nå vår målrettede GPU-minnebruk. Gitt at hver av våre innbyggingsmodeller tilsvarer to Triton-kodermodeller, var vi i stand til å huse et bestemt antall innbyggingsmodeller per forekomst. Som et resultat beregnet vi det totale antallet forekomster som kreves for å betjene alle våre innbyggingsmodeller. Denne eksperimenteringen har vært avgjørende for å optimalisere ressursbruken vår og forbedre effektiviteten til modellene våre.
Vi utførte lignende benchmarking for våre autofullføringsmodeller. Disse modellene var på rundt 292.0 MB hver. Da vi testet hvor mange modeller som ville passe på en enkelt ml.g4dn.xlarge-forekomst, la vi merke til at vi bare var i stand til å passe fire modeller før forekomsten vår begynte å losse modeller, til tross for at modellene hadde en liten størrelse. Våre viktigste bekymringer var:
- Årsak til økt CPU-minneutnyttelse
- Årsak til at modeller ble losset når vi prøvde å laste inn en modell til i stedet for bare den minst nylig brukte (LRU) modellen
Vi var i stand til å finne årsaken til minneutnyttelsen som kom fra initialiseringen av CUDA-runtime-miljøet vårt i Python-modellen, som var nødvendig for å flytte modellene og dataene våre på og av GPU-enheten. CUDA laster mange eksterne avhengigheter inn i CPU-minnet når kjøretiden initialiseres. Fordi Triton PyTorch-backend håndterer og abstraherer flytting av data på og av GPU-enheten, har vi ikke støtt på dette problemet for våre innebygde modeller. For å løse dette prøvde vi å bruke ml.g4dn.2xlarge-forekomster, som hadde samme mengde GPU-minne, men dobbelt så mye CPU-minne. I tillegg la vi til flere mindre optimaliseringer i Python-backend-koden vår, inkludert sletting av tensorer etter bruk, tømming av hurtigbufferen, deaktivering av gradienter og søppelinnsamling. Med den større instanstypen fikk vi plass til 10 modeller per instans, og CPU- og GPU-minneutnyttelsen ble mye mer på linje.
Følgende diagram illustrerer denne arkitekturen.
Automatisk skalering
Vi har knyttet retningslinjer for automatisk skalering til både innebyggings- og autofullførings-MME-ene våre. Vår policy for innbyggingsendepunktet vårt målrettet 80 % gjennomsnittlig GPU-minneutnyttelse ved bruk av tilpassede beregninger. Våre autofullføringsmodeller så et mønster med høy trafikk i arbeidstiden og minimal trafikk over natten. På grunn av dette opprettet vi en policy for automatisk skalering basert på InvocationsPerInstance
slik at vi kunne skalere i henhold til trafikkmønstrene og spare kostnader uten å ofre påliteligheten. Basert på vår benchmarking for ressursbruk, konfigurerte vi skaleringspolicyene våre med et mål på 225 InvocationsPerInstance
.
Distribuer logikk og pipeline
Å lage en MME på SageMaker er enkelt og ligner på å lage et hvilket som helst annet endepunkt på SageMaker. Etter at endepunktet er opprettet, er det like enkelt å legge til flere modeller til endepunktet som å flytte modellartefakten til S3-banen som endepunktet er målrettet mot; på dette tidspunktet kan vi komme med slutningsforespørsler til vår nye modell.
Vi definerte logikk som ville ta inn modellmetadata, formatere endepunktet deterministisk basert på metadataene og sjekke om endepunktet eksisterte. Hvis den ikke gjorde det, oppretter vi endepunktet og legger til Triton-modellartefakten til S3-patchen for endepunktet (også deterministisk formatert). For eksempel, hvis modellens metadata indikerte at det er en autofullføringsmodell, vil den opprette et endepunkt for autofullføringsmodeller og en tilknyttet S3-bane for autofullføringsmodellartefakter. Hvis endepunktet eksisterte, ville vi kopiere modellartefakten til S3-banen.
Nå som vi hadde modellformene våre for MME-modellene våre og funksjonaliteten for å distribuere modellene våre til MME, trengte vi en måte å automatisere distribusjonen på. Våre brukere må spesifisere hvilken modell de ønsker å distribuere; vi håndterer pakking og distribusjon av modellen. Den tilpassede slutningskoden som er pakket med modellen er versjonert og sendt til Amazon S3; i pakketrinnet trekker vi slutningskoden i henhold til den angitte versjonen (eller den nyeste versjonen) og bruker YAML-filer som indikerer filstrukturene til Triton-modellene.
Et krav til oss var at alle MME-modellene våre ble lastet inn i minnet for å unngå kaldstartforsinkelse under produksjonsslutningsforespørsler om å laste inn modeller. For å oppnå dette, sørger vi for nok ressurser til å passe alle modellene våre (i henhold til den foregående benchmarkingen) og ringer hver modell i vår MME på en timelig takt.
Følgende diagram illustrerer modelldistribusjonsrørledningen.
Følgende diagram illustrerer modellens oppvarmingsrørledning.
Modellanrop
Vårt eksisterende API-lag gir en abstraksjon for innringere å gjøre slutninger om alle våre ML-modeller. Dette betydde at vi bare måtte legge til funksjonalitet til API-laget for å kalle SageMaker MME med riktig målmodell avhengig av slutningsforespørselen, uten endringer i kallekoden. SageMaker-inferenskoden tar slutningsforespørselen, formaterer Triton-inngangene som er definert i våre Triton-modeller, og påkaller MME-ene ved å bruke Boto3.
Kostnadsfordeler
Forthought gjorde betydelige fremskritt med å redusere kostnadene for modellvertstjenester og redusere OOM-feil i modellen, takket være migreringen til SageMaker MME-er. Før denne endringen kjører ml.g4dn.xlarge-forekomster i Amazon EKS. Med overgangen til MME-er oppdaget vi at den kunne huse 12 innebyggingsmodeller per forekomst, samtidig som vi oppnådde 80 % GPU-minneutnyttelse. Dette førte til en betydelig nedgang i våre månedlige utgifter. For å sette det i perspektiv, realiserte vi en kostnadsbesparelse på opptil 80 %. Dessuten, for å administrere høyere trafikk, vurderte vi å skalere opp replikaene. Hvis vi antar et scenario der vi bruker tre kopier, fant vi ut at kostnadsbesparelsene våre fortsatt ville være betydelige selv under disse forholdene, og ligge rundt 43 %.
Reisen med SageMaker MMEs har vist seg økonomisk fordelaktig, og reduserer utgiftene våre samtidig som vi sikrer optimal modellytelse. Tidligere ble språkmodellene våre for autofullføring distribuert i Amazon EKS, noe som nødvendiggjorde et varierende antall ml.g4dn.xlarge-forekomster basert på minnetildelingen per modell. Dette resulterte i en betydelig månedlig kostnad. Med vår nylige migrering til SageMaker MME-er har vi imidlertid vært i stand til å redusere disse kostnadene betydelig. Vi er nå vert for alle modellene våre på ml.g4dn.2xlarge-forekomster, noe som gir oss muligheten til å pakke modeller mer effektivt. Dette har redusert våre månedlige utgifter betydelig, og vi har nå realisert kostnadsbesparelser i området 66–74 %. Dette trekket har vist hvordan effektiv ressursutnyttelse kan føre til betydelige økonomiske besparelser ved å bruke SageMaker MME.
konklusjonen
I dette innlegget gjennomgikk vi hvordan Forethought bruker SageMaker multi-modell endepunkter for å redusere kostnadene for sanntidsslutning. SageMaker tar på seg de udifferensierte tunge løftene, så Forethought kan øke ingeniøreffektiviteten. Den lar også Forethought redusere kostnadene for sanntidsslutninger dramatisk, samtidig som ytelsen som er nødvendig for de forretningskritiske operasjonene opprettholdes. Ved å gjøre det, er Forethought i stand til å gi et differensiert tilbud til sine kunder ved å bruke hyper-personlige modeller. Bruk SageMaker MME til å være vert for modellene dine i stor skala og redusere hostingkostnadene ved å forbedre endepunktutnyttelsen. Det reduserer også distribusjonskostnader fordi Amazon SageMaker administrerer lasting av modeller i minnet og skalerer dem basert på trafikkmønstrene til endepunktet ditt. Du kan finne kodeeksempler på hosting av flere modeller ved å bruke SageMaker MME på GitHub.
Om forfatterne
Jad Chamoun er direktør for Core Engineering hos Forethought. Teamet hans fokuserer på plattformteknikk som dekker Data Engineering, Machine Learning Infrastructure og Cloud Infrastructure. Du kan finne ham på Linkedin.
Salina Wu er Sr. Machine Learning Infrastructure-ingeniør ved Forethought.ai. Hun jobber tett med maskinlæringsteamet for å bygge og vedlikeholde deres ende-til-ende opplæring, servering og datainfrastruktur. Hun er spesielt motivert av å introdusere nye måter å forbedre effektiviteten og redusere kostnadene på tvers av ML-området. Når han ikke er på jobb, liker Salina surfing, keramikk og å være i naturen.
James Park er løsningsarkitekt hos Amazon Web Services. Han jobber med Amazon.com for å designe, bygge og distribuere teknologiløsninger på AWS, og har en spesiell interesse for AI og maskinlæring. På fritiden liker han å oppsøke nye kulturer, nye opplevelser og holde seg oppdatert med de nyeste teknologitrendene. Du finner ham på Linkedin.
Sunil Padmanabhan er en Startup Solutions Architect hos AWS. Som tidligere oppstartsgründer og CTO brenner han for maskinlæring og fokuserer på å hjelpe startups å utnytte AI/ML for sine forretningsresultater og designe og distribuere ML/AI-løsninger i stor skala.
Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring inkludert NLP- og Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- EVM Finans. Unified Interface for desentralisert økonomi. Tilgang her.
- Quantum Media Group. IR/PR forsterket. Tilgang her.
- PlatoAiStream. Web3 Data Intelligence. Kunnskap forsterket. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- evne
- I stand
- Om oss
- abstraksjon
- sammendrag
- akselerert
- Ifølge
- nøyaktighet
- nøyaktig
- nøyaktig
- Oppnå
- oppnådd
- oppnå
- tvers
- legge til
- la til
- legge
- tillegg
- Ytterligere
- I tillegg
- adresse
- adressering
- avansert
- Fordel
- Etter
- Agent
- agenter
- AI
- ai brukstilfeller
- AI / ML
- sikte
- justere
- justert
- Alle
- allokering
- tillate
- tillater
- allerede
- også
- Selv
- Amazon
- Amazon SageMaker
- Amazon Web Services
- Amazon.com
- beløp
- an
- og
- Årlig
- En annen
- svar
- noen
- api
- APIer
- tilsynelatende
- hensiktsmessig
- ca
- arkitektur
- ER
- rundt
- artikler
- kunstig
- kunstig intelligens
- AS
- bistår
- assosiert
- At
- auto
- automatisere
- Automatisert
- automatisk
- gjennomsnittlig
- unngå
- borte
- AWS
- Backend
- Balansere
- basen
- basert
- BE
- ble
- fordi
- bli
- vært
- før du
- begynne
- være
- referansemåling
- gunstig
- nytte
- BEST
- Bedre
- mellom
- øke
- både
- bringe
- bygge
- innebygd
- byrde
- virksomhet
- men
- by
- Cache
- beregnet
- ring
- som heter
- ringer
- Samtaler
- CAN
- kandidater
- evner
- saken
- saker
- henvender seg
- Årsak
- utfordre
- utfordringer
- endring
- Endringer
- sjekk
- valg
- valgte
- klienter
- tett
- Cloud
- sky infrastruktur
- kode
- forkjølelse
- Samle
- COM
- kommer
- Felles
- Selskapets
- sammenlignet
- kompatibilitet
- kompatibel
- datamaskin
- Datamaskin syn
- databehandling
- bekymringer
- samtidig
- forhold
- gjennomført
- konfigurert
- konservativ
- betydelig
- ansett
- vurderer
- Container
- innhold
- konvertert
- Kjerne
- korrigere
- tilsvarer
- Kostnad
- kostnadsbesparelser
- kostnadseffektiv
- kostbar
- Kostnader
- kunne
- dekker
- skape
- opprettet
- Opprette
- avgjørende
- CTO
- skikk
- kunde
- kunde Data
- Kundetilfredshet
- Kundeservice
- Kundeservice
- Kunder
- tilpasset
- dato
- Dato
- Avslå
- redusere
- dyp
- dyp læring
- definert
- definere
- leverer
- levere
- demonstrert
- avhengig
- utplassere
- utplassert
- utplasserings
- distribusjon
- distribusjoner
- utforming
- ønsket
- Til tross for
- Bestem
- bestemmes
- bestemmes
- bestemme
- utviklet
- utviklere
- enhet
- gJORDE
- forskjellig
- differensiert
- Regissør
- oppdaget
- distinkt
- distribueres
- distribuert databehandling
- gjør
- domene
- domener
- ikke
- dramatisk
- under
- dynamisk
- dynamisk
- hver enkelt
- effektivitet
- effektiv
- effektivt
- embedding
- muliggjøre
- muliggjør
- ende til ende
- Endpoint
- engasjerende
- ingeniør
- Ingeniørarbeid
- forbedre
- styrke
- nok
- sikre
- sikrer
- bedrifter
- Miljø
- feil
- Selv
- Hver
- eksempel
- eksisterende
- forventet
- utgifter
- dyrt
- erfaring
- Erfaringer
- eksperiment
- utvendig
- raskere
- filet
- Filer
- fyll
- finansiell
- økonomisk
- Finn
- Først
- passer
- FLÅTE
- fleksibilitet
- fokuserer
- etter
- Til
- format
- Tidligere
- funnet
- Grunnleggeren
- fire
- fra
- fullt
- funksjonalitet
- videre
- Dess
- hull
- generere
- generert
- generative
- Generativ AI
- få
- gif
- gitt
- Giving
- mål
- GPU
- GPU
- gradienter
- HAD
- hånd
- håndtere
- Håndterer
- Håndtering
- skje
- maskinvare
- Ha
- å ha
- he
- tung
- tung løfting
- hjelpe
- hjelpe
- hjelper
- Høy
- høy ytelse
- høyere
- ham
- hans
- panser
- vert
- Hosting
- hosting kostnader
- TIMER
- hus
- Hvordan
- Men
- HTML
- http
- HTTPS
- Hundrevis
- identifisert
- if
- illustrerer
- umiddelbart
- forbedre
- bedre
- in
- Inc.
- Inkludert
- Innkommende
- Øke
- indikerer
- indikert
- informasjon
- Infrastruktur
- infrastruktur
- innovative
- inngang
- innganger
- f.eks
- i stedet
- Integrering
- integrering
- Intelligens
- interaksjon
- interaksjoner
- interesse
- inn
- innføre
- påkalt
- påkaller
- involvert
- utstedelse
- IT
- DET ER
- selv
- reise
- jpg
- bare
- holde
- nøkkel
- Vet
- kunnskap
- Språk
- stor
- Store bedrifter
- større
- Ventetid
- siste
- lag
- føre
- ledende
- læring
- minst
- Led
- Legacy
- mindre
- Leverage
- utnytter
- løfte
- laste
- lasting
- laster
- logikk
- Lav
- lavere
- maskin
- maskinlæring
- laget
- Hoved
- vedlikeholde
- Vedlike
- gjøre
- administrer
- fikk til
- ledelse
- forvalter
- administrerende
- mange
- marked
- maksimere
- ment
- Minne
- metadata
- Metrics
- Migrere
- migrasjon
- millioner
- minimal
- mindre
- formildende
- ML
- modell
- modeller
- Overvåke
- månedlig
- mer
- Videre
- mest
- motivert
- flytte
- flytting
- mye
- Multi-Model endepunkt
- flere
- må
- innfødt
- Natur
- nødvendig
- Trenger
- nødvendig
- behov
- Ny
- nlp
- nå
- Antall
- Nvidia
- Målet
- of
- off
- tilby
- tilby
- Tilbud
- ofte
- on
- gang
- ONE
- bare
- Drift
- Opportunity
- optimal
- optimalisere
- or
- rekkefølge
- organisasjoner
- Annen
- vår
- oss selv
- ut
- utfall
- enn
- over natten
- Pakk med deg
- pakke
- pakket
- emballasje
- Spesielt
- spesielt
- lidenskapelig
- patch
- banen
- Mønster
- mønstre
- ytelse
- perspektiv
- rørledning
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- Point
- Politikk
- politikk
- Post
- makt
- powered
- presentert
- forrige
- tidligere
- primære
- Principal
- Før
- problemer
- prosess
- prosessering
- Produkt
- Produksjon
- produktivitet
- ordentlig
- utprøvd
- gi
- forutsatt
- gir
- forsyning
- presset
- sette
- Python
- pytorch
- kvalitet
- spørsmål
- søken
- raskt
- område
- spenner
- Ranking
- å nå
- sanntids
- realisert
- nylig
- nylig
- redusere
- reduserer
- redusere
- i slekt
- relevans
- relevant
- pålitelighet
- pålitelig
- forblir
- representert
- anmode
- forespørsler
- påkrevd
- behov
- Krav
- Krever
- ressurs
- Ressurser
- svar
- ansvar
- ansvarlig
- resultere
- resulterende
- Resultater
- anmeldt
- ikke sant
- rigid
- root
- Kjør
- rennende
- ofre
- sagemaker
- SageMaker Inference
- samme
- tilfredshet
- Spar
- besparende
- Besparelser
- så
- skalerbarhet
- skalerbar
- Skala
- skalere opp
- vekter
- skalering
- scenario
- scenarier
- forskere
- Søk
- sikkerhet
- søker
- senior
- separat
- Sequence
- Serien
- betjene
- tjeneste
- Tjenester
- servering
- sett
- flere
- Shadow
- figurer
- Del
- delt
- hun
- signifikant
- betydelig
- lignende
- Enkelt
- forenkle
- enkelt
- Størrelse
- liten
- Smart
- So
- løsning
- Solutions
- LØSE
- noen
- Rom
- spesifikk
- spesielt
- spesifisert
- spike
- iscenesettelse
- Begynn
- startet
- oppstart
- startups
- state-of-the-art
- Trinn
- Steps
- Still
- lagring
- rett fram
- fremskritt
- betydelig
- slik
- suite
- støtte
- Systemer
- bord
- takle
- skreddersydd
- Ta
- tar
- Target
- målrettet
- mål
- Oppgave
- lag
- lag
- Technologies
- Teknologi
- testet
- tester
- enn
- Takk
- Det
- De
- deres
- Dem
- Disse
- de
- denne
- tre
- Gjennom
- billetter
- tid
- tidkrevende
- til
- tokens
- topp
- Totalt
- trafikk
- Tog
- trent
- Kurs
- overføre
- Transform
- overgang
- Trender
- prøvd
- Triton
- To ganger
- to
- typen
- typer
- etter
- unik
- us
- bruk
- bruke
- bruk sak
- brukt
- Brukere
- bruker
- ved hjelp av
- utnytte
- versjon
- veldig
- syn
- vs
- ønsker
- ønsket
- var
- Vei..
- måter
- we
- web
- webtjenester
- var
- når
- om
- hvilken
- mens
- med
- uten
- Arbeid
- arbeidet
- virker
- bekymring
- ville
- skriving
- wu
- yaml
- Du
- Din
- zephyrnet