Belső SaaS-szolgáltatás létrehozása az Amazon Bedrock | alapmodelljeinek költség- és használati nyomon követésével Amazon webszolgáltatások

A vállalatok arra törekszenek, hogy gyorsan kiaknázzák a generatív AI-ban rejlő lehetőségeket azáltal, hogy hozzáférést biztosítanak az alapmodellekhez (FM-ekhez) a különböző üzletágak (LOB) számára. Az informatikai csapatok felelősek azért, hogy segítsék a LOB-ot a gyorsaságban és agilitásban, miközben központi irányítást és megfigyelhetőséget biztosítanak. Előfordulhat például, hogy nyomon kell követniük az FM-használatot a csapatok között, a visszaterhelési költségeket, és biztosítaniuk kell a megfelelő költséghely láthatóságát a LOB-ban. Ezenkívül előfordulhat, hogy csapatonként szabályozniuk kell a különböző modellekhez való hozzáférést. Például, ha csak bizonyos FM-ek engedélyezettek a használatra.

Amazon alapkőzet egy teljes körűen felügyelt szolgáltatás, amely egyetlen API-n keresztül a vezető mesterségesintelligencia-cégek, például az AI21 Labs, az Anthropic, a Cohere, a Meta, a Stability AI és az Amazon nagy teljesítményű alapmodelljeit kínálja, valamint a generatív mesterséges intelligencia felépítéséhez szükséges lehetőségek széles skáláját. biztonságot, adatvédelmet és felelős AI-t biztosító alkalmazások. Mivel az Amazon Bedrock szerver nélküli, nem kell semmilyen infrastruktúrát felügyelnie, és biztonságosan integrálhatja és telepítheti a generatív AI-képességeket alkalmazásaiba a már jól ismert AWS-szolgáltatások segítségével.

A szoftver, mint szolgáltatás (SaaS) réteg az alapozási modellekhez egyszerű és konzisztens felületet biztosíthat a végfelhasználók számára, miközben fenntartja a hozzáférés és a fogyasztás központi irányítását. Az API-átjárók laza kapcsolatot biztosíthatnak a modellfogyasztók és a modellvégpont-szolgáltatás között, valamint rugalmasságot biztosítanak a változó modellekhez, architektúrákhoz és hívási módszerekhez való alkalmazkodáshoz.

Ebben a bejegyzésben bemutatjuk, hogyan építhet fel belső SaaS-réteget az Amazon Bedrock alapmodelljeinek eléréséhez több bérlős (csapat) architektúrában. Kifejezetten a bérlőnkénti használat és költségkövetésre, valamint az olyan vezérlőkre összpontosítunk, mint a bérlőnkénti használat korlátozása. Leírjuk, hogy a megoldás és az Amazon Bedrock fogyasztási tervek hogyan illeszkednek az általános SaaS utazási keretrendszerhez. A megoldás kódja és egy AWS Cloud Development Kit (AWS CDK) sablon elérhető a GitHub tárház.

Kihívások

Az AI platform rendszergazdájának szabványos és egyszerű hozzáférést kell biztosítania az FM-ekhez több fejlesztőcsapat számára.

Íme néhány kihívás az alapítványi modellekhez való szabályozott hozzáférés biztosításával kapcsolatban:

• Költség és felhasználás nyomon követése – Kövesse nyomon és auditálja az egyes bérlői költségeket és az alapítványi modellek használatát, és biztosítson visszatérítési költségeket meghatározott költséghelyek számára
• Költségvetési és felhasználási vezérlők – Az API-kvóták, a költségvetés és a használati korlátok kezelése az alapmodellek engedélyezett használatához bérlőnként meghatározott gyakorisággal
• Hozzáférés-szabályozás és modellirányítás – Határozzon meg hozzáférés-vezérlést bérlőnként meghatározott engedélyezett modellekhez
• Több bérlős szabványosított API – Konzisztens hozzáférést biztosít az alapozó modellekhez OpenAPI szabványok
• Az API központosított kezelése – Egyetlen réteg biztosítása a modellekhez való hozzáféréshez szükséges API-kulcsok kezeléséhez
• Modell verziók és frissítések – Kezelje az új és frissített modellverziók bevezetését

