Amazon Bedrock-Kosten senken: das Engineering-Playbook

On-Demand vs. Provisioned Throughput, Batch Inference, Modellauswahl und Token Caching – mit konkreten Zahlen.

TL;DR – Fünf Strategien, die in Summe 60–80 % Ersparnis bei Bedrock bringen:

1. Batch Inference für asynchrone Workloads → 50 % Rabatt, kein Qualitätsverlust
2. Prompt Caching für wiederkehrenden Kontext → 90 % günstiger bei gecachten Input-Tokens
3. Model Routing (günstige Modelle für einfache Aufgaben) → 40–70 % Kostensenkung
4. Benchmarking + LLM-as-a-judge, um zu belegen, dass günstigere Modelle gut genug sind
5. Observability (OTel + DoiT GenAI Intelligence), um Drift zu erkennen und Einsparungen dauerhaft abzusichern

Mit diesem Playbook haben wir einen Kunden von 40.000 $/Monat auf 18.000 $ gebracht. Details unten.

Ich leite das APAC-Engineering-Team bei DoiT. Im letzten Quartal hat mich ein Kunde aus dem Finanzdienstleistungssektor gebeten, seine Bedrock-Ausgaben zu prüfen. Er nutzte Claude Sonnet für alles – Ticket-Klassifizierung, Dokumentenextraktion, Kundenchats – und die Monatsrechnung war unbemerkt auf über 40.000 $ angewachsen. Zwei Wochen später lagen wir bei 18.000 $, ohne an der Ausgabequalität zu rütteln.

Genau dieses Playbook teile ich hier. Wenn Sie für die Bedrock-Kosten eines Engineering- oder Datenteams verantwortlich sind, sind das die Hebel, die Ihre Rechnung wirklich bewegen.

Die Kundenbeispiele in diesem Artikel sind verdichtete Muster aus mehreren Projekten – keine einzelnen Fallstudien.

Die zwei Preismodelle verstehen

Bedrock hat zwei Preismodelle, und ich habe in beide Richtungen teure Fehler gesehen. (Eine ausführliche Analyse, wie Bedrock-Pricing funktioniert – inklusive Fine-Tuning-Kosten, Token-Schätzung und Tagging-Strategien – finden Sie in Josh Palmers CloudOps-Leitfaden zum Bedrock-Pricing. Dieser Artikel konzentriert sich auf die Engineering-Entscheidungen, die die Rechnung senken.)

On-Demand-Pricing

Sie zahlen pro Token – Input und Output werden separat berechnet. Keine Verpflichtung, keine Mindestabnahme.

Das passt, wenn Ihre Nutzung schwankt, Sie noch experimentieren oder Ihre Monatsausgaben unter dem Crossover-Punkt liegen (mehr dazu unten).

Eine typische Stolperfalle: Output-Tokens kosten meist 3–5x mehr als Input-Tokens. Der erwähnte Finanzdienstleister hatte seine Kosten allein auf Basis der Input-Token-Preise kalkuliert und seine tatsächliche Rechnung damit um fast den Faktor 3 unterschätzt. Eine Aufgabe, die 1.000 Input-Tokens verbraucht, aber 2.000 Output-Tokens erzeugt, wird von den Output-Kosten dominiert. Rechnen Sie immer beide Seiten durch.

Provisioned Throughput

Sie kaufen Model Units stundenweise (oder mit 1- bzw. 6-Monats-Commitments). Eine Model Unit ist Bedrocks reservierter Kapazitätsblock – stellen Sie sich "eine Spur auf der Autobahn" vor, die Sie stündlich bezahlen, ob Sie sie nutzen oder nicht.

Das passt bei dauerhaften, vorhersehbaren Workloads, wenn Ihre Auslastung konstant über dem Crossover-Schwellenwert liegt und Sie garantierte Latenz brauchen.

Letztes Jahr habe ich mit einem Medienunternehmen gearbeitet, dessen Provisioned Throughput bei 15 % Auslastung lief. Während eines Lasttests eingerichtet, danach vergessen umzustellen – drei Monate lang Geld verbrannt, bevor es jemandem auffiel. Die Umstellung auf On-Demand war eine einzeilige Konfigurationsänderung und sparte sofort tausende Dollar. Provisioned Throughput mit niedriger Auslastung ist der teuerste Einzelfehler bei Bedrock.

