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.
Häufig gestellte Fragen
In diesem Abschnitt werden häufig gestellte Fragen zur Auswahl und Kombination der Amazon Bedrock-Kostenzuweisungsmechanismen beantwortet.
Eine Methode wählen
F: Ich möchte eine Zuordnung pro Benutzer und pro Eingabeaufforderung. Was sind meine Wahlmöglichkeiten?
A: Verwenden Sie Modellaufrufprotokolle, nicht die abrechnungsbasierten Methoden. Die nativen Methoden (IAM-Hauptzuweisung, ProjekteAnwendungsinferenzprofile, undArbeitsbereiche) erzeugen in AWS Cost Explorer und CUR immer nur aggregierte Dollars — niemals eine Zeile pro Anfrage. Die Ansicht pro Eingabeaufforderung ist nur in Ihren Protokollen vorhanden, sodass der Benutzer von einem von zwei Orten kommen kann.
Die erste Option besteht darin, bei jedem Aufruf ein Request-Metadaten-Tag festzulegen:
client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )
Die zweite Möglichkeit besteht darin, sich auf die automatische Erfassung zu verlassenidentity.arn, was funktioniert, wenn Ihr Anrufer seine IAM-Rolle mit einem pro Benutzer übernimmt. RoleSessionName Sie berechnen die Kosten anhand der protokollierten Token-Anzahl. Wenn Sie außerdem eine genaue Rechnungsstellung pro Benutzer wünschen, sollten Sie das auch tun. IAM-Hauptzuweisung
F: Ich habe ein bestimmtes Szenario. Welche Methode sollte ich verwenden?
A: Ordnen Sie Ihr Szenario anhand der folgenden Tabelle einer Methode zu.
| Szenario | Verwenden Sie |
|---|---|
| Sie müssen die Ausgaben der einzelnen Teams auf Ihrer monatlichen Rechnung verbuchen. | IAM-Hauptzuweisung(Tag für Team) oder ein Tag Projekte oder Anwendungsinferenzprofile |
| Sie benötigen die Kosten pro individueller Aufforderung und pro Funktion. | Per-request Tagging von Metadatenmit Protokollen zum Aufrufen von Modellen |
| Sie verwenden viele Modelle und benötigen einen Kostenbereich pro Anwendung. | Projekteein bedrock-mantle — ein einzelnes Projekt kann sich über viele Modelle erstrecken |
| Sie sind bei InvokeModel Converse und wollen Geld pro Anwendung. | Anwendungsinferenzprofile |
| Sie stellen Amazon Bedrock ein Gateway zur Verfügung, das viele Benutzer bedient. | Per-user sts:AssumeRolefür Rechnungsbeträge plus Per-request Tagging von Metadaten für Details pro Aufforderung |
F: Sollte ich Projekte oder Anwendungs-Inferenzprofile verwenden?
A: Beide liefern aggregierte Dollars in AWS Cost Explorer und CUR. Wählen Sie nach Endpunkt und Maßstab.
-
Anwendungsinferenzprofilefunktionieren auf dem
bedrock-runtimeEndpunkt (InvokeModel und Converse), aber sie sind modellspezifisch. Sie erstellen ein Profil pro Modell, sodass die Anzahl der Ressourcen steigt, wenn Sie Modelle oder Teams hinzufügen. -
Projektearbeiten Sie auf dem
bedrock-mantleEndpunkt (Antworten und Chat-Abschlüsse), und ein einzelnes Projekt kann sich über viele Modelle erstrecken. Sie lassen sich besser skalieren, wenn Sie viele Modelle pro Workload haben, sie aber nur für einzelne Modelle verfügbar sind.
Verwenden Sie es IAM-Hauptzuweisung zusammen mit einem der beiden, um Informationen pro Benutzer zu erhalten.
Fragen zum Kosten- und Nutzungsbericht
F: Was ist der Unterschied zwischen klassischem CUR und CUR 2.0 bei der Kostenzuweisung?
A: Aktivierte Kostenzuordnungs-Tags ausProjekte, AnwendungsinferenzprofileArbeitsbereiche, und IAM-Prinzipal-Tags werden sowohl in der klassischen CUR als auch in CUR 2.0 angezeigt. Der Unterschied besteht in der automatischen Anruferidentitätsspalte, die das Arbeiten ohne Tagging ermöglichtIAM-Hauptzuweisung. Diese Spalte — die Daten „Wer hat den Anruf getätigt“ — ist nur in einem CUR 2.0-Export (AWSDatenexporte) vorhanden, bei dem die Option Anruferidentität ausgewählt ist. Wenn Sie eine systemeigene Zuordnung pro Benutzer in Ihren Einzelpostendaten wünschen, benötigen Sie CUR 2.0.
F: Kann ich die Kosten für eine einzelne Aufforderung im AWS Cost Explorer oder CUR sehen?
A: Nein. Sowohl bei der klassischen CUR als auch bei CUR 2.0 werden die Kosten nach Nutzungsart über einen Zeitraum von einer Stunde oder einem Tag zusammengefasst, und beide enthalten in ihren Einzelposten keine ID pro Anfrage. Per-prompt Details sind nur in Ihren Modellaufrufprotokollen enthalten. Verknüpfen Sie die Logs anhand des Modells und des Nutzungstyps Grain mit CUR, um einen Abgleich zu ermöglichen, nicht um Kosten pro Prompt zu berechnen.
F: Meine Kosten sind in CUR angegeben, aber meine Tags und Tokens sind in Logs. Wie kombiniere ich sie?
A: Es gibt zwei Muster. Um fakturierungsgenaue Gesamtwerte zu erhalten, verknüpfen Sie die Logs an der gleichen Stelle mit CUR. model/usage type/day Die Kosten pro Prompt berechnen Sie anhand der protokollierten Token-Anzahl und der veröffentlichten Tarife pro Token. Die folgende CloudWatch Logs Insights-Abfrage generiert die Token-Gesamtwerte pro Benutzer und Modell, die in die Berechnung einfließen:
fields requestMetadata.user as user, modelId, input.inputTokenCount as inTokens, output.outputTokenCount as outTokens | stats sum(inTokens) as totalInput, sum(outTokens) as totalOutput, count() as calls by user, modelId
Bei der berechneten Zahl handelt es sich um eine Schätzung. Rabatte, Verpflichtungen, Chargenpreise, das kostenlose Kontingent oder der bereitgestellte Durchsatz werden nicht berücksichtigt, sofern Sie sie nicht modellieren. Details hierzu finden Sie unter Kosten aus Ihren Protokollen ableiten.
Worin unterscheiden sich die Mechanismen
F: Was ist der Unterschied zwischen einem IAM-Sitzungs-Tag und Anforderungsmetadaten?
A: Bindung und Ziel. Ein Sitzungs-Tag wird einmal gesetzt sts:AssumeRole und ist für jeden Anruf, der mit den Anmeldeinformationen dieser Sitzung getätigt wird, konstant. Es wird nur als aggregierte Abrechnungsdaten in AWS Cost Explorer und CUR (sowohl klassisch CUR als auch CUR 2.0) angezeigt. Anforderungsmetadaten werden pro Anruf festgelegt, variieren je nach Anfrage und landen in Ihren Aufrufprotokollen.
Verwenden Sie für die Zuordnung pro Benutzer und pro Aufforderung Anforderungsmetadaten. Verwenden Sie für die Abrechnung pro Benutzer Sitzungs-Tags oder verlassen Sie sich auf den ARN für die Anruferidentität.
F: Werden Metadaten der Anfrage auf meiner Rechnung angezeigt?
A: Nein. Metadaten anfordern ist kein Tag für die Kostenzuweisung. Es wird nur in Ihre Modellaufrufprotokolle geschrieben und erscheint nie im AWS Cost Explorer oder CUR. Verwenden Sie es für betriebliche Analysen und proprompte Analysen und verwenden Sie eine systemeigene Methode (z. B. IAM-Hauptzuweisung oderProjekte) für fakturierte Dollars.
Implementierung
F: Wie funktioniert die Zuordnung hinter einem LLM-Gateway?
A: Amazon Bedrock zeichnet die Rolle des Gateways als Identität des Anrufers auf. Um die Zuordnung auf Benutzerebene beizubehalten, nehmen Sie die Rolle pro Benutzer an, speichern Sie die Anmeldeinformationen für die Dauer der Sitzung im Cache und übergeben Sie den Benutzer als Sitzungs-Tag (für Rechnungskosten) and/or als a RoleSessionName (damit der Benutzer identity.arn in Ihren Protokollen landet):
sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )
Wenn Sie Informationen pro Aufforderung ohne AWS STS Anruf pro Anfrage wünschen, legen Sie stattdessen den Benutzer in den Anforderungsmetadaten für jeden Anruf fest.
F: Kann ich verlangen, dass jeder Anruf markiert wird?
A: Nicht von der Amazon Bedrock-Seite. Metadaten können pro Anruf angefordert werden, und Amazon Bedrock lehnt keine Anrufe ab, bei denen sie ausgelassen werden. Es handelt sich nicht um eine AWS Tag-Richtlinie, die nur Ressourcen regelt. Erzwingen Sie das Tagging in einem gemeinsam genutzten Client oder einem LLM-Gateway, das es bei jeder Anfrage stempelt. Verwenden Sie für eine Zuordnung, die immer ohne Code pro Anruf vorhanden istIAM-Hauptzuweisung, da die Identität des Anrufers automatisch erfasst wird.
F: Welche Felder lege ich bei jedem Anruf fest und welche sind automatisch?
A: Fast alles im Protokolldatensatz wird automatisch von Amazon Bedrock erfasst:accountId,,,, region modelId requestIdidentity.arn, die Anzahl der Eingabe- und Ausgabetokens und die Schema-Metadaten. Das einzige Feld, das Sie pro Anruf angeben, istrequestMetadata. Sie legen es nicht modelId als Tag fest, sondern das Modell oder das Inferenzprofil, das Sie aufgerufen haben.
