Información general sobre el costo y el uso de tokens del optimizador de agentes

El optimizador de agentes de Foundry Agent Service proporciona una estimación modelada de los costes antes de que envíe un trabajo de optimización. Una vez finalizado el trabajo, su resultado puede incluir el uso medido del token. Use la estimación para planificar y el uso registrado para comprender la actividad del modelo durante la ejecución.

La estimación de ejecución previa y el uso del token posterior a la ejecución sirven para diferentes propósitos. Ninguno de los valores es un límite de gasto o un reemplazo de la factura de Azure.

Estimación de costes antes de la ejecución para agentes de solicitudes

Antes de crear un trabajo de optimización de prompt-agent en el portal de Foundry, el paso Revisión muestra una estimación de costos para la configuración solicitada. Los flujos de optimización del agente hospedado no muestran actualmente esta estimación previa a la ejecución.

La estimación calcula las llamadas al modelo y los costes por tokens. Solicitar una estimación no crea un trabajo de optimización ni invoca los modelos. El número de llamadas se calcula a partir de los datos de entrada del trabajo. Los valores monetarios se modelan aplicando suposiciones estáticas sobre los tokens y precios de referencia del modelo a esos recuentos de llamadas.

En el portal se muestran tres valores de moneda modelados:

El resumen identifica el recuento de candidatos, el recuento de filas del conjunto de datos, el recuento del evaluador y la fecha de precio de referencia. Expanda Desglose de costos (estimado) para revisar cada fase.

Entradas para la estimación

El optimizador calcula los rangos de número de llamadas a partir de la configuración resuelta del trabajo. El cálculo usa estas entradas:

Para un conjunto de datos al que se hace referencia, el servicio resuelve su recuento de filas antes de devolver una estimación. Si no puede resolver un recuento de filas no vacías, no crea una estimación a partir de un tamaño de conjunto de datos asumido.

En las ejecuciones de selección de modelos, la estimación no calcula por separado el coste de las llamadas al agente para cada modelo del espacio de búsqueda. Usa el modelo de agente de línea base configurado cuando está disponible. Si no se puede determinar ese modelo, se utiliza el precio del modelo de evaluación para la capa del agente.

Suposiciones sobre tokens estáticos

La estimación separa la actividad del modelo en capas para que pueda ver qué parte de la ejecución contribuye al total. Usa las siguientes suposiciones estáticas TokensPerCall :

Estas suposiciones administradas por el servicio pueden cambiar a medida que se calibra el estimador. Para cada capa, el optimizador multiplica el rango del número de llamadas por las suposiciones estáticas sobre los tokens de entrada y de salida. A continuación, aplica precios de referencia con fecha por millón de tokens:

modeled layer cost = calls × ((prompt tokens × input price) + (completion tokens × output price)) / 1,000,000

El total es la suma de las capas a las que se les puede asignar un precio. Si un precio de modelo o una suposición de token no está disponible para una capa, la estimación identifica la capa sin precios y la excluye del total.

¿Qué ocurre durante una ejecución de optimización?

Para comprender las capas de costo, ayuda a saber cómo usa el optimizador cada modelo en segundo plano. Un proceso de optimización sigue este bucle tanto para los agentes de indicaciones como para los agentes alojados:

1. Evalúe la línea base (agente + juez). El optimizador invoca al agente en cada fila del conjunto de datos para recopilar respuestas. A continuación, el modelo de evaluación asigna una puntuación a cada respuesta según cada evaluador para establecer puntuaciones de referencia.
2. Generar un candidato (reflexión). El modelo de optimización recibe las puntuaciones de línea base, analiza las debilidades y genera una configuración mejorada del agente. En función del tipo de agente, la configuración puede incluir instrucciones reescritas, aptitudes refinadas, mejores descripciones de herramientas o un modelo diferente.
3. Evalúe el candidato (agente + juez). El optimizador ejecuta el agente con la configuración candidata en las mismas filas del conjunto de datos y puntúa las respuestas.
4. Repita. Los pasos 2–3 se repiten para cada candidato adicional. Cada ciclo agrega otra ronda de llamadas de reflexión y evaluación.

Las tres capas de costes se corresponden directamente con este bucle:

• Ejecutar el agente : cada vez que se invoca al agente en una fila del conjunto de datos (línea base y cada candidato).
• Puntuación de respuestas — cada vez que el modelo de evaluación evalúa una respuesta con respecto a un evaluador.
• Generación de mejoras : cada vez que el modelo de optimización refleja los resultados y genera un nuevo candidato.

Ejemplo trabajado: ejecución de 2-max-candidate

En el ejemplo siguiente se muestra cómo se aplica la fórmula a una configuración de trabajo concreta. Todos los precios son solo para ilustración.

Configuración del trabajo:

