Visão geral do custo do otimizador de agentes e da utilização de tokens

O otimizador de agentes no Foundry Agent Service fornece uma estimativa de custo modelada antes de submeter um trabalho de otimização. Após a conclusão do trabalho, o respetivo resultado pode incluir a utilização medida de tokens. Use a estimativa para planeamento e a utilização medida para compreender a atividade do modelo que ocorreu durante a execução.

A estimativa antes da execução e a utilização de tokens após a execução têm finalidades diferentes. Nenhum dos valores é um limite de despesas ou uma substituição da sua fatura Azure.

Estimativa de custos antes da execução para agentes de prompt

Antes de criar um trabalho de otimização de prompt-agent no portal Foundry, a etapa Revisão mostra uma estimativa de custo para as configurações solicitadas. Os fluxos de otimização com agente hospedado não mostram atualmente esta estimativa pré-execução.

A estimativa prevê chamadas ao modelo e custos dos tokens. Pedir uma estimativa não cria um trabalho de otimização nem invoca os modelos. As contagens de chamadas são calculadas a partir dos dados de entrada da tarefa. Os valores monetários são estimados aplicando pressupostos estáticos relativos aos tokens e preços de referência dos modelos a essas contagens de chamadas.

O portal mostra três valores monetários modelados:

O resumo identifica a contagem de candidatos, a contagem de linhas do conjunto de dados, a contagem de avaliadores e a data do preço de referência. Expandir a divisão de custos (estimada) para rever cada fase.

Entradas para a estimativa

O otimizador calcula os intervalos de contagem de chamadas a partir da configuração da tarefa já resolvida. O cálculo utiliza estas entradas:

Para um conjunto de dados referenciado, o serviço resolve a contagem de linhas antes de devolver uma estimativa. Se não conseguir resolver uma contagem de linhas não vazia, não cria uma estimativa a partir do tamanho assumido do conjunto de dados.

Para execuções de seleção de modelos, a estimativa não calcula em separado o custo das chamadas do agente de todos os modelos no espaço de pesquisa. Utiliza o modelo de agente base configurado quando disponível. Se esse modelo não puder ser resolvido, é utilizado o preço do modelo de avaliação para a camada do agente.

Suposições estáticas de tokens

A estimativa separa a atividade do modelo em camadas para que possa ver qual a parte da execução que contribui para o total. Utiliza as seguintes suposições estáticas TokensPerCall :

Estas suposições geridas pelo serviço podem mudar à medida que o estimador é calibrado. Para cada camada, o otimizador multiplica o intervalo do número de chamadas pelos pressupostos estáticos do prompt e dos tokens de conclusão. Depois, aplica-se preços de referência datados por um milhão de tokens:

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

O total é a soma das camadas que podem ser precificadas. Se não estiver disponível uma suposição de preço de modelo ou token para uma camada, a estimativa identifica a camada não precificada e exclui-la do total.

O que acontece durante uma execução de otimização

Para compreender as camadas de custo, é útil saber como o otimizador utiliza cada modelo nos bastidores. Uma execução de otimização segue este ciclo tanto para agentes de prompt como para agentes alojados:

1. Avalie a linha de base (agente + juiz). O otimizador invoca o seu agente em cada linha do conjunto de dados para recolher respostas. Depois, o modelo de avaliação avalia cada resposta em relação a cada avaliador para estabelecer as pontuações de referência.
2. Gerar um candidato (reflexão). O modelo de otimização recebe as pontuações base, analisa as fraquezas e produz uma configuração melhorada do agente. Dependendo do tipo de agente, a configuração pode incluir instruções reescritas, competências refinadas, melhores descrições de ferramentas ou um modelo diferente.
3. Avaliar o candidato (agente + juiz). O otimizador executa o agente com a configuração candidata nas mesmas linhas do conjunto de dados e pontua as respostas.
4. Repita. Os passos 2–3 repetem-se para cada candidato adicional. Cada ciclo acrescenta mais uma ronda de chamadas de reflexão e avaliação.

As três camadas de custo correspondem diretamente a este ciclo:

• Executar o seu agente — sempre que o agente é invocado contra uma linha de conjunto de dados (linha de base e cada candidato).
• Classificação das respostas — sempre que o modelo de avaliação classifica uma resposta com base num avaliador.
• Gerar melhorias — sempre que o modelo de otimização reflete os resultados e produz um novo candidato.

Exemplo prático: execução com 2 candidatos máximos

O exemplo seguinte mostra como a fórmula se aplica a uma configuração concreta de tarefa. Todos os preços são apenas para ilustração.

