Företag försöker snabbt frigöra potentialen hos generativ AI genom att ge tillgång till grundmodeller (FM) till olika branscher (LOB). IT-team är ansvariga för att hjälpa LOB att förnya sig med snabbhet och smidighet samtidigt som de tillhandahåller centraliserad styrning och observerbarhet. Till exempel kan de behöva spåra användningen av FM:er över team, återkravskostnader och ge synlighet till relevant kostnadsställe i LOB. Dessutom kan de behöva reglera tillgången till olika modeller per team. Till exempel om bara specifika FM-apparater får godkännas för användning.
Amazonas berggrund är en helt hanterad tjänst som erbjuder ett urval av högpresterande grundmodeller från ledande AI-företag som AI21 Labs, Anthropic, Cohere, Meta, Stability AI och Amazon via ett enda API, tillsammans med en bred uppsättning möjligheter för att bygga generativ AI applikationer med säkerhet, integritet och ansvarsfull AI. Eftersom Amazon Bedrock är serverlöst behöver du inte hantera någon infrastruktur, och du kan säkert integrera och distribuera generativa AI-funktioner i dina applikationer med hjälp av de AWS-tjänster du redan är bekant med.
Ett SaaS-lager (Software as a Service) för grundmodeller kan tillhandahålla ett enkelt och konsekvent gränssnitt för slutanvändare, samtidigt som man upprätthåller centraliserad styrning av åtkomst och konsumtion. API-gateways kan ge lös koppling mellan modellkonsumenter och modellens slutpunktstjänst, och flexibilitet att anpassa sig till förändrade modell, arkitekturer och anropsmetoder.
I det här inlägget visar vi dig hur du bygger ett internt SaaS-lager för att komma åt grundmodeller med Amazon Bedrock i en arkitektur med flera hyresgäster (team). Vi fokuserar specifikt på användning och kostnadsspårning per hyresgäst och även kontroller som användningsstrypning per hyresgäst. Vi beskriver hur lösningen och Amazons konsumtionsplaner för berggrunden kartläggs till det allmänna SaaS-reseramverket. Koden för lösningen och en AWS Cloud Development Kit (AWS CDK) mall är tillgänglig i GitHub repository.
Utmaningar
En AI-plattformsadministratör måste ge standardiserad och enkel åtkomst till FM:er till flera utvecklingsteam.
Följande är några av utmaningarna för att ge reglerad tillgång till grundmodeller:
- Spårning av kostnader och användning – Spåra och granska enskilda hyresgästers kostnader och användning av grundmodeller och tillhandahålla återkravskostnader till specifika kostnadsställen
- Budget- och användningskontroller – Hantera API-kvot, budget och användningsgränser för tillåten användning av grundmodeller över en definierad frekvens per hyresgäst
- Tillträdeskontroll och modellstyrning – Definiera åtkomstkontroller för specifika tillåtna modeller per hyresgäst
- Multi-tenant standardiserat API – Ge konsekvent tillgång till grundmodeller med Öppna API standarder
- Centraliserad hantering av API – Tillhandahåll ett enda lager för att hantera API-nycklar för åtkomst till modeller
- Modellversioner och uppdateringar – Hantera utrullningar av nya och uppdaterade modellversioner
Lösningsöversikt
I denna lösning hänvisar vi till en flerhyresgäst närma sig. A hyresgäst här kan vara allt från en enskild användare, ett specifikt projekt, team eller till och med en hel avdelning. När vi diskuterar tillvägagångssättet använder vi termen grupp, eftersom det är det vanligaste. Vi använder API-nycklar för att begränsa och övervaka API-åtkomst för team. Varje team tilldelas en API-nyckel för åtkomst till FM:erna. Det kan finnas olika mekanismer för användarautentisering och auktorisering i en organisation. För enkelhetens skull inkluderar vi inte dessa i denna lösning. Du kan också integrera befintliga identitetsleverantörer med denna lösning.
Följande diagram sammanfattar lösningsarkitekturen och nyckelkomponenterna. Team (hyresgäster) tilldelade separata kostnadsställen konsumerar Amazon Bedrock FMs via en API-tjänst. För att spåra förbrukning och kostnad per team loggar lösningen data för varje enskild anrop, inklusive den anropade modellen, antal tokens för textgenereringsmodeller och bilddimensioner för multimodala modeller. Dessutom aggregerar den anropen per modell och kostnader för varje team.
Du kan distribuera lösningen på ditt eget konto med hjälp av AWS CDK. AWS CDK är ett ramverk för utveckling av programvara med öppen källkod för att modellera och tillhandahålla dina molnapplikationsresurser med hjälp av välbekanta programmeringsspråk. AWS CDK-koden är tillgänglig i GitHub repository.
I de följande avsnitten diskuterar vi nyckelkomponenterna i lösningen mer i detalj.
Fånga grundmodellanvändning per team
Arbetsflödet för att fånga FM-användning per team består av följande steg (som numrerat i föregående diagram):
- Ett teams ansökan skickar en POST-förfrågan till Amazon API Gateway med modellen som ska åberopas i
model_idfrågeparametern och användarprompten i begärandetexten. - API Gateway dirigerar begäran till en AWS Lambda funktion (
bedrock_invoke_model) som är ansvarig för att logga in teamanvändningsinformation amazoncloudwatch och åberopa Amazon Bedrock-modellen. - Amazon Bedrock tillhandahåller en VPC-slutpunkt som drivs av AWS PrivateLink. I den här lösningen skickar Lambda-funktionen begäran till Amazon Bedrock med hjälp av PrivateLink för att upprätta en privat anslutning mellan VPC:n på ditt konto och Amazon Bedrock-tjänstkontot. För att lära dig mer om PrivateLink, se Använd AWS PrivateLink för att ställa in privat åtkomst till Amazon Bedrock.
- Efter Amazonas berggrundsupprop, Amazon CloudTrail genererar en CloudTrail-evenemang.
- Om Amazon Bedrock-anropet lyckas loggar Lambda-funktionen följande information beroende på typen av anropad modell och returnerar det genererade svaret till applikationen:
- team_id – Den unika identifieraren för teamet som utfärdar begäran.
- requestId – Den unika identifieraren för begäran.
- modell_id – ID för modellen som ska åberopas.
- inputTokens – Antalet tokens som skickas till modellen som en del av prompten (för textgenerering och inbäddningsmodeller).
- outputTokens – Det maximala antalet tokens som ska genereras av modellen (för modeller för textgenerering).
- höjd – Höjden på den begärda bilden (för multimodala modeller och multimodala inbäddningsmodeller).
- bredd – Bredden på den begärda bilden (endast för multimodala modeller).
- steg – De begärda stegen (för Stability AI-modeller).
Spårningskostnader per lag
Ett annat flöde aggregerar användningsinformationen, beräknar och sparar sedan on-demand-kostnaderna per team på daglig basis. Genom att ha ett separat flöde säkerställer vi att kostnadsspårning inte påverkar latensen och genomströmningen av modellanropsflödet. Arbetsflödesstegen är följande:
- An Amazon EventBridge regeln utlöser en lambdafunktion (
bedrock_cost_tracking) dagligen. - Lambdafunktionen hämtar användningsinformationen från CloudWatch för föregående dag, beräknar associerade kostnader och lagrar data som aggregeras av
team_idochmodel_idin Amazon enkel lagringstjänst (Amazon S3) i CSV-format.
För att fråga och visualisera data som lagras i Amazon S3 har du olika alternativ, inklusive S3 Väljoch Amazon Athena och Amazon QuickSight.
Kontrollera användningen per team
En användningsplan anger vem som kan komma åt en eller flera distribuerade API:er och ställer valfritt in målfrekvensen för begäranden för att börja strypa förfrågningar. Planen använder API-nycklar för att identifiera API-klienter som kan komma åt det associerade API:et för varje nyckel. Du kan använda API Gateway användningsplaner för att strypa förfrågningar som överskrider fördefinierade trösklar. Du kan också använda API-nycklar och kvotgränser, som gör att du kan ställa in det maximala antalet förfrågningar per API-nyckel som varje team får utfärda inom ett visst tidsintervall. Detta är utöver Amazon Bedrock tjänstekvoter som endast tilldelas på kontonivå.
Förutsättningar
Innan du distribuerar lösningen, se till att du har följande:
Distribuera AWS CDK-stacken
Följ instruktionerna i README filen i GitHub-förvaret för att konfigurera och distribuera AWS CDK-stacken.
Stacken distribuerar följande resurser:
- Privat nätverksmiljö (VPC, privata undernät, säkerhetsgrupp)
- IAM-roll för kontroll av modellåtkomst
- Lambdalager för de nödvändiga Python-modulerna
- Lambdafunktion
invoke_model - Lambdafunktion
list_foundation_models - Lambdafunktion
cost_tracking - Rest API (API Gateway)
- API Gateway användningsplan
- API-nyckel kopplad till användningsplanen
Ombord på ett nytt team
För att ge tillgång till nya team kan du antingen dela samma API-nyckel mellan olika team och spåra modellförbrukningen genom att tillhandahålla en annan team_id för API-anropet, eller skapa dedikerade API-nycklar som används för att komma åt Amazon Bedrock-resurser genom att följa instruktionerna i README.
Stacken distribuerar följande resurser:
- API Gateway-användningsplan kopplad till det tidigare skapade REST API:et
- API-nyckel som är kopplad till användningsplanen för det nya teamet, med reserverad strypning och burst-konfigurationer för API:t
För mer information om API Gateway-strypning och burstkonfigurationer, se Throttle API-förfrågningar för bättre genomströmning.
När du har distribuerat stacken kan du se att den nya API-nyckeln för team-2 skapas också.
Konfigurera modellens åtkomstkontroll
Plattformsadministratören kan tillåta åtkomst till specifika grundmodeller genom att redigera IAM-policyn kopplad till Lambda-funktionen invoke_model. De
IAM-behörigheter definieras i filen setup/stack_constructs/iam.py. Se följande kod:
Åberopa tjänsten
Efter att du har implementerat lösningen kan du anropa tjänsten direkt från din kod. Det följande
är ett exempel i Python för att konsumera invoke_model API för textgenerering genom en POST-begäran:
Output: Amazon Bedrock är en intern teknologiplattform utvecklad av Amazon för att driva och driva många av deras tjänster och produkter. Några viktiga saker om Berggrund...
Följande är ett annat exempel i Python för att konsumera invoke_model API för inbäddningsgenerering genom en POST-begäran:
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"]
Utdata: 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 …
Tillgång nekad till grundmodeller
Följande är ett exempel i Python för att konsumera invoke_model API för textgenerering genom en POST-begäran med ett svar som nekats åtkomst:
“Spårning (senaste anrop senast):n Fil ”/var/task/index.py”, rad 213, i lambda_handlern-svar = _invoke_text(bedrock_client, model_id, body, model_kwargs)n File ”/var/task/index.py ”, rad 146, i _invoke_textn raise en File ”/var/task/index.py”, rad 131, i _invoke_textn response = bedrock_client.invoke_model(n File ”/opt/python/botocore/client.py”, rad 535, i _api_calln returnerar self._make_api_call(operation_name, kwargs)n File ”/opt/python/botocore/client.py”, rad 980, i _make_api_calln höj error_class(parsed_response, operation_name)nbotocore.erroriedException.Access Ett fel inträffade (AccessDeniedException) vid anrop av InvokeModel-operationen: Ditt konto är inte auktoriserat att anropa denna API-operation.n"
Exempel på kostnadsuppskattning
När man åberopar Amazon Bedrock-modeller med on-demand-prissättning, beräknas den totala kostnaden som summan av in- och outputkostnaderna. Ingångskostnader baseras på antalet inmatade tokens som skickas till modellen, och utgående kostnader baseras på de tokens som genereras. Priserna är per 1,000 1,000 inmatade tokens och per XNUMX XNUMX output tokens. För mer information och specifika modellpriser, se Prissättning för Amazons berggrund.
Låt oss titta på ett exempel där två team, team1 och team2, får tillgång till Amazon Bedrock genom lösningen i det här inlägget. Användnings- och kostnadsdata som sparats i Amazon S3 under en enda dag visas i följande tabell.
Kolumnerna input_tokens och output_tokens lagra de totala inmatnings- och utdatatokenerna för modellanrop per modell respektive per team för en given dag.
Kolumnerna input_cost och output_cost lagra respektive kostnader per modell och per team. Dessa beräknas med hjälp av följande formler:
input_cost = input_token_count * model_pricing["input_cost"] / 1000output_cost = output_token_count * model_pricing["output_cost"] / 1000
| team_id | modell_id | input_tokens | output_tokens | anrop | 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-vy av en funktionell serverlös SaaS-miljö med flera klienter
Låt oss förstå hur en end-to-end funktionell SaaS-miljö utan server med flera klienter kan se ut. Följande är ett referensarkitekturdiagram.
Det här arkitekturdiagrammet är en utzoomad version av det tidigare arkitekturdiagrammet som förklarats tidigare i inlägget, där det tidigare arkitekturdiagrammet förklarar detaljerna för en av de nämnda mikrotjänsterna (fundamental modelltjänst). Det här diagrammet förklarar att du, förutom grundläggande modelltjänst, måste ha andra komponenter också i din SaaS-plattform för flera innehavare för att implementera en funktionell och skalbar plattform.
Låt oss gå igenom detaljerna i arkitekturen.
Hyresgäst ansökningar
Hyresgästapplikationerna är frontendapplikationerna som interagerar med miljön. Här visar vi flera hyresgäster som kommer åt från olika lokala eller AWS-miljöer. Frontend-applikationerna kan utökas med en registreringssida där nya hyresgäster kan registrera sig och en administratörskonsol för administratörer av SaaS-tjänstlagret. Om klientapplikationerna kräver att en anpassad logik implementeras som kräver interaktion med SaaS-miljön, kan de implementera specifikationerna för applikationsadapterns mikrotjänst. Exempel på scenarier kan vara att lägga till anpassad auktoriseringslogik samtidigt som auktoriseringsspecifikationerna för SaaS-miljön respekteras.
Delade tjänster
Följande är delade tjänster:
- Hyresgäst- och användarhanteringstjänster –Dessa tjänster ansvarar för att registrera och hantera hyresgästerna. De tillhandahåller den tvärgående funktionaliteten som är separat från applikationstjänsterna och delas mellan alla hyresgäster.
- Stiftelsemodelltjänst – Lösningsarkitekturdiagrammet som förklaras i början av det här inlägget representerar denna mikrotjänst, där interaktionen från API Gateway till Lambda-funktioner sker inom ramen för denna mikrotjänst. Alla hyresgäster använder denna mikrotjänst för att åberopa grundmodellerna från Anthropic, AI21, Cohere, Stability, Meta och Amazon, samt finjusterade modeller. Den fångar också informationen som behövs för användningsspårning i CloudWatch-loggar.
- Kostnadsspårningstjänst – Den här tjänsten spårar kostnaden och användningen för varje hyresgäst. Den här mikrotjänsten körs enligt ett schema för att fråga CloudWatch-loggarna och mata ut den aggregerade användningsspårningen och antagna kostnaden för datalagringen. Tjänsten för kostnadsspårning kan utökas för att bygga ytterligare rapporter och visualisering.
Applikationsadaptertjänst
Den här tjänsten presenterar en uppsättning specifikationer och API:er som en hyresgäst kan implementera för att integrera sin anpassade logik i SaaS-miljön. Baserat på hur mycket anpassad integration som behövs kan denna komponent vara valfri för hyresgäster.
Datalager för flera hyresgäster
De delade tjänsterna lagrar sina data i ett datalager som kan vara en enda delad Amazon DynamoDB tabell med en hyresgästpartitioneringsnyckel som associerar DynamoDB-objekt med enskilda hyresgäster. Den delade kostnadsspårningstjänsten matar ut den aggregerade användnings- och kostnadsspårningsdata till Amazon S3. Baserat på användningsfallet kan det också finnas ett applikationsspecifikt datalager.
En multi-tenant SaaS-miljö kan ha mycket fler komponenter. För mer information, se Bygga en SaaS-lösning för flera hyresgäster med hjälp av AWS-serverlösa tjänster.
Stöd för flera distributionsmodeller
SaaS-ramverk beskriver vanligtvis två implementeringsmodeller: pool och silo. För poolmodellen får alla hyresgäster tillgång till FM:er från en delad miljö med gemensam lagrings- och datorinfrastruktur. I silomodellen har varje hyresgäst sin egen uppsättning dedikerade resurser. Du kan läsa om isoleringsmodeller i SaaS Tenant Isolation Strategies whitepaper.
Den föreslagna lösningen kan användas för båda SaaS-distributionsmodellerna. I poolmetoden är en centraliserad AWS-miljö värd för API-, lagrings- och beräkningsresurserna. I siloläge får varje team åtkomst till API:er, lagrings- och beräkningsresurser i en dedikerad AWS-miljö.
Lösningen passar också med de tillgängliga konsumtionsplanerna från Amazon Bedrock. AWS erbjuder ett val av två förbrukningsplaner för slutledning:
- On-Demand – Det här läget låter dig använda grundmodeller på en pay-as-you-go-basis utan att behöva göra några tidsbaserade åtaganden
- Provisioned throughput – Det här läget låter dig tillhandahålla tillräcklig genomströmning för att uppfylla din applikations prestandakrav i utbyte mot ett tidsbaserat åtagande
För mer information om dessa alternativ, se Prissättning för Amazons berggrund.
Den serverlösa SaaS-referenslösningen som beskrivs i det här inlägget kan tillämpa Amazon Bedrock-konsumtionsplanerna för att tillhandahålla grundläggande och premiumalternativ för slutanvändare. Basic kan inkludera On-Demand- eller Provisioned Throughput-förbrukning av Amazon Bedrock och kan inkludera specifika användnings- och budgetgränser. Hyresgästgränser kan aktiveras genom att strypa förfrågningar baserat på förfrågningar, tokenstorlekar eller budgettilldelning. Hyresgäster på premiumnivå kan ha sina egna dedikerade resurser med tillhandahållen genomströmningsförbrukning av Amazon Bedrock. Dessa hyresgäster skulle vanligtvis vara associerade med produktionsbelastningar som kräver hög genomströmning och låg latensåtkomst till Amazon Bedrock FMs.
Slutsats
I det här inlägget diskuterade vi hur man bygger en intern SaaS-plattform för att komma åt grundmodeller med Amazon Bedrock i en multi-tenant setup med fokus på att spåra kostnader och användning, och begränsningar för varje hyresgäst. Ytterligare ämnen att utforska inkluderar integration av befintliga autentiserings- och auktoriseringslösningar i organisationen, förbättring av API-lagret till att inkludera webbsockets för dubbelriktad klientserverinteraktion, lägga till innehållsfiltrering och andra styrräcken, designa flera distributionsnivåer, integrera andra mikrotjänster i SaaS. arkitektur och många fler.
Hela koden för denna lösning finns tillgänglig i GitHub repository.
För mer information om SaaS-baserade ramverk, se SaaS Journey Framework: Bygga en ny SaaS-lösning på AWS.
Om författarna
Hasan Poonawala är Senior AI/ML Specialist Solutions Architect på AWS, som arbetar med Healthcare and Life Sciences-kunder. Hasan hjälper till att designa, distribuera och skala Generative AI och Machine learning-applikationer på AWS. Han har över 15 års kombinerad arbetserfarenhet inom maskininlärning, mjukvaruutveckling och datavetenskap på molnet. På sin fritid älskar Hasan att utforska naturen och umgås med vänner och familj.
anastasia Tzeveleka är Senior AI/ML Specialist Solutions Architect på AWS. Som en del av sitt arbete hjälper hon kunder i EMEA att bygga grundmodeller och skapa skalbara generativa AI- och maskininlärningslösningar med hjälp av AWS-tjänster.
bruingen Pistone är en generativ AI och ML Specialist Solutions Architect för AWS baserad i Milano. Han arbetar med stora kunder som hjälper dem att på djupet förstå deras tekniska behov och designa lösningar för AI och Machine Learning som utnyttjar AWS Cloud och Amazon Machine Learning-stacken på bästa sätt. Hans expertis inkluderar: Machine Learning end to end, Machine Learning Industrialization och Generative AI. Han tycker om att umgås med sina vänner och utforska nya platser, samt att resa till nya destinationer.
Vikesh Pandey är en Generative AI/ML Solutions-arkitekt, specialiserad på finansiella tjänster där han hjälper finansiella kunder att bygga och skala Generative AI/ML-plattformar och lösning som kan skalas till hundratals till till och med tusentals användare. På fritiden gillar Vikesh att skriva på olika bloggforum och bygga lego med sitt barn.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/