Den Crossover-Punkt finden

Monatliche On-Demand-Kosten = (input_tokens × input_price) + (output_tokens × output_price)
Monatliche Provisioned-Kosten = model_units × hourly_rate × 730 hours

Für die meisten Modelle wird Provisioned ab etwa 60–70 % dauerhafter Auslastung einer Model Unit günstiger. Auf dem Wort "dauerhaft" liegt die ganze Last – schauen Sie nicht auf Spitzenwerte. Traffic, der den ganzen Tag bei rund 70 % liegt mit kleinen Spitzen, ist ein guter Kandidat; Traffic, der bei 10 % vor sich hin dümpelt und stündlich für fünf Minuten auf 100 % springt, ist es nicht.

Batch Inference: der übersehene 50-%-Rabatt

Das ist wahrscheinlich mein Lieblingsthema im Kundengespräch, weil die Reaktion immer dieselbe ist: "Moment, wir können einfach … die Hälfte zahlen?"

Genau. Bedrock berechnet Batch-Tokens für unterstützte Modelle mit ~50 % der On-Demand-Tarife. Gleiche Modelle, gleiche Qualität, halber Preis. (Stand jetzt – prüfen Sie die Pricing-Seite, bevor Sie eine Roadmap auf diese Zahl bauen.) Der Tradeoff: ein 24-Stunden-SLA ohne Streaming – Ihre Jobs landen in einer Queue und werden asynchron abgearbeitet.

Jeder Workload, der keine Echtzeit-Antwort braucht, kommt infrage: Support-Tickets kategorisieren, Dokumentenkorpora für RAG verarbeiten, Produktbeschreibungen generieren, Eval-Suites laufen lassen, strukturierte Daten aus unstrukturierten Dokumenten ziehen. Meine Schätzung: Bei den meisten Teams lassen sich 30–40 % des Bedrock-Workloads ohne nutzerseitige Auswirkung in den Batch-Modus verschieben.

Konkret sieht das so aus: 10.000 Anfragen mit durchschnittlich 500 Input-Tokens und 200 Output-Tokens, mit Claude Sonnet (On-Demand-Preise in ap-southeast-2):

26,25 $ gespart bei einem einzigen Batch-Lauf. Bei täglichen Pipelines summiert sich das schnell auf tausende Dollar pro Monat. Und die Umsetzung sind ein paar JSONL-Dateien in S3 – eine Plumbing-Änderung, keine Architekturfrage.

Modellauswahl als Kostenstrategie

Die Wahl des richtigen Modells ist eine Kostenentscheidung mit einer Spreizung von 10–60x. Die meisten Teams greifen standardmäßig zu etwas Teurerem als nötig, weil sie das Modell beim Prototyping ausgewählt und die Entscheidung nie wieder hinterfragt haben.

Die abgestufte Architektur

Die kosteneffizientesten Bedrock-Deployments, die ich gesehen habe, arbeiten mit Tiers:

• Tier 1 (Haiku, Mistral 7B, Llama 3 8B) – Klassifizierung, Routing, Extraktion, einfache Q&A. Bruchteile eines Cents pro Anfrage. Sollte 60–80 % Ihres Traffics abdecken.
• Tier 2 (Sonnet, Mistral Large, Llama 3 70B) – komplexes Reasoning, nuancierte Generierung. 5–10x günstiger als Top-Tier.
• Tier 3 (Opus, Claude 3.5 Sonnet) – nur die schwierigsten Aufgaben. Premium-Preise, reserviert für das, was es wirklich braucht.

Das Router-Pattern

Bedrock hat eine eingebaute Lösung – allerdings nur für familieninternes Routing. Intelligent Prompt Routing liefert einen einzelnen serverless Endpoint, der Anfragen je nach Prompt-Komplexität zwischen Modellen derselben Familie verteilt. Sie geben eine Modellfamilien-ARN an (z. B. Anthropic Claude), und Bedrock entscheidet, ob jede Anfrage an Haiku oder Sonnet geht. AWS verspricht bis zu 30 % Kostensenkung – nach meiner Erfahrung bei Kunden ist das eine plausible Größenordnung. Kein Custom Code nötig, Sie tauschen einfach Ihre Model-ID gegen die ARN des Prompt Routers.

