Compara políticas de límite de frecuencia

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Punto clave:

Las políticas de cuota, SpikeArrest, PromptTokenLimit y LLMTokenQuota se usan para límite de frecuencia, pero tienen diferentes propósitos y operan con diferentes métricas. Si bien las políticas de Quota y SpikeArrest se enfocan en los recuentos de solicitudes, las políticas de PromptTokenLimit y LLMTokenQuota administran y controlan el consumo en función de los tokens, lo que es fundamental para las cargas de trabajo de IA y modelos de lenguaje grandes (LLM).

Si bien SpikeArrest y PromptTokenLimit mantienen los recuentos con alta confiabilidad, están diseñados para usar una caché de mejor esfuerzo de Redis para almacenar sus recuentos. Debido a que la caché no se replica, hay casos en los que los conteos pueden perderse, como un reinicio de los servidores de caché o, también, otros casos excepcionales.

Por estos motivos, recomendamos no usar SpikeArrest ni PromptTokenLimit para casos de uso que requieren un recuento preciso. Solo la política síncrona de cuotas o LLMTokenQuota ofrece recuentos precisos en todas las regiones durante un período determinado.

Usa el siguiente cuadro comparativo para decidir qué política usar para tu caso de uso de límite de frecuencia:

	Cuota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Úsala para lo siguiente:	Limita la cantidad de llamadas al proxy de API que una app o desarrollador puede realizar durante un período específico. Es mejor para límite de frecuencia en intervalos de tiempo más largos, como días, semanas o meses, en especial cuando se requiere un recuento preciso.	Limita la cantidad de llamadas a la API que se pueden realizar en un proxy de API en todos los consumidores durante un período breve, como segundos o minutos.	Administra y limita el consumo total de tokens para las llamadas a la API de LLM durante un período especificado (minuto, hora, día, semana o mes). Esto te permite controlar los gastos en LLM y aplicar una administración detallada de las cuotas según los productos de API.	Protege el backend de destino del proxy de API contra el abuso de tokens, las instrucciones masivas y los posibles intentos de denegación de servicio limitando la tasa de tokens enviados en la entrada a través de la regulación de solicitudes según la cantidad de tokens en el mensaje de instrucción del usuario. Es un paradigma comparativo de Spike Arrest para el tráfico de API, pero para los tokens.
No lo uses para lo siguiente:	Proteger el backend de destino del proxy de API contra los aumentos de tráfico Usa SpikeArrest o PromptTokenLimit para eso.	Contar y limitar la cantidad de conexiones que las apps pueden realizar en el backend de destino del proxy de API durante un período específico, en especial cuando se requiere un recuento preciso	Protege el backend de destino del proxy de API contra el abuso de tokens. Para ello, usa PromptTokenLimit.	Contar y limitar con precisión la cantidad total de tokens consumidos para la facturación o la administración de cuotas a largo plazo Para ello, usa la política LLMTokenQuota.
¿Almacena un recuento?	Sí	No	Sí, mantiene contadores que registran la cantidad de tokens que consumen las respuestas del LLM.	Cuenta los tokens para aplicar un límite de frecuencia, pero no almacena un recuento persistente a largo plazo, como la política LLMTokenQuota.
Prácticas recomendadas para adjuntar la política:	Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, después de la autenticación del usuario. Esto permite que la política verifique el contador de cuotas en el punto de entrada del proxy de API.	Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, al principio del flujo. Esto proporciona protección contra los aumentos de tráfico en el punto de entrada del proxy de API.	Aplica la política de aplicación (EnforceOnly) en el flujo de solicitud y la política de recuento (CountOnly) en el flujo de respuesta. Para las respuestas de transmisión, adjunta la política de recuento a un EventFlow.	Adjúntala al flujo previo de solicitudes de ProxyEndpoint, al comienzo del flujo, para proteger tu backend de mensajes demasiado grandes.
Código de estado HTTP cuando se alcanza el límite:	429 Servicio no disponible	429 Servicio no disponible	429 Servicio no disponible	429 Servicio no disponible
Información útil:	El contador de cuotas se almacena en Cassandra. Puedes configurar la política para sincronizar el contador de forma asíncrona y ahorrar recursos, pero esto puede permitir que las llamadas superen apenas el límite.	Te permite elegir entre un algoritmo de suavizado o un algoritmo de recuento eficaz. El primero reduce la cantidad de solicitudes que pueden ocurrir en un período especificado y el último limita la cantidad total de solicitudes que pueden ocurrir dentro de un período específico, sin importar qué tan rápido se envíen sucesivamente. El suavizamiento no está coordinado en los Message Processors.	Se puede configurar como CountOnly para hacer un seguimiento del uso de tokens o como EnforceOnly para rechazar las solicitudes que superen la cuota. Funciona con los productos de API para permitir configuraciones de cuota detalladas según la app, el desarrollador, el modelo o un conjunto específico de operaciones de LLM. Usa <LLMTokenUsageSource> para extraer el recuento de tokens de la respuesta del LLM y <LLMModelSource> para identificar el modelo utilizado.	El cálculo de tokens puede diferir ligeramente del que usa el LLM. El elemento <UserPromptSource> especifica la ubicación de la instrucción del usuario en el mensaje de solicitud.
Obtén más detalles:	Política de cuotas	Política de SpikeArrest	Política LLMTokenQuota	Política PromptTokenLimit

Sugerencia: También puedes usar lo siguiente para proteger backends lentos sin afectar el rendimiento de las APIs:

• Crear flujos compartidos reutilizables: Combina políticas y recursos en un flujo compartido que puedes consumir desde varios proxies de API, e incluso desde otros flujos compartidos.
• Encadenar proxies de API: Especifica que un proxy es el extremo de destino de otro y conecta de manera efectiva los dos proxies en una cadena de proxy. La cadena de proxies de esta forma puede ayudarte a evitar un salto de red y, así, mejorar el rendimiento general.