Usar o processamento Flex com o Azure OpenAI no Microsoft Foundry Models (versão prévia)

O processamento flex (versão prévia) fornece inferência a um desconto de 50% em comparação com o processamento Standard para cargas de trabalho que podem tolerar tempos de resposta mais lentos e indisponibilidade ocasional de recursos. Selecione o processamento Flex para uma solicitação individual da Responses API ou da Chat Completions API ao definir service_tier como flex.

Use o processamento flex para trabalhos não interativos e de prioridade mais baixa, como avaliações de modelo, enriquecimento de dados, análise de documentos e fluxos de trabalho de aplicativo assíncronos. Para cargas de trabalho sensíveis à latência ou à capacidade, use o processamento Standard, o processamento de prioridade ou a taxa de transferência provisionada.

Pré-requisitos

• Uma assinatura do Azure. Criar um gratuitamente.

• Um recurso Azure OpenAI com um modelo com suporte implantado usando o tipo de implantação Global Standard.

• O ponto de extremidade do recurso e uma chave de API ou credenciais do Microsoft Entra ID. Os exemplos neste artigo usam uma chave de API armazenada na variável de AZURE_OPENAI_API_KEY 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 uma solicitação Flex

Defina service_tier como flex em cada solicitação que deve usar o processamento flex. O valor model é o nome da implantação do seu modelo no Azure.

Python

O exemplo a seguir envia uma solicitação Flex usando a API de Respostas:

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 a camada de serviço que processa a solicitação.

Referência:API de Responses

REST

O exemplo a seguir envia a mesma solicitação diretamente para a API de Respostas:

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 camada processa a solicitação, verifique o service_tier campo em uma resposta bem-sucedida.

Referência:referência REST da API de respostas

Escolher uma opção de processamento

O processamento flex, Standard e Priority são opções de camada de serviço para solicitações de API online. O processamento em lote e o provisionamento de taxa de transferência são opções de implantação e compra separadas.

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

• Sua carga de trabalho pode tolerar tempos de processamento mais longos e variáveis.
• Você prefere menor custo em vez de latência previsível.
• Seu aplicativo pode tentar novamente falhas transitórias ou rotear uma solicitação com falha para o processamento Standard.
• Há suporte para o modelo selecionado e o contexto de solicitação.

Não use o processamento Flex quando qualquer uma das condições a seguir se aplicar:

• Um usuário está aguardando uma resposta interativa.
• A solicitação deve ser concluída dentro de uma meta de latência rigorosa.
• Seu aplicativo não pode tolerar ou tentar novamente respostas HTTP 429 transitórias.
• Você precisa de capacidade de processamento reservada ou taxa de transferência previsível.

O processamento flex tem as seguintes características:

• Seleção no nível da solicitação: Defina service_tier para flex cada solicitação que deve usar o processamento Flex.
• Nenhuma implantação separada: Envie solicitações Standard e Flex para a mesma implantação Global Standard e selecione a camada por solicitação.
• APIs com suporte: Use a API de Respostas ou a API de Conclusões de Chat.
• Resposta síncrona: A chamada à API permanece síncrona, embora a carga de trabalho possa levar mais tempo para ser concluída. O processamento Flex não é o mesmo que a Batch API.
• Disponibilidade dependente da capacidade: Uma solicitação pode retornar HTTP 429 quando a capacidade flex não estiver disponível.
• Sem fallback automático para Standard: Seu aplicativo deve tentar novamente explicitamente com service_tier definido como default se o processamento Standard for aceitável.
• Cota compartilhada: As solicitações Flex e Standard usam a cota atribuída à implantação Global Standard.
• Mesma qualidade de saída do modelo: O Flex usa o mesmo modelo subjacente que o Standard. A camada de processamento altera a latência, a disponibilidade e o preço, não a qualidade do modelo.

Ver modelos compatíveis

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

Verifique esta tabela antes de enviar uma solicitação Flex. Não suponha que um modelo ou uma nova versão de modelo dê suporte ao processamento Flex porque ele dá suporte ao processamento Standard ou Priority. Um modelo sem suporte retorna HTTP 400. Para evitar interromper seu aplicativo, implemente um fallback no nível do aplicativo para o processamento Standard quando os preços e o desempenho padrão forem aceitáveis.

Voltar ao processamento Standard

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

O exemplo a seguir usa uma política que prioriza a conclusão. Primeiro, tenta o processamento Flex e faz uma nova tentativa usando o processamento Standard após receber 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 para o Standard altera as características de preço e desempenho da solicitação. Use esse padrão somente quando a carga de trabalho puder aceitar preços Padrão.

Uma resposta HTTP 429 pode indicar uma capacidade Flex indisponível ou um limite de cota. Como o processamento Flex e Standard compartilham a cota, a solicitação Standard também pode falhar quando a cota causou a resposta original. Aplique limites de novas tentativas e trate um segundo RateLimitError em seu aplicativo. Quando o serviço retorna o identificador de erro específico do Flex, use-o para limitar o recurso alternativo às respostas relacionadas à capacidade.

Para cargas de trabalho que priorizam o menor custo, tente novamente o processamento Flex com backoff exponencial antes de recorrer ao fallback. Para cargas de trabalho que priorizam o tempo de conclusão, reverta para Standard após o primeiro erro de capacidade Flex.

