Kostenoptimierung

Inferenzkosten nach Token-Nutzung (z. B. Amazon Bedrock)

Abrechnung pro Aufruf (z. B. und) AWS Lambda AWS Step Functions

Volumengesteuerte Auslöser für Ereignisse (z. B. Amazon EventBridge und Amazon S3)

Wissensdatenbank, Tool-Aufruf und Erweiterungsdynamik von Retrieval Augmented Generation (RAG)

LLM-Größenauswahl — Höhere Modelle (z. B. Amazon Nova Premier) sind pro Token deutlich teurer.

Länge und Ausführlichkeit der Eingabeaufforderung — Längere Ein- und Ausgaben erhöhen die Kosten von Amazon Bedrock linear.

Zunahme von Toolaufrufen — Agenten, die zu viele oder redundante Tools verwenden, können Lambda- und Datenübertragungsgebühren in die Höhe treiben.

Granularität des Workflows von Step Functions — Übermäßig fragmentierte Workflows erhöhen die Zustandsübergänge und erhöhen die Ausführungsdauer.

Datenverschiebung — Übermäßiger regionsübergreifender Verkehr, unnötige RAG-Indizierung oder wiederholtes Abrufen von Wissensdatenbanken können kostspielig werden.

Verwenden Sie eine gestaffelte Modellauswahl — Modelle wie Amazon Nova, Amazon Titan und Anthropic Claude bieten unterschiedliche Preismodelle mit Kompromissen bei Kosten, Geschwindigkeit und Genauigkeit. Um diese Strategie umzusetzen, leiten Sie Eingabeaufforderungen mit geringer Komplexität an Amazon Nova Micro weiter und eskalieren Sie sie nur, wenn das Vertrauen gering ist.

Eingabeaufforderungen und Ausgaben kürzen — Die Tokenanzahl ist der größte Kostentreiber in Amazon Bedrock. Um diese Strategie umzusetzen, sollten Sie die maximale Größe der Eingabeaufforderung durchsetzen, präzise Formulierungen verwenden und ausführliche Vervollständigungen vermeiden.

Kontrollieren Sie den Umfang des RAG-Abrufs — Unbegrenzte Anzahl von Dokumenten in einer Wissensdatenbank kann den Kontext in die Höhe schnellen lassen. Verwenden Sie zur Umsetzung dieser Strategie Metadatenfilter und Top-K-Rankings. Fügen Sie außerdem nur relevante Inhalte in die LLM-Eingabeaufforderung ein.

Batch-Ereignisse für Inferenz — Einzelne Inferenzaufrufe sind teurer als die Batch-Verarbeitung. Um diese Strategie zu implementieren, gruppieren Sie Eingaben (z. B. Stimmungsanalyse und Zusammenfassung) und führen Sie pro Batch eine einzelne Inferenz durch.

Verwenden Sie Step Functions für die Aggregation, nicht für das Mikromanagement — Die übermäßige Verwendung von Übergängen in atomaren Zuständen führt zu langen Dauern. Um diese Strategie zu implementieren, gruppieren Sie die zugehörige Logik in Lambda-Einheiten und vermeiden Sie Muster von Zustandsexplosionen.

Asynchrone Antwortverarbeitung — Blockieren Sie die Rechenleistung nicht, indem Sie auf langsame Modelle warten. Verwenden Sie diese Strategie EventBridgezusammen mit Amazon Simple Queue Service (Amazon SQS) und Lambda für verzögerte Antwortmuster (z. B. asynchrone Zusammenfassung).

Verwenden Sie Amazon Bedrock Kostenzuweisungs-Tags — Tags ermöglichen die Sichtbarkeit je nach Anwendung und Team. Um diese Strategie zu implementieren, wenden Sie standardisierte Tags auf Amazon Bedrock-Aufrufe an (z. B. Project=MarketingAI undTeam=GenOps).

Optimieren Sie die Wiederholungs- und Vertrauenslogik — Unnötige Wiederholungsversuche oder Ausweichketten erhöhen die Kosten. Um diese Strategie umzusetzen, sollten Sie strukturierte Vertrauensschwellen und vorzeitige Ausstiege verwenden, um Wiederholungsversuche zu begrenzen.

Verwenden Sie Caching für Tool-Aufrufe — Bei vielen Aufrufen von Agententools werden Datenabrufe wiederholt. Um diese Strategie umzusetzen, speichern Sie aktuelle Tool-Ergebnisse in Amazon DynamoDB mit Time to Live (TTL) und verwenden Sie sie, falls sie unverändert sind, wieder.

