Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Domande frequenti
Questa sezione risponde alle domande più comuni sulla scelta e la combinazione dei meccanismi di attribuzione dei costi di Amazon Bedrock.
Scelta di un metodo
D: Voglio l'attribuzione per utente e per prompt. Quali sono le mie scelte?
R: Utilizza i log di invocazione del modello, non i metodi basati sulla fatturazione. I metodi nativi (Attribuzione principale IAM, ProgettiProfili di inferenza delle applicazioni, eWorkSpace) producono solo dollari aggregati in AWS Cost Explorer e CUR, mai una riga per richiesta. La visualizzazione per prompt esiste solo nei log, da cui l'utente può provenire da una delle due posizioni.
La prima opzione consiste nell'impostare un tag di metadati di richiesta per ogni chiamata:
client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )
Il secondo è affidarsi all'acquisizione automaticaidentity.arn, che funziona se il chiamante assume il proprio ruolo IAM con un singolo utente. RoleSessionName Il costo viene calcolato sulla base dei conteggi registrati dei token. Se desideri anche dollari accurati per utente in termini di fatturazione, corri a fianco. Attribuzione principale IAM
D: Ho uno scenario specifico. Quale metodo devo usare?
R: Abbina il tuo scenario a un metodo utilizzando la tabella seguente.
| Scenario | Utilizzo |
|---|---|
| La spesa di ogni squadra deve essere inserita nella fattura mensile. | Attribuzione principale IAM(tag per team), oppure un tag Progetti o Profili di inferenza delle applicazioni |
| È necessario il costo per singolo prompt, per funzionalità. | Per-request etichettatura dei metadaticon registri di invocazione del modello |
| Utilizzate molti modelli e desiderate un unico budget per applicazione. | Progettionbedrock-mantle: un singolo progetto può estendersi su più modelli |
| Sei su InvokeModel Converse e desideri un dollaro per applicazione. | Profili di inferenza delle applicazioni |
| Fornisci ad Amazon Bedrock un gateway che serve molti utenti. | Per-user sts:AssumeRoleper la fatturazione in dollari e per i dettagli relativi a Per-request etichettatura dei metadati ogni richiesta |
D: Devo usare Projects o i profili di inferenza delle applicazioni?
R: Entrambi forniscono dollari aggregati in AWS Cost Explorer e CUR. Scegli per endpoint e scala.
-
Profili di inferenza delle applicazionifunzionano sull'
bedrock-runtimeendpoint (InvokeModel e su Converse), ma sono specifici del modello. Crei un profilo per modello, in modo che il numero di risorse cresca man mano che aggiungi modelli o team. -
Progettilavorano sull'
bedrock-mantleendpoint (risposte e completamenti della chat) e un singolo progetto può abbracciare più modelli. Si adattano meglio quando si hanno molti modelli per carico di lavoro, ma sono utilizzabili solo come mantello.
Utilizzali Attribuzione principale IAM insieme a uno dei due per i dettagli relativi a ciascun utente.
Domande sul rapporto sui costi e sull'utilizzo
D: Qual è la differenza tra il CUR classico e il CUR 2.0 per l'attribuzione dei costi?
R: I tag di allocazione dei costi attivati da Progetti Profili di inferenza delle applicazioniWorkSpace, e i tag principali IAM compaiono sia nella versione classica di CUR che in CUR 2.0. La differenza è la colonna automatica dell'identità del chiamante che funziona senza tag. Attribuzione principale IAM Quella colonna, i dati «chi ha effettuato la chiamata», esiste solo in un'esportazione CUR 2.0 (Esportazioni AWS dati) con l'opzione caller-identity selezionata. Se desideri un'attribuzione nativa per utente nei dati degli elementi di riga, hai bisogno di CUR 2.0.
D: È possibile visualizzare il costo di un singolo prompt in AWS Cost Explorer o CUR?
R: No. Sia il CUR classico che il CUR 2.0 aggregano i costi per tipo di utilizzo nell'arco di un'ora o un giorno e nessuno dei due riporta un identificatore per richiesta nelle voci. Per-prompt i dettagli sono presenti solo nei log di invocazione del modello. Unisci i log a CUR in base al modello e al tipo di utilizzo per la riconciliazione, non per il costo per richiesta.
D: I miei costi sono in CUR ma i miei tag e token sono nei log. Come li combino?
R: Esistono due modelli. Per ottenere totali accurati in base alla fattura, unisci i registri al CUR nel punto in cui si trovano. model/usage type/day Per quanto riguarda il costo per richiesta, calcolalo in base al numero di token registrati e alle tariffe pubblicate per token. La seguente query di CloudWatch Logs Insights produce i totali dei token per utente e per modello che alimentano il calcolo:
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
La cifra calcolata è una stima. Non riflette sconti, impegni, prezzi in batch, piano gratuito o produttività prevista, a meno che non vengano modellati. Per informazioni dettagliate, vedi Calcolare i costi dai log.
In che modo differiscono i meccanismi
D: Qual è la differenza tra un tag di sessione IAM e i metadati di richiesta?
R: Associazione e destinazione. Un tag di sessione viene impostato una volta sts:AssumeRole ed è costante per ogni chiamata effettuata con le credenziali di quella sessione; viene visualizzato solo come dati di fatturazione aggregati in AWS Cost Explorer e CUR (sia CUR classico che CUR 2.0). I metadati della richiesta vengono impostati per chiamata, variano in base alla richiesta e vengono inseriti nei registri delle chiamate.
Per l'attribuzione per utente e per prompt, utilizza i metadati della richiesta. Per pagare in bolletta dollari per utente, usa i tag di sessione o affidati all'identità del chiamante (ARN).
D: I metadati della richiesta vengono visualizzati sulla mia fattura?
R: No. I metadati della richiesta non sono un tag di allocazione dei costi. Viene scritto solo nei log di invocazione del modello e non viene mai visualizzato in AWS Cost Explorer o CUR. Utilizzatelo per l'analisi operativa e mirata e utilizzate un metodo nativo (ad esempio o) per i dollari fatturati. Attribuzione principale IAM Progetti
Implementazione
D: Come funziona l'attribuzione dietro un gateway LLM?
R: Amazon Bedrock registra il ruolo del gateway come identità del chiamante. Per preservare l'attribuzione a livello utente, assumi il ruolo per utente, memorizza nella cache le credenziali per tutta la durata della sessione e passa l'utente come tag di sessione (per fatturare dollari) and/or come un RoleSessionName (in modo che l'utente acceda ai tuoi log): identity.arn
sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )
D: Posso richiedere che ogni chiamata sia contrassegnata?
R: Non dal lato di Amazon Bedrock. I metadati della richiesta sono attivabili per ogni chiamata e Amazon Bedrock non rifiuta le chiamate che li omettono. Non è una AWS Tag Policy, che regola solo le risorse. Implementa l'etichettatura in un client condiviso o in un gateway LLM che la timbra su ogni richiesta. Per un'attribuzione sempre presente senza codice per chiamata, utilizza, poiché l'identità del chiamante viene acquisita Attribuzione principale IAM automaticamente.
D: Quali campi devo impostare per ogni chiamata e quali sono automatici?
R: Quasi tutto il record di log viene acquisito automaticamente da Amazon Bedrock:accountId,,,,region, modelId requestIdidentity.arn, i conteggi dei token di input e output e i metadati dello schema. L'unico campo che fornisci per chiamata è. requestMetadata Non lo imposti modelId come tag; è il modello o il profilo di inferenza che hai richiamato.
