Desempenho e latência

Este artigo fornece-lhe contexto sobre como a latência e o throughput funcionam com o Azure OpenAI e como otimizar o seu ambiente para melhorar o desempenho.

Entendendo a taxa de transferência contra a latência

Existem dois conceitos-chave a considerar ao dimensionar uma aplicação: (1) Rendimento ao nível do sistema medido em tokens por minuto (TPM) e (2) tempos de resposta por chamada (também conhecido como latência).

Rendimento ao nível do sistema

Isto analisa a capacidade global da sua implementação – quantos pedidos por minuto e o total de tokens que podem ser processados.

Para uma implementação padrão, a quota atribuída à sua implementação determina parcialmente a quantidade de rendimento que pode alcançar. No entanto, a quota determina apenas a lógica de admissão para as chamadas à implementação e não impõe diretamente o controle do rendimento. Devido às variações de latência por chamada, pode não conseguir atingir uma largura de banda tão alta quanto o seu limite estabelecido.

Numa implementação provisionada, uma quantidade definida de capacidade de processamento de modelos é alocada ao seu endpoint. A quantidade de throughput que pode alcançar no endpoint depende da forma da carga de trabalho, incluindo a quantidade do token de entrada, a quantidade de saída, a taxa de chamadas e a taxa de correspondência da cache. O número de chamadas simultâneas e o total de tokens processados podem variar com base nestes valores.

Para todos os tipos de implementação, compreender o rendimento ao nível do sistema é um componente chave para otimizar o desempenho. É importante considerar o desempenho do sistema para um determinado modelo, versão e combinação de carga de trabalho, pois o desempenho pode variar de acordo com estes fatores.

Estimativa do rendimento ao nível do sistema

Estimar TPM com métricas do Azure Monitor

Uma abordagem para estimar o rendimento ao nível do sistema para uma dada carga de trabalho é usar dados históricos de utilização de tokens. Para cargas de trabalho do Azure OpenAI, todos os dados históricos de utilização podem ser acedidos e visualizados com as capacidades nativas de monitorização oferecidas no Azure OpenAI. São necessárias duas métricas para estimar o rendimento ao nível do sistema para cargas de trabalho Azure OpenAI: (1) Prompt Tokens Processados e (2) Tokens de Conclusão Gerados.

Quando combinados, as métricas de Processed Prompt Tokens (TPM de entrada) e Generated Completion Tokens (TPM de saída) fornecem uma visão estimada do desempenho do sistema, baseada no tráfego real de trabalho. Esta abordagem não tem em conta os benefícios do prompt cache, pelo que será uma estimativa conservadora do rendimento do sistema. Estas métricas podem ser analisadas usando agregação mínima, média e máxima ao longo de janelas de 1 minuto ao longo de um horizonte temporal de várias semanas. Recomenda-se analisar estes dados ao longo de um horizonte temporal de várias semanas para garantir que existem pontos de dados suficientes para avaliar. A captura de ecrã seguinte mostra um exemplo da métrica Processed Prompt Tokens visualizada em Azure Monitor, que está disponível diretamente através do portal Azure.

Captura de ecrã de Azure Monitor gráfico que mostra a métrica Processed Prompt Tokens dividida por modelo e versão.

Estimativa do TPM a partir de dados de pedidos

Uma segunda abordagem para a taxa de transmissão estimada a nível do sistema envolve a recolha de informações sobre a utilização de tokens com base nos dados de requisição da API. Este método oferece uma abordagem mais detalhada para compreender a forma da carga de trabalho por pedido. Ao combinar a informação sobre utilização de tokens por pedido com o volume de pedidos, medido em pedidos por minuto (RPM), obtemos uma estimativa do desempenho ao nível do sistema. É importante notar que quaisquer suposições feitas para a consistência da informação de utilização de tokens entre pedidos e volume de pedidos impactarão a estimativa de throughput do sistema. Os dados de utilização de token podem ser encontrados nos detalhes de resposta da API para um dado pedido de conclusão de chat do Azure OpenAI no Microsoft Foundry Models.

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

