Desempenho e latência

Este artigo fornece informações básicas sobre como a latência e a taxa de transferência funcionam com Azure OpenAI e como otimizar seu ambiente para melhorar o desempenho.

Noções básicas sobre taxa de transferência versus latência

Há dois conceitos importantes para pensar ao dimensionar um aplicativo: (1) Taxa de transferência de nível do sistema medida em tokens por minuto (TPM) e (2) tempos de resposta por chamada (também conhecidos como latência).

Vazão no nível do sistema

Isso analisa a capacidade geral de sua implementação – quantas solicitações por minuto e o total de tokens que podem ser processados.

Para uma implantação típica, a cota atribuída à sua implantação determina em parte a quantidade de desempenho que pode ser alcançada. No entanto, a cota determina apenas a lógica de admissão de chamadas para o sistema implantado e não está garantindo diretamente o desempenho. Devido a variações de latência por chamada, talvez você não consiga obter uma taxa de transferência tão alta quanto sua cota.

Em uma implantação provisionada, uma quantidade definida de capacidade de processamento de modelo é alocada ao seu endpoint. O throughput que pode ser alcançado no endpoint é um fator da configuração da carga de trabalho, incluindo a quantidade de tokens de entrada, a quantidade de saída, a taxa de chamadas e a taxa de correspondência do cache. O número de chamadas simultâneas e o total de tokens processados pode variar com base nesses valores.

Para todos os tipos de implantação, entender a taxa de transferência no nível do sistema é um componente fundamental para otimizar o desempenho. É importante considerar a taxa de transferência de nível do sistema para uma determinada combinação de modelo, versão e carga de trabalho, pois a taxa de transferência variará entre esses fatores.

Estimando a taxa de transferência no nível do sistema

Estimando o TPM com métricas de Azure Monitor

Uma abordagem para estimar a taxa de transferência a nível de sistema para uma determinada carga de trabalho é usar dados históricos de utilização de tokens. Para cargas de trabalho do Azure OpenAI, todos os dados de uso histórico podem ser acessados e visualizados com os recursos de monitoramento nativos oferecidos no Azure OpenAI. Duas métricas são necessárias para estimar o rendimento no nível do sistema para cargas de trabalho de Azure OpenAI: (1) Tokens Processados de Prompt e (2) Tokens Gerados de Conclusão.

Quando combinadas, as métricas Tokens de Prompt Processado (TPM) e Tokens de Conclusão Gerados (TPM) fornecem uma visão estimada da taxa de transferência no nível do sistema, baseada no tráfego de carga de trabalho real. Essa abordagem não contabiliza os benefícios do armazenamento em cache de prompts, portanto, será uma estimativa conservadora da capacidade de transferência do sistema. Essas métricas podem ser analisadas usando agregação mínima, média e máxima em janelas de 1 minuto em um horizonte de tempo de várias semanas. É recomendável analisar esses dados em um horizonte de tempo de várias semanas para garantir que haja pontos de dados suficientes para avaliar. A captura de tela a seguir mostra um exemplo da métrica Processed Prompt Tokens visualizada no Azure Monitor, que está disponível diretamente por meio do portal Azure.

Captura de tela do gráfico do Azure Monitor mostrando a métrica tokens de prompt processados divididos por modelo e versão.

Estimando o TPM dos dados de solicitação

Uma segunda abordagem para a taxa de transferência estimada do sistema envolve a coleta de informações de uso de token a partir dos dados de solicitação de API. Esse método fornece uma abordagem mais granular para entender a forma da carga de trabalho por solicitação. A combinação de informações de uso de token por solicitação com o volume de solicitações, medido em solicitações por minuto (RPM), fornece uma estimativa para o throughput em nível de sistema. É importante observar que quaisquer suposições feitas para consistência de informações de uso de token entre solicitações e volume de solicitação afetarão a estimativa de taxa de transferência do sistema. Os dados de saída de uso do token podem ser encontrados nos detalhes da resposta da API para uma solicitação de conclusão de chat em um determinado Azure OpenAI nos Modelos de Microsoft Foundry.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Supondo que todas as requisições de uma determinada carga de trabalho sejam uniformes, os tokens de prompt e os tokens de conclusão dos dados de resposta da API podem ser multiplicados pelo RPM estimado para identificar o TPM de entrada e saída para uma carga de trabalho dada.