Megoldás áttekintése

Ebben a megoldásban hivatkozunk a több bérlő megközelítés. A bérlő Ez egy egyéni felhasználótól, egy adott projekttől, csapattól vagy akár egy egész részlegtől is terjedhet. Amikor a megközelítésről beszélünk, a kifejezést használjuk csapat, mert ez a leggyakoribb. API-kulcsokat használunk a csapatok API-hozzáférésének korlátozására és figyelésére. Minden csapat hozzá van rendelve egy API-kulcshoz az FM-ekhez való hozzáféréshez. Egy szervezetben különböző felhasználói hitelesítési és engedélyezési mechanizmusok lehetnek telepítve. Az egyszerűség kedvéért ezeket nem foglaljuk bele ebbe a megoldásba. Ezzel a megoldással integrálhatja a meglévő identitásszolgáltatókat is.

Az alábbi diagram összefoglalja a megoldás architektúráját és a legfontosabb összetevőket. A külön költséghelyekhez rendelt csapatok (bérlők) egy API-szolgáltatáson keresztül fogyasztják az Amazon Bedrock FM-eket. A fogyasztás és a csapatonkénti költség nyomon követése érdekében a megoldás naplózza az egyes hívások adatait, beleértve a meghívott modellt, a szöveggenerálási modellek tokenek számát és a multimodális modellek képméreteit. Ezenkívül modellenként összesíti a kéréseket és az egyes csapatok költségeit.

A megoldást saját fiókjában telepítheti az AWS CDK használatával. Az AWS CDK egy nyílt forráskódú szoftverfejlesztő keretrendszer a felhőalkalmazások erőforrásainak modellezésére és biztosítására az ismert programozási nyelvek használatával. Az AWS CDK kód elérhető a GitHub tárház.

A következő részekben a megoldás kulcsfontosságú összetevőit tárgyaljuk részletesebben.

Az alapozó modell használatának rögzítése csapatonként

A csapatonkénti FM-használat rögzítésére szolgáló munkafolyamat a következő lépésekből áll (az előző diagram számozása szerint):

1. Egy csapat jelentkezése POST kérést küld a címre Amazon API átjáró a meghívandó modellel a model_id lekérdezési paramétert és a felhasználói promptot a kérelem törzsében.
2. Az API Gateway a kérést egy AWS Lambda függvény (bedrock_invoke_model), amely a csapathasználati információk naplózásáért felelős amazonfelhőóra és az Amazon Bedrock modelljének megidézése.
3. Az Amazon Bedrock egy VPC-végpontot biztosít, amelyet a AWS PrivateLink. Ebben a megoldásban a Lambda funkció elküldi a kérést az Amazon Bedrock-nak a PrivateLink használatával, hogy privát kapcsolatot létesítsen a fiókjában lévő VPC és az Amazon Bedrock szolgáltatásfiók között. Ha többet szeretne megtudni a PrivateLinkről, lásd: Az AWS PrivateLink használatával állítsa be az Amazon Bedrock privát hozzáférését.
4. Az Amazon Bedrock invokációja után Amazon CloudTrail generál a CloudTrail esemény.
5. Ha az Amazon Bedrock hívás sikeres, a Lambda függvény a következő információkat naplózza a meghívott modell típusától függően, és visszaküldi a generált választ az alkalmazásnak:
   • team_id – A kérelmet kibocsátó csapat egyedi azonosítója.
   • requestId – A kérelem egyedi azonosítója.
   • model_id – A meghívandó modell azonosítója.
   • inputTokens – A prompt részeként a modellnek küldött tokenek száma (szöveggeneráló és beágyazási modelleknél).
   • outputTokens – A modell által generálandó tokenek maximális száma (szöveggeneráló modelleknél).
   • magasság – A kért kép magassága (multimodális modelleknél és multimodális beágyazású modelleknél).
   • szélesség – A kért kép szélessége (csak multimodális modelleknél).
   • lépések – A kért lépések (stabilitási AI modelleknél).