Definições do trabalho:

Número estimado de chamadas:

O otimizador deriva as contagens de chamadas a partir da configuração do trabalho:

Aplique a fórmula a cada camada:

O otimizador consulta os preços de entrada e saída de referência datados para cada modelo e aplica a fórmula. Por exemplo, o cálculo da camada de agentes é:

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

O mesmo padrão aplica-se às camadas juiz e de reflexão, cada uma usando as suposições dos tokens e os preços de referência para o seu respetivo modelo. O portal soma então todas as camadas para produzir os valores Mínimo, Estimado e Máximo apresentados na etapa de Revisão .

Numa execução típica de 2 candidatos, a camada de reflexão (modelo de otimização) representa a maior fatia do custo estimado porque utiliza um modelo mais capaz com taxas por token mais elevadas. A camada de juízes é geralmente a mais barata porque utiliza um modelo de avaliação mais pequeno com baixas suposições de token por chamada.

Suposições e limitações de estimativa

A estimativa é um valor de planeamento e não uma cobrança final, pois combina um orçamento de chamadas algorítmico com a utilização modelada de tokens.

• As suposições de tokens são médias para cada camada de custo. O número real de prompts, respostas, raciocínios e tokens em cache variam consoante o modelo e o pedido.
• Um trabalho de otimização pode parar cedo depois de não encontrar melhorias adicionais. Parar cedo pode reduzir o consumo real abaixo do valor estimado ou máximo .
• A utilização do agente varia consoante as instruções, os turnos de conversa, o comprimento da resposta, as chamadas de ferramentas e a saída da ferramenta.
• Os preços dos modelos de referência são datados e podem diferir dos preços da sua subscrição, região, tipo de implementação ou acordo.
• O orçamento não inclui encargos de APIs externas, bases de dados, serviços de pesquisa ou outras ferramentas que o seu agente utiliza.
• O valor máximo não é um limite de gasto.

Utilização de tokens medida após a execução

Quando um trabalho de otimização termina, o seu resultado pode incluir o uso medido de tokens para cada fase da execução. A visualização da utilização de tokens pode estar disponível tanto para execuções do prompt-agent como do hosted-agent.

Para agentes alojados, a utilização de Executar o seu agente só está disponível quando a amostra de avaliação ou o rastreamento do agente inclui informações sobre a utilização de tokens. Se o agente hospedado não reportar o uso, o portal omite a fase do agente em vez de a reportar como zero. O portal regista separadamente a utilização de respostas de pontuação e de geração de melhorias quando essas chamadas de modelo comunicam dados de utilização.

A vista pode conter várias linhas para Executar o seu agente quando o otimizador avalia múltiplos modelos de agentes.

O portal calcula um custo estimado a partir do uso medido dos tokens e dos preços dos modelos de referência. Selecionar Ver preços para rever a fonte de preços. A estimativa não corresponde ao montante final faturado.

A ausência de um valor da fase ou do token significa que o uso não foi medido. Isto não significa que a fase tenha usado zero tokens ou que não tenha havido qualquer custo. Alguns agentes alojados e tarefas de otimização mais antigas poderão não fornecer informações sobre a utilização dos agentes.

O resultado subjacente da tarefa pode conter mais detalhes sobre tokens em cache e tokens de raciocínio. Os tokens em cache são um subconjunto dos tokens de entrada, e os tokens de raciocínio são um subconjunto dos tokens de saída. Não adicione estes valores de subconjuntos aos totais de entrada ou saída.

Calcular o custo do modelo a partir do uso medido

A utilização medida de tokens é mais representativa do que os pressupostos prévios à execução, mas indica o número de tokens em vez do valor final faturado. Aplique o preço de cada linha do modelo para aproximar o custo do modelo:

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

Se o uso detalhado fornecer um número de tokens em cache e o modelo tiver uma tarifa separada para entrada em cache, subtraia os tokens em cache do total de entrada e calcule separadamente o preço das parcelas em cache e não em cache.

Calcule cada fase e cada linha do modelo separadamente e depois adicione os resultados. Se uma linha não identificar um modelo, não pode aplicar de forma fiável um preço específico de implementação a esse uso.

Use as tarifas que se aplicam à sua subscrição, região, tipo de implementação e acordo de faturação. Para tarifas publicadas, consulte os preços do Azure OpenAI Service. O resultado ainda exclui os custos de ferramentas e serviços externos.

Conteúdo relacionado

• Visão geral do otimizador de agentes
• Quickstart: Otimize um agente de prompts
• Quickstart: Otimizar um agente hospedado