Byg en intern SaaS-tjeneste med omkostnings- og brugssporing for fundamentmodeller på Amazon Bedrock | Amazon Web Services

Virksomheder søger hurtigt at frigøre potentialet ved generativ AI ved at give adgang til fundamentmodeller (FM'er) til forskellige brancher (LOB'er). It-teams er ansvarlige for at hjælpe LOB med at innovere med hastighed og smidighed, mens de giver centraliseret styring og observerbarhed. For eksempel kan de have brug for at spore brugen af ​​FM'er på tværs af teams, tilbageførselsomkostninger og give synlighed til det relevante omkostningscenter i LOB'en. Derudover skal de muligvis regulere adgangen til forskellige modeller pr. hold. For eksempel hvis kun specifikke FM'er må godkendes til brug.

Amazonas grundfjeld er en fuldt administreret tjeneste, der tilbyder et udvalg af højtydende fundamentmodeller fra førende AI-virksomheder som AI21 Labs, Anthropic, Cohere, Meta, Stability AI og Amazon via en enkelt API, sammen med et bredt sæt af muligheder til at bygge generativ AI applikationer med sikkerhed, privatliv og ansvarlig AI. Fordi Amazon Bedrock er serverløs, behøver du ikke at administrere nogen infrastruktur, og du kan sikkert integrere og implementere generative AI-funktioner i dine applikationer ved hjælp af de AWS-tjenester, du allerede er bekendt med.

Et software as a service-lag (SaaS) til fundamentmodeller kan give en enkel og ensartet grænseflade til slutbrugere, samtidig med at centraliseret styring af adgang og forbrug opretholdes. API-gateways kan give løs kobling mellem modelforbrugere og modelslutpunktstjenesten og fleksibilitet til at tilpasse sig skiftende model, arkitekturer og invokationsmetoder.

I dette indlæg viser vi dig, hvordan du bygger et internt SaaS-lag for at få adgang til fundamentmodeller med Amazon Bedrock i en multi-tenant (team) arkitektur. Vi fokuserer specifikt på forbrugs- og omkostningssporing pr. lejer og også kontroller såsom forbrugsregulering pr. lejer. Vi beskriver, hvordan løsningen og Amazon Bedrock-forbrugsplaner er knyttet til den generelle SaaS-rejseramme. Koden til løsningen og en AWS Cloud Development Kit (AWS CDK) skabelon er tilgængelig i GitHub repository.

Udfordringer

En AI-platformsadministrator skal give standardiseret og nem adgang til FM'er til flere udviklingsteams.

Følgende er nogle af udfordringerne for at give styret adgang til fundamentmodeller:

• Omkostnings- og forbrugssporing – Spor og revider individuelle lejeromkostninger og brug af fundamentmodeller, og giv tilbageførselsomkostninger til specifikke omkostningssteder
• Budget- og brugskontrol – Administrer API-kvoter, budget og brugsgrænser for den tilladte brug af fundamentmodeller over en defineret frekvens pr. lejer
• Adgangskontrol og modelstyring – Definer adgangskontroller for specifikke tilladte modeller pr. lejer
• Multi-tenant standardiseret API – Giv ensartet adgang til fundamentmodeller med Åbn API standarder
• Centraliseret styring af API – Giv et enkelt lag til at administrere API-nøgler for at få adgang til modeller
• Modelversioner og opdateringer – Håndter udrulning af nye og opdaterede modelversioner

Løsningsoversigt

I denne løsning henviser vi til en multi-lejer nærme sig. EN lejer her kan spænde fra en individuel bruger, et specifikt projekt, team eller endda en hel afdeling. Når vi diskuterer tilgangen, bruger vi udtrykket hold, fordi det er det mest almindelige. Vi bruger API-nøgler til at begrænse og overvåge API-adgang for teams. Hvert hold får tildelt en API-nøgle for adgang til FM'erne. Der kan være forskellige brugergodkendelses- og autorisationsmekanismer implementeret i en organisation. For nemheds skyld inkluderer vi ikke disse i denne løsning. Du kan også integrere eksisterende identitetsudbydere med denne løsning.

