Desempenho e latência

Artigo
09/24/2024

Este artigo fornece informações básicas sobre como a latência e a taxa de transferência funcionam com o 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 no nível do sistema e (2) Tempos de resposta por chamada (também conhecido como Latência).

Taxa de transferência no nível do sistema

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

Para uma implantação padrão, a cota atribuída à sua implantação determina parcialmente a quantidade de taxa de transferência que você pode alcançar. No entanto, a cota determina apenas a lógica de admissão de chamadas para a implantação e não está aplicando diretamente a taxa de transferência. 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. Saiba mais sobre gerenciamento de cota.

Em uma implantação provisionada, uma quantidade definida de capacidade de processamento de modelo é alocada ao seu ponto de extremidade. A quantidade de taxa de transferência que você pode obter no ponto de extremidade é um fator de tamanho da entrada, taxa de chamada e taxa de correspondência de cache. O número de chamadas simultâneas e o total de tokens processados pode variar com base nesses valores. As etapas a seguir explicam como avaliar a taxa de transferência que você pode obter uma determinada carga de trabalho em uma implantação provisionada:

Use a calculadora de capacidade para uma estimativa de dimensionamento.
Faça o parâmetro de comparação da carga usando a carga de trabalho de tráfego real. Medir as métricas processadas de utilização e tokens do Azure Monitor. Execução para um período estendido. O repositório do parâmetro de comparação do OpenAI do Azure contém código para executar o parâmetro de comparação. Por fim, a abordagem mais precisa é executar um teste com seus próprios dados e características de carga de trabalho.

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

Tamanho do prompt (tokens)	Tamanho da geração (tokens)	Chamadas por minuto	PTUs obrigatórias
800	150	30	100
1000	50	300	700
5000	100	50	600

O número de PTUs é dimensionado aproximadamente de modo linear, com a taxa de chamada (pode ser sublinear) 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 obter solicitações de conclusão e conclusão de chat, a latência depende em grande parte do tipo de modelo, do número de tokens no prompt e do número de tokens gerados. Em geral, cada token de prompt adiciona pouco tempo em comparação a cada token incremental gerado.

Estimar a 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 primários: (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. Os itens 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 modelos

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 chamada de conclusões de chat. Se o seu caso de uso exigir os modelos de menor latência com os tempos de resposta mais rápidos, recomendamos o modelo mais recente GPT-4o mini.

Tamanho da geração e tokens máximos

Quando você envia uma solicitação de conclusão para o ponto de extremidade de OpenAI do Azure, o texto de entrada é convertido em tokens que sã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 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 de geração solicitado (parâmetro max_tokens) é 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 o menor possível.
Incluir sequências de parada para impedir a geração de conteúdo extra.
Gerar menos respostas: os parâmetros best_of &n podem aumentar muito a latência porque geram várias saídas. Para a resposta mais rápida, não especifique esses valores ou defina-os como 1.

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

Streaming

A configuração stream: true em uma solicitação torna os tokens de retorno do serviço assim que eles estiverem disponíveis, em vez de aguardar a sequência completa de tokens ser gerada. Ela 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 streaming:

Bots de chat e interfaces de conversa.

O streaming afeta a latência percebida. Com o streaming habilitado, recebe 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 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

O OpenAI do Azure inclui um sistema de filtragem de conteúdo que funciona juntamente com os principais modelos. Esse sistema funciona executando o prompt e a conclusão por meio de um conjunto de modelos de classificação destinados a detectar e impedir a saída de conteúdo prejudicial.

O sistema de filtragem de conteúdo detecta e executa ações em categorias específicas de conteúdo potencialmente prejudicial em prompts de entrada e conclusões 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 desativação dos filtros de conteúdo para melhorar o desempenho pode valer a pena ser explorada.

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

Separação de cargas de trabalho

A combinação de cargas de trabalho diferentes no mesmo ponto de extremidade pode prejudicar a latência. Isso ocorre porque (1) elas são agrupadas em lote durante a inferência, e chamadas curtas podem estar aguardando conclusões mais longas, além disso (2) misturar as chamadas pode reduzir a taxa de ocorrências 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.

Separação 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 com duas medidas:

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 de Solicitações OpenAI do Azure e a divisão pelo ModelDeploymentName
Total de Tokens por minuto: o número total de tokens sendo processados por minuto pela sua implantação. Isso inclui tokens de prompt e gerados. Isso geralmente é dividido em medir ambos para uma compreensão mais profunda do desempenho da implantação. Isso pode ser medido no Azure-Monitor usando a métrica de tokens de inferência processada.

Você pode saber mais sobre isso em Monitoramento do Serviço OpenAI do Azure.

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.