Zephyrnet-logo

Bouw een interne SaaS-service met tracking van kosten en gebruik voor basismodellen op Amazon Bedrock | Amazon-webservices

Datum:

Bedrijven proberen snel het potentieel van generatieve AI te ontsluiten door toegang te bieden tot basismodellen (FM’s) aan verschillende bedrijfstakken (LOB’s). IT-teams zijn verantwoordelijk voor het helpen van de LOB om snel en flexibel te innoveren en tegelijkertijd gecentraliseerd bestuur en observatie te bieden. Het kan bijvoorbeeld nodig zijn dat ze het gebruik van FM's tussen teams bijhouden, kosten terugbetalen en inzicht bieden in de relevante kostenplaats in de LOB. Bovendien moeten ze mogelijk de toegang tot verschillende modellen per team reguleren. Bijvoorbeeld als alleen specifieke FM’s mogen worden goedgekeurd voor gebruik.

Amazonebodem is een volledig beheerde service die via één API een keuze biedt uit goed presterende basismodellen van toonaangevende AI-bedrijven zoals AI21 Labs, Anthropic, Cohere, Meta, Stability AI en Amazon, samen met een breed scala aan mogelijkheden om generatieve AI te bouwen applicaties met beveiliging, privacy en verantwoorde AI. Omdat Amazon Bedrock serverloos is, hoeft u geen enkele infrastructuur te beheren en kunt u generatieve AI-mogelijkheden veilig integreren en implementeren in uw applicaties met behulp van de AWS-services waarmee u al bekend bent.

Een Software as a Service (SaaS)-laag voor basismodellen kan een eenvoudige en consistente interface voor eindgebruikers bieden, terwijl het gecentraliseerde beheer van toegang en verbruik behouden blijft. API-gateways kunnen een losse koppeling bieden tussen modelconsumenten en de modeleindpuntservice, en flexibiliteit om zich aan te passen aan veranderende modellen, architecturen en aanroepmethoden.

In dit bericht laten we je zien hoe je een interne SaaS-laag bouwt om toegang te krijgen tot basismodellen met Amazon Bedrock in een multi-tenant (team) architectuur. We richten ons specifiek op het bijhouden van gebruik en kosten per tenant en ook op controles zoals gebruiksbeperking per tenant. We beschrijven hoe de oplossing en de Amazon Bedrock-consumptieplannen aansluiten op het algemene SaaS-reisframework. De code voor de oplossing en een AWS Cloud-ontwikkelingskit (AWS CDK)-sjabloon is beschikbaar in de GitHub-repository.

Uitdagingen

Een AI-platformbeheerder moet meerdere ontwikkelteams gestandaardiseerde en gemakkelijke toegang tot FM's bieden.

Hier volgen enkele van de uitdagingen bij het bieden van gereguleerde toegang tot funderingsmodellen:

  • Kosten- en gebruiksregistratie – Volg en controleer de kosten van individuele huurders en het gebruik van funderingsmodellen, en geef terugboekingskosten aan specifieke kostenplaatsen
  • Budget- en gebruikscontroles – Beheer API-quota, budget en gebruikslimieten voor het toegestane gebruik van funderingsmodellen over een gedefinieerde frequentie per tenant
  • Toegangscontrole en modelbeheer – Definieer toegangscontroles voor specifieke toegestane modellen per tenant
  • Gestandaardiseerde API voor meerdere tenants – Bied consistente toegang tot funderingsmodellen met OpenAPI normen
  • Gecentraliseerd beheer van API – Bied één enkele laag om API-sleutels te beheren voor toegang tot modellen
  • Modelversies en updates – Verwerk de implementatie van nieuwe en bijgewerkte modelversies

Overzicht oplossingen