Für familienübergreifendes Routing (Haiku für Klassifizierung, Mistral für Extraktion, Sonnet für komplexes Reasoning) müssen Sie selbst Hand anlegen. Und ehrlich gesagt: Genau das machen die meisten Teams in Produktion. Es gibt schlicht kein ausgereiftes Out-of-the-Box-Framework, das das gut genug löst, um es ohne Vorbehalte zu empfehlen.

Drei Patterns, die funktionieren – grob nach Reifegrad sortiert:

Regelbasierte Klassifizierung ist der Punkt, an dem die meisten Teams starten und viele bleiben. Schreiben Sie 5–10 Regeln auf Basis struktureller Signale: Aufgabentyp-Keywords, Eingabelänge, erwartetes Output-Format, Konversationstiefe. Kein ML, keine Abhängigkeiten, an einem Tag deploybar. Trifft 70–80 % der Routing-Entscheidungen korrekt. Das sind nur ein paar hundert Zeilen bedingter Logik.

Confidence-basiertes Cascading ist das Pattern mit dem höchsten ROI, das ich gesehen habe. Schicken Sie jede Anfrage zuerst an das günstigste Modell. Prüfen Sie die Antwort auf Hedging-Sprache, fehlerhaften Output oder fehlende Pflichtfelder. Schlägt sie fehl, eskalieren Sie auf die nächste Stufe. Rechnen Sie mit der Latenz eines zusätzlichen Modellaufrufs bei den ~5–15 % eskalierten Anfragen. Ein Team, mit dem ich gearbeitet habe – eine E-Commerce-Plattform, die Produktanfragen verarbeitet – ging so von 38.000 $/Monat auf 15.000 $/Monat. Die Eskalationsrate lag bei nur 8 %. Der Klassifikator muss nicht perfekt sein; er muss nur oft genug richtig liegen, damit die Eskalation die Ausnahmen abfängt. Wenn Ihre Eskalationsrate über 25–30 % steigt, korrigieren Sie den Klassifikator.

Hybrid aus Regeln + ML-Klassifikator ist die nächste Reifestufe. Sobald Sie ein paar Wochen Produktions-Traffic mit gelabelten Outcomes haben, trainieren Sie einen kleinen Klassifikator (DistilBERT oder logistische Regression auf TF-IDF), der weniger als 5 ms Latenz hinzufügt. Der Klassifikator selbst kostet nur einstellige Millisekunden; die eigentlichen Kosten sind die Engineering-Disziplin, Daten zu labeln und regelmäßig nachzutrainieren. Teams, die das tun, verbessern die Routing-Genauigkeit typischerweise von ~78 % auf ~91 %.

Ich habe mir bestehende Frameworks genau angeschaut. RouteLLM vom LMSys-Team ist forschungsbasiert, im Kern aber ein Zwei-Modell-Router, trainiert auf allgemeinen Chat-Daten – für domänenspezifische Bedrock-Workloads müssten Sie nachtrainieren. LiteLLM ist hervorragend für Infrastruktur (einheitliche API, Fallbacks, Retries), aber das Routing dort ist Load Balancing, keine qualitätsbasierte Modellauswahl. Keines ist eine Drop-in-Lösung für das familienübergreifende Problem.

Fangen Sie mit Intelligent Prompt Routing an. Sobald Sie Belege haben, dass familienübergreifendes Routing nennenswert Geld spart, bauen Sie einen regelbasierten Klassifikator. Er ist vorhersehbar, debuggbar – und die Teams, mit denen ich arbeite und die diesen Weg gegangen sind, berichten konsistent von 40–70 % Kostensenkung.

Modellqualität vs. Kosten benchmarken

Gehen Sie nicht davon aus, dass Sie das teuerste Modell brauchen. Lassen Sie Ihre tatsächlichen Aufgaben über mehrere Modelle laufen und messen Sie Genauigkeit für Ihren konkreten Use Case, Kosten pro Aufgabe (nicht pro Token) und Latenz.

Genau das haben wir mit dem Finanzdienstleister gemacht. Seine Ticket-Klassifizierung erreichte 94 % Genauigkeit auf Haiku gegenüber 97 % auf Sonnet – zu 1/15 der Kosten. Diese 3 % Differenz waren für den Use Case irrelevant. Ihre Zahlen werden anders aussehen, das Muster bleibt: erst benchmarken, dann festlegen.