Como usar estimativas de taxa de transferência no nível do sistema

Depois que a vazão de nível do sistema tiver sido estimada para uma determinada carga de trabalho, essas estimativas poderão ser usadas para dimensionar implantações padrão e provisionadas. Para implantações Standard, os valores de TPM de entrada e saída podem ser combinados para estimar o TPM total a ser atribuído a uma determinada implantação. Para implantações provisionadas, os dados de uso do token de solicitação ou valores de TPM de entrada e saída podem ser usados para estimar o número de PTUs necessários para dar suporte a uma determinada carga de trabalho com a experiência da calculadora de capacidade de implantação.

Aqui estão alguns exemplos para o mini modelo GPT-4o:

Tamanho do prompt (tokens)	Tamanho da geração (tokens)	Solicitações por minuto	TPM de entrada	TPM de saída	Total TPM	PTUs necessárias
800	150	30	24,000	4,500	28,500	15
5,000	50	1,000	5,000,000	50,000	5,050,000	140
1,000	300	500	500,000	150,000	650,000	30

O número de PTUs aumenta de forma aproximadamente linear com a taxa de chamada quando a distribuição da carga de trabalho permanece constante.

Latência: os tempos de resposta por chamada

A definição de latência de alto nível nesse contexto é o tempo necessário para obter uma resposta do modelo. Para solicitações de conclusão e de chat, a latência depende em grande parte do tipo de modelo, da quantidade de tokens no prompt e dos tokens gerados. Em geral, cada token de prompt adiciona pouco tempo em comparação com cada token incremental gerado.

Estimar sua latência esperada por chamada pode ser um desafio com esses modelos. A latência de uma solicitação de conclusão pode variar com base em quatro fatores principais: (1) o modelo, (2) o número de tokens no prompt, (3) o número de tokens gerados e (4) a carga geral no sistema e na implantação. Um e três geralmente são os principais colaboradores para o tempo total. A próxima seção entra em mais detalhes sobre a anatomia de uma chamada de inferência de modelo de linguagem grande.

Melhorar o desempenho

Há vários fatores que você pode controlar para melhorar a latência por chamada do aplicativo.

Seleção de modelo

A latência varia de acordo com o modelo que você está usando. Para uma solicitação idêntica, espere que diferentes modelos tenham latências diferentes para a solicitação de conclusão de chat. Se o caso de uso exigir os modelos de latência mais baixos com os tempos de resposta mais rápidos, recomendamos o mini modelo GPT-4o mais recente.

Tamanho da geração e tokens máximos

Quando você envia uma solicitação de conclusão para o endpoint Azure OpenAI, o texto de entrada é convertido em tokens que são então enviados para o modelo implantado. O modelo recebe os tokens de entrada e, em seguida, começa a gerar uma resposta. É um processo sequencial iterativo, um token por vez. Outra maneira de pensar nisso é como um loop for com n tokens = n iterations. Para a maioria dos modelos, gerar a resposta é a etapa mais lenta do processo.

No momento da solicitação, o tamanho da geração solicitado (max_tokens parâmetro) é usado como uma estimativa inicial do tamanho da geração. O tempo de computação para gerar o tamanho completo é reservado pelo modelo à medida que a solicitação é processada. Depois que a geração for concluída, a cota restante será liberada. Maneiras de reduzir o número de tokens:

Defina o parâmetro max_tokens em cada chamada com o menor valor possível.
Inclua sequências de interrupção para impedir a geração de conteúdo extra.
Gerar menos respostas: Usar o parâmetro n pode aumentar a latência porque produz várias saídas por solicitação. Para a resposta mais rápida, não defina n (ou defina-a como 1).

Em resumo, reduzir o número de tokens gerados por solicitação reduz a latência de cada solicitação.

Nota

max_tokens altera apenas o comprimento de uma resposta e, em alguns casos, pode truncá-la. O parâmetro não altera a qualidade da resposta.

Streaming

