Como comparar políticas de limitação de taxa

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Importante:

As políticas Quota, SpikeArrest, PromptTokenLimit e LLMTokenQuota são usadas para limitação de taxa, mas têm finalidades diferentes e operam em métricas diferentes. Enquanto as políticas de cota e SpikeArrest se concentram na contagem de solicitações, as políticas PromptTokenLimit e LLMTokenQuota gerenciam e controlam o consumo com base em tokens, o que é crucial para cargas de trabalho de IA e modelos de linguagem grandes (LLMs).

Embora a SpikeArrest e a PromptTokenLimit mantenham contagens com alta confiabilidade, elas foram projetadas para usar um cache de melhor esforço do Redis para armazenar as contagens. Como o cache não é replicado, há casos em que as contagens podem ser perdidas, como uma reinicialização dos servidores desse tipo ou outros casos raros.

Por esses motivos, não recomendamos o uso do SpikeArrest ou do PromptTokenLimit para casos de uso que exijam uma contagem precisa. Somente a política síncrona de cotas ou LLMTokenQuota oferece contagem precisa em todas as regiões em um determinado período.

Use a tabela de comparação abaixo para ajudar a decidir qual política usar para seu caso de uso de limitação de taxa:

	Cota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Use para:	Limitar o número de chamadas de proxy de API que um app ou desenvolvedor pode fazer durante um período específico. É melhor para limitação de 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 de API que podem ser feitas em um proxy de API em todos os consumidores durante um curto período, como segundos ou minutos.	Gerenciar e limitar o consumo total de tokens para chamadas de API de LLM durante um período especificado (minuto, hora, dia, semana ou mês). Isso permite controlar os gastos com LLMs e aplicar um gerenciamento granular de cotas com base em produtos de API.	Proteja o back-end de destino do proxy de API contra abuso de token, comandos em massa e possíveis tentativas de negação de serviço limitando a taxa de tokens enviados na entrada ao limitar as solicitações com base no número de tokens na mensagem de comando do usuário. É um paradigma comparativo à detenção de pico para tráfego de API, mas para tokens.
Não use para:	Protege 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 conexões que os apps podem fazer ao back-end de destino do proxy da API durante um período específico, principalmente quando a contagem precisa é necessária.	Protege o back-end de destino do proxy de API contra abuso de token. Use PromptTokenLimit para isso.	Contar e limitar com precisão o número total de tokens consumidos para faturamento ou gerenciamento de cotas de longo prazo. Use a política LLMTokenQuota para isso.
Armazena uma contagem?	Sim	Não	Sim, ele mantém contadores que rastreiam o número de tokens consumidos pelas respostas do LLM.	Ele conta tokens para aplicar um limite de taxa, mas não armazena uma contagem persistente de longo prazo, como a política LLMTokenQuota.
Práticas recomendadas para anexar a política:	Anexe-a ao PreFlow de solicitação do ProxyEndpoint, geralmente após a autenticação do usuário. Assim, a política pode verificar o contador de cotas no ponto de entrada do proxy de API.	Anexe-a ao PreFlow de solicitação do ProxyEndpoint, geralmente no início do fluxo. Isso fornece proteção contra picos no ponto de entrada do proxy da API.	Aplique a política de aplicação (EnforceOnly) no fluxo de solicitação e a política de contagem (CountOnly) no fluxo de resposta. Para respostas de streaming, anexe a política de contagem a um EventFlow.	Anexe-a ao PreFlow de solicitação do ProxyEndpoint, no início do fluxo, para proteger seu back-end contra solicitações grandes demais.
Código de status HTTP quando o limite é 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 cotas é armazenado no Cassandra. É possível configurar a política para sincronizar o contador de maneira assíncrona para poupar recursos, mas isso pode permitir que as chamadas excedam levemente o limite.	Permite que você escolha entre um algoritmo de suavização ou um algoritmo de contagem efetiva. O primeiro suaviza o número de solicitações que podem ocorrer em um período especificado, e o segundo limita o número total de solicitações que podem ocorrer em um período especificado, não importa a rapidez com que são enviadas em sequência. A suavização não é coordenada entre os processadores de mensagens.	Pode ser configurado como CountOnly para rastrear o uso de tokens ou EnforceOnly para rejeitar solicitações que excedam a cota. Ele funciona com produtos de API para permitir configurações granulares de cota com base no app, no desenvolvedor, no modelo ou em um conjunto específico de operações de LLM. Usa <LLMTokenUsageSource> para extrair a contagem de tokens da resposta do LLM e <LLMModelSource> para identificar o modelo usado.	O cálculo de tokens pode ser um pouco diferente daquele usado pelo LLM. O elemento <UserPromptSource> especifica o local do comando do usuário na mensagem da solicitação.
Saiba mais:	Política de cotas	Política SpikeArrest	Política LLMTokenQuota	Política PromptTokenLimit

Dica:você também pode usar o seguinte para proteger back-ends lentos sem afetar o desempenho das APIs:

• Criar fluxos compartilhados reutilizáveis:combine políticas e recursos em um fluxo compartilhado que você pode consumir de vários proxies de API e até mesmo de outros fluxos compartilhados.
• Encadear proxies de API: especifique que um proxy é o endpoint de destino de outro, conectando efetivamente os dois proxies em uma cadeia de proxy. Encadear proxies dessa maneira pode ajudar a evitar um salto de rede e, portanto, melhorar o desempenho geral.