Qualitätsbewertung mit LLM-as-a-judge automatisieren

Bei Klassifizierung oder Extraktion lässt sich Qualität programmatisch validieren. Bei offener Generierung – Zusammenfassungen, Erklärungen, Kundenantworten – bedeutete Bewertung traditionell menschliche Reviewer. Das skaliert nicht.

Bedrock bringt eine Antwort dafür mit: LLM-as-a-judge Modellbewertung. Sie liefern einen Datensatz mit Prompts (optional mit Ground-Truth-Antworten), wählen ein Evaluator-Modell, und Bedrock lässt die Outputs des Kandidatenmodells durch den Judge laufen – über Metriken wie Korrektheit, Vollständigkeit, Hilfreichkeit, Kohärenz, Relevanz und Sicherheit. Das läuft als Managed Job; Sie bekommen Per-Prompt-Scores und Aggregate, abgelegt in S3.

Ziel ist es, zu belegen, dass ein Modell, das pro Token 5–15x weniger kostet, "gut genug" ist, bevor Sie echten Traffic darauf umleiten. Bereiten Sie eine JSONL-Datei mit Ihren repräsentativen Prompts vor, fahren Sie denselben Evaluation Job gegen Haiku, Sonnet und alles andere, was infrage kommt, und vergleichen Sie die Scores nebeneinander. AWS hat dazu einen Walkthrough mit Code-Samples veröffentlicht, dazu gibt es ein begleitendes Jupyter Notebook auf GitHub.

Ein paar Erfahrungswerte aus der Anwendung mit Kunden.

Verwenden Sie über alle Vergleiche hinweg dasselbe Evaluator-Modell. Bewerten Sie Haikus Output mit einem Modell und Sonnets mit einem anderen, messen Sie Evaluator-Unterschiede – nicht Modellunterschiede.

Nehmen Sie Ihre echten Produktions-Prompts, keine generischen Benchmarks. MT-Bench taugt für einen Sanity-Check, aber Ihre Ticket-Klassifizierungs-Prompts verhalten sich anders als akademische Question-Answering-Aufgaben.

Die Bewertung selbst kostet Geld (das Judge-Modell verarbeitet jeden Output). Starten Sie deshalb mit 200–500 repräsentativen Prompts statt mit Ihrem gesamten Datensatz. Das reicht meist, um zu sehen, ob das günstige Modell klar schlechter, klar gut genug oder "muss näher untersucht werden" ist.

Ground Truth ist optional, aber wertvoll: Bei Aufgaben mit bekannten Soll-Outputs werden die Metriken zu Faithfulness und Korrektheit deutlich aussagekräftiger.

benchmark_bedrock.py erfasst Kosten und Latenz; LLM-as-a-judge bewertet Qualität. Beides zusammen liefert Ihnen das vollständige Bild aus Kosten und Qualität – ohne manuelles Review.

Prompt Caching: 90 % Ersparnis bei wiederkehrendem Kontext

Mich überrascht, wie wenige Teams das aktiviert haben. Gecachte Input-Tokens werden mit 90 % Rabatt auf den Standardpreis abgerechnet.

Wenn Sie eine Anfrage mit aktiviertem Caching senden, speichert Bedrock das Präfix Ihres Prompts. Folgeanfragen mit demselben Präfix landen im Cache. Cache-Hits kosten ~10 % des Normalpreises. Cache-Writes (erste Anfrage) kosten etwas mehr; es spart also nur Geld, wenn Sie dasselbe Präfix mehrfach wiederverwenden – aber bei einem System-Prompt oder Few-Shot-Beispielen ist die Amortisation sofort da.

Besonders gut funktioniert es bei: System-Prompts über 1.500 Tokens, statischen Few-Shot-Beispielen, geteiltem Dokumentenkontext in RAG-Anwendungen, Multi-Turn-Konversationsverläufen.

Die Rechnung ist eindeutig. Ein System-Prompt mit 2.000 Tokens und 10.000 Anfragen pro Tag auf Claude Sonnet:

53 $/Tag. Über 1.500 $/Monat. Allein für den System-Prompt. Letzten Monat habe ich diese Rechnung mit einem Kunden durchgesprochen – er hat Caching aktiviert, bevor unser Call zu Ende war.

Darauf sollten Sie achten:

