Gerenciar o tráfego com transbordamento para implementações provisionadas

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

O Spillover gere as flutuações de tráfego nas implementações provisionadas, encaminhando automaticamente os pedidos de excedente para uma implementação padrão correspondente. Quando a sua implantação provisionada está totalmente utilizada e devolve respostas sem código 200 (como quando as PTUs estão esgotadas429), o mecanismo de transbordo redireciona esses pedidos para a implantação padrão, ajudando-o a reduzir interrupções durante picos de tráfego. Esta capacidade opcional pode ser configurada para todos os pedidos numa implementação ou gerida por pedido.

Pré-requisitos

  • Uma subscrição do Azure. Crie um gratuitamente.
  • Uma implantação gerida provisionada e uma implementação padrão no mesmo recurso da Foundry.
  • CLI do Azure instalado para exemplos de APIs REST, ou acesso ao portal Foundry.
  • A variável de ambiente AZURE_OPENAI_ENDPOINT definida para o URL do ponto final do Azure OpenAI.
  • Função de Contribuidor de Serviços Cognitivos ou superior no recurso Foundry para criar ou modificar implementações.

Ativar o spillover para todos os pedidos numa implementação provisionada

  1. Inicie sessão no Microsoft Foundry. Certifica-te de que a opção New Foundry está ativada. Estes passos dizem respeito a Foundry (new).

  2. Selecione a subscrição e o recurso na região onde tem a quota.

  3. Selecione Descobrir no canto superior direito da navegação, depois Modelos no painel esquerdo.

  4. Selecione o filtro Collections e filtre por Diretamente de Azure para ver modelos vendidos diretamente por Azure. Uma seleção destes modelos suporta a opção de implementação de throughput provisionado.

  5. Selecione o modelo que pretende implementar para abrir a respetiva ficha do modelo.

  6. Selecione Definir>definições Personalizadas para configurar a sua implementação. O menu pendente Tipo de implementação apresenta os tipos de implementação aprovisionados que estão disponíveis para o modelo selecionado.

    Nota

    Para permitir o spillover, a sua conta deve ter pelo menos uma implementação pay-as-you-go ativa que corresponda ao modelo e à versão da sua implementação provisionada atual.

  7. Defina o tipo de Implantação para uma das opções provisionadas, por exemplo Throughput Global Provisionado.

  8. Selecione Traffic spillover para ativar o spillover para a sua implementação provisionada.

Ativar transbordamento para pedidos de inferência selecionados

Para ativar seletivamente o spillover por pedido, defina o x-ms-spillover-deployment cabeçalho do pedido de inferência para o destino padrão de implementação para pedidos de spillover. Se o cabeçalho x-ms-spillover-deployment não estiver definido num determinado pedido, o spillover não é iniciado no caso de uma resposta diferente de 200. A utilização ou omissão deste cabeçalho proporciona flexibilidade para controlar quando o transbordamento deve ou não ser iniciado para uma carga de trabalho ou cenário específico.

curl $AZURE_OPENAI_ENDPOINT/openai/deployments/spillover-ptu-deployment/chat/completions?api-version=2024-10-21 \
  -H "Content-Type: application/json" \
  -H "x-ms-spillover-deployment: spillover-standard-deployment" \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN' \
  -d '{"messages":[{"role": "system", "content": "You are a helpful assistant."},{"role": "user", "content": "Does Azure OpenAI support customer managed keys?"},{"role": "assistant", "content": "Yes, customer managed keys are supported by Azure OpenAI."},{"role": "user", "content": "Do other Azure services support this too?"}]}'

Um pedido bem-sucedido devolve o código de estado HTTP 200 com a resposta de conclusão do chat. Se ocorrer transbordamento, a resposta inclui o x-ms-spillover-from-deployment cabeçalho.

Referência:Gerar conclusão de conversa

Nota

Se a capacidade de spillover estiver ativada para a implantação usando a propriedade spilloverDeploymentName e também ao nível do pedido usando o cabeçalho x-ms-spillover-deployment, o sistema utiliza como padrão a configuração da propriedade de implantação. Se quiser garantir que o spillover seja ativado apenas para cada pedido, não defina a propriedade spilloverDeploymentName na implantação aprovisionada e dependa apenas do cabeçalho x-ms-spillover-deployment para cada pedido.

Identificar pedidos de transbordamento

Os seguintes cabeçalhos de resposta HTTP indicam que um pedido específico transbordou:

  • x-ms-spillover-from-deployment: Contém o nome de implementação da PTU. A presença deste cabeçalho indica que o pedido é um pedido de transbordo.
  • x-ms-deployment-name: Contém o nome da implementação que serve o pedido. Se a requisição ultrapassar os limites, o nome da implementação é o nome da implementação padrão.
  • x-ms-spillover-error é devolvido em qualquer pedido que transborde, e contém o código de resposta da implantação aprovisionada que desencadeou o transbordo (por exemplo, 429, 500 ou 503). Está presente independentemente de a tentativa de transbordamento ter sucesso ou não.

Para um pedido que excede a capacidade, se a implementação standard também não conseguir processá-lo, a resposta da implementação standard (incluindo o código de estado e o corpo da resposta) é devolvida ao autor da chamada. Os cabeçalhos x-ms-spillover-from-deployment e x-ms-spillover-error ainda estão presentes, pelo que o invocador pode distinguir uma falha de transbordo de uma falha direta de implementação padrão.

Monitorizar o uso excessivo