Følgende diagram opsummerer løsningsarkitekturen og nøglekomponenterne. Teams (lejere), der er tildelt separate omkostningscentre, bruger Amazon Bedrock FM'er via en API-tjeneste. For at spore forbrug og omkostninger pr. team, logger løsningen data for hver enkelt påkaldelse, inklusive den påkaldte model, antal tokens for tekstgenereringsmodeller og billeddimensioner for multimodale modeller. Derudover aggregerer den påkaldelser pr. model og omkostninger for hvert team.

Du kan implementere løsningen på din egen konto ved hjælp af AWS CDK. AWS CDK er en open source-softwareudviklingsramme til at modellere og levere dine cloud-applikationsressourcer ved hjælp af velkendte programmeringssprog. AWS CDK-koden er tilgængelig i GitHub repository.

I de følgende afsnit diskuterer vi nøglekomponenterne i løsningen mere detaljeret.

Registrering af fundamentmodelbrug pr. team

Arbejdsgangen til at registrere FM-brug pr. team består af følgende trin (som nummereret i det foregående diagram):

1. Et teams ansøgning sender en POST-anmodning til Amazon API Gateway med den model, der skal påberåbes i model_id forespørgselsparameter og brugerprompten i anmodningsteksten.
2. API Gateway dirigerer anmodningen til en AWS Lambda funktion (bedrock_invoke_model), der er ansvarlig for at logge oplysninger om teambrug ind amazoncloudwatch og påberåber sig Amazon Bedrock-modellen.
3. Amazon Bedrock leverer et VPC-endepunkt drevet af AWS PrivateLink. I denne løsning sender Lambda-funktionen anmodningen til Amazon Bedrock ved hjælp af PrivateLink for at etablere en privat forbindelse mellem VPC'en på din konto og Amazon Bedrock-tjenestekontoen. For at lære mere om PrivateLink, se Brug AWS PrivateLink til at konfigurere privat adgang til Amazon Bedrock.
4. Efter Amazonas grundbjerg-påkaldelse, Amazon CloudTrail genererer en CloudTrail begivenhed.
5. Hvis Amazon Bedrock-kaldet lykkes, logger Lambda-funktionen følgende oplysninger afhængigt af typen af ​​påberåbt model og returnerer det genererede svar til applikationen:
   • team_id – Den unikke identifikator for det team, der udsteder anmodningen.
   • requestId – Anmodningens unikke identifikator.
   • model_id – ID'et for den model, der skal påberåbes.
   • inputTokens – Antallet af tokens sendt til modellen som en del af prompten (til tekstgenerering og indlejringsmodeller).
   • outputtokens – Det maksimale antal tokens, der skal genereres af modellen (for tekstgenereringsmodeller).
   • højde – Højden på det ønskede billede (for multimodale modeller og multimodale indlejringsmodeller).
   • bredde – Bredden af ​​det ønskede billede (kun for multimodale modeller).
   • trin – De anmodede trin (for Stability AI-modeller).

Sporingsomkostninger pr. hold

Et andet flow samler brugsoplysningerne og beregner og sparer derefter on-demand-omkostningerne pr. team på daglig basis. Ved at have et separat flow sikrer vi, at omkostningssporing ikke påvirker ventetiden og gennemløbet af modelopkaldsflowet. Workflow-trinene er som følger:

1. An Amazon Eventbridge regel udløser en lambdafunktion (bedrock_cost_tracking) daglige.
2. Lambdafunktionen henter brugsoplysningerne fra CloudWatch for den foregående dag, beregner de tilknyttede omkostninger og gemmer data aggregeret af team_id , model_id in Amazon Simple Storage Service (Amazon S3) i CSV-format.

For at forespørge og visualisere de data, der er gemt i Amazon S3, har du forskellige muligheder, bl.a S3 Vælgog Amazon Athena og Amazon QuickSight.

Styring af forbrug pr. hold

En brugsplan specificerer, hvem der kan få adgang til en eller flere implementerede API'er og indstiller valgfrit målanmodningshastigheden for at begynde at begrænse anmodninger. Planen bruger API-nøgler til at identificere API-klienter, der kan få adgang til den tilknyttede API for hver nøgle. Du kan bruge API Gateway brugsplaner at drosle anmodninger, der overstiger foruddefinerede tærskler. Du kan også bruge API-nøgler og kvotegrænser, som gør det muligt for dig at indstille det maksimale antal anmodninger pr. API-nøgle, som hvert team har tilladelse til at udstede inden for et bestemt tidsinterval. Dette er foruden Amazon Bedrock servicekvoter som kun er tildelt på kontoniveau.