Nyomon követési költségek csapatonként

Egy másik folyamat összesíti a használati információkat, majd naponta kiszámítja és megtakarítja a csapatonkénti igény szerinti költségeket. Külön folyamattal biztosítjuk, hogy a költségkövetés ne befolyásolja a modellhívási folyamat várakozási idejét és átviteli sebességét. A munkafolyamat lépései a következők:

1. An Amazon EventBridge szabály aktivál egy lambda függvényt (bedrock_cost_tracking) napi.
2. A Lambda funkció beszerzi a CloudWatch előző napi használati adatait, kiszámítja a kapcsolódó költségeket, és tárolja az összesített adatokat. team_id és a model_id in Amazon egyszerű tárolási szolgáltatás (Amazon S3) CSV formátumban.

Az Amazon S3-ban tárolt adatok lekérdezéséhez és megjelenítéséhez különböző lehetőségek állnak rendelkezésre, többek között S3 Válassza kiés Amazon Athena és Amazon QuickSight.

A használat ellenőrzése csapatonként

A használati terv meghatározza, hogy ki férhet hozzá egy vagy több telepített API-hoz, és opcionálisan beállítja a kérések célarányát a kérések korlátozásának megkezdéséhez. A terv API-kulcsokat használ az API-ügyfelek azonosítására, akik hozzáférhetnek a társított API-hoz az egyes kulcsokhoz. Használhatja az API-átjárót használati terveket az előre meghatározott küszöbértékeket meghaladó kérések visszaszorítására. Használhatod is API kulcsok és kvótakorlátok, amelyek lehetővé teszik, hogy beállítsa az API-kulcsonkénti kérelmek maximális számát, amelyet az egyes csapatok adott időintervallumon belül kiadhatnak. Ez amellett Amazon Bedrock szolgáltatási kvóták amelyek csak fiókszinten vannak hozzárendelve.

Előfeltételek

A megoldás üzembe helyezése előtt győződjön meg arról, hogy rendelkezik a következőkkel:

Telepítse az AWS CDK-vermet

Kövesse a README a GitHub-tárhely fájlját az AWS CDK-verem konfigurálásához és üzembe helyezéséhez.

A verem a következő erőforrásokat telepíti:

• Privát hálózati környezet (VPC, privát alhálózatok, biztonsági csoport)
• IAM szerepkör a modellelérés vezérléséhez
• Lambda rétegek a szükséges Python modulokhoz
• Lambda funkció invoke_model
• Lambda funkció list_foundation_models
• Lambda funkció cost_tracking
• Rest API (API átjáró)
• API-átjáró használati terv
• A használati tervhez társított API-kulcs

Egy új csapat fedélzetére

Az új csapatok hozzáférésének biztosításához megoszthatja ugyanazt az API-kulcsot a különböző csapatok között, és nyomon követheti a modellfogyasztást egy másik team_id az API-híváshoz, vagy hozzon létre dedikált API-kulcsokat az Amazon Bedrock erőforrásainak eléréséhez a README.

A verem a következő erőforrásokat telepíti:

• A korábban létrehozott REST API-hoz társított API-átjáró használati terv
• Az új csapat használati tervéhez társított API-kulcs, fenntartott szabályozási és sorozat-konfigurációkkal az API-hoz

Az API-átjáró szabályozási és sorozat-konfigurációival kapcsolatos további információkért lásd: Throttle API kérések a jobb átvitel érdekében.

A verem üzembe helyezése után láthatja, hogy az új API-kulcs a következőhöz team-2 létre is jön.

Konfigurálja a modell hozzáférés-vezérlését

A platform adminisztrátora hozzáférést biztosíthat bizonyos alapozási modellekhez a Lambda funkcióhoz társított IAM-házirend szerkesztésével invoke_model Az

Az IAM engedélyek a fájlban vannak meghatározva setup/stack_constructs/iam.py. Lásd a következő kódot:

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)

Hívja fel a szolgáltatást

A megoldás üzembe helyezése után közvetlenül a kódból hívhatja meg a szolgáltatást. A következő