In deze oplossing verwijzen we naar a meerdere huurders nadering. EEN huurder dit kan variëren van een individuele gebruiker, een specifiek project, team of zelfs een hele afdeling. Als we de aanpak bespreken, gebruiken we de term team, omdat dit de meest voorkomende is. We gebruiken API-sleutels om de API-toegang voor teams te beperken en te monitoren. Elk team krijgt een API-sleutel toegewezen voor toegang tot de FM's. Er kunnen in een organisatie verschillende gebruikersauthenticatie- en autorisatiemechanismen zijn geïmplementeerd. Voor de eenvoud nemen we deze niet op in deze oplossing. U kunt met deze oplossing ook bestaande identiteitsproviders integreren.

Het volgende diagram geeft een overzicht van de oplossingsarchitectuur en de belangrijkste componenten. Teams (huurders) die aan afzonderlijke kostenplaatsen zijn toegewezen, gebruiken Amazon Bedrock FM's via een API-service. Om het verbruik en de kosten per team bij te houden, registreert de oplossing gegevens voor elke individuele aanroep, inclusief het aangeroepen model, het aantal tokens voor modellen voor het genereren van tekst en afbeeldingsdimensies voor multimodale modellen. Bovendien worden de aanroepen per model en de kosten van elk team samengevoegd.

U kunt de oplossing in uw eigen account implementeren met behulp van de AWS CDK. AWS CDK is een open source softwareontwikkelingsframework om uw cloudapplicatiebronnen te modelleren en in te richten met behulp van bekende programmeertalen. De AWS CDK-code is beschikbaar in de GitHub-repository.

In de volgende secties bespreken we de belangrijkste componenten van de oplossing in meer detail.

Vastleggen van het gebruik van het basismodel per team

De workflow om het FM-gebruik per team vast te leggen bestaat uit de volgende stappen (zoals genummerd in het voorgaande diagram):

  1. De toepassing van een team verzendt een POST-verzoek naar Amazon API-gateway met het model dat moet worden aangeroepen in de model_id queryparameter en de gebruikersprompt in de aanvraagtekst.
  2. API Gateway stuurt het verzoek door naar een AWS Lambda functie (bedrock_invoke_model) die verantwoordelijk is voor het loggen van teamgebruiksinformatie Amazon Cloud Watch en een beroep doen op het Amazon Bedrock-model.
  3. Amazon Bedrock biedt een VPC-eindpunt mogelijk gemaakt door AWS PrivéLink. In deze oplossing stuurt de Lambda-functie het verzoek naar Amazon Bedrock met behulp van PrivateLink om een ​​privéverbinding tot stand te brengen tussen de VPC in uw account en het Amazon Bedrock-serviceaccount. Voor meer informatie over PrivateLink, zie Gebruik AWS PrivateLink om privétoegang tot Amazon Bedrock in te stellen.
  4. Na de Amazon Bedrock-aanroep, Amazon CloudTrail genereert een CloudTrail-evenement.
  5. Als de Amazon Bedrock-aanroep succesvol is, registreert de Lambda-functie de volgende informatie, afhankelijk van het type aangeroepen model, en retourneert het gegenereerde antwoord naar de applicatie:
    • team_id – De unieke identificatiecode van het team dat het verzoek indient.
    • Aanvraag ID – De unieke identificatie van het verzoek.
    • model_id – De ID van het model dat moet worden aangeroepen.
    • invoerTokens – Het aantal tokens dat naar het model is verzonden als onderdeel van de prompt (voor modellen voor het genereren van tekst en insluitingen).
    • uitvoerTokens – Het maximale aantal tokens dat door het model moet worden gegenereerd (voor modellen voor het genereren van tekst).
    • Hoogte – De hoogte van de gevraagde afbeelding (voor multimodale modellen en multimodale inbeddingsmodellen).
    • Breedte – De breedte van de gevraagde afbeelding (alleen voor multimodale modellen).
    • stappen – De gevraagde stappen (voor Stability AI-modellen).

Kosten bijhouden per team