Forudsætninger

Før du implementerer løsningen, skal du sikre dig, at du har følgende:

Implementer AWS CDK-stakken

Følg instruktionerne i README fil i GitHub-lageret for at konfigurere og implementere AWS CDK-stakken.

Stakken implementerer følgende ressourcer:

• Privat netværksmiljø (VPC, private undernet, sikkerhedsgruppe)
• IAM-rolle til kontrol af modeladgang
• Lambdalag til de nødvendige Python-moduler
• Lambda funktion invoke_model
• Lambda funktion list_foundation_models
• Lambda funktion cost_tracking
• Rest API (API Gateway)
• API Gateway-brugsplan
• API-nøgle knyttet til brugsplanen

Ombord på et nyt hold

For at give adgang til nye teams kan du enten dele den samme API-nøgle på tværs af forskellige teams og spore modelforbruget ved at levere en anden team_id til API-indkaldelsen, eller opret dedikerede API-nøgler, der bruges til at få adgang til Amazon Bedrock-ressourcer ved at følge instruktionerne i README.

Stakken implementerer følgende ressourcer:

• API Gateway-brugsplan knyttet til den tidligere oprettede REST API
• API-nøgle knyttet til brugsplanen for det nye team, med reserveret drosling og burst-konfigurationer til API'en

For mere information om API Gateway throttling og burst-konfigurationer, se Throttle API-anmodninger for bedre gennemløb.

Når du har implementeret stakken, kan du se, at den nye API-nøgle til team-2 oprettes også.

Konfigurer modeladgangskontrol

Platformadministratoren kan tillade adgang til specifikke fundamentmodeller ved at redigere IAM-politikken knyttet til Lambda-funktionen invoke_model. Det

IAM-tilladelser er defineret i filen setup/stack_constructs/iam.py. Se følgende kode:

self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", “bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1"
], ) ], ) … self.bedrock_policy.attach_to_role(self.lambda_role)

Påkald tjenesten

Når du har implementeret løsningen, kan du aktivere tjenesten direkte fra din kode. Det følgende

er et eksempel i Python til at forbruge invoke_model API til tekstgenerering gennem en POST-anmodning:

api_key=”abcd1234” model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} 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 }
) text = response.json()[0]["generated_text"] print(text)

Output: Amazon Bedrock er en intern teknologiplatform udviklet af Amazon til at drive og drive mange af deres tjenester og produkter. Nogle vigtige ting om Bedrock …

Det følgende er et andet eksempel i Python til at forbruge invoke_model API til generering af indlejringer gennem en POST-anmodning:

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"]

Output: 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, 0.079589844, 0.033935547, 0.796875, 0.15429688, 0.29882812, 0.25585938 , 0.45703125, 0.044921875, 0.34570312, XNUMX, -XNUMX, XNUMX, -XNUMX, -XNUMX, -XNUMX, -XNUMX. XNUMX, XNUMX …

Adgang nægtet til fundamentmodeller

Følgende er et eksempel i Python til at forbruge invoke_model API til tekstgenerering gennem en POST-anmodning med et svar med nægtet adgang:

model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} 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 }
) print(response)
print(response.text)

“Traceback (seneste opkald sidst):n Fil ”/var/task/index.py”, linje 213, i lambda_handlern-svar = _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.errorfactory.Access Der opstod en fejl (AccessDeniedException) ved kald af InvokeModel-handlingen: Din konto er ikke autoriseret til at påkalde denne API-handling.n"

Eksempel på omkostningsberegning

Når man påberåber sig Amazon Bedrock-modeller med on-demand-priser, beregnes de samlede omkostninger som summen af ​​input- og outputomkostningerne. Inputomkostninger er baseret på antallet af input-tokens, der sendes til modellen, og output-omkostninger er baseret på de genererede tokens. Priserne er pr. 1,000 input-tokens og pr. 1,000 output-tokens. For flere detaljer og specifikke modelpriser, se Priser for Amazons grundfjeld.

Lad os se på et eksempel, hvor to teams, team1 og team2, får adgang til Amazon Bedrock gennem løsningen i dette indlæg. Brugs- og omkostningsdataene, der er gemt i Amazon S3 på en enkelt dag, er vist i følgende tabel.

