O que é o débito provisionado para modelos Foundry?

A visualizar atualmente:Versão do novo portal Foundry - Mudar para a versão do portal clássico do Foundry

O throughput provisionado é um tipo de implementação no Microsoft Foundry que fornece um throughput dedicado de processamento de modelos para a sua implementação. Ao contrário das implementações padrão, em que a capacidade de inferência é partilhada entre clientes e a taxa de processamento pode variar consoante a procura, uma implementação provisionada reserva uma quantidade fixa de capacidade de processamento em exclusivo para a sua utilização, quer existam pedidos ou não.

Este artigo apresenta os conceitos centrais subjacentes à taxa de transferência aprovisionada: o que é, quando utilizá-la, como a capacidade é medida e faturada e o que deve saber sobre a quota e a capacidade antes de implementar.

Categorias de implantação comparadas

Implementações padrão, implementações em lote, processamento prioritário e capacidade aprovisionada são formas de implementar modelos no Microsoft Foundry. A escolha certa depende dos seus requisitos de latência, padrões de tráfego e tolerância a custos.

Tipo de implantação Billing Acordo de Nível de Serviço de Latência (SLA) Tipo de carga de trabalho e necessidades
Standard Pagamento por token None Cargas de trabalho equilibradas: desenvolvimento, teste e produção com tráfego variável ou imprevisível
Processamento prioritário Pagamento por token (tarifa do nível prioritário) Alvo de latência definido por modelo Cargas de trabalho de produção sensíveis à latência que necessitam de baixa latência consistente sem compromisso a longo prazo
Aprovisionado Por cada PTU por hora (ou utilizando reservas do Azure) Alvo de latência definido por modelo Cargas de trabalho de produção críticas para a missão, de alta escala, que exigem rendimento garantido e latência consistente
Batch Pagamento por token (taxa de lote descontada) None Processamento em massa sem requisitos de latência. Os resultados são devolvidos de forma assíncrona.

Quando usar o débito provisionado

O débito provisionado é a escolha certa quando a sua aplicação tem:

  • Padrões de tráfego previsíveis: Tem uma estimativa razoável de pedidos por minuto e volumes de tokens.
  • Requisitos sensíveis à latência: Os seus utilizadores ou sistemas a jusante precisam de respostas consistentes e de baixa latência.
  • Volume à escala de produção: Casos de uso de alta taxa de transferência onde a faturação por token se torna dispendiosa.
  • Cenários em tempo real ou interativos: Aplicações de chat, copilotos ou agentes onde os tempos de resposta variáveis degradam a experiência do utilizador.

As implementações padrão continuam a ser as mais adequadas para desenvolvimento, testes, uso de baixo volume ou tráfego altamente variável que dificulte o dimensionamento de uma implementação antecipadamente.

Unidades de throughput provisionadas

As unidades de taxa de transferência aprovisionada (PTUs) são a unidade de medida da taxa de transferência aprovisionada. Uma PTU representa uma quantidade fixa de capacidade de processamento de modelos. Quando cria uma implementação provisionada, especifica quantas PTUs deve alocar. A Foundry reserva essa quantidade de computação e mantém-na para a tua implementação.

Principais características das PTUs:

  • Independente do modelo: A mesma quota de PTU pode ser usada para implementar qualquer modelo suportado. Não se compram PTUs para um modelo específico.
  • Específico por região: A quota de PTU é concedida por subscrição, por região e por tipo de implementação. A quota no Leste dos EUA não se aplica à Europa Ocidental.
  • O rendimento varia consoante o modelo: Os tokens por minuto (TPM) que um dado número de PTUs entregam dependem do modelo. Um modelo mais pesado requer mais PTUs para servir o mesmo TPM que um modelo mais leve. Para as proporções de PTU para TPM por modelo, consulte Parâmetros de débito por modelo.
  • Aplicam-se tamanhos mínimos de implementação: Cada modelo tem um número mínimo de PTUs necessário para criar uma implantação. Os mínimos variam consoante o modelo e estão listados em parâmetros de implementação e valores de throughput por modelo.

Quota e capacidade

A quota e a capacidade da PTU são conceitos relacionados, mas distintos, que determinam se pode criar uma implementação. Esta secção explica o que cada um é, como solicitar quotas adicionais e como verificar se a capacidade está disponível na sua região.

O que é a quota da PTU?

A quota de PTU é o número máximo de PTUs que pode implementar por subscrição, por região e por tipo de implementação. Quota é um limite de política imposto pelo Azure e não tem custo associado. A quota é definida ao nível da oferta (Global Provisioned, Data Zone Provisioned e Regional Provisioned são pools de quotas separados) e ao nível regional (por exemplo, a quota no Leste dos EUA não se aplica à Europa Ocidental).

