AWS lægger en brugbar opskrift frem på et praktisk problem: at blande managed foundation models med egne, billigere eller domænespecifikke modeller uden at ændre agentframeworket. I et nyt blogindlæg demonstreres, hvordan OpenAI-kompatible endpoints på Amazon SageMaker AI kan kobles med Amazon Bedrock AgentCore og Strands Agents, så flere agenter arbejder på tværs af hostingmiljøer. Arkitekturvalget er relevant for teams, der vil i drift med agenter uden at låse sig fast i én model eller ét miljø.
I praksis fordeler en orkestrator i Bedrock AgentCore brugerens forespørgsel til specialiserede agenter, hvor hver agent bruger den model, der passer til opgaven – uden at ramme frameworket. AWS peger på tre fordele ved kombinationen: prisoptimering, dataresidency og modelfleksibilitet. Det er forfatternes påstande, men mekanikken er logisk: man kan vælge mindre eller selv-hostede modeller, når en tung managed model ikke er nødvendig, og holde følsomme flows på eget endpoint.
Arkitekturen i eksemplet
Blogindlægget beskriver en tretrinsopsætning, der alle går gennem én Bedrock AgentCore-container. Orkestratoragenten kører med Claude Haiku 4.5 på Bedrock og klassificerer intent, inklusiv routing via Strands’ agents-as-tools-mønster. En budgetagent bruger Claude Sonnet 4.6 på Bedrock til at levere et 50\/30\/20-budget med struktureret Pydantic-output. Og en finansanalyseagent kører Qwen 3.5 9B som et SageMaker AI realtids-endpoint via en OpenAI-kompatibel API.
Flowet er: Anmodningen lander hos orkestratoren i AgentCore-runtime, den kalder enten budgetagenten eller finansagenten som et værktøj, og resultaterne returneres gennem orkestratoren. Strands Agents er frameworket, og Bedrock AgentCore leverer runtime og managed deployment. Kildekoden ligger i det tilhørende GitHub-repo, som blogindlægget henviser til.
Tekniske byggeklodser fra blogindlægget
Den praktiske kobling mellem SageMaker AI og Bedrock AgentCore står på fire ben. 1) SageMaker-endpointet eksponeres med en OpenAI-kompatibel API, der kræver bearer token. Tokens udløber, så auto-refresh pr. request skal håndteres ved længere sessioner. 2) Eksemplet deployer Qwen 3.5 9B via vLLM Deep Learning Container v0.22.1, Python 3.12 og CUDA 13.0, på en ml.g6e.2xlarge med én L40S GPU (48 GB VRAM).
3) AgentCore-runtime håndterer orkestreringslogik og lader agenter køre som værktøjer – også når værktøjet peger på et eksternt SageMaker-endpoint. 4) Blogindlægget understreger behovet for token-niveau observabilitet på SageMaker-siden, da Strands ikke leverer det ud af boksen. Det kræver ekstra instrumentering og er nødvendigt i produktion.
Hvorfor hybrid uden omskrivning er det centrale
Pointen er ikke endnu et multi-agent-diagram, men at agentframeworket bevares, når en agent ruter til enten en Bedrock-model eller en egenhostet SageMaker-model. Det sænker friktion i udviklingen og gør det realistisk at udskifte eller tilføje modeller uden at starte forfra. Der opnås en grad af praktisk vendor-agnosticitet, så pris og dataforhold kan vægtes mod kvalitet fra opgave til opgave.
Tradeoffet er driftsmæssigt: man driver både Bedrock-kald og egne endpoints. Gevinsten er mulighed for at flytte opgaver med lavere krav til en billigere 9B-model og reservere de tunge sprogopgaver til en Claude-variant.
Modelvalg og routing i eksemplet
Orkestratoren bruger Claude Haiku 4.5 til hurtig klassifikation, routing og samtalestyring. Budgetagenten kører Claude Sonnet 4.6, der i eksemplet leverer Pydantic-struktureret output til en 50\/30\/20-brydning, så downstream-systemer kan validere kontrakten uden at parse fri tekst. Finansagenten kører Qwen 3.5 9B på SageMaker AI til portefølje- og aktieanalyse, inklusiv tool-calling.
Tekniske konsekvenser: Latens påvirkes af kald på tværs af tjenester, netværkshop og modelstart. Omkostning: betaling per token på Bedrock-modellerne og per instans-time på SageMaker, plus eventuel egress. Data residency: følsomme dele kan blive på SageMaker-endpointet. AWS peger eksplicit på regionafhængighed for Bedrock-modeller, så tilgængelighed skal matche driftsregion.
SageMaker-deploymenten i detaljer
Blogindlægget giver en konkret opskrift: vLLM 0.22.1 GPU-image for us-west-2, model_id sat til Qwen\/Qwen3.5-9B, tensor parallel size 1, max model length 32768. Endpoints deployes på ml.g6e.2xlarge med en opstarts-timeout, og IAM-rollen skal have sagemaker:InvokeEndpoint og sagemaker:CallWithBearerToken. Det sidste er centralt, da OpenAI-kompatibiliteten bygger på bearer-flows. Små detaljer, men de vælter ofte første forsøg, hvis de mangler.
Derudover kræves Python 3.12 og installation af bl.a. sagemaker-core, openai, httpx, strands-agents[otel], yfinance, pydantic og bedrock-agentcore. Toolchainen er eksplicit, hvilket gør eksemplet reproducerbart uden gætterier.
Observabilitet og MLOps
Forfatterne viser, hvordan man får token-niveau logging ud af SageMaker-endpointet, netop fordi Strands ikke leverer det. Uden tokenlogning er det svært at styre latens pr. delopgave, stopgrunde og fejltilstande, når flere agenter skubber data frem og tilbage. Pydantic-struktureret output på budgetagenten gør validering, test og kontraktstyring mellem agenter enklere.
Governance uddybes ikke, men IAM-krav, regiontilgængelighed og modeladgange på Bedrock nævnes. Et driftsteam bør supplere med netværk i VPC, private endpoints samt kryptering i transit og at rest. Uden det bliver dataresidency mest intention, ikke garanti.
Tre praktiske tradeoffs du skal adressere
Omkostninger. Den påståede prisoptimering forudsætter aktiv routingpolitik og målinger. Blogindlægget giver ikke benchmarks for pris per token eller TCO. Indbyg derfor måling af: tokens per agent, GPU-udnyttelse på SageMaker, og hvor ofte orkestratoren kalder en dyr model uden merværdi. Ellers bliver hybrid blot ekstra drift uden besparelse.
Governance. Når en agent lover struktur via Pydantic, kan du lave kontrakttest og schema-versionering. Gør det, ellers knækker integrationer ved uventede modelskift. Involver sikkerhed i at definere tilladte værktøjer i Strands og begræns modelkald i IAM. Simpelt, men ofte overset.
Modelversioner. Bedrock-modeller kan opdateres bag kulisserne, mens et SageMaker-endpoint er under jeres kontrol. Den forskel kan overraske. Indfør canary-udrulning og A\/B i orkestratoren, hvor en andel af kald går til en ny modelversion, mens resten bliver på den stabile. Mål både kvalitet og latens.
Hvad blogindlægget ikke dækker
Der mangler tal: ingen latensmålinger, ingen throughput under belastning, ingen konkrete omkostningsbenchmarks. Det er forventeligt for et arkitekturindlæg, men produktion kræver målinger. Autoskalering på SageMaker med vLLM er heller ikke beskrevet: concurrency-grænser, warm pools, skaleringstid. Det bør testes tidligt.
Regionafhængighed nævnes uden detaljer. Tjek Bedrocks oversigt for modeltilgængelighed per region, før designet låses. Performance i heterogene setups kan svinge, især ved streaming og tool-calling på tværs af services. Til selvhostede modeller kan kvantisering af KV-cachen være relevant. Et eksternt perspektiv fremhæver, at valg af kvantiseringsakse kan ændre kvalitet markant ved samme bitpræcision. Det er ikke noget blogindlægget behandler, men det påvirker hostingvalg.
Tjekliste til et hurtigt proof of concept
Forudsætninger: adgang til Amazon Bedrock AgentCore, modeladgang til Claude Haiku 4.5 og Sonnet 4.6 i jeres region, en SageMaker-rolle med sagemaker:InvokeEndpoint og sagemaker:CallWithBearerToken samt kapacitet til en ml.g6e.2xlarge. Installer de nævnte Python-pakker og deploy Qwen 3.5 9B med vLLM 0.22.1. Verificer OpenAI-kompatible kald lokalt, før integration i Strands.
Test og målepunkter: lav A\/B-routing i orkestratoren mellem Bedrock og SageMaker på en kontrolleret opgave. Mål tid til første token, total latens, tokens ud\/ind, fejlrate og outputkvalitet mod en fast eval. Log tokenstrømme fra SageMaker og gem Pydantic-responser som kontraktlog. Sæt thresholds for rollback. Lav også en simpel prisoversigt per kald for jeres typiske flows – det synliggør hurtigt gevinsterne.
Implikationer for prioriteringer i arkitekturen
Hybrid-opsætningen giver handlefrihed, men kræver disciplin. Afgør tidligt hvor routinglogik bor, hvem der ejer modelgodkendelser, og hvordan versionsskift rulles ud. Budgettet flytter sig fra rene API-omkostninger til en blanding af instanspriser og forbrug. Governance bliver en løbende proces med kontrakter og audits, ikke en engangstjekliste.
Konkurrentperspektiv
Andre clouds adresserer samme behov. På Google Cloud kan Vertex AI Agents og Model Garden kobles med selvhostede endpoints. Azure tilbyder agenttjenester og hosting af egne modeller via Azure AI. I open source kan LangGraph og Ray levere lignende orkestrering på egne klynger. AWS adskiller sig her ved koblingen mellem Bedrock AgentCore som managed runtime og en OpenAI-kompatibel vej til SageMaker, understøttet af en officiel vLLM-DLC og fokus på token-observabilitet.
Konklusion
AWS-bloggens arkitektur viser en praktisk måde at mikse Bedrock-modeller med egne SageMaker-endpoints i et fælles agentflow uden at ændre frameworket. Styrken er fleksibilitet og en realistisk rute til prisstyring og dataresidency. Svagheden er, at produktion kræver ekstra arbejde med observabilitet, benchmarks og policy-baseret routing. Start småt, mål alt, og hold versionsstyring stramt. Resten er håndværk.