Søjlerne input_tokens , output_tokens gemme de samlede input- og outputtokens på tværs af modelankaldelser pr. model og pr. team, henholdsvis for en given dag.

Søjlerne input_cost , output_cost gemme de respektive omkostninger pr. model og pr. hold. Disse beregnes ved hjælp af følgende formler:

input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000

End-to-end visning af et funktionelt multi-tenant serverløst SaaS-miljø

Lad os forstå, hvordan et end-to-end funktionelt multi-tenant serverløst SaaS-miljø kan se ud. Det følgende er et referencearkitekturdiagram.

Dette arkitekturdiagram er en udzoomet version af det tidligere arkitekturdiagram forklaret tidligere i indlægget, hvor det forrige arkitekturdiagram forklarer detaljerne for en af ​​de nævnte mikrotjenester (fundamental modelservice). Dette diagram forklarer, at du, bortset fra grundlæggende modelservice, også skal have andre komponenter i din multi-tenant SaaS-platform for at implementere en funktionel og skalerbar platform.

Lad os gennemgå detaljerne i arkitekturen.

Lejer ansøgninger

Lejerapplikationerne er frontend-applikationerne, der interagerer med miljøet. Her viser vi flere lejere, der har adgang fra forskellige lokale eller AWS-miljøer. Frontend-applikationerne kan udvides til at omfatte en registreringsside, hvor nye lejere kan registrere sig selv, og en administrationskonsol for administratorer af SaaS-servicelaget. Hvis lejerapplikationerne kræver, at en brugerdefineret logik skal implementeres, der kræver interaktion med SaaS-miljøet, kan de implementere specifikationerne for applikationsadapterens mikroservice. Eksempler på scenarier kunne være tilføjelse af tilpasset godkendelseslogik, mens autorisationsspecifikationerne for SaaS-miljøet respekteres.

Fælles tjenester

Følgende er delte tjenester:

• Lejer- og brugeradministrationsydelser – Disse tjenester er ansvarlige for at registrere og administrere lejerne. De leverer den tværgående funktionalitet, der er adskilt fra applikationstjenester og deles på tværs af alle lejere.
• Foundation model service – Løsningsarkitekturdiagrammet, der er forklaret i begyndelsen af ​​dette indlæg, repræsenterer denne mikroservice, hvor interaktionen fra API Gateway til Lambda-funktioner sker inden for denne mikroservices omfang. Alle lejere bruger denne mikroservice til at påberåbe sig fundamentsmodellerne fra Anthropic, AI21, Cohere, Stability, Meta og Amazon, samt finjusterede modeller. Det fanger også de nødvendige oplysninger til brugssporing i CloudWatch-logfiler.
• Omkostningssporingstjeneste – Denne service sporer omkostningerne og forbruget for hver lejer. Denne mikrotjeneste kører efter en tidsplan for at forespørge CloudWatch-logfilerne og udlæse den aggregerede brugssporing og udledte omkostninger til datalagringen. Omkostningssporingstjenesten kan udvides til at opbygge yderligere rapporter og visualisering.

Applikationsadaptertjeneste

Denne service præsenterer et sæt specifikationer og API'er, som en lejer kan implementere for at integrere deres brugerdefinerede logik til SaaS-miljøet. Baseret på hvor meget tilpasset integration der er behov for, kan denne komponent være valgfri for lejere.

Datalager for flere lejere

De delte tjenester gemmer deres data i et datalager, der kan være en enkelt delt Amazon DynamoDB tabel med en lejeropdelingsnøgle, der knytter DynamoDB-varer til individuelle lejere. Den delte tjeneste for omkostningssporing udsender de aggregerede brugs- og omkostningssporingsdata til Amazon S3. Baseret på use casen kan der også være et applikationsspecifikt datalager.

Et SaaS-miljø med flere lejere kan have mange flere komponenter. For mere information, se Opbygning af en Multi-Tenant SaaS-løsning ved hjælp af AWS-serverløse tjenester.

Understøttelse af flere implementeringsmodeller

SaaS-frameworks skitserer typisk to implementeringsmodeller: pool og silo. For poolmodellen får alle lejere adgang til FM'er fra et delt miljø med fælles lager- og computerinfrastruktur. I silomodellen har hver lejer sit eget sæt dedikerede ressourcer. Du kan læse om isolationsmodeller i Whitepaper om SaaS-lejerisoleringsstrategier.