A configuração stream: true em uma solicitação faz com que o serviço retorne tokens assim que eles estiverem disponíveis, em vez de aguardar a sequência completa de tokens ser gerada. Ele não altera o tempo para obter todos os tokens, mas reduz o tempo para a primeira resposta. Essa abordagem fornece uma melhor experiência do usuário, pois os usuários finais podem ler a resposta conforme ela é gerada.

O streaming também é valioso com chamadas grandes que levam muito tempo para serem processadas. Muitos clientes e camadas intermediárias têm tempo limite em chamadas individuais. Chamadas de longa geração podem ser canceladas devido a tempos limite do lado do cliente. Ao transmitir os dados de volta, você pode garantir que os dados incrementais sejam recebidos.

Exemplos de quando usar o streaming:

Bots de chat e interfaces de conversa.

O streaming afeta a latência percebida. Com o streaming habilitado, você receberá tokens de volta em partes assim que eles estiverem disponíveis. Para os usuários finais, essa abordagem geralmente parece que o modelo está respondendo mais rapidamente, embora o tempo geral para concluir a solicitação permaneça o mesmo.

Exemplos de quando o streaming é menos importante:

Análise de sentimento, tradução de idioma, geração de conteúdo.

Há muitos casos de uso em que você está executando alguma tarefa em massa em que você se preocupa apenas com o resultado concluído, não com a resposta em tempo real. Se o streaming estiver desabilitado, você não receberá nenhum token até que o modelo tenha concluído toda a resposta.

Filtragem de conteúdo

Azure OpenAI inclui um sistema de filtragem content que funciona junto com os modelos principais. Esse sistema funciona executando tanto o pedido inicial quanto a resposta por meio de um conjunto de modelos de classificação voltados para detectar e prevenir a geração de conteúdo prejudicial.

O sistema de filtragem de conteúdo detecta e toma medidas em categorias específicas de conteúdo potencialmente prejudicial em solicitações de entrada e resultados de saída.

A adição da filtragem de conteúdo vem com um aumento na segurança, mas também latência. Há muitos aplicativos em que essa compensação no desempenho é necessária, no entanto, há alguns casos de uso de menor risco em que a desabilitação dos filtros de conteúdo para melhorar o desempenho pode valer a pena ser explorada.

Saiba mais sobre como solicitar modificações nas políticas de filtragem de conteúdo padrão.

Separação de cargas de trabalho

A combinação de cargas de trabalho diferentes no mesmo ponto de extremidade pode afetar negativamente a latência. Isso ocorre porque (1) eles são processados em lote durante a inferência e as chamadas curtas podem esperar por processamentos mais longos e (2) misturar as chamadas pode reduzir a taxa de acertos de cache, pois ambas estão competindo pelo mesmo espaço. Quando possível, é recomendável ter implantações separadas para cada carga de trabalho.

Tamanho do prompt

Embora o tamanho do prompt tenha menor influência sobre a latência do que o tamanho da geração, ele afeta o tempo geral, especialmente quando o tamanho aumenta.

Processamento em Lotes

Se você estiver enviando várias solicitações para o mesmo ponto de extremidade, poderá colocar as solicitações em lote em uma única chamada. Isso reduz o número de solicitações que você precisa fazer e, dependendo do cenário, pode melhorar o tempo de resposta geral. Recomendamos testar esse método para ver se ele ajuda.

Como medir sua taxa de transferência

Recomendamos medir sua taxa de transferência geral em uma implantação usando dois critérios:

Chamadas por minuto: o número de chamadas de inferência de API que você está fazendo por minuto. Isso pode ser medido no Azure Monitor usando a métrica Azure OpenAI Requests e segmentando por ModelDeploymentName.
Total de tokens por minuto: o número total de tokens processados por minuto pela sua implantação. Isso inclui tokens de prompt e tokens gerados pelo sistema. Geralmente, isso é dividido em medir ambos os aspectos para uma compreensão mais profunda do desempenho da implantação. Isso pode ser medido em Azure-Monitor usando a métrica de tokens de inferência processada.

Você pode saber mais sobre Monitoring Azure OpenAI.

Como medir a latência por chamada

O tempo necessário para cada chamada depende de quanto tempo leva para ler o modelo, gerar a saída e aplicar filtros de conteúdo. A maneira como você mede o tempo variará se você estiver usando streaming ou não. Sugerimos um conjunto diferente de medidas para cada caso.