AWS prepojilo vlastné modely v SageMaker AI s agentmi v Bedrock AgentCore

Jeden workflow, tri odlišné modelové úlohy

AWS zverejnilo referenčnú architektúru, v ktorej agentická aplikácia kombinuje spravované modely z Amazon Bedrocku s modelom nasadeným na vlastnom real-time endpointe Amazon SageMaker AI. Nejde o nový model ani o nezávislý výkonnostný test. Hodnota postupu spočíva v ukážke, ako možno v jednom workflowe prevádzkovať heterogénne modely bez vytvorenia samostatného agentického rámca pre každý z nich. Tím si tak môže vyberať model podľa typu úlohy, ceny, požadovaného umiestnenia dát alebo potreby použiť vlastný či doladený checkpoint.

Demonštračná aplikácia má podobu osobného finančného asistenta s tromi rolami. Orchestrátor používa Claude Haiku 4.5, rozpoznáva zámer a odovzdáva požiadavku špecializovanému agentovi. Rozpočtový agent s Claude Sonnet 4.6 vytvára štruktúrované rozdelenie rozpočtu. Analýzu akcií a návrh portfólia zabezpečuje Qwen 3.5 9B, ktorý beží cez vLLM 0.22.1 na SageMaker inštancii ml.g6e.2xlarge s jednou kartou NVIDIA L40S a 48 GB pamäte. Ide o konkrétnu ukážkovú konfiguráciu, nie o všeobecné odporúčanie pre kapacitu alebo náklady.

Smerovanie je postavené na vzore „agents as tools“ vo frameworku Strands Agents. Orchestrátor vidí špecializovaných agentov ako nástroje a vyberá ich podľa požiadavky. Model v SageMakeri je sprístupnený cez OpenAI kompatibilné rozhranie, takže ho aplikácia pripája klientom AsyncOpenAI. Kompatibilita API však neznamená úplnú zameniteľnosť poskytovateľov: odlišné ostávajú autentifikácia, dostupné parametre, spôsob streamovania, telemetria aj prevádzkové limity.

Detaily, ktoré rozhodujú mimo prototypu

OpenAI kompatibilný endpoint SageMakeru v tomto príklade očakáva krátkodobý bearer token. Token vytvorený iba pri štarte aplikácie môže počas dlhej agentickej relácie vypršať, preto AWS používa vlastnú implementáciu httpx.Auth, ktorá pred požiadavkou vygeneruje aktuálne poverenie. Je to malý, ale podstatný rozdiel medzi notebookovou ukážkou a službou, ktorá spracúva dlhšie alebo viacstupňové úlohy. Príslušná rola zároveň potrebuje oprávnenia na vyvolanie endpointu a získanie tokenu; samotné OpenAI kompatibilné API neodstraňuje potrebu správne nastaveného IAM.

Ďalšou pascou je zdieľanie stavu. AWS odporúča pri každom vyvolaní nástroja vytvoriť čerstvú inštanciu špecializovaného agenta. Singleton môže pri súbežných požiadavkách spôsobiť konflikty alebo nechcené miešanie priebežného stavu. V produkčnom systéme preto nestačí overiť, že agent odpovedá jednému používateľovi. Potrebné sú testy paralelných behov, izolácie relácií, opakovaných pokusov po chybe a správania pri čiastočne dokončených nástrojových volaniach.

Architektúra môže uľahčiť aj ďalšie scenáre: nasadenie firemne doladeného checkpointu zo služby S3, A/B testovanie variantov alebo smerovanie podľa odhadovanej zložitosti. Jednoduchá požiadavka môže ísť na menší spravovaný model a výpočtovo náročná úloha na vyhradený GPU endpoint. Takéto rozhodovanie však musí vychádzať z reálnych meraní. Stále bežiaci SageMaker endpoint má vlastné náklady aj pri nižšom využití a viac modelových trás pridáva ďalšie miesta zlyhania.

Chýbajúce tokeny v telemetrii

Najdôležitejším doplnením oproti základnému opisu architektúry je spôsob merania. AgentCore podľa dokumentácie poskytuje metriky, stopy a logy v OpenTelemetry kompatibilnom formáte a v CloudWatch možno sledovať napríklad latenciu, chyby, počet relácií či tokeny. Automatická instrumentácia však v ukážke nepokrýva SageMaker endpoint pripojený cez OpenAIModel rovnako ako volania modelov v Bedrocku. Udalosti agenta a nástrojov môžu byť viditeľné, zatiaľ čo spotreba modelu Qwen v stope chýba.

AWS túto medzeru vypĺňa vlastným OpenTelemetry spanom okolo volania finančného agenta. Po dokončení načíta z výsledku Strands hodnoty vstupných, výstupných a celkových tokenov a pridá ich do stopy. Pri streamovaní treba navyše nastaviť stream_options s include_usage: true; inak vLLM štandardne neposkytne záverečný blok so spotrebou a zaznamenané počty môžu zostať nulové. Formálne prítomný span teda ešte nie je dôkazom, že systém meria všetko potrebné.

Samostatná dokumentácia OpenTelemetry potvrdzuje širší význam spoločných konvencií pre modelové a agentické operácie, zároveň ich však označuje ako rozpracované. Aktuálne konvencie rozlišujú napríklad vyvolanie modelu, agenta, workflowu, plánovanie či vykonanie nástroja. Tímy by preto nemali napevno predpokladať, že dnešné názvy atribútov ostanú bez zmien. Telemetrickú vrstvu je vhodné verzovať, testovať pri aktualizácii knižníc a oddeliť od obchodnej logiky aplikácie.

Európsky kontext a hranice ukážky

Pre slovenské a európske firmy je spoločná stopa užitočná nielen pri kontrole ceny. Pomáha spätne určiť, ktorý agent, model a nástroj spracoval konkrétnu požiadavku, kde vzniklo oneskorenie a ktorá vetva zlyhala. To podporuje interné audity a správu rizík, samo osebe však nezabezpečuje súlad s európskymi pravidlami. Pri systémoch nasadených v regulovaných oblastiach treba rozsah záznamov odvodiť od konkrétneho použitia, rolí organizácie a citlivosti spracúvaných údajov.

OpenTelemetry výslovne upozorňuje, že pokyny, vstupy a výstupy môžu obsahovať veľké alebo citlivé dáta a nemajú sa štandardne zaznamenávať bez vedomého zapnutia. Pre organizácie pracujúce s osobnými údajmi to znamená oddeliť technické metriky od obsahu promptov, nastaviť retenčné lehoty, prístupové práva a prípadnú redakciu citlivých údajov. Počet tokenov či identifikátor modelu možno často uchovať bez uloženia celej konverzácie. Detailnejšia observability preto nemusí znamenať plošné kopírovanie používateľských vstupov do logov.

Zverejnený postup napokon nie je benchmarkom kvality smerovania, bezpečnosti ani celkových nákladov. AWS neporovnáva túto zostavu s jednoduchším systémom využívajúcim jeden model a neuvádza produkčnú priepustnosť, dostupnosť či výsledky záťažových testov. Ukážka je napriek tomu praktická, pretože pomenúva problémy, ktoré sa v prezentáciách viacagentových systémov často strácajú: expiráciu poverení, izoláciu súbežných behov, neúplnú telemetriu a nulové údaje o spotrebe pri streamovaní. Pred nasadením zostáva potrebné zmerať ekonomiku GPU endpointu, kvalitu rozhodovania orchestrátora, ochranu dát a správanie celej zostavy pri výpadku jednej z modelových trás.