Drei Modelle, ein Workflow: Wie SageMaker AI und Bedrock AgentCore zusammenspielen

Modellmix als Businessproblem, nicht als Buzzword

Ein Agentensystem braucht angeblich ein einziges großes Foundation-Modell, das Orchestrierung, Fachlogik und teure Spezialaufgaben gleichermaßen abdeckt – dieser Mythos hält sich hartnäckig, weil er die Architektur scheinbar vereinfacht und Einkauf wie Governance auf einen Anbieter reduziert. AWS widerlegt ihn im eigenen Referenzbeispiel unmissverständlich: Ein häufiges Problem beim Bau von Agentenworkflows ist es, verwaltete Foundation-Modelle mit eigenen, kostenoptimierten oder domänenspezifischen Modellen zu kombinieren, ohne das Agentenframework dafür jedes Mal neu zu schreiben. Genau das zeigt AWS in einem aktuellen Technik-Blogpost zu SageMaker AI und Bedrock AgentCore, indem es OpenAI-kompatible Endpunkte auf Amazon SageMaker AI mit der AgentCore Runtime von Amazon Bedrock verbindet.

Das Ergebnis ist kein Architekturdiagramm zur Zierde, sondern ein lauffähiges System, in dem spezialisierte Agenten an komplexen Aufgaben zusammenarbeiten und jeder das für seinen Job am besten geeignete Modell nutzt. Diese Kombination liefert Kostenoptimierung, Datenresidenz und Modellflexibilität in einer einzigen produktionsreifen Architektur – drei Ziele, die sich mit einem einzelnen Modell nicht gleichzeitig erreichen lassen, weil jedes davon unterschiedliche Kompromisse zwischen Latenz, Hosting-Ort und Rechenkosten verlangt. Wer ausschließlich auf ein verwaltetes Flaggschiff-Modell setzt, zahlt für Fälle, die ein kleineres, selbst gehostetes Modell günstiger und mit mehr Kontrolle über die Datenlage lösen könnte.

Für Sie heißt das: Wenn eine Ausschreibung oder ein interner Architekturvorschlag verspricht, ein Modell decke „alle Agentenaufgaben“ ab, lohnt sich der Blick auf genau diesen AWS-Beleg als Gegenprobe. Die praktische Frage ist nicht, ob Modellmix möglich ist, sondern welche drei bis vier Aufgabenklassen in Ihrem eigenen Workflow tatsächlich unterschiedliche Modelle rechtfertigen – und welche davon Sie testen können, bevor Sie sich auf eine feste Architektur festlegen.

Die Architektur: drei Modellpfade in einem AgentCore-Container

Die Architektur verbindet drei Modell-Hosting-Pfade über einen einzigen Amazon-Bedrock-AgentCore-Container: Ein Orchestrator-Agent auf Basis von Claude Haiku 4.5 auf Bedrock klassifiziert die Nutzerabsicht und leitet Aufgaben über eine globale, regionsübergreifende Inferenz weiter. Ein Budget-Agent mit Claude Sonnet 4.6 auf Bedrock berechnet 50/30/20-Budgetaufteilungen mit strukturierter Pydantic-Ausgabe. Ein Finanzanalyse-Agent setzt dagegen auf Qwen 3.5 9B, gehostet auf Amazon SageMaker AI, und übernimmt Aktienanalyse sowie Portfolio-Konstruktion über Tool-Calling.

Diese Aufteilung ist kein Zufall: Die Routing-Aufgabe braucht Geschwindigkeit und Verfügbarkeit über Regionen hinweg, die Budgetlogik braucht verlässliche strukturierte Ausgabe für nachgelagerte Systeme, und die Finanzanalyse braucht ein Modell, das sich mit eigenen Daten feinabstimmen und günstiger betreiben lässt als ein verwaltetes Flaggschiff-Modell. Eine Nutzeranfrage läuft dabei zuerst in den Orchestrator-Agenten innerhalb der AgentCore Runtime, wird von dort an den passenden Spezialisten weitergegeben und die Antwort läuft anschließend über den Orchestrator zurück an die Person, die die Anfrage gestellt hat.

Ein Punkt, den Sie vor jeder Region-Entscheidung prüfen sollten: Die Modellverfügbarkeit auf Amazon Bedrock unterscheidet sich je AWS-Region, was AWS selbst mit einem Verweis auf die eigene Region-Übersicht für Bedrock-Modelle unterstreicht. Wer ein Deployment in einer Region plant, in der Claude Haiku 4.5 oder Claude Sonnet 4.6 nicht verfügbar sind, muss die Orchestrierungsschicht entsprechend anpassen, bevor überhaupt ein einziger Testlauf startet.

Bearer-Token und frische Agenteninstanzen: Der Preis der Integration

