Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Nutzung und Kosten in Amazon Bedrock verfolgen
Amazon Bedrock bietet mehrere Möglichkeiten, die Nutzung und Kosten von Modellinferenzen bestimmten Benutzern, Teams, Anwendungen, Umgebungen oder Experimenten zuzuordnen. Sie können einen einzelnen Mechanismus verwenden oder mehrere kombinieren. Verwenden Sie beispielsweise die IAM-Prinzipalzuweisung für die Sichtbarkeit pro Benutzer zusammen mit Projekten für das Tagging pro Anwendung und fordern Sie Metadaten für die Nachverfolgung von Experimenten pro Anruf an.
Tipp
Wenn Sie sich nicht sicher sind, welcher Mechanismus zu Ihrem Anwendungsfall passt, beginnen Sie mit dem Häufig gestellte Fragen am Ende dieses Kapitels. Es beantwortet häufig gestellte Entscheidungsfragen wie „Ich möchte eine Zuordnung pro Benutzer und pro Eingabeaufforderung — welche Möglichkeiten habe ich?“ und „Was ist der Unterschied zwischen klassischem CUR und CUR 2.0?“.
Auswahl des Ansatzes
Welche Methode zur Kostenzuweisung Sie wählen, hängt davon ab, welche Dimension Sie verfolgen möchten, welche Amazon Bedrock-APIs Sie verwenden und welche Granularität Sie benötigen. Die folgenden beiden Tabellen enthalten ergänzende Ansichten. Verwenden Sie die erste, um die Mechanismen anhand Ihres Ziels nachzuschlagen, und die zweite, um die Mechanismen nebeneinander zu vergleichen.
Wähle nach Ziel
Wenn Sie wissen, was Sie von der Kostenverfolgung erwarten, beginnen Sie hier.
| Wenn dein Ziel ist... | Verwenden Sie |
|---|---|
| Per-user oder Dollar pro Team auf Ihrer Rechnung | IAM-Hauptzuweisung |
| Per-application oder Dollar pro Workload | Anwendungsinferenzprofile(bedrock-runtime), oder Projekte und Arbeitsbereiche () bedrock-mantle |
| Per-prompt Token-Nutzung und Kosten, aufgeteilt nach beliebigen Dimensionen | Per-request Tagging von Metadaten, mit Protokollen zum Aufrufen von Modellen |
| Per-user und Details pro Eingabeaufforderung | Modellieren Sie Aufrufprotokolle, wobei der Benutzer aus dem identity ARN oder einem Request-Metadaten-Tag stammt |
| Sowohl rechnungstechnische Angaben als auch detaillierte Angaben pro Aufforderung | Kombinieren Sie eine native Methode (z. B.) mit IAM-Hauptzuweisung Per-request Tagging von Metadaten |
Vergleichen Sie die Mechanismen
In der folgenden Tabelle werden die verfügbaren Mechanismen danach verglichen, was Sie mit ihnen zuordnen können, was sie ausgeben, wie detailliert die Ausgabe ist, wo die Daten geliefert werden und welche Endpunkte sie unterstützen.
| Mechanismus | Attribut von | Ausgabe | Granularity | Datenziel | Unterstützte APIs | bedrock-runtime |
bedrock-mantle |
|---|---|---|---|---|---|---|---|
| IAM-Hauptzuweisung | IAM-Identität | In Rechnung gestellte Dollar | Aggregiert, pro Nutzungstyp und Tag | AWS Cost Explorer//CUR 2.0 | InvokeModel, Converse, Chat-Abschlüsse |  |
 |
| Anwendungsinferenzprofile | Ressourcen-Tags für Profile | In Rechnung gestellte Dollar | Aggregiert, pro Nutzungstyp und Tag | AWS Cost Explorer//CUR 2.0 | InvokeModel, Converse, Chat-Abschlüsse | |
|
| Projekte | Tags für Projektressourcen | In Rechnung gestellte Dollar | Aggregiert, pro Nutzungstyp und Tag | AWS Cost Explorer//CUR 2.0 | Antworten, Chat-Abschlüsse | |
|
| Arbeitsbereiche | Tags für Projektressourcen über den Workspace-Header | In Rechnung gestellte Dollar | Aggregiert, pro Nutzungstyp und Tag | AWS Cost Explorer//CUR 2.0 | Anthropische Botschaften | |
|
| Per-request Tagging von Metadaten | Per-request Schlüssel-Wert-Tags | Token-Anzahl (Sie rechnen in Kosten um) | Pro Anfrage | Nur Aufruf-Logs | InvokeModel, Converse InvokeModelWithResponseStream, ConverseStream | |
|
Anmerkung
Die systemeigenen Methoden (IAM-Hauptzuweisung, AnwendungsinferenzprofileProjekte, undArbeitsbereiche) liefern aggregierte in Rechnung gestellte Dollar an AWS Cost Explorer und CUR 2.0. Die beste Verteilung erfolgt pro Nutzungstyp und Tag, zugeordnet nach Identität oder Tag. Sie erzeugen keine Zeile pro Anfrage. Verwenden Sie Modellaufrufprotokolle, bei denen es sich bei jedem Aufruf um einen separaten Datensatz handelt, der seine eigene Token-Anzahl enthält, um Informationen zu den einzelnen Eingabeaufforderungen zu erhalten.
Zuordnung hinter einem LLM-Gateway
Wenn ein Gateway oder Proxy Amazon Bedrock im Namen vieler Benutzer aufruft, zeichnet Amazon Bedrock die IAM-Rolle des Gateways als Identität des Anrufers auf. Um die Zuordnung auf Benutzerebene beizubehalten, wählen Sie auf der Grundlage der benötigten Ausgabe.
-
Lassen Sie das Gateway für Ihre Abrechnungstools pro Benutzer seine Amazon Bedrock-Rolle pro Benutzer oder Mandant übernehmen, indem Sie Tags pro Benutzer
RoleSessionNameoder Sitzung verwenden. Zwischenspeichern Sie die resultierenden Anmeldeinformationen für die Dauer der Sitzung, um zu vermeiden, dass bei jeder Anfrage ein AWS STS Anruf erfolgt. Weitere Informationen finden Sie unter IAM-Hauptzuweisung. -
Für Details pro Aufforderung legen Sie bei jedem Anruf den Benutzer in den Anforderungsmetadaten fest. Die Metadaten der Anfrage variieren je nach Anforderung ohne zusätzliche AWS STS Aufrufe, was Sitzungs-Tags in einer gemeinsamen Sitzung nicht tun können.