egy példa a Pythonban a invoke_model API szöveggeneráláshoz POST kéréssel:

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)

Kimenet: Az Amazon Bedrock egy belső technológiai platform, amelyet az Amazon fejlesztett ki számos szolgáltatásának és termékének működtetésére és működtetésére. Néhány fontos dolog a Bedrockról…

A következő egy másik példa Pythonban a invoke_model API beágyazás generálásához POST kéréssel:

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

Kimenet: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422 . 1.03125, 0.8515625 …

Az alapozó modellekhez való hozzáférés megtagadva

A következő egy példa Pythonban a invoke_model API szöveggeneráláshoz POST-kérésen keresztül, hozzáférés megtagadással:

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 (legutóbbi hívás utolsó):n Fájl ”/var/task/index.py”, 213. sor, lambda_handlern response = _invoke_text(bedrock_client, model_id, body, model_kwargs)n Fájl ”/var/task/index.py ”, 146. sor, _invoke_textn raise en Fájl ”/var/task/index.py”, 131. sor _invoke_textn response = bedrock_client.invoke_model(n File ”/opt/python/botocore/client.py”, 535. sor, in _api_calln return self._make_api_call(operation_name, kwargs)n File ”/opt/python/botocore/client.py”, 980. sor, a _make_api_calln raise error_class(parsed_response, operation_name)nbotocore.errorfactoryedAccceptioness:D Hiba történt (AccessDeniedException) az InvokeModel művelet meghívásakor: Az Ön fiókja nem jogosult az API-művelet meghívására.n”

Költségbecslési példa

Amikor az Amazon Bedrock modelleket igény szerinti árazással hívja meg, a teljes költséget a bemeneti és a kimeneti költségek összegeként számítják ki. A bemeneti költségek a modellnek küldött input tokenek számán, a kimeneti költségek pedig a generált tokeneken alapulnak. Az árak 1,000 bemeneti tokenre és 1,000 kimeneti tokenre vonatkoznak. További részletekért és a konkrét modellárakért lásd: Amazon Bedrock árképzés.

Nézzünk egy példát, ahol két csapat, a team1 és a team2 hozzáfér az Amazon Bedrockhoz a bejegyzésben található megoldáson keresztül. Az Amazon S3-ban egy nap alatt mentett használati és költségadatokat a következő táblázat mutatja.

Az oszlopok input_tokens és a output_tokens tárolja a teljes bemeneti és kimeneti tokeneket a modellhívások között modellenként és csapatonként, egy adott napon.

Az oszlopok input_cost és a output_cost tárolja a vonatkozó költségeket modellenként és csapatonként. Ezeket a következő képletekkel számítjuk ki:

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

Egy funkcionális több-bérlős kiszolgáló nélküli SaaS-környezet végpontok közötti nézete

Nézzük meg, hogyan nézhet ki egy végpontok között működő, több-bérlős kiszolgáló nélküli SaaS-környezet. A következő egy referencia architektúra diagram.

Ez az architektúra diagram a bejegyzésben korábban ismertetett korábbi architektúra diagram kicsinyített változata, ahol az előző architektúra diagram az egyik említett mikroszolgáltatás (alapmodell szolgáltatás) részleteit magyarázza. Ez a diagram elmagyarázza, hogy az alapmodell-szolgáltatáson kívül más összetevőket is tartalmaznia kell a több-bérlős SaaS-platformban egy működőképes és méretezhető platform megvalósításához.

Nézzük végig az építészet részleteit.

Bérlői pályázatok

A bérlői alkalmazások a környezettel kölcsönhatásba lépő előtér-alkalmazások. Itt több bérlőt mutatunk be, akik különböző helyi vagy AWS-környezetekből férnek hozzá. Az előtér-alkalmazások kibővíthetők egy regisztrációs oldallal, ahol az új bérlők regisztrálhatják magukat, valamint egy felügyeleti konzolt a SaaS szolgáltatási réteg rendszergazdái számára. Ha a bérlőalkalmazások egyéni logikát igényelnek, amely interakciót igényel a SaaS-környezettel, megvalósíthatják az alkalmazásadapter mikroszolgáltatásának specifikációit. Példahelyzet lehet egyéni engedélyezési logika hozzáadása a SaaS-környezet engedélyezési specifikációinak tiszteletben tartása mellett.

Közös szolgáltatások

A következők megosztott szolgáltatások:

• Bérlő- és felhasználókezelési szolgáltatások – Ezek a szolgáltatások felelősek a bérlők nyilvántartásáért és kezeléséért. Olyan átfogó funkcionalitást biztosítanak, amely elkülönül az alkalmazásszolgáltatásoktól, és megosztva az összes bérlő között.
• Alapítvány modell szolgáltatás – A bejegyzés elején ismertetett megoldás architektúra diagramja ezt a mikroszolgáltatást ábrázolja, ahol az API Gateway és a Lambda funkciók közötti interakció ennek a mikroszolgáltatásnak a hatókörén belül történik. Minden bérlő ezt a mikroszolgáltatást használja az Anthropic, az AI21, a Cohere, a Stability, a Meta és az Amazon alapmodelljeinek, valamint a finomhangolt modelleknek a meghívására. Ezenkívül rögzíti a használat nyomon követéséhez szükséges információkat a CloudWatch naplóiban.
• Költségkövető szolgáltatás – Ez a szolgáltatás nyomon követi az egyes bérlők költségeit és felhasználását. Ez a mikroszolgáltatás ütemezetten fut, hogy lekérdezze a CloudWatch naplókat, és kiadja az összesített használati nyomon követést és a kikövetkeztetett költségeket az adattárolónak. A költségkövetési szolgáltatás kiterjeszthető további jelentések és vizualizációk készítésére.

Alkalmazásadapter szolgáltatás

Ez a szolgáltatás olyan specifikációkat és API-kat tartalmaz, amelyeket a bérlő implementálhat egyéni logikájának a SaaS-környezetbe való integrálása érdekében. Attól függően, hogy mennyi egyéni integrációra van szükség, ez az összetevő opcionális lehet a bérlők számára.

Több bérlős adattár

A megosztott szolgáltatások egy adattárban tárolják az adataikat, amely egyetlen megosztott lehet Amazon DynamoDB táblázat egy bérlői particionálási kulccsal, amely DynamoDB-elemeket társít az egyes bérlőkkel. A költségkövető megosztott szolgáltatás az összesített használati és költségkövetési adatokat adja ki az Amazon S3-nak. A használati eset alapján lehet alkalmazás-specifikus adattár is.

A több bérlős SaaS-környezet sokkal több összetevőt tartalmazhat. További információkért lásd: Több-bérlős SaaS-megoldás felépítése AWS kiszolgáló nélküli szolgáltatások használatával.

Több telepítési modell támogatása

A SaaS-keretrendszerek általában két üzembe helyezési modellt vázolnak fel: a készletet és a silót. A poolmodell esetében minden bérlő hozzáfér az FM-ekhez egy megosztott környezetből, közös tárolási és számítási infrastruktúrával. A silómodellben minden bérlőnek saját, dedikált erőforráskészlete van. Az izolációs modellekről a SaaS bérlői elkülönítési stratégiák fehér könyve.

A javasolt megoldás mindkét SaaS-telepítési modellhez alkalmazható. A pool megközelítésben egy központosított AWS-környezet tárolja az API-t, a tárolást és a számítási erőforrásokat. Siló módban minden csapat hozzáfér az API-khoz, a tároláshoz és a számítási erőforrásokhoz egy dedikált AWS-környezetben.

A megoldás az Amazon Bedrock által biztosított fogyasztási tervekhez is illeszkedik. Az AWS két fogyasztási terv közül választhat a következtetésekhez:

• Igény szerint – Ez a mód lehetővé teszi, hogy felosztó-kirovó alapon használjon alapozási modelleket anélkül, hogy időalapú határidős kötelezettségeket kellene vállalnia.
• Biztosított áteresztőképesség – Ez a mód lehetővé teszi, hogy elegendő átviteli sebességet biztosítson az alkalmazás teljesítménykövetelményeinek teljesítéséhez, cserébe egy időalapú lekötésért

Ezekről a lehetőségekről további információért lásd: Amazon Bedrock árképzés.

Az ebben a bejegyzésben ismertetett kiszolgáló nélküli SaaS-referenciamegoldás alkalmazhatja az Amazon Bedrock fogyasztási terveket, hogy alapvető és prémium szintű rétegezési lehetőségeket biztosítson a végfelhasználók számára. Az alapszint magában foglalhatja az Amazon Bedrock igény szerinti vagy biztosított áteresztőképességű fogyasztását, és tartalmazhat konkrét felhasználási és költségvetési korlátokat. A bérlői korlátok engedélyezhetők a kérelmek kérelmek, tokenméretek vagy költségvetés-elosztás alapján történő korlátozásával. A prémium szintű bérlők saját, dedikált erőforrásokkal rendelkezhetnek az Amazon Bedrock által biztosított átviteli fogyasztás mellett. Ezek a bérlők általában olyan termelési munkaterhelésekhez kapcsolódnak, amelyek nagy átviteli sebességet és alacsony késleltetésű hozzáférést igényelnek az Amazon Bedrock FM-ekhez.

Következtetés

Ebben a bejegyzésben megvitattuk, hogyan építsünk fel egy belső SaaS-platformot az alapmodellek eléréséhez az Amazon Bedrock segítségével több bérlős beállításban, a költségek és a használat nyomon követésére, valamint az egyes bérlők korlátozására összpontosítva. További felfedezendő témakörök közé tartozik a meglévő hitelesítési és engedélyezési megoldások integrálása a szervezetbe, az API-réteg fejlesztése a kétirányú kliensszerver-interakciókhoz szükséges websocketekkel, tartalomszűrés és egyéb irányítási korlátok hozzáadása, több telepítési szint tervezése, más mikroszolgáltatások integrálása a SaaS-be. építészet, és még sok más.

A megoldás teljes kódja elérhető a GitHub tárház.

A SaaS-alapú keretrendszerekkel kapcsolatos további információkért lásd: SaaS Journey Framework: Új SaaS-megoldás készítése AWS-en.

A szerzőkről

Hasan Poonawala az AWS vezető AI/ML specialista megoldások építésze, egészségügyi és élettudományi ügyfelekkel dolgozik. A Hasan segít a generatív AI és gépi tanulási alkalmazások tervezésében, üzembe helyezésében és méretezésében az AWS-en. Több mint 15 éves kombinált munkatapasztalattal rendelkezik a gépi tanulás, a szoftverfejlesztés és a felhőalapú adattudomány területén. Szabadidejében Hasan szereti felfedezni a természetet, és időt tölt barátaival és családjával.

Anasztázia Tzeveleka az AWS vezető AI/ML-megoldások specialistája. Munkája részeként segít ügyfeleinek EMEA-szerte alapmodellek felépítésében, valamint méretezhető generatív AI és gépi tanulási megoldások létrehozásában az AWS-szolgáltatások segítségével.

Brunincs Pistone az AWS generatív AI és ML specialista megoldások építésze milánói székhelyű. Nagy ügyfelekkel dolgozik, segít nekik mélyen megérteni műszaki igényeiket, és olyan mesterséges intelligencia- és gépi tanulási megoldásokat tervezni, amelyek a lehető legjobban használják ki az AWS felhőt és az Amazon Machine Learning veremét. Szakértelme a következők: gépi tanulás végpontokig, gépi tanulási iparosítás és generatív AI. Szívesen tölt időt barátaival és új helyeket fedez fel, valamint új úti célokra utazik.

Vikesh Pandey a Generative AI/ML Solutions építésze, pénzügyi szolgáltatásokra szakosodott, ahol segít a pénzügyi ügyfeleknek generatív AI/ML platformok és megoldások felépítésében és méretezésében, amelyek több száztól akár több ezer felhasználóig terjedhetnek. Szabadidejében Vikesh szeret különféle blogfórumokon írni, és legókat építeni a gyerekével.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/