Bedrifter søker å raskt frigjøre potensialet til generativ kunstig intelligens ved å gi tilgang til grunnmodeller (FM-er) til ulike bransjer (LOB-er). IT-team er ansvarlige for å hjelpe LOB med å innovere med hastighet og smidighet, samtidig som de gir sentralisert styring og observerbarhet. For eksempel kan de trenge å spore bruken av FM-er på tvers av team, tilbakeføringskostnader og gi synlighet til det relevante kostnadssenteret i LOB. I tillegg kan det hende de må regulere tilgangen til forskjellige modeller per team. For eksempel hvis bare spesifikke FM-er kan godkjennes for bruk.
Amazonas grunnfjell er en fullstendig administrert tjeneste som tilbyr et utvalg av høyytende grunnmodeller fra ledende AI-selskaper som AI21 Labs, Anthropic, Cohere, Meta, Stability AI og Amazon via et enkelt API, sammen med et bredt sett med muligheter for å bygge generativ AI applikasjoner med sikkerhet, personvern og ansvarlig AI. Fordi Amazon Bedrock er serverløs, trenger du ikke å administrere noen infrastruktur, og du kan trygt integrere og distribuere generative AI-funksjoner i applikasjonene dine ved å bruke AWS-tjenestene du allerede er kjent med.
Et programvare som en tjeneste (SaaS)-lag for grunnmodeller kan gi et enkelt og konsistent grensesnitt for sluttbrukere, samtidig som det opprettholdes sentralisert styring av tilgang og forbruk. API-porter kan gi løs kobling mellom modellforbrukere og modellendepunkttjenesten, og fleksibilitet til å tilpasse seg skiftende modell, arkitekturer og påkallingsmetoder.
I dette innlegget viser vi deg hvordan du bygger et internt SaaS-lag for å få tilgang til fundamentmodeller med Amazon Bedrock i en multi-tenant (team) arkitektur. Vi fokuserer spesielt på bruks- og kostnadssporing per leietaker og også kontroller som bruksregulering per leietaker. Vi beskriver hvordan løsningen og Amazons grunnfjellsforbruksplaner kartlegger det generelle SaaS reiserammeverket. Koden for løsningen og en AWS skyutviklingssett (AWS CDK) mal er tilgjengelig i GitHub repository.
Utfordringer
En AI-plattformadministrator må gi standardisert og enkel tilgang til FM-er til flere utviklingsteam.
Følgende er noen av utfordringene for å gi styrt tilgang til fundamentmodeller:
- Kostnads- og brukssporing – Spor og revider individuelle leietakers kostnader og bruk av fundamentmodeller, og gi tilbakeføringskostnader til spesifikke kostnadssteder
- Budsjett- og brukskontroller – Administrer API-kvoter, budsjett og bruksgrenser for tillatt bruk av fundamentmodeller over en definert frekvens per leietaker
- Adgangskontroll og modellstyring – Definer tilgangskontroller for spesifikke tillat oppførte modeller per leietaker
- Multi-tenant standardisert API – Gi konsekvent tilgang til fundamentmodeller med Åpne API standarder
- Sentralisert styring av API – Gi et enkelt lag for å administrere API-nøkler for tilgang til modeller
- Modellversjoner og oppdateringer – Håndtere utrullinger av nye og oppdaterte modellversjoner
Løsningsoversikt
I denne løsningen viser vi til en Multi leietaker nærme seg. EN leietaker her kan variere fra en individuell bruker, et spesifikt prosjekt, team eller til og med en hel avdeling. Når vi diskuterer tilnærmingen, bruker vi begrepet lag, fordi det er det vanligste. Vi bruker API-nøkler for å begrense og overvåke API-tilgang for team. Hvert lag er tildelt en API-nøkkel for tilgang til FM-ene. Det kan være forskjellige brukerautentiserings- og autorisasjonsmekanismer utplassert i en organisasjon. For enkelhets skyld inkluderer vi ikke disse i denne løsningen. Du kan også integrere eksisterende identitetsleverandører med denne løsningen.
Følgende diagram oppsummerer løsningsarkitekturen og nøkkelkomponentene. Lag (leietakere) tildelt separate kostnadssteder bruker Amazon Bedrock FM-er via en API-tjeneste. For å spore forbruk og kostnad per team, logger løsningen data for hver enkelt påkalling, inkludert modellen som påkalles, antall tokens for tekstgenereringsmodeller og bildedimensjoner for multimodale modeller. I tillegg samler den påkallelsene per modell og kostnader for hvert team.
Du kan distribuere løsningen på din egen konto ved å bruke AWS CDK. AWS CDK er et rammeverk for programvareutvikling med åpen kildekode for å modellere og levere skyapplikasjonsressursene dine ved å bruke kjente programmeringsspråk. AWS CDK-koden er tilgjengelig i GitHub repository.
I de følgende avsnittene diskuterer vi nøkkelkomponentene i løsningen mer detaljert.
Fanger bruk av grunnlagsmodell per team
Arbeidsflyten for å fange opp FM-bruk per team består av følgende trinn (som nummerert i det foregående diagrammet):
- Et teams søknad sender en POST-forespørsel til Amazon API-gateway med modellen som skal påberopes i
model_id
spørringsparameter og brukerledeteksten i forespørselsteksten. - API-gateway ruter forespørselen til en AWS Lambda funksjon (
bedrock_invoke_model
) som er ansvarlig for å logge inn informasjon om teambruk Amazon CloudWatch og påkaller Amazons grunnfjell-modell. - Amazon Bedrock gir et VPC-endepunkt drevet av AWS PrivateLink. I denne løsningen sender Lambda-funksjonen forespørselen til Amazon Bedrock ved hjelp av PrivateLink for å etablere en privat forbindelse mellom VPC-en på kontoen din og Amazon Bedrock-tjenestekontoen. For å lære mer om PrivateLink, se Bruk AWS PrivateLink til å sette opp privat tilgang til Amazon Bedrock.
- Etter påkallelsen av Amazonas grunnfjell, Amazon CloudTrail genererer en CloudTrail-arrangement.
- Hvis Amazon Bedrock-anropet er vellykket, logger Lambda-funksjonen følgende informasjon avhengig av typen påkalt modell og returnerer det genererte svaret til applikasjonen:
- team_id – Den unike identifikatoren for teamet som utsteder forespørselen.
- requestId – Den unike identifikatoren til forespørselen.
- modell_id – ID-en til modellen som skal påberopes.
- inputTokens – Antall tokens sendt til modellen som en del av ledeteksten (for tekstgenerering og innebyggingsmodeller).
- outputTokens – Maksimalt antall tokens som skal genereres av modellen (for tekstgenereringsmodeller).
- høyde – Høyden på det forespurte bildet (for multimodale modeller og multimodale innbyggingsmodeller).
- bredde – Bredden på det forespurte bildet (kun for multimodale modeller).
- trinn – Trinnene som kreves (for Stability AI-modeller).
Sporingskostnader per lag
En annen flyt samler bruksinformasjonen, og beregner og sparer deretter on-demand-kostnadene per team på daglig basis. Ved å ha en separat flyt sikrer vi at kostnadssporing ikke påvirker ventetiden og gjennomstrømningen til modellpåkallingsflyten. Arbeidsflyttrinnene er som følger:
- An Amazon EventBridge regel utløser en Lambda-funksjon (
bedrock_cost_tracking
) daglig. - Lambda-funksjonen henter bruksinformasjonen fra CloudWatch for dagen før, beregner de tilknyttede kostnadene og lagrer dataene samlet av
team_id
ogmodel_id
in Amazon enkel lagringstjeneste (Amazon S3) i CSV-format.
For å spørre og visualisere dataene som er lagret i Amazon S3, har du forskjellige alternativer, inkludert S3 Velgog Amazon Athena og Amazon QuickSight.
Kontrollere bruk per lag
En bruksplan spesifiserer hvem som kan få tilgang til én eller flere distribuerte API-er og angir eventuelt målfrekvensen for forespørsler for å starte struping av forespørsler. Planen bruker API-nøkler for å identifisere API-klienter som kan få tilgang til den tilknyttede API-en for hver nøkkel. Du kan bruke API Gateway bruksplaner for å strupe forespørsler som overskrider forhåndsdefinerte terskler. Du kan også bruke API-nøkler og kvotegrenser, som lar deg angi maksimalt antall forespørsler per API-nøkkel som hvert team har lov til å utstede innen et spesifisert tidsintervall. Dette kommer i tillegg til Amazon Bedrock-tjenestekvoter som kun tildeles på kontonivå.
Forutsetninger
Før du distribuerer løsningen, sørg for at du har følgende:
Distribuer AWS CDK-stakken
Følg instruksjonene i README filen til GitHub-depotet for å konfigurere og distribuere AWS CDK-stakken.
Stabelen distribuerer følgende ressurser:
- Privat nettverksmiljø (VPC, private undernett, sikkerhetsgruppe)
- IAM-rolle for å kontrollere modelltilgang
- Lambdalag for de nødvendige Python-modulene
- Lambda funksjon
invoke_model
- Lambda funksjon
list_foundation_models
- Lambda funksjon
cost_tracking
- Rest API (API Gateway)
- API Gateway-bruksplan
- API-nøkkel knyttet til bruksplanen
Ombord på et nytt team
For å gi tilgang til nye team kan du enten dele den samme API-nøkkelen på tvers av forskjellige team og spore modellforbruket ved å gi en annen team_id
for API-påkallelsen, eller lag dedikerte API-nøkler som brukes for å få tilgang til Amazon Bedrock-ressurser ved å følge instruksjonene i README.
Stabelen distribuerer følgende ressurser:
- API Gateway-bruksplan knyttet til den tidligere opprettede REST APIen
- API-nøkkel knyttet til bruksplanen for det nye teamet, med reservert struping og burst-konfigurasjoner for API-en
For mer informasjon om API Gateway struping og burst-konfigurasjoner, se Throttle API-forespørsler for bedre gjennomstrømning.
Etter at du har distribuert stabelen, kan du se at den nye API-nøkkelen for team-2
opprettes også.
Konfigurer modelltilgangskontroll
Plattformadministratoren kan gi tilgang til spesifikke fundamentmodeller ved å redigere IAM-policyen knyttet til Lambda-funksjonen invoke_model
. De
IAM-tillatelser er definert i filen setup/stack_constructs/iam.py. Se følgende kode:
Påkall tjenesten
Etter at du har distribuert løsningen, kan du påkalle tjenesten direkte fra koden din. Følgende
er et eksempel i Python for å konsumere invoke_model
API for tekstgenerering gjennom en POST-forespørsel:
Utgang: Amazon Bedrock er en intern teknologiplattform utviklet av Amazon for å drive og drifte mange av deres tjenester og produkter. Noen viktige ting om Berggrunn ...
Følgende er et annet eksempel i Python for å konsumere invoke_model
API for generering av innebygging gjennom en POST-forespørsel:
model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model }
) text = response.json()[0]["embedding"]
Utgang: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125. . 0.8515625, 0.16308594 …
Tilgang nektet til fundamentmodeller
Følgende er et eksempel i Python for å konsumere invoke_model
API for tekstgenerering gjennom en POST-forespørsel med et svar nektet tilgang:
"Traceback (siste anrop sist):n File "/var/task/index.py", linje 213, i lambda_handlern response = _invoke_text(bedrock_client, model_id, body, model_kwargs)n File "/var/task/index.py ”, linje 146, i _invoke_textn raise en File ”/var/task/index.py”, linje 131, i _invoke_textn response = bedrock_client.invoke_model(n File ”/opt/python/botocore/client.py”, linje 535, i _api_calln returnerer self._make_api_call(operation_name, kwargs)n File ”/opt/python/botocore/client.py”, linje 980, i _make_api_calln raise error_class(parsed_response, operation_name)nbotocore.erroriedException.Access Det oppstod en feil (AccessDeniedException) ved oppkalling av InvokeModel-operasjonen: Kontoen din er ikke autorisert til å påkalle denne API-operasjonen.n"
Eksempel på kostnadsberegning
Ved påkalling av Amazon Bedrock-modeller med on-demand-prising, beregnes totalkostnaden som summen av input- og output-kostnadene. Input-kostnader er basert på antall input-tokens som sendes til modellen, og output-kostnader er basert på tokens som genereres. Prisene er per 1,000 input-tokens og per 1,000 output tokens. For flere detaljer og spesifikke modellpriser, se Priser for Amazons grunnfjell.
La oss se på et eksempel der to team, team1 og team2, får tilgang til Amazon Bedrock gjennom løsningen i dette innlegget. Bruks- og kostnadsdataene som er lagret i Amazon S3 på en enkelt dag, vises i tabellen nedenfor.
Kolonnene input_tokens
og output_tokens
lagre de totale input- og output-tokenene på tvers av modellanrop per modell og per team, henholdsvis for en gitt dag.
Kolonnene input_cost
og output_cost
lagre de respektive kostnadene per modell og per lag. Disse beregnes ved hjelp av følgende formler:
input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000
team_id | modell_id | input_tokens | output_tokens | besvergelser | input_cost | output_cost |
Team1 | amazon.titan-tg1-large | 24000 | 2473 | 1000 | 0.0072 | 0.00099 |
Team1 | anthropic.claude-v2 | 2448 | 4800 | 24 | 0.02698 | 0.15686 |
Team2 | amazon.titan-tg1-large | 35000 | 52500 | 350 | 0.0105 | 0.021 |
Team2 | ai21.j2-grande-instruct | 4590 | 9000 | 45 | 0.05738 | 0.1125 |
Team2 | anthropic.claude-v2 | 1080 | 4400 | 20 | 0.0119 | 0.14379 |
End-to-end-visning av et funksjonelt multi-tenant-serverløst SaaS-miljø
La oss forstå hvordan et ende-til-ende funksjonelt multi-tenant serverløst SaaS-miljø kan se ut. Følgende er et referansearkitekturdiagram.
Dette arkitekturdiagrammet er en utzoomet versjon av det forrige arkitekturdiagrammet som ble forklart tidligere i innlegget, hvor det forrige arkitekturdiagrammet forklarer detaljene til en av de nevnte mikrotjenestene (fundamental modelltjeneste). Dette diagrammet forklarer at, bortsett fra grunnleggende modelltjeneste, må du også ha andre komponenter i SaaS-plattformen for flere leietakere for å implementere en funksjonell og skalerbar plattform.
La oss gå gjennom detaljene i arkitekturen.
Søknader for leietakere
Leietakerapplikasjonene er frontendapplikasjonene som samhandler med miljøet. Her viser vi flere leietakere som har tilgang fra forskjellige lokale eller AWS-miljøer. Frontend-applikasjonene kan utvides til å inkludere en registreringsside der nye leietakere kan registrere seg selv og en administrasjonskonsoll for administratorer av SaaS-tjenestelaget. Hvis leietakerapplikasjonene krever at en tilpasset logikk implementeres som trenger interaksjon med SaaS-miljøet, kan de implementere spesifikasjonene til applikasjonsadapterens mikrotjeneste. Eksempelscenarier kan være å legge til tilpasset autorisasjonslogikk samtidig som man respekterer autorisasjonsspesifikasjonene til SaaS-miljøet.
Delte tjenester
Følgende er delte tjenester:
- Tjenester for leietaker og brukeradministrasjon –Disse tjenestene har ansvar for å registrere og administrere leietakerne. De gir den tverrgående funksjonaliteten som er atskilt fra applikasjonstjenester og delt på tvers av alle leietakerne.
- Grunnleggende modelltjeneste – Løsningsarkitekturdiagrammet som er forklart i begynnelsen av dette innlegget representerer denne mikrotjenesten, der interaksjonen fra API Gateway til Lambda-funksjoner skjer innenfor rammen av denne mikrotjenesten. Alle leietakere bruker denne mikrotjenesten til å påkalle grunnmodellene fra Anthropic, AI21, Cohere, Stability, Meta og Amazon, samt finjusterte modeller. Den fanger også opp informasjonen som trengs for brukssporing i CloudWatch-logger.
- Kostnadssporingstjeneste –Denne tjenesten sporer kostnadene og bruken for hver leietaker. Denne mikrotjenesten kjører etter en tidsplan for å spørre CloudWatch-loggene og sende ut den aggregerte brukssporingen og utledede kostnadene til datalagringen. Kostnadssporingstjenesten kan utvides for å bygge ytterligere rapporter og visualisering.
Applikasjonsadaptertjeneste
Denne tjenesten presenterer et sett med spesifikasjoner og APIer som en leietaker kan implementere for å integrere sin egendefinerte logikk til SaaS-miljøet. Basert på hvor mye tilpasset integrasjon som trengs, kan denne komponenten være valgfri for leietakere.
Datalager for flere leietakere
De delte tjenestene lagrer dataene sine i et datalager som kan være en enkelt delt Amazon DynamoDB tabell med en leietakerpartisjoneringsnøkkel som knytter DynamoDB-elementer til individuelle leietakere. Den delte tjenesten for kostnadssporing sender ut de aggregerte bruks- og kostnadssporingsdataene til Amazon S3. Basert på brukstilfellet kan det også være et applikasjonsspesifikt datalager.
Et SaaS-miljø med flere leietakere kan ha mange flere komponenter. For mer informasjon, se Bygge en SaaS-løsning for flere leietakere ved å bruke AWS-serverløse tjenester.
Støtte for flere distribusjonsmodeller
SaaS-rammeverk skisserer vanligvis to distribusjonsmodeller: basseng og silo. For bassengmodellen har alle leietakere tilgang til FM-er fra et delt miljø med felles lagrings- og datainfrastruktur. I silomodellen har hver leietaker sitt eget sett med dedikerte ressurser. Du kan lese om isolasjonsmodeller i Hvitbok om SaaS-leieisolasjonsstrategier.
Den foreslåtte løsningen kan brukes for begge SaaS-implementeringsmodellene. I bassengtilnærmingen er et sentralisert AWS-miljø vert for API-, lagrings- og dataressursene. I silomodus får hvert team tilgang til APIer, lagrings- og dataressurser i et dedikert AWS-miljø.
Løsningen passer også med de tilgjengelige forbruksplanene levert av Amazon Bedrock. AWS gir et valg mellom to forbruksplaner for slutning:
- På etterspørsel – Denne modusen lar deg bruke grunnmodeller på betal-som-du-go-basis uten å måtte inngå noen tidsbaserte forpliktelser
- Provisioned Throughput – Denne modusen lar deg sørge for tilstrekkelig gjennomstrømning for å møte applikasjonens ytelseskrav i bytte mot en tidsbasert forpliktelse
For mer informasjon om disse alternativene, se Priser for Amazons grunnfjell.
Den serverløse SaaS-referanseløsningen som er beskrevet i dette innlegget, kan bruke Amazons grunnfjells-forbruksplaner for å gi grunnleggende og førsteklasses nivåvalg til sluttbrukere. Basic kan inkludere On-Demand eller Provisioned Throughput-forbruk av Amazon Bedrock og kan inkludere spesifikke bruks- og budsjettgrenser. Leietakergrenser kan aktiveres ved å begrense forespørsler basert på forespørsler, tokenstørrelser eller budsjettallokering. Premium tier leietakere kan ha sine egne dedikerte ressurser med klargjort gjennomstrømningsforbruk av Amazon Bedrock. Disse leietakerne vil typisk være assosiert med produksjonsarbeidsbelastninger som krever høy gjennomstrømning og lav latenstilgang til Amazon Bedrock FM-er.
konklusjonen
I dette innlegget diskuterte vi hvordan man bygger en intern SaaS-plattform for å få tilgang til grunnmodeller med Amazon Bedrock i et multi-tenant-oppsett med fokus på sporing av kostnader og bruk, og strupegrenser for hver leietaker. Ytterligere emner å utforske inkluderer integrering av eksisterende autentiserings- og autorisasjonsløsninger i organisasjonen, forbedring av API-laget til å inkludere web-sockets for toveis klientserverinteraksjoner, legge til innholdsfiltrering og andre styringsrekkverk, designe flere distribusjonsnivåer, integrere andre mikrotjenester i SaaS arkitektur og mye mer.
Hele koden for denne løsningen er tilgjengelig i GitHub repository.
For mer informasjon om SaaS-baserte rammeverk, se SaaS Journey Framework: Bygge en ny SaaS-løsning på AWS.
Om forfatterne
Hasan Poonawala er senior AI/ML spesialistløsningsarkitekt hos AWS, og jobber med kunder innen helsevesen og biovitenskap. Hasan hjelper til med å designe, distribuere og skalere Generative AI og Machine learning-applikasjoner på AWS. Han har over 15 års kombinert arbeidserfaring innen maskinlæring, programvareutvikling og datavitenskap på skyen. På fritiden elsker Hasan å utforske naturen og tilbringe tid med venner og familie.
Anastasia Tzeveleka er senior AI/ML spesialistløsningsarkitekt hos AWS. Som en del av arbeidet hennes hjelper hun kunder over hele EMEA med å bygge grunnmodeller og lage skalerbare generative AI- og maskinlæringsløsninger ved hjelp av AWS-tjenester.
Bruingen Pistone er en generativ AI og ML spesialistløsningsarkitekt for AWS basert i Milano. Han jobber med store kunder og hjelper dem med å forstå deres tekniske behov dypt og utforme AI- og maskinlæringsløsninger som utnytter AWS Cloud og Amazon Machine Learning-stabel på best mulig måte. Hans ekspertise inkluderer: Machine Learning end to end, Machine Learning Industrialization og Generative AI. Han liker å tilbringe tid med vennene sine og utforske nye steder, i tillegg til å reise til nye destinasjoner.
Vikesh Pandey er en Generative AI/ML Solutions-arkitekt som spesialiserer seg på finansielle tjenester hvor han hjelper finanskunder med å bygge og skalere Generative AI/ML-plattformer og -løsninger som skaleres til hundrevis til til og med tusenvis av brukere. På fritiden liker Vikesh å skrive på ulike bloggfora og bygge lego sammen med ungen sin.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 000
- 1
- 120
- 15 år
- 15%
- 160
- 26%
- 500
- 7
- a
- Om oss
- adgang
- Tilgang
- Logg inn
- tvers
- tilpasse
- legge
- tillegg
- Ytterligere
- I tillegg
- admin
- administratorer
- vedtatt
- aggregater
- AI
- AI-modeller
- AI-plattform
- AI / ML
- Alle
- allokering
- tillate
- tillater
- langs
- allerede
- også
- Amazon
- Amazon maskinlæring
- Amazon QuickSight
- Amazon Web Services
- an
- og
- En annen
- Antropisk
- noen
- hverandre
- api
- API-tilgang
- API NØKLER
- APIer
- Søknad
- søknader
- Påfør
- tilnærming
- godkjent
- arkitektur
- arkitekturer
- ER
- AS
- tildelt
- assosiert
- tilknyttede
- At
- revisjon
- Autentisering
- autorisasjon
- autorisert
- tilgjengelig
- AWS
- basert
- grunnleggende
- basis
- BE
- fordi
- Begynnelsen
- BEST
- Bedre
- mellom
- Blogg
- kroppen
- både
- bred
- budsjett
- bygge
- Bygning
- virksomhet
- by
- beregnet
- beregner
- ring
- ringer
- CAN
- evner
- fangst
- fanger
- saken
- sentrum
- Sentre
- sentralisert
- utfordringer
- endring
- valg
- kunde
- klienter
- Cloud
- kode
- kolonner
- kombinert
- Felles
- Selskaper
- komponent
- komponenter
- Beregn
- Konfigurasjon
- tilkobling
- konsistent
- består
- Konsoll
- forbruke
- Forbrukere
- tidkrevende
- forbruk
- innhold
- kontroll
- kontrollerende
- kontroller
- Kostnad
- Kostnader
- kunne
- skape
- opprettet
- skikk
- Kunder
- daglig
- dato
- datavitenskap
- datalagring
- dag
- dedikert
- dypt
- definere
- definert
- benektet
- Avdeling
- avhengig
- utplassere
- utplassert
- distribusjon
- Distribueres
- beskrive
- beskrevet
- utforming
- utforme
- destinasjoner
- detalj
- detaljer
- utviklet
- Utvikling
- utviklingsteam
- diagram
- forskjellig
- dimensjoner
- direkte
- diskutere
- diskutert
- do
- ikke
- ikke
- hver enkelt
- Tidligere
- lett
- effekt
- enten
- embedding
- EMEA
- muliggjøre
- aktivert
- slutt
- ende til ende
- Endpoint
- styrke
- sikre
- Hele
- Miljø
- miljøer
- feil
- etablere
- Selv
- Event
- eksempel
- stige
- utveksling
- eksisterende
- erfaring
- ekspertise
- forklarte
- forklarer
- utforske
- Utforske
- ekspress
- utvidet
- kjent
- familie
- filet
- filtrering
- finansiell
- finansielle tjenester
- passer inn
- fleksibilitet
- flyten
- Fokus
- etter
- følger
- Til
- format
- fora
- Fundament
- grunn
- Foundations
- Rammeverk
- rammer
- Frekvens
- venner
- fra
- foran
- Front end
- fullt
- funksjon
- funksjonelle
- funksjonalitet
- funksjoner
- videre
- gateway
- gatewayer
- general
- generert
- genererer
- generasjonen
- generative
- Generativ AI
- blir
- GitHub
- gitt
- Go
- styresett
- styrt
- Gruppe
- håndtere
- Skjer
- Ha
- å ha
- he
- helsetjenester
- høyde
- hjelpe
- hjelper
- her
- her.
- Høy
- høytytende
- hans
- Vertskapet
- Hvordan
- Hvordan
- HTML
- http
- HTTPS
- Hundrevis
- ID
- identifikator
- identifisere
- Identitet
- if
- bilde
- Påvirkning
- iverksette
- implementert
- in
- inkludere
- Inkludert
- individuelt
- utledet
- informasjon
- Infrastruktur
- innovere
- inngang
- innganger
- instruksjoner
- integrere
- Integrering
- integrering
- samhandle
- interaksjon
- interaksjoner
- Interface
- intern
- inn
- påkalt
- isolasjon
- utstedelse
- utstedelse
- IT
- varer
- DET ER
- reise
- jpg
- nøkkel
- nøkler
- Kid
- Labs
- språk
- stor
- Siste
- Ventetid
- lag
- lag
- ledende
- LÆRE
- læring
- Nivå
- Life
- Life Sciences
- i likhet med
- liker
- grenser
- linje
- linjer
- oppført
- lokal
- logging
- logikk
- Se
- ser ut som
- Lot
- elsker
- Lav
- maskin
- maskinlæring
- Vedlike
- gjøre
- administrer
- fikk til
- ledelse
- administrerende
- mange
- kart
- maksimal
- Kan..
- mekanismer
- Møt
- nevnt
- Meta
- metoder
- mikrotjeneste
- microservices
- kunne
- MILAN
- ML
- Mote
- modell
- modeller
- Overvåke
- mer
- mest
- mye
- flere
- Natur
- nødvendig
- Trenger
- nødvendig
- behov
- nettverk
- Ny
- Antall
- nummerert
- forekom
- of
- Tilbud
- on
- På etterspørsel
- ONE
- bare
- åpen
- åpen kildekode
- betjene
- drift
- alternativer
- or
- rekkefølge
- organisasjon
- Annen
- omriss
- produksjon
- utganger
- enn
- egen
- side
- parameter
- parametere
- del
- for
- ytelse
- tillatelser
- steder
- fly
- planer
- plattform
- Plattformer
- plato
- Platon Data Intelligence
- PlatonData
- politikk
- basseng
- Post
- potensiell
- powered
- forut
- forhåndsdefinert
- Premium
- gaver
- forrige
- tidligere
- Prisene
- prising
- privatliv
- privat
- Produksjon
- Produkter
- Programmering
- programmerings språk
- prosjekt
- foreslått
- gi
- forutsatt
- tilbydere
- gir
- gi
- forsyning
- Python
- spørring
- raskt
- heve
- område
- Sats
- Lese
- nylig
- referere
- referanse
- registrere
- registrering
- Registrering
- Regulere
- relevant
- Rapporter
- Repository
- representerer
- anmode
- forespørsler
- krever
- Krav
- reservert
- Ressurser
- respektere
- de
- henholdsvis
- svar
- ansvarlig
- REST
- begrense
- retur
- avkastning
- Rolle
- ruter
- Regel
- Kjør
- går
- SaaS
- samme
- lagret
- skalerbar
- Skala
- vekter
- scenarier
- planlegge
- Vitenskap
- VITENSKAPER
- omfang
- seksjoner
- sikkert
- sikkerhet
- se
- søker
- SELV
- sender
- senior
- sendt
- separat
- server
- server~~POS=TRUNC
- tjeneste
- Tjenester
- sett
- sett
- oppsett
- Del
- delt
- hun
- Vis
- vist
- Enkelt
- enkelhet
- enkelt
- størrelser
- Software
- programvare som en tjeneste
- programvareutvikling
- løsning
- Solutions
- noen
- kilde
- spesialiserer seg
- spesialist
- spesifikk
- spesielt
- spesifikasjoner
- spesifisert
- fart
- bruke
- utgifter
- Stabilitet
- stable
- Begynn
- Steps
- lagring
- oppbevare
- lagret
- butikker
- strategier
- subnett
- vellykket
- slik
- tilstrekkelig
- sikker
- bord
- Target
- lag
- lag
- Teknisk
- Teknologi
- mal
- leietaker
- begrep
- tekst
- Det
- De
- informasjonen
- deres
- Dem
- seg
- deretter
- Der.
- Disse
- de
- ting
- denne
- tusener
- Gjennom
- gjennomstrømning
- nivået
- tid
- titan
- til
- token
- tokens
- temaer
- Totalt
- spor
- Sporing
- spor
- sant
- to
- typen
- typisk
- forstå
- unik
- låse opp
- oppdatert
- bruk
- bruke
- bruk sak
- brukt
- Bruker
- Brukere
- bruker
- ved hjelp av
- v1
- verdi
- ulike
- versjon
- versjoner
- av
- Se
- synlighet
- visualisering
- visualisere
- we
- web
- webtjenester
- Web-sockets
- VI VIL
- Hva
- Hva er
- når
- hvilken
- mens
- HVEM
- bredde
- med
- innenfor
- uten
- Arbeid
- arbeidsflyt
- arbeid
- virker
- ville
- skrive
- år
- Du
- Din
- zephyrnet