Een andere stroom verzamelt de gebruiksinformatie en berekent vervolgens dagelijks de on-demand kosten per team en slaat deze op. Door een aparte stroom te hebben, zorgen we ervoor dat het bijhouden van kosten geen invloed heeft op de latentie en doorvoer van de modelaanroepstroom. De workflowstappen zijn als volgt:

  1. An Amazon EventBridge regel activeert een Lambda-functie (bedrock_cost_tracking) dagelijks.
  2. De Lambda-functie haalt de gebruiksinformatie van CloudWatch voor de vorige dag op, berekent de bijbehorende kosten en slaat de gegevens op die zijn verzameld door team_id en model_id in Amazon eenvoudige opslagservice (Amazon S3) in CSV-formaat.

Om de gegevens die zijn opgeslagen in Amazon S3 op te vragen en te visualiseren, heeft u verschillende opties, waaronder S3 Selecteer en Amazon Athena en Amazon QuickSight.

Controle van het gebruik per team

Een gebruiksplan specificeert wie toegang heeft tot een of meer geïmplementeerde API's en stelt optioneel de doelverzoeksnelheid in om verzoeken te beperken. Het plan maakt gebruik van API-sleutels om API-clients te identificeren die voor elke sleutel toegang hebben tot de bijbehorende API. U kunt API-gateway gebruiken gebruiksplannen om verzoeken af ​​te remmen die vooraf gedefinieerde drempels overschrijden. Je kan ook gebruiken API-sleutels en quotalimieten, waarmee u het maximale aantal verzoeken per API-sleutel kunt instellen dat elk team binnen een bepaald tijdsinterval mag uitgeven. Dit is een aanvulling op Amazon Bedrock-servicequota die alleen op accountniveau worden toegewezen.

Voorwaarden

Zorg ervoor dat u over het volgende beschikt voordat u de oplossing implementeert:

Implementeer de AWS CDK-stack

Volg de instructies in het README -bestand van de GitHub-repository om de AWS CDK-stack te configureren en te implementeren.

De stapel zet de volgende bronnen in:

  • Privé-netwerkomgeving (VPC, privé-subnetten, beveiligingsgroep)
  • IAM-rol voor het beheren van modeltoegang
  • Lambda-lagen voor de benodigde Python-modules
  • Lambda-functie invoke_model
  • Lambda-functie list_foundation_models
  • Lambda-functie cost_tracking
  • Rest-API (API-gateway)
  • API Gateway-gebruiksplan
  • API-sleutel die is gekoppeld aan het gebruiksplan

Aan boord van een nieuw team

Om toegang te verlenen aan nieuwe teams kunt u dezelfde API-sleutel delen met verschillende teams en het modelverbruik volgen door een andere team_id voor de API-aanroep, of maak speciale API-sleutels die worden gebruikt voor toegang tot Amazon Bedrock-bronnen door de instructies te volgen in de README.

De stapel zet de volgende bronnen in:

  • API Gateway-gebruiksplan gekoppeld aan de eerder gemaakte REST API
  • API-sleutel die is gekoppeld aan het gebruiksplan voor het nieuwe team, met gereserveerde beperkings- en burst-configuraties voor de API

Voor meer informatie over API Gateway-throttling en burst-configuraties raadpleegt u Verlaag API-verzoeken voor een betere doorvoer.

Nadat u de stapel heeft geïmplementeerd, kunt u zien dat de nieuwe API-sleutel voor team-2 wordt ook gecreëerd.

Configureer modeltoegangscontrole

De platformbeheerder kan toegang verlenen tot specifieke funderingsmodellen door het IAM-beleid te bewerken dat aan de Lambda-functie is gekoppeld invoke_model. De

IAM-machtigingen worden gedefinieerd in het bestand setup/stack_constructs/iam.py. Zie de volgende code:

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)

Roep de dienst op

Nadat u de oplossing heeft geïmplementeerd, kunt u de service rechtstreeks vanuit uw code aanroepen. Het volgende

is een voorbeeld in Python voor het consumeren van de invoke_model API voor het genereren van tekst via een POST-verzoek:

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 is een intern technologieplatform ontwikkeld door Amazon om veel van hun diensten en producten uit te voeren en te exploiteren. Enkele belangrijke dingen over Bedrock…