Uma quantidade predefinida de quota é atribuída às subscrições elegíveis em várias regiões.

O que é capacidade?

A capacidade é a quantidade real de PTUs por versão do modelo que está disponível para implementação. A capacidade é atribuída no momento da implantação e mantida durante toda a vida útil da implantação.

Importante

Ter uma quota de PTU não garante que a capacidade esteja disponível. Se a capacidade na região for insuficiente para a contagem solicitada de PTU, a implementação falha. Verifique sempre a disponibilidade de capacidade antes de planear uma implantação ou comprar uma reserva.

Porque a capacidade é um recurso finito e dinamicamente mutável:

  • A disponibilidade de capacidade varia ao longo do dia com base na procura dos clientes em todas as regiões e modelos.
  • Eliminar ou reduzir uma implantação liberta a capacidade correspondente de volta para o conjunto regional. Não há garantia de que a mesma capacidade esteja disponível se recriar a implantação ou aumentar posteriormente a escala da mesma.

Como obter a quota

Uma quantidade padrão de quota provisionada - global, da zona de dados e regional - é atribuída a assinaturas elegíveis em várias regiões. Pode solicitar mais quota ou capacidade submetendo o formulário de pedido de quota. O formulário também está disponível no portal Foundry na página Quota.

A aprovação pode demorar vários dias consoante a disponibilidade da quota, e recebe uma notificação por email quando o pedido é aprovado.

Como verificar a capacidade disponível

Para verificar a disponibilidade de capacidade em tempo real:

  • Use a experiência de implementação do portal Foundry, que indica se há capacidade disponível quando tenta criar uma implementação e lista regiões alternativas com capacidade disponível caso a sua região-alvo não tenha capacidade suficiente.
  • Use a API de capacidades do modelo para consultar programaticamente o número máximo de PTUs implantáveis para um dado modelo e região.

Se a sua região-alvo não tiver capacidade disponível:

  • Submeta o formulário de pedido de quota para solicitar mais quota ou capacidade.
  • Tente implementar com menos PTUs.
  • Tente novamente mais tarde, pois a disponibilidade de capacidade muda dinamicamente ao longo do dia.

Para orientações passo a passo sobre a criação de implantações provisionadas e a gestão de restrições de capacidade, consulte Começar com implementações provisionadas.

Dimensionamento da PTU

Antes de criar uma implementação provisionada, estima quantas PTUs a sua carga de trabalho necessita. Três fatores influenciam o cálculo:

  • Forma do pedido: Os seus pedidos esperados por minuto (RPM), tamanho médio do prompt (tokens de entrada) e tamanho médio da resposta (tokens de saída).
  • Relação saída-entrada: Os tokens de saída requerem mais capacidade de processamento do que os tokens de entrada. Cada modelo tem uma razão que expressa a quantidade de tokens de entrada a que um token de saída equivale para efeitos de capacidade. Para os modelos GPT-4.1 e posteriores do Azure OpenAI, esta proporção corresponde à relação global padrão de preços entre os tokens de saída e de entrada do modelo. Para mais informações sobre esta razão, consulte Parâmetros de implementação e valores de throughput por modelo.
  • Taxa de cache: A fração dos tokens de entrada servidos pela cache de prompt. Os tokens em cache não consomem capacidade de PTU, por isso uma taxa de cache mais alta reduz as PTUs necessárias.

O cálculo de dimensionamento utiliza estes fatores para converter os volumes esperados de tokens num único valor de TPM normalizado e, em seguida, divide esse valor pelo valor de TPM de entrada por PTU do modelo para obter o número de PTUs necessário.

Pode dimensionar manualmente, usando as fórmulas e valores por modelo, ou usar a calculadora de capacidade no portal Foundry (clássico) para uma estimativa guiada.

Para a metodologia completa de dimensionamento, incluindo fórmulas, exemplos trabalhados e a referência do calculador de capacidade, veja Determinar o dimensionamento PTU para uma carga de trabalho.

Tipos de implementação de throughput provisionado

A capacidade de débito provisionada está disponível como três tipos de implementação. Todos oferecem capacidade dedicada e latência previsível uma vez implementados. A diferença está em onde o teu tráfego de inferência é processado:

Tipo de implantação sku-name em CLI Roteamento de dados Melhor para
Global Provisionado GlobalProvisionedManaged Encaminhado entre regiões do Azure em todo o mundo Maior disponibilidade; quando a região de encaminhamento não está limitada
Área de Dados Provisionada DataZoneProvisionedManaged Permanece dentro de uma zona geográfica (EUA ou UE) Residência de dados ao nível da zona com maior disponibilidade do que a residência de dados regional
Provisionamento Regional ProvisionedManaged Permanece na região específica do Azure da implantação Requisitos rigorosos de residência de dados numa única região

