As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Perguntas frequentes
Esta seção responde a perguntas comuns sobre como escolher e combinar os mecanismos de atribuição de custos do Amazon Bedrock.
Escolhendo um método
P: Quero atribuição por usuário e por solicitação. Quais são minhas escolhas?
R: Use registros de invocação do modelo, não os métodos baseados em cobrança. Os métodos nativos (Atribuição principal do IAM,, ProjetosPerfis de inferência de aplicações, eEspaços de trabalho) só produzem dólares agregados no AWS Cost Explorer e no CUR — nunca uma linha por solicitação. A visualização por solicitação existe somente em seus registros, onde o usuário pode vir de um dos dois lugares.
A primeira opção é definir uma tag de metadados de solicitação em cada chamada:
client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )
A segunda é confiar na captura automáticaidentity.arn, que funciona se o chamador assumir sua função de IAM com um por usuário. RoleSessionName Você calcula o custo a partir das contagens de tokens registradas. Se você também quiser dólares precisos na fatura por usuário, participe. Atribuição principal do IAM
P: Eu tenho um cenário específico. Qual método devo usar?
R: Combine seu cenário com um método usando a tabela a seguir.
| Cenário | Use |
|---|---|
| Você precisa dos gastos de cada equipe em sua fatura mensal. | Atribuição principal do IAM(tag por equipe), ou um marcado Projetos ou Perfis de inferência de aplicações |
| Você precisa de um custo por solicitação individual, por recurso. | Per-request marcação de metadadoscom registros de invocação do modelo |
| Você executa vários modelos e quer um intervalo de custos por aplicativo. | Projetosativado bedrock-mantle — um único projeto pode abranger vários modelos |
| Você usa nossa InvokeModel Converse e quer dólares por aplicativo. | Perfis de inferência de aplicações |
| Você enfrenta o Amazon Bedrock com um gateway que atende a muitos usuários. | Per-user sts:AssumeRolepara faturamento em dólares, além de Per-request marcação de metadados detalhes por solicitação |
P: Devo usar projetos ou perfis de inferência de aplicativos?
R: Ambos entregam dólares agregados no AWS Cost Explorer e no CUR. Escolha por endpoint e escala.
-
Perfis de inferência de aplicaçõesfuncionam no
bedrock-runtimeendpoint (InvokeModel e no Converse), mas são específicos do modelo. Você cria um perfil por modelo, para que a contagem de recursos aumente à medida que você adiciona modelos ou equipes. -
Projetostrabalha no
bedrock-mantleendpoint (respostas e conclusões de bate-papo), e um único projeto pode abranger vários modelos. Eles escalam melhor quando você tem muitos modelos por carga de trabalho, mas são somente para mantas.
Use Atribuição principal do IAM junto com qualquer um para obter detalhes por usuário.
Perguntas sobre o relatório de custo e uso
P: Qual é a diferença entre o CUR clássico e o CUR 2.0 para atribuição de custos?
R: As tags de alocação de custos ativadas deProjetos, Perfis de inferência de aplicaçõesEspaços de trabalho, e as tags principais do IAM aparecem tanto na CUR clássica quanto na CUR 2.0. A diferença é a coluna automática de identidade de chamadas que Atribuição principal do IAM funciona sem marcação. Essa coluna — os dados “quem fez a chamada” — existe somente em uma exportação CUR 2.0 (Exportações de AWS dados) com a opção de identidade do chamador selecionada. Se você quiser atribuição nativa por usuário em seus dados de item de linha, você precisa do CUR 2.0.
P: Posso ver o custo de uma solicitação individual no AWS Cost Explorer ou no CUR?
R: Não. Tanto o CUR clássico quanto o CUR 2.0 agregam o custo por tipo de uso em uma hora ou um dia, e nenhum deles carrega um identificador por solicitação em seus itens de linha. Per-prompt os detalhes residem apenas nos registros de invocação do modelo. Junte os registros ao CUR na granulação do modelo e do tipo de uso para reconciliação, não por um custo imediato.
P: Meus custos estão em CUR, mas minhas etiquetas e tokens estão em registros. Como faço para combiná-los?
R: Há dois padrões. Para obter totais precisos na fatura, junte os registros ao CUR imediatamente. model/usage type/day Para obter o custo por solicitação, calcule-o a partir das contagens de tokens registradas e das taxas publicadas por token. A consulta do CloudWatch Logs Insights a seguir produz os totais de tokens por usuário e por modelo que alimentam o cálculo:
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
O valor computado é uma estimativa. Ele não reflete descontos, compromissos, preços em lote, nível gratuito ou taxa de transferência provisionada, a menos que você os modele. Para obter detalhes, consulte Obtendo o custo de seus registros.
Como os mecanismos diferem
P: Qual é a diferença entre uma tag de sessão do IAM e os metadados de solicitação?
R: Encadernação e destino. Uma tag de sessão é definida uma vez sts:AssumeRole e é constante para cada chamada feita com as credenciais dessa sessão; ela aparece somente como dados de faturamento agregados no AWS Cost Explorer e no CUR (tanto o clássico CUR quanto o CUR 2.0). Os metadados da solicitação são definidos por chamada, variam de acordo com a solicitação e chegam aos seus registros de invocação.
Para atribuição por usuário e por solicitação, use metadados de solicitação. Para obter dólares por usuário na fatura, use tags de sessão ou confie no ARN da identidade do chamador.
P: Os metadados da solicitação aparecem na minha fatura?
R: Não. Os metadados de solicitação não são uma tag de alocação de custos. Ele é gravado somente nos registros de invocação do modelo e nunca aparece no AWS Cost Explorer ou no CUR. Use-o para análises operacionais e por solicitação e use um método nativo (como Atribuição principal do IAM ouProjetos) para dólares faturados.
Implementação
P: Como a atribuição funciona por trás de um gateway LLM?
R: O Amazon Bedrock registra o papel do gateway como a identidade do chamador. Para preservar a atribuição em nível de usuário, assuma a função por usuário, armazene em cache as credenciais durante a vida útil da sessão e passe o usuário como uma tag de sessão (para faturar dólares) and/or como RoleSessionName (para que o usuário acesse seus registros): identity.arn
sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )
Para obter detalhes por solicitação sem uma AWS STS chamada por solicitação, defina o usuário nos metadados da solicitação em cada chamada.
P: Posso exigir que todas as chamadas sejam marcadas?
R: Não do lado do Amazon Bedrock. Os metadados de solicitação são opcionais por chamada, e o Amazon Bedrock não rejeita chamadas que os omitem. Não é uma política de AWS tags, que rege apenas os recursos. Imponha a marcação em um cliente compartilhado ou gateway LLM que a carimba em todas as solicitações. Para atribuição que está sempre presente sem código por chamada, useAtribuição principal do IAM, pois a identidade do chamador é capturada automaticamente.
P: Quais campos eu defino em cada chamada e quais são automáticos?
R: Quase tudo no registro de log é capturado automaticamente pelo Amazon Bedrock:accountId,,,,region,modelId, requestIdidentity.arn, as contagens de tokens de entrada e saída e os metadados do esquema. O único campo que você fornece por chamada érequestMetadata. Você não define modelId como uma tag; é o modelo ou perfil de inferência que você invocou.