Assumindo que todos os pedidos para uma determinada carga de trabalho são uniformes, os prompt tokens e os completion tokens dos dados de resposta da API podem ser multiplicados pelo RPM estimado para identificar o TPM de entrada e saída para a carga de trabalho determinada.

Como usar estimativas de rendimento ao nível do sistema

Uma vez que o rendimento ao nível do sistema tenha sido estimado para uma dada carga de trabalho, estas estimativas podem ser usadas para dimensionar implementações Standard e Provisionadas. Para implementações padrão, os valores de TPM de entrada e saída podem ser combinados para estimar o total de TPM a ser atribuído a uma dada implementação. Para implementações provisionadas, os dados de utilização do token de pedido ou os valores de TPM de entrada e saída podem ser usados para estimar o número de PTUs necessárias para suportar uma dada carga de trabalho com a experiência da calculadora de capacidade de implementação.

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

Tamanho do Prompt (tokens)	Tamanho da Geração (Tokens)	Pedidos por minuto	TPM de entrada	TPM de saída	Total TPM	PTUs requeridas
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 escala aproximadamente linearmente com a taxa de chamadas quando a distribuição da carga de trabalho se mantém constante.

Latência: Os tempos de resposta por chamada

A definição geral de latência neste contexto é o tempo que demora a obter uma resposta do modelo. Para solicitações de conclusão e de 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 com cada token incremental gerado.

Estimar a sua latência esperada por chamada pode ser um desafio com estes modelos. A latência de um pedido 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 total sobre a implementação e o sistema. Um e três são frequentemente os principais contribuintes para o tempo total. A secção seguinte entra em mais detalhes sobre a anatomia de uma chamada de inferência por modelo de linguagem grande.

Melhorar o desempenho

Existem vários fatores que pode controlar para melhorar a latência por chamada da sua aplicação.

Seleção de modelos

A latência varia consoante o modelo que estás a usar. Para um pedido idêntico, espere que diferentes modelos tenham latências diferentes para a chamada de conclusão do chat. Se o seu caso de uso exigir modelos com menor latência e tempos de resposta mais rápidos, recomendamos o modelo mini mais recente do GPT-4o.

Tamanho da geração e número máximo de tokens

Quando envia um pedido de conclusão para o endpoint Azure OpenAI, o seu texto de entrada é convertido em tokens que depois são enviados para o seu modelo implementado. O modelo recebe os tokens de entrada e depois começa a gerar uma resposta. É um processo iterativo e sequencial, um token de cada vez. Outra forma de pensar nisso é como um ciclo for com n tokens = n iterations. Para a maioria dos modelos, gerar a resposta é a etapa mais lenta do processo.

No momento do pedido, o tamanho de geração solicitado (max_tokens parâmetro) é usado como estimativa inicial do tamanho da geração. O tempo de cálculo para gerar o tamanho total é reservado pelo modelo à medida que o pedido é processado. Uma vez concluída a geração, a quota restante é libertada. Formas de reduzir o número de tokens:

Defina o parâmetro max_tokens o menor possível em cada chamada.
Inclua sequências de paragem para evitar gerar conteúdo extra.
Gerar menos respostas: Usar o n parâmetro pode aumentar a latência porque produz múltiplas saídas por pedido. Para obter uma resposta mais rápida, não definas n (ou define como 1).

Em resumo, reduzir o número de tokens gerados por pedido diminui a latência de cada pedido.

Nota

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

Streaming

Definir stream: true num pedido faz com que o serviço devolva tokens assim que estes estejam disponíveis, em vez de esperar pela geração completa da sequência de tokens. Não altera o tempo para obter todos os tokens, mas reduz o tempo para a primeira resposta. Esta abordagem proporciona uma melhor experiência ao utilizador, uma vez que os utilizadores finais podem ler a resposta à medida que é gerada.