Nutzen Sie reservierte Parallelität oder bereitgestellte Parallelität (falls erforderlich) — In Fällen mit hohem Volumen reduziert diese Strategie den Kaltstart und die Kostenunsicherheit. Implementieren Sie diese Strategie, indem Sie sie nur für Funktionen mit vorhersehbarem Datenverkehr und langen Aufwärmzeiten aktivieren.

Das mehrstufige Modell-Routing reduziert die Kosten, da kleinere Anfragen mit einem kleineren Modell bearbeitet werden. Bei diesem Ansatz werden Amazon Nova Lite für häufig gestellte Fragen und Claude 3 Sonnet nur für die 10 Prozent der Fälle verwendet, in denen eine Begründung oder mehrere Tool-Calls erforderlich sind.

Durch das schnelle Zuschneiden und die Kontrolle der Vorlagen wird eine konsistente, kalkulierbare Nutzung gewährleistet. Eingabeaufforderungen sind tokenbegrenzt und bestehen aus strukturierten Vorlagen (z. B. maximal 400 Token mit Kontext).

Kontextuelles RAG-Scoping verhindert, dass überflüssige Dokumente in eine LLM-Eingabeaufforderung eingefügt werden. Die Wissensdatenbank beschränkt den Abruf mithilfe von Metadatenfiltern auf relevante Produktkategorien oder Richtliniendomänen.

Durch das Zwischenspeichern der Ergebnisse von Toolaufrufen werden doppelte Lambda-Aufrufe vermieden, wenn Benutzer sie umformulieren. Ergebnisse von getOrderStatus und lookupReturnWindow werden in DynamoDB mit einer TTL von 10 Minuten zwischengespeichert.

Die vertrauensbasierte Modeleskalation sorgt für ein ausgewogenes Verhältnis zwischen Erlebnisqualität und LLM-Kostenkontrolle. Wenn die Antwortsicherheit von Amazon Nova Lite (gemessen an Struktur- und Regex-Heuristiken) gering ist, greifen Sie auf Anthropic Claude oder eine menschliche Eskalationswarteschlange zurück.

Der Antwortvalidator Lambda reduziert unnötige Ausgabetokens um etwa 25 Prozent. Dieser Ansatz entfernt ausführliche Modellvervollständigungen, formatiert Antworten in präzise Ausgaben und protokolliert die Tokengröße.

Die Kostenkennzeichnung ermöglicht die FinOps Berichterstattung pro Funktion und pro Umgebung. Alle Amazon Bedrock-Aufrufe sind mit Application=SupportAssistantEnvironment=Production, und Team=CustomerSuccess gekennzeichnet.

CloudWatchmetrics verfolgt die Nutzung von Amazon Bedrock-Tokens, die Dauer der Step Functions Functions-Schritte und die Kosten für Lambda-Aufrufe.

AWS Budgetsbenachrichtigt Teams, wenn Kostengrenzwerte überschritten werden (z. B. die täglichen Token-Kosten).

AWS Cost Explorerund Cost Categories bieten Ansichten der Ausgaben pro App, Team oder Modell.

Die API-Protokolle von Amazon Bedrock (durch CloudWatch) ermöglichen die Analyse der Prompt-Struktur und der Antwortgröße.

Amazon Athena - und Amazon S3 S3-Protokolle unterstützen einmalige oder Ad-hoc-Abfragen zu Nutzungsdaten, die aus Protokollen exportiert wurden, AWS CloudTrail oder benutzerdefinierte Protokolle.

Anstieg der Token-Nutzung — Dies kann auf eine sofortige Änderung, eine neue Modellversion oder einen übermäßigen RAG-Abruf hinweisen.

Erhöhung der Amazon Bedrock-Latenz — Kann zu längeren Lambda-Dauern und höheren Kosten pro Inferenz führen.

Anstieg der Tool-Aufrufe pro Agentensitzung — deutet auf einen Missbrauch von Tools oder eine ineffiziente Eingabeaufforderungslogik hin.

Step Functions Functions-Schritte mit langer Laufzeit — Kann auf übermäßig zerlegte Zustände oder blockierte asynchrone Ereignisse zurückzuführen sein.

Zu wenig genutzte Modellstufe — Zeigt an, dass Sie für erstklassige Genauigkeit bei Anfragen mit geringem Risiko zahlen.