Utilizar o processamento Flex com o Azure OpenAI no Microsoft Foundry Models (pré-visualização)

O processamento flexível (pré-visualização) oferece inferência com um desconto de 50% em comparação com o processamento padrão para cargas de trabalho que toleram tempos de resposta mais lentos e indisponibilidade ocasional de recursos. Selecione o processamento Flex para um pedido individual de API de Respostas ou API de Completação de Chat, definindo service_tier para flex.

Use o processamento Flex para trabalhos não interativos e de menor prioridade, como avaliações de modelos, enriquecimento de dados, análise de documentos e fluxos de trabalho assíncronos de aplicação. Para cargas de trabalho sensíveis à latência ou à capacidade, utilize-se processamento Standard, processamento Prioritário ou throughput provisionado.

Pré-requisitos

• Uma assinatura do Azure. Crie um gratuitamente.

• Um recurso Azure OpenAI com um modelo suportado implementado utilizando o tipo de implementação Global Standard.

• O ponto final do recurso e uma chave de API ou credenciais do Microsoft Entra ID. Os exemplos neste artigo utilizam uma chave API armazenada na AZURE_OPENAI_API_KEY variável de ambiente.

• Uma carga de trabalho que pode tolerar latência variável e respostas transitórias de indisponibilidade de recursos.

• Python 3.10 ou posterior e o pacote Python OpenAI para os exemplos de Python:

  pip install --upgrade openai
  

Enviar um pedido Flex

Defina service_tier como flex em cada pedido que deva utilizar o processamento Flex. O model valor é o nome da implementação do seu modelo Azure.

Python

O exemplo seguinte envia um pedido Flex usando a API Responses:

import os

from openai import OpenAI

AZURE_OPENAI_ENDPOINT = "https://YOUR-RESOURCE-NAME.openai.azure.com"

# Create a client with a longer timeout for Flex requests.
openai = OpenAI(
    base_url=f"{AZURE_OPENAI_ENDPOINT}/openai/v1/",
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
    timeout=900.0,
)

# Send a request for Flex processing.
response = openai.responses.create(
    model="YOUR-GPT-5.6-SOL-DEPLOYMENT-NAME",
    input="Analyze these records and summarize the recurring themes.",
    service_tier="flex",
)

print(response.output_text)
print(f"Processed by service tier: {response.service_tier}")

<generated-analysis>
Processed by service tier: flex

A resposta contém a análise gerada e o nível de serviço que processa o pedido.

Referência:API de Respostas

REST

O exemplo seguinte envia o mesmo pedido diretamente para a API Responses:

curl -X POST https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/responses \
  -H "Content-Type: application/json" \
  -H "api-key: $AZURE_OPENAI_API_KEY" \
  -d '{
    "model": "YOUR-GPT-5.6-SOL-DEPLOYMENT-NAME",
    "input": "Analyze these records and summarize the recurring themes.",
    "service_tier": "flex"
  }'

{
    "service_tier": "flex",
    "status": "completed",
    "output": [<response-output>]
}

Para verificar qual o nível que processa o pedido, verifique o service_tier campo numa resposta bem-sucedida.

Referência:Referência da API Responses REST

Escolha uma opção de processamento

Flex, Standard e Priority Processing são opções de nível de serviço para pedidos de API online. O throughput por lote e provisionado são opções separadas de implementação e compra.

Escolha o processamento Flex quando todas as seguintes condições se aplicarem:

• A sua carga de trabalho pode tolerar tempos de processamento mais longos e variáveis.
• Prefere um custo mais baixo a uma latência previsível.
• A sua aplicação pode tentar novamente falhas transitórias ou encaminhar um pedido falhado para o processamento Standard.
• O modelo selecionado e o contexto do pedido são suportados.

Não utilize processamento Flex quando se aplicar qualquer uma das seguintes condições:

• Um utilizador está à espera de uma resposta interativa.
• O pedido deve ser concluído dentro de um objetivo de latência rigoroso.
• A sua aplicação não consegue tolerar nem tentar novamente respostas HTTP 429 transitórias.
• Necessita de capacidade de processamento reservada ou capacidade de processamento previsível.

O processamento flexível apresenta as seguintes características:

• Seleção ao nível do pedido: Definir service_tier para flex em cada pedido que deva usar processamento Flex.
• Sem implementação separada: Envie pedidos Standard e Flex para a mesma implementação Global Standard e selecione o nível por pedido.
• APIs suportadas: Use a API de Respostas ou a API de Completação de Chat.
• Resposta síncrona: A chamada API mantém-se síncrona, mesmo que a carga de trabalho possa demorar mais a ser concluída. O processamento Flex não é o mesmo que a API Batch.
• Disponibilidade dependente da capacidade: Um pedido pode devolver HTTP 429 quando a capacidade Flex não está disponível.
• Sem alternativa automática do Padrão: A sua aplicação deve tentar explicitamente com service_tier definido para default se o processamento Padrão for aceitável.
• Quota partilhada: Os pedidos Flex e Standard utilizam a quota atribuída à implementação Global Standard.
• Mesma qualidade de saída do modelo: O Flex utiliza o mesmo modelo subjacente que o Standard. O nível de processamento altera a latência, disponibilidade e preço, não a qualidade do modelo.