So elegant der Architekturplan aussieht, die OpenAI-kompatible API von SageMaker AI verlangt einen Bearer-Token, und dieser Token läuft ab. Für jede länger laufende Agenten-Session brauchen Sie deshalb einen Mechanismus, der den Token bei jeder Anfrage automatisch erneuert – im Referenzcode gelöst über eine eigene httpx.Auth-Unterklasse, die den Token nachzieht, bevor die Anfrage überhaupt abgeschickt wird. Ohne diesen Baustein läuft jede Session, die länger als die Token-Gültigkeit dauert, schlicht in einen Authentifizierungsfehler.

Der zweite Reibungspunkt betrifft die Agenteninstanzen selbst: Der Aufbau nutzt frische Agenteninstanzen pro Aufruf statt eines wiederverwendeten Singletons. Das ist mehr als Stilfrage. Singleton-Agenten führen bei gleichzeitigen Anfragen zu Konflikten bei nebenläufigen Aufrufen – ein Detail, das in Lastszenarien mit mehreren parallelen Nutzeranfragen schnell zum echten Produktionsproblem wird, aber in Demo-Notebooks fast nie auffällt, weil dort ohnehin nur eine Anfrage zur Zeit läuft.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptAn operator hand swaps one specialized ceramic model piece at a neutral connector while the surrounding braided workflow remains intact and physically continuous. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Spezialisierte Agenten teilen sich einen Ablauf

Der Orchestrator nutzt das Agents-as-Tools-Muster von Strands Agents, um eine eingehende Anfrage entweder an den Budget-Agenten oder an den Finanzanalyse-Agenten weiterzuleiten. Beide spezialisierten Agenten rufen dabei ihr jeweiliges Modell auf: Der Budget-Agent spricht Claude Sonnet 4.6 über Amazon Bedrock an, der Finanzanalyse-Agent spricht Qwen 3.5 9B über einen SageMaker-AI-Echtzeitendpunkt mit der OpenAI-kompatiblen API an. Die Ergebnisse laufen zurück durch den Orchestrator zur Nutzerin oder zum Nutzer.

Genau an dieser Stelle zeigt sich der eigentliche Witz des Musters: Sie tauschen ein einzelnes Modellteil aus, ohne den restlichen Ablauf anzufassen. Der Orchestrator kennt keine Details darüber, ob ein Werkzeug Bedrock oder SageMaker im Hintergrund aufruft – für ihn ist die Finanzanalyse-Funktion einfach ein Werkzeug mit einer definierten Signatur. Wollen Sie das Qwen-Modell später durch ein anderes, feinabgestimmtes Modell ersetzen, ändert sich an Authentifizierungsschicht, Telemetrie und AgentCore-Deployment nichts – nur der Verweis auf den neuen Checkpoint in Amazon S3 muss angepasst werden.

Das ist der belegbare Unterschied zwischen einem echten Baukasten und einem Architekturposter: Die Kopplung zwischen Agenten läuft über Funktionssignaturen, nicht über Modell-Identität. Wer diesen Unterschied ignoriert, baut sich bei jedem Modellwechsel eine neue Integrationsbaustelle, statt einen Parameter zu tauschen.

Die blinde Stelle: Warum Token-Verbrauch bei SageMaker unsichtbar bleibt

Amazon Bedrock AgentCore Runtime instrumentiert Agenten automatisch mit OpenTelemetry – das klingt nach vollständiger Observability out of the box. Die Realität hat eine Lücke: Amazon-Bedrock-Modellaufrufe erhalten automatisch vollständige Generative-AI-Spans mit Tokenzahlen, ohne zusätzlichen Aufwand. Amazon-SageMaker-OpenAI-kompatible-Endpunkte über den entsprechenden Strands-Modellprovider bekommen dagegen keine automatische Token-Telemetrie – die Instrumentierung erkennt sie schlicht nicht als Generative-AI-Aufrufe.

Die Ursache liegt tiefer als ein fehlendes Feature: Die OpenTelemetry-Integration von Strands sendet Spans für Tool-Aufrufe und den Agenten-Lebenszyklus, aber keine Chat-Spans mit Token-Attributen für diesen speziellen Modellprovider. Die Auto-Instrumentierung von AgentCore erkennt ausschließlich Bedrock-Modellaufrufe, die über boto3 laufen, als Generative-AI-Operationen. Für Sie bedeutet das: Tokens, die der Finanzanalyse-Agent beim Aufruf von Qwen 3.5 9B auf SageMaker verbraucht, sind in den Traces vollständig unsichtbar. Sie können weder Kosten überwachen noch Regressionen erkennen noch Latenz debuggen – ausgerechnet bei dem Modellpfad, der am ehesten kostenoptimiert betrieben werden soll und dessen Kosten Sie eigentlich am genauesten kennen wollen.

Der Fix: eigene Telemetrie-Spans und die Streaming-Falle