Recuentos estimados de llamadas:

El optimizador obtiene el número de llamadas a partir de la configuración de la tarea:

Aplique la fórmula a cada capa:

El optimizador busca los precios de entrada y salida de referencia con fecha para cada modelo y aplica la fórmula. Por ejemplo, el cálculo de la capa del agente es:

60 × ((2,000 × <input price>) + (400 × <output price>)) / 1,000,000

El mismo patrón se aplica a la capa de evaluación y a las capas de reflexión; cada una de ellas utiliza los supuestos de tokens y los precios de referencia del modelo correspondiente. A continuación, el portal suma todas las capas para generar los valores Mínimo, Estimado y Máximo que se muestran en el paso Revisar .

En una ejecución típica de 2 candidatos, la capa de reflexión (modelo de optimización) tiene en cuenta la mayor parte del costo estimado porque usa un modelo más capaz con mayores tasas por token. Normalmente, la capa de juez es la menos costosa, ya que utiliza un modelo de evaluación más pequeño con una estimación baja de tokens por llamada.

Suposiciones y limitaciones de estimación

La estimación es un valor de planificación en lugar de un cargo final porque combina un presupuesto de llamadas algorítmicas con el uso del token modelado.

• Las suposiciones de token son promedios para cada capa de costo. Los recuentos reales de mensajes, respuestas, razonamientos y tokens almacenados en caché varían según el modelo y la solicitud.
• Un trabajo de optimización puede detenerse temprano después de que no encuentre ninguna mejora adicional. La detención temprana puede reducir el uso real por debajo del valor Estimado o Máximo .
• El uso del agente varía en función de las instrucciones, los turnos de conversación, la longitud de la respuesta, las llamadas a herramientas y los resultados de las herramientas.
• Los precios del modelo de referencia están fechados y pueden diferir de los precios de su suscripción, región, tipo de implementación o contrato.
• La estimación no incluye cargos de API externas, bases de datos, servicios de búsqueda u otras herramientas a las que llama el agente.
• El valor Máximo no es un límite de gasto.

Uso del token medido posterior a la ejecución

Cuando finaliza un trabajo de optimización, su resultado puede incluir el uso medido de tokens para cada fase de la ejecución. La vista Uso de tokens puede estar disponible tanto para las ejecuciones de prompt-agent como para las de hosted-agent.

En el caso de los agentes hospedados, la ejecución del uso del agente solo está disponible cuando el ejemplo de evaluación o seguimiento del agente incluye información de uso de tokens. Si el agente hospedado no notifica el uso, el portal omite la fase del agente en lugar de notificarlo como cero. El portal registra por separado el uso de respuestas de puntuación y generación de mejoras cuando esas llamadas al modelo informan del uso.

La vista puede contener varias filas para Ejecutar el agente cuando el optimizador evalúa varios modelos de agente.

El portal calcula un costo estimado a partir del uso de tokens medido y los precios del modelo de referencia. Seleccione Ver precios para revisar el origen de precios. La estimación no es el importe final facturado.

Un valor de token o fase que falta significa que el uso no se ha medido. No significa que la fase haya usado cero tokens ni que haya supuesto ningún cargo. Es posible que algunos agentes alojados y trabajos de optimización más antiguos no proporcionen información sobre el uso del agente.

El resultado del trabajo subyacente puede contener más detalles del token almacenado en caché y del token de razonamiento. Los tokens almacenados en caché son un subconjunto de tokens de entrada y los tokens de razonamiento son un subconjunto de tokens de salida. No agregue estos valores de subconjunto a los totales de entrada o salida.

Cálculo del costo del modelo a partir del uso medido

El uso medido de tokens es más representativo que los supuestos de ejecución previa, pero notifica los recuentos de tokens en lugar del importe facturado final. Aplique los precios de cada fila de modelo para aproximar el costo del modelo:

approximate model cost = ((input tokens × input price) + (output tokens × output price)) / 1,000,000

Si el uso detallado proporciona un recuento de tokens almacenados en caché y el modelo tiene una tarifa independiente para entrada en caché, resta los tokens almacenados en caché del total de entrada y calcula por separado el precio de las porciones almacenadas en caché y no almacenadas en caché.

Calcule cada fase y fila del modelo por separado y agregue los resultados. Si una fila no identifica un modelo, no puede aplicar de forma confiable un precio específico de la implementación a ese uso.

Use las tarifas que se aplican a su suscripción, región, tipo de implementación y contrato de facturación. Para obtener tarifas publicadas, consulte precios de Azure OpenAI Service. El resultado sigue excluyendo los cargos de herramientas y servicios externos.

Contenido relacionado

• Introducción al optimizador de agentes
• Inicio rápido: Optimizar un agente de prompts
• Inicio rápido: Optimización de un agente hospedado