Referência:RateLimitError

Lidar com erros do Flex

Distinguir erros de solicitação permanente de erros transitórios de capacidade.

Use backoff exponencial com jitter aleatório para respostas HTTP 408, 429 e 5xx transitórias. Defina uma contagem máxima de repetição e um atraso máximo para que uma solicitação com falha não permaneça em um loop de repetição não associado.

1. Honra Retry-After quando a resposta a inclui.
2. Caso contrário, aguarde um atraso exponencialmente crescente com jitter aleatório.
3. Use o Retry Flex apenas enquanto o atraso for aceitável para a carga de trabalho.
4. Volte para Standard se o orçamento de repetição estiver esgotado e o aplicativo permitir o custo Padrão mais alto.
5. Retorne uma falha explícita se nem o processamento Flex atrasado nem o fallback Standard atenderem aos requisitos da aplicação.

Não tente repetidamente a mesma solicitação Flex sem suporte. Uma repetição só é bem-sucedida depois que você altera o modelo, o tamanho do contexto, a configuração da API ou a camada de serviço.

Monitorar o uso e os custos

Use as métricas do Azure Monitor para comparar o tráfego do Flex e do Standard na mesma implantação. Monitore o volume de solicitação, o consumo de token, a latência, as falhas e a taxa na qual as solicitações flex retornam ao Standard em seu aplicativo.

1. Entre no portal do Azure.

2. Vá para o recurso Azure OpenAI e selecione Métricas.

3. Adicione a métrica Azure OpenAI Requests. Você também pode adicionar Latência do Azure OpenAI, Uso do Azure OpenAI e métricas de erro.

4. Adicione um filtro em que ServiceTierRequest seja flexigual a .

   

5. Crie alertas para respostas HTTP 429 persistentes, aumento nas taxas de erro e latência que exceda o orçamento de novas tentativas da sua carga de trabalho.

Acompanhe os seguintes sinais para cada carga de trabalho:

Para obter mais informações sobre como monitorar implantações de modelo, consulte Monitor Azure OpenAI.

O uso flex é cobrado em medidores Flex dedicados para que você possa diferenciá-lo do uso Padrão. Use a Análise de Custo para examinar os custos do token Flex por recurso e implantação.

1. No portal do Azure, abra Gerenciamento de Custos + Cobrança>.
2. Filtre pela assinatura, grupo de recursos ou recurso do Azure OpenAI que contém a implantação.
3. Agrupar ou filtrar por Medidor para separar o uso Flex do uso Padrão.
4. Adicione um filtro de cobrança por tag, selecione implantação e escolha o nome da implantação.
5. Compare a economia de custos do Flex com os custos de contingência do Standard e os requisitos de finalização da carga de trabalho.

Os tokens flex de entrada e saída custam 50% dos preços padrão correspondentes. O armazenamento em cache de prompts pode reduzir ainda mais o custo dos tokens de entrada elegíveis armazenados em cache. Uma solicitação Flex rejeitada porque a capacidade de processamento não está disponível não é cobrada.

Aplicar práticas recomendadas de produção

• Defina um tempo limite maior. As solicitações flex podem levar mais tempo do que as solicitações Standard. Comece com um timeout do cliente adequado à sua carga de trabalho, como 15 minutos, e teste com prompts representativos.
• Use repetições com limite. Limite as tentativas de repetição e o tempo total decorrido.
• Adicione tremulação. Aleatorize os atrasos de backoff para evitar picos de novas tentativas sincronizadas.
• Torne o fallback explícito. Defina service_tier como default em vez de depender do comportamento implícito.
• Rastreie a camada processada. Registre o valor da resposta service_tier com latência, status, uso de token e dados de custo.
• Separar o tráfego interativo e em segundo plano. Mantenha as solicitações destinadas ao usuário em Standard, Priority ou taxa de transferência provisionada, a menos que a latência variável do Flex seja aceitável.
• Controle o trabalho duplicado. Garanta que o aplicativo não envie a mesma tarefa lógica mais de uma vez após expirações de tempo no lado do cliente.
• Teste os caminhos 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.
• Examine o suporte ao modelo antes das atualizações. Um modelo de substituição ou versão de modelo não herda automaticamente o suporte ao Flex.

Sobrescrever o nível de serviço usando um cabeçalho de solicitação

Use o cabeçalho da solicitação x-ms-service-tier quando um gateway, proxy ou uma camada de roteamento centralizada precisar selecionar a camada de serviço sem inspecionar ou modificar o corpo da solicitação. O cabeçalho também pode reduzir as alterações de migração para aplicativos que já selecionam uma camada de serviço OpenAI por meio de um cabeçalho de solicitação.

O cabeçalho aceita os seguintes valores:

Quando o cabeçalho está presente e é válido, ele tem precedência sobre o service_tier valor no corpo da solicitação.

Este exemplo solicita o processamento Flex por meio do cabeçalho. O cabeçalho substitui o valor default no corpo da solicitação:

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 sobreposição não fornece fallback automático. Um valor de cabeçalho inválido ou uma camada que a implantação selecionada não dá suporte retorna HTTP 400.

Conteúdo relacionado

• Habilitar o processamento de prioridade para modelos de Microsoft foundry
• Usar o processamento em lote global com Azure OpenAI
• Analise os tipos de implantação para modelos do Microsoft Foundry