Comparar políticas de limitação de taxas

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Ponto-chave:

As políticas de Quota, SpikeArrest, PromptTokenLimit e LLMTokenQuota são todas usadas para limitar a taxa, mas servem propósitos diferentes e operam em métricas diferentes. Embora a Quota e o SpikeArrest se foquem nas contagens de pedidos, as políticas PromptTokenLimit e LLMTokenQuota gerem e controlam o consumo com base em tokens, o que é fundamental para as cargas de trabalho de IA e de grandes modelos de linguagem (LLMs).

Embora o SpikeArrest e o PromptTokenLimit mantenham as contagens com elevada fiabilidade, foram concebidos para usar uma cache de melhor esforço do Redis para armazenar as respetivas contagens. Uma vez que a cache não é replicada, existem casos em que as contagens podem ser perdidas, como um reinício dos servidores de cache ou outros casos raros.

Por estes motivos, recomendamos que não use o SpikeArrest nem o PromptTokenLimit para exemplos de utilização que exijam uma contagem precisa. Apenas a política de quota síncrona ou LLMTokenQuota oferece uma contagem precisa em todas as regiões num determinado período.

Use o gráfico de comparação abaixo para ajudar a decidir que política usar para o seu exemplo de utilização de limitação de taxa:

	Quota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Use-a para:	Limitar o número de chamadas de proxy de API que uma app de programador ou um programador pode fazer durante um período específico. É mais adequado para limitar a taxa em intervalos de tempo mais longos, como dias, semanas ou meses, especialmente quando a contagem precisa é um requisito.	Limitar o número de chamadas API que podem ser feitas a um proxy de API em todos os consumidores durante um curto período, como segundos ou minutos.	Faça a gestão e limite o consumo total de tokens para chamadas da API LLM durante um período especificado (minuto, hora, dia, semana ou mês). Isto permite-lhe controlar os gastos com o MDG e aplicar uma gestão detalhada de quotas com base nos produtos de API.	Proteja o back-end de destino do proxy de API contra o abuso de tokens, os comandos massivos e as potenciais tentativas de negação de serviço limitando a taxa de tokens enviados na entrada através da restrição de pedidos com base no número de tokens na mensagem de comando do utilizador. É um paradigma comparativo ao Spike Arrest para o tráfego da API, mas para tokens.
Não a use para:	Proteja o back-end de destino do proxy de API contra picos de tráfego. Use SpikeArrest ou PromptTokenLimit para isso.	Contar e limitar o número de ligações que as apps podem fazer ao back-end de destino do proxy da API durante um período específico, especialmente quando é necessária uma contagem precisa.	Proteja o back-end de destino do proxy de API contra o abuso de tokens. Use PromptTokenLimit para isso.	Contar e limitar com precisão o número total de tokens consumidos para a faturação ou a gestão de quotas a longo prazo. Use a política LLMTokenQuota para isso.
Armazena uma contagem?	Sim	Não	Sim, mantém contadores que monitorizam o número de tokens consumidos pelas respostas do GML.	Conta os tokens para aplicar um limite de taxa, mas não armazena uma contagem persistente a longo prazo, como a política LLMTokenQuota.
Práticas recomendadas para anexar a política:	Anexe-o ao ProxyEndpoint Request PreFlow, geralmente após a autenticação do utilizador. Isto permite que a política verifique o contador de quotas no ponto de entrada do proxy de API.	Anexe-o ao ProxyEndpoint Request PreFlow, geralmente no início do fluxo. Isto oferece proteção contra picos no ponto de entrada do proxy de API.	Aplique a política de aplicação (EnforceOnly) no fluxo de pedidos e a política de contabilização (CountOnly) no fluxo de respostas. Para respostas de streaming, anexe a política de contagem a um EventFlow.	Anexe-o ao ProxyEndpoint Request PreFlow, no início do fluxo, para proteger o seu back-end de comandos demasiado grandes.
Código de estado HTTP quando o limite foi atingido:	429 (Serviço indisponível)	429 (Serviço indisponível)	429 (Serviço indisponível)	429 (Serviço indisponível)
É bom saber:	O contador de quota é armazenado no Cassandra. Pode configurar a política para sincronizar o contador de forma assíncrona para poupar recursos, mas isto pode permitir chamadas ligeiramente superiores ao limite.	Permite-lhe escolher entre um algoritmo de suavização ou um algoritmo de contagem eficaz. O primeiro suaviza o número de pedidos que podem ocorrer num período especificado, e o segundo limita o número total de pedidos que podem ocorrer num período especificado, independentemente da rapidez com que são enviados sucessivamente. A suavização não é coordenada entre os processadores de mensagens.	Pode ser configurado como CountOnly para acompanhar a utilização de tokens ou EnforceOnly para rejeitar pedidos que excedam a quota. Funciona com produtos de API para permitir configurações de quotas detalhadas com base na app, no programador, no modelo ou num conjunto de operações de LLM específico. Usa <LLMTokenUsageSource> para extrair a contagem de tokens da resposta do MDI/CE e <LLMModelSource> para identificar o modelo usado.	O cálculo de tokens pode diferir ligeiramente do utilizado pelo MDG. O elemento <UserPromptSource> especifica a localização do comando do utilizador na mensagem de pedido.
Obtenha mais detalhes:	Política de quotas	Política SpikeArrest	Política LLMTokenQuota	Política de PromptTokenLimit

Sugestão: também pode usar o seguinte para proteger os back-ends lentos/morosos sem afetar o desempenho das APIs:

• Criar fluxos partilhados reutilizáveis: combine políticas e recursos num fluxo partilhado que pode usar a partir de vários proxies de API e até mesmo de outros fluxos partilhados.
• Encadeamento de proxies de API: especifique que um proxy é o ponto final de destino de outro, ligando efetivamente os dois proxies numa cadeia de proxies. A encadeamento de proxies desta forma pode ajudar a evitar um salto de rede e, por isso, melhorar o desempenho geral.