Compartilhar via

O que é taxa de transferência provisionada?

  • Artigo

Observação

Se você estiver procurando o que foi alterado recentemente com a oferta de taxa de transferência provisionada, confirao artigo de atualização para obter mais informações.

A oferta de taxa de transferência provisionada é um tipo de implantação de modelo que permite especificar a quantidade de taxa de transferência necessária em uma implantação de modelo. O Azure OpenAI aloca a capacidade de processamento de modelo necessária e garante que ele esteja pronto para você. A taxa de transferência provisionada fornece:

  • Desempenho previsível: latência máxima estável e taxa de transferência para cargas de trabalho uniformes.
  • Capacidade de processamento reservada: uma implantação configura a quantidade de taxa de transferência. Uma vez implantada, a taxa de transferência estará disponível, sendo usada ou não.
  • Economia de custos: as cargas de trabalho com alta taxa de transferência podem oferecer economia de custos em comparação com o consumo baseado em token.

Dica

Quando usar a taxa de transferência provisionada

Você deve considerar mudar de implantações padrão para implantações gerenciadas provisionadas quando tiver requisitos de taxa de transferência e latência bem definidos e previsíveis. Normalmente, isso ocorre quando o aplicativo está pronto para produção ou já foi implantado em produção e há uma compreensão do tráfego esperado. Isso permite que os usuários preveem com precisão a capacidade necessária e evitem cobranças inesperadas. Implantações gerenciadas provisionadas também são úteis para aplicativos com requisitos sensíveis de tempo real/latência.

Conceitos principais

PTUs (Unidades de produtividade provisionada)

As unidades de produtividade provisionadas (PTUs) são unidades genéricas de capacidade de processamento de modelo que você pode usar para dimensionar implantações provisionadas para atingir a taxa de transferência necessária para processar prompts e gerar conclusões. Unidades de produtividade provisionadas são concedidas a uma assinatura como cota e usadas para definir custos. Cada cota é específica para uma região e define o número máximo de PTUs que podem ser atribuídas a implantações nessa assinatura e região. Para obter informações sobre os custos associados à oferta gerenciada de provisionamento e PTUs, consulte Noções básicas sobre os custos associados à PTU.

Tipos de implantação

Ao criar uma implantação provisionada no Azure AI Foundry, o tipo de implantação na caixa de diálogo Criar Implantação pode ser definido como o tipo de implantação Gerenciada e Provisionada Globalmente, Gerenciada e Provisionada em Zona de Dados ou Gerenciada e Provisionada Regionalmente, dependendo das necessidades de processamento de dados para a carga de trabalho fornecida.

Ao criar uma implantação provisionada no Azure OpenAI por meio da CLI ou da API, o sku-name pode ser definido como GlobalProvisionedManaged, DataZoneProvisionedManaged ou ProvisionedManaged, dependendo da necessidade de processamento de dados para a carga de trabalho fornecida. Para adaptar o comando de exemplo da CLI do Azure abaixo a um tipo de implantação diferente, basta atualizar o parâmetro sku-name para corresponder ao tipo de implantação que você deseja implantar.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

Transparência de capacidade

O OpenAI do Azure é um serviço altamente requisitado, onde a demanda dos clientes pode exceder a capacidade de GPU do serviço. A Microsoft se esforça para fornecer capacidade para todas as regiões e modelos sob demanda, mas a possibilidade de esgotar as vendas em uma região sempre existe. Essa restrição pode limitar a capacidade de alguns clientes de criar uma implantação do modelo, versão ou número desejados de PTUs em uma região específica, mesmo que tenham cota disponível nessa região. De modo geral:

  • A cota estabelece um limite de número máximo de PTUs que podem ser implantadas em uma assinatura e região, mas não garante a disponibilidade de capacidade.
  • A capacidade é alocada no momento da implantação e é mantida enquanto a implantação existir. Se a capacidade do serviço não estiver disponível, a implantação falhará
  • Os clientes usam informações em tempo real sobre disponibilidade de cota/capacidade para escolher uma região apropriada para seu cenário, com a capacidade de modelo necessária
  • Reduzir a escala ou excluir uma implantação libera a capacidade de volta para a região. No entanto, não há garantia de que a capacidade estará disponível caso a implantação seja expandida ou recriada posteriormente.