O streaming também é valioso em chamadas grandes que demoram muito a ser processadas. Muitos clientes e camadas intermédias têm tempos de espera em chamadas individuais. Chamadas de longa geração podem ser canceladas devido a timeouts do lado do cliente. Ao transmitir os dados de volta, pode garantir que os dados incrementais são recebidos.

Exemplos de quando usar streaming:

Bots de chat e interfaces conversacionais.

O streaming afeta a latência percebida. Com o streaming ativado, recebes tokens de volta em blocos assim que estiverem disponíveis. Para os utilizadores finais, esta abordagem muitas vezes parece que o modelo responde mais rapidamente, mesmo que o tempo total para completar o pedido se mantenha o mesmo.

Exemplos de quando o streaming é menos importante:

Análise de sentimento, tradução de línguas, geração de conteúdos.

Existem muitos casos de uso em que está a realizar uma tarefa em massa em que só se preocupa com o resultado final, não com a resposta em tempo real. Se o streaming estiver desativado, não receberá nenhum token até o modelo terminar toda a resposta.

Filtragem de conteúdos

Azure OpenAI inclui um sistema filtro de conteúdos que funciona em conjunto com os modelos principais. Este sistema funciona ao executar tanto o prompt como a conclusão através de um conjunto de modelos de classificação destinados a detectar e prevenir a produção de conteúdos prejudiciais.

O sistema de filtragem de conteúdos deteta e age sobre categorias específicas de conteúdo potencialmente prejudicial tanto em prompts de entrada como em conclusões de saída.

A adição do filtro de conteúdo traz um aumento da segurança, mas também da latência. Existem muitas aplicações onde este compromisso de desempenho é necessário, no entanto, existem certos casos de menor risco em que desativar os filtros de conteúdo para melhorar o desempenho pode valer a pena explorar.

Saiba mais sobre como solicitar modificações às políticas de filtragem de conteúdo por defeito.

Separação das cargas de trabalho

Misturar diferentes cargas de trabalho no mesmo endpoint pode afetar negativamente a latência. Isto porque (1) as chamadas são agrupadas durante a inferência e as chamadas curtas podem ficar à espera de conclusões mais longas e (2) misturar as chamadas pode reduzir a taxa de acerto na cache, pois ambas competem pelo mesmo espaço. Sempre que possível, recomenda-se ter implementações separadas para cada carga de trabalho.

Tamanho do Prompt

Embora o tamanho do prompt tenha menor influência na latência do que o tamanho da geração, afeta o tempo total, especialmente quando o tamanho cresce.

Processamento em Lotes

Se estiveres a enviar vários pedidos para o mesmo endpoint, podes agrupar os pedidos numa única chamada. Isto reduz o número de pedidos que precisa de fazer e, dependendo do cenário, pode melhorar o tempo de resposta global. Recomendamos testar este método para ver se ajuda.

Como medir o seu rendimento

Recomendamos medir o seu rendimento global numa missão com duas medidas:

Chamadas por minuto: O número de chamadas de inferência de API que faz por minuto. Isto pode ser medido no Azure-monitor usando a métrica Azure OpenAI Requests e dividindo pelo ModelDeploymentName
Total de Tokens por minuto: O total de tokens processados por minuto pela sua implementação. Isto inclui prompts e tokens gerados. Isto é frequentemente dividido em medições de ambos os aspetos para uma compreensão mais profunda do desempenho da implementação. Isto pode ser medido em Azure-Monitor usando a métrica de tokens de Inferência Processada.

Pode saber mais sobre Monitoring Azure OpenAI.

Como medir a latência por chamada

O tempo que demora cada chamada depende de quanto tempo demora a ler o modelo, gerar a saída e aplicar filtros de conteúdo. A forma como medes o tempo vai variar se usares streaming ou não. Sugerimos um conjunto diferente de medidas para cada caso.