• Mindestlänge des cachebaren Präfixes variiert je nach Modell (typischerweise 1.024–2.048 Tokens)
• Exaktes Präfix-Matching – Whitespace und Reihenfolge zählen
• TTL bzw. Ablauf nach Inaktivität (Ihr Cache wird kalt, wenn der Traffic abfällt)
• Noch nicht alle Modelle unterstützen Caching – aktuelle Docs prüfen

Ein Benchmarking-Framework aufbauen

Ihre Optimierungsentscheidungen sollten auf Daten aus Ihren tatsächlichen Workloads basieren. Mein Team empfiehlt Folgendes.

Für jedes Modell und jede Konfiguration, die Sie testen, erfassen Sie: Kosten pro Aufgabe, Input-/Output-Token-Counts, Latenz (Time to first Token und gesamt) und einen aufgabenspezifischen Qualitäts-Score.

Der Ablauf: Wählen Sie 3–5 Aufgaben, die Ihren tatsächlichen Workload-Mix abbilden, erstellen Sie 100–500 Test-Beispiele pro Aufgabe mit bekannten Soll-Outputs, lassen Sie jede Aufgabe auf jedem Kandidatenmodell laufen, berechnen Sie Kosten pro Aufgabe (nicht pro Token – Modelle tokenisieren unterschiedlich) und tragen Sie Kosten gegen Qualität auf, um den Knick der Kurve zu finden. Selbst ein grober Scatter Plot reicht – Sie suchen nach "gleiche Qualität, deutlich günstiger" oder "leicht schlechtere Qualität, dramatisch günstiger".

Ich habe ein Python-Skript zusammengestellt (benchmark_bedrock.py), das das automatisiert: Es fährt Prompts über mehrere Bedrock-Modelle, erfasst Token-Counts und Latenz, gibt CSV aus und druckt Summary-Statistiken. Forken, an Ihre Workloads anpassen, fertig.

Beim Auswerten der Ergebnisse achten Sie auf Modelle, bei denen die Qualität ein Plateau erreicht (Haiku bei 93 % vs. Sonnet bei 95 % – sind diese 2 % den Faktor 10 wert?), auf Latenz-Ausreißer, Unterschiede in der Token-Effizienz (ein Modell, das pro Token günstiger, aber doppelt so geschwätzig ist, ist tatsächlich nicht günstiger) und auf Batch-Kandidaten.

Einheitliche GenAI-Kostentransparenz mit DoiT GenAI Intelligence

Die meisten Teams, mit denen ich arbeite, betreiben nicht nur Bedrock. Sie haben OpenAI für manche Workloads, Anthropic direkt für andere, vielleicht Vertex AI in einem GCP-Projekt. Die Kostendaten verteilen sich auf vier Konsolen mit inkompatiblen Dimensionen.

Genau dafür haben wir GenAI Intelligence gebaut. Es konsolidiert KI-Kosten- und Nutzungsdaten aus Bedrock, Vertex AI, Azure ML, Databricks, Anthropic und OpenAI in einer einheitlichen, normalisierten Sicht. Ihre Bedrock-Ausgaben erscheinen direkt neben allem anderen. Ohne Custom-ETL.

Für Bedrock liegt der Mehrwert in den normalisierten Labels. Model / Model Family trackt Kosten pro Modell anbieterübergreifend. Usage Type schlüsselt Input- vs. Output-Token-Ausgaben auf – die Aufteilung, die die meisten Teams unterschätzen. Cached zeigt, ob Operationen gecachte Tokens verwendet haben, sodass Sie den Caching-ROI direkt aus den Abrechnungsdaten messen können. GenAI Spend kennzeichnet alle generativen KI-Kosten unabhängig vom Anbieter für ein gesamthaftes Budget-Tracking.

Sie können Fragen stellen wie "Wie viel haben uns gecachte Tokens auf Claude Sonnet letzten Monat gespart?" oder "Wie verteilt sich unser Spend zwischen Haiku und Sonnet bei der Ticket-Klassifizierung?" – anbieterübergreifend, an einem Ort.