Den foreslåede løsning kan anvendes til begge SaaS-implementeringsmodeller. I pooltilgangen er et centraliseret AWS-miljø vært for API-, lager- og computerressourcerne. I silotilstand får hvert team adgang til API'er, lager- og computerressourcer i et dedikeret AWS-miljø.

Løsningen passer også med de tilgængelige forbrugsplaner leveret af Amazon Bedrock. AWS giver et valg mellem to forbrugsplaner til slutning:

• On-Demand – Denne tilstand giver dig mulighed for at bruge fundamentmodeller på en pay-as-you-go-basis uden at skulle indgå nogen tidsbaserede forpligtelser
• Forsynet gennemløb – Denne tilstand giver dig mulighed for at levere tilstrækkelig gennemstrømning til at opfylde din applikations ydeevnekrav i bytte for en tidsbaseret forpligtelse

For mere information om disse muligheder, se Priser for Amazons grundfjeld.

Den serverløse SaaS-referenceløsning, der er beskrevet i dette indlæg, kan anvende Amazon Bedrock-forbrugsplanerne til at give slutbrugere grundlæggende og førsteklasses niveaumuligheder. Basic kunne omfatte On-Demand eller Provisioned Throughput forbrug af Amazon Bedrock og kunne omfatte specifikke brugs- og budgetgrænser. Lejergrænser kan aktiveres ved at begrænse anmodninger baseret på anmodninger, tokenstørrelser eller budgettildeling. Premium-lejere kunne have deres egne dedikerede ressourcer med forudsat gennemløbsforbrug af Amazon Bedrock. Disse lejere vil typisk være forbundet med produktionsarbejdsbelastninger, der kræver høj gennemstrømning og lav latensadgang til Amazon Bedrock FM'er.

Konklusion

I dette indlæg diskuterede vi, hvordan man opbygger en intern SaaS-platform for at få adgang til fundamentmodeller med Amazon Bedrock i et multi-tenant-opsætning med fokus på sporing af omkostninger og brug og begrænsninger for hver lejer. Yderligere emner at udforske omfatter integration af eksisterende godkendelses- og godkendelsesløsninger i organisationen, forbedring af API-laget til at inkludere web-sockets til tovejs klientserverinteraktioner, tilføjelse af indholdsfiltrering og andre styringsværn, design af flere implementeringsniveauer, integration af andre mikrotjenester i SaaS arkitektur og mange flere.

Hele koden for denne løsning er tilgængelig i GitHub repository.

For mere information om SaaS-baserede rammer, se SaaS Journey Framework: Opbygning af en ny SaaS-løsning på AWS.

Om forfatterne

Hasan Poonawala er Senior AI/ML Specialist Solutions Architect hos AWS, der arbejder med Healthcare og Life Sciences-kunder. Hasan hjælper med at designe, implementere og skalere Generative AI og Machine learning-applikationer på AWS. Han har over 15 års kombineret arbejdserfaring inden for maskinlæring, softwareudvikling og datavidenskab i skyen. I sin fritid elsker Hasan at udforske naturen og tilbringe tid med venner og familie.

Anastasia Tzeveleka er Senior AI/ML Specialist Solutions Architect hos AWS. Som en del af sit arbejde hjælper hun kunder på tværs af EMEA med at bygge fundamentmodeller og skabe skalerbare generative AI- og maskinlæringsløsninger ved hjælp af AWS-tjenester.

Bruingen Pistone er en generativ AI og ML Specialist Solutions Architect for AWS baseret i Milano. Han arbejder med store kunder, der hjælper dem til dybt at forstå deres tekniske behov og designe AI- og Machine Learning-løsninger, der gør den bedste brug af AWS Cloud og Amazon Machine Learning-stakken. Hans ekspertise omfatter: Machine Learning end to end, Machine Learning Industrialization og Generative AI. Han nyder at tilbringe tid med sine venner og udforske nye steder, såvel som at rejse til nye destinationer.

Vikesh Pandey er en Generative AI/ML Solutions-arkitekt med speciale i finansielle tjenester, hvor han hjælper finansielle kunder med at opbygge og skalere Generative AI/ML-platforme og -løsninger, som kan skaleres til hundredvis til endda tusindvis af brugere. I sin fritid kan Vikesh godt lide at skrive på forskellige blogfora og bygge lego sammen med sit barn.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang 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/