View a markdown version of this page

Preguntas frecuentes - Amazon Bedrock

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Preguntas frecuentes

Esta sección responde a preguntas frecuentes sobre la elección y la combinación de los mecanismos de atribución de costes de Amazon Bedrock.

Elegir un método

P: Quiero una atribución por usuario y por mensaje. ¿Cuáles son mis opciones?

R: Utilice los registros de invocación del modelo, no los métodos basados en la facturación. Los métodos nativos (Atribución principal de IAM, ProyectosPerfiles de inferencia de aplicaciones, yEspacios de trabajo) solo generan dólares agregados en AWS Cost Explorer y CUR, nunca una fila por solicitud. La vista por mensaje solo existe en sus registros, donde el usuario puede proceder de dos lugares.

La primera opción consiste en establecer una etiqueta de metadatos de solicitud en cada llamada:

client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )

La segunda es confiar en la captura automáticaidentity.arn, que funciona si la persona que llama asume su función de IAM por usuario. RoleSessionName El costo se calcula a partir de los recuentos de tokens registrados. Si también quieres facturar en dólares por usuario con precisión, hazlo. Atribución principal de IAM

P: Tengo un escenario específico. ¿Qué método debo usar?

R: Haga coincidir su escenario con un método mediante la siguiente tabla.

Escenario Uso
Necesitas los gastos de cada equipo en tu factura mensual. Atribución principal de IAM(etiquetar por equipo), o una etiquetada Proyectos o Perfiles de inferencia de aplicaciones
Necesita el costo por mensaje individual, por función. Per-request etiquetado de metadatoscon registros de invocación de modelos
Ejecuta muchos modelos y desea un segmento de costes por aplicación. Proyectosactivadobedrock-mantle: un solo proyecto puede abarcar muchos modelos
Estás usando InvokeModel o Converse y quieres dinero por aplicación. Perfiles de inferencia de aplicaciones
Estás frente a Amazon Bedrock con una puerta de enlace que sirve a muchos usuarios. Per-user sts:AssumeRolepara facturar en dólares, además de Per-request etiquetado de metadatos los detalles por pedido

P: ¿Debo usar perfiles de inferencia de proyectos o aplicaciones?

R: Ambos entregan dólares agregados en AWS Cost Explorer y CUR. Elija por punto final y escala.

  • Perfiles de inferencia de aplicacionesfuncionan en el bedrock-runtime punto final (InvokeModel y en Converse), pero son específicos del modelo. Creas un perfil por modelo, por lo que el número de recursos aumenta a medida que agregas modelos o equipos.

  • Proyectostrabajan en el bedrock-mantle punto final (respuestas y finalizaciones de chat), y un solo proyecto puede abarcar varios modelos. Se escalan mejor cuando se tienen muchos modelos por carga de trabajo, pero solo son permanentes.

Atribución principal de IAMUtilícelos junto con cualquiera de ellos para obtener detalles por usuario.

Preguntas sobre el informe de costo y uso

P: ¿Cuál es la diferencia entre el CUR clásico y el CUR 2.0 en cuanto a la atribución de costes?

R: Las etiquetas de asignación de costes activadas deProyectos, Perfiles de inferencia de aplicacionesEspacios de trabajo, y las etiquetas principales de IAM aparecen tanto en el CUR clásico como en el CUR 2.0. La diferencia es que la columna de identidad automática de las personas que llaman funciona sin necesidad de etiquetar. Atribución principal de IAM Esa columna, los datos sobre «quién realizó la llamada», solo existe en una exportación CUR 2.0 (exportación de AWS datos) con la opción de identidad de la persona que llama seleccionada. Si quieres una atribución nativa por usuario en tus datos de partidas, necesitas CUR 2.0.

P: ¿Puedo ver el costo de un anuncio individual en AWS Cost Explorer o CUR?

R: No. Tanto el CUR clásico como el CUR 2.0 suman el costo por tipo de uso durante una hora o un día, y ninguno de los dos incluye un identificador por solicitud en sus líneas de pedido. Per-prompt Los detalles solo se encuentran en los registros de invocación de su modelo. Une los registros a CUR según el modelo y el tipo de uso para conciliarlos, no por un costo por solicitud.

P: Mis costos están en CUR, pero mis etiquetas y fichas están en registros. ¿Cómo los combino?

R: Hay dos patrones. Para obtener totales exactos en las facturas, combine los registros con el CUR en el nivel -. model/usage type/day Para calcular el costo por cotización, calcúlelo a partir de los recuentos de tokens registrados y las tarifas publicadas por token. La siguiente consulta de CloudWatch Logs Insights produce los totales de los tokens por usuario y por modelo que se utilizan para el 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

La cifra calculada es una estimación. No refleja los descuentos, los compromisos, los precios por lotes, el nivel gratuito ni el rendimiento aprovisionado, a menos que los modeles. Para obtener más información, consulte Cómo obtener el costo de sus registros.

En qué se diferencian los mecanismos

P: ¿Cuál es la diferencia entre una etiqueta de sesión de IAM y los metadatos de una solicitud?

R: Encuadernación y destino. Una etiqueta de sesión se establece una vez en sts:AssumeRole y es constante para cada llamada realizada con las credenciales de esa sesión; solo aparece como datos de facturación agregados en AWS Cost Explorer y CUR (tanto CUR clásico como CUR 2.0). Los metadatos de la solicitud se configuran por llamada, varían según la solicitud y se incluyen en los registros de invocaciones.

Para la atribución por usuario y por mensaje, usa los metadatos de la solicitud. Para obtener el dinero por usuario en la factura, usa etiquetas de sesión o confía en la identidad de la persona que llama (ARN).

P: ¿Los metadatos de la solicitud aparecen en mi factura?

R: No. Los metadatos de la solicitud no son una etiqueta de asignación de costes. Se escribe únicamente en los registros de invocación del modelo y nunca aparece en AWS Cost Explorer ni en CUR. Úselo para el análisis operativo y por solicitud, y utilice un método nativo (como Atribución principal de IAM oProyectos) para los dólares facturados.

Implementación

P: ¿Cómo funciona la atribución detrás de una pasarela LLM?

R: Amazon Bedrock registra la función de la pasarela como identidad de la persona que llama. Para preservar la atribución a nivel de usuario, asuma el rol por usuario, almacene en caché las credenciales durante la duración de la sesión y pase el usuario como etiqueta de sesión (para facturar dólares) and/or en vez de RoleSessionName (para que el usuario aparezca identity.arn en sus registros):

sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )

Para obtener detalles por mensaje sin necesidad de una AWS STS llamada por solicitud, configura el usuario en los metadatos de la solicitud para cada llamada.

P: ¿Puedo exigir que todas las llamadas estén etiquetadas?

R: No desde el lado de Amazon Bedrock. Los metadatos de las solicitudes son opcionales por llamada y Amazon Bedrock no rechaza las llamadas que los omiten. No se trata de una política de AWS etiquetas, que solo regula los recursos. Imponga el etiquetado en un cliente compartido o en una pasarela LLM que lo selle en cada solicitud. Para una atribución que esté siempre presente sin un código por llamada, utilízalaAtribución principal de IAM, ya que la identidad de la persona que llama se captura automáticamente.

P: ¿Qué campos configuro en cada llamada y cuáles son automáticos?

R: Amazon Bedrock captura automáticamente casi todo el contenido del registro:accountId,,,,,, region modelId requestIdidentity.arn, los recuentos de los tokens de entrada y salida y los metadatos del esquema. El único campo que debe proporcionar por llamada esrequestMetadata. No lo estableces modelId como una etiqueta; es el modelo o perfil de inferencia que has invocado.