Das Dashboard liefert vorgefertigte Reports: Spend nach Anbieter (monatlich), Kosten nach Modellfamilie (täglich für die letzten 14 Tage – fängt Spikes schnell ab), Token-Aufschlüsselung nach Modell (30 Tage) und stündliche Token-Nutzung nach Anbieter (letzte 2 Tage – nützlich für die Korrelation mit Deployments). Da die GenAI-Daten in unsere Cloud-Analytics-Engine fließen, bekommen Sie zusätzlich Budgets, Allokationen, Anomaly Detection und Forecasting für Ihre KI-Ausgaben.

Angenommen, Sie nutzen Haiku für Klassifizierung und Sonnet für Reasoning, mit Caching auf beiden:

Haikus Cache-Hit-Rate ist solide (60 % der Tokens gecacht). Sonnets ist schwach (40 %). Caching bei Sonnet zu reparieren könnte hunderte Dollar pro Monat sparen – und Sie sehen das, ohne eine einzige CloudWatch-Query zu schreiben.

So legen Sie los: AWS-Account mit DoiT verbinden, in Dashboards → GenAI Intelligence wechseln – Ihre Bedrock-Daten füllen sich automatisch. Auf der Bedrock-Seite ist keine Instrumentierung nötig.

Observability mit OpenTelemetry

Benchmarking liefert eine Momentaufnahme. Produktions-Workloads driften – Prompts ändern sich, Traffic-Muster verschieben sich, neue Modelle erscheinen. GenAI Intelligence deckt die Abrechnungsseite der laufenden Sichtbarkeit ab. Für die Instrumentierung auf Anwendungsebene – Latenz, Routing-Entscheidungen, Cache-Hits pro Anfrage – empfehle ich OpenTelemetry.

Dank der GenAI Semantic Conventions versteht jedes OTel-kompatible Backend (Grafana, Datadog, Honeycomb) Ihre Spans. Verpacken Sie jeden Bedrock-Aufruf in einen Span mit diesen Attributen:

• gen_ai.system – "aws.bedrock"
• gen_ai.request.model – die Model-ID
• gen_ai.usage.input_tokens / output_tokens – aus den Response-Metadaten
• gen_ai.usage.cost – berechnet aus Ihrer Pricing-Tabelle
• task.type – Ihr Aufgabenname auf Anwendungsebene

Was Sie damit bekommen: Trends bei Kosten pro Aufgabe über die Zeit (fängt Prompt-Drift ab, bevor er auf der Rechnung landet), Validierung des Model Routings (bei einem Kunden hat Tier 1 nur 40 % statt der erwarteten 70 % bearbeitet – ein Bug, der zusätzliche 800 $/Monat gekostet hat) und Monitoring der Cache-Hit-Rate (Einbrüche innerhalb weniger Stunden erkennen, nicht erst zum Ende des Abrechnungszeitraums).

Außerdem haben Sie die Daten, um sie mit ModelUnitUtilization aus CloudWatch für Provisioned-Throughput-Entscheidungen zu korrelieren.

Minimale Instrumentierung:

from opentelemetry import trace

tracer = trace.get_tracer("bedrock-client")

def invoke_with_telemetry(client, model_id, prompt, max_tokens, task_type="unknown"):
    with tracer.start_as_current_span("bedrock.invoke") as span:
        span.set_attribute("gen_ai.system", "aws.bedrock")
        span.set_attribute("gen_ai.request.model", model_id)
        span.set_attribute("gen_ai.request.max_tokens", max_tokens)
        span.set_attribute("task.type", task_type)

        resp = client.invoke_model(modelId=model_id, body=body, contentType="application/json")
        data = json.loads(resp["body"].read())

        in_tok = data["usage"]["input_tokens"]
        out_tok = data["usage"]["output_tokens"]
        span.set_attribute("gen_ai.usage.input_tokens", in_tok)
        span.set_attribute("gen_ai.usage.output_tokens", out_tok)

        return data

Darauf bauen Sie vier Panels – tägliche Kosten pro Modell, Kosten pro Aufgabe pro Modell, Cache-Hit-Rate, p50/p95-Latenz – und prüfen sie wöchentlich.

Häufige Fallstricke

Die Fehler, die ich am häufigsten sehe, grob nach Geldverschwendung sortiert:

Provisioned-Throughput-Auslastung wöchentlich überwachen. Dauerhaft unter 50 %? Auf On-Demand umstellen. Das genannte Medienunternehmen hat mehr Geld mit ungenutzter Provisioned-Kapazität verbrannt als mit der eigentlichen Inferenz.