Die Lösung ist ein manuell erzeugter Chat-Span, der den SageMaker-Agentenaufruf umschließt und die Tokenzahlen aus dem internen Nutzungsfeld der Strands-Agentenmetriken extrahiert. Im Beispieltrace aus dem Blogpost liefert dieser Span konkrete Zahlen: 1.391 Input-Tokens, 1.432 Output-Tokens, insgesamt 2.823 Tokens bei einer Laufzeit von rund 37 Sekunden für einen einzelnen Finanzanalyse-Aufruf.

Ohne eine zusätzliche Einstellung bleiben diese Zahlen bei null: Standardmäßig liefert vLLM in Streaming-Antworten keinen Nutzungs-Chunk mit. Strands erhält Textstücke, aber niemals ein finales Nutzungsobjekt. Erst ein zusätzlicher Streaming-Parameter zwingt vLLM, am Ende einen Chunk mit den Tokenzahlen zu senden – fehlt diese eine Einstellung, melden Ihre eigenen Spans stur null Tokens, und der ganze Aufwand für die manuelle Instrumentierung war umsonst.

Ein zweiter Stolperstein liegt außerhalb des Codes: Die Standard-Sampling-Rate von AWS X-Ray verwirft die meisten Traces, weil sie bei einem Prozent liegt. Für belastbare Beobachtungen während der Entwicklungsphase müssen Sie diese Rate manuell auf 100 Prozent setzen – sonst fehlen Ihnen ausgerechnet die Traces, die Sie zur Fehlersuche brauchen, weil der Zufall neun von zehn Anfragen aus der Stichprobe wirft, bevor Sie überhaupt ein Muster erkennen können.

Aufräumen und Kostenkontrolle als Teil der Architektur, nicht als Nachgedanke

AWS beendet die eigene Anleitung nicht mit dem fertigen Trace, sondern mit einem Abschnitt zum Aufräumen: Um künftige Kosten zu vermeiden, sollen die Ressourcen gelöscht werden – konkret die AgentCore-Runtime, der SageMaker-Endpunkt, die Endpunktkonfiguration und das Modell selbst. Diese vier Löschschritte sind unspektakulär, aber sie sind der Beleg dafür, dass eine GPU-Instanz mit 48 GB VRAM eben nicht kostenlos im Hintergrund weiterläuft, nur weil der Demo-Lauf vorbei ist.

Für Ihre eigene Planung bedeutet das: Ein SageMaker-Endpunkt mit eigenem Modell ist kein einmaliger Konfigurationsschritt, sondern eine laufende Kostenposition, die Sie aktiv gegen die verwaltete Bedrock-Alternative gegenrechnen müssen. Genau hier liegt der Unterschied zwischen einer Kostenoptimierung auf dem Papier und einer, die im Monatsabschluss auch tatsächlich sichtbar wird.

Was der Praxis-Report für Ihre Pilotentscheidung bedeutet

Bevor Sie das Muster übernehmen, klären Sie die Voraussetzungen: ein AWS-Konto mit Rechten für SageMaker AI, Bedrock und AgentCore, eine IAM-Rolle mit den passenden Endpunkt-Berechtigungen, Modellzugriff für Claude Haiku 4.5 und Claude Sonnet 4.6 sowie eine aktuelle Python-Version. Das Beispiel selbst läuft auf einer GPU-Instanz mit einer L40S-GPU und 48 GB VRAM für das Qwen-Modell – eine überschaubare, aber reale Kostenposition, die Sie gegen ein rein Bedrock-basiertes Setup gegenrechnen sollten.

Die AWS-Autoren nennen selbst drei Ausbaurichtungen: eigene feinabgestimmte Modell-Checkpoints aus S3 einspeisen, Basis- und Fine-Tuning-Varianten gegeneinander A/B-testen, und kostenbewusstes Routing, bei dem einfache Anfragen an Haiku auf Bedrock gehen, während der GPU-Endpunkt für mehrstufige Analyseaufgaben reserviert bleibt. Wie stark sich allgemein die Antwortzeit von Bedrock-Agenten drücken lässt, haben wir separat in unserer Analyse zur Latenzreduzierung bei Bedrock-Agenten aufgeschlüsselt – ein sinnvoller Anschlusspunkt, wenn Ihr Orchestrator-Pfad selbst zum Flaschenhals wird.

Was der Blogpost nicht liefert, ist eine unabhängige Preisrechnung oder ein Benchmark gegen Alternativen – das bleibt Ihre eigene Hausaufgabe vor einem Piloten. Wer im selben Agentenworkflow zusätzlich fremden Code ausführen lassen will, etwa für generierte Analyseskripte, findet in unserem Test des WASI-Sandboxmoduls für sicheres Codeausführen im Editor den nächsten Anschlusspunkt für die Sicherheitsfrage, die AWS in diesem Beitrag bewusst ausklammert. Der Modellmix-Mythos ist damit widerlegt, aber die Betriebsverantwortung bleibt bei Ihnen – nicht bei der Architekturfolie.