Diretrizes sobre a capacidade regional

Para encontrar a capacidade necessária para suas implantações, use a API de capacidade ou a experiência de implantação do IA do Azure Foundry para fornecer informações em tempo real sobre a disponibilidade de capacidade.

No Azure AI Foundry, a experiência de implantação identifica quando uma região não tem a capacidade necessária para implantar o modelo. Isso analisa o modelo, a versão e o número desejados de PTUs. Se a capacidade não estiver disponível, a experiência direcionará os usuários para selecionar uma região alternativa.

Detalhes sobre a experiência de implantação podem ser encontrados no guia de introdução ao provisionamento do Azure OpenAI.

A API de capacidades do modelo pode ser usada para identificar programaticamente a implantação de tamanho máximo de um modelo especificado. A API considera tanto sua cota quanto a capacidade de serviço na região.

Se uma região aceitável não estiver disponível para dar suporte ao modelo, versão e/ou PTUs desejados os clientes também poderão tentar as seguintes etapas:

  • Tentar realizar a implantação com um número menor de PTUs.
  • Tentar realizar a implantação em um momento diferente. A disponibilidade de capacidade muda dinamicamente com base na demanda dos clientes, e mais capacidade pode ficar disponível posteriormente.
  • Verifique se a cota está disponível em todas as regiões aceitáveis. A API de capacidades do modelo e a experiência do IA do Azure Foundry consideram a disponibilidade de cota no retorno de regiões alternativas para criar uma implantação.

Como posso monitorar a capacidade?

A métrica Uso Provisionado-Gerenciado V2 no Azure Monitor mede uma determinada utilização de implantação em incrementos de um minuto. Todos os tipos de implantação provisionada são otimizados para garantir que as chamadas aceitas sejam processadas com um tempo de processamento de modelo consistente (a latência real de ponta a ponta depende das características de uma chamada).

Como funciona o desempenho de utilização

As implantações provisionadas fornecem a você uma quantidade alocada de capacidade de computação para executar um determinado modelo.

Em todos os tipos de implantação provisionada, quando a capacidade for excedida, a API retornará imediatamente um Erro de Status HTTP 429. Essa resposta rápida permite que o usuário tome decisões sobre como gerenciar seu tráfego. Os usuários podem redirecionar solicitações para uma implantação separada, para uma instância de implantação padrão ou usar uma estratégia de repetição para gerenciar uma determinada solicitação. O serviço continuará retornando o código de status HTTP 429 até que a utilização caia abaixo de 100%.

O que devo fazer quando receber uma resposta 429?

A resposta 429 não é um erro, mas, em vez disso, parte do design para dizer aos usuários que uma determinada implantação é totalmente utilizada em um momento. Ao fornecer uma resposta de falha rápida, você tem controle sobre como lidar com essas situações de maneira que melhor atenda aos seus requisitos de aplicativo.

Os cabeçalhos retry-after-ms e retry-after na resposta informam o tempo de espera antes que a próxima chamada seja aceita. A forma de lidar com essa resposta depende dos requisitos do seu aplicativo. Estas são algumas considerações:

  • Você pode pensar em redirecionar o tráfego para outros modelos, implantações ou experiências. Essa abordagem é a solução de menor latência porque essa ação pode ser tomada assim que você recebe o sinal 429. Para obter ideias sobre como implementar efetivamente esse padrão, consulte esta Postagem da comunidade.
  • Se você não tem problemas com latências mais longas por chamada, implemente a lógica de repetição do lado do cliente. Essa opção oferece a você a maior quantidade de taxa de transferência por PTU. As bibliotecas de clientes do OpenAI do Azure incluem recursos internos para lidar com novas tentativas.