Output-Tokens modellieren und begrenzen. Output-Tokens kosten 3–5x mehr als Input. Ein Team hat seine Output-Kosten um 40 % gesenkt, indem es einfach "antworte in JSON, keine Erklärungen" zu seinen Extraktions-Prompts hinzugefügt hat.

Alles batchen, was keine Sub-24-Stunden-Latenz braucht. 50 % Rabatt. Kein Qualitätskompromiss.

Sonnet nicht zum Default machen. Sonnet für alles zu nutzen, weil es im Prototyping funktioniert hat, ist die häufigste Form von Überausgaben, die ich sehe.

Caching aktivieren, wo immer Sie Prompts wiederverwenden. Statischer System-Prompt oder Few-Shot-Beispiele? Minutenarbeit, sofortige Ersparnis.

Pro Aufgabe messen, nicht pro Token. Ein günstigeres Modell mit ausschweifenderem Output kann pro Aufgabe teurer sein. Benchmarken Sie auf Aufgabenebene.

Alles zusammenführen

Der Optimierungspfad, den ich mit den meisten Teams gehe:

1. Batch Inference – asynchrone Workloads verschieben. Sofort 50 % Ersparnis, kein Qualitätsverlust.
2. Prompt Caching – für wiederkehrenden Kontext aktivieren. Minutenarbeit.
3. Modellalternativen benchmarken – sehr wahrscheinlich laufen 60–80 % Ihres Workloads problemlos auf Tier 1.
4. Model Routing – einen Klassifikator bauen. Mit Regeln starten.
5. Provisioned Throughput – erst, wenn die Punkte oben stabil laufen und Ihre Nutzung vorhersehbar ist.

Die Effekte summieren sich. Der eingangs erwähnte Finanzdienstleister hat Schritte 1–4 in sechs Wochen umgesetzt. Batch Inference hat 22 % gespart. Caching 18 %. Model Routing weitere 25 %. Insgesamt: von 40.000 $ auf 18.000 $.

Aber das ist kein einmaliges Projekt. Die Bedrock-Landschaft verändert sich ständig. Als Claude 3.5 Haiku erschien, war es bei etwa demselben Preispunkt deutlich besser als Claude 3 Haiku – Teams mit hartkodierten Model-IDs haben das Upgrade monatelang verpasst. AWS hat die Bedrock-Preise schon mehrfach ohne große Ankündigung angepasst. Und Ihr eigener Workload driftet: Prompts werden länger, neue Aufgabentypen kommen hinzu, Traffic-Verhältnisse verschieben sich.

Was funktioniert: ein schlanker Quartals-Review. Lassen Sie Ihre Benchmarks gegen alle neuen Modelle laufen (mit dem Benchmarking-Skript ein Nachmittag). Nutzen Sie LLM-as-a-judge, um zu bestätigen, dass die Qualität nicht zurückgegangen ist. Prüfen Sie Ihre OTel-Dashboards auf Routing-Drift – bedient Tier 1 noch den erwarteten Traffic-Anteil? Hat sich Ihre Cache-Hit-Rate verändert?

Wenn Sie DoiT nutzen, zeigt Ihnen GenAI Intelligence Trends bei den Kosten pro Modell, an denen sofort sichtbar wird, wenn sich etwas verschoben hat. Der gesamte Review dauert nach dem ersten Mal nur einen halben Tag.

Das erwähnte Medienunternehmen hat bei einem dieser Reviews entdeckt, dass eine Prompt-Änderung die Cache-Hit-Rate stillschweigend von 94 % auf 61 % gedrückt hatte – zusätzliche 2.000 $/Monat, die niemandem aufgefallen waren.

Wenn Sie heute auf Bedrock unterwegs sind und ein zweites Augenpaar auf Ihrer Rechnung haben wollen, schaue ich gerne drauf – besonders, wenn Sie in APAC sitzen. Und wenn Sie bereits DoiT-Kunde sind, haben Sie das GenAI-Intelligence-Dashboard – nutzen Sie es als Ausgangspunkt für diesen Quartals-Review.

Das in diesem Artikel referenzierte Benchmarking-Skript finden Sie unter https://github.com/p-obrien/bedrock-cost-model-blog. Lassen Sie es gegen Ihre eigenen Workloads laufen, um die Datenbasis für fundierte Entscheidungen zu erzeugen.