O spillover baseia-se numa combinação de implementações provisionadas e padrão para gerir os excessos de tráfego, permitindo que o monitoramento seja realizado ao nível da implementação para cada implementação. Para ver quantos pedidos foram processados na implementação principal provisionada em comparação com a implementação padrão de spillover, aplique a funcionalidade de divisão nas métricas do Azure Monitor para visualizar os pedidos processados por cada implementação e os respetivos códigos de estado. De forma semelhante, use a funcionalidade de divisão para ver quantos tokens foram processados na implementação principal provisionada em comparação com a implementação padrão de spillover para um dado período de tempo.

O seguinte gráfico de métricas do Azure Monitor fornece um exemplo da divisão dos pedidos entre a implementação principal provisionada e a implementação padrão de spillover, quando este é iniciado. Para criar um gráfico, navegue até ao seu recurso no portal Azure.

  1. Selecione Métricas de Monitorização> no menu de navegação à esquerda.

  2. Adicione a métrica Azure OpenAI Requests.

    Uma captura de ecrã que mostra as métricas de um exemplo básico de spillover no portal Azure.

  3. Selecione Aplicar divisões e aplica as divisões ModelDeploymentName e StatusCode à métrica Azure OpenAI Requests. Isto apresenta um gráfico com o 200 (sucesso) e o 400 (código de erro) gerados para o seu recurso. A contagem relativa ao código de erro é neste momento zero no gráfico.

    Uma captura de ecrã que mostra o menu para adicionar divisões no portal Azure.

  4. Selecione Adicionar filtro. Na caixa de filtro, defina a Propriedade para ModelDeploymentName e defina os Valores para as implementações do modelo que pretende visualizar.

    Uma captura de ecrã mostrando um filtro com as implementações de modelos selecionadas.

    Cada solicitação que a implantação provisionada não consegue processar (devolvendo 429, 500 ou 503) é imediatamente redirecionada para a implantação pay-as-you-go usada para transbordo, onde é processada e contabilizada como uma resposta 200 (gpt-4.1, 200 = 954). A linha de implantação provisionada (gpt-4.1-ptum, 200 = 46) reflete apenas os pedidos que serviu diretamente, uma vez que os pedidos transferidos não são contados como 429s na implementação provisionada. Para distinguir o tráfego excedente do tráfego direto na implementação padrão, aplique a divisão IsSpillover, conforme mostrado na secção seguinte.

    Uma captura de ecrã que mostra as métricas para visualizar o spillover.

Ver métricas de transbordamento

Aplicar a separação IsSpillover permite-lhe ver quais as solicitações da sua implementação padrão que chegaram por transbordo de uma implementação aprovisionada. Os pedidos excedentes aparecem como registos na implantação padrão com IsSpillover = True e o respetivo código de estado final (tipicamente 200). Eles não são contados duas vezes como 429s na implantação provisionada.

No gráfico seguinte, o pedido de transbordamento aparece como IsSpillover=True, gpt-4.1, 200 = 954 apenas na implementação padrão. A implementação aprovisionada não tem qualquer registo IsSpillover=True.

Uma captura de ecrã que mostra a divisão do transbordamento no portal Azure.

Quando ativar o transbordamento

Para maximizar a utilização da sua implementação provisionada, ative o transbordo para todas as implementações globais e zonas de dados provisionadas. Com o spillover, os surtos ou flutuações no tráfego podem ser geridos automaticamente pelo serviço. Esta capacidade reduz o risco de sofrer interrupções quando uma implantação provisionada é totalmente utilizada. Alternativamente, a propagação pode ser configurada por pedido para proporcionar flexibilidade em diferentes cenários e cargas de trabalho. A Spillover também colabora com o Serviço de Agentes da Fundição.

Quando o transbordamento entra em vigor

Quando ativa o transbordo para uma implementação ou o configura para um dado pedido de inferência, o transbordo inicia-se quando um código de resposta específico diferente de 200 é recebido devido a um destes cenários:

  • As unidades de processamento provisionadas (PTU) são totalmente utilizadas, o que resulta num 429 código de resposta.

  • Envia um pedido de token de contexto longo, que resulta num código de erro 400. Por exemplo, quando usas gpt 4.1 modelos em série, o PTU suporta apenas comprimentos de contexto inferiores a 128K e devolve HTTP 400.

  • Erros de servidor ocorrem ao processar o seu pedido, o que resulta em código 500 de erro ou 503.

Quando um pedido resulta em um destes códigos de resposta que não são 200, o Azure OpenAI envia automaticamente o pedido da sua implementação provisionada para a implementação padrão para processamento.

Nota

Mesmo que um subconjunto de pedidos seja encaminhado para a implementação padrão, o serviço prioriza o envio de pedidos para a implementação provisionada antes de enviar quaisquer pedidos excedentes para a implementação padrão. Esta priorização pode gerar latência adicional.

Custo de transbordamento

Como o spillover utiliza uma combinação de implementações provisionadas e padrão para gerir flutuações de tráfego, a faturação por spillover envolve dois componentes:

  • Para quaisquer pedidos processados pela sua implementação provisionada, apenas o custo de implementação provisionada por hora se aplica. Não são incorridos custos adicionais por estes pedidos.

  • Para quaisquer pedidos encaminhados para a sua implementação padrão, o pedido é faturado às taxas associadas de token de entrada, token em cache e token de saída para a versão do modelo e tipo de implementação especificados.

Conteúdo relacionado

  • Last updated on