Como o serviço decide quando enviar um 429?

Em todos os tipos de implantação provisionada, cada solicitação é avaliada individualmente de acordo com o tamanho da solicitação, tamanho de geração esperado e modelo para determinar sua utilização esperada. Isso contrasta com as implantações padrão, que têm um comportamento de limitação de taxa personalizado com base na carga de tráfego estimada. Para implantações padrão, isso pode levar a erros HTTP 429 gerados antes de valores de cota definidos serem excedidos se o tráfego não for distribuído uniformemente.

Para implantações provisionadas, usamos uma variação do algoritmo Leaky Bucket para manter a utilização abaixo de 100%, permitindo alguma intermitência no tráfego. A lógica de alto nível é a seguinte:

  1. Cada cliente tem uma quantidade definida de capacidade que pode utilizar em uma implantação

  2. Quando uma solicitação é feita:

    a. Quando a utilização atual está acima de 100%, o serviço retorna um código 429 com o cabeçalho retry-after-ms definido como o tempo até que a utilização esteja abaixo de 100%

    b. Caso contrário, o serviço estima a alteração incremental para utilização necessária para atender à solicitação combinando os tokens de prompt, menos quaisquer tokens armazenados em cache e o max_tokens especificado na chamada. Um cliente pode receber até 100% de desconto em seus tokens de prompt, dependendo do tamanho daqueles armazenados em cache. Se o parâmetro max_tokens não for especificado, o serviço estimará um valor. Essa estimativa pode levar a uma simultaneidade menor do que a esperada quando o número de tokens reais gerados é pequeno. Para maior simultaneidade, verifique se o valor max_tokens é o mais próximo possível do tamanho da geração real.

  3. Quando uma solicitação é concluída, passamos a saber o custo real de computação para a chamada. Para garantir uma contabilidade precisa, corrigimos a utilização usando a seguinte lógica:

    a. Se o > real for estimado, a diferença será adicionada à utilização da implantação.

    b. Se o < real for estimado, a diferença será subtraída.

  4. A utilização geral é decrementada a uma taxa contínua com base no número de PTUs implantadas.

Observação

As chamadas são aceitas até que a utilização alcance 100%. As intermitências acima de 100% podem ser permitidas em períodos curtos, mas, ao longo do tempo, seu tráfego é limitado a 100% de utilização.

Diagrama mostrando como as chamadas subsequentes são adicionadas à utilização.

Quantas chamadas simultâneas posso ter na minha implantação?

O número de chamadas simultâneas que você pode alcançar depende da forma de cada chamada (tamanho da solicitação, parâmetro max_tokens, etc.). O serviço continuará aceitando chamadas até que a utilização atinja a 100%. Para determinar o número aproximado de chamadas simultâneas, você pode modelar o máximo de solicitações por minuto para uma forma de chamada específica na calculadora de capacidade. Se o sistema gerar menos do que o número de tokens de saída definidos para o parâmetro max_tokens, a implantação provisionada aceitará mais solicitações.

Quais modelos e regiões estão disponíveis para taxa de transferência provisionada?

Disponibilidade global do modelo gerenciado provisionado

Região gpt-4.1, 2025-04-14 gpt-4.1-mini, 2025-04-14 o3-mini, 2025-01-31 o1, 2024-12-17 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o, 2024-11-20 gpt-4o-mini, 2024-07-18
australiaeast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brasil Sul ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Canadá Oriental ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
alemanhacentro-oeste ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italynorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
norwayeast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Polônia Central ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southafricanorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southeastasia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sul da Índia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
swedencentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Suíça Norte ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Suíça Oeste ✅ - ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Observação

A versão provisionada da gpt-4Versão:turbo-2024-04-09 atualmente está limitada apenas a texto.

Próximas etapas