Rever modelos suportados

O processamento Flex tem disponibilidade limitada de modelos no lançamento. gpt-5.6-sol é o primeiro modelo suportado. A tabela a seguir lista os modelos suportados. A Microsoft adiciona mais modelos à medida que o suporte se torna disponível.

Verifique esta tabela antes de enviar um pedido Flex. Não assuma que um modelo ou uma nova versão do modelo suporta processamento Flex porque suporta processamento Standard ou Priority. Um modelo não suportado devolve HTTP 400. Para evitar perturbar a sua aplicação, implemente um recurso de recurso ao nível da aplicação para o processamento Padrão quando o preço e o desempenho Padrão forem aceitáveis.

Regresso ao processamento padrão

O processamento Flex não encaminha automaticamente um pedido para o Standard quando a capacidade Flex não está disponível. Se concluir o pedido for mais importante do que manter o preço Flex, tente novamente o pedido com service_tier definido como default.

O exemplo seguinte utiliza uma política de conclusão em primeiro lugar. Primeiro tenta o processamento Flex e tenta novamente uma vez com o processamento Standard após qualquer resposta HTTP 429:

import os

from openai import OpenAI, RateLimitError

AZURE_OPENAI_ENDPOINT = "https://YOUR-RESOURCE-NAME.openai.azure.com"

# Create a client with a longer timeout for Flex requests.
openai = OpenAI(
    base_url=f"{AZURE_OPENAI_ENDPOINT}/openai/v1/",
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
    timeout=900.0,
)

request = {
    "model": "YOUR-GPT-5.6-SOL-DEPLOYMENT-NAME",
    "input": "Analyze these records and summarize the recurring themes.",
}

# Try Flex processing, and fall back to Standard after an HTTP 429 response.
try:
    response = openai.responses.create(**request, service_tier="flex")
except RateLimitError:
    response = openai.responses.create(**request, service_tier="default")

print(response.output_text)
print(f"Processed by service tier: {response.service_tier}")

<generated-analysis>
Processed by service tier: <flex-or-default>

O Fallback to Standard altera as características de preços e desempenho do pedido. Use este padrão apenas quando a carga de trabalho puder aceitar preços padrão.

Uma resposta HTTP 429 pode indicar capacidade Flex indisponível ou um limite de quota. Como o Flex e o Standard partilham a mesma quota, o pedido Standard também pode falhar quando a resposta original tiver sido causada pela quota. Aplique limites de novas tentativas e trate de um segundo RateLimitError na sua aplicação. Quando o serviço devolver o identificador de erro específico do Flex, utilize-o para limitar o recurso a respostas relacionadas com a capacidade.

Para cargas de trabalho que priorizam o custo mais baixo, tente novamente o processamento Flex com recuo exponencial antes de recuar. Para cargas de trabalho que dão prioridade ao tempo de conclusão, recorra ao Standard após o primeiro erro de capacidade do Flex.

Referência:RateLimitError

Tratar erros do Flex

Distinga os erros permanentes de solicitação dos erros transitórios de capacidade.

Utilize retrocesso exponencial com jitter aleatório para respostas HTTP 408, 429 e respostas 5xx transitórias. Define um número máximo de tentativas e um atraso máximo para que um pedido falhado não fique num ciclo de retentativas ilimitado.

1. Respeita Retry-After quando a resposta o incluir.
2. Caso contrário, aguarde um intervalo de espera exponencialmente crescente com variação aleatória.
3. Utilize Retry Flex apenas enquanto o atraso se mantiver aceitável para a carga de trabalho.
4. Recorra ao Standard se o limite de tentativas estiver esgotado e a aplicação permitir o custo mais elevado do Standard.
5. Devolve uma falha explícita se nem o processamento Flex atrasado nem o recurso-Padrão cumprirem os requisitos da aplicação.

Não tentes repetidamente o mesmo pedido Flex não suportado. Uma retentativa só tem sucesso depois de alterar o modelo, o comprimento do contexto, a configuração da API ou o nível de serviço.

Monitorizar a utilização e os custos

Use métricas do Azure Monitor para comparar o tráfego Flex e Standard na mesma implementação. Monitorize o volume de pedidos, o consumo de tokens, a latência, as falhas e a taxa a que os pedidos Flex regressam ao Standard na sua aplicação.