Het volgende is nog een voorbeeld in Python voor het consumeren van de invoke_model API voor het genereren van insluitingen via een POST-verzoek:

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

Uitgang: 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 …

Toegang geweigerd tot funderingsmodellen

Het volgende is een voorbeeld in Python voor het consumeren van de invoke_model API voor het genereren van tekst via een POST-verzoek met een antwoord geweigerd:

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 (meest recente oproep als laatste):n Bestand ”/var/task/index.py”, regel 213, in lambda_handlern antwoord = _invoke_text(bedrock_client, model_id, body, model_kwargs)n Bestand ”/var/task/index.py ”, regel 146, in _invoke_textn raise en Bestand ”/var/task/index.py”, regel 131, in _invoke_textn response = bedrock_client.invoke_model(n Bestand ”/opt/python/botocore/client.py”, regel 535, in _api_calln return self._make_api_call(operation_name, kwargs)n File ”/opt/python/botocore/client.py”, regel 980, in _make_api_calln raise error_class(parsed_response, operations_name)nbotocore.errorfactory.AccessDeniedException: Er is een fout opgetreden (AccessDeniedException) bij het aanroepen van de InvokeModel-bewerking: uw account is niet geautoriseerd om deze API-bewerking aan te roepen.n”

Voorbeeld van kostenraming

Bij het aanroepen van Amazon Bedrock-modellen met on-demand prijzen worden de totale kosten berekend als de som van de input- en outputkosten. De invoerkosten zijn gebaseerd op het aantal invoertokens dat naar het model is verzonden, en de uitvoerkosten zijn gebaseerd op de gegenereerde tokens. De prijzen zijn per 1,000 invoertokens en per 1,000 uitvoertokens. Voor meer details en specifieke modelprijzen, zie Amazon Bedrock-prijzen.

Laten we eens kijken naar een voorbeeld waarbij twee teams, team1 en team2, toegang krijgen tot Amazon Bedrock via de oplossing in dit bericht. De gebruiks- en kostengegevens die op één dag in Amazon S3 zijn opgeslagen, worden in de volgende tabel weergegeven.

De kolommen input_tokens en output_tokens bewaar de totale invoer- en uitvoertokens voor modelaanroepen per model en per team voor een bepaalde dag.

De kolommen input_cost en output_cost bewaar de betreffende kosten per model en per team. Deze worden berekend met behulp van de volgende formules:

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

team_id model_id invoer_tokens uitvoer_tokens aanroepen invoerkosten uitvoerkosten
Team1 amazon.titan-tg1-groot 24000 2473 1000 0.0072 0.00099
Team1 antropisch.claude-v2 2448 4800 24 0.02698 0.15686
Team2 amazon.titan-tg1-groot 35000 52500 350 0.0105 0.021
Team2 ai21.j2-grande-instruct 4590 9000 45 0.05738 0.1125
Team2 antropisch.claude-v2 1080 4400 20 0.0119 0.14379

End-to-end weergave van een functionele multi-tenant serverloze SaaS-omgeving

Laten we eens kijken hoe een end-to-end functionele multi-tenant serverloze SaaS-omgeving eruit zou kunnen zien. Het volgende is een referentiearchitectuurdiagram.

Dit architectuurdiagram is een uitgezoomde versie van het vorige architectuurdiagram dat eerder in het bericht werd uitgelegd, waarbij het vorige architectuurdiagram de details uitlegt van een van de genoemde microservices (fundamentele modelservice). In dit diagram wordt uitgelegd dat u naast de fundamentele modelservice ook andere componenten in uw multi-tenant SaaS-platform nodig heeft om een ​​functioneel en schaalbaar platform te implementeren.

Laten we de details van de architectuur doornemen.

Huurders aanvragen

De tenanttoepassingen zijn de frontendtoepassingen die communiceren met de omgeving. Hier laten we meerdere tenants zien die toegang hebben vanuit verschillende lokale of AWS-omgevingen. De frontendapplicaties kunnen worden uitgebreid met een registratiepagina waar nieuwe tenants zichzelf kunnen registreren en een adminconsole voor beheerders van de SaaS-servicelaag. Als voor de tenanttoepassingen een aangepaste logica moet worden geïmplementeerd die interactie met de SaaS-omgeving vereist, kunnen ze de specificaties van de microservice van de toepassingsadapter implementeren. Voorbeeldscenario's kunnen het toevoegen van aangepaste autorisatielogica zijn, terwijl de autorisatiespecificaties van de SaaS-omgeving worden gerespecteerd.

Gedeelde diensten

Dit zijn gedeelde services:

  • Diensten voor huurder- en gebruikersbeheer –Deze diensten zijn verantwoordelijk voor het registreren en beheren van de huurders. Ze bieden de transversale functionaliteit die losstaat van de applicatieservices en wordt gedeeld door alle tenants.
  • Funderingsmodelservice –Het oplossingsarchitectuurdiagram dat aan het begin van dit bericht werd uitgelegd, vertegenwoordigt deze microservice, waarbij de interactie van API Gateway naar Lambda-functies plaatsvindt binnen de reikwijdte van deze microservice. Alle tenants gebruiken deze microservice om de basismodellen van Anthropic, AI21, Cohere, Stability, Meta en Amazon aan te roepen, evenals verfijnde modellen. Het legt ook de informatie vast die nodig is voor het volgen van het gebruik in CloudWatch-logboeken.
  • Kostenregistratieservice –Deze service houdt de kosten en het gebruik voor elke huurder bij. Deze microservice draait volgens een schema om de CloudWatch-logboeken te doorzoeken en de geaggregeerde gebruiksregistratie en afgeleide kosten voor de gegevensopslag uit te voeren. De kostenregistratieservice kan worden uitgebreid om verdere rapporten en visualisaties op te bouwen.

Applicatie-adapterservice

Deze service presenteert een reeks specificaties en API's die een tenant kan implementeren om zijn aangepaste logica in de SaaS-omgeving te integreren. Op basis van hoeveel aangepaste integratie nodig is, kan dit onderdeel optioneel zijn voor tenants.

Gegevensopslag voor meerdere tenants

De gedeelde services slaan hun gegevens op in een gegevensarchief dat één gedeeld kan zijn Amazon DynamoDB tabel met een tenantpartitioneringssleutel die DynamoDB-items koppelt aan individuele tenants. De gedeelde service voor het bijhouden van kosten voert de verzamelde gebruiks- en kostenregistratiegegevens uit naar Amazon S3. Op basis van de use case kan er ook sprake zijn van een applicatiespecifieke dataopslag.

Een multi-tenant SaaS-omgeving kan uit veel meer componenten bestaan. Voor meer informatie, zie Een SaaS-oplossing voor meerdere tenants bouwen met behulp van AWS Serverless Services.

Ondersteuning voor meerdere implementatiemodellen

SaaS-frameworks schetsen doorgaans twee implementatiemodellen: pool en silo. Bij het poolmodel hebben alle tenants toegang tot FM's vanuit een gedeelde omgeving met een gemeenschappelijke opslag- en computerinfrastructuur. In het silomodel heeft elke tenant zijn eigen set specifieke bronnen. Over isolatiemodellen leest u in de Whitepaper over SaaS Tenant Isolation Strategies.

De voorgestelde oplossing kan voor beide SaaS-implementatiemodellen worden toegepast. Bij de poolbenadering host een gecentraliseerde AWS-omgeving de API-, opslag- en computerbronnen. In de silomodus heeft elk team toegang tot API's, opslag en computerbronnen in een speciale AWS-omgeving.

De oplossing past ook bij de beschikbare verbruiksplannen van Amazon Bedrock. AWS biedt een keuze uit twee consumptieplannen voor gevolgtrekking:

  • On-Demand – Met deze modus kunt u funderingsmodellen gebruiken op basis van een pay-as-you-go-basis, zonder dat u op tijd gebaseerde termijnverplichtingen hoeft aan te gaan
  • Ingerichte doorvoer – In deze modus kunt u voldoende doorvoer leveren om aan de prestatievereisten van uw toepassing te voldoen, in ruil voor een op tijd gebaseerde termijnverplichting

Voor meer informatie over deze opties, zie Amazon Bedrock-prijzen.

De serverloze SaaS-referentieoplossing die in dit bericht wordt beschreven, kan de Amazon Bedrock-consumptieplannen toepassen om basis- en premium tiering-opties aan eindgebruikers te bieden. Basic kan het verbruik van Amazon Bedrock op aanvraag of voorziene doorvoer omvatten en kan specifieke gebruiks- en budgetlimieten omvatten. Tenantlimieten kunnen worden ingeschakeld door aanvragen te beperken op basis van aanvragen, tokengroottes of budgettoewijzing. Premium-tenants kunnen over hun eigen specifieke bronnen beschikken met een ingericht doorvoerverbruik van Amazon Bedrock. Deze tenants worden doorgaans geassocieerd met productieworkloads die een hoge doorvoersnelheid en toegang met lage latentie tot Amazon Bedrock FM's vereisen.

Conclusie

In dit bericht hebben we besproken hoe je met Amazon Bedrock een intern SaaS-platform kunt bouwen om toegang te krijgen tot basismodellen in een opstelling met meerdere tenants, met de nadruk op het bijhouden van kosten en gebruik, en het beperken van limieten voor elke tenant. Bijkomende onderwerpen om te verkennen zijn onder meer het integreren van bestaande authenticatie- en autorisatieoplossingen in de organisatie, het verbeteren van de API-laag met websockets voor bidirectionele client-serverinteracties, het toevoegen van contentfiltering en andere beheerbeveiligingen, het ontwerpen van meerdere implementatielagen en het integreren van andere microservices in de SaaS architectuur, en nog veel meer.

De volledige code voor deze oplossing is beschikbaar in de GitHub-repository.

Raadpleeg voor meer informatie over op SaaS gebaseerde raamwerken SaaS Journey Framework: een nieuwe SaaS-oplossing bouwen op AWS.


Over de auteurs

Hassan Poonawala is een Senior AI/ML Specialist Solutions Architect bij AWS en werkt met klanten uit de gezondheidszorg en life sciences. Hasan helpt bij het ontwerpen, implementeren en schalen van generatieve AI- en machine learning-applicaties op AWS. Hij heeft meer dan 15 jaar gecombineerde werkervaring in machine learning, softwareontwikkeling en data science in de cloud. In zijn vrije tijd houdt Hasan ervan om de natuur te verkennen en tijd door te brengen met vrienden en familie.

Anastasia Tzeveleka is een Senior AI/ML Specialist Solutions Architect bij AWS. Als onderdeel van haar werk helpt ze klanten in EMEA bij het bouwen van basismodellen en het creëren van schaalbare generatieve AI- en machine learning-oplossingen met behulp van AWS-services.

Brugeen Pistone is een Genative AI en ML Specialist Solutions Architect voor AWS, gevestigd in Milaan. Hij werkt met grote klanten en helpt hen hun technische behoeften diepgaand te begrijpen en AI- en Machine Learning-oplossingen te ontwerpen die optimaal gebruik maken van de AWS Cloud en de Amazon Machine Learning-stack. Zijn expertise omvat onder meer: ​​machine learning van begin tot eind, machine learning-industrialisatie en generatieve AI. Hij brengt graag tijd door met zijn vrienden en ontdekt graag nieuwe plaatsen, maar ook reist hij graag naar nieuwe bestemmingen.

Vikesh Pandey is een Genative AI/ML Solutions-architect, gespecialiseerd in financiële dienstverlening, waarbij hij financiële klanten helpt bij het bouwen en schalen van Genative AI/ML-platforms en -oplossingen die kunnen worden geschaald naar honderden tot zelfs duizenden gebruikers. In zijn vrije tijd schrijft Vikesh graag op verschillende blogforums en bouwt hij samen met zijn kind Lego.

spot_img

Laatste intelligentie

spot_img