Para uma comparação completa de todos os tipos de implementação do Foundry, incluindo padrão, em lote e aprovisionado, consulte Tipos de implementação para os Modelos do Microsoft Foundry.

Modelos suportados

Para obter uma lista completa dos Modelos Foundry que suportam débitos aprovisionados, incluindo os tipos de implementação suportados por cada modelo e a disponibilidade regional, consulte Disponibilidade regional dos Modelos Foundry vendidos diretamente pela Azure.

Transbordamento

Spillover é uma configuração opcional para gerir flutuações de tráfego em implementações provisionadas, encaminhando automaticamente os pedidos de overflow para uma implementação padrão correspondente no mesmo recurso Foundry. Quando uma implantação provisionada está totalmente utilizada e devolve respostas com códigos diferentes de 200 (como 429 quando as PTUs estão esgotadas), o transbordo redireciona esses pedidos para a implantação padrão, ajudando a reduzir as interrupções durante picos de tráfego.

Todos os modelos Azure OpenAI no Foundry que suportam débito aprovisionado também suportam transbordo. Os modelos Foundry de outros fornecedores (Azure DeepSeek, Meta Llama) não suportam spillover de momento.

O spillover pode ser configurado para todos os pedidos numa implementação ou controlado por pedido usando o x-ms-spillover-deployment cabeçalho do pedido. Para os passos de configuração, consulte Gerir tráfego com spillover para implementações provisionadas.

Faturação horária e reservas no Azure

As implementações aprovisionadas suportam dois modos de faturação: faturação horária para utilização flexível e de curto prazo, e Reservas do Azure para cargas de trabalho de produção sustentadas a um preço com desconto.

Faturação horária

Todos os tipos de implementação provisionados são faturados a uma taxa horária ($/PTU/hr) baseada no número de PTUs implementadas, independentemente do número de tokens consumidos. O medidor começa quando a implantação é criada e termina quando é eliminada.

A faturação por hora é adequada para cenários de curto prazo, como a avaliação comparativa de um novo modelo ou o aumento temporário da capacidade para um evento, como um hackathon. No entanto, não planeie escalar implementações provisionadas para cima e para baixo com o tráfego para manter a faturação horária por estas razões:

  • A capacidade pode não estar disponível quando for necessário voltar a aumentar a escala.

  • A faturação horária contínua com elevada utilização normalmente ultrapassa os preços das reservas.

Para orientações completas sobre faturação horária e escalabilidade de implementações provisionadas, consulte Faturação por hora.

Reservas do Azure

As Reservas do Azure são um desconto financeiro aplicado ao contador de faturação da PTU (o contador de utilização horária sobre o qual o Azure cobra), e não a implementações individuais. Em troca de um compromisso de 1 mês ou 1 ano, recebe uma tarifa efetiva com desconto em $/PTU/hora. Alguns aspetos importantes a ter em conta sobre as reservas incluem:

  • As reservas são adquiridas por tipo de implantação (Global, Data Zone ou Regional) e podem ser dimensionadas para abranger uma ou mais subscrições ou grupos de recursos.

  • Reservas e implantações são pouco ligadas, o que significa que se criam implantações e reservas de forma independente.

  • As reservas não garantem capacidade. Primeiro, crie implementações para confirmar que a capacidade está disponível; depois, compre a reserva para fixar a tarifa com desconto.

Para obter orientações completas sobre dimensionamento, aquisição e gestão de reservas, consulte Reservas do Azure para débito aprovisionado.

Como acompanhar os custos e faturação da PTU

Utilize o Microsoft Cost Management para monitorizar e analisar a utilização da PTU e os custos de reserva:

O que queres fazer Artigo
Veja que percentagem dos seus PTUs reservados estão efetivamente a ser utilizados em todas as suas implementações Exibir a utilização de reservas do Azure
Revise o histórico de compras e qualquer atividade de reembolso Ver transações de compra e reembolso de reservas do Azure
Compreenda o impacto amortizado nos custos das suas reservas para uma visibilidade mais clara da faturação por implantação Ver custos de benefícios amortizados
Distribuir os custos de reserva entre equipas ou projetos para atribuição interna de custos Reembolsar os custos de reserva do Azure
Configure a renovação automática para evitar o vencimento da reserva e manter a tarifa com desconto Renovar automaticamente reservas do Azure

Conteúdo relacionado

  • Last updated on