1. Inicie sessão no portal Azure.

2. Vá ao seu recurso Azure OpenAI e selecione Métricas.

3. Adicione a métrica Azure OpenAI Requests. Também pode adicionar Azure OpenAI Latency, Azure OpenAI Usage e métricas de erro.

4. Adicione um filtro onde ServiceTierRequest seja flexigual a .

   

5. Crie alertas para respostas HTTP 429 persistentes, aumento das taxas de erro e latência superior ao orçamento de novas tentativas da sua carga de trabalho.

Acompanhe os seguintes sinais para cada carga de trabalho:

Para mais informações sobre monitorização de implementações de modelos, consulte Monitorizar Azure OpenAI.

A utilização do Flex é faturada em contadores dedicados do Flex, para que o possa distinguir da utilização Standard. Use a Análise de Custos para rever os custos dos tokens Flex por recursos e implementação.

1. No portal do Azure, abra Gestão de Custos + Faturação>Análise de custos.
2. Filtre pela subscrição, pelo grupo de recursos ou pelo recurso Azure OpenAI que contém a implementação.
3. Agrupar ou filtrar por Medidor para separar a utilização Flex da utilização Standard.
4. Adicione um filtro de faturação por Etiqueta, selecione implementação e escolha o nome da implementação.
5. Compare as poupanças do Flex com os custos de recurso ao Standard e os requisitos de conclusão da carga de trabalho.

Os tokens de entrada e saída flexíveis são avaliados a 50% das taxas padrão correspondentes. O armazenamento em cache de prompts pode reduzir ainda mais o custo dos tokens de entrada elegíveis armazenados em cache. Um pedido Flex rejeitado porque a capacidade de processamento não está disponível não é faturado.

Aplicar as melhores práticas de produção

• Defina um tempo limite mais alargado. Os pedidos Flex podem demorar mais do que os pedidos Standard. Comece com um timeout para o cliente adequado à sua carga de trabalho, como 15 minutos, e teste com prompts representativos.
• Utilizar um número limitado de tentativas. Limitar as tentativas de repetição e o tempo total decorrido.
• Adiciona tremor. Aleatorize os tempos de espera de recuo para evitar picos sincronizados de novas tentativas.
• Torne explícita a solução de recurso. Defina service_tier como default em vez de depender do comportamento implícito.
• Acompanhe o escalão processado. Registar o valor da resposta service_tier com latência, estado, utilização de tokens e dados de custo.
• Separe o tráfego interativo e o de fundo. Mantenha os pedidos visíveis para o utilizador no modo Standard, Priority ou de débito aprovisionado, a menos que a latência variável do Flex seja aceitável.
• Controla o trabalho duplicado. Garanta que a aplicação não submeta a mesma tarefa lógica várias vezes após timeouts do lado do cliente.
• Teste os cenários de falha. Valide o tratamento para respostas HTTP 400, 408, 429 e transitórias 5xx antes de usar o processamento Flex em fluxos de trabalho de produção.
• Revise o suporte ao modelo antes das atualizações. Um modelo ou versão de substituição não herda automaticamente o suporte Flex.

Sobrepor o nível de serviço com um cabeçalho de pedido

Utilize o cabeçalho x-ms-service-tier do pedido quando um gateway, proxy ou camada centralizada de encaminhamento precisar de selecionar o nível de serviço sem inspecionar ou modificar o corpo do pedido. O cabeçalho também pode reduzir alterações de migração para aplicações que já selecionam um nível de serviço OpenAI através de um cabeçalho de pedido.

O cabeçalho aceita os seguintes valores:

Quando o cabeçalho está presente e válido, tem prioridade sobre o service_tier valor no corpo do pedido.

Este exemplo solicita processamento Flex através do cabeçalho. O cabeçalho substitui o valor default no corpo do pedido:

curl -X POST https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/responses \
  -H "Content-Type: application/json" \
  -H "api-key: $AZURE_OPENAI_API_KEY" \
  -H "x-ms-service-tier: flex" \
  -d '{
    "model": "YOUR-GPT-5.6-SOL-DEPLOYMENT-NAME",
    "input": "Analyze these records and summarize the recurring themes.",
    "service_tier": "default"
  }'

{
    "service_tier": "flex",
    "status": "completed",
    "output": [<response-output>]
}

O cabeçalho de substituição não fornece uma alternativa automática. Um valor de cabeçalho inválido ou um nível que a implementação selecionada não suporta devolve HTTP 400.

Conteúdo relacionado

• Ativar o processamento prioritário para modelos Microsoft Foundry
• Utilizar o processamento em lote global com o Azure OpenAI
• Revise os tipos de implementação para os modelos Microsoft Foundry